Version 2.0 of my plugin for Picard - “Classical Extras” is now available as a beta release. This is basically a re-engineered and enhanced version specifically for use with Picard 2.0.x.
A brief summary of what it does:
Classical Extras 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. While it is designed to cater for the complexities of classical music tagging, it may also be useful for other music which has more than just basic song/artist/album data.
The options screen provides five tabs for users to control the tags produced:
1. Artists: Options as to whether artist tags will contain standard MB names, aliases or as-credited names.
Ability to include and annotate names for specialist roles (chorus master, arranger, lyricist etc.).
Ability to read lyrics tags on the file which has been loaded and assign them to track and album levels if required.
(Note: Picard will not normally process incoming file tags).
2. Tag mapping: in some ways, this is a simple substitute for some of Picard’s scripting capability. The main advantage is that the plugin will remember what tag mapping you use for each release (or even track).
3. Works and parts: The plugin will build a hierarchy of works and parts (e.g. Work → Part → Movement or Opera → Act → Number) based on the works in MusicBrainz’s database. These can then be displayed in tags in a variety of ways according to user preferences. Furthermore partial recordings, medleys, arrangements and collections of works are all handled according to user choices. There is a processing overhead for this at present because MusicBrainz limits look-ups to one per second.
4. Genres etc.: Options are available to customise the source and display of information relating to genres, instruments, keys, work dates and periods. Additional capabilities are provided for users of Muso (or others who provide the relevant XML files) to use pre-existing databases of classical genres, classical composers and classical periods.
5. Advanced: Various options to control the detailed processing of the above.
All user options can be saved on a per-album (or even per-track) basis so that tweaks can be used to deal with inconsistencies in the MusicBrainz data (e.g. include English titles from the track listing where the MusicBrainz works are in the composer’s language and/or script).
Also existing file tags can be processed (not possible in native Picard).
A slight health warning: classical music tagging is quite a complicated matter, so the plugin necessarily has a large number of options which may initially be daunting; it is important to fully read the the comprehensive documentation in the “readme” file. Once you have determined the options which fit your requirements and
music software ecosystem, however, it does very much streamline otherwise complex tagging (assuming the data is in MusicBrainz ) For more context on how to use it, see my website.
Get the zip file to install the plugin here. If there are any questions (after reading the readme) or issues, please post to this thread.
Not sure I want to add even more options at this stage - I’ve had complaints that there are too many . Does your music manager expect the value of the showmovement tag to be 1? In which case, the easiest thing is just to map “show work movement” onto “showmovement” in the tag mapping section. No need for a script, and you certainly don’t want to edit the plugin itself (over 8000 lines of code, excluding the UI ).
Somehow I keep overlooking the mapping options.
(it might have to do with the colours )
I gave the mapping option a quick try, but I noticed two things that hinder me/I don’t understand well.
When I click on the ‘Source from:’ button in the Tag mapping tab, it becomes a darker grey and you can enter something in the field next to it.
But when I re-open that panel, it’s greyed-out again.
It doesn’t seem to hinder the purpose, but it looks/feels awkward, and I don’t think I’m able to tell if a mapping rule is active or not?
(maybe it’s a Windows graphics thing?)
Using mapping, it now writes both ‘show work movement’ and ‘showmovement’ tags.
I believe you can prevent that by adding an entry under ‘Initial tag processing’, but I have that part of the pane ‘greyed out’ and cannot enter anything in it.
I found out that it’s probably because I currently have ‘Create extra artist metadata’ unchecked in another tab.
But I wouldn’t guess that that setting on the ‘Artists’ tab would be of influence on the tagging options for the mapping panel?
P.s.
F.y.i. (or others interested), this little script works fine for this purpose:
$if($gte($get(_cwp_part_levels),1),$set(showmovement,1),)
$unset(show work movement)
A “feature” of Qt seems to be that you can’t lock a dropdown from unwanted scrolling when the mouse is not over it. By default, therefore, I have locked source dropdowns to prevent inadvertant changes by mousewheel movements. Clicking the “Source” button unlocks it for editing (as described in the notes on that page).
That is correct.
That is also correct. At the top of the panel it says “N.B. Artist options (1st tab) need to be enabled for this section to run” which is slightly misleading because the tag mapping will still run. You are right to point out the inconsistency - originally this was all part of the “artists” section. I’ll look at fixing it if it is easy, otherwise it will have to wait as my focus is on bug fixes and code improvements before doing an “official” release.
Given that you have disabled the artists section and want to delete the original tag, then this is the best approach. That’s what the hidden variables are for.
BTW, I’m interested to know why you disabled the first section. Assuming you have sensible options, it shouldn’t interfere with anything and takes negligible processing time.
That’s mainly because of testing purposes.
I’m still a bit in my wonder years in regard to MusicBrainz/Picard/plugins/scripting.
I am currently testing a new plugin that manages instruments/performers, and I thought it wise to disable other plugins and scripts that might interfere in the results I am getting.
I am still not very confident I understand exactly what is the ‘chain of command’ in regard to settings in Picard itself, scripts and plugins.
So for me that will take a lot of time, and a lot of testing to learn and understand the results.
If I understand correctly, when you remove all entries from the genre and sub-genre boxes in the Genres tab, that shoud work as a “do not filter” switch.
But I find that if I do clear those boxes, no genres are matched at all anymore.
And a tag: 003_information [genres]: “Candidate genres found but not matched: …” is written.
From a users perspective, it would be nicer (and a little more obvious) if you could enable/disable this filtering with a checkbox.
Now if you have cleared these boxes, all proposed genres are definitely gone and you will have to enter any ‘usual suspects’ genres and sub-genres manually again.
(not an easy job if you forgot to copy and save the original contents of the boxes somewhere
I’ll think about that too. This section could do with a bit more clarity.
Before making any changes on this scale, I would always recommend backing up your Picard.ini file. You can then easily go back to the earlier choices. It’s a good idea to back up regularly anyway.
Just another thought on this. Because I use Muso, I don’t tend to use these boxes much. Even non-Muso users can simulate the Muso-based behaviour by adding an xml file as described in the readme. That way you have an external store of these options and can turn it on or off at any time.
BTW I’ve spotted that the greying out of options on this tab (when use Muso selected) is no longer working. I’ll fix that in the next release.
Good advice of course. But if you restore that ini, it’s kind of a a global restore.
It will also affect scripts and other plugin settings you might not be sure of that you want restored to the state when you created that .ini.
And it’s not very realistic to think you’ll remember or write down everything related to the specific .ini’s that you have saved.
Personally I would prefer to have some more control over what to save/restore exactly.
Ideally some options like these would be nice:
import/export Picard settings
import/export scripts
import/export plugin settings (per plugin)
Surely that goes beyond the scope of this specific thread, but wouldn’t you like to have an ‘export/import settings’ option for your plugin?
That is (in essence) provided by the “Overwrite options in Options Page” setting at the bottom right of the advanced tab. It will restore the settings to those saved with a particular album. An export/import might be a good idea, too, if it doesn’t distract me from getting the new release out
But that will not apply to a release you are running by your plugin for the first time.
No hurries, no demands, no pressure.
Just some observations from a 12th row musician from the orchestra pit offered to a well-respected conductor.
I know it’s a bit devious, but this is how it works:
You load an album which you have previously tagged with the settings you want to use (and which you have saved using the options labelled “Save plugin details and options in a tag?” on the advanced tab. When you load that album, select all the options labelled “Over-ride plugin options displayed in Options Pages with options from local file tags (previously saved using method in box above)?*” and also select “Overwrite options in Options Pages”.
This will change all the CE options to be the same as on the album you just loaded. Now load your new album and CE will apply those options to it.
If you use this method, every time you save an album, you are effectively exporting those settings with it. Normally when you load an album with saved options, it does not overwrite the displayed options, but will use its saved options instead (and write a tag to say what it has over-ridden). Only if you select “Overwrite options in Options Pages” will it overwrite the displayed options (like an import) so that they will affect any subsequent album you load (assuming it doesn’t have save options or that the “over-ride options” are not selected).
I am trying to understand the mechanics behind ‘show work movement’.
With e.g. this release:
the plugin will write the ‘show work movement = 1’ tag for track 10.
(Pavane for orchestra and mixed choir, op. 50)
I am far from a classical buff, but I believe this is to be considered a stand-alone work?
If that’s correct, why would the ‘show work movement’ tag get written?
Because it is an arrangement of Pavane, op. 50 and you have selected “Show arrangements as parts of original works”. So CE will treat it as a child of the Pavane, op. 50. If you don’t want works which are arrangements to be treated like children, deselect the option.
The indicator is intended to permit iTunes to display the “movement” as part of the parent work in an indented style. If you want arrangements to appear in this way then this flag needs to be set; if you don’t then deselect the option. The term “show work movement” is iTunes’ not mine. I would prefer to call it something like “show work structure” but that won’t work in iTunes You can call it what you like by changing it in the tag mapping section (which, btw, I am restructuring as previously discussed).
I think you are absolutely right.
But iApple did a fine job here (again) in simplifying, confusing, mis-informing and dumbing-down ‘the people’.
Please carry on
) For more context on how to use it, see my website.
. Does your music manager expect the value of the showmovement tag to be 1? In which case, the easiest thing is just to map “show work movement” onto “showmovement” in the tag mapping section. No need for a script, and you certainly don’t want to edit the plugin itself (over 8000 lines of code, excluding the UI 
).
You can call it what you like by changing it in the tag mapping section (which, btw, I am restructuring as previously discussed).