I didnt pay much attention to the iPod artwork issue until I found the coverflow became extremely slow and out of response occasionally.
I’m using Amarok via libgpod-0.6.0 to manage my iPod library, there’re approximately 1,000 songs of 68 albums in my iPod. As I checked the
iPod_Control/Artwork directory of my iPod, it took up unexpectedly +300mb for the cover images.
punkid@Genbox /media/MUGELLO/iPod_Control $ du -h Artwork/ 314M Artwork/
Then I tried iTunes to rebuild my music library, the artwork database shrinks to 53mb.
punkid@Genbox /media/MUGELLO/iPod_Control $ du -h Artwork/ 53M Artwork/
As someone in that post pointed out:
it turns out that iTunes isn’t actually storing one piece of artwork per track or even one per album – in my case at least, it stored one cover for only 2 of the tracks on the 12-track album …
Fortunately this issue has been fixed in the libgpod svn version, and the new artwork database size looks quite impressive. It’s even smaller than the iTunes’ one.
punkid@Genbox /media/MUGELLO/iPod_Control $ du -h Artwork/ 18M Artwork/
The latest libgpod svn build has already supported the new iPod Nano 4G, and the photo issue also seems to be fixed. If you dont have the patience for a “never-landed” new stable release, grab the latest libgpod svn snapshot.
For Gentoo users, you may put the media-libs/libgpod-9999.ebuild into your personal ebuild repo.
Note : I removed the
doc USE flag from the ebuild due to the latest libgpod somehow needs gtk-doc to make distcheck to work correctly. Bad news, KDE fan boys :(