Improvements to Picard's cover art handling

Today I realised that Picard by default will both retrieve artwork, and embed it into the user’s files.
Is that a good idea?

(give-away: I don’t think it is :wink: )

1 Like

I think for the basic user (the kind who might not look into the settings), this is ideal. no need to mess with external images, and it automagically gets you cover art too~ :magic_wand:

2 Likes

I agree with @hiccup , changing to embedding art by default is too much of a change to the files.

This is one of those you either like embedding or not choices really :slightly_smiling_face:

I’ll not change defaults for the 2.10 release, especially as we want to release in the next days and I don’t want to introduce a change to defaults on short notice between the RC release and the final version. We can consider this for a future version.

For Picard 3 we can in general see to change defaults to a larger degree. Ideally combined with a configuration wizard that let’s new users choose things like cover art saving. @aerozol had some initial talk about this yesterday and we’ll come up with a proposal for this.

3 Likes

Not only that,
A user could have carefully selected artwork embedded in his files, and Picard will overwrite them without clear notice.
So in a sense this default setting allows for deleting data that may be valuable to a user.
I think that’s a bad thing.

1 Like

By default Picard does not even save tags at all. But that is also something I think we should change and saving tags should be the default.

I’ve always liked the “need to actively turn it on”. Sometimes I’ll run Picard on a different PC, or grab a standalone to do something. Nicer to turn on what you need, instead of having to remember to turn things off. Especially artwork, as getting a 40MB PNG stuffed into a music file isn’t always my first choice. :smile:

This makes sense. A wizard to let people know this can be done, but by default sticking to a “no change” option.

2 Likes

Weren’t there performance problems too, files getting fully rewritten for lack of padding?
Also the cover art changes don’t always seem very obvious. Text tags are more obvious and have color highlighting too.

There is room for improvement:


Is the cover being shown the existing one or from MusicBrainz? (Hint: the selected release has no cover embedded)

cover details Frank_Beat-Braindead-(DSRD673X)-WEB-2023-PTC


However, many of my files come with cover art in optimal resolution (IMO) embedded. I wouldn’t expect them to be overwritten by an inferior (smaller) version or an even larger one.

For example, this selected release comes with cover art embedded:

But only when I “show more details” the actual change becomes apparent:

cover details LSDXOXO-Delusions_Of_Grandeur_(D.O.G.)_EP-WEB-2023-BABAS

1200px would take 497kB, too much IMO but up to 200kB for 700-1000px is okay for me.
Ideally it would be JPEG XL, no quality loss but down to 97kB with jpegxl.io
264kB for the 1200px CAA version
30kB for the 500px CAA version

For reference the original file is 12.3MB JPEG or 2MB in JPEG XL


The context menu for the cover art section offers:

cover context menu

What does “Append front cover art” do? After saving, the existing image is gone and replaced by the smaller version from CAA

It seems that setting affects “choose local file” but once I do there seems no way to undo the selected file. If I “keep original cover art” it sticks and can seemingly only undo by reloading the release.

3 Likes

I moved this discussion into a separate thread.

It’s generally well known that there is a lot room for improvement on cover art. We have a couple of tickets for this already.

A notable ticket is https://tickets.metabrainz.org/browse/PICARD-2121 together with the related tickets linked there. This would really give a lot of flexibility to better control which cover art to use.

If you have additional notes or suggestions it would be great if you could add them to relevant tickets or create new tickets if you think it is not yet covered by the existing ones.

This setting changes how cover art you manually add to a file or track is handled. If “Append” is selected it gets added in addition to existing cover art, with “Replace” it replaces all the cover art.

That’s essentially the same as the “use original value” for other tags: It clears the newly set cover art and thus uses the original again. You have this option as soon as you see both “new” and “original” cover art displayed. It’s a one time action.

4 Likes

I don’t think I see a ticket for this. What about an option for different settings for embedded and external cover art images? So I could have a nice high resolution single image(I’d like to be able to do up to 3000px personally, as that’s pretty standard from Apple) in each album folder saved, but don’t waste 5MB on every track in the album and rather just have those set to a smaller size(I’d still like embedded as well not one or the other).

1 Like

Yes, please create a ticket for this as well :slight_smile:

I’m pretty bad at JIRA, hope I did this right [PICARD-2783] Provide separate options for embedded and external cover art - MetaBrainz JIRA

2 Likes