Classical Extras 2.0

MusicBrainz Picard
, ,
44

The latest version - intended for official release (subject to any last minute bugs and PR checks) is now available here: https://github.com/MetaTunes/picard-plugins/releases/tag/2.0.4

I have added an option to attempt to get works and movement info from title if there are no work relationships (requires title in form “work: movement”). If Muso-specific genre processing is selected (or XML reference file is provided including classical composers) and there is no composer (because of a lack of work relationship) then the plugin will check the listed artist against the reference list of classical composers and, if there is a match, will populate the composer metadata and set the genre to classical.

3 Likes
45

Heya. I’m new here and have a lot of Classical music to tag. Also, some video game music played by orchestras to tag. For example, one such album is Smashing…Live!.

Now, I find myself in the camp of wanting to place the performer as the artist. In the above album’s case, it would be “New Japan Philharmonic”. My head is still swimming with the sheer quantity of options available in Classical Extras, as well as exactly what each of them does. I think the option I want is “Use recording artists to update track artists”. However, when I select that option, nothing really changes. The artists are still all set to the composers.

If this isn’t the right place for me to ask what I’m doing wrong, then please point me in the right direction? Thank you.

46

Much of this complexity comes because of the complexity (aka richness?) of the MB database, which the plugin exposes rather than hides. There are pros & cons - but I decided to let the user make the choices rather than dictate.

I have tried to document this fully in the readme file which is included in the zip file and also available here (for the released version) or here (for the next release referred to in a post above above). If you have specific questions after reading that, I’ll try and answer them.

Re your specific issue posted, your understanding of:

is correct. For the release you mention, however, the recording artist seems to be the same as the track artist for each track, so this option will have no effect. You would need to edit the recordings and set the recording artists to be the conductor and orchestra (per style guidelines) for there to be a difference.

Also, I note that the release is just credited to “various artists”. Amending that to include the conductor and orchestra (who are the same for all tracks, I think) should also solve your problem.

Without editing the database, the quickest fix for your problem is just to set a relationship in the tag mapping section of the plugin. Just select the tag you want to use - e.g. performer_sort - as a source and map it to the artist tag. (I recommend the “View Script Variables” plugin to see the full list of potential sources, including all the hidden variables generated from Classical Extras).
The default tag mapping options for artist are:

Tag%20mapping%20part
Tag%20mapping%20part1140×198 35.8 KB

so, if you don’t fix the recording artists to be the performers, or the release to include them, that is why the composer is in the artist field. If you fix the release details, then the first line will have sources and take precedence.

I think my preference would be to fix the release artists so you don’t have to change the plugin options for this release. I think that would conform to style guidelines as the orchestra is credited on the cover. Otherwise, I would fix the recording artists using @loujin’s browser script . Messing with the options would be the fall-back.

So, as I said, the complexity is in the MB database. Generally, if style guidelines have been followed fully (which in this case they have not), the default plugin options for artist should work. For the release in question, there may be some issues with Japanese script, so let me know if this is a problem, after following the recommendations.

3 Likes
47

PS Since the credits on the cover seem to be in English, I recommend setting aliases for the performers in MB before using the script to update the recording artists.
PPS If you are not a MusicBrainz editor, then I recommend becoming one since you have a lot of classical music to tag and you will inevitably find errors and omissions in the database.

4 Likes
48

Hey, @MetaTunes, thank you so much for clarifying things for me. It took me a while to grok it all, especially the difference between “Recording Artist” and “Track Artist,” but I think I’ve got it now.

I’ve submitted edits to MB about this release and hoping that I’ve done so correctly; I’m still a newb at editing and even more so when it comes to Classical music. Honestly, I’m not entirely sure I’ll edit the MB releases in the future while ripping my Classical CDs as it is quite a bit of work.

Anyway, thanks again for being kind and taking the time to explain things for me. :blush: It is greatly appreciated. :pray:t2:

2 Likes
49

I think those edits are correct, so I’ve voted for them. However, it doesn’t look like you added the aliases and then used @loujin’s browser script as I suggested. That script makes edits like this a breeze (although you still need to wait for the voting before they take effect). Let’s see how it works through.
Re the general point of editing classical releases, I agree it can be a bit time consuming sometimes, but there are a lot of short cuts (see The Classical Editor’s Toolbox) and there are people on this forum who can help. If you have a lot of releases to tag then you may choose to accept less than top-quality metadata first time around, then fix it later when you get time and where the pay-off is worth the effort. Re-submitting MusicBrainz-tagged releases to Picard is easy and, if you saved the Classical Extras tagging options (in the advanced tab) the first time around, it will apply the same options next time, even if you changed them in the panels.

