Individuals sometimes release music under one name for a while and then switch to using a different name. Ashasbeendiscussedfrequently, there are two broadly-accepted ways of representing this in MusicBrainz:
Create a single artist entity named after the currently-in-use name and add “ended” aliases for past names (and an alias for the artist’s legal name, if known).
Create entities for all of the artist’s performance names and link them to another entity representing the legal name using is person (a.k.a. “performs as” / “legal name”) relationships.
I tend to favor the first approach when it seems like the artist treats all the names as a single project since it makes things easier to manage (no duplicated or inconsistent gender/area data, all URLs go in one place, etc.).
As discussed in Picard 2.9 Beta 1, Picard 2.9 will enable its “Use standardized artist names” option by default for new users. I don’t use this option, but I’m worried that the single-entity editing approach may lead to undesirable behavior for new users: it seems like albums from an artist’s back catalog would end up getting the current name rather than the name that was used at the time of release, which could be confusing.
Am I misunderstanding how this option works, or should I think about switching to the multiple-entities approach? (Despite asking that, I’m sympathetic to @outsidecontext’s concern in the Picard thread that I quoted about not making changes to MB data due to the way that tagging software behaves.)
(And just to mention it since I hadn’t seen it discussed, there’s also an artist rename relationship that seems like it could be used to link performance names together without a central “legal name” artist. It sounds like it’s mostly intended for groups rather than individuals, though.)
I also may be misunderstanding how the Picard option works. Does it treat aliases as “standardized names”? It wasn’t clear to me from the docs, although it sounds like aliases are still used in at least some cases:
If the “Translate artist names” option above is also checked, it will override this option if a suitable alias is found.
I’m somewhat surprised this option is being enabled by default, and I definitely wasn’t aware of this.
I would still stick with the current approach of using ended aliases, as this approach allows us to differentiate between artists simply changing names vs. artists starting entirely new projects. The database structure and style should not be built around the limitations of data consumers where at all possible.
Maybe Picard could gain an option for using the “artist name” alias that was current at the time of a given release?
What has changed is the default value of the setting in Picard for new users. The option is still there to select whether “standardized” or “credited” names are used, and this setting isn’t changed in the settings for current users.
Personally, I need to have both the standardized name and credited name available for my file naming script, which is why I created the “Additional Artists Variables” plugin. That allows me to group albums in directories under a standardized name (so things like “Pretenders” and “The Pretenders” are kept together), while the metadata and file name indicate the credied name.
Perhaps, if it doesn’t require additional calls to the MusicBrainz API. I haven’t looked at what would be required for that yet, but there could be some issues deciding which date to use (especially if there is no date specified on the release or the release is a re-issue at a time when the artist was using a different alias), or which alias to use if the artist had multiple active aliases at the time of the release. Maybe enter a ticket for it, so the idea won’t get lost.
With this example I actually agree that the new default behavior is really not great. Given the feedback so far I would be in favor of reverting it.
The original PICARD-2634 was concerned about file naming splitting up same artist over multiple folders. Maybe we should approach just this issue.
@rdswift I agree with your proposal to integrate variables from your plugin into Picard directly. Maybe we should at least provide variables for standardzed artist and albumartist (e.g. %_artist_stanardized% and %_albumartist_standardized%), then change the default file naming script to use the standardized name for the artist folder.
What do you all think, would this solve the original issue without introducing all the issues of the changed default? @zas?
Reverting the default change is definitively the way to go according to feedback.
I agree adding new script variables would help to solve the original issue while providing more control on this to the user.
I personally use the sort name for the artist folder, which does end up standardized. Since that’s essentially the point of the sort name, maybe that could be used by default?
Well, we really have to consider multiple different aspects here. This whole thing unfortunately isn’t as simple as to just decide whether the default setting should be on or off.
Let me start by summarizing why standarized artist names are desirable in the first place:
Standarized artist names generally allow to get rid of unwanted artist name variations. This is important because there is a huge number of them in the database. Some examples here:
Standarized artist names allow to cleanly organize a music collection by artist. Most music player software (and hardware) will group audio files by either the %artist% or %albumartist% tag, and so you typically don’t want to have artist name variations in there.
Standarized artist names allow to accurately search your music collection by artist. With non-standarized names, this isn’t easily possible.
Standarized artist names allow to organize audio files into artist folders without creating multiple different folders for the very same artist.
Non-standardized artist names can clash with the sortable artist name. For example, it’s a little strange that the (non-standardized) artist name Hootie + the Blowfish has the sortname Hootie & the Blowfish. Using & instead of + isn’t necessary to obtain a well-defined sort order.
However, a (big) problem with standarized artist names are artist name changes. In case of an artist name change, some users want to use the old artist name for the old releases, while other users want to use the new artist name even for the old releases as well.
Now, using old artist names for old releases is currently only possible when using non-standarized artist names. However, this will come at the huge cost of having a lot of unwanted artist name variations as well. Since artist name variations are much more common than artist name changes, I’d still argue that the default setting should be to standardize artist names.
At the very least, the %albumartist% tag should always be standardized. This would at least solve some of the name variation issues outlined above.
However, a clean solution would be to actually change the option itself, and not just its default setting. Instead of a simple boolean, there should be three possible settings:
Never standardize artist names. This will use the artist credit names as before.
Standardize artist names except in case of an artist name change. This should be the default setting. It will use the standardized artist names by default. However, if there exists a different primary artist alias which was active at the time when the release appeared, then that artist alias is used instead.
Always standardize artist names. This will always use the standardized artist names as before.
Does this refer to the “This is the primary alias for this locale” checkbox in MusicBrainz’s “Edit alias” form? If so, do you have a feeling for how consistently this is checked for past “primary” aliases?
It seems like it can only be checked if a locale has been selected, and I’m not sure how many editors set locales for aliases. I typically don’t, apart from when entering aliases that use non-Latin scripts, as I have no idea what I’m supposed to select – is “Metallica” an “English” alias even though the same name is used in many non-English-speaking locales?
Thanks for your comment, derat. I simplified this one a little bit, in order to keep it simple. The complete algorithm should actually be (something like) the following:
If there exists a primary artist alias for a matching locale which has already ended but was active at the time when the release appeared, then that artist alias is used. Otherwise, if there exists a non-primary artist alias for a matching locale which has already ended but which was active at the time when the release appeared, then that artist alias is used.
Hence, non-primary artist aliases should of course be considered as well, but primary artist aliases should take precedence. Generally, only artist aliases which have already ended should be considered, since we only target artist name changes here.
That all makes sense. That means in order to move forward I think we should:
Revert this change for the 2.9 release (which is currently only blocked by some technical issues, but beyond that I don’t want to delay it any further)
We add a new ticket for handling this specific handling of artist aliases
I don’t know for sure if an artist can have multiple primary artist aliases for the same language/locale… might need to adjust this to include any former aliases for the proper language
But I think the discussion so far has been very clear. The change brings unintended issues that should be avoided in a new release. So for 2.9 not shipping this change is the solution for now.