Not sure if this should be a base feature or a plugin. a few artists perform under multiple names. in some cases, their work is so similar that i would prefer to group it all together. Vektroid is perhaps the best example of this. each “artist” has their own style, but they are all electronic with shades of vaporwave.
Currently my path formats might create:
Macintosh Plus - Floral Shoppe
New Dreams Ltd. - Initiation Tape
In the future I’d want:
Vektroid aka Macintosh Plus - Floral Shoppe
Vektroid aka New Dreams Ltd. - Initiation Tape
You can map up from a release to an artist credit. (todo for me: clarify how this mapping works)
Open question: how to choose a parent artist name. It could be whatever MB lists, or whichever artist has the most releases. I am fine writing my own rule here (perhaps with special cases for some user-defined artists) and don’t see a need to come up with some standard everyone likes. (Especially if it’s a plugin).
It’s arbitrary. Vektroid is her Twitter handle. If I do this my first pass will probably take whichever artist has the most albums in the beets library.
No, it won’t. Beets follows MusicBrainz and MusicBrainz knows Vektroid, Macintosh Plus et al. as equals. One solution might be to get beets to use the woman’s legal name (Ramona Andra Xavier), but as far as I know there’s no ID3 tag for an artist’s legal name.
Interesting! This sounds pretty tricky to do reliably, because it’s inevitably going to be based on some kind of heuristic (e.g., largest number of albums). I think starting with a plugin to see how it goes would be a good place to start. The plugin could work by, for each album, attempting to populate a $artist_aka field based on a bunch of crazy heuristic MusicBrainz queries and see how well that does what you expect?
For two given artists, are they actually equivalent?
For equivalent artists, what is the naming convention?
Thanks to MusicBrainz, concern (1) seems straightforward to answer: just look up the “also performs as” info and cache it locally in the beets DB. Rather than hacking new attributes onto albums or whatnot, a new table would make sense to me: maybe a map from each artist ID to its list of alias IDs. Though since these relationships are symmetric, such a structure would be redundant space-wise but efficient time-wise for lookups. Alternately, you could store the data as a list of sets… This seems like the start of creating an artists table in the DB, which would be good to keep minimal, but in this circumstance it would be helpful to have.
For concern (2): the new artist equivalence table could also have a column for “canonical artist name” which could be a vanilla string (e.g. “Vektroid”), or a template expression (e.g. “Vektroid aka ${alias}”). This would give total control over how the naming is done per artist (no hardcode heuristic will please everyone here), at the expense of the naming rules being hidden in the DB rather than declared in the config.yaml directly. Alternately, the plugin could offer nothing here, and instead recommend the existing rewrite plugin for such purposes. Simply identifying and reporting equivalent mb_artistids within a collection would go a long way toward helping to maintain a sensible rewrite list. Though artist name clashes (multiple artists with the same name but different MusicBrainz IDs) would remain a problem with this strategy.
On reflection, I’m just going to make a custom field. I only have <10 releases that apply to this so it’ll be faster than making a plugin. If I get more into Vektroid and have more releases I might revisit the plugin concept.