2 Likes
50

Please don’t invest any time in this in case it is not an obvious bug, because it’s quite likely that it is just a result of my tweaking and experimenting with 2.0.4, or perhaps some setting I did elsewhere in Picard.

Whether I set ‘Use only metadata from canonical works’ or ‘Use canonical work metadata enhanced with title text’, the result is always the same. (I believe it always outputs ‘enhanced with title text’)
I tried several releases, including the Respighi BBC release you have used as an example for this.

It’s not bugging me in any way, but I thought to report it in case that it is an actual bug.

51

It works fine for me. Are you over-riding the plugin options with saved options (last section of advanced tab)?

52

You’re fast :wink:

Don’t worry about it. I already suspected it was probably just something I have messed up somewhere. (it’s not the ‘over-ride options’ though)
It’s not important for me to investigate further or have you wasting time on it.
The output it gives is perfectly satisfactory.

Thanks for this release b.t.w, working great.

53

Yeah, as I said, I’m quite the newb here. I did install the browser script, but only after I had already manually submitted edits for each track. You mention adding aliases, but all of the composers seemed to have an English alias already except for the first one, to which I made an edit to correct that.

I also am unsure as to whether or not that script would have even helped in this case and I didn’t want to submit edits without knowing for certain if they were the correct edits. I’m sure I’m just missing something, as I don’t really see how adding any other aliases to the composers would have helped the script to automate what I did manually. If I understand it, the script sets the “recording artist” to the “performer,” but “performer” was not set for any of those tracks (except one–and even then, it was set to the composer’s name).

54

Ah - the first was the only one I looked at in detail. I added “English” and “primary” to the alias “Hajime Hirasawa” - that means that Classical Extras will pick it up (if you have set English as the locale in Picard). This was applied automatically. Then I spotted your edit, which also changed the sort name, so is subject to voting, which is why it hadn’t been applied yet. Confusing!! I’ve now voted for your edit - I hope MB doesn’t trip itself up!

The “performers” are those (with performer-type attributes) listed underneath the track title on the overview, not those listed as “artist” next to it. (Maybe a simple pictorial guide to MB terminology would be helpful?)

1 Like
55

@metatunes,

I am still/again struggling with classical works that contain several levels.
(I am aiming to populate separate tags for each level)
But for the releases I have used for testing, I get confusing and inconsistent results.

Could you perhaps recommend one or two releases that you are sure of that have more than two levels and have a perfect entry in MusicBrainz in this regard?

56

Anything with Vivaldi’s 4 seasons on is a good test (it’s doubly complicated in having 2 separate parent works). E.g. this one When imported into Muso, it looks like this:

4
4831×831 100 KB

I’m not sure if or how you can replicate that multi-level appearance in MusicBee, but the tags should all be available. Note that the two-level tagging uses a double colon to separate 2 levels in a single tag, or you can use the hidden variables. (I assume you use the “View script variables” plugin to view the hidden variables.) If it still doesn’t work, I’d need to look at your option settings.
The Brandenburg concertos are also a good test. E.g. this release. (BTW I’ve found that the new movementnumber tag can get out of sequence on this one - I’m still investigating).

57

Thanks again.
Yes, I use ‘View script variables’, and I am also aware of the double colons.
But I also recently read your initial postings that triggered you to create your plugin.
You then spoke about ‘at least 8 levels’, and somebody from MB replying something like “that should already be infinite”.

I think I am looking to be able to populate tags for all isolated levels that a recording may contain.
So something like this:

level_0
Il cimento dell’armonia e dell’inventione, op. 8; Le quattro stagioni

level_1
Concerto no. 2 in G minor, RV 315

level_2
III. Presto (Tempo impetuoso d’estate)

.

Or:
level_0
Trionfi

level_1
Carmina Burana

level_2
III. Cour d’Amours

level_3
Stetit puella

.

I haven’t been able to create a scheme yet that will produce something like this consistently for at least a fair percentage of classical releases.
But that’s probably mostly due to a lack of understanding and learning MusicBrainz and Picard on my side.
Or, I am on a completely wrong path in trying to understand ‘levels’ and what you can do with them.
I really need to dive in and focus on this matter anytime soon. This has been confusing me for far too long now.

58

