Music metadata tags explained: ID3, Vorbis comments and MP4 atoms

Every music file carries two kinds of information: the audio, and everything you know about the audio. The second kind is metadata, and it is stored inside the file in one of three systems, chosen by the container rather than by you.

• MP3 files use ID3 tags, in frames identified by four-character codes: TIT2 for the title, TPE1 for the artist, TALB for the album.
• FLAC and Ogg files use Vorbis comments, which are plain NAME=value text pairs: TITLE, ARTIST, ALBUM.
• M4A and MP4 files use MP4 atoms, the iTunes vocabulary, with names like ©nam, ©ART and ©alb.

The three describe the same concepts and disagree about the details, and almost every tagging problem anyone has ever had lives in that disagreement. This is the reference for what maps to what, and where it breaks.

One album, three files, three tagging systems

track.mp3MP3 stream · ID3v2 tag

Shape Named frames in a block prepended to the audio, so a player reading a stream gets the tags first.

Names Fixed four-character codes from a published list. Anything else needs a TXXX frame with its own description.

Text Four possible encodings, including ISO-8859-1 and UTF-8. Multiple values are a null-separated list.

track.flacFLAC stream · Vorbis comments

Shape A metadata block of free-text pairs, alongside other blocks such as STREAMINFO and PICTURE.

Names Any printable name you like, case-insensitive. A short list is suggested; the rest is convention.

Text UTF-8, always. A field may simply appear more than once to hold several values.

track.m4aALAC or AAC · MP4 atoms

Shape Atoms inside the MP4 container's metadata box, alongside everything else the container holds.

Names Four characters, many with a leading ©. Extensions use a freeform atom, ----:com.apple.iTunes:Name.

Text Typed values — some atoms are text, some are numeric pairs, and cpil is a boolean.

Embedded tags versus filenames and folders

Two places hold information about a track, and only one of them survives contact with other software.

Embedded metadata is inside the audio file. It travels with the file when it is moved, renamed, copied to a phone or handed to a different player, and it is what every modern player actually reads.

Filenames and folder structure are outside the file. They are useful — a sane Artist/Album (Year)/01 - Track.flac layout is worth having, and worth being consistent about — but they are a human convenience and a fallback, not a source of truth. Renaming a file changes nothing inside it. Which questions a folder tree answers that tags cannot is the other half of this distinction, and it is not the half most people expect.

There is a third place, and it is the one that costs people their work: a player’s own database. Star ratings, play counts and smart playlists that exist only in an application’s library file disappear with that application. If information matters over years, it belongs in the file.

The field mapping

The table below is the practical core of this article. Every row is one concept and how the three systems name it, following the mapping MusicBrainz Picard publishes and implements — which is as close to a lingua franca as this area has, because Picard has to write all three correctly.

Concept	ID3v2.4	Vorbis comment	MP4 atom	Caveat
Title	TIT2	TITLE	©nam	The one field everybody agrees on
Artist	TPE1	ARTIST	©ART	Multi-value handling differs — see below
Album	TALB	ALBUM	©alb	Must match exactly across the record, punctuation included
Album artist	TPE2	ALBUMARTIST	aART	The field that holds a compilation together
Track number	TRCK	TRACKNUMBER	trkn	ID3 packs the total as 3/12; MP4 stores a numeric pair; Vorbis needs a second field
Disc number	TPOS	DISCNUMBER	disk	Same three-way split as track number
Date	TDRC	DATE	©day	ID3v2.3 used TYER plus TDAT; converters lose precision here
Genre	TCON	GENRE	©gen	Free text everywhere in practice, despite ID3v1’s numeric list
Composer	TCOM	COMPOSER	©wrt	Essential for classical, ignored by most pop workflows
Compilation flag	TCMP	COMPILATION	cpil	TCMP is a non-standard but universally implemented frame
Artwork	APIC	METADATA_BLOCK_PICTURE	covr	Native FLAC uses a PICTURE block instead — see below
MusicBrainz recording	UFID:http://musicbrainz.org	MUSICBRAINZ_TRACKID	----:com.apple.iTunes:MusicBrainz Track Id	The only stable identity a track has
MusicBrainz release	TXXX:MusicBrainz Album Id	MUSICBRAINZ_ALBUMID	----:com.apple.iTunes:MusicBrainz Album Id	Identifies the pressing, not just the album
ReplayGain track gain	TXXX:REPLAYGAIN_TRACK_GAIN	REPLAYGAIN_TRACK_GAIN	----:com.apple.iTunes:REPLAYGAIN_TRACK_GAIN	A convention rather than a standard; widely implemented

