#402 Wave Parser doesn't pad chunks

[James Boer]

Hey all,

It looks like there's a fairly simple (and common) bug in the LAME wave parser. It doesn't pad chunk reads to word boundaries, so it will fail to correctly parse any valid wave file that happens to have an odd-sized chunk before the data chunk. It's pretty rare, but we actually ran into this situation in our processing pipeline where ProTools chunks were rearranged in front of the wave data by our Dolby post-production batch processing machine.

It's a fairly simple fix, so I can just describe it here, if that's ok. In get_audio.c file, in the parse_wave_header() function (line 1140), we see:

else {
subSize = Read32BitsLowHigh(sf);
if (fskip(sf, (long) subSize, SEEK_CUR) != 0) {
return -1;
}
}

All chuck reads should be padded to word boundaries in all RIFF files, including the WAV format.

So, you could fix the code by doing something like this (untested code, just an example):

else {
subSize = Read32BitsLowHigh(sf);
if (fskip(sf, (long) subSize + subSize % 2, SEEK_CUR) != 0) {
return -1;
}
}

Please let me know if you have any questions, or would like me to post a sample wave file with these sorts of chunks (I can do this on Monday when I'm back in the office).

[Robert Hegemann]

Hello James, a sample wave file would be nice to have. This will allow us to test the modification.

[James Boer]

Demonstrates odd-sized chunk parser bug

[James Boer]

Sure thing Robert. I've attached a wave file that demonstrates this issue.

[Robert Hegemann]

Thanks James! It seems we already padded uneven chunks when reading AIFF files. For WAVE files, this is fixed now in CVS.

[James Boer]

Not a problem - thanks for taking care of that. Also, in general, a big thanks to you guys for the work you do on this project!