Sort out unwanted covers

A large number of my albums have 2 to 4 embedded covers.
Some of them are not square, some are smaller than 500x500.
I want to create an action to make sure that
only one square cover with at least 500x500 remains embedded.
Has anyone already solved this task?

MP3tag shows the properties of the first embedded picture.
You can filter for the number of embedded pictures with %_covers%.

You cannot delete a specific embedded picture.

So the only way I see is to export all embedded pictures to a filename that also features the dimensions and use the search function of the file system to delete all files that should not get imported.

Just a note: CDs shipped in digipaks usually do not have a square picture but one slightly rectangular.

Thanks for the suggestion.
Suppose there are 3 covers embedded:

  1. 498x505
  2. 300x300
  3. 800x800
    How do I achieve that after an export with naming according to dimensions
    only the image with the name 800x800.JPG will be imported?

see the help on property variables for covers:

so,

Variable Description
%_cover_height% Cover height of first cover art in the tag of the file in pixels
%_cover_width% Cover width of first cover art in the tag of the file in pixels

would probably help.
The import will be a little more tricky as you don't know which dimensions are the largest, so the wildcards will probably not work to pick to right one.
You would have to delete all the unwanted ones in the explorer and then import the only leftover picture from that folder.

I know about the documentation of these variables.
To delete the unwanted images after an export manually in a file manager
seems to me also because of the intermediate step even more complex than to delete the covers directly in MP3TAG manually.
The work with some hundred albums I would have facilitated gladly.
Nevertheless, my thanks to you ohrenkino.
Maybe I'll find another workaround.

How can you be sure that an action will pick the matching front cover and not a back cover or any other (unwanted) cover art only by it's size?
This would only work if all your covers would be the same front cover picture - only in different dimensions.

You could avoid that if you add the %_cover_type% to the export filename mask which in return would require that the embedded pictures are properly categorized as front, back, inlet, booklet etc.
If these categories would be missing and all the pictures are of the type "front" then it would be down to the visual check.

You're right.
According to this, the type of an image, if not specified by a name or parameter, can only be categorized manually.
I would be happy if half of the work would be done automatically. The parameters exists.
As ohrenkino mentioned, the rest of the corrections have to be done manually.

If you have at least 2 embedded pictures of the same type but with different dimension and you export the dimensions with $num(%_cover_width%,4) x $num(%_cover_height%,4), then I would assume that an import like
%album%_%front%_3*.jpg
would import all the files with 3xyz pixels width.
then
%album%_front cover_2*.jpg
then
%album%_front cover_1*.jpg
and then
%album%_front cover_?9??.jpg
all those with 900 pixels.
Go on like that for the next 4 numbers. I would assume that files below 500x500 would not be worthwhile to treat. or could be imported anyway.

This doesn't work as expected.
Only the dimensions of the first cover are used.
So it creates the files 0498x505.jpg and 0498x505(1).jpg and 0498x505(2).jpg.
What's wrong?

I had hoped that the description would not be accurate - but unfortunately, it is.
You really only get the dimensions of the first picture but not those of the current one.
Sorry, to have wasted your time with a dysfunctional approach.

Don't worry.
But isn't there way using the $meta(x,y) function?
I've tried it but failed again.

Embedded pictures are different, I think. So $meta() does not work.
I see your use case and also the inconsistency in behaviour that the _COVER_TYPE is updated for each picture but other properties aren't.
I wrote a feature request:

Thank you for the feature request.
Please let me know if there are effects to be discussed.
When do you estimate there will be a response to this request?

This has been

(so the response time was just 2 days. Amazingly short, I think.)

2 Likes

Yes that's true: amazing fast realization of the function :melting_face: :hugs: