ffprobe says the file is pcm_s16le, and I don’t do anything special with the Python for reading it in.
Swift is reading it in as a Float32, which for some reason works (Float64 fails because it’s a Double). Python appears to be reading it in as Float64 (the default for the soundfile library), which explains the multiple orders of magnitude of difference.
However, the fact that Swift is reading the same values instead of different ones — why would that be the case?
You’re right, and as will all things, producing a full MRE has solved all my problems.
Paste: hqgfgUJz is the Swift code I had, and in adding the Python code that produces the values that I thought were correct, I realized that it was the PYTHON code that was wrong.
tl;dr Python was overwriting the values with a Hann window, which is why they looked different by the time I inspected them.
I was using numpy and had code to the effect of the following two lines:
inp = self.voltages[start:end]
inp *= self.window
This causes self.voltages to be overwritten, which I was NOT expecting.
Anyways, the Swift code was totally fine, but I am absolutely open to suggestions on improving it!
pcm_s16le is signed Int16 little endian samples, reading them as 32 bit floats can not possibly be right.
I don't have the PCM file to see what are the values of the first few samples to expect from it.
My understanding is that the difference between reading them as Int16 and Float32 is that Float32 value = Int16 value / max Float32 value, so I wasn’t worried about them. And since I put it into a Fourier transform, I figure it’s their relative values that are important.