Picard 2.0.2 released! Signed macOS releases!

Go check it out!


In the release note it says:
“with Picard 2.0, Picard Windows builds will be portable standalone binaries.”

So to try it out, I ran it from another partition then where I have my Picard 1.4 installed.
But 2.0 seems to have adopted settings from my 1.4 installation without asking anything, or me doing anything.

So, contrary to what the release notes say, is 2.0 actually not ‘portable’?


We even have a warning about configuration files in the blog post. https://blog.musicbrainz.org/2018/07/19/picard-2-0-released/

By portable, I meant that Picard no longer needs to be installed and can be run as a one off binary.

Apart from warnings further down the road, the notes mention something about Picard 2.0 for Windows from now on being portable.

This is what is considered ‘portable’ software:

“To be considered for inclusion, an application must be executable on multiple computers from removable storage without installation, and without writing settings or data onto a computer’s non-removable storage.”

This Picard 2.0 release is not portable.
It seems to write to the system drive, and it removed settings from my installed Picard 1.4 release.

The description should really be changed to avoid confusion and prevent users misinterpreting what is actually meant here.

(an actual portable version would be great to have b.t.w.)


Quick edit to add - YAAY! for a new version. Keen to try it out…

@hiccup thank you from stopping me making a mistake and breaking my current setup. Totally agree that a “Portable” windows application means one that does not touch anything else on the PC. ESPECIALLY other installations of itself.

Where is Picard 2.0 storing its settings? If a portable app the settings should be ini files sitting next to the exe.

“Portable” means I can carry it on a flash drive, drag it from computer to computer, keeping all settings on the flash drive and leaving zero traces behind on the PCs.

Does this release change the old Picard 1.4 settings in %APPDATA%? I want to try out 2.0, but not change any of my 1.4 setup yet.

1 Like

Updated https://blog.musicbrainz.org/2018/07/21/picard-2-0-1-released-windows-and-macos-users-rejoice/


That’s great.
Is there any chance of releasing a portable version?
That would be very helpful to make it possible to give 2.0 a try without breaking a carefully setup 1.4.

(personally I won’t use an installed version of 2.0 until at least the Classical Extras plugin is updated to be compatible with it)

1 Like

Does that mean that we should UNinstall previous versions before using this one? I noticed it ran right from my downloads folder, and I used the .exe to overwrite the old one in my program files. But it doesn’t need all the extra program files anymore?

Edit: nevermind, I found the installable version now

Any chance of getting this addressed promptly?


The change made breaks functionality that worked in 1.4 (but could be improved even from that)

Can’t seem to install any plugins on 2.0.1. :confused:

finally it’s not constantly crashing any more, nice!!

1 Like

Since it looks like MetaTunes is making nice progress with preparing his plugin for v2, I decided to already jump ship and install 2.0.
Until now it’s running very well indeed, so thanks a lot for all the work that has gone into that.

(It’s not completely clear to me if this thread is strictly for announcing further developments and discussing specific issues, or that more general requests and observations are also welcome here.
So if the following is not considered appropriate for this thread, please let me know.)

One of the ‘user experience’ improvements I was hoping for is this one:

After doing a lookup, Picard will show a large amount of tags in the bottom panel.
It is not clear to see from looking at the tag names under the ‘Tag’ column where those tags came from, and if they are prone to actions/changes.
Some will have been sourced from MusicBrainz, some will be sourced from the files, and some will be both.
Some may have a ‘Preserve this tag’ setting applied, or have an ‘unset’ script active. Others are completely free for Picard to (over)write.

All the above is currently impossible to discern from looking at the first column only.

Also it is not possible (please correct me if I am wrong) to completely exclude specific tags from showing up in Picard.
For example, my files have a lot of custom created tags, and tags related to audio details of the files such as ReplayGain, ripper/encoder used, comments, etc. , that will never be sourced from the database, and have no actual use for Picard.

