"cannot open parser": Max vs WAVs with "junk"

Misc
James Harkins's icon

James Harkins

I was just helping a student to investigate the famous "cannot open parser" error for some audio files.

I used SuperCollider to look at the header (because I had recently written a hexdump-style print function for byte data) and found:

-- good file
52 49 46 46 64 C4 0A 00  57 41 56 45 66 6D 74 20   RIFFd... WAVEfmt 
10 00 00 00 01 00 02 00  44 AC 00 00 10 B1 02 00   ........ D.......
04 00 10 00 64 61 74 61  40 C4 0A 00 00 00 00 00   ....data @.......
00 00 00 00 FF FF 00 00  00 00 00 00 FF FF 00 00   ........ ........

-- bad file
52 49 46 46 6A CC 0A 00  57 41 56 45 4A 55 4E 4B   RIFFj... WAVEJUNK
1C 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
66 6D 74 20 10 00 00 00  01 00 02 00 44 AC 00 00   fmt .... ....D...

- ID (RIFF or RIFX)
- size (little-endian), 4 bytes
- "WAVE" (format string)

... and at this point, RIFF allows a chunk called "JUNK" to be inserted, to align the WAVE part proper to a certain boundary. It's optional, but, according to the daubnet page, it is part of the RIFF standard: "To align RIFF chunks to certain boundaries (i.e. 2048bytes for CD-ROMs) the RIFF specification includes a JUNK chunk."

After that would come "fmt" and "data" chunks.

The good file has no JUNK in the chunks.

The bad file has a JUNK segment, to push "fmt" down to exactly byte offset = 48.

So it looks, then, like some versions of Max do not fully implement the RIFF standard.

This... would have to be a bug, wouldn't it? SuperCollider, by way of libsndfile, has no trouble with the "bad" file. Nor does Pd, nor Audacity, Reaper, ... etc etc. They all just skip the JUNK chunk without any fuss.

Is this a known issue? I see this is a somewhat frequent question on the forum, but I didn't find where anyone else identified a concrete cause.

hjh