.WAV File Format – Sample data

Frames and interleaving

A frame is one sample for every channel at the same moment. Frames follow one another in time order, and inside a frame the channels are interleaved: left then right for stereo, or the order of the channel mask for more channels.

Four numbers follow from the format chunk, for PCM, float and G.711:

• bytes per frame is nBlockAlign, which is nChannels × wBitsPerSample / 8;
• the number of frames is the data chunk’s size divided by nBlockAlign;
• the length in seconds is the number of frames divided by nSamplesPerSec;
• sample c of frame f starts at the data start plus f × nBlockAlign plus c × (nBlockAlign / nChannels).

A data size that is not a whole number of frames leaves a partial frame at the end, which the explorer reports.

Sample encodings

The format code and bits per sample together decide how each sample is stored. In the words of the 1991 specification, “the least significant byte is stored first”.

Up to 8 bits a sample is unsigned: subtract 128 to get a signed value. From 9 bits up every integer is signed two’s complement. A sample always fills whole bytes, and when it has fewer bits than its container the bits sit at the top with the rest zero: a 12-bit sample in a 16-bit container has the low four bits of its first byte zero, and a 20-bit recording is stored in 24-bit slots, with wValidBitsPerSample set to 20 in an extensible format chunk. A reader that ignores the valid bit count still plays the audio at the right level.

The explorer scales every sample to −1 to 1 for the waveform: 8-bit as (b − 128) / 128, 16-bit as v / 32,768, 24-bit as v / 8,388,608, 32-bit as v / 2,147,483,648, and float as it is.

A worked example

The four frames at the end of the complete file example: 16-bit stereo, so 4 bytes per frame.

0000002C  00 00 00 00 FF 7F 01 80 FF FF 01 00 00 01 00 FF

G.711 A-law and µ-law

Format codes 6 and 7 store one byte a sample, each byte a code for a 13-bit (A-law) or 14-bit (µ-law) value from ITU-T G.711. The common reference decoders, which the explorer follows, give the value on a 16-bit scale:

• A-law. a = code XOR 0x55; exponent e = (a >> 4) & 7; mantissa m = a & 15. The value is (m << 4) + 8 when e is 0, otherwise ((m << 4) + 0x108) << (e − 1). It is negative when bit 7 of a is clear. The range is ±32,256: code 0xD5 gives +8 and 0x2A gives −32,256.
• µ-law. u = NOT code; e = (u >> 4) & 7; m = u & 15. The value is (((m << 3) + 0x84) << e) − 0x84, negative when bit 7 of u is set. The range is ±32,124: 0xFF gives 0, 0x00 gives −32,124 and 0x80 gives 32,124.

Microsoft’s 1994 revision says wBitsPerSample should be 8 for these formats; McGill’s notes point out an example table that says 16. The files seen use 8. They also carry a fact chunk.

IMA ADPCM

Format code 0x11 stores 4 bits a sample in blocks of nBlockAlign bytes, each of which decodes on its own. This is how libsndfile decodes WAV IMA ADPCM, using the shift-and-add form of the IMA’s recommended algorithm; the explorer does the same.

1. Each block starts with a 4-byte header for each channel: the first sample (i16), output as it is; the step index (u8), 0 to 88, which libsndfile clamps when it is larger; and a reserved byte, zero (libsndfile logs “IMA ADPCM synchronisation error” when it is not).
2. Then come groups of 4 bytes for each channel in turn: channel 0’s 4 bytes, then channel 1’s, and so on. Each group holds 8 codes for its channel, the low nibble of each byte first.
3. For each 4-bit code n: step = STEP[index]; diff = step >> 3; if n & 4, add step; if n & 2, add step >> 1; if n & 1, add step >> 2. If n & 8 the sample decreases by diff, otherwise it increases; clamp it to −32,768 to 32,767. Then index += INDEX[n & 7] and clamp the index to 0 to 88.
4. A block decodes to 2 × (nBlockAlign − 4 × nChannels) / nChannels + 1 frames: 505 for a 256-byte mono block, 1,017 for 512-byte mono and for 1,024-byte stereo.

