Classical Extras plugin (for Picard 1.4.x)

0.8.1

Could it also be some setting in Picard that messes this up for me?

You haven’t ticked “include all work levels” (which should be ticked by default). Without that, this part will not run. :sweat_smile:

Thanks, now it is working indeed.
I guess I didn’t check, since the ‘work’ tag was being populated with the required full canonicle title, so ‘the engine’ seemed to be working to me.

So the intention of that checkbox is to disable everything on that page, and everything related to writing ‘work’ and ‘parts’.?
That’s not completely obvious from an ‘interface point of view’.
Maybe as a visual indicator of that, the whole page could be 'greyed out, including disabling making it possible to make adjustments to all those settings?

And as I said, the ‘work’ tag was written with that checkbox unticked.
Shouldn’t all writing of ‘work’ and ‘parts’ have been disabled then?

I’ll make the checkbox clearer in the next version. The lowest level work will still be populated by Picard and written to the “work” tag, even if the plugin does not run this section (or, indeed, if it is not run at all).

Just for semantics sake and good understanding of ‘levels’ in this context:
When you say ‘the lowest level work’, in this case it is actually from the lowest level up to and including the highest level, right? Not only the ‘lowest level’.
(E.g. the highest level being ‘Die Walkure’, the lowest “Scene 1 - ‘Hojotoho! Hojotoho! Heiaha! Heiaha!’”)

The “lowest” level work name is no more or less than the text used to describe the work at the lowest level in the hierarchy in MusicBrainz.
Thus for Track 2 of https://musicbrainz.org/release/ec519fde-94ee-4812-9717-659d91be11d4?tport=8001, the lowest level (0) is that described as “recording of”, i.e. https://musicbrainz.org/work/8e830042-faee-3930-98ea-29f69f4b0f64
This is ‘part of’ https://musicbrainz.org/work/f04b42df-7251-4d86-a5ee-67cfa49580d1 - that is level 1
which is part of https://musicbrainz.org/work/45afb3b2-18ac-4187-bc72-beb1b1c194ba (level 2)
Often the level 0 text includes the full work name, but not always, hence the choices in the options.

1 Like

Thanks, that’s what I thought. (however sometimes I mistakenly imagine it the other way around)
Is there some agreed naming within MusicBrainz for the full title of all levels combined?

I have been calling it ‘full canonical title’, but if that’s incorrect/confusing, I’ll erase it from my vocabulary to avoid further possible misunderstandings.
That’s the one I was interested to get written to ‘title’.
If I understood your explanation correct, even for you it’s not so simple to retrieve that as one ‘string’ from MusicBrainz?
You’ll have to retrieve separate levels, and then concatenate them yourself to get some result?

Not AFAIK. The lowest level work usually (but not always) contains text describing the higher levels. You don’t need my plugin to get this - ‘plain’ Picard calls it “Work”. The style guidelines for works doesn’t seem to say much about how to word them.
What Picard doesn’t give you is the work structure above that - that was the original purpose of the plugin, but it has somewhat expanded from that.
By concatenating the hierarchy, which Classical Extras extracts, you do get the full description (but possibly with some repetition).
Personally, I tend to leave the Title unchanged, but that’s because I can import and display a multi-level hierarchy in Muso. The Title is then just used on the remote players. See screenshots at http://music.highmossergate.co.uk/screenshots.php. If the MB guidelines for titles has been followed (Style / Classical / Track Title - MusicBrainz) this should be pretty meaningful.

Just f.y.i. and to give some insight in my motivations, I am trying to decide on some definitive (yeah, don’t laugh) scheme for the music player/manager I am using.
I am trying out a new scheme, where the full classical title (containing all levels) is essential as a starting point.
When unleashing several rules/formulas/regex on those titles, pretty much anything is possible in respect to displaying/filtering etc.
And if I can get that to work to full satisfaction (I’m at some 90% now), it will prevent the need to maintain and populate additional tag frames for the different levels, since that required info is already present in the title, and the formulas will dissect those perfectly.
Of course additionally I will be needing tag frames for composers, performers, dates, box-sets, etc. etc.