The plugin gives the following hidden variables:
_cwp_work_0: Concerto in G minor, op. 8 no. 2, RV 315 “L’estate”: III. Presto (1723)
_cwp_work_1: Concerto in G minor, op. 8 no. 2, RV 315 “L’estate” (1723)
_cwp_work_2: Il cimento dell’armonia e dell’inventione, op. 8; Le quattro stagioni
_cwp_part_0: III. Presto
_cwp_part_1: Concerto in G minor, … no. 2, RV 315 “L’estate” (1723)

so the ordering is inverted from yours and you would need:
level_0 <=> _cwp_work_2
level_1 <=> _cwp_part_1
level_2 <=> _cwp_part_0

Note that the “…” in _cwp_part_1 is because my options eliminate duplicate text and the “1723” is because I chose to add composed year in my options. Other differences are because the MB work names differ from those you quote.

More generally, if there are n part levels, then:
level_0 <=> _cwp_work_[n]
level_1 <=> _cwp_part_[n-1]
…
level_[n] <=> _cwp_part_0

The work tags section will combine the tags into just two tags: a work/grouping tag with a double colon if there are 2 levels and a movement/part tag, but maybe in MusicBee you can construct your own from the hidden variables even if n is not fixed.

Carmina Burana is a good test as well, with 3 work levels. My (2) copies of this only have Carmina Burana on the album. In these circumstances, the plugin assumes that the album name can substitute for the top level work name (Trionfi) and omits it from the work/grouping tag (arguably wrongly in this case - maybe that should be another option!). The hidden variables are all present as described.

There are complications when only some parts have sub-parts - e.g. Haydn: The Creation. If you load this into Picard with the CE plugin, you will see that _cwp_work_part_levels = 3 but that for all but the last 2 tracks, _cwp_part_levels = 2. The former tells you the max number of part levels in this overall work, whereas the latter tells you the number of levels in the current “branch”. The plugin will create the double-level work tag only where required, but will use the max number of levels in deciding whether to let the album “stand in for” the top level - which in this case it does. Again these heuristics are solely designed to optimise the display. If you don’t like them, and MusicBee can handle the multiple variable tags, you can construct your own scheme from the hidden variables, which are always true to the description given above.

Sorry for the slightly long answer, but you can see I did a lot of head-scratching to come up with the method - trying to give a ready-made set of tags but also to allow the building blocks to be there for others to do things differently. I hope the above explains my thinking (for the benefit of others as well).

1 Like
59

I for sure need to digest all this info a bit better, but what strikes me as some inconsistency looking at your ‘four seasons’ example above is that:

_cwp_work_2 contains the top level only,
_cwp_work_1 contains the middle level only,
_cwp_work_0 contains the two lowest levels combined.

Wouldn’t it be more logical to have _cwp_work_0 exclusively contain the lowest, ehh highest, sh*t, last level?

And, if I am correct, the top-level work is provided by _cwp_work_top
So also having it in _cwp_work_n(highest number) is kind of duplicate? Will they always output the same value?

60

They contain what is in the MB database, which is usually “workname: movement” at the bottom level. _cwp_part_ is the unique text for the level x (other than the highest, obviously), which is why I use that for the lower levels, not _cwp_work_.

Yes. _cwp_work_top is there so that the user (or user system) does not have to work out which is the highest _cwp_work_. Typically it is used to catalogue your library by work, using the canonical MB name so that different work names on releases get grouped together.

1 Like
61

This is a bug which occurs if a work is split over more than one disc. The fix will be in the next release (which will be a while yet unless this is a problem for someone).

63

I was hoping to be able to retrieve the name of the second level of a multi-level work. (the one right after _cwp_work_top)

E.g. taking these two releases as an example:


those would be the names in blue highlight:

For the first release it could be retrieved from cwp_work_1, for the second release it could be retrieved from cwp_work_2
I should then probably use the value in cwp_work_part_levels to set a mapping to point at the correct cwp_work_n tag.

But while the first release has 0,1, and 2 populated, and the second one 0,1,2, and 3, for both cwp_work_part_levels says 3.
Shouldn’t it say 4 for the second release?

64

Hi @hiccup. As per my earlier post:

This is the case with your first release - there are other parts with more levels. So _cwp_part_levels is 2 and _cwp_work_part_levels is 3. You need to get _cwp_work_[_cwp_part_levels - 1].

No. 3 is correct. In this case, _cwp_part_levels = _cwp_work_part_levels = 3. Again, you want _cwp_work_[_cwp_part_levels - 1].

1 Like