Bug report: WaveLab Pro writes a malformed iTunes trkn atom in M4A renders — track number invisible in Apple Music
Summary
When rendering to M4A (AAC), WaveLab Pro writes the iTunes-style track-number
atom (moov.udta.meta.ilst.trkn) with an invalid data-type indicator
(0x0000001F instead of 0x00000000) and a 7-byte value payload instead of
the standard 8 bytes. As a result, Apple Music / iTunes / Finder ignore the
tag entirely: the track number field shows up empty, although tools such as
ffprobe (which do not validate the type indicator) still display it.
Environment
- WaveLab Pro 13.0.20 (build as reported in the
©tooatom: “WaveLab Pro 13.0.20”) - macOS 26.5 (build 25F71), Apple Silicon
- Render format: AAC (M4A), 128 kbps CBR, encoded through the bundled
FFmpeg 8.0.1 (aac_atAudioToolbox encoder) - Track number set in the WaveLab montage / CD metadata: track 1 of 2
Steps to reproduce
- In WaveLab Pro, set up a render to M4A (AAC) with a track number in the
metadata (e.g. track 1 of 2). - Render the file.
- Import the resulting
.m4ainto Apple Music (or inspect it in Finder’s
Get Info panel).
Expected result
The track number is displayed (“1 of 2”).
Actual result
The track number field is empty in Apple Music even
though the trkn atom is present in the file.
Analysis
Hex dump of the trkn atom as written by WaveLab (file offset 0x2A1470 in
the sample file):
00 00 00 1F 74 72 6B 6E trkn box, size 31 <- should be 32
00 00 00 17 64 61 74 61 data box, size 23 <- should be 24
00 00 00 1F type indicator = 0x1F <- INVALID, must be 0x00
00 00 00 00 locale
00 00 00 01 00 02 00 payload: 7 bytes <- should be 8:
pad, track=1, total=2, pad(2) track(2)
1 trailing byte total(2) pad(2)
The same atom as written by compliant taggers (AtomicParsley, iTunes, TagLib,
mutagen, FFmpeg’s mov muxer) — this is also the byte-exact form that fixed
the file:
00 00 00 20 74 72 6B 6E trkn box, size 32
00 00 00 18 64 61 74 61 data box, size 24
00 00 00 00 type indicator = 0 ("reserved"/binary, implicit)
00 00 00 00 locale
00 00 00 01 00 02 00 00 payload: 8 bytes (pad, track, total, pad)
Two defects:
-
Type indicator is
0x1F(31). Per Apple’s QuickTime File Format
specification (“Metadata” chapter, Data Atoms and Well-Known Types),
the 32-bit version/flags field of a metadatadataatom holds a
well-known data-type code.trkn/diskmust use type0
(“reserved” — value interpreted implicitly by the atom type). Type 31 is
not a registered well-known type, so Apple’s parsers discard the atom.
Note that 0x1F (31) happens to be the size of the enclosingtrknbox,
which may hint at the underlying bug in the writer (a size value being
written into the version/flags field). -
Payload is 7 bytes instead of 8. The
trknvalue is defined as four
16-bit big-endian fields: padding, track number, track total, padding.
WaveLab writes only one trailing padding byte, making both thedata
box (23 vs 24) and thetrknbox (31 vs 32) one byte short.
Other atoms written by the same tagging pass are fine — e.g. the ©too
atom (“WaveLab Pro 13.0.20”) uses the correct type indicator 1 (UTF-8) and
correct sizes. Only the binary-typed number atoms are affected.
Evidence that the defect is in WaveLab’s tag writer (not FFmpeg)
- The FFmpeg command line issued by WaveLab (captured via a logging
wrapper) contains no-metadata track=...option, and replaying that
exact command against the bundledffmpegbinary produces an M4A with
notrknatom at all and©too= “Lavf62.12.102”. - The final rendered file contains
trknand©too= “WaveLab Pro
13.0.20”: WaveLab rewrites theilstafter FFmpeg has finished. - FFmpeg’s mov muxer (
mov_write_trkn_taginlibavformat/movenc.c)
hard-codes the compliant 32/24-byte, type-0, 8-byte-payload form and is
therefore incapable of producing the observed bytes.
Proof that this is the cause of the Apple Music symptom
Patching only the trkn atom of a rendered file to the compliant form
shown above (type indicator 0x1F → 0x00, payload padded to 8 bytes, box
sizes 31/23 → 32/24, parent ilst/meta/udta/moov sizes adjusted by
+1) — with the audio stream and every other byte untouched — makes Apple
Music display the track number correctly. Re-tagging with AtomicParsley
(--tracknum 1/2 --overwrite) has the same effect.
Suggested fix
In WaveLab’s MP4 metadata writer, for trkn (and presumably disk):
write 0x00000000 as the data atom’s version/flags (well-known type 0)
and an 8-byte payload (uint16 padding, uint16 number, uint16 total,
uint16 padding), giving data size 24 and trkn size 32.
References
- Apple, QuickTime File Format Specification, “Metadata” chapter —
“Data Atoms” and “Well-Known Types” (type 0 = reserved/implicit binary;
list of valid type codes, which does not include 31). - ISO/IEC 14496-12 (box size/structure rules).
- Interoperability references writing the compliant form: iTunes /
Apple Music itself, AtomicParsley (AtomFlags_Data_Binary = 0, 4×uint16
payload), TagLib, mutagen, FFmpeglibavformat/movenc.c.
A sample rendered file (before/after fix) can be provided on request.
