Version: 2.1 SVN 979396 (using KDE 4.2.3) Installed from: Unlisted Binary Package Current Amarok collection scanner automatically selects as album cover the biggest (in KB) image file that it finds sitting in the same folder as the audio files. Usually I have more than one image inside the folder, i.e.: "back.jpg" "inlay.jpg" and "cover.jpg". Amarok selects the one with the biggest filesize. It would be optimal to have it first search for images with some strings like "cover", "tapa" (spanish), "front", etc. And then, yes, if it doesn't find any of those strings, it should select the biggest image file it can find. Keep it up!
it makes sense to me.
*** Bug 204313 has been marked as a duplicate of this bug. ***
Jeff, do you think this is something doable?
Hm, I could probably do something like this. Could probably have it search for "front.something" (where "something" is jpg or png) or "cover.something" or i18n("front") + ".something" or i18n("cover") + ".something"...
Here are some variations on image file names in my collection: ./The Beatles/The Beatles - Revolver remaster/revolver front.jpg ./The Beatles/Beatles 1962-1966 (Red Album)/Beatles_-_Red_Album_1962_1966_(Front).jpg ./U2/U2 ~ U2 Remixes For DJ Promo Only + All Artwork/DJ Promo Only - Jewel Insert - Front Only.jpg ./U2/[2002] The Best Of 1990-2000 & B-Sides - U2 - 427mb @ 320kbs ##~/The Best Of 1990-2000 & B-Sides - U2 (Front) [2002].jpg ./Grateful Dead/albums/1977 - Terrapin Station/AlbumArtSmall.jpg ./Grateful Dead/albums/1977 - Terrapin Station/AlbumArt_{8E8D7A98-48A7-43C6-A67D-FAD0C5AEEC93}_Small.jpg * ./Grateful Dead/albums/1977 - Terrapin Station/AlbumArt_{8E8D7A98-48A7-43C6-A67D-FAD0C5AEEC93}_Large.jpg ./Pink Floyd & The Orb & D.J. Fish - Trance Remixes/Pink Floyd & The Orb/(1975) Wish You Were Here (Trance Remix)/Back Cover.jpg ./Pink Floyd & The Orb & D.J. Fish - Trance Remixes/Pink Floyd & The Orb/(1975) Wish You Were Here (Trance Remix)/CD.jpg * ./Pink Floyd & The Orb & D.J. Fish - Trance Remixes/Pink Floyd & The Orb/(1975) Wish You Were Here (Trance Remix)/Front Cover.jpg ./Pink Floyd & The Orb & D.J. Fish - Trance Remixes/Pink Floyd & The Orb/(1975) Wish You Were Here (Trance Remix)/Inlay.jpg ./Pink Floyd & The Orb & D.J. Fish - Trance Remixes/Pink Floyd & The Orb/(1975) Wish You Were Here (Trance Remix)/Wish You Were Here (Trance Remix) (Cover).jpg ./Pink Floyd & The Orb & D.J. Fish - Trance Remixes/Pink Floyd & The Orb/(1975) Wish You Were Here (Trance Remix)/Inside.jpg ./younger brother - 2000 - a flock of bleeps/younger brother - a flock of bleeps ('03) - insert 2.jpg * ./younger brother - 2000 - a flock of bleeps/younger brother - a flock of bleeps ('03) - cover front.jpg ./younger brother - 2000 - a flock of bleeps/folder.jpg ./younger brother - 2000 - a flock of bleeps/younger brother - a flock of bleeps ('03) - insert 4.jpg ./younger brother - 2000 - a flock of bleeps/younger brother - a flock of bleeps ('03) - insert 3.jpg ./younger brother - 2000 - a flock of bleeps/younger brother - a flock of bleeps ('03) - cover back.jpg ./younger brother - 2000 - a flock of bleeps/younger brother - a flock of bleeps ('03) - insert.jpg ./Conjure One/2005 - Extraordinary Ways (Special Edition)/Cover-back.jpg * ./Conjure One/2005 - Extraordinary Ways (Special Edition)/Cover-front.jpg ./Frank Zappa x 34/(1981) Frank Zappa - 34 - You are what You is [256]/Frank Zappa - You are what You is - back.jpg * ./Frank Zappa x 34/(1981) Frank Zappa - 34 - You are what You is [256]/Frank Zappa - You are what You is - front.jpg ./Frank Zappa x 34/(1981) Frank Zappa - 34 - You are what You is [256]/Frank Zappa - You are what You is - cd.jpg ./Mike Oldfield/Amarok/(Amarok) cover- cd.jpg ./Mike Oldfield/Amarok/(Amarok) cover- inside.jpg ./Mike Oldfield/Amarok/Amarok.jpg * ./Mike Oldfield/Amarok/(Amarok) cover- front.jpg ./Mike Oldfield/Amarok/(Amarok) cover- back.jpg ./Alice Cooper/(1999) The Life And Crimes Of Alice Cooper/ALice Cooper - The Life And Crimes Of Alice Cooper - CD4 - back.jpg ./Alice Cooper/(1999) The Life And Crimes Of Alice Cooper/ALice Cooper - The Life And Crimes Of Alice Cooper - CD2 - back.jpg ./Alice Cooper/(1999) The Life And Crimes Of Alice Cooper/ALice Cooper - The Life And Crimes Of Alice Cooper - CD3 - back.jpg ./Alice Cooper/(1999) The Life And Crimes Of Alice Cooper/alice_cooper_life_and_crimes_3_INSIDE.jpg ./Alice Cooper/(1999) The Life And Crimes Of Alice Cooper/ALice Cooper - The Life And Crimes Of Alice Cooper - CD1 - back.jpg ./Alice Cooper/(1969) Nobody Likes... Alice Cooper Live/Alice_Cooper_-_Nobody_Likes_(Back).jpg ./Alice Cooper/(1969) Nobody Likes... Alice Cooper Live/Alice_Cooper_-_Nobody_Likes_(Cd).jpg ./Alice Cooper/(1969) Nobody Likes... Alice Cooper Live/Alice_Cooper_-_Nobody_Likes_(Full).jpg ./Alice Cooper/(1969) Nobody Likes... Alice Cooper Live/Alice_Cooper_-_Nobody_Likes_(Inlay).jpg ./Alice Cooper/(1969) Nobody Likes... Alice Cooper Live/Alice_Cooper_-_Nobody_Likes_(Inside).jpg I denoted with "*" the correct files, when possible. Most covers have random filenames, but they are only images in those directories. "cover.jpg" and "front.jpg" are very popular, but there are many variations with "cover" and "front". In the case of Alice Cooper, there may be a different cover for each CD in the set, all in the same folder. Perhaps another regexp for "CDx" if the tracks define a disc number? (In this case they are back covers, but they as well be front covers) Perhaps this list will help in creating the logic of choosing the best file. :)
Well no, this list reinforces why this wasn't implemented in the first place. Most of the right ones seem to have the word "front" (with some capitalization or another) in it. The problem is that if we start scanning for "front" somewhere in the string, if we try to do that with translated strings it could very easily break. So the answer is really one of two things: 1) Pick the file with "front" in it if found, and people can manually set covers for incorrect/missing artwork. 2) Leave it as it is now, and people can manually set covers for incorrect/missing artwork. #1 seems a bit less random, so there is that going for it.
This is harder than first anticipated. It doesn't pick the largest size out of the covers. What it does is pick the last, alphabetically. Basically, it reads in all images in a directory (I don't actually know why), and then every time it reads in a new image it updates the album to use that as the image. However, changing this doesn't immediately always seem to take effect because it prefers cached resized copies in ~/.kde4/share/apps/amarok/albumcovers/cache (which is reasonable). So you won't really see this unless you wipe out the cache first (which has no ill effects other than making it take a tiny bit of cpu time to regenerate them). What I don't know is why it's keeping all of the images around. I can try prioritizing based on the filename, but ideally I'll be able to save some processing time and SQL stuff by having it just use one cover.
I would go for: if "front" (and maybe some other language would come in handy, at least for me, like spanish "tapa") found then choose that one. else the last modified image. end.
Ok. I vote to add also "cover" to the keywords.
"cover" is pretty ambiguous...is it the front cover, or the back?
well, I think 90% of my covers are named cover.{jpg/png}. That is mainly because my portable mp3 player only recognize "cover.jpg" for displaying an album cover. Some stats from my collection: $ grep -i "cover.jpg" collection_scan.files | wc -l 925 $ grep -i "back.jpg" collection_scan.files | wc -l 123 $ grep -i "front.jpg" collection_scan.files | wc -l 116 $ grep -i "front cover.jpg" collection_scan.files | wc -l 1 $ grep -i "back cover.jpg" collection_scan.files | wc -l 1 $ grep -i "cover.png" collection_scan.files | wc -l 460 $ grep -i "front.png" collection_scan.files | wc -l 6 $ grep -i "back.png" collection_scan.files | wc -l 4
FIW: My album covers have various names, and if there are several, those are named 'front' 'back' 'inlet' and 'label' most of the time. None is called 'cover'. There also are a lot who actually just have numbers. So I don't think this is easy to solve, and will bring a lot of problems in translated versions.
Sorry, I wasn't clear. "Cover" tends to be ambiguous so it's not acceptable as a first-order keyword. I'm going to write it so it look for keywords (using both English and translated strings) in a hierarchy. First "front", then "cover", then "large" (if they just have artwork in small and large versions, which is often the case with iTunes, this will put preference on the large one). After that, probably the one with the largest file size (at least that's better than the last alphabetically, which is what is happening now).
Fixed in 4b7de4d08988bdac4936370fa9c041bcb50dc02d In order it case-insensitively looks for the following: 1) "front" or i18n("front") -- more than one file with "cover" will probably have "front" in one of them 2) "cover" or i18n("cover") -- if only one file with "cover" in it it's probably the front cover 3) "large" or i18n("large") -- iTunes-style large/small album art, usually if a "large" is present it means large front cover 4) If none of those match, it looks for the file with the largest file size, which is often/usually a high-res version of the front cover
Oh, as a follow-up: for this to take effect, you'll need to a) delete the files in ~/.kde4/share/apps/amarok/albumcovers/cache*; and b) run a full rescan of your files (not an update/incremental scan).
Thanks. :) I upgraded from git and now it works. I looked a few albums that were having from covers, and now their cover is set from "cover.jpg". Good work!
Thanks. :) I upgraded from git and now it works. I selected a few albums that were having wrong covers, and now their cover is properly set from "cover.jpg". Good work!
It seems that automatic cover fetching from internet does not work, even if I have ticked the option on. May have this recent change broken that?
No...this change only affects covers scanned in via the collection scanner. It affects only what is stored in the database, and doesn't affect lookup of those covers from the database or touch any other part of cover handling code.