Picard 2.3 Beta 1

MusicBrainz Picard
, ,
21

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”
image
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)
image
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)

22

Trivial issue. You forgot the capital F on Fingerprints
image

23

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

2 Likes
24

These are not clickable for me

image
image770×280 10.7 KB

I assume this is because I am not logged in?

25

Ah, sorry. I did not notice those downloads require permissions. That’s a bit stupid, makes it more difficult for me to share a specific fixed build with you :frowning:

2 Likes
26

That does make sense. I have had those same settings for a few years back to v1.x, old values make sense. Currently the are 70%, 70%, 40%. A “Reset to Default” could be handy. Though I also think that anyone with it set at 80% will have an old value that could be changed to current defaults. I bet my 70 \ 80 \ 40 are just old default and would be a set of values to just correct to modern defaults if spotted by the installer?.

Old habits. MP3TAG gives me that “big view” making it quicker to edit full screen. Now more work has happened on the left in this Picard release I’ll be looking closer.

Currently I used MP3TAG to mess with specific tags, and Picard to bring in data from MusicBrainz to enhance my files.

Trying to find clever ways to get text to fit toolbars is always a headache. And once you fix it in English, you then find the German word for it is 50 characters long and messes up all that careful formatting…

You have “Submit AcoustID” so why not just “Generate AcoustID” and drop the fingerprints text? You have a good tooltip that includes “fingerprints” and explanation.

Not too bad. Most Things Are Capitalised in a Sensible Way due to your habit of editing to MB Guidelines :wink:

27

If the Beta can get a public share, must be somewhere to get those public too. I am sure I have seen this with other projects…

28

There is a reset default button on all option pages, including this one. I just used it here to see the defaults. The new default is 70, 70, 40. Previously up to Picard 2.2.3 it was 70, 80, 40.

2 Likes
29

I always assumed that button was to reset ALL settings to default and not just the one page. It is sitting with the MAKE IT SO, APPLY and CANCEL buttons which all work with ALL pages.

Doh! Just looked at Picard and see there are TWO default buttons down there. (And no APPLY) And there is even a sensible pop-up message that makes it clear that resetting just the one page. Yay!

Well done for using the Time Machine to jump back and implement features after they have been asked for. Either that or I am just daft and never noticed it before. :sunglasses: :joy:

Ah- so it is only these new Betas that are 70, 70, 40? In that case I would suggest a test in the installer to look for 70, 80, 40 and tweak it down to the new normal 70, 70, 40 as most users will never go into Advanced settings as they are scared of dragons.

30

@outsidecontext THIS POST IS GETTING UPDATED AS TESTING EXPANDS

A new issue. NOTHING tells you when a task is in progress. That means you accidentally interrupt a task without being aware. And can loose AcoustIDs that you thought you were generating.

Example. That boxset has 94 files. (Yeah - I know I am evil :japanese_ogre:when testing… but that’s what ya need to kick out edge cases)

  • Drop all 94 into left side and make cluster.
  • Now press “Generate AcoustID” button
  • 5 seconds later press Lookup button
  • Now we find a match, files jump to the riiiiiight and sync up while artwork downloads.

BUT… the AcoustIDs never finished generating and got abandoned half way down the list.

How do I know? Because I turned on the new column on the RIGHT to see Fingerprint status. And can see it had got only half way down and then they have been abandoned.

Qu: Why did it stop? and why is there nothing that tells me work is happening? This is what a Status Bar is for. Certainly don’t abort what I thought was a task that would run to completion.

-=-=-=

Second issue: When I look a the list of new columns on the Context Menu for selection it says “Fingerprint status”. This should say “AcoustID Status” to stay consistent with the toolbar, menu and other places that this is referred to.

And I just spotted I need to go do some translation - there is a Catalog No. in that menu too… I need to update the English (not US) translations. Edit: Now fixed: UK, Aus, Can are back to Catalogue No.

-=-=-

Talking of progress bars - when hitting the SAVE button things are odd. These flac files are taking longer to tag today. But nothing in the PROGRAM says this. Only the little task bar icon. As I have 94 files here I can’t see them getting their ticks in the right hand window as that scrolled out of sight a while ago.

SUGGESTIONS - the SAVE button should stay popped out \ coloured while it has something to save \ is saving then go back grey when completed. Just like “Submit AcoustID” does. When nothing to save it should be grey.

(v2.2 also keeps the save button “lit up” all the time that files are selected, even if there are no changes to save)

A progress bar should also appear on the app’s Status Bar while this is going (just like your mail client, etc does) Let the user know the app is working.

Similar can then be done with the Generate AcoustID button - leave pressed down and grey while it is in progress, pop a progress bar on the status bar to show it is happening.

I’d also like to see something down there when artwork is downloading… but now I getting greedy.

Lack of Feedback that “something is happening” is a puzzle in Picard. And noobs will trip over this even more often. The taskbar button is great - but the App itself needs to also be clear it is working on a task.

31

That’s great also.

But it’s not beyond me to looking a gifted horse in the mouth:

A suggestion/request; when activated, the Track Number will be positioned at the end or somewhere in the middle.
Perhaps it would be more natural to have it displayed at the beginning in-between Title and Length?

fuggedabout it, draggin and droppin it is…

1 Like
32

The columns can be dragged and dropped into the order you require… (or at least it does on Windoze version I am testing). Standard OS GUI behaviour.

The only column that doesn’t move is “Title” that stays locked in first position.

1 Like
33

Thanx Ivan, lazy me.
I have been Pavloved by another application where you can drag the entries up and down in the settings menu.
When that didn’t work my brain just stopped.

