Request: Column for cover image dimensions


#1

I'd like to request the ability to show the dimensions of the cover image in a column.

Currently, if an MP3 file has a cover image embedded, Mp3tag will show the mime-type, resolution, size, and cover type in the left-hand sidebar next to the image itself.

I'd like to have a new information field for the cover resolution.

Mp3tag already has information fields for "cover_mimetype", "cover_size", and "cover_type". So why not also have "cover_resolution"? :slight_smile:

This would be very useful when scanning a folder with lots of MP3s that have a range of different-resolution album covers.


#2

With "resolution" you ask for something like "500x500"?
Or x=500 and y=500?
Or what exactly would you like to see as "cover_resolution"?


#3

The embedded picture cannot be manipulated by MP3tag, you would have to export it for that purpose.

Then: this topic itself is rather old, there is even an attempt for a workaround from 2008:

One of the more recent threads around this topic:


#4

Hi @ohrenkino, per my request above, I'm not asking for the ability to manipulate the image in any way. I'm simply asking for the ability to display the image resolution.

As I noted, Mp3tag can already display the image mime-type, size (in kilobytes), and cover type, using the respective information fields that I mentioned. These fields are not used for manipulating the image, but just for displaying information about the image.

I'm merely making a feature request for a new info tag that displays the image resolution.

The resolution is already calculated by Mp3tag and shown in the left-hand sidebar, as you can see in this screenshot, where it says "1600x1600". That's the exact data that I'm asking to have available in a new info field:

2018-03-29%2019_15_26

If Mp3tag is able to calculate the resolution and display it there on the left, for the currently-selected file, then why is it not technically possible for it to include this exact same information in a new field?

The two older posts that you mentioned were asking if it is currently possible to do this, or if there is a workaround. However, I'm not asking if it is currently possible (I already know that it is not). I'm asking for this feature to be added in a future release of Mp3tag. That's the purpose of making a feature request, right?

Please kindly pass this on to the developers as a feature request! If I've posted this in the wrong area for a feature request, I'm happy to re-post it in the correct area of this forum. Or if there is another way I can officially make a feature request to the developers, please kindly let me know.


#5

@LyricsLover - just showing "500x500" - exactly as it already shows in the left-hand sidebar - would be fine for me. My point here is that the data is already calculated by Mp3tag, so why not allow it to be shown in a field too, just as the other image data (mime type, size etc) is already available in fields. It makes logical sense.


#6

And if implementing such feature: why not also give ability to display in Column only vertical size and only horizontal size?

So something like:

  • cover_resolution
  • cover_resolution_horizontal
  • cover_resolution_vertical

Request for better handling of multiple embedded images
#7

...Let me illustrate my point a little further with another screenshot, showing the cover image and the four lines of image data in the left sidebar: mime-type, resolution, size, and cover type.

As you can see, it's possible to show mime-type, size, and cover type in respective columns in the main area of the window.

But it's not possible to show the resolution in a column. Why is that, when the resolution data is already there?


#8

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


#9

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.


#10

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.


#11

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.


#12

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: )


#13

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

But, now we have library feature...so 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:


#14

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


#15

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


#16

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: )


#19

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.


#20

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%]


#21

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.


#22

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