# Request: Column for cover image dimensions
**URL:** https://community.mp3tag.de/t/request-column-for-cover-image-dimensions/41243
**Category:** General Discussion
**Created:** [March 29, 2018, 4:06pm UTC](https://community.mp3tag.de/t/request-column-for-cover-image-dimensions/41243 "2018-03-29T16:06:22Z")
**Posts on this page:** 7
**Page:** 2
### Author:  [@incifinci](https://community.mp3tag.de/u/incifinci)
#### Post date: [April 10, 2018, 12:33pm UTC](https://community.mp3tag.de/t/request-column-for-cover-image-dimensions/41243/23 "2018-04-10T12:33:40Z")
Thank you too, Florian, for this nice feature.
Sorry, I expected trouble. I loaded the whole library (25 thousands files) into Mp3tag. In a newly created columns %\_cover\_width% and %\_cover\_height% **the table shows only partially the value**. If I select the erronous lines, it immediately shows those values.
Moreover: Mp3tag at some records does not show **any** cover image info (23rd line on an uplodead image).
The more regrettable: **Mp3tag does not use the missing dimension values at filtering and other functions**. I did a filter:
`%_extension% IS mp3 AND "$ifgreater(%_cover_height%,850,1,)" IS 1`
Mp3 tag shows only records, where it already read the dimensions data.
Error with the other function, by calculations: look at the line No. 23! Missing all cover image values. And the column "Fölös" (mean "unnecessary") shows incorrect value "98", because this value is based on image size (bytes) value, too. The correct value must be "2".
The column is:
`$fmtNum($div($sub(%_tag_size%,$add($len(%albumartist%$meta_sep(composer, ________)$meta_sep(arranger,________ )$meta_sep(lyricist, ________)$meta_sep(artist,________ )$meta_sep(conductor, ________)%album%%title%$meta_sep(genre,_____ )%subtitle%%contentgroup%$meta_sep(publisher, ________ )%comment%%unsyncedlyrics%%encodersettings%%cuesheet%%tagtechinfo%),%_cover_size%)),1024))`
I tried: reopen the app; refresh the list.
Now I try to test with less loaded files.
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [April 10, 2018, 12:52pm UTC](https://community.mp3tag.de/t/request-column-for-cover-image-dimensions/41243/24 "2018-04-10T12:52:09Z")
> [@incifinci](#):
>
> the table shows only partially the value. If I select the erronous lines, it immediately shows those values.
Thanks for your feedback!
I'm assuming that you have the library enabled: since it's a new field and the modification timestamps of those files have unlikely be changed in the meantime, Mp3tag reloads the data from the library (which does not have the new fields yet).
To update the entries, you'd need to reload those files (e.g., via click on the individual files or Ctrl + T) to make use of the new information fields.
---
### Author:  [@incifinci](https://community.mp3tag.de/u/incifinci)
#### Post date: [April 10, 2018, 1:03pm UTC](https://community.mp3tag.de/t/request-column-for-cover-image-dimensions/41243/25 "2018-04-10T13:03:38Z")
Thank you for your quick reply. It works. 🙂 (Yes, library is enabled.)
---
### Author:  [@poster](https://community.mp3tag.de/u/poster)
#### Post date: [April 11, 2018, 3:20pm UTC](https://community.mp3tag.de/t/request-column-for-cover-image-dimensions/41243/26 "2018-04-11T15:20:31Z")
> [@Florian](#):
>
> After various internal experiments, I'm happy to have a solution that has no significant performance implications.
Ninety minutes ago I decided to use this new feature. I loaded all my files in MP3Tag which was done very fast because of the library feature. Then I marked all my music-files and started an update with `CTRL+T` to get the new fields in the library. This seems to last very much longer than the initial loading of all files to build up the library. After about ninety minutes MP3Tag has updated just about 80.000 files and stopped: Not enough memory.
I now will delete my database folder and start from scratch to test if this speeds up the process. It seems that updating the library with `CTRL+T` is not so advisable.
Edit:
Starting from scratch lasted about 34 minutes. If updating with `CTRL+T` would not have stopped after 90 minutes because of not enough memory it would have taken probably more than 3 hours.
---
### Author:  [@stevehero](https://community.mp3tag.de/u/stevehero)
#### Post date: [April 13, 2018, 9:54pm UTC](https://community.mp3tag.de/t/request-column-for-cover-image-dimensions/41243/27 "2018-04-13T21:54:29Z")
> [@Florian](#):
>
> you can now use %\_cover\_width% and %\_cover\_height% to access the width and the height of the first embedded cover art.
This is cool, thanks.
How about for `.flac` files in my example. I don't embed art into them as it's a labor intensive job to save each time. I name the artwork for each album `folder.jpg`.
Is there any chance that you might add one for an image stored in the files folder.
Perhaps a preference setting to say: `front`, `folder` etc..
---
### Author:  [@scott967](https://community.mp3tag.de/u/scott967)
#### Post date: [April 20, 2018, 8:42pm UTC](https://community.mp3tag.de/t/request-column-for-cover-image-dimensions/41243/28 "2018-04-20T20:42:25Z")
Just a quick thanks to Florian for the cover\_height and cover\_width. Solved a problem that I was having maintaining tagged cover art.
scott s.
.
---
### Author:  [@system](https://community.mp3tag.de/u/system)
#### Post date: [April 4, 2022, 7:56am UTC](https://community.mp3tag.de/t/request-column-for-cover-image-dimensions/41243/29 "2022-04-04T07:56:58Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
[Previous page](https://community.mp3tag.de/t/request-column-for-cover-image-dimensions/41243.md?page=1)