You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 ;-)
The text was updated successfully, but these errors were encountered:
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 ;-)
The text was updated successfully, but these errors were encountered: