[Gtkpod-devel] Cover art inefficiency

[Michael B. C. <mik...@gm...>]

Hi all,

I have a couple quick questions/comments regarding the use of
thumbnails for cover art.  I tried syncing all of my music onto my
iPod with coverart attached, and the result was pretty dreadful
(discussed further below).  After peeping around a bit, it *seems* to
me like I'm storing each album cover something on the order of **90**
times (15 * 6) on average because of the following:

 1) The cover art appears to be stored on a per-track basis, as
opposed to a per-album basis (I'm going to venture a guess that my
average album consists of 15 tracks).  Having only skimmed a little
bit through the source thus far, I'm still wondering -- is this really
necessary?

 2) Each thumbnail appears to be stored in 6 different sizes.  Does it
make sense to review / trim this list for different models?  As best I
can tell, my iPod (160GB classic) only makes use of 2 of these.


More detailed discussion follows:

I've got a 160GB classic, and the method I'm using to sync my music is
a simple python script I've written that uses the python bindings for
libgpod.  (The reason why I'm not using gtkpod is because all I really
need to do is just sync my music directory to my iPod every so often,
which should be fairly simple -- from my experience, gtkpod is always
slow and buggy, when really all I need to do is something quite
simple.  If gtkpod has somehow addressed any of the concerns I'm
raising, please let me know.).

All of my music is stored in complete albums, and I've got about 120GB
of it.  I synced all of it onto the iPod without cover art, and it all
worked well.  I wiped the contents, and started syncing again with
coverart included (by calling Track.set_coverart() from ipod.py).
30GB of music into my syncing, I'm seeing > 2GB of data in my
iPod_Control/Artwork directory -- yikes!

I try to use the iPod, and the performance is abysmal.  Going to Cover
Flow, it takes several seconds for the first cover to appear, and only
a few covers appear at a time.  Scrolling a few covers forward, I hear
the disk continue to churn as it slowly loads images one by one.  I go
ahead and pick and album and start playing it, and then I hit MENU to
return back to the Cover Flow, and the iPod blocks for ten seconds or
so.  Browsing by individual artists, the iPod blocks for a second or
two on each artist, as it loads the mini thumbnails for the list of
albums.

This probably isn't as big a deal on smaller iPods (and obviously not
for those with solid state drives), but for fattie iPods like the 160,
this seek time is killer.  Aside from the latency, I'm worried that
this is going to ruin my drive -- it's sounding like a garbage
disposal trying to crank all these images out.

I'm assuming that since there is an ArtworkDB file and some .ithmb
files that appear to contain thumbnails, that all of the disk accesses
are only happening on this 2GB of art data.  So, I'm hoping that
trimming the size of the DB down to a reasonable size (by removing all
of the redundant copies) will make things run fairly smoothly, and
that all hope is not lost.

To address problem (1) above, for the time being, I've set my script
to only set coverart for the first track of each album.  Having tested
this on a single album, this is sufficient for album previews to work
when viewing by album, but the tracks don't show cover art when
playing (except, obviously, for the first track).

To address problem (2) above, I started commenting out values from the
list in itdb_track.c:

  ITDB_THUMB_COVER_SMALL,
  ITDB_THUMB_COVER_LARGE,
  ITDB_THUMB_COVER_XLARGE,
  ITDB_THUMB_COVER_MEDIUM,
  ITDB_THUMB_COVER_SMEDIUM,
  ITDB_THUMB_COVER_XSMALL,

I found that, of these, I only need:

  ITDB_THUMB_COVER_MEDIUM,
  ITDB_THUMB_COVER_XSMALL,

The former appears to be used for Cover Flow and for displaying when
the track is playing; the latter appears to be used when browsing by
album.  As far as I'm aware, I'm not seeing anywhere else where cover
art is displayed on the iPod classic.

Anyways, let me know if you have any comments on these ramblings
(apologies for the verbosity), and thanks for reading!

-- 
Mike