Picard 2.0.4 is available


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 :slight_smile:


Ooops, thanks for noticing the bad link, fixed :wink:


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 :smiley:

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:

  1. You want to write a specific ID3 frame which is not supported by Picard’s Tag Mapping
  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).

_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.