From the deadwax

Twenty Years of Tags Deserve a Careful Editor

By Keynell
metadataid3mp3preservation

You correct a spelling in an old MP3 and then notice that another artist credit has disappeared. Or a name with an accented character looks wrong in a different player. The song still plays, so the edit appears successful until you inspect the details.

A collection kept for twenty years can contain tags written by several generations of software. An editor may be changing one field inside a structure with an older version, unusual encodings, several stored values, and data the editor does not display. A tidy form on screen cannot show all of those decisions.

Private Press handles legacy ID3 with version-aware writing, ordered text values, and refusals for structures it cannot safely rewrite within its supported rules. There are limits worth understanding before you apply a change to the oldest part of your collection.

The version changes the rules

ID3v2 tags organize metadata into frames: separate blocks for titles, artists, pictures, comments, and other information. The format version determines how those blocks and their contents are represented. A file that plays normally can still contain a tag that needs special handling during an edit.

Text is a clear example. ID3v2.3 defines Latin-1 and Unicode text encodings, with a byte order mark for the Unicode form. ID3v2.4 also defines UTF-8. The encoding marker must agree with the tag version and the bytes that follow it. ID3v2.3 specification, ID3v2.4 structure specification.

Private Press writes changed ID3v2.3 text using UTF-16 with a byte order mark. For ID3v2.4, it writes UTF-8. Supported text frames outside the requested changes retain their stored payloads rather than being rewritten merely to make the whole tag uniform.

That distinction gives an ordinary correction a sensible scope. In a hypothetical album, you can correct the title while leaving an existing performer list alone. The editor does not need to normalize every text frame to make that one change.

One visible name can represent several values

A text field is not always one string. ID3v2.4 permits multiple text strings separated by null terminators. ID3v2.3 tells readers to stop displaying text at a terminator, and real collections can still contain additional text after it. The same stored bytes can therefore need different treatment for display and preservation. ID3v2.4 text frame rules, ID3v2.3 text frame rules.

Suppose an artist frame contains two names in order. Private Press can display the first value while retaining the ordered values for search. You can find the album through a later stored name without forcing every name into the visible label. Showing one name does not, by itself, mean the other values have been deleted.

There is a separate writing decision. An untouched multi-value field keeps its stored payload on a supported edit. When you deliberately edit that field through a single-value text control, the replacement is the one value you entered. The earlier additional values are not automatically appended to it.

This deserves attention during cleanup. Re-entering the visible first value into a field that held several values can replace the list with that single value. If you only meant to change the genre, leave the artist field untouched. Review the fields you are changing, especially on collaborations and albums tagged by software that supports multiple credits.

Private Press may display only the first value in a field while keeping the additional values available for search. Cleaning up that display alone does not change which album the app has already scanned; deliberately editing title or artist text can.

Older tags can require an upgrade

When Private Press edits an ID3v2.2 tag, it upgrades the tag to ID3v2.3. That requires mapping older frame identifiers and, for some frames, converting their contents. It is more work than replacing a word in an otherwise unchanged container.

For supported legacy pictures, this includes converting the older picture representation while carrying the retained picture's image and descriptive content forward. A malformed mapped frame whose contents cannot be converted causes the mutation to be refused. Some unsupported structures, including compressed v2.2 tags, are also refused.

There is an important boundary: well-formed v2.2 frames without a supported v2.3 equivalent can be dropped during the upgrade, with a diagnostic count. This is not total historical metadata preservation. If your files contain uncommon vendor or experimental frames that matter to you, preserve an original copy and inspect that material before choosing an editor or a batch operation.

Reading a file and rewriting it have different requirements. A tolerant reader may recover useful information from a tag that a writer cannot reliably rebuild. Being able to see the title is therefore insufficient evidence that every part of the file is supported for editing.

Make the first correction small

Choose a few representative files from the older collection. Include an accented name, a multi-artist track, and an album with more than one embedded picture if you have them. Keep original copies. Change one field and read the result in the software you actually use.

Check the edited text, the fields you left alone, and any additional values or pictures you care about. Successful playback answers an audio question; it does not check every metadata detail. Likewise, a correct result in one player does not establish compatibility with every device you might own.

Once those checks fit your collection, expand the work in manageable selections. Private Press provides a careful repair path for supported tags, with explicit rules for what is shown, searched, retained, and replaced. Knowing those rules lets you correct a twenty-year-old spelling without casually turning twenty years of tagging choices into a fresh blank form.

Read about the file formats and tag handling covered by Private Press.

See the format-specific editing notes