WAV - Failure when reading file

[Tangenten]

I'm calling new Track() on a .wav filepath in order to get some metadata from it. and my app gets stuck forever, continuously allocating more and more memory. This error prints over and over again:

Offset and length were out of bounds for the array or count is greater than the number of elements from index to the end of the source collection. (Parameter 'count') at System.IO.FileStream.ValidateReadWriteArgs(Byte[] buffer, Int32 offset, Int32 count) at System.IO.FileStream.Read(Byte[] buffer, Int32 offset, Int32 count) at ATL.AudioData.IO.List.readInfoPurpose(Stream source, MetaDataIO meta, ReadTagParams readTagParams, UInt32 chunkSize, Int64 maxPos) at ATL.AudioData.IO.List.FromStream(Stream source, MetaDataIO meta, ReadTagParams readTagParams, UInt32 chunkSize) at ATL.AudioData.IO.WAV.readWAV(Stream source, ReadTagParams readTagParams) at ATL.AudioData.IO.WAV.read(Stream source, ReadTagParams readTagParams) at ATL.AudioData.IO.WAV.Read(Stream source, SizeInfo sizeInfo, ReadTagParams readTagParams) at ATL.AudioData.AudioDataManager.read(Stream source, ReadTagParams readTagParams) at ATL.AudioData.AudioDataManager.read(Stream source, Boolean readEmbeddedPictures, Boolean readAllMetaFrames, Boolean prepareForWriting) at ATL.AudioData.AudioDataManager.ReadFromFile(Boolean readEmbeddedPictures, Boolean readAllMetaFrames)

This is in version 4.21.0 . Downgrading to 4.20.0 fixes it and I'm no longer stuck in an infinite loop, although the error does print to the console once and only once (for each time loading the file). I'm on window 11 64 bit. It only happens on certain files, and I think .wav files in particular.

Speculation:

The debugger takes me to this while loop, which it gets stuck in: https://github.com/Zeugma440/atldotnet/blob/e38b6508d05922ea8234d3204043a625279ef910/ATL/AudioData/AudioFileIO.cs#L54

And it seems the reason has to do with this line of code here: https://github.com/Zeugma440/atldotnet/blob/e38b6508d05922ea8234d3204043a625279ef910/ATL/AudioData/AudioDataManager.cs#L340 This sets "result" to false every time because something is throwing, it returns "result" and so the while loop continues (I think that's the reason).

The line of code that is throwing is here: https://github.com/Zeugma440/atldotnet/blob/e38b6508d05922ea8234d3204043a625279ef910/ATL/AudioData/IO/WAV.cs#L350 Looking at the data in the debugger the "chunkSize" variable is one more than the data available left in the stream. so, we get the out of bounds error here.

[Zeugma440]

Thanks for your feedback and analysis. I'll take care of that shortly.

Would it be possible to have the file too?

[Zeugma440]

Fix available in today's v4.22 😅

[Zeugma440]

I'm still interested by the file, by the way. The library doesn't loop anymore, but the core issue remains unsolved

[Tangenten]

Tried 4.22.0 and not getting stuck anymore (: And while it seems like the metadata is coming through fine (or maybe it just fails gracefully halfway through?) it is still throwing errors on certain files. It's not super rare. When scanning through my sample library there's a constant output to the console. I can't find a real pattern to it either. These files are consistently giving me an error: https://www.dropbox.com/t/2dLCOUOeDg8VCBqQ

[Zeugma440]

Thanks for the share!

Looking at the file, it looks like the software you're using to tag those samples doesn't handle padding bytes properly.

In the ILST chunk, the IENG sub-chunk is padded with a byte whose value is 1, whereas WAV specs clearly say padding bytes should have a value of zero.

Can you do anything about that (e.g. homebrew tagging software)? Or should I write a workaround code?

[Tangenten]

I did not tag these files manually myself; I've gotten the error from files I've rendered out of audio software and from files I've downloaded from various sample packs online. So, I'm guessing I won't be the only person running into this issue. If the file itself is corrupted I guess it's fine to simply throw and exit, but I'm also not seeing any other media player or audio software complaining about the file. so maybe they have implemented a workaround or are just gracefully skipping metadata / exiting without complaining. for now, I've simply disabled the error logging as it had some impact on the performance.

[Zeugma440]

Thanks for the feedback. I'm implementing a workaround.

[Zeugma440]

Fixed in today's v4.23