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).
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.
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
sort-name: “Ōsera, Ai”
(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 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.
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.
Yes, that’s indeed the case.
Just installed and tried to use this pluging, but I find the choice of background colours makes it unusable.
e.g. on the artist tab with a pale yellow background and white text? I see nothing.
The plugin doesn’t support dark UI. Changing this depends on the system being used, but on Mac and Windows you can change Picard to a light UI in the user interface options.
I am aware of this, thanks. Hopefully @P-Crow , the suggested solution works for you. It is on my to-do list to do a ‘dark’ version, but I’m afraid its in quite a long queue.
Once in a while I am getting genres that I believe are incorrect, but when checking MusicBrainz’ database, I can not find them present anywhere.
Neither tagged to the release, the recording, the work nor the artist.
So I am then also not able to make possible corrections for it.
After some specific tests, I found that this happens only when under ‘Genres etc.’, both ‘Folksonomy work tags’ and ‘Infer from artist metadata’ are checked.
Using only one or the other doesn’t result in this ‘problem’.
I would like to understand what is happening here, so I will know where to look to make possible adjustments.
Here is a specific example:
The first 16 tracks all get tagged with ‘Chamber music’, but only with the settings mentioned above.
And as I said, I am not able to find any entity related to these tracks that are tagged ‘Chamber music’.
Can somebody clear this up for me?
Hm, I’m not sure anymore about the combination of ‘checks’ that triggers this.
it also happens when only ‘Infer from artist metadata’ is checked.
That release also gets ‘Chamber music’ in that case, which I am not able to find in the database.
So where does CE get it from?
It looks like it could be related to: Advanced > Groups somehow?
When that field is blank, ‘Chamber music’ gets created by CE.
Strangely enough, when (as a vague gut-feeling) I removed only ‘Chamber’ from that pre-populated field and left all the other entries there, the ‘error’ still occurs, and CE will still create ‘Chamber music’ as a tag.
(probably same as I was before)