Why your MP3 tags look different in every player

Every MP3 can carry two tags at once

The older format, ID3v1, is a fixed 128-byte block glued to the very end of the file. It has room for thirty characters of title, thirty of artist, thirty of album, four of year, and nothing else. When those fields fill up, they are simply truncated.

The newer format, ID3v2, sits at the front of the file, has no practical length limit, and holds everything modern players show: track and disc numbers, composer, comments, lyrics, cover art. Most files written this century have both, because taggers keep writing the old block for the benefit of ancient hardware.

Nothing keeps the two in step. Edit a title in one program and it may update only the modern tag, leaving a stale copy at the end of the file that some other player prefers.

Non-English text survives in one tag and not the other

ID3v1 has no concept of character encoding. It is bytes, interpreted with whatever legacy encoding the reading program assumes, which means Korean, Japanese, Cyrillic and accented Latin either come out as the wrong characters or as question marks.

ID3v2 fixed this by putting an encoding byte at the start of every text frame, so a title can be stored as UTF-8 or UTF-16 and read back correctly anywhere. This is why a track can show its proper title in one app and a row of question marks in another: the two apps are reading different tags.

The cover art lives in the tag, not next to the file

Album art is embedded in an ID3v2 picture frame, complete with a type — front cover, back cover, artist photo — and the image bytes themselves. A folder.jpg sitting beside the file is a convention some players honour and others ignore entirely.

So artwork that appears on your phone but not in your desktop player usually means the art is only in one of those places. It is also why a single album can end up several megabytes larger than it needs to be: a large cover embedded in every track is stored once per file.

Players cache what they read the first time

Most music software builds a library database when it first scans a folder and reads from that database afterwards. Retagging the file on disk does not update the library, so the old name persists in the interface even though the file is correct.

Before concluding that a tag edit failed, force the player to rescan or remove and re-add the track. A surprising share of tagging complaints are a stale cache rather than a stale tag.

Track numbers and their surprising conflict

The original ID3v1 had no track number at all. A later revision found room for one by taking the last two bytes of the thirty-byte comment field, so a track number exists only if the comment is twenty-eight characters or shorter.

That is a real trade-off encoded in the format: a long comment and a track number cannot both be stored in the old tag. If your track numbers vanish in one player, this is a likely reason.

What the file itself tells you

Beyond the tags, the first frame of audio carries the bitrate, sample rate and channel mode, and these describe what was actually encoded rather than what a tag claims. A file labelled as high quality whose frames say 96 kbps was not improved by relabelling it.

Duration is a related trap. A constant-bitrate file stores no length at all, so players estimate it from the file size, which is why a variable-bitrate file without a proper header often shows the wrong duration and seeks inaccurately.

How to sort out a file that disagrees with itself

Read both tags before changing anything, so you know which one your problem player is believing. If they differ, that difference is the answer, and the fix is either to correct the stale one or to remove the old block entirely.

When you do write, prefer a tagger that writes ID3v2 with a Unicode encoding, and only keep the old block if something in your setup genuinely needs it. Two sources of truth in one file is exactly the arrangement that produced the problem in the first place.