So I’ll probably end up not using your ‘work/levels page’ a lot, but the remaining features will probably be very valuable.

In the ‘help’ tab of the plugin, under “Use canonical work metadata enhanced with title text”, the explaining text is cut-off right after “This is clearly”
(at github I can see what should be there)

For anyone wishing to use this plugin, can I please suggest you read the readme at picard-plugins/plugins/classical_extras/Readme.md at 1.0 · MetaTunes/picard-plugins · GitHub first. This will give you an understanding of what it is trying to do and help you achieve what you want. In particular, read the “important” notes in the Usage Section, including this one:

Important:
The plugin will not work fully unless you have enabled “Use release relationships” and “Use track relationships” in Picard->Options->Metadata.

1 Like

A new version of Classical Extras is now available. This incorporates a significant number of enhancements and will be the last beta version before the next full release.
Enhancements include

  • Ability to use aliases of work names instead of the MusicBrainz standard names.
  • Various options to use aliases and as-credited names for performers and work-artists (i.e. work relationship artists).
  • Option to use recording artists as well as (or instead of) track artists.
  • All work relationship artists are now tagged for all work levels (with some special processing for lyricists).
  • New UI layout to separate tag mapping from artist options.
  • Option to split lyrics into common (release) and unique (track) components.

There has also been a good deal of code-tidying and bug fixing, so I hope it is reasonably robust. You can download the zip file for installation here: https://github.com/MetaTunes/picard-plugins/releases/tag/v0.8.4
Please read the readme at https://github.com/MetaTunes/picard-plugins/blob/1.0/plugins/classical_extras/Readme.md before use and in case of difficulty, but otherwise post any issues in this discussion.

2 Likes

It looks like this version doesn’t populate the ‘composer’ tag, only the ‘composer sort order’ tag.
Is that intentional?

No! Looks like a line of code got erased. Temporary work-round is to add a tag mapping from “composers” to “composer”. This will use the hidden variable which is still being written. I’ll issue a bug fix version shortly.

Bug fix version is now at https://github.com/MetaTunes/picard-plugins/releases/tag/v0.8.5

I noticed that ‘performer_sort’ is being written even when ‘Also populate sort tags if a sort tag exists for the source’ is unchecked.
Not a big issue, just mentioning it.

edit:
I just noticed that for band_sort, arranger_sort and conductor_sort also.

Thanks. I’ll look into it.

Your plugin can set the ‘show movement’ switch.
For flac it writes two different tag frames: ‘show work movement’ and 'showmovement’
But for mp3 it only writes ‘show work movement’.

My player/manager uses ‘showmovement’.
So currently for mp3 that switch doesn’t work using your plugin.

Could you add it to id3v2 too?

edit:
Hm, I would swear it wrote ‘showmovement’ for flac earlier, but I am now doubting very much if that is actually true.

It now looks like it doesn’t, so in that case my request would be simply to have the option to write ‘showmovement’ instead of ‘show work movement’.

Actually the plugin was writing these regardless of any tag mappings. This could easily be removed. This would have the following effect:
Any tag mappings which use sources with associated sorts (which is all of the hidden artist variables) will still create a sort tag if the option is checked. So band_sort would be written if ensemble_names is written to band. Otherwise (if there is no tag mapping action) only tags for which Picard natively writes sort tags (e.g. composersort) will get sort tags from the plugin. But conductor_sort (for example) could still be provided if conductors_sort is mapped to conductor_sort.

Thanks for the fast reply and explanation.
I’m not sure I understand the above quote. Do you mean you could change something in the code, but you are asking my opinion on it?
I’m still just getting my feet wet with all this, so I am not sure I could well oversee repercussions for other use(r)s.
But at this moment I would prefer it to be removed. (understanding how ‘mapping’ can affect it, as you explained)

I’m beginning to have some fun with all this :wink:
It’s an impressive piece of work.

Is there an option to save the current settings of the plugin?
It would make it easier to return to a setting that worked well, before messing it up with experimenting.
And it would make it possible to ex/import the settings to another installation of Picard…