The problem seems to be that when parsing the "SSND" chunk (inside ma_dr_wav_init__internal), the following method is invoked ma_dr_wav_bytes_to_u32_ex(offsetAndBlockSizeData + 0, pWav->container), which will increase the read cursor by a few bytes (link to source: https://github.com/mackron/dr_libs/blob/master/dr_wav.h#L3537). But when the SSND chunk has been parsed and it's time to seek forward to the next chunk, the seeking will now overshoot the target by these few bytes - and as a result, COMM is never reached.
A solution would of course be to reduce the chunkSize before seeking forward, but there's a little detail which prevented me from simply putting up a pull request: I'm not sure about the check which is performed before seeking forward (if (sequential || !isProcessingMetadata)).
Here, I understand that the AIFF parser does not support reading of metadata, nor does it support (sequential) writing - so why even bother checking for these things?
PS: when playing back the example files with miniaudio, the files are rejected by the dr_wav decoder (as you would expect), but two of them seem to be picked up by the dr_mp3 decoder and played back as a brief glitchy noise. I guess this isn't intended ;-)
If an AIFF file happens to have the "COMM" chunk at the end of the file, dr_wav will not be able to play it back. A few example files: https://drive.google.com/file/d/10TWdCnJxyq7R2B9ksYhA0AIpoJagCm5B/view?usp=sharing
The problem seems to be that when parsing the "SSND" chunk (inside
ma_dr_wav_init__internal), the following method is invokedma_dr_wav_bytes_to_u32_ex(offsetAndBlockSizeData + 0, pWav->container), which will increase the read cursor by a few bytes (link to source: https://github.com/mackron/dr_libs/blob/master/dr_wav.h#L3537). But when the SSND chunk has been parsed and it's time to seek forward to the next chunk, the seeking will now overshoot the target by these few bytes - and as a result, COMM is never reached.A solution would of course be to reduce the chunkSize before seeking forward, but there's a little detail which prevented me from simply putting up a pull request: I'm not sure about the check which is performed before seeking forward (
if (sequential || !isProcessingMetadata)). Here, I understand that the AIFF parser does not support reading of metadata, nor does it support (sequential) writing - so why even bother checking for these things?PS: when playing back the example files with miniaudio, the files are rejected by the dr_wav decoder (as you would expect), but two of them seem to be picked up by the dr_mp3 decoder and played back as a brief glitchy noise. I guess this isn't intended ;-)