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)
Important:
The plugin will not work fully unless you have enabled “Use release relationships” and “Use track relationships” in Picard->Options->Metadata.
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.
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.
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.
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
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…
I guess I was My thinking is that it is more consistent to make the change. I’ve spotted some other areas where consistency could be improved, so I’ll do them as a batch.
There are two ways of doing this:
Save your picard.ini file (copy and rename as something) - it’s in AppData->Roaming->MusicBrainz in Windows.
On the Advanced tab in the plugin UI, “Save plugin details and options in a tag?” can be used so that the user has a record of the version of Classical Extras which generated the tags and which options were selected to achieve the resulting tags. This will just associate the options with that particular release. To re-use them, check the “Over-ride plugin options displayed in UI with options from local file tags” option.
See the readme for full details. I just use the comments tag (see the picture in the readme). Best to stick with the same name once you’ve chosen one - I haven’t fully tested what happens if you change the name here (it should cope, but no guarantees).
Ah, that’s very clever.
I really have read the tutorial, and my eyes have went over the settings certainly more than once, but only now the penny has dropped on that one…
The plugin writes to “show work movement” (only) because that is the tag that I think iTunes uses. I wasn’t aware of a different tag being used by other software. However, if you want to use a different tag, just use the tag mapping - map the source “show work movement” to “showmovement” or whatever.
“show work movement” is set to 1 if the number of levels is > 0. If you need more sophisticated information, the source “part_levels” will give the number of levels for this track and “work_part_levels” gives the greatest number of levels for the work as a whole.
Please note that if you want to use Classical Extras, it will only run currently with Picard v1.4, not v2.0. I am planning a v2.0-compatible version, but not quite yet.
I have Picard setup with a script to write MusicBrainz’s ‘Work’ title to the ‘title’ tag.
(I like having this ‘recording of:’ as a title)
But when I have the plugin active, the title tag is always (over)written.
I have searched for possible settings related to writing the ‘title’ tag, but couldn’t find any.
Is there a way to prevent the plugin from writing the ‘title’ tag?
