The SSND chunk holds the audio. There is at most one, and it is required
unless the file has no sample frames. What the bytes mean depends on the
compression type.
Fields
| Offset | Size | Type | Name | Description |
|---|---|---|---|---|
| 0 | 4 | u32 | offset | where the audio starts in soundData; most software writes 0 |
| 4 | 4 | u32 | blockSize | the size of the alignment blocks; 0 means the data need not be block-aligned |
| 8 | … | bytes | soundData | the audio |
A reader should find the audio at offset from the start of
soundData. FFmpeg, for one, adds offset and skips the block
size.
Uncompressed audio
With NONE or twos, sample points are two’s-complement
numbers, most significant byte first. A sample of fewer bits than the bytes it uses is
left-justified, with the spare low bits zero:
sampleSize | Bytes |
|---|---|
| 1 to 8 | 1 |
| 9 to 16 | 2 |
| 17 to 24 | 3 |
| 25 to 32 | 4 |
With sowt, the same samples are stored little-endian: 16-bit values are
byte-swapped, which is why many tools treat it as a form of PCM.
Floats (fl32, fl64) are big-endian IEEE numbers.
alaw and ulaw are single bytes; see
µ-law and A-law.
Channels
Frames are stored in time order and channels are interleaved within each frame, in the same way as in plain AIFF.
Compressed audio
A codec’s data is stored in that codec’s own layout. The common chunk still gives the
audio’s channels, frames and sample rate, with sampleSize the depth before
compression. The specification left the layout of each codec to its definers, and the
AIFF-C chunks do not describe them.