It would be great if something could be done to improve on the above.
Perhaps by means of colouring or differentiation in font, and by having a filter to prevent specific tags from showing up in Picard at all.

I think this could improve the user experience for Picard quite a lot.

Seeing that @samj1912 ‘liked’ this post, allow me to make my suggestion a bit more specific:

These are some categories of tags that I imagine could deserve some visual distinction in how Picard shows them in the bottom pane.

  1. tag frames that are currently present in the file and are fully protected from writing.
  2. tag frames that are currently present in the file and are protected only from over-writing.
  3. tag frames that are currently not present in the file and were retrieved from MusicBrainz.
  4. tag frames that are set to be hidden. (useful for tags such as ReplayGain tags, encoder, comments, occasion, or any tag the user is not much interested in to see in Picard)
    These ‘hidden’ tags could be completely hidden from view, or perhaps assembled at the bottom of the list and greyed-out.

hiccup, be cautious with 2.0 because there was a change made that breaks the preserve tags functionality for custom tags already in the file in some circumstances (see the ticket I posted above). This makes it hard for me to tag right now because if I’m not watching super closely I will lose my custom tags from MusicBee.


Maybe I am performing some ‘illegal’ action, but Picard hangs at, it so I thought to mention it here.

Suppose you have two very simple scripts:

  1. $unset(album)
  2. $unset(label)
  • Activate (check) only the first script.
  • Load one track from an album, perform ‘Scan’.
  • After the result is displayed in the right panel, drag the recognized track from the right panel back to ‘unclustered files’ in the left panel.
  • Remove the album from the right panel.
  • Deactivate script 1, activate script 2.
  • Reselect the track under ‘unclustered files’, click ‘Scan’.

Nothing happens, Picard keeps saying ‘loading album information’.

1 Like

Thanks for the warning psychoadept!
That’s indeed a very serious and relevant issue to be aware of.
Hopefully it will get addressed before long, and I’ll be sure to keep experimenting with 2.x for a while longer before I let it touch my precious…

Why is this being called “release”? Surely it should be called “beta” as it is clearly not yet feature complete and on a level with v1.4.

It is great to see this - don’t think I am being negative - but reading these posts scare me. Features like not preserving tags and breaking many previous plugins show that this is really Beta territory.

I totally second the request for a portable edition so I can help to test without disrupting the settings for my working v1.4


I can’t speak for the developers, but perhaps I can speak as an observer.

Maybe this is a bit indicative for two worlds colliding at the MusicBrainz universe.
One world inhabited by developers and coders, the other one by regular end-users.

I am sure a lot of work and testing has been going on on Planet #1 for the last six years.
But Planet #2 hasn’t been involved too much with that.

What I think I have been noticing:
When an inhabitant of Planet #2 raises something on this forum, be it a bug, a suggestion or a wish, the reply will often be: “sure, you can raise a ticket for that”.
But that of course is a language and a concept that is not very familiar with inhabitants from Planet #2.

I can understand and appreciate that MusicBrainz has some ‘elitist’ barriers to protect their coders from too much noise from Planet #2.
Some barriers may be forced a bit, some will just be natural.

But MB should then also understand and accept that some of those barriers will hinder popularizing their products and services, and it will also miss out on valuable information and feedback that monkeys testing out machine guns could bring.
(Tesla understands this quite well: “let’s have some fun with humans behind the wheels for a while”)

All kidding aside.
I really feel there is a missing link in the MusicBrainz universe.
Some moderators certainly do their best to mediate on this once in a while, and that is appreciated, but it looks to me that there is nothing structural put in place to gather input from non-coders, create some two-way bridge of communication, and so create a win-win situation for all parties involved.


Picard 2.0.2 released https://blog.musicbrainz.org/2018/07/30/picard-2-0-2-released-signed-macos-builds/


I replicated your steps. Was able to complete the expected action without any problems. Can you post the specific release id or you log instead?