Editing MP3 Tags in Windows Explorer: ID3 Fields in File Properties

You can edit MP3 tags in Windows Explorer without installing anything, which makes the file property sheet the default tag editor on most machines. It is a partial one: it shows some fields, writes fewer, and quietly ignores parts of the file that other software reads. Knowing which parts explains almost every surprise in this area.

What Explorer reads from an ID3 tag, and from where

An MP3 file is a run of audio frames with metadata bolted on at either end. ID3v1 is a fixed 128-byte block at the very end of the file with seven fields, each truncated hard: thirty characters for the title, thirty for the artist, a single byte for a genre chosen from a numbered list. ID3v2 sits at the front, is variable in length, and is organised as named frames, so it can hold long strings, multiple artists, embedded cover art and arbitrary custom fields.

The property handler prefers ID3v2 and falls back to ID3v1. Which means a file tagged by an older program that wrote only the trailing block appears empty in the dialog while a media player shows it correctly. This is the single most common reason people conclude that MP3 tags in Windows Explorer are broken: both readers are behaving correctly and looking at different bytes.

The practical consequence is that any attempt to edit MP3 tags in Windows Explorer works on the ID3v2 block and only on that block. A file with no ID3v2 block gets one created on the first save, at which point the two tags exist side by side and can drift apart: the older block still holding whatever the previous program wrote.

Which fields you can edit in file properties

The dialog splits its content the same way the format does. The tag fields are editable: title, contributing artist, album, year, track number, genre, comment, and a few classification fields such as rating. The frame-derived values are display-only, because they are calculated from the audio when the file is read and there is nowhere to write them back to.

A save writes to ID3v2. If the existing block has enough padding the write is a small in-place update; if it does not, the entire file is rewritten to make room, which is why editing one character on a large file can take a noticeable moment and why a nearly full volume can make the operation fail. Nothing warns about this. The change simply does not stick.

Two limits catch people out. Multi-value fields are flattened: several artists arrive in one text box separated by semicolons, and editing them there rewrites the frame as entered. And any frame the handler does not map is left strictly alone, which is good news. It means editing in Explorer does not destroy fields it cannot show.

What a shell extension added to the property sheet

Before the built-in handler covered audio properly, the gap was filled by shell extensions: small in-process components registered against a file type, which the shell loads when a property sheet is built and which contribute their own tab. One such extension, published as freeware for Windows 9x, NT and 2000, added a single MP3 tab that did two things the shell then did not.

It put the editable ID3 fields and the decoded frame-header values on the same tab, so size, bitrate, length, sampling frequency, frame count and MPEG version sat directly under the fields you were editing. And it supplied an info tip, so hovering a file in a folder produced the same summary without opening the dialog at all: on the shell versions that supported tips, which at the time meant Internet Explorer 4 and later.

The figure above is a redrawing of that tab. It is worth looking at as an interface argument rather than nostalgia: the decoded values are the ones that tell you whether a file is worth keeping, and putting them beside the tag rather than one tab away is a better arrangement than the current default.

HKEY_CLASSES_ROOT\.mp3\shellex\PropertySheetHandlers\<handler>
  (Default) = {CLSID of the in-process component}

HKEY_CLASSES_ROOT\CLSID\{CLSID}\InprocServer32
  (Default)   = C:\Windows\System32\example.dll
  ThreadingModel = Apartment

Doing it now: what to use to edit MP3 tags in Windows Explorer

There are three levels of answer, depending on how many files are involved. For one or two files, the built-in dialog is enough and has the advantage of leaving unmapped frames untouched. For anything in bulk it is the wrong instrument: it edits one file at a time, offers no pattern-based renaming, and cannot repair the v1-versus-v2 mismatch that caused the problem in the first place.

A dedicated tagger handles all three, and the one setting worth checking before a bulk run is which tag versions it writes. Writing ID3v2 plus a synchronised ID3v1 block costs almost nothing and makes the files legible to both Explorer and any hardware that reads only the trailing block. Writing v2 only is cleaner and occasionally leaves an old car stereo showing nothing at all.

If tags look correct in a tagger and wrong in the shell after all of that, the remaining suspect is the cache. Thumbnails and property values are cached per user, and a rebuilt cache resolves a display that has fallen behind the file. It is worth trying before concluding that a write failed.