Two patterns are worth noticing in that table.

Where a concept has no native home, every system escapes into a generic mechanism. ID3 uses TXXX with a description, MP4 uses a freeform ----:com.apple.iTunes: atom, and Vorbis just invents a field name. This is why MusicBrainz identifiers and ReplayGain values look so different in each format: they are all extensions, expressed in three different extension mechanisms. The ReplayGain row is the clearest example of a tag written by software for software — a loudness measurement a player reads and applies at playback rather than anything a person types.

The numeric fields are the awkward ones. Track and disc numbers are the only common concepts where the three systems genuinely store different kinds of thing, which is exactly why they survive conversion badly.

The three systems, individually

ID3 — the MP3 one, with the longest history

An ID3v2 tag is a block of frames, and “the default location of an ID3v2 tag is prepended to the audio so that players can benefit from the information when the data is streamed”. Each frame has a four-character identifier and a payload.

Three details cause most real-world trouble:

Version. ID3v1 was 128 bytes at the end of the file with fixed-length fields, and truncated anything longer. ID3v2.3 and ID3v2.4 are the ones in use. They differ in ways that matter — date handling, multi-value support, the encodings they allow — and a tagger writing v2.3 for compatibility will represent some things differently from one writing v2.4.

Text encoding. ID3v2.4 permits four: ISO-8859-1, UTF-16 with a byte-order mark, UTF-16BE without one, and UTF-8. A tag written in ISO-8859-1 cannot represent most of the world’s names, and mojibake in an old library is almost always this.

Multiple values. In ID3v2.4, “all text information frames supports multiple strings, stored as a null separated list”. Earlier versions had no such mechanism, so applications invented separators — a slash, a semicolon, a comma — and disagreed. A track credited to two artists is the single most common place tags stop round-tripping cleanly.

For anything without a frame of its own there is TXXX, a user-defined text frame; multiple TXXX frames may exist provided each has a unique description. That is where ReplayGain values and most MusicBrainz identifiers live.

Vorbis comments — the FLAC and Ogg one, and the most permissive

A Vorbis comment is a list of NAME=value pairs, and the specification is unusually short because it specifies very little.

• Always UTF-8. “Field contents … use the UTF-8 character encoding to allow easy representation of any language.” There is no encoding to get wrong.
• Names are case-insensitive — ARTIST, Artist and artist are the same field — and may contain any printable ASCII character except =.
• A field may repeat. “Field names are not required to be unique (occur once) within a comment header”, so two artists are simply two ARTIST lines. This is the cleanest multi-value model of the three by a distance.
• Almost nothing is mandatory. The specification proposes a short list — TITLE, VERSION, ALBUM, TRACKNUMBER, ARTIST, PERFORMER, COPYRIGHT, LICENSE, ORGANIZATION, DESCRIPTION, GENRE, DATE, LOCATION, CONTACT and ISRC — and then says that “no single or group of field names is mandatory”.

That permissiveness is the format’s strength and its one real weakness. Xiph’s own wiki puts the weakness plainly: “Although the syntax of VorbisComment is well-specified, various conventions exist for the field names in use.” Note what is missing from the proposed list above: ALBUMARTIST and DISCNUMBER, two of the most important fields in any library, are conventions rather than specification. So is the choice between TRACKTOTAL and TOTALTRACKS.

In practice the conventions have converged, and Picard’s mapping is the version almost everything implements. But “almost everything” is doing real work in that sentence, and it is why a field you can see in one tagger occasionally vanishes in another.

MP4 atoms — the M4A one, typed and Apple-shaped

.m4a, .m4b and .mp4 are all the MP4 container, and their metadata lives in atoms: four-character names, many prefixed with ©, inside the container’s metadata box.

The distinctive property is that values are typed. trkn and disk are numeric pairs rather than text, cpil is a boolean, covr holds image data. This makes MP4 metadata cleaner to parse and less forgiving to convert into: there is no way to write 3/12 into trkn as a string and hope for the best.

Extension works through freeform atoms of the form ----:com.apple.iTunes:Something, which is where MusicBrainz identifiers and ReplayGain values go, exactly as TXXX serves that role in ID3.

The vocabulary is narrower than ID3’s and much narrower than “anything you like”, which is one of the practical arguments in the FLAC versus ALAC decision for anyone who expects to script over their library.

Artwork is stored differently again

