nayuki / nayuki-web-published-code Goto Github PK

I have been using the JavaScript implementation of Smallest-Enclosing-Circle
with the following data:
points = [{x: 33.656329, y: 73.069683}, {x: 33.668902, y: 73.06007}, {x: 33.676902, y: 73.07655}, {x: 33.66433, y: 73.086163}]
circle = makeCircle(points)
/*
r: 0.013245261728258257
x: 33.666616000000005
y: 73.0731165
*/

lat = circle[x]
long = circle[y]
radius = circle[r]

the returned long lat is accurate to be center point but the radius value which should be around 1Km seems incomprehensible.
Can you please tell me what's the unit being used to return the radius value and if there's a predefined method to convert it to SI units.

Hi,

Thank you for implementing DCT in so many languages, it is incredibly helpful.

I'm using FastDCT.ts from Nayuki-web-published-code/fast-discrete-cosine-transform-algorithms/FastDct.ts and have noticed when using fastDctLee.transform followed by fastDctLee.inverseTransform on the same array, the result seems to be scaled up by a factor of 4. Codified:

let arr: number[] = [0,1,2,3,4,5,6,7];
fastDctLee.transform(arr);
console.log(arr); // [ 28, -12.884646045410275, 0, -1.3469096018078828, 0, -0.4018058074719937, 0, -0.10140464551929199 ]
fastDctLee.inverseTransform(arr);
console.log(arr); // [ -1.7763568394002505e-15, 4, 8, 12.000000000000004, 15.999999999999996, 20, 24, 28 ]

Is this a feature of fastDctLee, or am I right to expect applying the inverse transform should get me back to the original data? If this is how it is intended to work, what adjustment would I need to make to make it 'symmetrical'?

SUMMARY

It appears that SimpleEncodeWavToFlac.java produces a bad FLAC file, possibly because of the block size.

STEPS TO REPRODUCE

1. Prepare a test audio file in WAV format
2. Compile SimpleEncodeWavToFlac.java
3. Convert the file: java SimpleEncodeWavToFlac orig.wav out.flac
4. Use ffmpeg to convert the resulting FLAC file to WAV: ffmpeg -i out.flac out.wav

OBSERVED RESULT

In Step 4, the conversion will fail because the FLAC file produced by SimpleEncodeWavToFlac.java cannot be decoded:

Press [q] to stop, [?] for help
[flac @ 0x564ee0f5c380] blocksize 4096 > 4095
[flac @ 0x564ee0f5c380] decode_frame() failed
[flac @ 0x564ee0f52f80] blocksize 4096 > 4095
[flac @ 0x564ee0f52f80] decode_frame() failed
[flac @ 0x564ee0f49ec0] blocksize 4096 > 4095
[flac @ 0x564ee0f49ec0] decode_frame() failed
Error while decoding stream #0:0: Invalid data found when processing input
    Last message repeated 2 times
[flac @ 0x564ee0f5c380] blocksize 4096 > 4095
[flac @ 0x564ee0f5c380] decode_frame() failed
[flac @ 0x564ee0f52f80] blocksize 4096 > 4095
[flac @ 0x564ee0f52f80] decode_frame() failed
[flac @ 0x564ee0f49ec0] blocksize 4096 > 4095
[flac @ 0x564ee0f49ec0] decode_frame() failed
Error while decoding stream #0:0: Invalid data found when processing input
    Last message repeated 2 times

ADDITIONAL INFORMATION

If I change Line 96 as follows, then it appears that the FLAC file produced is correct:

@@ -93,7 +93,7 @@
 		
 		// Read raw samples and encode FLAC audio frames
 		for (int i = 0; numSamples > 0; i++) {
-			int blockSize = Math.min(numSamples, BLOCK_SIZE);
+			int blockSize = Math.min(numSamples, BLOCK_SIZE - 1);
 			encodeFrame(in, i, numChannels, sampleDepth, sampleRate, blockSize, out);
 			numSamples -= blockSize;
 		}

Hi, after reviewing FastDct.ts, I noticed a few incorrect and redundant argument checks, notably the check for length === power of two in fastDctLee.transform and fastDctLee.inverseTransform.

The expression (n <= 0 && (n & (n - 1)) != 0) will return true for all negative numbers (which will never be the result of Array.length. No check for n <= 0 is needed, so the correct check should be:

if((n & (n - 1)) !== 0) throw "Length must be a power of 2";

In the current state, the code runs even with invalid input but with incorrect results due to the improper logic in the check.

Not an issue (and probably off-topic), but...

Your web article and open-source implementation of the force-crc32 solution was great. Thank you for sharing it! 👍
I actually had no idea that a non-brute-force approach was possible and was happily surprised when I found your article on the web.

Cheers! 👋