Will do, but it might have to wait until the weekend, I’m aftraid.
Thanks for the effort!
Will do, but it might have to wait until the weekend, I’m aftraid.
Thanks for the effort!
Hi @MetaTunes, it works perfectly now. Quite fast and without a glitch. Thanks!
Good! The fix has actually made it a bit faster. Be aware that there is a slight effect on the tags given to some releases, which I will address, along with a few other minor improvements, before releasing the next official version.
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.
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.
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:
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.
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.
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. It is greatly appreciated.
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.
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.
It works fine for me. Are you over-riding the plugin options with saved options (last section of advanced tab)?
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.
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).
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?)
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?
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:
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:
Il cimento dell’armonia e dell’inventione, op. 8; Le quattro stagioni
Concerto no. 2 in G minor, RV 315
III. Presto (Tempo impetuoso d’estate)
III. Cour d’Amours
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.
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).
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?
They contain what is in the MB database, which is usually “workname: movement” at the bottom level. _cwp_part_[x] 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_[x].
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_[x]. 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.