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?
Another (and more ideal) solution would of course be that your plugin could map and write MusicBrainz’s ‘work’ title. (= “recording of:” )
Then I could avoid the need of a script for it.
But unless I am mistaken, that cannot be achieved at the moment?
(and wouldn’t it be nice if like the Eskimos have 50 words for snow, we had 50 words for work?)
Classical Extras does not overwrite title. However, if you have specified “work” as a tag in the options, the script will use that, not the original MB work (the script runs after the plugin).
You have a number of alternatives:
Make sure “work” is not set by Classical Extras (also make sure you are not overriding the displayed options and setting it).
Use the hidden variable “_cwp_work_0” in the script instead of work (no need to unset afterwards)
That’s exactly right. Use tag mapping to map “work_0” to “title”. You will also have to add “title” in the list of tags to blank (otherwise it will append work to the existing title) and add another tag mapping line (after the first) to map “title” to “title” with “conditional” selected (in case there isn’t a work for the track).
I am experiencing regular freezes when trying to load albums in Picard.
If they already contain MB ID’s, without the plugin active, loading it’s information in the right panel goes quite speedy.
But with the plugin active, not only does it go a lot slower, but it also regularly freezes.
Restarting Picard will fix it, but after a couple of albums it often freezes again. (it will continue displaying “loading album information”)
Secondly (but this might well be to be expected), loading incomplete box-sets/albums goes very slow.
For example from a box set of originally 20 albums, I might have only 8 tracks containing a specific work_n
With the plugin deactivated, it will load rather quickly (a couple of seconds), showing all box set tracks, and only 8 of them with a green block. (which is to be expected)
With the plugin active, this will take a lot more time, and as I said, also regularly is interrupted by freezes.
I notice at the bottom right of Picard’s panel that the green arrow will be counting down all tracks from the box set. Not only the 8 tracks that are actually present.
That probably explains the longer loading time, but without the plugin active Picard seems to ‘know’ only to get info for the tracks present?
Let me now if I can do some more specific tests if you see possible issues here.
Just a quick thing first - check that you have removed logging in the “advanced” tab. For first-time loads, I recommend only logging errors, not warnings, debug or info.
Ok. But before possibly wasting your time, I’ll do some more testing first for at least a couple of days. I also found the picard.exe.log file, and I’ll see if I notice anything there that might give a clue.
So you yourself never experience such freezes?
That would definitely hint at something being wrong with my settings/setup.
Maybe some setting I have changed in Picard that doesn’t play nice with your plugin.
I’ll be back when I have some more useful info.
No probs. I have a test set of currently about 160 albums (and growing) which I use for regression testing and it all runs as a batch with no errors. I hope to release v0.8.7 shortly which fixes known bugs and has a few improvements.
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.
