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.
1 Like
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
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.
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.
1 Like
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.
1 Like
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.
1 Like
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.
2 Likes
Thanks a lot MetaTunes and WovenTales.
All your info, and some more reading brought me one step further, namely deciding not to put too much effort in creating, and trying to populate too many different tag frames in my music player/manager such as ‘works’, ‘acts’, ‘movements’ etc. (I won’t even be using the introduced ‘Movement name’ tag)
My setup will mainly depend on retrieving and storing as complete track titles as possible, and importantly, use (well, keep using actually) custom delimiters on title segments such as ‘work’, ‘cat. nr.’, ‘part’, etc.
That’s because one thing I learned in testing stuff out, is that the suggested delimiters such as comma, colon and hyphen are far too common, and make it pretty much impossible to get consistent results when using formulas to dissect them.
(also because many releases on MBr don’t seem to follow these guidelines)
So I am confident I can now make a clean setup of all needed tag frames and formulas for my player.
When that’s all done to satisfaction, I’ll return to Picard and this great plugin for the next round…
I hope upcoming beta’s will be made available. Testing those will probably bring some more understanding, and very very maybe some suggestions/wishes.
That’s whyClassical Extras uses the canonical work names in MusicBrainz as the primary source. I got fed up with different naming conventions for titles. To the extent that I do use them (e.g. to provide additional info) the plugin infers the structure in the title from the MusicBrainz work structure and only resorts to colon-splitting 
if all else fails (usually compilation albums).
What I can do now is see all the recordings of a work that I have regardless of how they were named on the title (and even if they are arrangements - in v0.8 
).
v0.8 is now available for beta testing at picard-plugins/plugins/classical_extras at 1.0 · MetaTunes/picard-plugins · GitHub
Zip and install the .py files.
Release notes:
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).
Allow for multiple parents of recordings and works (and multiple parents of those) - multiples are given as multiple tag instances, where permitted, otherwise separated by semi-colons.
Option as to whether to include parent works where the relationship attribute is “part of collection”.
Plus minor enhancements and bug fixes too numerous to mention!
I use Part, Groupheading, and Work in Muso and just leave the players with Title.
Groupheading is for the work name text to be displayed. Work is the canonical top work to allow browsing for recordings of the same work.
You could just reconstitute Title from component elements in your desired fashion, if you wish.
I am not sure I have a correct understanding of what ‘canonical’ is in this context, could you explain?