1 Like
34

So you wanted your cake AND eat it? :laughing:

35

I prefer having a whisky and drink it :wink:

2 Likes
36

Not heard of Pavlov whisky before? Just her cakes.

37
2 Likes
38

Always need good cakes when testing software.

2 Likes
39

Another bug undocumented feature

I keep coming back to this AcoustID thing as there is clearly something weird here.

Generate AcoustID data is not being saved.

I have just loaded my tagged FLAC files back up and can’t find the AcoustID data.

I look online and it is also not there in the Release in MB - even though I have submitted it a few times now.

Maybe I am going mad, so we’ll try again slowly…

  • I have my Tagged by Picard files. All 94 of them.

  • Quick independent check in MP3TAG and I see MBIDs and other data, but not AcoustID. Weird.

  • Start Picard, drag folder of all 94 files in, they automatically jump to the right due to the MBIDs

  • And the “Thumbprint status” column is empty. Weird.

  • Drag to the left, recluster, press Generate AcoustID

  • Wait and watch all 94 tracks get their little thumb logo in the new column…

  • Drag cluster back to the right. See all 94/96 light up again. All with little thumbs in the columns.

  • BUT look at the bottom pane with the before\after tag data. Fail to find AcoustID listed at all!

  • Press Submit AcoustID (thumbs now change red to grey)

  • Press SAVE

  • Still no AcoustID showing in that lower pane.

  • Still have thumbs next to all the tracks, but no way to see my AcoustID.

  • Double check in MP3TAG - and no AcoustIDs are being written to the files.

  • Fire up Picard again, drop files in, Drag to the left, now try the old method of SCAN

  • NOW we have the new AcoustID data appearing in the bottom pane.

  • Hitting SAVE now correctly writes the data to the files.

  • Now close and reopen Picard and the AcoustIDs are shown

  • The old method is still good.

Assumption is that when hitting Generate AcoustID this data is not correctly being copied to the lower pane/data structure. So it is not there when I hit Save. Therefore never making it to the files.

I also notice when the files are on the left and I hit Generate AcoustID I see nothing change in the bottom pane. The separate icons light up as each are generated in the list, but it feels as if the actual value is not getting stored\displayed.

When I hit SCAN i see the bottom pane add an AcoustID field for each track in turn…

Okay, getting a bit tired now, but maybe another point to help narrow this down.

Edit: There is another timing issue here. So this really needs LONG lists of fat flacs to get time to see it happen while tracks move left to right.

Tagged files with no AcoustIDs ready to go on left side.

Cursor on left side, highlight the release. When I hit SCAN I get no AcoustIDs displayed in the bottom pane.

Click over to the right pane and it shows the AcoustIDs.

Click back to the left, no AcoustIDs being displayed. The bottom pane shrinks and removes the row.

I am clicking back and forth while the tracks are still being scanned and matched. The AcoustID row appears and hides depending on the side I am on.

Once all the tracks are scanned and moved to the right, I can then drag them back to the left and NOW they all show their AcoustIDs on the left.

Sorry, I’ll turn the computer off now before I break anything else.

40

Sorry, I’m just a bit of an awkward tester - got another oddity caused by the large 94 file package. :hammer:

It is possible to LOOSE files from the interface and my pack of 94 shrunk.

This is all about being impatient and not having a stop action button. I know I am dragging stuff around while work is in progress. That is the point here. :wink:

  • Open Picard.
  • Throw 94 files release in that has MBIDs already tagged
  • They jump to the right and start downloading the 8 items of JPG artwork for the Release (I always download all available art)
  • I quickly grab the folder of Unmatched Files and throw it back to the left into Unclusterd while Picard is still downloading image files (important step) .
  • Files start reappearing under unclustered files as all 94 slowly get written down the page…
  • …but that list never gets to the bottom because…
  • Suddenly the artwork has finished downloading and the files jump back to the right. (I assume it is completing the “match the files” step from the initial shuffle to the right.)
  • But what has happened?
  • Eeek! now I only have 62 files and can’t work out where the rest have gone. LOL

Second repeat run of this test I only ended up with 4 files. :rofl:

A few more runs and I have worked out what happens. I think the trick to trip the bug is to still have the files moving from right (unmatched files) to left (unclustered files) at the moment the art stops downloading.

If the files are still reappearing on the left, building the list, at the exact moment they are then called back to the right. Crunch - files lost in limbo somewhere.

Yeah, I know I am giving the code a kicking. But you wanted proper tests. 11 disc box set tests of evilness. Mwahahahahahaha…

To reproduce have a LONG list of flac files in the release, and lots of artwork to download.

The artwork has to finish downloading while the list on the left is still being slowly written. I expect you can get the timing even better if you have loads of columns enabled on the left.

(tip - Tori Amos has some HUGE images at 20MB per image. Good for this kind of test. There are also some huge Pink Floyd boxsets like the Discovery compilation box with tons of files and artwork. It will be tricky to get the timings correct as you have different network speeds, etc…)

And I have seen this issue appear in v2.2xx. I never really worked out why I could sometime loose files when moving right to left, but I think this could be part of it. Timing issues caused by images still downloading on the right when I am dragging back to the left. I trigger this more often due to by tendency of getting all artwork.

BTW - my testing is only helping you get perfection. I know you guys have worked hard on many areas of this program and it shows. I’m only trying to kick out a few unknown bugs. The laughing is due to enjoying helping out by finding weird things… There is clearly lots of good new stuff in this release. Thanks for that

1 Like