# Picard 2.0.4 is available
**URL:** https://community.metabrainz.org/t/picard-2-0-4-is-available/396815
**Category:** MusicBrainz Picard
**Created:** [September 5, 2018, 12:20pm UTC](https://community.metabrainz.org/t/picard-2-0-4-is-available/396815 "2018-09-05T12:20:23Z")
**Posts on this page:** 19
**Page:** 1
### Author:  [@outsidecontext](https://community.metabrainz.org/u/outsidecontext)
#### Post date: [September 5, 2018, 12:20pm UTC](https://community.metabrainz.org/t/picard-2-0-4-is-available/396815/1 "2018-09-05T12:20:23Z")
We have another Picard release, see the [release announcement](https://blog.musicbrainz.org/2018/09/05/picard-2-0-4-released/).
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](https://tickets.metabrainz.org/browse/PICARD-1332?jql=project%20%3D%20PICARD%20AND%20fixVersion%20%3D%202.1.0%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC) in the pipeline.
---
### Author:  [@rdswift](https://community.metabrainz.org/u/rdswift)
#### Post date: [September 5, 2018, 11:45pm UTC](https://community.metabrainz.org/t/picard-2-0-4-is-available/396815/2 "2018-09-05T23:45:28Z")
And thank _ **YOU** _ @outsidecontext for all the bugs you fixed and tickets you closed as part of this release. Well done, sir!
---
### Author:  [@hiccup](https://community.metabrainz.org/u/hiccup)
#### Post date: [September 15, 2018, 4:31pm UTC](https://community.metabrainz.org/t/picard-2-0-4-is-available/396815/3 "2018-09-15T16:31:38Z")
Bumping this request/observation:
> [@Picard 2.0.3 released: Crash-fixes and scripting improvements](https://community.metabrainz.org/t/picard-2-0-3-released-crash-fixes-and-scripting-improvements/393584/3):
>
> Great, thanks @samj1912 I was wondering, could you comment on this observation I have made earlier? : . And another thing I noticed: The input for the ‘preserve these tags’ option seems to be case-sensitive. I myself can not think of any useful reason that it is. On the contrary, it makes it more troublesome to get it working, since you’ll have to worry about idiosyncrasies of other software and the different codecs you might be using. Do you agree? Could it be made case-insensitive?
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’.
---
### Author:  [@Zas](https://community.metabrainz.org/u/Zas)
#### Post date: [September 18, 2018, 10:56pm UTC](https://community.metabrainz.org/t/picard-2-0-4-is-available/396815/4 "2018-09-18T22:56:56Z")
We have a bug report concerning shortcuts not working on Windows 7with 2.0.4 : [https://tickets.metabrainz.org/projects/PICARD/issues/PICARD-1348](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
---
### Author:  [@rdswift](https://community.metabrainz.org/u/rdswift)
#### Post date: [September 19, 2018, 12:26am UTC](https://community.metabrainz.org/t/picard-2-0-4-is-available/396815/5 "2018-09-19T00:26:27Z")
> [@Zas](#):
>
> Can you test if Ctrl+D open the Add Folder… dialog for you and report back along your env ?
Works for me using Picard 2.0.4 under Windows 7.
---
### Author:  [@culinko](https://community.metabrainz.org/u/culinko)
#### Post date: [September 19, 2018, 6:30am UTC](https://community.metabrainz.org/t/picard-2-0-4-is-available/396815/6 "2018-09-19T06:30:16Z")
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](https://tickets.metabrainz.org/projects/PICARD/issues/PICARD-1348) instead 🙂
---
### Author:  [@Zas](https://community.metabrainz.org/u/Zas)
#### Post date: [September 19, 2018, 8:05am UTC](https://community.metabrainz.org/t/picard-2-0-4-is-available/396815/7 "2018-09-19T08:05:08Z")
Ooops, thanks for noticing the bad link, fixed 😉
---
### Author:  [@Zas](https://community.metabrainz.org/u/Zas)
#### Post date: [September 19, 2018, 8:30am UTC](https://community.metabrainz.org/t/picard-2-0-4-is-available/396815/8 "2018-09-19T08:30:38Z")
It looks like the issue is locale-dependent. We’re on the track, thanks for reports.
---
### Author:  [@hiccup](https://community.metabrainz.org/u/hiccup)
#### Post date: [September 25, 2018, 7:36am UTC](https://community.metabrainz.org/t/picard-2-0-4-is-available/396815/10 "2018-09-25T07:36:58Z")
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?
---
### Author:  [@outsidecontext](https://community.metabrainz.org/u/outsidecontext)
#### Post date: [September 25, 2018, 8:31am UTC](https://community.metabrainz.org/t/picard-2-0-4-is-available/396815/11 "2018-09-25T08:31:25Z")
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 😃
> [@hiccup](#):
>
> If I use $set(\_id3:TXXX/newtag, a new tag is written, but only as TXXX/ (leaving out ‘newtag’)
> Is my syntax wrong here?
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`
> [@hiccup](#):
>
> 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?
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](http://id3.org/Developer%20Information).
Historically there had been two use cases why one would want to use the \_id3 tags:
1. You want to write a specific ID3 frame which is not supported by [Picard’s Tag Mapping](https://picard.musicbrainz.org/docs/mappings/)
2. You want to write a specific `TXXX:` frame
The 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).
> [@hiccup](#):
>
> 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)
`_id3` has some limitations, see the following ticket and my answers:
>
---
### Author:  [@hiccup](https://community.metabrainz.org/u/hiccup)
#### Post date: [September 25, 2018, 8:57am UTC](https://community.metabrainz.org/t/picard-2-0-4-is-available/396815/12 "2018-09-25T08:57:21Z")
> [@outsidecontext](#):
>
> First I would question why you need the `_id3:` style tags at all. What is your use case?
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.
---
### Author:  [@hiccup](https://community.metabrainz.org/u/hiccup)
#### Post date: [October 28, 2018, 6:09am UTC](https://community.metabrainz.org/t/picard-2-0-4-is-available/396815/13 "2018-10-28T06:09:26Z")
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?
---
### Author:  [@outsidecontext](https://community.metabrainz.org/u/outsidecontext)
#### Post date: [October 28, 2018, 6:12am UTC](https://community.metabrainz.org/t/picard-2-0-4-is-available/396815/14 "2018-10-28T06:12:50Z")
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.
---
### Author:  [@hiccup](https://community.metabrainz.org/u/hiccup)
#### Post date: [October 28, 2018, 6:30am UTC](https://community.metabrainz.org/t/picard-2-0-4-is-available/396815/15 "2018-10-28T06:30:08Z")
> [@outsidecontext](#):
>
> 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.
---
### Author:  [@MetaTunes](https://community.metabrainz.org/u/MetaTunes)
#### Post date: [October 28, 2018, 9:34am UTC](https://community.metabrainz.org/t/picard-2-0-4-is-available/396815/16 "2018-10-28T09:34:41Z")
> [@hiccup](#):
>
> 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 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.
> [@hiccup](#):
>
> 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.
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.
---
### Author:  [@outsidecontext](https://community.metabrainz.org/u/outsidecontext)
#### Post date: [October 28, 2018, 10:17am UTC](https://community.metabrainz.org/t/picard-2-0-4-is-available/396815/17 "2018-10-28T10:17:55Z")
> [@hiccup](#):
>
> I didn’t touch ‘restore all defaults’, because I am guessing it resets Picard itself completely?
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.
> [@hiccup](#):
>
> In the case of CE, that doesn’t seem true, since it resets the plugin as a whole, not only the current page.
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.
---
### Author:  [@MetaTunes](https://community.metabrainz.org/u/MetaTunes)
#### Post date: [October 28, 2018, 10:34am UTC](https://community.metabrainz.org/t/picard-2-0-4-is-available/396815/18 "2018-10-28T10:34:17Z")
> [@outsidecontext](#):
>
> the plugin would be able to override the reset behavior,
Is there an API for that?
---
### Author:  [@outsidecontext](https://community.metabrainz.org/u/outsidecontext)
#### Post date: [October 28, 2018, 10:39am UTC](https://community.metabrainz.org/t/picard-2-0-4-is-available/396815/19 "2018-10-28T10:39:03Z")
> [@MetaTunes](#):
>
> 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.
---
### Author:  [@Freso](https://community.metabrainz.org/u/Freso)
#### Post date: [November 5, 2018, 2:32am UTC](https://community.metabrainz.org/t/picard-2-0-4-is-available/396815/20 "2018-11-05T02:32:12Z")
A post was split to a new topic: [Movements saved in TXXX id3v2.4 frames instead of MVNM ones](https://community.metabrainz.org/t/movements-saved-in-txxx-id3v2-4-frames-instead-of-mvnm-ones/404300)