We have another Picard release, see the release announcement.
Picard 2.0.4 mostly fixes some important issues that were introduced with the 2.0 release, but it also fixes some long-standing bugs. Thanks a lot to everybody who reported issues here or on the bug tracker.
If everything goes well and no issues pop up that require a fast bug fix release most likely the next release will be Picard 2.1. We already have a couple of new features and fixes in the pipeline.
And thank YOU @outsidecontext for all the bugs you fixed and tickets you closed as part of this release. Well done, sir!
Bumping this request/observation:
Any thoughts on this from people that are able to make changes?
It still feels like a silly exercise having to add e.g. both:
composer, Composer, and COMPOSER to âpreserve these tagsâ.
We have a bug report concerning shortcuts not working on Windows 7with 2.0.4 : https://tickets.metabrainz.org/projects/PICARD/issues/PICARD-1348
Can you test if Ctrl+D open the Add Folder⌠dialog for you and report back along your env ?
Ctrl+D works for me on ubuntu 18.04 and 16.04
Works for me using Picard 2.0.4 under Windows 7.
Works for me using Picard 2.0.4 (64-bit) on Windows 7 Ultimate (64-bit). Also tested Ctrl+Y and it did Lookup, so that works as well.
Btw. you linked the wrong issue, my guess is that you meant to link https://tickets.metabrainz.org/projects/PICARD/issues/PICARD-1348 instead 
Ooops, thanks for noticing the bad link, fixed 
It looks like the issue is locale-dependent. Weâre on the track, thanks for reports.
I am still struggling how to make use of the $set(_id3: function.
Suppose I want to create an id3 tag frame named: TXXX/newtag
If I use $set(_id3:TXXX/newtag, a new tag is written, but only as TXXX/ (leaving out ânewtagâ)
Is my syntax wrong here?
And, using something like $set(_id3:TOAL works fine, but something like $set(_id3:USER will not work at all.
Are there some restrictions in what you can do with this?
Or is this perhaps a Picard 2.0.4 issue?
Another thing I noticed testing this:
If I clear a track of all tags, and then run it through Picard using e.g.: $set(_id3:TOAL,%mixer%), Picard will not display that tag in the right column. (showing the âto be writtenâ tags)
But whe I check the file elsewhere, I find that it has been written indeed.
When running it through Picard a second time, it will show up in the left panel, but marking it for deletion.
Are there logics behind that that I am missing?
First I would question why you need the _id3: style tags at all. What is your use case? Because this is really a very special syntax (kind of a hack really), and unless you have a good reason to do this you should not use it 
The correct syntax is $set(_id3:TXXX:newtag,...). The result for MP3 will be the same as $set(newtag,...). If loading the file again the value will also be loaded as newtag
Yes, absolutely. With the _id3 syntax you are basically bypassing all normal Picard tag mappings and directly setting ID3 frames, and those are strictly defined in the ID3 specification.
Historically there had been two use cases why one would want to use the _id3 tags:
TXXX: frameThe first use case is still valid, but usually if a tag is supported by Picard you should use Picardâs tag name for setting it. So instead of $set(_id3:TOAL,...) you would do $set(originalalbum,...).
The second use case for TXXX frames has mostly become obsolete since Picard now supports writing unknown tags to TXXX frames by default. So $set(newtag,...) will actually write a frame TXXX:newtag. You still want to use the _id3 syntax if a name you want to write conflicts with a name defined by Picard. So e.g. if you want a frame TXXX:artist you would need to set it with $set(_id3:TXXX:artist,...), because artist is a tag name defined by Picard and mapped to TPE1 for ID3. Another exception is if you want to write a TXXX frame only for ID3 and donât want to have this tag in any other format (e.g. you only want TXXX:newtag in your MP3 files, but donât want to see the newtag tag in your FLAC files).
_id3 has some limitations, see the following ticket and my answers:
The reason for me trying to achieve this, is that my music manager will usually prepend âtxxxâ to a custom created id3 tag.
If I use the $set function in Picard using that same tag name, it will not prepend it with txxx if it is a known tag name for Picard.
So to make Picard and my music manager play nice together, for some tags I need to have Picard write the txxx part too.
Thanks to your explanation I have succeed in that now.
Iâm not sure if this is a Picard 2.0.4 issue, expected behaviour, or an oversight on my part:
(2.0.5 dev1 actually)
Suppose I have installed a plugin (for example in this case Classical Extras) and made adjustments to the settings of that plugin.
If I later remove the plugin completely (by means of Picards plugins panel), restart Picard, and re-install the plugin, all customized settings are there again.
While that can be useful in some cases, I find it a bit unexpected.
And it makes it difficult to start using a plugin with a clean slate and default settings.
Can the settings from removed plugins be found and deleted somewhere?
I think that is intentional behavior. I personally would find it very frustrating if my settings would be lost just because I donât want to use a plugin for a while. For restoring the default that should already be possible on the pluginâs options page.
Thank you Speedy Gonzales,
Are you suggesting that the plugin should have a ârestore defaultâ setting in itâs own interface somewhere?
(CE hasnât for as far as I can tell)
If you are referring to Picardâs ârestore defaultâ and ârestore all defaultsâ buttons that are pretty much âalways thereâ at the same location at the bottom, I always hesitated and refrained from using those.
The reason is that it wasnât clear to me what it ârestored/removedâ exactly.
Your suggestion made me try it out again.
I didnât touch ârestore all defaultsâ, because I am guessing it resets Picard itself completely?
Or maybe only the panel that you are looking at?
Trying ârestore defaultsâ indeed seems to restore the CE plugin when it is in view.
But it is not only restoring the tab of the plugin that is in view (what I would expect), but it resets the whole plugin.
These are just some observations, trying to understand how this works.
Iâll poke @MetaTunes about this, perhaps he has some ideas or remarks about this too.
Thanks.
.
edit:
Hm, I seem to have missed that these two buttons have pop-up notifications.
The first one indeed restores Picard completely.
So, would it also restore/remove all plugins, their settings, your scripts, etc. etc.?
Itâs a bit of an odd location for such a powerful (and potentially damaging) feature, isnât it?
I would suggest moving that button to âgeneralâ in settings with some brief explanation.
And perhaps add a some refinements for what you want to reset exactly?
The second one says âreset all settings for current options pageâ.
In the case of CE, that doesnât seem true, since it resets the plugin as a whole, not only the current page.
If you want to restore CE to its defaults then this needs to be done using the main Picard reset, as you discovered later. Iâll consider if the plugin needs its own ârestore defaultâ setting (see further comments later). Meanwhile, remember that the plugin has a more flexible way of managing different settings in that it can save any settings to a tag and (optionally) automatically re-use those same settings next time you load that album.
So you customise the settings to suit 80%+ of your needs (your own personal âdefaultâ) and tweak them for the albums where you want to use slightly different settings. You then make sure the settings are saved in tags and reloaded each time (on the âadvancedâ tab). If you want to change the settings for an album, refresh with the relevant âover-rideâ box unchecked and the displayed settings will be used. Then save again.
The next plugin release will have a number of enhancements which will hopefully make customising of settings between different albums less necessary. I will also be changing the defaults to what I consider a more useful set, but they will only ever be a âbare bonesâ starting point.
Picard doesnât realise there are multiple tabs. Most plugins arenât this big 
If the plugin had a ârestore defaults for this tabâ, then logically (from the softwareâs point of view) it would make sense to restore the linked settings on the advanced tab too, but that might not be obvious to the user.
One important point that is missing from the prior discussion is to backup the Picard.ini file. This is by far the best way of keeping a set of options (for Picard and its plugins) - or several different sets - which you can revert to at any time.
@outsidecontext : I think it would be great if Picard had a menu option to make a backup or restore from a backup .ini - itâs a bit of a pain having to search for the file (buried in a hidden folder in Users, in Windows, not even the same place as the plugins folder since 2.0).
Lastly, the âget out of jailâ card with Classical Extras is to use the âOverwrite options in Options Pagesâ box at the bottom right of the advanced tab. This will over-write the displayed options with any that have been saved to tags, as per above, when loading a release, provided the âOver-ride plugin optionsâ boxes are checked as well. So, if you know that a certain release uses your personal favourite default settings, you can use that to restore these defaults to the .ini file, even if you have no backup. Note that the box will automatically be unticked after loading/refreshing one album, and will always be turned off when starting Picard, to prevent inadvertant use.
There are two buttons. âRestore all defaultsâ resets all settings, âRestore defaultsâ only the options page you are currently looking at. In both cases only the options in the dialog are reset, you still have to save the dialog to persist the changes.
It is true, the options page is what you select in the left. Inside one options page the plugin would be free to do what it wants. It can have different sections, tabs, nested tabs, multiple tabs, sub dialogs etc. However, the plugin would be able to override the reset behavior, so if it would make sense to reset only part of the settings based on the view that could be implemented by the plugin.
Is there an API for that?
Yes, you can override restore_defaults in your OptionsPage implementation. You can look at the Picard source, some of the existing options pages make use of it. Although in most cases thatâs only a very small addition, whereas in your case you would probably need to reimplement the function to handle only currently visible optiins.