It works fine for me. Are you over-riding the plugin options with saved options (last section of advanced tab)?
You’re fast 
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?)
1 Like
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:
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).
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.
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
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_ 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
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).
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?
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
Hallelujah!
Thanks for helping a cripple crossing the street!
You explained that you chose to have the composed year added.
Is that perhaps avoidable by some advanced setting?
Periods and dates at the bottom of the genres tab 
Full details are in the readme.
2 Likes
[insert embarrassed smiley here]
Just in case you are interested in what your plugin helped me to accomplish in regard to making it work for MusicBee, look here:
https://getmusicbee.com/forum/index.php?topic=28999.msg161506#msg161506
Thanks again.
On my system, this release is problematic:
Picard will get stuck after the count-down at the right bottom reaches ‘1’.
F.w.i.w.:
I just tried again with disabling ‘use cache’, and then it will get stuck not at ‘1’, but at repetitive alternating between ‘2’ and ‘3’.
The problem (if there is only one) is with Track 5. You will see that it is said to be 2 recordings, but the second recording is “part of” the first. This is causing an infinite loop. The plugin should detect and pass over errors of this type (and give you a warning), but for some reason it is not catching this one. Obviously the MB entry needs fixing (presumably the first recording relationship should be removed?), after which the plugin should work. But before fixing it I’d like to see why its not catching this one.
EDIT And track 7
1 Like
Fix is in current development version obtainable at https://github.com/MetaTunes/picard-plugins/releases/tag/2.0.5
However, because of the circular references, the plugin has to choose which recording to use and typically picks the first one. In this case, I think the second one is correct for both tracks 5 and 7, so the best thing is to fix the MB data. At least Picard should run now. Please test it before fixing the data and let me know if any problems.
1 Like