Even with import: language: en in my config, a good few artist names were not localized. Looking at the musicbrainz data for them, I saw that they didn't have any English localized aliases, despite having English releases, credited to a localized name.
Though this can be corrected by adding the aliases in musicbrainz, I thought it might be useful if beets could use the artist-credit data in these cases.
Example Case
Though I have since added the necessary English locale alias myself, you can see that the band has credited as Tokyo Shoegazer on a US release before
Solution
In the case that no localized aliases are found for the artist, we can then try and find a valid alternative name from the artist-credits.
I've written a proof-of-concept doing this here, and I can go and make a PR using this integrating the changes into mb.py, and adding some test cases, however there are some potential issues with this solution that I think warrant discussion before I prepare a PR.
If it turns out too janky to merge, then I would be happy enough to have this as a plugin or a personal fork instead.
Potential Issues and Questions
API Lookups
We would require an additional API lookup with browse_releases for the artist id, per artist. In the case of a single artist the same as the album_artist, this is fine, however it could easily be problematic for an album involving many artists credits, and would create duplicate api lookups.
An option is to only attempt this solution for the album artist rather than the individual track artists.
Another is to have a small cache of artist release lookups in the mb module, to avoid duplicate api calls.
Wrong Alternative Name
The solution may not end up being super robust in the case of an artist credited by many names, and could end up treating what should really be a non-primary alias as a primary artist name.
An example of this is AJJ/Andrew Jackson Jihad .
I attempt to catch this case by:
- Not using a name which matches an existing alias which has an "end date" (artist has changed name since)
- Where there are multiple possible credited names to choose, pick the one associated with the newer release
ISO369-1 vs ISO369-3 Language Codes
Musicbrainz' style guide for the alias locale field, and the release language field seem to very loosely suggest use of ISO369, it seems like 369-3 is used for release languages,
while 369-1 is used for artist aliases. Beets currently handles aliases as if their locale is a two letter ISO369-1 style code, and so the language config option is usually set to match this assumption.
In my mockup I simply compare the release language with the config locale by converting both to ISO369-3 using a simple dictionary. For better handling however, perhaps a library such as pycountry could be used,
also in beets' existing handling of alias locales and the language config, though obviously another dependecy might be too much for the job...
Extra Config Option
This feature could be enabled (or disabled) by a config option, since the results can be subjectively better or worse.
Example Cases
I ran the mockup, testing against some example cases that I found with a beets query:
sh beet ls -a -f 'Artist Musicbrainz Aliases: http://musicbrainz.org/artist/$mb_albumartistid/aliases' '^language:en' 'albumartist::[^\u0000-\u007f]' '^mb_albumid::^$'
Looking at the artist aliases pages, you can see what aliases they have, and the list of credited names.
I tested my solution against some instances I ran into (which I have now added English aliases to):
- Midori, credited as Midori on a japanese release, with language = jpn, script = Ltn
- Miki Furukawa, credited as Miki Furukawa on an english release
- Rei Harakami, credited as Rei Harakami on japanese releases, with language = eng
- Shinsei Kamattechan, credited as Shinsei kamattechan (sic) on a UK release with language = eng
- Tokyo Shoegazer, credited as Tokyo Shoegazer on a US release
I've still to test this against more samples (such as everything in my library), just to see if it breaks significantly on edge cases in the musicbrainz data.
Even with import: language: en in my config, a good few artist names were not localized. Looking at the musicbrainz data for them, I saw that they didn't have any English localized aliases, despite having English releases, credited to a localized name.
Though this can be corrected by adding the aliases in musicbrainz, I thought it might be useful if beets could use the artist-credit data in these cases.
Example Case
Though I have since added the necessary English locale alias myself, you can see that the band has credited as Tokyo Shoegazer on a US release before
Solution
In the case that no localized aliases are found for the artist, we can then try and find a valid alternative name from the artist-credits.
I've written a proof-of-concept doing this here, and I can go and make a PR using this integrating the changes into mb.py, and adding some test cases, however there are some potential issues with this solution that I think warrant discussion before I prepare a PR.
If it turns out too janky to merge, then I would be happy enough to have this as a plugin or a personal fork instead.
Potential Issues and Questions
API Lookups
We would require an additional API lookup with browse_releases for the artist id, per artist. In the case of a single artist the same as the album_artist, this is fine, however it could easily be problematic for an album involving many artists credits, and would create duplicate api lookups.
An option is to only attempt this solution for the album artist rather than the individual track artists.
Another is to have a small cache of artist release lookups in the mb module, to avoid duplicate api calls.
Wrong Alternative Name
The solution may not end up being super robust in the case of an artist credited by many names, and could end up treating what should really be a non-primary alias as a primary artist name.
An example of this is AJJ/Andrew Jackson Jihad .
I attempt to catch this case by:
ISO369-1 vs ISO369-3 Language Codes
Musicbrainz' style guide for the alias locale field, and the release language field seem to very loosely suggest use of ISO369, it seems like 369-3 is used for release languages,
while 369-1 is used for artist aliases. Beets currently handles aliases as if their locale is a two letter ISO369-1 style code, and so the language config option is usually set to match this assumption.
In my mockup I simply compare the release language with the config locale by converting both to ISO369-3 using a simple dictionary. For better handling however, perhaps a library such as pycountry could be used,
also in beets' existing handling of alias locales and the language config, though obviously another dependecy might be too much for the job...
Extra Config Option
This feature could be enabled (or disabled) by a config option, since the results can be subjectively better or worse.
Example Cases
I ran the mockup, testing against some example cases that I found with a beets query:
sh beet ls -a -f 'Artist Musicbrainz Aliases: http://musicbrainz.org/artist/$mb_albumartistid/aliases' '^language:en' 'albumartist::[^\u0000-\u007f]' '^mb_albumid::^$'Looking at the artist aliases pages, you can see what aliases they have, and the list of credited names.
I tested my solution against some instances I ran into (which I have now added English aliases to):
I've still to test this against more samples (such as everything in my library), just to see if it breaks significantly on edge cases in the musicbrainz data.