Picard 2.8 Release Candidate

We have released Picard 2.8rc1, please see the blog post for details:


I’m currently using Picard 2.8rc1 beta release, 64-bit portable as portable version on Windows 10.

The “Submit AcoustIDs”-Button
doesn’t turn to colored and activated, no matter what I try to do.

What I have checked:
a) I have entered my API key in Fingerprinting options
b) I tried to “Generate Acoustid Fingerprints” from the right-click context menu
(what is usually not necessary because they are already included in my files.)

The same files activate the above button in the current stable and installed Picard version v2.7.3 automatically without any user interaction.

I think this might be because of PICARD-2420.

Previously when you loaded a file which contained the fingerprint in the tags and had an existing MBID, Picard would load the corresponding release, attach the file and directly enable the submission. I disabled that so that this situation behaves like when you use scan and Picard finds a match it doesn’t mark this combination for submission. I thought when one had already done the fingerprinting earlier they would not need / want to resubmit every time they load the file.

But as I understand in your case you have probably precalculated the fingerprints elsewhise and then you want to use Picard to submit them, right?

I think we should just revert that change for release 2.8 then.

Exactly. If I see all my tracks from an album with a golden CD

and all tracks with a green check mark

then I usually hit “Submit AcoustIDs”

How would I do that in your new situation?

If this prevent wrong submissions, could you check if the above situation with fully matched tracks from an album is reached and then activate the button?

I don’t think that’s a good idea. People do not always have full albums, or might just retag a few files from an album.

The intention behind this change was also never to prevent bad submission. On the opposite, the assumption was that if a file has both a recording ID and a fingerprint this probably was already submitted, so no need to trigger the submission again. Obviously this assumption is wrong in cases like yours, where you pre-calculate but not submit the fingerprints.


We just released another candidate.


Thanks for PICARD-2474.

Works fine now with “2.8.0rc2 beta release, 64-bit portable”.


Hey, could this bug be fixed in 2.8…?

This is in fact a HIGH PRIORITY BUG, so I don’t know why it was downgraded to “Normal”.
It changes peoples data in the music file that it’s not supposed to be touching etc.


No, that won’t be in 2.8, we won’t add any new functionality before that release.

The priority of that ticket was lowered because it actually touched multiple separate issues and what is left comes down to a feature enhancement:

  • Picard did reset the cover art type to “other” for unsupported types. This has been fixed in Picard 2.7 with PICARD-2311
  • The sort order of images after saving is not preserved. This is tracked in PICARD-1696. But that’s actually intentional behavior in mutagen and would need to be fixed there. This is still open.
  • Have some option to keep existing images. This basically comes down to a new feature, of which I’m honestly not quite sure how it should behave.

In the report it becomes clear that you have configured Picard to only embed a single image, and that’s what it does. But you also want it to keep other images. There are multiple possibly solutions to this, not sure which actually meets your expectations:

  • Have an option to instruct to only replace the images of the files it saves, but keep images of other types intact. So if Picard e.g. would save front and back cover images, it would replace all existing front and back images, but it would keep existing images of other types, e.g. medium or artist.
  • Make it easier to disable embedding images into tags, so you can temporarily turn this off
  • Maybe disable changing images per file, so you can disable it just for certain files before saving

In general Picard should also better indicate what happens to which image, e g. if it gets saved to tags, saved as file or nothing at all.


I don’t know how to tick the box to say “Translations up to date”. English (UK)(Aus)(Can) all updated as far as I can see… I still check these and keep them up to date.


Don’t worry, translations will be synced again before next release regardless. And thanks for keeping an eye on that :slight_smile: