I get that this is a bug, but it kinda sucks that people feel it’s all right to act this way. Software is hard and unless you’re using a language with zero-overhead iteration you’re probably writing your drivers in C and iterating with a for-loop like our ancestors did. Off by one errors are stupidly common and everyone is human.

I mean, fuck mega corporations. This is still cringeworthy.

That being said, it’s going to be fun to see quality differences in these operating systems in a few years because, as far as I know, Apple would rather force Swift into the systems-level language space than adopt a memory-safe language today.

Meanwhile Microsoft, Google, and Amazon, etc are all investing heavily in Rust by integrating it into their platforms.

They go on to deduce it’s an off-by-one error in the time domain.
So instead of 0-127 it’s processing 0-126 samples (a classing i < 127 instead of i <= 127 in a for loop)

https://social.treehouse.systems/@marcan/111160552044972689

The train of thought was:

• The aliasing is every 375 Hz.
• 48000 / 375 = 128 so this is some fourier thing with a block size 128???
• Wait no, this could be time domain, aliasing like that is what you get when you upsample without lowpassing.
• Specifically, when you upsample with zero-sample padding (standard), that is, when one sample out of 128 has the low frequency content.
• So this is like taking the average of a 128-sample block and adding it to just one sample?
• Wait, isn’t that almost equivalent to zeroing out one sample?

numpy time

fs, signal = wavfile.read("sweep.wav")
signal[::128] = 0
wavfile.write("lol.wav", fs, signal)

And the rest is history.

Edit:
Stupid less-than symbol getting html-coded