INDEX, for n & 7 from 0 to 7, is −1, −1, −1, −1, 2, 4, 6, 8. STEP has 89 values: 7, 8, 9, 10, 11, 12, 13, 14, 16, 17, 19, 21, 23, 25, 28, 31, 34, 37, 41, 45, 50, 55, 60, 66, 73, 80, 88, 97, 107, 118, 130, 143, 157, 173, 190, 209, 230, 253, 279, 307, 337, 371, 408, 449, 494, 544, 598, 658, 724, 796, 876, 963, 1060, 1166, 1282, 1411, 1552, 1707, 1878, 2066, 2272, 2499, 2749, 3024, 3327, 3660, 4026, 4428, 4871, 5358, 5894, 6484, 7132, 7845, 8630, 9493, 10442, 11487, 12635, 13899, 15289, 16818, 18500, 20350, 22385, 24623, 27086, 29794, 32767.

A worked example: a mono block whose header is 00 00 00 00 (sample 0, index 0) and whose codes start 77. The first code, 7, has step 7: 0 + 7 + 3 + 1 = 11, so the sample is 11 and the index becomes 8. The second, also 7, has step 16: 2 + 16 + 8 + 4 = 30, giving 41 and index 16. A third 7, at step 34, adds 4 + 34 + 17 + 8 = 63, giving 104. The output starts 0, 11, 41, 104.

FFmpeg’s general IMA decoder works out the difference as ((2n′ + 1) × step) >> 3 instead, which can differ in rounding.

Microsoft ADPCM

Format code 2 also stores 4 bits a sample in blocks of nBlockAlign bytes, for one or two channels. The coefficient pairs are in the format chunk. This is how libsndfile decodes it, and the explorer with it:

1. The block header holds, for each channel, bPredictor (u8, an index into the coefficient pairs), iDelta (i16), iSamp1 (i16) and iSamp2 (i16): 7 bytes a channel, all of one field before the next, so a stereo header is 2 + 4 + 4 + 4 = 14 bytes.
2. The first two output frames are iSamp2, then iSamp1.
3. Then come 4-bit codes, the high nibble of each byte first; with two channels the nibbles alternate left, right.
4. For each code: predict = (sample1 × coef1 + sample2 × coef2) >> 8; take n as signed (8 to 15 mean −8 to −1); the new sample is predict + n × delta, clamped to 16 bits; then delta = (ADAPT[n unsigned] × delta) >> 8, at least 16; sample2 = sample1; sample1 = the new sample.
5. A block decodes to 2 × (nBlockAlign − 7 × nChannels) / nChannels + 2 frames: 500 for a 256-byte mono block.

ADAPT is 230, 230, 230, 230, 307, 409, 512, 614, 768, 614, 512, 409, 307, 230, 230, 230.

A worked example: the mono block 00 10 00 64 00 32 00 10 00 has predictor 0, the pair (256, 0); delta 16; iSamp1 100 and iSamp2 50; and the codes 1, 0, 0, 0. The output is 50, 100, then 100 + 1 × 16 = 116, and 116 three more times, since a code of 0 adds nothing and the delta stays at its floor of 16.

Compressed formats

For ADPCM and other codecs, the data chunk is a run of blocks of nBlockAlign bytes, each decoding to a fixed number of frames given in the codec’s format data. The last block is often shorter than nBlockAlign and holds fewer frames. The number of frames cannot be worked out from the size, so these files carry a fact chunk with the exact count; the 1991 specification requires it for every compressed format. The explorer takes the frame count of an ADPCM file from it.

With the Ogg Vorbis format codes the data chunk holds a complete Ogg stream, pages starting OggS. In the files seen, which came from old FL Studio sample packs and name GoldWave or FL Studio 4 as their software, mode 1 files had a 26-byte format chunk and mode 2 files a 4,244-byte one. The explorer shows these and the other codecs as bytes and does not decode them.

Padding

When the data chunk’s size is odd, as with 8-bit mono or 24-bit mono audio with an odd number of frames, one zero pad byte follows the samples. It is not part of the audio and is not counted in the chunk size.

Wave lists and silence

The 1991 specification also allows the samples to be held in a LIST of type wavl, a run of data chunks and slnt chunks. A slnt chunk is a u32 count of samples of silence, “not necessarily a repeated zero volume or baseline sample”. A file with a wave list needs a fact chunk. No file seen uses one; the explorer shows such a list’s items as bytes.