Bug alert: I’ve discovered a slight bug in the new release. I suggest not using it until I fix it.
No hurries on my account. I am aware it’s beta, and I will just be messing around on test files for a (long) while before I make things more permanent.
By way of further explanation of the difference between recordings and works. If you go to the overview tab of the work - https://musicbrainz.org/work/7929a5ce-db78-355a-a026-e623933548a4 - you will see about 48 recordings listed - of which the recording referenced above is number 13.
So the work name is unique (within MB) but the the recording names most definitely are not!
More accurately, replace “work name” with “work ID”. We don’t care whether two artists both name their separate songs “Summer” or something, but they will definitely be different entities. Maybe the classical guidelines put enough data in there to uniquely identify them, but in other genres we typically just use the (most common) recording title and, if you’re lucky, add a disambiguation. Any logic that works purely on those titles is going to be tripped up rather easily – there’s a reason the “select a work” dropdown on the site also includes the writers and artists.
1 Like
Agreed that is probably the case for non-classical music. The internal logic of Classical Extras works entirely on ids of course. However, the classical work names are pretty unique 
, especially when combined with Composer, particularly because there is usually an opus or catalogue number included. So, using my favoured library manager (Muso), I can look at the Composer->Work hierarchy (where Work is the top-level work name in MB) and see all the recordings I have of that particular work (or parts or arrangements of it). This is not possible using names derived from Titles. The only other method I know of is the proprietary MusiCHI system, but I far prefer the community-based MusicBrainz 
2 Likes
I realized a bit after posting that that you probably have pretty good luck with restricting your plugin to classical works before the rest of the fields are processed. 
For anyone else reading through the thread who might have a mixed library, though, I figured it wouldn’t hurt to clarify the difference.
1 Like
Known bugs have been fixed 
Beta version 0.8.1 is now at https://github.com/MetaTunes/picard-plugins/releases/tag/v0.8.1
Note that the new functionality to save the options used as tags (and re-use them) means that you can use different options for different releases if necessary and they will be remembered (if that’s what you want). The options to control this are at the bottom of the “advanced” tag.
1 Like
I’m considering adding an option to use the “primary alias” of a work name (for a chosen “locale”) rather than the main work name. This follows on from various discussions, such as this one - Language consistency in work names and should reduce the problem with inconsistent use of original language names etc. At first this would just be for works, rather than artists, but could be extended.
Question: should I use the name or the sort-name? From what I can see, sort-names are optional, not always added and will default to the name if left blank.
1 Like
I’d recommend both if you can, like Picard does for the official variables: artist and artistsort, title and titlesort (even though the latter isn’t currently meaningful). Or I might just be revealing my complete ignorance and Classical Extras doesn’t actually operate with scripts and variables.
Classical Extras is a python-based plugin which creates many “hidden variables”. It has a UI which then permits the user to map these variables to tags according to their wishes. If the UI does not fulfill someone’s needs then they can write scripts to use the hidden variables.
So clearly the plugin can create hidden variables for both sorted and unsorted - that is not a problem. I am reluctant, however, to add too much more to the UI as it is already quite complex. I will add an option to use aliases. My inclination then is to use the unsorted names for the work and movement tags (which will be used by the music software for display purposes) and to just allow the sorted option for the “top-level” work, which is more likely to be used for cataloguing purposes. Browsing through the MB database, I can’t find much use of the “sorted” names for work aliases anyway - even ones like “The Sleeping Beauty” will therefore get catalogued under “T” not “S” unless someone edits the alias to add a sort name.
1 Like
We have a long term-ish goal of replacing entity “canonical” names with aliases (e.g., to improve on i18n and l12n), at which point the sort names would probably get more use. I’m not sure the alias sort names are used for anything in MB itself right now.
1 Like
Is there somewhere where the plan for this is described? What will happen to the “canonical” names and will the aliases continue to be stored in the same way in the database structure (accessible via XML with inc=aliases and listed under the alias-list & alias tags)?
It’s long term enough that I don’t think there’s any decided implementation details.
I’ll conclude from the previous remarks that providing the alias as an option is a “good idea” and will worry about any database changes if and when they happen.
Makes sense, and probably a good plan, but my mentality is more on the side of “managing one extra variable and one extra $if2 is worth the flexibility of (eventually) being able to work with both”. I do see where you’re coming from though, and I do tend to go overboard at times in planning for the future, so if you don’t think there’s enough benefit then I’d get where you’re coming from in not including it.
They’ll both be there as “hidden” variables - it was just a question of what makes it into the UI.
1 Like
I haven’t been able to make a lot of progress yet (busy with other stuff), but I have a quick question for now:
I would like to have the ‘title’ tag filled with the full canonical title.
After changing some settings in the plugin, I was able to write that full title to the ‘work’ frame, but when I (mis?)-use this setting to try to write it to ‘title’ instead, that won’t work:
Is this achievable somehow?
(my apologies beforehand if this is to be found in your excellent ‘howto’. You have gone out of your way to create that great tutorial. But still, the vast amount of new information and concepts can blind a newbie, and make one miss some obvious information that in hindsight was already available)
Not quite sure what you mean by “won’t work”. If it has no effect at all, check that you don’t have the “over-ride plugin options” selected for “work options” at the bottom of the “advanced” tab, otherwise any changes made to the “work and parts” tab will have no effect if the release has already been tagged by the plugin…
In any case, what you have done will only put the parent work name in the title. If you want the movement name as well then you will need to add ‘title’ in the movement section too:
This may result in some duplicated text - the risk of this can be reduced by using the “consistent with lowest level work” option in the “tagging style” section.
There may still be some duplication even then. I am working on a solution for this. In the meantime, if this is a problem, an easy work-round is to use the tag mapping on the “Artists” tab. (This can be used for any tag mapping, not just artists).
Just map
~cwp_work_0
onto title, with conditional unchecked, thus:
EDIT: You will also need to blank the title first, by adding “title” to the list of tags to blank, otherwise you will get the old title and the new one.
Thanks for the quick reply.
I can’t get it to work right now. Tried it with flac, mp3, different capitalizations for tag names, etc.
It does write the ‘work’ frame with the full canonical title, but the ‘title’ frame still gets a ‘shortened’ version:
But perhaps I have changed some other relevant setting in Picard or your plugin.
I’ll give it a clean shot anytime soon.
Which version of the plugin are you using?
Looks like Title is concatenating the top work with the movement. But I can’t replicate that with v0.8.1. I’d need to know what all the work options were (e.g. an image of the “work and parts” tab).