Picard 2.3 Beta 1

Tags: #<Tag:0x00007f00bd3aba50> #<Tag:0x00007f00bd3ab7d0> #<Tag:0x00007f00bd3ab2f8>

A beta release for Picard 2.3 is now available. See the blog post for details on the changes and download information:

Please note also the following discussion about changes to the scripting:


Fantastic. You and your fellow-wizards must have been very busy lately.

Two quick observations:

It looks like ‘originalfilename, TOFN’ is now recognized by Picard, and thus can be excluded from possible deletion.
But I believe three other tags mentioned here are not recognized yet:


Using the WIndows Portable install version (additional thanks and a tip of the hat for that), I noticed that Picard is writing some stuff to: C:\Users\xxxxxx\AppData\Local\Temp

Also when I open Options > Fingerprinting, by default it reads:

It’s not really bothering me, and I am not sure if this could pose an actual problem for some users with limited user-rights, but I thought to mention it.

1 Like

Nope, not done yet. The tickets for that are still open.

That’s due to the packaging we use with PyInstaller. Everything required to run the app is bundled into one executable. For actually running this it needs to be extracted to the temp folder. The data gets removed again when closing the app. Even a user with limited rights should be able to write to a temp dir unless the system is badly misconfigured (at which point the user probably can’t run much anyway).

We can’t really change that from within the app as the data gets extracted before anything Picard related runs. If someone needs to change this a workaround is to set the TMP environment variable to a writeable location. E.g. one could create a batch file picard.bat with the following content and use that to start the portable:

@echo off
set BASEDIR=%~dp0
set TMP=%BASEDIR%\MusicBrainz-Picard\Temp
echo Using temp dir "%TMP%"
if not exist "%TMP%\*" mkdir "%TMP%"

This would use a “Temp” directory inside the data directory the portable app is creating. if running from a USB thumb drive this might be significantly slower to start, though.

1 Like

It seems that my settings were not saved while updating from the latest stable version. Is this intentional?

Also, what will happen if you install Picard from the Windows Store while you already have a traditionally installed Picard? (And what would happen if you install from the installer if you have the Windows Store version installed?)

Settings files are not backed up on updates automatically. It’s intentional in the sense that no backup of settings on update has ever been implemented nor requested. But I think it would be a good idea to move the existing settings to a versioned name on update. E.g. if Picard detects the settings was created by an older version copy that to e.g. Picard-2.2.3.ini.

Both cases are the same. You will have Picard installed twice, with two separate entries in the start menu. One will be installed at the traditional location in C:\Program Files, the other as a store app inside C:\Program Files\WindowsApps (which you can’t easily access directly by default). Apart from that Picard doesn’t care. It’s basically the same as if you would install Picard with the installer twice on different locations.

1 Like

I didn’t really mean a back-up (I should have made one off course), but I’m pretty sure that with previous new Picard versions, the settings were copied over after an update. I now have factory settings again.

1 Like

That hasn’t changed, if you use the installed version or the one from the Windows store it will just use your existing settings. Unless you use the portable version, that will use its separate settings by design.

But I have now started implementing that config backup thing on update because it bothers me that an update can just destroy your existing config and make it impossible to go back to a previous release without loosing the settings :wink:


False alarm, I downloaded the wrong file (MusicBrainz-Picard-2.3.0b1.exe), which is apparently the portable version. I now downloaded and installed the .msix file and have all my old settings back.


Just about to give this a kicking on Windows. Will return with notes.

Quickie question - are there any plans to better handle these HUGE lists of countries that the Digital Media files are now getting? I tagged a Deezer source album just now using Picard 2, and noticed it had been set to Canada and all other countries ignored. The first alphabetical one has been selected.

It would be really handy if we can get some control over this. Personally I’d prefer to select a country from the list (i.e. GB as that is where the band came from). Or have an option to replace a list with Worldwide.

-=-=- Feedback -=-=-

Going well so far. Nothing exploded. Updated and kept settings without trouble.

Maybe worth labelling which install package is which on Github.

Why is “Generate AcoustID fingerprints” hidden on a Right click menu? It there any way of getting that as a menu as part of the SCAN button on the toolbar? Good to see this feature.

Not sure if it is just me, but this seems to be running smoother \ quicker.

1 Like

I have an issue that has appeared, but seems it may be the same in v2.2

We’ll call it the Boxset Boogaloo (using dance moves from Rocky Horror Time Warp)

Qu: Does Lookup use the disc numbers? Is the Cluster aware of disc numbers?

I have an 11 CD set I am trying to match up from MP3 files, and it is a bit of a headache. Especially as it is seven copies of concerts from one 1972 tour. This means track names keep repeating across the disks in the same order.

It is already tagged with correct track titles.

A lookup fails totally to find this release. (Even after I had used MP3TAG to edit the actual Release title in and set all the Track nos and Disc nos. Maybe it didn’t like the colon in the name.)

