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.
Some RIFF readers blindly expect an even number of bytes in every chunk, and seek past each chunk to see if another chunk exists afterwards. In the case where the last chunk ends a byte earlier than expected, this class of RIFF reader gets confused and fails. So, to reiterate: 1) odd value in ckSize is correct, when appropriate 2) odd size of chunk is not correct, not under any conditions 3) flac should read RIFF anyway, if the only problem is the final padding byte in the chunk Note: if a RIFF is truncated more severely than just a missing padding byte, then it should be considered an error that is reported to the user. It's difficult to preserve lossless quality when input data is missing! I did not review this patch, but I wanted to clarify the RIFF specification on this subject, and to share my experience with common RIFF writer/reader bugs. Brian Willoughby On Jul 9, 2015, at 2:28 PM, lvqcl <lvqcl.m...@gmail.com> wrote: > This patch should fix ticket https://sourceforge.net/p/flac/bugs/419/ > and its duplicate https://sourceforge.net/p/flac/support-requests/152/ > > some programs write odd value to ckSize of RIFF chunk. Not sure > is it correct or not, but flac should read them anyway.<odd_riff_size.patch> _______________________________________________ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
