Why your music files have the wrong tags

An audio file doesn't know what it holds. It carries a title, an artist and a cover because someone, once, typed them into it. And that someone could be wrong.

Which is the thing worth knowing before you spend a weekend fixing a library by hand: a track's metadata is not a property of the sound. It is a note left beside it.

What is actually in the file

An MP3 is not only an audio stream. It drags a small block of text along with it: the ID3 tag, stuck to the front or the back of the file. Other formats have their own: Vorbis comments for FLAC and Opus, ilst atoms for AAC in an MP4 container. The idea never changes: key-value pairs, plus a picture.

TITLE=Nocturne
ARTIST=Ensemble Vireo
ALBUM=Low Tides
DATE=2019
TRACKNUMBER=4

None of it is verified, and nothing ties that text to the sound that follows. You can write Symphony No. 9 onto three minutes of silence: no player will object, no scanner will notice. The label is on the box, not in it.

A music library is a wall of labels nobody has ever read back.

Where the labels come from

Almost always one of four places, and each has its own way of lying.

• A ripped CD. The software derives an id from the track lengths and asks a database: historically CDDB, now MusicBrainz. Two discs that happen to share a layout share an id, and the wrong album wins.
• The filename. Plenty of tools assume Artist - Title.mp3 and split on the first dash. An artist whose name contains a dash, a title that contains one, a file called 01 - track 01.mp3, and the rule produces garbage with exactly the same confidence.
• The page the file came from. A web page title is not a track title, it is a pitch. Hence the (Official Video), HD, [Lyrics] and shouting capitals running through a whole collection.
• A human. The most reliable of the four, and the one that does not scale. Nobody tags three thousand files without giving up around fifty.

The five ways it breaks

The damage is always the same, whatever the source. Open your own collection now and you will find at least three of these.

• The album-artist field. On a compilation every track has its own artist, but the album has one. Tools that ignore ALBUMARTIST shatter it into eighteen one-track albums. That is the most common failure of all.
• Text encoding. ID3v2 allows several. A tag written as latin-1 and read back as UTF-8 gives you Björk instead of Björk, and it stays broken until someone retypes it.
• Guests. feat., ft., featuring, in brackets, after a comma, in the title or in the artist field. Six spellings of one fact, six separate artists in your list.
• Reissues. Remaster, anniversary edition, reissue with two bonus tracks: same album, different dates and track numbers. Sort by year and the discography becomes fiction.
• Blanks. No date, no track number, no artwork. A player that groups by album then falls back to alphabetical order, which is nobody's running order.

Why searching the title fixes nothing

The instinct is to send the tag text to a database and take the first hit. That fails precisely where you need it to work: when the text you started from is wrong.

A text search inherits the error it is meant to correct. It cannot separate two same-named songs by two different bands, a studio take from its live version, an original from a cover. Worse, it always answers something. Across a thousand files those plausible but wrong answers are invisible, until the day you go looking for a track and it is nowhere.

A fingerprint instead of a name

The other approach starts from the sound. Chromaprint reads the first two minutes of a track, measures how its energy falls across the twelve pitch classes frame by frame, and compresses that sequence into a compact fingerprint.

$ fpcalc -length 120 track.mp3
FILE=track.mp3
DURATION=241
FINGERPRINT=AQADtEmiKFKSJIeS5Hkg5X...

It describes what you hear rather than what someone typed. It survives re-encoding, a bitrate change, volume normalisation, a few seconds of silence at the head. The same recording as FLAC and as AAC yields, near enough, the same signature.

Then it has to be matched against something. AcoustID keeps that ledger: millions of fingerprints, each tied to a recording in MusicBrainz, the open music encyclopedia. Out of it comes a stable id, and with it the exact title, the credited artist, the release, the year, the position on the disc and the cover.

It stops being a search and becomes a recognition: the file no longer gets a say in what it claims to be.

What a fingerprint will not do

Three limits, worth knowing before believing in magic.

• It identifies a recording, not a song. A live take, a remix, an acoustic session are different recordings and get different ids. That is the intent, and exactly what a title search cannot do.
• It only finds what has been submitted. A self-released EP, a recording of a local gig, a track that came out yesterday: no fingerprint in the database, no answer. The database is open, and it takes contributions.
• It has no opinions. Genre, mood, the rating you give a record are in no spectrum anywhere. Those fields stay yours, which is as it should be.

Doing it yourself

None of this is proprietary. fpcalc ships with Chromaprint, and beets is the library manager that wires the whole chain together: it fingerprints, queries AcoustID, proposes the match, writes the tags and files everything away.

$ pip install "beets[chroma]"
$ beet config -e        # add chroma to the plugin list
$ beet import ~/Music/to-sort

Budget an evening for the first setup, and some patience for the cases beets asks you to settle yourself. It is an excellent tool, written by people who thought of everything, but it lives in a terminal, and you have to want to live there too.

What you get out of it

Correct tags are not fussiness. They are what keeps a collection readable when it changes machine, software or decade. Files do not get lost; catalogues get lost. A track named and filed properly is one you find with ls, ten years later, without the application that imported it.

Which is the only kind of ownership that matters for a music library: being able to open it without asking anyone.