# Cover preview / cover info cropping in Tag info

**URL:** https://community.mp3tag.de/t/cover-preview-cover-info-cropping-in-tag-info/64900
**Category:** Fixed Bugs
**Tags:** bug-fixed
**Created:** [May 31, 2024, 2:14pm UTC](https://community.mp3tag.de/t/cover-preview-cover-info-cropping-in-tag-info/64900 "2024-05-31T14:14:45Z")
**Posts on this page:** 12
**Page:** 1

<div class="post-metadata">

### Author: ![rboss](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/r/5f9b8f/32.png) [@rboss](https://community.mp3tag.de/u/rboss)
#### Post date: [May 31, 2024, 2:14pm UTC](https://community.mp3tag.de/t/cover-preview-cover-info-cropping-in-tag-info/64900/1 "2024-05-31T14:14:45Z")

</div>

In v3.23c, the cover preview box was adjusted to fix this [bug](https://community.mp3tag.de/t/no-empty-space-in-gui-cover-art-discogs-when-album-cover-fits-perfectly-600x600/63076).

However, I've noticed that since then until the current version - v3.26 - when loading a cover that fills the entire cover preview box, the cover art will crop part of the cover info + checkbox.

Hovering over the cover info field brings it (info field) into view again, but now it's the cover info that will crop part of the cover art (and leave a tiny slit of cover on the left side).  
Enabling/disabling "Correct aspect ratio" will reset the behavior; but now it's back to square one (cover art over cover info; hovering reverses field on top)

Here are some screenshots for clarity:  
 ![imagem](https://community.mp3tag.de/uploads/default/original/3X/b/1/b1fcdeb09d6c2b4d351f7126a1c37bb1bd154f1a.png) ![imagem](https://community.mp3tag.de/uploads/default/original/3X/3/1/31fd0b21f7ba9e40bf860167c34de81f90af6500.png)

Since this behavior is related to the previous bugfix (I think), and since the OP in that topic could fix that issue with the "Correct aspect ratio" setting, I would like to ask to have the old cover box size/placement restored, or having the cover info position adjusted (move it slightly down) to prevent cropping.

Thank you.

---

<div class="post-metadata">

### Author: ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [June 6, 2024, 8:24am UTC](https://community.mp3tag.de/t/cover-preview-cover-info-cropping-in-tag-info/64900/2 "2024-06-06T08:24:30Z")

</div>

This is something I cannot reproduce at the moment (despite the screenshots clearly showing a problem).

Please tell me the Windows version you're using and which DPI percentage.

---

<div class="post-metadata">

### Author: ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [June 6, 2024, 8:34am UTC](https://community.mp3tag.de/t/cover-preview-cover-info-cropping-in-tag-info/64900/3 "2024-06-06T08:34:08Z")

</div>

The following environment:  
W11,

 ![grafik](https://community.mp3tag.de/uploads/default/original/3X/e/0/e057dce64e9cf63dbf56d8aa2cc070abd6898c21.png)  
leads to  
 ![grafik](https://community.mp3tag.de/uploads/default/original/3X/a/d/ad841d5325a5b6e1624af17f9061af38ef0df301.png)

using the default Musicbrainz script

---

<div class="post-metadata">

### Author: ![rboss](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/r/5f9b8f/32.png) [@rboss](https://community.mp3tag.de/u/rboss)
#### Post date: [June 6, 2024, 1:54pm UTC](https://community.mp3tag.de/t/cover-preview-cover-info-cropping-in-tag-info/64900/4 "2024-06-06T13:54:43Z")

</div>

Windows 10.

![imagem](https://community.mp3tag.de/uploads/default/original/3X/0/6/067eabd77b2dbc87bdac87248e63e6279fb16702.png)

@ohrenkino Can you also replicate the behavior when hovering with the mouse cursor?

---

<div class="post-metadata">

### Author: ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [June 6, 2024, 2:01pm UTC](https://community.mp3tag.de/t/cover-preview-cover-info-cropping-in-tag-info/64900/5 "2024-06-06T14:01:16Z")

</div>

> [@rboss](#):
>
> Can you also replicate the behavior when hovering with the mouse cursor?

No, hovering does not change anything.  
If I click on the picture, then it looks like this:  
 ![grafik](https://community.mp3tag.de/uploads/default/original/3X/f/2/f21f5afb24b8e75ea4678badffaa6a107664bef3.png)

(I get the zoomed picture dialogue as well, but as long as the focus stays on the picture, it has the additional bar at the bottom)

---

<div class="post-metadata">

### Author: ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [June 6, 2024, 2:20pm UTC](https://community.mp3tag.de/t/cover-preview-cover-info-cropping-in-tag-info/64900/6 "2024-06-06T14:20:59Z")

</div>

I'm programmatically resizing the cover window just to be sure that it's always square. When implementing this, I did this mainly to protect myself and make sure that even if I'd change the size in the dialog resource by one pixel, it still turns out as being square.

The screenshots clearly show that, on some systems, loading the dialog resource results in a not-at-all square cover window and the programmatic correction adds more than one pixel horizontally.

Even if I can't reproduce this at the moment, I might be able to resize and move the cover info and checkbox in a similar fashion. I'll keep you posted.

---

<div class="post-metadata">

### Author: ![rboss](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/r/5f9b8f/32.png) [@rboss](https://community.mp3tag.de/u/rboss)
#### Post date: [June 8, 2024, 1:14pm UTC](https://community.mp3tag.de/t/cover-preview-cover-info-cropping-in-tag-info/64900/7 "2024-06-08T13:14:27Z")

</div>

Small update:

By chance I happened to still have the installers for 3.25b and 3.24; and in both (portable installation) I was able to replicate the same behavior on win 10 pro. Later today I should be able to test these in a win 11 system and see if I get the same results as @ohrenkino.

---

<div class="post-metadata">

### Author: ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [June 8, 2024, 1:52pm UTC](https://community.mp3tag.de/t/cover-preview-cover-info-cropping-in-tag-info/64900/8 "2024-06-08T13:52:55Z")

</div>

Please save your testing energy until the release of v3.26a 😀

---

<div class="post-metadata">

### Author: ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [June 11, 2024, 1:52pm UTC](https://community.mp3tag.de/t/cover-preview-cover-info-cropping-in-tag-info/64900/9 "2024-06-11T13:52:47Z")

</div>

I've just released [Mp3tag v3.26a](https://community.mp3tag.de/t/455) which should fix the reported problem. Please let me know!

---

<div class="post-metadata">

### Author: ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [June 11, 2024, 1:59pm UTC](https://community.mp3tag.de/t/cover-preview-cover-info-cropping-in-tag-info/64900/10 "2024-06-11T13:59:32Z")

</div>

in 3.26a it looks like this:  
 ![grafik](https://community.mp3tag.de/uploads/default/original/3X/f/f/ffb466019a8af39a8e7a7b3b4c0756b9621331ca.png)

Which, IMHO, is fine!  
And here is the other one:  
 ![grafik](https://community.mp3tag.de/uploads/default/original/3X/1/7/173274d6d7c874ead7caabef3964095c2d179072.png)  
Also OK.  
The yellow stripe at the bottom is part of the picture

---

<div class="post-metadata">

### Author: ![rboss](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/r/5f9b8f/32.png) [@rboss](https://community.mp3tag.de/u/rboss)
#### Post date: [June 12, 2024, 12:11pm UTC](https://community.mp3tag.de/t/cover-preview-cover-info-cropping-in-tag-info/64900/11 "2024-06-12T12:11:13Z")

</div>

> [@Florian](#):
>
> I've just released [Mp3tag v3.26a](https://community.mp3tag.de/t/455) which should fix the reported problem. Please let me know!

Looks good on this (Win 10) end:

![imagem](https://community.mp3tag.de/uploads/default/original/3X/4/6/463ba0c96121abf228baf07d21049bc6d567cfee.png)

On non-squared covers, the black bars are properly displayed, and "Correct aspect ratio" is working as it should, and not doing anything that it wasn't supposed to do.

So (tentatively) I would call this as "fixed".

@ohrenkino I did end up spending my testing energy and tested v3.26 on my W11 laptop, and I was unable to replicate what you reported. On the exact same (portable) installation where I was getting the bug in W10 I did not get it in W11 on a different machine.

---

<div class="post-metadata">

### Author: ![system](https://community.mp3tag.de/uploads/default/original/2X/c/ce7035d426cb755a7916793326d23b465222a407.png) [@system](https://community.mp3tag.de/u/system)
#### Post date: [July 12, 2024, 12:11pm UTC](https://community.mp3tag.de/t/cover-preview-cover-info-cropping-in-tag-info/64900/12 "2024-07-12T12:11:20Z")

</div>

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