Re: [Rhythmbox-devel] Evolution of the album cover support in rhythmbox

[Adam Skobel <skobel gmail com>]

How about none of the above and doing top-left, but still in that bar
where there is space available? That way the image will be right below
the currently playing song so its clear its related to that, and we
are using the available space. I don't see why the space needs to be
truncated off the bottom of the sidebar, taking it off the top to make
it closer makes more sense to me.

<quote>
OK. The album cover issue has been tossed around a few time around
here, and seems to now be broken into 2 parts, neither of which people
seem to be able to agree on.  As a lurker who comes out of hiding
every now and then, I'm going to summarize because I think it would be
good if we all get this straight, plus I'd like to throw in my
opinion, since that seems to be the thing to do.

Placement: 
1) Top (next to title, etc.)
    pros: 
        - Makes logical sense.  All information about the current song
in one place.
    cons:
        - either causes this piece of the UI to become huge, or forces
the use of a tiny album cover

2) Bottom-Left (ala iTunes)
    pros:
        - Plenty of space for a reasonable sized album cover
    cons:
        - Causes there to be 2 places with song info instead of one

My opinion: Go with 2.  A tiny album cover isn't any better than no
album cover. Yes, there will be two places with song info, but who
would this confuse?  I think a tiny image has more potential to be
confusing to the user than placement does here.

Storage:
1) In the song's metadata
    pros: 
        - It's in the ID3 spec
        - iTunes does it this way
    cons:
        - repetative storage (an album with 12 songs stores the same
info 12 times)
        - I'll be honest here: Rb's metadata support is still flakey
at best.  Malformed ID3 tags are still the number one (maybe only)
reason Rb () crashes for me.

2) Per directory
   pros:
        - done elsewhere (xmms plugins, Rb gdesklet, albumcover, etc.)
        - easy to implement
        - stores 1 cover image per album
    cons:
        - requires the user to maintain a directory heirarchy

3) dot directory mapping
    pros:
        - stores 1 cover image per album
        - doesn't require user to do anything
    cons:
        - Rb specific
        - difficult to edit by hand

My opinion:  I think 1 is the worst thing about iTunes.  And given
Rb's metadata reading problems (which we can't pretend will just go
away), and the newness of its writing, I think having another feature
depend on this would just be silly.  There are no good tools to
hand-edit this on Linux that I know of.  2 would be a great solution
for me as I'm a bit obsessive about my music organization, but I know
there are others who are happy about keeping a flat directory
structure.  Unless Rb did file management ala iTunes, this probably
isn't a good option.

So let's just for the sake of discussion here say we're filing all of
these images with unique filenames in ~/.rbcovers/.  You can't name
them after just the album name since multiple artists have albums with
the same name.  You can't name them artist-album.png because the
compilation album case-scenario would cause problems.  So we could
generate a unique ID for each album somehow in Rhythmbox and store it
in rhythmdb, but then it becomes too difficult to edit by hand.  This
is fine only if I can drag and drop an album cover from somewhere (eg
mozilla) and it always works and it is somehow made clear that a user
can do this.  The reason this is so important is that Amazon isn't
100% here.  I have run into many situations where the right album
cover cannot be found via Amazon or worse, the wrong album cover(s)
are found.

In the end, though, I think these issues can and probably will be
debated ad nauseum as there probably isn't one best solution (we're
not the only ones attempting to address this).  At some point someone
(ahem *Colin* ahem) is probably going to have to lay down an edict 
saying the Rb way of doing it and we'll run with it, or else we'll end
up stuck here in UI debate world looking for an imaginary solution
that solves everyones problems.

--Mike


On Thu, 18 Nov 2004 10:00:17 +0100, Christophe Fergeau <teuf gnome org> wrote:
> This won't work for ogg or flac files (besides I don't like much images
> embedded in id3 tags ;)
> 
> Christophe
> 
> Le jeudi 18 novembre 2004 à 09:45 +0100, Fredrik Noring a écrit :
> > Hi Christophe and Marc
> >
> > ons 2004-11-17 klockan 23:23 +0100 skrev Christophe Fergeau:
> > > It would probably be a good idea to get the various apps using covers
> > > to agree on a common cover cache directory. There were some talks about
> > > a thumbnail managing standard on freedesktop a while ago, dunno if there
> > > is an "official" spec by  now.
> >
> > The ID3 tag supports album pictures. I believe iTunes uses this.
> >
> >    http://id3lib.sourceforge.net/id3/id3v2.3.0.html#sec4.15
> >
> > Pictures can be edited with e.g. a patched version of EasyTAG. The
> > standard allows more than front cover pictures: back cover, leaflet
> > page, artist, conductor, composer, recording location etc.
> >
> > Having the pictures in the ID3 tag is nice because the songs can be
> > moved, edited, copied to other devices and so on and still have the
> > pictures attached like the rest of the metadata (title, album name
> > etc.). A reasonable good picture makes a song about 1-3 % larger.
> >
> > Fredrik
> >
> >
> > _______________________________________________
> > rhythmbox-devel mailing list
> > rhythmbox-devel gnome org
> > http://mail.gnome.org/mailman/listinfo/rhythmbox-devel
> >
> >
> 
> 
> _______________________________________________
> rhythmbox-devel mailing list
> rhythmbox-devel gnome org
> http://mail.gnome.org/mailman/listinfo/rhythmbox-devel
> 
> 
> 
>