Created attachment 31200 [details] [review]
Implementation of redesign

This is nice...I only wish Nautilus-Media and Muine could share the same cover
art, but Muine stores the images in a database.

With risk of spamming:
The dialog looks _very_ nice.

Any plans to do the same thing for music files as with images? I mean, what
about using the CD cover as an icon for the music file, just like images and
movies. I'm sure someone would scream very loudly about something like that, but
they could just turn it off. Of course, it's not in the scope of this bug, but I
just wanted to vent the idea.

Could anyone add the "usability" keyword? I don't have the required permission bits.

Added.

Screenshot would be nice here, btw.

Created attachment 31239 [details]
Screenshot of James' patch (AFAIK)

James: I took the liberty of uploading the image from your blog entry at
<http://esco.mine.nu/archive/2004/09/01/serpentine.html>, hope that's OK :)

I like this quite a bit as it seems to add a touch of class. What happend if no
network connection is avaiable to get the coverart? Can you show a screenshot of
that case? All in all I think it is nice :)

Also, have you given thought to a normal string next to the bitrate? So the
bitrate would be listed as Quality instead of bitrate with the value set to
something like "High (149 kbps)" or something similar? Bitrate seems to be a bit
to jargon-ish. 

The label "statistics" and "information" seem unecessary as well, and their
removal would help it not look so busy. 

On the constrary, you might want to add labels for the song title, album name
and artist, as were present in the older properties view as it was not entirely
clear to me from the information there which was wich.

I would also  suggest placing the year of the recording after the album

In response to  Vidar Braut Haarr , I dont think that would be a good idea,
because if you have an entire album on your computer and browse to it, you would
see 14 or 15 thumbnails of the same imgage, and I don't know as that would be
any better usability wise than the current mp3 mime icon. (I would also be
inclined to think it would be a lot slower). 

Created attachment 31258 [details]
A mockup of some more suggestions to improve the UI

This shows some of the suggestions I made, along with an alternate layout that,
I  think, looks less busy. What do you think James? Could you tweak your patch
to produce something like this?

Created attachment 31263 [details]
Intended Direction

I'm currently in the process of rewriting a large chunk of nautilus-media to be
a nautilus extension (possibly adding a "Video" property page as well,
depending on what happened to the Totem audio/video preview page -- AFAIK it
was removed), complete with Columns, Property Pages, etc. Anyhow, this
attachment is what I'm thinking re: the UI now.

The coverart as thumbnail, I think, is a cool idea, but one has to remember
that it is only *really* cool when you've got lots of diverse songs in one dir
(ala C:\My Downloads\My Music). The problem with it is that downloaded songs
typically have horrible tagging, so there's no gaurantee that the coverart
could even be found. Bottom line: I'm in favor of it (and the
nautilus-extension can attach the the little "Music" emblem to clear up any
confusion), so long as the "find metadata" code is improved to at least try to
find info for un-tagged media.

The "expensive-ness" is (IMO) just a call to musicbrainz, and one can simply
store a thumbnail of the original coverart URI and just copy it when a song is
discovered to need it. And seriously, gst-thumbnail is already pretty expensive
:-)

In response to your comments on my little idea.
dowem:
Yes, you would see 14 or 15 thumbnails of the same image :) But that already
happens with regular icons. I don't see how this can be different. On the other
hand, whether it is better usability-wise or not, I don't know. I just know that
some times (especially the case James mentions) it would be really useful.
Remember that we easily make associations with images, but not that easily with
text.

About the slowness, I don't think that would be an issue, as the whole thing is
really slow already. In addition, it is done sequentially, and you don't need to
wait for it if you don't want to.

James:
Thanks :) I agree, it is most cool when you've got "My Music". So, why not study
the usecases? When looking at my two brothers and my parents (that's 3
computers), they all have it that way. The only ones I know that have extensive,
sorted music libraries are "nerds".
I see the problem with the tags :/ One of the guys at work even *removes* the
tags on audio media (!). But if the cover-art can't be found, just as with video
media that nautilus-media doesn't understand, it will just show the proper
MIME-icon.

As to the "expensive-ness" :) Does nautilus-media cache these images? If not,
that should be done.

Does anyone feel this idea and related issues warrants its own bug?

Personally I'm not too fond of this idea.  Lots of tracks are on more than one
album.  Cover art is copyrighted, I have my doubts about the legality of doing
this.  And musicbrainz gets tracks wrong about 5% of the time.  A feature like
this belongs in a player, not a file browser.

Those are good points, but: (1) the image will be fetched for the album in
question. If the song has no album that can be extracted from either its
metadata or the filename (if that is made possible), then it should retain its
regular MIME-icon, (2) it is copyrighted, yes, but isn't movies copyrighted as
well? I'm thinking about the thumbnail feature. What about Muine, it shows the
album covers all over? (3) Whether or not the technology is adequate or not
shouldn't stop us from discussing the possibility, IMO, and (4) nautilus already
has "special handling" for lots of types. I don't see how this is different.

