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 little-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.
00000000 66 61 63 74 04 00 00 00 44 AC 00 00 fact....D...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, GSM and MP3 data in a WAV file have one, and players use it to show the length.
- Floating point and extensible files: many writers add one, and some readers expect it.
- Integer PCM: optional, since the frame count is the data size divided by the block align.
About one in nine of the files examined for this site had a fact chunk.
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. One µ-law file seen had a fact count of 15,675,
two frames fewer than its data held.