Request: Column for cover image dimensions

@Zerow - yes, I like that idea too! Why not all three?!

I just found a thread from 2006:

The answer in those days was: This will not be implemented as it would slow down MP3tag dramatically.

Hi @ohrenkino,

First of all, that thread is 12 years old, and computers have come a long way since then. :wink:

Second of all, the user in that thread is not asking for the same thing as I am. He writes, "Anzeige des 1. Bildes oder evtl. des mit der größten Auflösung" - so he is asking for the ability to display the image itself in a column. Obviously that would, indeed, slow down Mp3tag dramatically. But that's not what I'm asking for, of course! I'm just asking for the resolution of the image to be displayed, not the image itself.

I don't see my request having any burden on the speed of Mp3tag, for the following reasons:

  1. If I open a folder in MP3tag containing over 1000 MP3s, I can click on each MP3 one by one and it shows the cover image (I mean the actul image itself) in the left sidebar instantly. Literally instantly, as I click from one song to the next. There is not even a fraction of a second of delay.

  2. If Florian were to add a new "cover_resolution" info field to Mp3tag, it would not be enabled in a column by default. Users would need to manually add it as a new column. Therefore, even if it would slow down Mp3tag a little bit (which I don't accept), it would be the user's choice to do this. As long as this new field is not added to a new column, there would be zero effect on the performance.

  3. Mp3tag now has a new Library feature, which stores the tag info in a database for faster reading. Therefore, even if this new "cover_resolution" field were to affect the loading times of Mp3tag (again, I don't believe it would), I can avoid this by using the Library feature. And again, this is my choice as the user. For users who don't want to use this new field, they aren't affected in any way.

Remember, we've come a long way since 2006 - we have much faster hard drives, and most of us are using SSDs now. But in any case, the post from 2006 was asking for something else, as I mentioned above. :slight_smile:

Question: does @Florian read these feature requests too? I appreciate your comments and help with this, but how can I give a feature request to Florian as the developer, so he can consider it? You can see that there are other users here (commenting in this thread) who would also like to see this feature added.

1 Like

Yes, I think @Florian does read all this.
And: I did not want to disqualify or dismiss your request in any way.
I am not the one who implements such things or does not implement them.
But as it is a good exercise to see if possibly somebody else already had an idea, i tried to point out the older threads. It would have been nice to revive an old thread just to proove that the idea is still worthwhile being followed as there is still demand for it.
Such a proceeding also reduces the need to repeat arguments or it is easier to pick up old arguments and see if they are still valid.
Nothing more.
But as always with requests: until it is implemented you can use the workaround that I linked.
It is never quite clear whether a request is published to overcome a certain problem and any way to solve it is welcome or whether teh request has only one particular implementation in the focus.

Thanks @ohrenkino. And I agree with what you're saying about older posts, to see if someone already asked for the same thing.

But from my own searching of older threads about this topic (including one that I actually created myself in 2013), they are mostly people asking "is this currently possible" or "is there a workaround", and the answer, of course, was "no it's not", and "yes, here is some (complicated) workaround".

So I thought to create a new thread as a proper feature request, to specifically ask for this feature to be added, rather than just ask if it's currently possible. :wink:

What would actually be a nice feature of this new community forum, if possible, is to have a dedicated "feature request" section, and also to allow the developer(s) to mark each feature request somehow as "Will do", "Might do", "Won't do" etc - so that the requester can know if there is any chance of it happening in the future, or not. :wink:

(I should add: in my day job I'm a software Quality Assurance Engineer - mostly working with Jira...:wink: )

1 Like

The answer in those days was: This will not be implemented as it would slow down MP3tag dramatically.

But, now we have library this data could be stored there and only inital loading would be "slow" this way.
So basically @Florian could tie it to Library enabled/disabled if it affects performance too much. :wink:

Even that should not be necessary, as I explained in my comment above! :wink:

I would like to draw your attention to the fact that even now the properties already shown for embedded images describe only the "first" image - whatever that first image may look like and may be.
For a thorough investigation it would still be necessary to export the embedded images to files with unique names and then see if there is anything left to be done.
Right now it is not possible to define the order of embedded images (which is first, second, third and so on).
And without export it is not possible to see of what type further embedded images are as only the first one is shown.
So I get the impression that showing the dimensions is either not enough (as a lot of functions to handle embedded images properly are missing) or it is too much of an effort (as even with this additional shown property it would still be ncessary to go the way of exporting the images where you could see this property straightaway).

Hi @ohrenkino,

If I'm honest, it seems like you're over-complicating the feature request!! :wink: It's absolutely not necessary to export the images to files. It's also not necessary to try and determine which image is which, for the purpose of my request. I'm only - simply - requesting that the resolution of the currently-displayed image is available as a new Information Field, which can be added to a column. Nothing more! :slight_smile:

Let me show you my screenshot again:

Here you can see, that there are already Information Fields for the mime-type, image size, and cover type. It's certainly not necessary for Mp3tag to export the images to files, in order to calculate those three values, is it? Mp3tag simply grabs the mime-type, size, and cover type values of the default image, which is already displayed in the sidebar. If the MP3 file has more than one image, it's too bad - Mp3tag will still only show the values from the default image.

Therefore, by extension, Mp3tag can also show the image resolution of that SAME image. No need to export to a file, or do fancy calculations or anything else. Just take the SAME image that is already used to show the mime-type, size, and cover type columns, and grab the resolution of that SAME image. Very, very simple - right?

Do you get what I mean?

I think the things you are proposing are going way beyond what I (and the other users in this thread) are hoping for. I just want to keep it nice and simple! (So yeah, maybe your extra wishes should belong in another thread?? :wink: )

I agree that this information field would be an improvement.
I am constantly working on my music files with the intention to embed front-cover-art with a standard resolution of 800x800.
At the moment I have to use third-party-software to filter for the resolution parallel to MP3Tag. In MP3Tag it is only possible to filter for the size of the embedded cover at the moment.

After various internal experiments, I'm happy to have a solution that has no significant performance implications.

With Mp3tag v2.87b, you can now use %_cover_width% and %_cover_height% to access the width and the height of the first embedded cover art.

An example column configuration that resembles the requested information field for cover resolution would be [%_cover_width% x %_cover_height%]


Wow thanks so much Florian! I just tested it on a large folder I have with over 1200 songs, and it works perfectly! :slight_smile: Really appreciate the quick implementation.

1 Like

@Florian, huge thank you...been waiting this feature for ages.


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.

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.

Thank you for your quick reply. It works. :slight_smile: (Yes, library is enabled.)

1 Like

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.

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.

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..

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.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.