Difficulties with work artist aliases

MusicBrainz Development
, ,
1

As I mentioned a few days ago, I’m rebasing a project on python-musicbrainzngs. In the old code, I would do one API call per track. As I dug into the API, it was looking like I could get away with a lot less. In fact, for a long time, it would looking like I could get all the metadata I wanted to tag an entire release with just a single API call. Then I hit a snag. I decided to add a new feature to the code: look for primary artist aliases for a given locale. No more translating from Cyrillic to Latin by hand. I would need this for release ACs, track ACs, recording ARs, and work ARs. After playing around with the includes, I wound up with this:

incs = ['artists', 'artist-credits', 'artist-rels', 'recordings', 'recording-level-rels',
        'work-rels', 'work-level-rels', 'release-groups', 'labels', 'aliases']
releaseid = '0aadac63-79e4-4374-8757-a36f887a8121'
result = musicbrainzngs.get_release_by_id(releaseid, includes=incs)

Which got me aliases for everything but the work ARs - those dang Russian composers! So, I fell back to one API call per work. Most recordings have only one work, so it wouldn’t be much worse than where I started. That led me to this:

incs = ['artist-rels', 'work-rels', 'aliases']
workid = '36dfecf2-b58c-3997-a629-3b34979791ae'
result = musicbrainzngs.get_work_by_id(workid, includes=incs)['work']

I was very surprised to find this still didn’t give me the aliases for the artists in the artist-relation-list. Calling the API for each work-artist AR is a deal breaker. Is there something I’m doing wrong? I haven’t had to make a per-artist API call for any of the other artist relations.

Thanks.

2

I don’t think you are doing anything wrong. My Picard plugin “Classical Extras” has the same issue using the web xml service. Aliases are only returned for track artists, not relationships. You can, however use the “as credited” information

3

Which doesn’t really help their case, since in most cases the composer-level relationships should be credited to the original (Cyrillic) name…

4

Composers should be track artists so the alias will be available.

5

Composers should be track artists so the alias will be available.

Sometimes, yes. That doesn’t help much with getting names for librettists/lyricists or composers for non-classical works. Even when the track AC is the composer, I’d have to bend over backwards to pull an alias from a completely different area of the metadata.

I’ll have to double-check, but I thought I was getting aliases for recording ARs. It’s possible I confused them with recording ACs. If those aliases are not coming through, I suppose I’ll also have issues with Evgeny Kissin, Vladimir Horowitz, and the like. Yes, the credit and sortname are probably English, but I’m trying to support any locale.

You can, however use the “as credited” information

I was trying to support any user-selectable locale.

6

Earlier today, I had thoughts to:

  1. Before doing anything else, run through and collect the aliases I do have from ACs into a dictionary keyed by artist ID.

  2. Due to the rate limit, I can’t fetch all artists missing aliases, especially those already in Latin script - the performance would be terrible. So, only fetch those artists for which I don’t already have aliases and which don’t match the chosen locale.

Completely overlooked the fact that artists don’t have a locale attribute, nor anything else I could use to check for non-Latin scripts. I suppose I could examine the string for characters outside the Latin Unicode blocks, but this is feeling silly.

Picard itself seems to translate composer names, yet it doesn’t seem to bog down collecting this information. Scanning through the source, I don’t see how it’s getting around this. It seems to only make an API call for the release (or recording if a standalone recording). Unless musicbrainzngs is leaving data out, I don’t understand.

7

Holy cow! I took my release query and translated it into a web service URL that I put directly into Firefox. If I use the default XML format (1), I get no aliases for the work relation artists. If I request JSON format (2), I do get aliases for the work relation artists. I wonder if this is by design or a bug.

(1) https://musicbrainz.org/ws/2/release/0aadac63-79e4-4374-8757-a36f887a8121?inc=artists+artist-credits+artist-rels+recordings+recording-level-rels+work-rels+work-level-rels+release-groups+labels+aliases
(2) https://musicbrainz.org/ws/2/release/0aadac63-79e4-4374-8757-a36f887a8121?inc=artists+artist-credits+artist-rels+recordings+recording-level-rels+work-rels+work-level-rels+release-groups+labels+aliases&fmt=json

1 Like
8

Well I never…!:star_struck:
I wonder whether it would be a simple thing to fix the XML format? I’m not sure how to get the json format in my plugin as I am dependent on Picard, which gets the XML and turns it into the internal XMLNode object (which, ironically, looks very much like json) :disappointed:
BTW, I think Picard only translates composer names when they are the track artist. If no alias is available, then the sort name is used. My plugin adopts a similar strategy if there is no alias - detects cyrillic script (using the “silly” method) then uses the sort name. But obviously this does not use the locale. If there are aliases, then it selects the primary alias for the chosen locale.

9

I’d love to see that happen, as to use “beta” JSON format with the python bindings, I have to ignore a warning they generate.

Hmm. I’m not sure that’s true. When I tagged the release above with Picard, for track 4, I got a translated name (not sort name) for work orchestrators Rimsky-Korsakov and Glazunov, while the track artist is Borodin.

10

I think you will have got this in the arranger tag:

Nikolai Andreyevich Rimsky-Korsakov; Alexander Konstantinovich Glazunov

Picard takes the sort names and “unsorts” them. This is not the standard translation. Also, if you select (say) Dutch rather than English, you get exactly the same result, even though the Dutch version of Glazunov is “Aleksandr Glazoenov”.

If you use the “Classical Extras” plugin with Dutch as the locale, you will get the following in the arranger field:

Alexander Glazunov (orch.); Nikolaj Rimski-Korsakov (orch.); Alexander Glazunov (arr.); Nikolaj Rimski-Korsakov (arr.)

(Note that the annotations are optional)
If you look at this closely, you will see that Glazunov has the English spelling - I derive it from the sort name (in the absence of an alias) as per vanilla Picard, but remove the patronym to comply with standard English usage. On the other hand, you will see that “Nikolaj Rimski-Korsakov” is the Dutch spelling, i.e. from the alias, even though he is not the track artist. This is because he is the track artist on another track and I cache all the aliases. The composer is “Aleksandr Borodin” (the Dutch version) whether or not the plugin is used, as he is the track artist.

11

I see. Thanks for the explanation.

12

FWIW, Picard 2.0 uses the JSON format and so picks up the relationship artist aliases. Well, that’s the theory - however, it doesn’t seem to work fully as not all the aliases get populated - see JSON webservice relationships returned