.WAV File Format – RIFF chunks

The RIFF header

The file starts with the outer chunk’s header and its form type, 12 bytes in all.

The first 44 bytes of a real 16-bit stereo recording at 44,100 Hz:

00000000  52 49 46 46 BE 47 3C 00 57 41 56 45 66 6D 74 20  RIFF.G<.WAVEfmt 
00000010  10 00 00 00 01 00 02 00 44 AC 00 00 10 B1 02 00  ........D.......
00000020  04 00 10 00 64 61 74 61 74 24 3C 00              ....datat$<.

The RIFF size is 0x3C47BE, 3,950,526, so the file is 3,950,534 bytes. The format chunk says PCM, 2 channels, 44,100 Hz, 176,400 bytes a second, 4 bytes a frame, 16 bits. The data chunk holds 0x3C2474, 3,941,492 bytes of samples; the 8,998 bytes of the outer chunk after them are further chunks.

The outer size in practice

Readers that follow ckSize stop at the end of the outer chunk, so a wrong value hides chunks or runs off the end. The explorer reports each of these and keeps reading:

• a size larger than the file: the file has been cut short;
• a size equal to the whole file size, 8 too many, as some writers give it (29 of the files examined for this site, from two sound-effects libraries);
• bytes, or whole chunks, after the end of the outer chunk, which readers that follow the size do not see;
• a size of 0 or 0xFFFFFFFF, as a writer leaves it when it cannot go back and fill it in; the chunks are then read to the end of the file.

The chunk layout

The rest of the file is a run of chunks, back to back. Offsets are from the start of the chunk.

A chunk ID that is not printable ASCII, where the next chunk should start, means the sizes before it are wrong. Among the files seen, this mostly came from files made by joining audio, where the outer size was updated but the data size was not, so more samples follow the data chunk.

The pad byte

The pad byte keeps every chunk on an even offset. It is easy to forget: an 8-bit mono file with an odd number of samples has an odd data size, and the next chunk starts one byte later than the size alone suggests. The same rule applies to the small chunks inside a LIST.

Some writers leave the pad out. It was missing after an odd chunk in a few of the files seen, among them files from Awave and from old FL Studio sample packs. libsndfile always skips a pad byte. The explorer decides by looking ahead: after an odd chunk it takes the pad byte, unless a chunk header that fits starts straight away and none starts one byte later (it looks one chunk further to settle a tie), and then it reports the missing pad.

Chunk order

The 1991 specification gives the order as

RIFF('WAVE' <fmt-ck> [<fact-ck>] [<cue-ck>] [<playlist-ck>]
     [<assoc-data-list>] <wave-data>)

and says that “<fmt-ck> must always occur before <wave-data>, and both of these chunks are mandatory”. In practice only that rule holds: the data cannot be read without the format. Other chunks appear before or after the data, in any order. Writers often put small metadata chunks first and the data chunk last, or append metadata after the samples once a recording has finished.

A reader should look for chunks by ID and skip any it does not recognise, using the size and the pad rule.

A complete file

The smallest useful WAV file is 44 bytes of headers and then the samples. This one holds four frames of 16-bit stereo audio at 44,100 Hz.

00000000  52 49 46 46 34 00 00 00 57 41 56 45 66 6D 74 20  RIFF4...WAVEfmt 
00000010  10 00 00 00 01 00 02 00 44 AC 00 00 10 B1 02 00  ........D.......
00000020  04 00 10 00 64 61 74 61 10 00 00 00 00 00 00 00  ....data........
00000030  FF 7F 01 80 FF FF 01 00 00 01 00 FF              ............

Finding the samples

A robust reader never assumes the 44-byte layout. It walks the chunks:

1. Read 12 bytes and check for RIFF and WAVE.
2. Read an 8-byte chunk header.
3. If the ID is fmt , read the format. If it is data, note where the samples start and how long they are.
4. Skip ckSize bytes, plus one more if ckSize is odd, and go back to step 2 until the end of the outer chunk or of the file.

A data size of 0 or 0xFFFFFFFF is a placeholder from a writer that streamed the file and could not go back. FFmpeg then reads to the end of the file (“Ignoring maximum wav data size, file may be invalid”), and libsndfile repairs a file “which wasn’t closed properly” when the data size is 0 and the RIFF size is 8. The explorer takes the samples to run to the end of the file and reports it.