ACIDCAT . FILE FORMAT REFERENCE

AIFF Anatomy

Audio IFF / AIFCApple, big-endian
rev 2026.06

magic "FORM"

endian big

container IFF chunks

form AIFF / AIFC

AIFF is Apple's IFF container: a FORM header, a form type (AIFF or compressed AIFC), then chunks, all big-endian. It mirrors RIFF with the bytes flipped and COMM in place of fmt. The standout is the sample rate, stored as an 80-bit IEEE-754 extended float that Python's struct cannot unpack, reassembled by hand. Hover a field to light its bytes, click a + for its table. Color marks kind (see the key).

chunk regions

FORM wraps the lot; COMM and SSND are required, the rest optional. Big-endian sizes, word-aligned with a pad byte on odd lengths.

▸FORM0x00 . 12 bytes

magic"FORM"

sizeu32 BIG-endian = file size - 8

form type"AIFF" (PCM) or "AIFC" (compressed)

signed sizethe IFF size field is signed by spec (Pascal-compatible), a ~2 GB nominal ceiling; unsigned use is common but a deviation

the container header (12 bytes)

Byte for byte the shape of a RIFF header, and the opposite byte order.

▸FVERaifc version . 4 bytes

Required in AIFC, absent in plain AIFF. One u32 timestamp naming the format version; the only defined value is 0xA2805140, the Mac epoch (seconds since 1904-01-01) encoding of 23 May 1990. Readers compare it exactly.

▸COMMcommon . drawn below

Channels, frame count, bit depth, and the 80-bit sample rate. AIFC adds a 4-char compression type and a pascal-string name after the rate; the type must be checked against the known set before any decode. See the byte map below.

uncompressedNONE, twos, sowt, raw , in24/in32, 42ni/23ni, fl32/fl64: frames are real frames, duration is exact

sowt“twos” reversed: little-endian PCM inside the big-endian container. Assume big-endian samples and it decodes to full-scale noise

packet-codedalaw/ulaw, ima4, MAC3/MAC6, QDMC/QDM2, Qclp: frames count packets, duration is only approximate and flagged ~

unknown 4ccsurfaced with a warning, never silently treated as PCM

▸SSNDsound data

offsetu32, bytes to the first frame (usually 0)

block_sizeu32, block alignment (usually 0)

audiosize - 8 - offset bytes; clamp to the bytes actually present

the audio chunk header (16 bytes)

Two fields sit between the chunk and its samples. Skipping them is the classic AIFF bug.

▸MARK / INSTmarkers, instrument

MARKu16 count, then id + position + pascal-string name

INSTbase note, detune, gain, key/velocity range, sustain/release loops referencing marker ids

▸COMTtimestamped comments

num_commentsu16 record count

time_stampu32, seconds since the 1904 Mac epoch

markeri16 MARK id the comment annotates, 0 = none

textu16 count, then count bytes, padded to even

▸AESDaes3 channel status

A verbatim 24-byte AES3 channel-status block. Byte 0 carries: bit 0 professional/consumer, bit 1 audio/non-audio, bits 2-4 emphasis, bits 6-7 sample rate (48000 / 44100 / 32000 / unindicated).

▸APPLapplication data

signature4-byte OSType naming the owning application

dataapplication-defined; "pdos" and "stoc" begin it with a pascal string naming the app/structure

▸bascapple loops tempo

Apple Loops metadata: version, beat count, root key, scale, time signature. No official spec; layout field-verified against indexed loops. Tempo is not stored directly: bpm = beats / (frames / rate) * 60.

▸cate / trns / coll / FLLRapple loops companions

catecategory labels (instrument, genre) as NUL-padded ASCII on a 50-byte grid, after a 4-byte count

trnstransient/slice table used for time-stretching; the REX hiding inside AIFF

collcollection membership; no published field layout

FLLRfiller/padding so metadata can be rewritten in place

a trns record (16 bytes)

A 76-byte header comes first: a version at 0x00, two constants, a timestamp at 0x08, and the record count as a big-endian u32 at 0x48. Then one fixed record per transient, and nothing else -- payload length is always 76 + 24 × count.

The header is 76 bytes, not 100, and the difference is one whole record. The first record sits at 0x4C and its position is frame 0: the downbeat. Read the header as 100 bytes and the arithmetic still closes -- the payload divides evenly either way -- but the count the chunk states about itself no longer matches, and the transient that gets swallowed is the first one in the loop.

▸CHANchannel layout

CoreAudio's AudioChannelLayout, byte for byte the payload of a CAF chan chunk. It says which speaker each channel drives, which COMM cannot: COMM counts channels and stops there.

CHAN, header and layout (20 bytes)

▸NAME / AUTH / (c) / ANNO / ID3text + embedded tag

NAME / AUTHplain text: title, author

ID3an embedded ID3v2 tag, same as MP3 carries

a text chunk, and the pad byte (14 bytes)

The length counts the text. It does not count the byte that may follow it.

COMM chunk

18 bytes for AIFF. Example: 2 channels, 88200 frames, 16-bit, 44100 Hz.