A scan gets pretty close as it matches seven of the eleven discs up well using AcoustID, but for the rest it matches to other releases.

So now I have one GOOD match on the right with 63/96 files matched. And half a dozen wrong release matches. (Note: Now I have submitted AcoustIDs, this up to 81/96 matches)

Attempts to untangle this lead to a few bits of madness.

Drag everything back to the left and re-cluster. Now try and drag and drop the Cluster onto the Release on the right. Dropping on to Release title. Disc numbers are clearly ignored as now everything matches to CD1 and the first concert! Eeeek!!!

So we have to start again… with a step to the Left… bring everything back to the left again.

Go back and hit that SCAN button again for best matches… and they leap back to the riiiiight.

Now I gather up those miss-matched tracks from the right, re-cluster them.

Turn on the VERY HANDY new columns on the left. (Woo! Yay!! Thanks for that feature :+1: ) Now I can see the track nos and disc nos.

And the only way to get the last files across is drag and drop them one by one in to place.

So, you can see, it would be really handy to have the disc no checked when matching.


Next odd step - why is “copy cluster to clipboard” also not aware of disc numbers? I have 94 tracks here that I want to use to copy track times to MB… but can’t do this due to Copy Cluster to Clipboard also not knowing about disc numbers.

(If a copy is required for testing purposes I could find a way of getting this to you…)


Further notes:

  • Even once fully tagged the “Lookup” still fails totally for this release.
  • Press “Lookup in Browser” and the correct match is at the top of the search list.

Maybe some of the lookup fails as the MB database has no track times at all at this moment.

Options > User Interface > Top Tags

A great addition!

In the settings under “User interface” (or whatever it is in English), there should be a “Customize Action Toolbar” where you can… customise the toolbar.


I feel there isn’t enough of an uproar…

  • It is now possible to customize the columns in the main panel…
  • The new “Generate AcoustID fingerprints” action allows you to just generate the fingerprints without doing a search and match…
  • The Scripting options have been reworked to be more consistent and easier to use…
  • We addressed some cases where the Picard user interface became totally unresponsive…
  • and more…

And the crowd goes wild


Oh yeah, this is a great update. I’ve been preoccupied with some other things, but I can’t wait to test out the support for custom tags in M4A, and excluding certain tags from completeness checks.


It would help if you could tell us which release it is :smiley:

Indeed the matching of files to tracks currently does not consider the disc number :frowning: I’ll fix this, see PICARD-1723. Could you give the portable build from https://github.com/metabrainz/picard/actions/runs/34111621 a test run with your files? Which release is it, btw?

Because the tracks2clipboard plugin does not have this implemented. A lot of the plugins solve some small specific issue someone had. Obviously this was not something the author cared about. I filed an issue for this on https://github.com/metabrainz/picard-plugins/issues/251

Because it is a very special action which does not really have much utility on it’s own unless someone wants to submit to AcoustId. Which you all should do of course, but it also needs some knowledge on what you are doing and some care taken to have properly matched files. It does not make sense to expose a secondary option like this by default in the toolbar, which already is very crowded. But as freso said you can configure the toolbar to include this.

Picard in general? We had some performance improvements. Or do you mean the “Generate AcoustID fingerprints” in comparisson to “Scan”? That should be no surprise, it only does a fracture of what Scan is doing :smiley:


Please do :slight_smile: Especially changes like M4A custom tags is why we did put out a beta first. That’s a quite significant change to how tags are handled there.


Thanks. Should be enabled by default? That is a little too hidden for something so useful. Big time saver on a boxset or a compilation.

What I was actually thinking about is how a button can sometimes be implemented as a menu too. So a normal press on the button gets “scan and shuffle to right” but a press of the corner of the button would get the related actions.

There should be dancing in the streets… :partying_face: And big thanks to the work the devs put in.

1 Like

The beta - v2.3.0b1. As per thread title. Did a brief compare in v2.2.3 to confirm it was an old issue, but then the rest of the notes are from the current Beta.

Later today I’ll grab your portable test build a run though on that package. I have kept a copy with the original basic tags in it. The release is this one: https://musicbrainz.org/release/81e3c9e6-46af-4cb2-9cf2-fb53d8ba0aa5 (Still open edits on it as I am updating it as I go along)

Maybe it was getting to play with a shiny new thing, but it just seemed to work all so well.

Nice work guys :partying_face: I will continue to try and break it during the coming days.

And agree with others above - needs more shouting about the new features \ columns \ etc. When I started to get tangled up with these 94 files not matching it made it much easier being able to turn on those Track No and Disc No columns on the left.

1 Like

Can you give some more details how this fails? Does it load nothing or the wrong release? Are you looking up a cluster or individual files? In case of cluster lookup: What are the tags album and albumartist set to? Do you have all the 96 files in the cluster?

If you get not results at all, look at Options > Advanced > Matching and see if lowering the threshold for cluster lookups helps (and let me know how far you have to turn this down).