I’m trying to come up with a long-term folder naming strategy for a large MusicBrainz Picard-managed library and I keep getting stuck on one problem: artists with identical names.
Using plain artist names seems like the cleanest and most readable option:
artist/
year - album/
But eventually you run into two completely different artists sharing the same name.
Adding MusicBrainz IDs solves that technically:
artist [mbid]/
but it becomes ugly quickly, especially for releases with multiple album artists where multiple MBIDs get appended to the folder name.
You get the idea… The folder name can become extremely long.
___
I also considered:
shortened MBIDs
putting collaborations into a separate folder
conditional naming rules
but every solution seems to introduce inconsistency or readability problems.
For people managing large long-term libraries across Linux/Windows/macOS/Plex/etc:
how are you handling artist name collisions in your filesystem layout?
As a real use answer, the two times this occurs in my FLAC collection I have just put (country) after them.
Anything else would just look like an unreadable mess.
In your collection, how often do you ACTUALLY have a clash? If it is just one or two, then don’t fight to make a perfect script. Instead make a couple of exceptions just to handle the couple of exceptions.
Identical artist names are indeed an edge case for most users. I must admit that this has not been a problem for me yet. I am simply trying to avoid mistakes in the future.
Let’s say there are two artists named “Nirvana”.
I make an exception for identical artist names: '“Nirvana 1” and “Nirvana 2”.
Now, if I add another album, and use Picard to rename the new content, the album will be placed in “Nirvana”. In which case I will have to sort out that mess manually, right?
I’m not sure about that either. The only way to make the artists unique (and keep the content extendable) is to append the MBID. That’s what I would do first, to determine whether there is actually a problem with identical artist names, and then, in case, I would create special rules to differentiate them.
I personally use an established folder structure that I only extend manually. I’ve thought a lot about a file naming script, but I’ve encountered insurmountable obstacles. Much worse than duplicate artist names (only 1 case in my database) are collaborations. There are problems like: artist A is the main artist, soloist, composer of all tracks, thus it’s an album by artist A - but on the front cover all artists involved are listed and therefore rightfully collaborators on the release. … No script can handle this.
If you don’t have that many collaborations, you can of course try to find a scripted solution. In jazz, there are many collaborations, and cases like the one described above are not exactly rare. Any automated solution would scatter the releases across countless collaboration artists.
Depending on your operating system and filesystem, it actually can’t. Comparison of file systems - Wikipedia shows a bunch of maximum filename lengths, which is the longest that the artist directory name can be. For single artists that’s probably not a problem, but for an opera release with a composer, conductor, orchestra, chorus, and a handful of soloists, I’d expect to hit the limit if MBIDs are included. I don’t know what Picard does in that case, but I manually just truncate names and add … at the end.
I guess Picard is really good at editing files once, but not really that good at maintaining and updating media then.
I mean, I can probably edit artists once, but updating the library with Picard later to reflect changes in the MusicBrainz DB is going to f*** up the manual exceptions for sure.
This is disappointing. Preferably I would want to sync data straight from MusicBrainz without manual interactions, exceptions and edge cases.
I would say it is the opposite. First time identifying your music you create the folder structure. And add the all important MBID for the release.
Now any updates you don’t move or rename files. Just let Picard update the metadata which it does quick by looking up by the Release MBID now in each file.
What I do for special cases is that I have scripts in Picard that set e.g. a special artist name based on the artist MBID.
That way I handle the one case in my library with identical artist names and some cases of identical named albums. By having this scripted I can easily retag files without breaking the folder structure again.
Also I agree with @IvanDobsky’s advice: handle such cases when they appear. They are not often.
I forget the exact script I use, but I append the first 6 or so characters of the MBID to my album folders to split them properly (a more common situation than multiple same name artists, at least for me), and you could do similar for artists, that would prolly solve this issue and do it fully automatically
alternatively, you could do a taggerscript that adds a custom tag to files from one artist based on the MBID. for instance, for Nirvana x you might add a disambig tag of 1 and for Nirvana y it gets a 2 instead, which could then be conditionally added in the file naming script (I think it’s $ifs, but I could be mistaken). it’s a bit more manual, since you’ve got to notice you’ve got a dupe, then manually add an exception, but it would look cleaner than the other solution
I do a lot of fixes like these (e.g. replacing compiler name with various artists, changing the name of the artist etc.). Each time I do so I add to preserve_tags the field names I don’t want Picard to touch in the future (preserve_tags: artist albumartist). I don’t want to think about when to use Picards “Move” feature and when not, so I always use it.
This technique allows you to fix all the things that locally differ from MB while still being able to refresh the data from upstream without it potentnially changing your file paths.
Note that to dynamically preserve tags you need a Picard plugin or script.
In your case, just add country to the artist name and remember to do that for all releases manually. You could create script to automatically map specific mbids to names but I guess this happens so rarelly that manual fix is not a problem.
Lets say you changed albumartist from Gilles Peterson to Various Artists. On next Picard fetch that will get reverted. To make it permanent on case by case basis, (e.g. tomorrow you change Label and want to stick), you need Picard plugin/script.
This can be used for artist name too: If you stick country on ambiguous X - X (IT) it will get reverted on next fetch unless you do this.
(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.
Ah yes, hadn’t thought of that, it would add the comment (if it exists) to all artists, and these days there aren’t that many unique names.
I suppose it’s better than a random mbid or something that would be on everything.
Only option then it to have 2 file naming scripts, a main one that does everything as normal, and then a second you can use when you come across a ‘Nirvana’ situation.
Then you can have it like this if you prefer
Standard Script - Nirvana\Bleach\01. TrackName.mp3
Disambiguation - Nirvana (60s band from the UK)\All Of Us\01. TrackName.mp3
You could use 1 script that has if section at the beginning. If mbid is in given array which u maintain, use disamb. scheme, otherwise default scheme. Your job is only to just add to array once and it is set forever.