WavFile reader fails when data chunk is not at byte 36

[KJ-Waller]

Firstly, thanks for making this library. I'm finding it very useful for a project I'm working on.

I'm having issues reading a couple of wav files, and am getting the error 'invalid WAV file (expected 'data' at byte 36)' when running the following line:

(int sampleRate, double[] audio) = WavFile.ReadMono(audioFile_path);

The audioFile_path is a valid path to a wav file, which worked fine before the repo was recently updated to use this custom wave file reader. The wav files I encountered this error with were from "The Ryerson Audio-Visual Database of Emotional Speech and Song" which you can find here: https://zenodo.org/record/1188976

I get the same error for any of the wav files of this database I've tried. For other datasets I'm using, I don't get this error. Is there something I'm doing incorrect or is this something you could possibly fix?

Regards,
Kevin

[swharden]

Hey Kevin,

Sorry to hear the new WAV reader isn't reading these files like it used to! On one hand I tried to get the new WAV file reader to be able to read sample rate out of the header and support 2-channel WAV files, but on the other hand this requires the header to be properly parsed and I suspect the WAV file you're reading doesn't strictly adhere to the format described in http://soundfile.sapp.org/doc/WaveFormat/ which I used to base the new WAV reader on.

I'll take a closer look at these WAV files and put the old function back in and/or modify the current function to ensure it can read these. The specific download link for the WAV files you referenced is https://zenodo.org/record/1188976/files/Audio_Song_Actors_01-24.zip

Note that the WAV reading method in Spectrogram 1.0 is here:
https://github.com/swharden/Spectrogram/blob/1.0.0/src/Spectrogram/Tools.cs
in a pinch you can add this function to your project (modifying it as needed to output double[] instead of float[])

I'll get this on NuGet later today. Thanks again for reporting it!

[KJ-Waller]

Thanks Scott! I appreciate the speedy reply. I'll use Spectrogram 1.0 until the fix. Thanks!

[swharden]

It looks like this error is caused because the Microsoft WAV file spec says that the 4 bytes at position 36 should be data but Apple WAV files use FLLR ("filler").

It seems this topic is addressed at length here.

For a simple fix I'll just remove the assert and allow these 4 bytes to be any characters, this should fix the problem.

[swharden]

Plot thickens...

• After FLLR is a UInt32 that decodes to 4044, then the byte position is at 44.
• 4044 bytes later (at position 4088) are the letters data I was looking for.
• The UInt32 following data decodes to 429230 (the number of samples in the file).
• Then the actual audio data starts.
• At the end of the file is a bunch of XML. Weird!

[swharden]

Just released Spectrogram 1.2.1 with an improved WAV file reader. I'm pretty sure this will do the trick! Let me know if you hit any snags 👍