Artist Folder Naming: How Do You Handle Artists With Identical Names?

MusicBrainz Picard
, ,
14

(maybe stupid) Proposal: Per-file tag pinning via a PINNED_TAGS tag

The idea is to allow users to “pin” specific tags on a per-file basis, so that pinned values are preserved when Picard re-tag.

How it differs from “Preserve Tags”:

  • Preserve Tags is a global setting, it applies the same list of protected tag names to all files. If you preserve albumartist, it’s preserved everywhere.
  • Pinned Tags would be per-file, you pin albumartist only on the specific files where you’ve made a deliberate override. Other files continue to receive updates from MB normally.

How it would work:

  • A standard multi-value tag called PINNED_TAGS is written to the file, containing the names of tags the user wants to keep unchanged (e.g., albumartist, label).
  • When Picard loads fresh data from MB, it reads PINNED_TAGS from the file and feeds those names into the existing preservation mechanism but only for that file.
  • In the UI, you’d right-click a tag → “Pin tag” / “Unpin tag”. Pinned means “don’t overwrite until explicitly unpinned”.
  • Since PINNED_TAGS is a regular tag stored in the file itself, it persists across sessions, survives file moves, and works with all common formats (FLAC, MP3, M4A, APEv2…).
  • Using a generic tag name means other applications could also respect it in the future.
  • Of course, PINNED_TAGS itself is always preserved by default (in Picard).

This would address the recurring complaint that manual per-file tag edits (renaming an artist for disambiguation, changing albumartist to “Various Artists”, etc.) get reverted on the next Picard fetch, without requiring plugins or applying global preserve_tags rules that affect the entire library.

AFAIK, the concept of per-field metadata locking exists in some audio/media apps, but always stored in an application-specific database, not in the files themselves. It would be in-line with what we do already with MBID-related tags.

Pros & cons?

3 Likes