On Jul 13, 2015, at 11:04 AM, lvqcl <lvqcl.m...@gmail.com> wrote: > Brian Willoughby wrote: >> The ckSize field can be odd to represent the size of the valid data. >> >> However, the chunk itself must always be an even size. This requires a >> padding byte at the end of a chunk before the next chunk can begin, or >> before the end of file. The latter case is the one that most often occurs in >> buggy RIFF writing programs - the last chunk will have an odd ckSize and the >> file will be one byte shorter than a valid RIFF. > > The problem was in the size of RIFF chunk. > Should RIFF chunk size include the padding byte of a last chunk? > > For example, a program writes a RIFF WAV file which contains > 16-byte 'fmt ' chunk and 132219-byte 'data' chunk. > > Is 132255 (= 4 + 8 + 16 + 8 + 132219) the correct size of RIFF chunk, or > should it > be equal to 132256 (= 4 + 8 + 16 + 8 + 132219 + 1)?
That's an excellent question. I don't recall ever seeing this discussed. The specification is not explicit. My logical interpretation is that the RIFF chunk includes subchunks, and thus their data should be considered to always have an even number of bytes because that is the size of each chunk, even if the data inside the chunks may have an odd number of bytes. In other words, the RIFF chunk does not contain the audio data samples, which may be odd, but instead contains the chunk which are always even. Of course, when reading, it is preferred to be lenient in case the RIFF chunk has an odd size. However, when writing, I'd say that the ckSize should be even for the RIFF chunk, but odd for whatever the final chunk type is, e.g. 'data', assuming it has an odd number of bytes of data. I did a quick scan of the RIFF documentation, which seems to have changed over the years, but could find nothing definitive on this particular question. Brian Willoughby p.s. The only time that a 'data' chunk will be odd is for monophonic audio with 8-bit or 24-bit data. In contrast, all stereo files and all 16-bit files must have an even number of bytes in the 'data' chunk because those chunks are made of frames that are even in length. _______________________________________________ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
