I finally ran across an AIFF with a non-zero block_size in the SSND chunk, and the flac command line refused to process the file. The file was created by the Metric Halo Labs MIO Console recording application. In this case, for a 24-bit mono recording, the block_size was set to 3, which is somewhat redundant, but not illegal.
This prompted me to investigate the AIFF specification for block_size, and I've learned is that this field can safely be ignored when reading an AIFF or writing a new AIFF. The only time the block_size field needs to be interpreted is when an application is making a partial write of audio samples to an existing AIFF.
I suggest completely removing the check in encode.c which only accepts '0' for block_size. The block_size must be read to advance the file 4 bytes (i.e. to skip over the block_size), but there is no harm in completely ignoring the value, and no harm in proceeding to decode the AIFF without remembering block_size for later use.
There is one caveat: --keep-foreign-metadata should somehow be amended to remember this value so that the original AIFF can be precisely recreated later, but that would be a feature request after the above 'bug' has been corrected.
Log in to post a comment.