Bug with abbreviate_artistsort plugin and some non-ASCII artist names (e.g. Eötvös Péter)

picardplugins
abbreviations
Tags: #<Tag:0x00007f30957612a0> #<Tag:0x00007f3095761110>

#1

There’s a bug in the abbreviate_artistsort plugin, where the artist’s surname seems to be empty in some cases. I suppose it has to do with non-ASCII characters appearing in artist names, or with Unicode / UTF incompatibilities.

I’m running Picard 2.0.4 on OSX High Sierra.

D: 12:32:58,303 /Users/xxx/Library/Preferences/MusicBrainz/Picard/plugins/abbreviate_artistsort.zip/abbreviate_artistsort.abbreviate_artistsort:183: Abbreviate artist-sort: Track 4: Unable to abbreviate surname (Eötvös) - forename (Eötvös Péter, György Ligeti; Patricia Kopatchinskaja, Frankfurt Radio Symphony Orchestra, Ensemble Modern,) not matched in unsorted albumartist: ‘E’.

E: 12:32:58,312 album.error_append:200: Traceback (most recent call last):

File "picard/album.py", line 327, in _finalize_loading_track

File "picard/metadata.py", line 371, in run_track_metadata_processors

File "picard/plugin.py", line 510, in run

File "/Users/xxx/Library/Preferences/MusicBrainz/Picard/plugins/abbreviate_artistsort.zip/abbreviate_artistsort.py", line 144, in abbreviate_artistsort

while surname.split(None, 1)[0] == unsort.split(None, 1)[0]:

IndexError: list index out of range

Is there a way to fix this?


#2

This does not seem to be related to non-ascii characters, rather the way the sort name is constructed does confuse the plugin. I can reproduce this only if “Use standardized artist names” is active, then e.g. with:

The album artist credits for this release is:

Róbert Wittinger; Südfunk-Chor Stuttgart, Stuttgart Radio Symphony Orchestra, Eötvös Péter

Here its is strange why it is listed as

The sort name in Picard ends up to be:

Wittinger, Róbert; Südfunk-Chor Stuttgart, Stuttgart Radio Symphony Orchestra, Eötvös, Péter

This is already not quite correct, but I guess it’s hard for the software to see what the names are and what not. I am also not sure about how comma and semicolon are used in the credits.

Anyway, the last part, “Eötvös Péter” vs. “Eötvös, Péter” confuses the plugin. If you switch either, i.e. either “Péter Eötvös” for the normal credits or "“Péter, Eötvös” for the sorted credits, it works. Looks like the plugin doesn’t like it if the same name has the same order in both sorted und unsorted way.

Edit: Even the simple case of artist credits only “Eötvös Péter” and sortname being the same order with “Eötvös, Péter” triggers the issue.


#3

I forgot to mention that I indeed use standardized artist names. Otherwise it’s very confusing to find the proper artist credits, unless you like disjoint sets of synonyms.

Here’s the release yielding the problem:


#4

By the way, I suppose the problem could originate from the proper name ordering in Hungarian: Last name First name. See e.g. https://en.wikipedia.org/wiki/Péter_Eötvös

So the standardized name for a Hungarian artist is Doe John where in English it would be John Doe.

I added an alias for the English locale in Edit #55808541 - Add artist alias and now the problem is solved.

Probably this should also be checked in other artists with a primary locale that differs from English.


#5

That’s an interesting one. I think that the alias is the correct solution. BTW, if you use the Classical Extras plugin, you would need to select “Use alias for all work artists/performers” and “alias over-rides credited-as” on the Artists tab.
Perhaps an alternative / additional solution is to add a “credited as” name for the conductor recording relationship, and also on the release artist credits, since Peter Eötvös is the credit on the album cover.


#6

Likewise I am intrigued. Should I constitute the ZIP file on my own from the plugin sources on Git, or is there a zip file ready for download?


#7

You don’t need to create a ZIP file (although you can). But placing all the files at https://github.com/MetaTunes/picard-plugins/tree/metabrainz/2.0/plugins/classical_extras in a folder “classical_extras” inside your plugin ZIP folder.

@MetaTunes Any chance you will submit the 2.0 version of your popular plugin to the official picard-plugin repository?


#8

Quick reply - no time - more later. There is a zip file release on my GitHub site.


#9

@shutterfreak - here’s the link: https://github.com/MetaTunes/picard-plugins/releases/tag/2.0.1
@outsidecontext - I will submit the plugin to the repository in the not-too-distant future. TBH, the reason I have withheld it so far is the poor experiences I had with the repository for the v1 releases. Firstly, I was getting spurious errors when issuing PRs, then it took ages for the repository to be updated, so I resorted to just pointing users to my own GitHub. Since I haven’t had any bug reports for the latest v1 (0.9.3) or v2 (2.0.1) releases, I will now endeavour to do the necessary code clean-ups and submit PRs for them.