The fact chunk gives the length of the audio in sample frames. For PCM the
length follows from the data size, but for compressed audio it does not, so the
specifications require a fact chunk in every WAV file that is not PCM.
Fields
Offsets are from the start of the chunk. Numbers are big-endian.
| Offset | Size | Type | Name | Description |
|---|---|---|---|---|
| 0 | 4 | char[4] | ckID | fact |
| 4 | 4 | u32 | ckSize | 4, or more if later fields are added |
| 8 | 4 | u32 | dwSampleLength | the number of sample frames, that is samples for each channel |
The 1991 specification names the field dwFileSize, “Number of samples”,
and adds that “Added fields will appear following the <dwFileSize> field.” None
has been defined.
00000026 66 61 63 74 00 00 00 04 00 00 01 B9 fact........The count, 00 00 01 B9, is 441. The file’s data chunk holds 3,528 bytes
of 8-byte frames, which is also 441 frames.
When it appears
- The 1991 specification requires it for every compressed format, and for a file whose
samples are in a
wavllist. Microsoft’s 1994 revision requires it for every format that is not PCM. - So ADPCM, A-law, µ-law and other codecs have one, and players use it to show the length.
- Floating point files: SciPy writes one, as in the example above.
- Integer PCM: optional, since the frame count is the data size divided by the block align.
How far to trust it
For ADPCM the last block is often short, and the fact count is the only
exact length; the explorer takes the frame count from it. For PCM, G.711 and float the
explorer counts the frames in the data chunk and shows the fact count beside
them when the two differ.