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 WAVE
specifications require a fact chunk in every file that is not PCM. In RF64
the count can pass 32 bits, and then its real value is in the
ds64 chunk.
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; 0xFFFFFFFF when the count does not fit, and the real count is sampleCount in ds64 |
The 1991 RIFF 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 FF FF FF FF fact........When it appears
- The 1991 RIFF 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 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.
How far to trust it
When dwSampleLength is 0xFFFFFFFF, read
sampleCount from ds64; the explorer does so. When it is any
other value, trust it over sampleCount. In one of the two RF64 files
examined for this site, a SciPy test file, the fact chunk says 4,410 frames,
which matches the data, while ds64’s sampleCount says
41,745.
For ADPCM the last block is often short, and the frame count is the only exact length;
the explorer takes it from here. 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.