In any case, I've opened bug 151921 for further discussion on this topic. Sorry
for cluttering up the bug, James :)

Thomas, did you mean using coverart as a thumbnail, or using coverart period?

Vidar:
(1) why not get a picture of the band ? what if it's on multiple albums ? what
if it's just a piece of audio, not some song on some album ? why is something
that is at best not directly related to the file in question important enough to
take such a big part of the UI ?
(2) the movie is already on your disk.  you're using the data already available.
 In the case of the cover, you're downloading something copyrighted from the
internet automatically.  It's the same as when you would be downloading
subtitles or covers for DVD's automatically - AFAICT they're copyrighted.  So
it's completely different from getting one frame out of o movie on your disk.
(3) Feel free to discuss the possibility :)
(4) special handling != functionality that is unrelated to the file manager.  I
don't see why a file manager should download stuff from the net that's in some
cases only a little related to it.  This is functionality that is supposed to be
in an application.

James: Personally, yes, I don't think cover art should go into nautilus.  In any
music application it seems like a nice feature if correctly implemented (which
is currently still incredibly hard, and is part of my ten year plan to get
right, but not in nautilus)

Thomas: I replied in bug 151921. If you'd like to keep the discussion here for
some reason, that's fine with me - I'll re-post it here :)

Why don't you cover art in nautilus at all - is it the copyright issue ? If so,
someone should investigate whether its true or false.

I guess I don't see coverart as unrelated functionality, since the functionality
of the "Properties" page is "show me metadata about a file." If the file is a
digital representation of a CD track, then showing what the CD case looks like
(if you saw it in a record store, for example) is related. IOW, the file manager
is already showing (mostly) metadata, and coverart is metadata, so why not show
that too?

Regarding the difficulty in getting it to work properly (perfectly), IMO this is
akin to the fact that tags on an MP3 or OGG file may be inaccurate -- and the
tags are shown even though it can't verify that "somefile.mp3" is actually "Some
Song", by "Some Band", off the "Some Album" disc? I know for a fact I've seen
more incorrect tags than incorrect coverart...

the file manager shows metadata that is *in* the file.  Not metadata that it
downloads off the internet.  All other info you can see in the file manager is
gotten from data that is *in* the file. That is a clear difference IMO.

Also, you are building a reasoning on the premise that an audio file is coming
from a CD, and from only one CD.  Like I said before, this is not always the case.

Further, if tags are wrong, the goal is to have the property view to allow you
to edit them - which it will do when it can nicely be done from nautilus,
because for that you have to rewrite the file.

I'll put this bluntly - if you've seen a lot of incorrect tags, it's because
you've downloaded your music off of the internet.  If you had grabbed the music
of your own CD's, the application doing the grabbing would have gotten the tags
right.

By the way (and unrelated) - in the past there has been some resistance to
having musicbrainz inserted in the GNOME platform.  Personally I think something
like musicbrainz has its value, just letting you know beforehand.

There is a functional difference between metadata stored with the file and that
stored externally, but IMO that difference is one of those ugly technical
details users don't care about. As programmers we may *have* to care about it,
but the users certainly don't.

So far as songs coming from more than one CD, assuming there's an "Album" tag
somewhere (and it's correct), then the app knows what CD the track came from,
and thus doesn't have to worry about incorrect cover art.

So far as my "downloading", I have 12.2G in ~/Music, of which I've downloaded
182M -- and only 15 songs in that are purchasable (I refuse to pay $15 so I can
listen to "You Know You're Right", particularly since I already own copies of
every other song on that CD), the rest is live recordings and wierd spoken word
stuff -- things you can't buy if you tried. IOW, various record labels now have
somewhere in the range of $3-4k of my money, total.

However, I also know quite a few people who took advantage of their high-speed
internet connections in the dorms to download a couple thousand songs, and many
of those songs were improperly tagged. So, I've seen a lot of incorrect tags
because I've seen a lot of people's computers which had incorrectly tagged MP3s
on them. As you mentioned, tag editing would allow them to fix that problem,
just as it would allow someone like me to fix typos they didn't notice when
ripping a CD they own.

Anyhow, it may very well turn out that putting cover art into the properties
dialog won't fit if the tag editing is in the dialog (which it should be), but I
think that UI requirements should be the deciding factor on whether or not it's
done, not an arbitrary technical separation. And, for the record, I'm still in
favor of cover-art thumbnails, I think they'd be pretty cool (and easy to
optimize if you thumbnail the the source URI).

According to hadess the Totem audio/video properties tab is alive and well, see
bug 153174.

I was going to file a bug because some strings in the Audio properties tab
appear untranslated, but with the redesign this might already be fixed? Please
let me know.

is that still an issue or totem does this correctly now?

The new design doesn't appear to be integrated yet (nautilus 2.10, totem 1.1.1).

nautilus-media does not build against GNOME, and totem looks as though it will
provide the media page, so this bug is (AFAIK) irrelevent.

Indeed. Sorry that your efforts weren't honored, James.