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.