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.
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.
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 
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.
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 
) 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:
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…
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 
Indeed the matching of files to tracks currently does not consider the disc number 
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 tracks2clipboard should consider disc number · Issue #251 · metabrainz/picard-plugins · GitHub
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
Please do 
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… 
And big thanks to the work the devs put in.
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 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.
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).
How do I get a usable executable from that page?
I click on “package-windows (portabl…” in the left hand side, lots of ticks appear next to works… but nothing I can download.
The following is therefore done with the Beta v2.3b1
The Lookup literally does NOTHING. Click button, status bar says can’t find it.
I have gone back to a raw set of files again. These have only basic tags filled in. No MBIDs. No disc numbers. And there are two files missing so I have 94 of the 96 tracks numbered 1 to 94. Everything has perfect track names with only Capitals Different.
Drag whole folder into left hand side from the desktop - it gathers in Unclustered Files
Click CLUSTER and they all come together
I look at titles and I see “album = A Trip to the Moon” and “Album Artist = Pink Floyd”
With my cursor highlighting the cluster…
Click LOOKUP and it says in the status bar “No Matching Release for A Trip to the Moon”
Click LOOKUP IN BROWSER and there at the top of the list is the correct choice.
Now lets modify that title to improve lookup chance - adjust the title to what is in the database. I do this by closing Picard, then drop the whole lot into MP3TAG and change just the title to exact match of he MB database. Now back to Picard and repeat the above steps (with tracks still currently numbered 1 to 94)
Notice the status bar in that image? Exact same result as with half the title.
Notice that image also shows you ALL the tags that are filled in.
Next, experiment with lowering the CLUSTER matching as requested. Currently at (default?) of 80%. First test I went to 60% and now it is (almost) bang on with just the one release match. Juggle setting and I find 75% fails but 70% succeeds.
Note: There are slight oddities with my files. The version in MB is from the CD package and has the true 96 files listed. My copy is missing two files, so I only have 94 of 96 files.
When the cluster match was tweaked to 70% I am getting almost perfect alignment of those 94 files with their correct slots in the list. Only ONE has been incorrectly linked. (Track 9-08 was lined up to 6-01 but then they are the same name and identical times)
Also note - this is the raw files again. So these are numbered 1 to 94 and no discnumber info. And the match has worked very well all bar that one single file in the wrong place.
-=-=-
I may also have now slightly twisted the test as this morning I did add all the missing track times to this Release in MB which I guess is also now aiding matching.
EDIT: just to add, dropping that Cluster Match to 70% also means that a SCAN is now as good as it can get. 94 of 96 files correctly matched. No other releases being shown on the page. Yesterday I’d have six different releases on the right hand side.
(But this is also going to be aided by my having added AcoustID and track times to that Release on MB now)
Trivial issue. You forgot the capital F on Fingerprints
In the center below artifacts there are downloads. One is windows-portable. The download will be a ZIP file which contains the actual portable exe.
Current default is 70%. It used to be higher, but we reduced the default for cluster lookup in this release because we fixed cluster lookup to properly respect the preferred release types (and that causes it to have lower average scores by default). So your findings sound about correct. Also cluster lookup really is taking total number of tracks into account, so having a mismatch of files and total number of tracks negatively affects the matching score.
I did some testing with an artifical cluster for this release. And with album = “A Trip to the Moon: The Early 1972 UK Concerts”, albumartist = “Pink Floyd” and exactly 96 tracks I get a match score of 87%, with mismatching track count only 80%. As this also depends on your preferred releases settings the exact values might differ. With a shortened title of only “A Trip to the Moon” things get worse (74% and 69%).
Actually this works very well as expected, but it shows the old default threshold of 80% is wrong. Maybe we should automatically downgrade the matching threshold on upgrade if it is the default. Most users will not have changed this.
Why not do it directly in Picard? Changing these tags is a great way to improve the lookup search. I usually just click on the cluster and edit album and albumartist directly. No need to save it even, just adjust it for the search.
Thanks, will change it. Picard’s English capitalization is a bit messy (random?). Btw, that label is too long for the toolbar. I’m looking for a way to cleanly fix this. Unfortunately this seems to be not possible without duplicating a lot of code
