WavAudioFormat problem with odd-sized INFO subchunks

General JUCE discussion
1

Hi.

I noticed that if the INFO chunk contains an odd-sized subchunk, the WavAudioFormatReader loses track of the next subchunk.
For example, for chunks like the following:

LIST(INFO)
{
	ICMT { (odd bites) }
	CMNT { ... }
	COMM { ... }
}

In such a case, these CMNT and COMM chunks will not be read.

In my opinion, in the “juce_WavAudioFormat.cpp”, the ListInfoChunk::addToMetadata() loop is missing a step to skip padding if infoLength is odd.

Thanks.

2

Well technically chunk sizes can not be odd.
So the file is corrupt. Odd chunk sizes should be considered illegal.
You could be lenient and try to read them anyway and pad the byte.
But to be compliant you don’t have to.

1 Like
3

hmmm
To my understanding, the RIFF spec allows odd-sized chunks (cksize is odd), and in that case, the insertion of padding 0 is required.
As an actual example, Adobe Audition CS6 exports odd-sized metadata chunks like this one.

Can I find documentation somewhere that odd-sized chunks are illegal?

4

Yes. But the writer has to pad not the reader. So the chunk size present in the file should always be even.

5

Yes, the size of the chunk itself is always even. But I am talking about cases where the “length of this chunk” field in the chunk header is an odd number. I believe that is legal.

6

With the list sub-chunks it becomes even murkier.
But I think you’re right, nothing afaik stated about the parity of the sub-chunks in the standard.
If the sub-chunk size is correct it should just read.
And if the chunk size is odd the reader can assume the pad byte is present and start reading the next chunk after.

7

Binary data of fixed or variable size. The start of ckData is word-aligned with respect to the start of the RIFF file. If the chunk size is an odd number of bytes, a pad byte with value zero is written after ckData. Word aligning improves access speed (for chunks resident in memory) and maintains compatibility with EA IFF. The ckSize value does not include the pad byte.

[1] Multimedia Programming Interface and Data Specifications 1.0

With that information I would still think, that an odd number and writing without the padding byte would violate that standard. Otherwise what would be the point of the byte in the first place?

The number of bytes might be odd, which is then adding the pad byte, so the next chunck starts at an even address again.

In that time 16 bit processors were standard, so an odd chunck would have a performance impact back then.

But I am not an expert here.