Album art is distorted

Ever since I upgraded to 2.43, I've noticed the album art pictures now have white bands on each side of the picture, slightly squishing the image and not filling in the whole album art pane.

It used to have a little 3-D shading on one side to give it that slightly 3-D look which I liked, but now it looks distorted to me. This happens no matter the size of the .jpg I add cover to it.

What's going on here?


Which size do you use for your cover art pictures?
It seems, that "too small" cover art pictures (like my little 120x120 ones) will be re-sized to fit the pane.

Well, there are fine one (!) pixel sized lines around the image. Top and left side are colored gray, right and bottom are colored white (RGB:128,128,128/255,255,255). This is intended to see a slightly engraved 3D effect.
But in fact it seems not to be the same look like the engravement setting used in the metadata field. Yes, in the cover field there is missing the inner borderline (RGB:64,64,64/212,208,200).
Therefore the virtual engravement looks distorted.

Suggestion by the way ... I want to have the cover adding browse dialog to remember the folder where the image has been selected from at last. If the folder does not exist, maybe deleted or renamed in the meantime, then a standard default folder should be opened: Mp3tag application folder or just better the 'My Pictures' folder.


If this was the case, I’d probably shout out: »HELP! DON’T!«. It probably depends very much on one’s workflow — I couldn’t live without Mp3tag opening the folder where the audio file is in, because I usually store the cover art inside the album folder. And I’d hate it to always click through all the selections away from "C:\Documents and Settings\username\My Documents\My Pictures" … just to get one picture …

I agree it would be nice for people who store their cover art in a central location, though.

So if this was done, please make it a selectable option. :rolleyes:

Hmm, it's somehow different.

Yes that should and is the standard behaviour and it works well in all cases if you want to pick pictures which stored within the folder where the track resides.

But if you have to browse into a different folder on some disk anywhere where the pictures are stored which you want to import, then you are lost, because you have to browse over and over again to that specific folder for each picture you need - not so amusing (status now Mp3tag 2.43).

Well this is not what I've said. I am a one-click-lover too. That's because my posting from above!

My suggestion was to dedicate the file browser search to start in a destinated standard folder in case of the folder from the last browsing can not be accessed any longer.
Well, in changing my mind a bit this standard starting place should be the folder where the track resides (or alternatively can be set to system folder 'MyPictures' or other user defined folder by global setting option).
As long as the last browsed folder can be accessed, then the last browsed folder has to be the starting point for the next file picking (most implemented behaviour in many applications).


Well it used to. Not anymore

I suspect it has something to do with this so-called fix:

"[2009-03-03] FIX: aspect ratio was not kept when displaying cover art that exceeded the size of the cover art window."

I'll probably have to skip this upgrade until it reverts back to the way it was before. If not, then I may consider another tagger or skip the album art altogether.

It's a shame because it was a good idea having it, but right now, it sucks the way it looks. :frowning:

No don't do that. Leave it as is.

I always store the album art in the same file as the mp3s, tag files etc.. that the art is associated with. Having a central location for where the art is stored is repetitious and wastes time searching for it.

Misunderstanding the facts ... anyway, ok, it was not my intention to press more clicks than needed ... see my answer to moonbase from above posting.
But in the case if someone want to pick pictures from another place than the track folder, then the repetitive amount mouseclicks is enormous (status now). If the browser would remember the last visited folder, then the work will be done easier and quicker.
My suggestion to be fetched up in a default folder was only for the case when the last visited folder is not accessible because of some reason whatsoever.
This default folder can be the track folder or the 'My Pictures' folder or some other user defined folder anywhere in the system, should be defined by global setting.


So is there going to be any fix for the album art issue up above, or not?


No answer? <_<

Well it's back to 2.42 for me. Fortunately I can still get it

Do you notice this only with files tagged by v2.43 or also with file that have been previously tagged with v2.42. Can you maybe post a screenshot that exemplifies the distortion issue you're describing?

In my case, you can see the difference even with the empty placeholder CD-pictures. Just compare the "empty" pictures from the last working version 2.42f and the no more correctly working version 2.42h and newer (including 2.43):

Then have a look for the pictures in the resolution 120x120 and 900x900 pixels. The first picture is from the last working version 2.42f, the second from the newer 2.42h and 2.43. You can see the white frame in the working version and 120x120 Pixels and the no more visible frame in the newer version (because auf stretched picture)

With the 900x900 pictures it's a little bit more tricky to see the difference:

With the 900x900, I see no difference.

And I've never used anything as small as 120x120. That's too small! :astonished:

The minimum size jpg I will ever use is 306x280, the default size of the empty placeholder

I'll have to zap-grab a couple of pictures and show you all later this evening, but I can tell you I've never had an issue before, no matter what the size was, greater than the default placeholder size of 306x280

I can see the issue LyricsLover is describing (which was already reported here in the german speaking forum).

But it seems that this differs from what you're reporting and it would be most helpful to see the difference by means of screenshots.

Take a look at the attachment below. You will see white borders to the left and right of the image

Doc1.doc (64.5 KB)

Doc1.doc (64.5 KB)

In #14, can anybody see what I'm talking about here?


Sure, but it's not a distortion but just Mp3tag keeping the correct aspect ratio for cover art where height and width are different.

I'll see whether I'll add an option to stretch the image for the next release.

That would be great! :music:

Yeah, that would be great. These .jpgs used to shrink down and fill the whole placement pane if the .jpg itself was larger than the placement pane itself. The aspect ratio always corrected itself.

Now, the problem comes from putting a .jpg smaller than the placement pane itself, and having it stretch out to cover it. Well I've never had any issue finding bigger album art to avoid this. I find it strange some people can only find a 120x120 to use, when they can use Google image to find all kinds of larger .jpg sizes for a particular album.

A wonderful program like Mp3tag should give us the opportunity to do all the changes like we want to have it. That's the reason, why this 'stretch/distortion'-thing should be optional. Some like it enabled, other prefer it disabled. :rolleyes:

With such an option you can add 1920x1200 pixel album-pictures and I have fun with my little 120x120 one. :sunglasses:

Well that's sort of how I would have it. Have the default be what was previously in 2.42, but then have a menu or right mouse click option for those who want to stretch those little 120x120 pix to fill the pane for those who want that.

I personally would never use it because I never use .jpgs that small.

What do you think Florian? The idea you sent me was an improvement, but it was based on 2.43 correcting the aspect ratio of those bigger .jpgs in, as opposed to using 2.42 and expanding those smaller 120x120 .jpgs out (in four directions) in order to fill the pane.