This (Musicbrainz dropping relationship data on large releases) is fixable - it is a Simple Matter of Programming Effort in order to queue and process additional requests for relationship data that is dropped by MusicBrainz webservice on these large releases. Whether it is worth the effort needed, and whether it will actually be done, is a different matter.
I’ll look into that. My head is full of PHP at the moment, so I need to press a reset button for Python 
Quite!
1 Like
Composer(s) Magnus Lindberg not found in reference database of classical composers
This is the entry:
>
> Magnus Lindberg
> Lindberg M
> 1958
>
> FIN
> false
>
Original in XML
Other composers are found.
In the ‘period’ map you can specify the dates for a period.
And it says that dates may overlap.
Could you elaborate a little bit what happens to works that have a composition date that overlaps between two different date periods?
Hi
In the first track of this release, classical extras produced below error.
- Found parent which which is descendant of child - not using to prevent circular references. id = 9b1bd955-8635-43e6-9711-f2b820ffe8b8, name = Tannhäuser und der Sängerkrieg auf Wartburg, WWV 70
I checked the work relationship of the track and I confirmed it doesn’t have the circular reference.
The classical extra seems to produce this error if a track has two different level of work relationships to the top work.
In this case, the first track has both the relation to the overture of Tannhäuser (one level down of Tannhäuser ) and Bacchanale of Tannhäuser Act I. Scene I (Three level down of Tannhäuser).
Could you check this?
Regards.
I have been running into several bugs with Classical Extras for some time. I have found a release where I can trigger them easily.
- The performer vocals credit “ビートまりお” is instead coming down as “Beat Mario”
- The performer vocals credit “大瀬良あい” is instead coming down as “あい”
- The performer vocals credit “ななひら” is instead coming down as “Nanahira”
Settings:
Could you let me know which tracks you are talking about, please.
Hi @MusikBaum. I’m not sure what the query is here. The plugin does not maintain the reference database of composers. Could you provide more context please.
Sorry for the late response @hiccup. You probably guessed that the work will get a tag for both periods (or, at least, that’s what I think should happen).
1 Like
Hi @cngcng. Sorry for delay looking into this. I suspect that the problem may be caused by the track being a recording of two works. It’s quite a complicated one, but I will try and see what is happening.
A couple of things:
- You should have Japanese selected as the locale in the options->metadata
- Leave the ‘Fix non-Latin text…’ box unchecked (as you have…)
With those settings, items 1 & 3 seem to be fixed as far as I can see. Item 2 is a bit more of a puzzle as the name seems to have the first 3 characters removed. I’ll look into that a bit more, but meanwhile please confirm that you can fix 1 and 2 with the above settings.
I suspect that the problem with 大瀬良あい may be a more general python character-handling issue. I’m afriad I am no expert on Japanese character handling, so if you have any clues, please let me know.
1 Like
Actually the 3rd case seems to be an issue in the MB databse that I can’t quite fathom, so if anyone has any ideas I would be grateful.
If you look at https://musicbrainz.org/ws/2/release/4f0dc0ce-0450-452b-8b06-b9629413ec87?inc=release-groups+media+recordings+artist-credits+artists+aliases+labels+isrcs+collections+artist-rels+release-rels+url-rels+recording-rels+work-rels+recording-level-rels+work-level-rels&fmt=json
… towards the end you will see
artist: {
id: “ff5b5a87-bafe-4a31-9a19-20bd8f2954ba”,
type-id: “b6e035f4-3ce9-331c-97df-83397230b0df”,
disambiguation: “”,
type: “Person”,
name: “大瀬良あい”,
aliases: [],
sort-name: “Ōsera, Ai”
},
name: “あい”,
joinphrase: “”
}
(my bold highlighting) but if I look at https://beta.musicbrainz.org/artist/ff5b5a87-bafe-4a31-9a19-20bd8f2954ba, I can’t find that.
Changing ‘credited over-rides alias’ to ‘alias over-rides credited-as’ seems to fix it but I don’t know if that causes problems elsewhere. Please take a look and let me know.
1 Like
#1 has no effect for all combinations I tried of “Translate artist names…” enabled/disabled, and switching between English and Japanese in that dropdown menu. (I would be concerned if it actually had an effect, because I wouldn’t want non-Japanese artists’ names to be changed into Katakana.)
This webservice result is not a problem with the database. You are referring to the artist credit used on the last track of disc 2:
This shouldn’t be a problem unless Classical Extras is assuming that every time an MB Artist appears anywhere on the release, they are credited the same way.
So, I was able to “fix” #1 and #3 by flipping this setting at the top of the Artists page:
However, it breaks Release “君とボクの1日” by ヘスティア(CV:水瀬いのり) - MusicBrainz and causes the composer to come down as “草野華余子” instead of " カヨコ".
This works for me:
That may well be the case 
Did you try this?
Hi @yindesu. I’m afraid that the plugin uses credited-as names consistently throughout if you specify that they should over-ride. I can think about alternative approaches, but I suspect there are complications. Also, once loaded, they are stored and are unaffected by options changes, so you may need to restart Picard to have the desired effect.
As you correctly identified, the problem #3 is caused by the credited-as name on the last track. If you uncheck the last item in the ‘names to use’ options (‘and/or track artists’), that will prevent the truncation, but obviously will leave the full name in the track artist for the last track.
I didn’t really contemplate having ‘feat. …’ in track artists as the plugin was designed for classical releases where track artist is usually the composer. Normally it works fine for non-classical releases too, but you have managed to find a slight anomaly 
Don’t forget that you can use different settings to tag different releases and then save those settings as a tag so that next time it will use the saved settings, not the ones displayed - see the advanced tab.
I suggest you group releases and tag separately if you want to use different locales.
1 Like
Looking into this, the problem arises because the track is a recording of two parts which are at different levels in the hierarchy of parts. So when the paths are followed up the hierarchy one ‘leg’ reaches the top before the other. This confuses my plugin (and me) which thinks it has a circular reference.
This is not a simple fix and hopefully quite a rare occurrence. I think I knew at the time that this situation might cause problems, but put off dealing with because I didn’t know the answer.
At the heart of this is the need to decide how the results should be interpreted. In the simple case where a track is a recording of two adjacent movements (say), then the common parent is shown as the work. But what should the work be if the parents are asymmetric as here? Do we show both parents (messy, especially as this might continue for more levels) or (say) just the highest one? Answering this question would help in determining what is the appropriate programmatical solution.
2 Likes
Yes, that’s indeed the case.
1 Like