Classical Extras plugin (for Picard 1.4.x)

I have developed a Picard plugin for classical music which I hope may be of use to others. It provides tagging enhancements for artists/performers and, in particular, utilises MB’s hierarchy of works to provide work/movement tags. All options are set through a user interface in Picard options->plugins.
I have done a fair bit of testing of it, but further testing is welcome. It currently resides at where there is an extensive Readme describing the functions and interface. Please feel free to download the zip file, install it in Picard and play with it.
Depending on feedback, and after any further debugging, I will issue a pull request for it to be included as an “official” plugin.
Note that there are one or two areas where I know it could be improved; in particular, it struggles if a track is a partial recording of multiple works with multiple parents (i.e a sort of classical medley - e.g. Otherwise, provided the release is properly entered in MB, it should work.
Note also that because multiple XML lookups are required (1 per work at 1 second each), it can be a bit slow for large releases and I suggest you only tag one release at a time.
Otherwise any feedback is welcome.


I can’t wait to try it! Most of my tagging is classical and opera. This could be a huge help. Thank you.

Let me know how it goes. I’ll try and answer any questions and if there are particular issues with a release, post the release id and I’ll look into it.

New version 0.6.1 has amended regex to permit non-Latin characters in work text.

Latest version is 0.6.3 which has small enhancements & bug fixes. Please note that the plugin will not work unless you have enabled “Use release relationships” and “Use track relationships” in Picard->Options->Metadata.

Version 0.6.4 now provided at
This has better m4a and iTunes compatibility (see the readme) plus added functionality for chorus master, orchestrator and concert master (leader).
If there is a demand, I think this is nearing a point when it could offered for inclusion in the main plugins list. A bit of feedback first would be helpful, though.

1 Like

Version 0.6.5 now at
Includes ability to use multiple (concatenated) sources in tag mapping (see notes under “tag mapping” in Readme). All artist “sources” using hidden variables (prefixed _cea…) are now consistently in the plural, to distinguish from standard tags. Note that if “album” is used as a source in tag mapping, it will now be the revised name, where composer prefixing is used. To use the original name, use “release” as the source. Also various bug fixes, notably to ensure that all arrangers get picked up for use in tag mapping.
Subject to bug fixes and code tidying, this is the version to be used for a “pull request”.

1 Like

Version 0.7 released and pull request issued at

1 Like

For anyone wishing to try this plugin, the zip file can now be found at To just read about it, go to the readme at


Tried it, and the truth is that the jury is still out… there are a lot of options in the settings pages, and I just haven’t used it enough to determine whether unexpected output is caused by me or by a problem in the code.
One question I do have…Is there a way to eliminate the “descriptors” from the artist tags? I might have missed it in the settings, but I would prefer not to have contributors/artist names being followed by things like “(orchestra)” and “(conductor)”. While it may be informative, my media player (Kodi) does not like the syntax.
Here’s a screenshot with the first 13 tracks showing what I’m talking about:

Thanks in advance,

I just started experimenting a bit with this plugin.
I noticed that for id3v2 for ‘top work’, two entries are created:

Name                  Tag Code

TOP_WORK TXXX/top_work

Is that intentional?


Never mind. I know what happened.
I converted the flac album to mp3, and the converting application copied the vorbis tag, and after that Picard added the second tag field.
So the only one that gets written for idv3 is: TOP_WORK TXXX/top_work

I noticed that using this plugin, a couple of ‘movement’ tags are written:

Could somebody please point me to some explanation on usage, and differences between these three?
Just wanting to make sure that there is some sort of agreement/semi-standardization on this, so I can setup my own system to profit from all this available information.

edit 1:
Something else related to this subject:
For ‘Movement Name’, Picard writes a ‘TXXX/movement name’ frame for idv3.
But if I am correct, there already is a ‘MVNM’ frame intended for this?

edit 2:

Shouldn’t ‘MOVEMENT COUNT’ display a number of total movements?

edit 3:

These three tag frames get populated with identical content.
Is one of these preferred for this purpose, and are the others for redundancy/compatibility?
Or can there be situations where they are used differently?

1 Like

FYI, per my request MusicBee will read TXXX/MVMN into MVMN, etc. Direct support within Picard is in process but hadn’t been released yet (there’s a ticket for it but I’m not in a good position to link it right now). It spun off into a whole discussion about how to handle multi-level works, which you can find here in the forum.

I can also give you some scripts I use for handling works in Picard, which function correctly most of the time, if the work name is well formatted.

1 Like

Thanks for that psychoadept.
As you may have noticed, I also revived an old thread from vzell on the MBe forum.
I’m gonna take a break from this for a couple of days, and will be happy to ask you for some assistance when needed.
(and when I have it clear in my head what I want exactly for my clean-install)


Sorry I can’t respond properly at the moment as I am on holiday and don’t have my PC :slightly_smiling_face:
In the meantime, I think most queries can be answered by a thorough reading of the (admittedly long, but hopefully comprehensive) readme which is attached to the plugin.

Picard always supplies the sub keys for instruments etc. The plugin is designed to give different options.
There are versions of the variables with and without instruments etc. These are described in the readme, e.g. soloist_names. I remove (orchestra) in the options I use as I think it is unnecessary. IIRC the source variable you need for that is ensemble_names.
The reason there are so many options is to allow users to choose exactly what they want to appear, of which that is one example.
Once you have found the right options for you, they will be saved in picard.ini so it is a good idea to make a backup of that. Sometimes I find that slightly different options work better with some releases. If you use the option to save the options to tags (on the advanced tab), then the next version will enable those to be read and used so that each release will use its customised options if it is reloaded or refreshed.
I’ll try and provide some more specific comments once I have access to Picard again.
Hopefully I’ll release a beta of the new version shortly, which contains some significant enhancements.

Here are the links I couldn’t get earlier:

Picard ticket:

Forum thread: Levels in the structure of works

Thnx MetaTunes,

I’m sorry for interrupting your holiday.
I’ll do some more reading, and patiently await any additional input from you.
No hurries at all.

Thnx, yes, I have been following that thread with interest too.
But looking at the tickets, the discussions, and awaiting release of Picard 2.0, it is probably gonna take a while before all is set and decided on. I think I am going to stock some more patience for my project.

1 Like

I should add that probably the easiest way to read the read me is to go to

1 Like

Thanks for the reply. Not sure the readme addresses what I’m talking about but I’ll double check and post back if I can’t resolve the issue. Thanks again. I too am sorry for interrupting your holiday.