Does smaller image refer to resolution in pixels or size in kB?
This is about pixel size
1 Like
That should actually be sort of understood because the option is a sub-option of “Embed cover images into tags”, which implies that size is pixels rather than file size because it’s comparing to a previously stored cover image.
In addition, the documentation states, “Enabling this setting will prevent Picard from replacing an embedded cover image with one having smaller dimensions.”
4 Likes
It’s a tough choice, but my plugin can handle it.
The cover image is larger in pixels, but smaller in bytes.
Different levels of JPG compression. Smaller in bytes is likely lower quality/higher compression, but bigger in pixels is a physically bigger image. Which would likely then show up the lack of quality more. Which is best?
Your above screen shot is interesting. What you are now picking out with your images is that some of your AcoustID matches will pick out a different release than that track was initially ripped from.
Example from your above screen shot:
- second one down is swapping one compilation to another,
- sixth one down is swapping a standard release image to a Japanese release with Obi,
- seventh seems to swap an album to a compilation,
- eighth again seems to prefer Japanese release to a standard one.
I expect if you focus on the other images you see similar happening. As you are matching recording without metadata then the release they match with will often change.
I can see it works, just an interestingly different way to show how the matching algorithms are finding different recordings.
For test:
CD3 Release “Ultimate Movies: 4 CDs of Great Hits from the Movies” by Various Artists - MusicBrainz
I ran the Scan with this Setting:
I received the base:
Then I selected this option:
And here are two ways:
- I added this CD3 and Lookup
- I added this CD3 and Scan
