Around the packets an ALAC file in MP4 carries what any MP4 file carries: sample tables that
say where each packet is and how long it lasts, and a meta box of iTunes-style
tags. This page shows what is specific to ALAC files, and what Apple’s encoder
(afconvert, the same one iTunes and Apple Music use) and FFmpeg write for
them. The boxes themselves are described on the MP4 pages: see
sample tables and
metadata boxes. All numbers are big-endian.
Sample tables
Every ALAC packet is one MP4 sample, and every packet can be decoded by itself, so no
sync-sample box (stss) is written: with none, all samples are sync samples.
The tables of a 2-second, 44,100 Hz stereo file written by afconvert hold:
| Box | What it holds for ALAC | Example |
|---|---|---|
stts | Every packet lasts frameLength (normally 4096) units, in a timescale equal to the sample rate. The last packet is shorter when the audio does not fill it | 21 packets of 4096, then 1 of 2184: 88,200 samples |
stsz | The size in bytes of every packet. The sizes differ, because compression does: a loud passage costs more bytes than a quiet one. A fixed size appears only for audio that cannot be compressed, which is stored uncompressed | 1,674 bytes for the first packet; 22 entries |
stsc | How many packets sit together in a chunk. afconvert writes six to a chunk, with a shorter run in the last chunk | chunk 1: 6 packets; from chunk 4: 4 packets |
stco or co64 | Where each chunk starts in the file. co64 (64-bit offsets) appears when the data lies past 4 GiB | 4 chunk offsets, the first at 4096 |
stss, ctts | Absent: every packet is a sync sample, and decoding order is playing order |
The sample entry’s channelcount and samplesize repeat the cookie’s
numbers; the cookie’s are the ones to trust (see the sample entry).
The media timescale is the sample rate, so a packet’s duration in the table is a number of samples.
The explorer lists every packet in its Samples tab (offset, size, time, and which elements it holds) and, under Sound, a table of every packet’s elements with their fields; each row links to the packet’s bytes.
Gapless playback: iTunSMPB
A free-form item named iTunSMPB in the namespace com.apple.iTunes
tells a player how many samples of the stored audio are not music, so albums can play without
gaps. Its value is text: a space, then twelve fields of hexadecimal digits separated by
spaces.
| Field | Digits | Meaning |
|---|---|---|
| 1 | 8 | Always 00000000 |
| 2 | 8 | Encoder delay (priming): samples at the start to skip |
| 3 | 8 | End padding: samples at the end of the last packet to drop |
| 4 | 16 | Original length: the number of real samples |
| 5 to 12 | 8 each | Written as 00000000 by the encoders seen here; the meaning of other values is not published |
The tag written by afconvert for the file above reads
00000000 00000000 00000778 0000000000015888 00000000 …: no delay, 0x778 = 1,912
samples of padding and 0x15888 = 88,200 samples of sound. The packets hold 22 × 4096 =
90,112 = 1,912 + 88,200 samples, so the three numbers agree with the file. ALAC needs no
priming (the codec adds no delay), so the delay is 0, unlike AAC’s usual 2,112. Apple’s
encoder shortens the last packet’s duration in stts to 2,184 as well, so a player
that follows the tables alone also stops at the right sample. A file may instead
carry an edit list (edts); the explorer cuts the waveform to it. FFmpeg writes no
iTunSMPB for ALAC.
Another free-form item, iTunNORM, holds a run of hexadecimal numbers of volume
normalisation data (Sound Check); how iTunes computes them is not published, and the explorer shows
the text unchanged.
Chapters
Two ways exist and the explorer reads both. FFmpeg and Nero’s tools write a chpl box
in udta: a full box of version 1, then four reserved bytes, a one-byte count, and for
each chapter a 64-bit start in units of 100 nanoseconds, a one-byte title length and the UTF-8 title.
Two chapters, One at 0 and Two at 1 second, look like this:
00 00 00 29 63 68 70 6C size 41, chpl
01 00 00 00 version 1, flags 0
00 00 00 00 reserved
02 2 chapters
00 00 00 00 00 00 00 00 start 0
03 4F 6E 65 length 3, "One"
00 00 00 00 00 98 96 80 start 10,000,000 units = 1 second
03 54 77 6F length 3, "Two"
Apple’s tools write a text track instead, linked from the audio track by a tref
box of type chap; each of its samples is a two-byte length and the title, with a UTF-16
byte order mark when the title is UTF-16.
Files named .alac
There is no format called .alac. The extension is given by people and tools to a
MPEG-4 file that holds Apple Lossless, to tell it from AAC in .m4a, and the file
inside is exactly the one described here: ftyp, moov and
mdat boxes. Neither Apple nor the open-source codec describes a bare stream of packets
with the cookie in front, so a file of that kind has no defined layout, and the explorer does not guess
one. The explorer opens a .alac file as MPEG-4 and reports a file that is not
MPEG-4 (plain text, for one) as not that format; an MPEG-4 file that holds AAC under the name
.alac is shown as AAC.