Format	Where the image goes
MP3	An APIC frame inside the ID3v2 tag
FLAC	A PICTURE metadata block, type 6 — a native block, not a comment
Ogg Vorbis	A METADATA_BLOCK_PICTURE comment holding a base64-encoded FLAC picture structure
MP4 / M4A	A covr atom
Any of them	A cover.jpg or folder.jpg beside the tracks, read as a fallback

Which of those two to use, what each costs in bytes, and why the same album shows different art in different applications is the artwork storage question in full.

The Ogg case is the odd one and worth understanding, because it explains an error people meet. Xiph’s own documentation describes the mechanism directly: “The binary FLAC picture structure is base64 encoded and placed within a VorbisComment with the tag name METADATA_BLOCK_PICTURE.” Base64 is valid UTF-8, so it obeys the rules for comment data. In a native FLAC file, though, the right place is the PICTURE block — and a FLAC file carrying artwork as a base64 comment instead has been known to upset implementations that were not expecting it.

Whichever convention you choose, choose one. A library where half the albums have embedded art and half have a sidecar will show you gaps that are not really gaps, depending on which player you opened.

Where the three systems actually disagree

This is the section to come back to when something looks wrong.

Problem	What is happening
Two artists became one string	ID3v2.4 uses null separators, Vorbis repeats the field, MP4 has its own handling. Converting flattens the structure into whatever separator the writer chose
The track total vanished	TRCK carries 3/12 as text, trkn carries a numeric pair, Vorbis needs a separate TRACKTOTAL or TOTALTRACKS field — and the two names are both in use
A compilation exploded into forty albums	Album artist is empty, so players fell back to the track artist. TPE2 / ALBUMARTIST / aART is the field that prevents it
The release date lost its month	ID3v2.3 split date across TYER and TDAT; ID3v2.4 unified it in TDRC. Converting downwards discards precision
Accented characters turned into symbols	An ID3 tag written in ISO-8859-1 and read as something else. Vorbis comments cannot have this problem, because they are always UTF-8
A field is visible in one tagger and not another	Almost always a Vorbis field name that is convention rather than specification, or a TXXX / freeform atom the other application does not map
FLAC tags that half the software cannot see	An ID3 block attached to a FLAC file. Move the values into Vorbis comments and remove it

The pattern behind all seven: the systems are equally capable and unequally opinionated. Anything that has to survive a conversion should be one of the plain, universally implemented fields, and anything clever should be somewhere you are willing to lose.

What a player does with all this

A library application reads whichever system the container uses and reconciles the three into one model — which is where the disagreements above stop being trivia and start being your album list.

Digr reads tags locally with lofty: title, artist, album, year, genre, disc and track number and duration, from all seven containers it indexes, with no lookup service contacted and nothing about your library leaving the machine. Album identity is keyed on album artist, which is the decision that keeps a compilation as one record rather than forty. Artwork comes from inside the file or from a sidecar image beside it, whichever exists, handled per directory rather than per track.

One thing Digr does not do today: write. Scanning opens your audio files to read tags and artwork and never modifies them, so nothing above can be corrected from inside the application. Explicit, reviewable, undoable tag editing — with a MusicBrainz lookup that proposes rather than imposes — is a 3–6 month roadmap item, planned as part of Digr Free. Until then the fixing happens in a tagger, and MusicBrainz Picard is the one that writes all three systems correctly — in the order that lets you find out which of seven things is wrong first, because a display that disagrees with a file is not always a file that is wrong.

The short version

Three systems, one per container family, describing the same concepts with different names, different type systems and different ideas about how much should be specified. ID3 is the oldest and the most versioned. Vorbis comments are the simplest and the least standardised. MP4 atoms are the most typed and the narrowest.

Fill in the plain fields, get album artist right, keep everything in the file rather than in a player, and expect the clever fields to be the ones that do not survive a conversion.

Sources

• MusicBrainz Picard — Tag Mapping — the field-by-field mapping between Picard’s internal names, ID3v2.4 frames, Vorbis comment fields and MP4 atoms, used for the mapping table above
• ID3v2.4 structure and ID3v2.4 native frames — tag placement, the four text encodings, null-separated multiple strings, and the meaning of each frame identifier
• Ogg Vorbis I format specification: comment field and header specification — UTF-8 contents, case-insensitive field names, repeated fields, and the proposed field names with none of them mandatory
• Xiph wiki — VorbisComment — METADATA_BLOCK_PICTURE as a base64-encoded FLAC picture structure, and the note that conventions vary for field names in use
• FLAC FAQ — Vorbis comments as the tagging system FLAC requires and guarantees support for
• Digr — features and roadmap — tags read with lofty and never written, album identity keyed on album artist, and metadata editing as planned Free work