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
TOP_WORK TXXX/top_work
Is that intentional?
EDIT:
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?
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.
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 
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.
Re
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: https://tickets.metabrainz.org/browse/PICARD-1043
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.
I should add that probably the easiest way to read the read me is to go to https://github.com/metabrainz/picard-plugins/blob/1.0/plugins/classical_extras/Readme.md
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.
Having looked at this more carefully, my original answer stands:
As far as I can see, there is no “(conductor)” subkey in the image you posted and I would not expect one, as “conductor” has its own tag and is not one of the “performer:instrument” tags.
I thought I put the default of “tags to blank” as including “performer:orchestra, performer:choir, performer:choir vocals” with the ensemble_names source being used to replace these. This should do exactly what you want.
I appreciate that there are a lot of options, but I also provided a lot of defaults which can be used as a starting point. Take backups of picard.ini before saving new options, so that you can partially revert if necessary without having to revert to all the defaults.
Hope that helps.
The movement tags are just exactly what you specify in the “work parts” tab. Those are the default names, but you can change them.
Per the readme:
Movement/Part tags:
“Tags for(computed) movement number”. This is not necessarily the embedded movt/part number, but is the sequence number of the movement within its parent work on the current release.
“Tags for Movement - excluding embedded movt/part numbers”. As below, but without the movement part/number prefix (if applicable)
“Tags for Movement - including embedded movt/part numbers”. This tag(s) will contain the full lowest-level part name extracted from the lowest-level work name, according to the chosen tagging style. An option is also provided for tags which are to include any intermediate work levels which are missing from a single-level work tag. Use different tag names for these, from the multi-level version, otherwise both versions will be appended, creating a multi-valued tag (a warning will be given).
I do not provide a Movement Total tag as I don’t know what purpose is served by it (OK I guess you could put “Movement 1 of 4” into your title if you want, but that’s only useful for a player that doesn’t show the other tracks and which probably wouldn’t show work/movement anyway). I can add it if necessary, but bear in mind it will be based on the number of movements in the work as recorded (i.e. if there are only three out of four movements in a particular release, then the movement total will be 3). My recommendation is not to use computed numbers, but just to use the “Tags for Movement - including embedded movt/part numbers” - the “movement name” tag in your example
Use whatever suits your scheme. I use PART, which is consistent with SongKong. The default is to write all three “for redundancy/compatibility”.
See the readme again:
Note for iTunes users: iTunes and Picard do not work well together. iTunes can display work and movement for m4a(mp4) files, but Picard does not write the movement tag. To work round this, write the movement to the “subtitle” tag assuming that is not otherwise used, and use a simple Mp3tag action to convert it to MOVEMENTNAME before importing to iTunes. If you are writing to a FLAC file which will subsequently be converted to m4a then different tag names may be required; e.g. using dBpoweramp, write the movement to “movement name”. In both cases use “work” for the work. To store the top_work, use “grouping” if writing directly to m4a, but “style” if writing to FLAC followed by dBpoweramp conversion. You can put multiple tags into the boxes described above so that your options are multi-purpose. N.B. if work tags are specified and the work has at least one level (i.e. at least work: movement), then the tag “show work movement” will be set to 1. This is used by iTunes to trigger the hierarchical display and should work both directly with m4a files and indirectly via files which are subsequently converted.
I am just testing a new version of this plugin. This will have the following enhancements (so far):
Version 0.8: Handle multiple recordings and/or multiple parents of a work. Handle multiple albumartist composers for one track. Option to use “credited as” name for artists (inc. performers and composers) who are “release artist” or “track artist”. Option to exclude “solo” from instrument types. Option to over-ride plugin options with those used when the album was last saved. Option to keep (and append to) specified existing file tags - furthermore if “is_classical” is present, the work-type variable will include “Classical”. Option to use (and write) SongKong-compatible work tags (saves processing time if SongKong is used to pre-process large numbers of files). Include the work (and its parents) of which a work is an arrangement (as a “pseudo-parent”). Include medleys in movement/part description (as [Medley of:…] or other descriptor specified in options). Permit multiple parents of recordings and works (and multiple parents of those) - multiples are separated by semi-colons.
I am also looking into improving the “genre” capability and using the MusicBrainz “work-type” (NB not the same as the work-type variable referred to above - a confusion I’ll try and address). I’m happy to do a beta-release of the existing new version once my testing is complete, if anyone wants it. Otherwise I may wait until the genre enhancement is added. Let me know of any specific requests.
I am just getting my feet wet with your plugin, but I am already very impressed with all the thought and work that went into this.
It’s very extensive, and yet there is one keyword that is not mentioned in the ‘readme’, nor in the plugin itself, and that is ‘year’.
Are you planning to do anything related to trying to curb, and distinguishing between recording dates, original release dates, re-release dates etc.?
That’s sort of on the wish-list, but I haven’t spec’d it yet. I would like to have date composed as well as release-type dates.
Any specific suggestions are welcome.
Yeah, I understand. Handling years and dates related to tagging is a little nightmare by itself.
For my music manager, I try to restrict it to working with three date fields.
The first is a ‘general’ date field. That’s the one that is compatible with pretty much all soft- and hardware players and content providers.
It’s not always correct, nor very informative, but at least it is showing up pretty much everywhere.
The other two can be populated when more information is available.
If there is specific information on dates such as ‘recorded’, ‘broadcast’, ‘first release’, ‘this release’, etc., through some rules (formulas) they turn up in one of the three date fields that ends up being displayed in my music manager.
I have no clue on what fields MetaBrainz has available to store such dates?
Has MetaBrainz already separate fields available for storing/retrieving different dates such as ‘recorded’, ‘original release’, ‘this release’, etc.?
Date/decade ‘Composed’ would also be very useful for classical music!
And a related question:
I struggled a bit to understand what specific fields a plugin such as yours queries from MusicBrainz.
E.g., I now understand your plugin (has to?) uses formulas to derive the name of a movement, work, act, part, etc. from the ‘title’.
Are those not fields available to retrieve from MetaBrainz?
Is there a listing somewhere to see all fields that MetaBrainz currently uses to store all such attributes?
I noticed your plugin uses plural for ‘Ensemble’.
(id3: TXXX/ensembles Vorbis: ENSEMBLES)
Is that intentional?
I’ll hold date and extended genre functionality for version 0.9. I’m testing version 0.8 and will release a beta shortly.
Actually it is quite complex. Movements and intermediate parts have to be derived from MB metadata by stripping repetitive strings between each work name and its “parent”. For the “canonical” form, only recording/work names are used. The “extended” form adds additional metadata from the Title, attempting not to duplicate strings. The structure of “Title” is inferred firstly from the MB work structure and secondly (if that fails - e.g. just one track for a work) from the Title itself (assuming colons split parts).
The best way to see the actual MB structure is via an XML query - see MusicBrainz API - MusicBrainz
Yes. “ensembles” is just a shorthand for the internal (‘hidden’) variable _cea_ensembles. You can use the plugin “View script variables” to see all these. You use the tag mapping section to map it to whatever name you want to use - ENSEMBLE if you wish. I map to BAND not ENSEMBLE as it works better with Squeezebox (sometimes ENSEMBLE gets confused with ALBUM ARTIST). Also I use ‘ensemble_names’, not ‘ensemble’ as the source because I don’t want ‘(orchestra)’ etc. I use plurals in the internal variables to avoid confusion 
See the readme for the reason for this:
Artists
All the additional hidden variables for artists written by Classical Extras are prefixed by cea. Note that these are generally in the plural, whereas the standard tags are singular. If the user blanks a tag then the original value is stored in the singular with the cea prefix. Thus _cea_arranger would be the contents of the Picard tag “arranger” before blanking, whereas _cea_arrangers is hidden variable created by Classical Extras.
There’s two ways to answer that, depending on which interface you’re interested in: in terms of files, Picard by default only saves the date of the selected release and the date of the earliest release in the release group (you can see the full list here). In the database itself, the only dates explicitly tied to a particular entity are the potentially multiple release dates of a release – which is one of the arguments against standalone recordings – but any relationship can have beginning and ending dates as well.
That last is the closest we get to a recording date, and you’d probably be looking at the date on the “recording of” relationship with a work or the “recorded at/of” relationship with a place/location, but it’s a bit harder to boil down; as an extreme example, every performer could have played their track on a different day, in a different location, and then sent them to yet another person for mixing, and you might end up with more dates than you want to deal with. Or, unfortunately more likely, no relationhip on the recording could have a single date to it, if there are any relationships there in the first place.
Finally, Picard can theoretically take any of those and save them to any field you want, but you’d be writing a plugin to do so. There was some talk several months ago about a plugin that would calculate the earliest date of any release using each recording (rather than the simpler, official “original release”), but last I checked everyone working on it had more or less abandoned it, and it was still rather buggy.
After the next release (0.8) of Classical Extras, I’ll look into adding some date functionality.
That seems to me the most promising avenue to follow for the recording date - starting with the recording-work relationship (we are talking classical here…). What I need is a priority order for a single recording date so that at least something is found (hopefully).
I also want to add a composition date, which I think is an attribute of the work-composer relationship. There might then be an editable table to match periods with dates.
