# Sort out unwanted covers
**URL:** https://community.mp3tag.de/t/sort-out-unwanted-covers/57297
**Category:** Support
**Created:** [May 14, 2022, 5:18am UTC](https://community.mp3tag.de/t/sort-out-unwanted-covers/57297 "2022-05-14T05:18:56Z")
**Posts on this page:** 17
**Page:** 1
### Author:  [@Roland](https://community.mp3tag.de/u/Roland)
#### Post date: [May 14, 2022, 5:18am UTC](https://community.mp3tag.de/t/sort-out-unwanted-covers/57297/1 "2022-05-14T05:18:56Z")
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?
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [May 14, 2022, 6:03am UTC](https://community.mp3tag.de/t/sort-out-unwanted-covers/57297/2 "2022-05-14T06:03:43Z")
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.
---
### Author:  [@Roland](https://community.mp3tag.de/u/Roland)
#### Post date: [May 14, 2022, 7:22am UTC](https://community.mp3tag.de/t/sort-out-unwanted-covers/57297/3 "2022-05-14T07:22:58Z")
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?
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [May 14, 2022, 7:31am UTC](https://community.mp3tag.de/t/sort-out-unwanted-covers/57297/4 "2022-05-14T07:31:48Z")
see the help on property variables for covers:
> **[Format Strings and Placeholders – Mp3tag Documentation](https://docs.mp3tag.de/format/)**
>
> Documentation on format strings and placeholders to describe the structure of file names and imported data. Mp3tag is the universal Tag Editor.
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.
---
### Author:  [@Roland](https://community.mp3tag.de/u/Roland)
#### Post date: [May 14, 2022, 7:42am UTC](https://community.mp3tag.de/t/sort-out-unwanted-covers/57297/5 "2022-05-14T07:42:24Z")
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.
---
### Author:  [@LyricsLover](https://community.mp3tag.de/u/LyricsLover)
#### Post date: [May 14, 2022, 8:04am UTC](https://community.mp3tag.de/t/sort-out-unwanted-covers/57297/6 "2022-05-14T08:04:23Z")
> [@Roland](#):
>
> I want to create an action to make sure that
> only one square cover with at least 500x500 remains embedded.
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.
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [May 14, 2022, 8:16am UTC](https://community.mp3tag.de/t/sort-out-unwanted-covers/57297/7 "2022-05-14T08:16:38Z")
> [@LyricsLover](#):
>
> matching front cover and not a back cover
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.
---
### Author:  [@Roland](https://community.mp3tag.de/u/Roland)
#### Post date: [May 14, 2022, 9:19am UTC](https://community.mp3tag.de/t/sort-out-unwanted-covers/57297/8 "2022-05-14T09:19:14Z")
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.
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [May 14, 2022, 10:38am UTC](https://community.mp3tag.de/t/sort-out-unwanted-covers/57297/9 "2022-05-14T10:38:38Z")
> [@Roland](#):
>
> if half of the work would be done automatically
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.
---
### Author:  [@Roland](https://community.mp3tag.de/u/Roland)
#### Post date: [May 15, 2022, 7:34am UTC](https://community.mp3tag.de/t/sort-out-unwanted-covers/57297/10 "2022-05-15T07:34:51Z")
> [@ohrenkino](#):
>
> $num(%\_cover\_width%,4) x $num(%\_cover\_height%,4)
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?
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [May 15, 2022, 7:41am UTC](https://community.mp3tag.de/t/sort-out-unwanted-covers/57297/11 "2022-05-15T07:41:20Z")
> [@Roland](#):
>
> 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.
---
### Author:  [@Roland](https://community.mp3tag.de/u/Roland)
#### Post date: [May 15, 2022, 8:01am UTC](https://community.mp3tag.de/t/sort-out-unwanted-covers/57297/12 "2022-05-15T08:01:19Z")
Don't worry.
But isn't there way using the $meta(x,y) function?
I've tried it but failed again.
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [May 15, 2022, 8:04am UTC](https://community.mp3tag.de/t/sort-out-unwanted-covers/57297/13 "2022-05-15T08:04:23Z")
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:
> [@Export properties of current embedded cover (incl. dimensions)](https://community.mp3tag.de/t/export-properties-of-current-embedded-cover-incl-dimensions/57307):
>
> I would like to see that when exporting an embedded picture to file with the action of the type "Export cover to file" that all the properties are taken from the current picture - and not just from the first. So, e.g. if a cover file name is defined as %album%\_%\_cover\_type%\_%\_cover\_width%x%\_cover\_height% and there are embedded picture with the property front: 600\*539 and back: 840\*472 then the resulting filenames for the picture are: My Album\_Front Cover\_600x536 My Album\_Back Cover\_600x…
---
### Author:  [@Roland](https://community.mp3tag.de/u/Roland)
#### Post date: [May 15, 2022, 9:35am UTC](https://community.mp3tag.de/t/sort-out-unwanted-covers/57297/14 "2022-05-15T09:35:59Z")
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?
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [May 16, 2022, 1:02pm UTC](https://community.mp3tag.de/t/sort-out-unwanted-covers/57297/15 "2022-05-16T13:02:40Z")
> [@Roland](#):
>
> When do you estimate there will be a response to this request?
This has been
> [@Export properties of current embedded cover (incl. dimensions)](https://community.mp3tag.de/t/export-properties-of-current-embedded-cover-incl-dimensions/57307/3):
>
> added this with [Mp3tag v3.14k](https://community.mp3tag.de/t/455).
(so the response time was just 2 days. Amazingly short, I think.)
---
### Author:  [@Roland](https://community.mp3tag.de/u/Roland)
#### Post date: [May 16, 2022, 2:30pm UTC](https://community.mp3tag.de/t/sort-out-unwanted-covers/57297/16 "2022-05-16T14:30:46Z")
Yes that's true: amazing fast realization of the function 🫠 🤗
---
### Author:  [@system](https://community.mp3tag.de/u/system)
#### Post date: [February 9, 2026, 12:29pm UTC](https://community.mp3tag.de/t/sort-out-unwanted-covers/57297/17 "2026-02-09T12:29:46Z")