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. -------------- next part -------------- A non-text attachment was scrubbed... Name: odd_riff_size.patch Type: application/octet-stream Size: 669 bytes Desc: not available Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20150710/400380b6/attachment.obj
lvqcl 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.Applied. Thanks. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
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.mail at 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>
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)?