Bug 137756 - amaroK won't read more than the first ARTIST tag in OGG Vorbis files
Summary: amaroK won't read more than the first ARTIST tag in OGG Vorbis files
Status: RESOLVED DUPLICATE of bug 119539
Alias: None
Product: amarok
Classification: Applications
Component: Collections/Local (show other bugs)
Version: 2.0-SVN
Platform: Ubuntu Linux
: LO minor
Target Milestone: ---
Assignee: Amarok Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-11-23 04:22 UTC by Robert Grønning
Modified: 2013-01-02 17:11 UTC (History)
11 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Grønning 2006-11-23 04:22:43 UTC
Version:            (using KDE KDE 3.5.5)
Installed from:    Ubuntu Packages

amarok 1.4.4 won't AFAIK read more than the first occurence of ARTIST tags in Ogg Vorbis files.

vorbiscomment doumentation: http://xiph.org/vorbis/doc/v-comment.html

In this documentation they encourage the use of several ARTIST tags if necessary, this is a very neat feature since much music is created as a collaboration between bands (ex. Linkin Park feat. Jay-Z)

Changes that would have to be made to amaroK:
  Tageditor should be able to read all artist in the file
  Tageditor should be able to append new artist's to the file
  In the playlist the Artist field should contain something like this:
    ARTIST1, ARTIST2, ARTIST3, ARTIST4 & ARTIST5
    or it could display the same but without the '&' between the two last artists.
  The collection browser should display each artist separately

this might be the issue with id3v2 tags too, but AFAIK id3v2 only supports 4 predefined artists.

This is posted as a bug since amaroK supports ogg, and currently isn't displaying it correctly.
Comment 1 Erik Hovland 2006-11-27 20:17:51 UTC
Currently I use this behavior as a feature. On albums like say "Ball Hog or Tugboat" there is one consistent artist (Mike Watt). If I make sure that he is the first artist tag then amarok correctly associates the right cover art with the song. If this bug were to be worked on, it sure would be polite to consider this situation.
Comment 2 Mark Kretschmann 2006-12-09 00:03:48 UTC
Hmm you see, we support many tag formats, and we have to make it all fit into one unified GUI. If ogg supports multiple Artist tags, but none of the other formats support it, then I don't see how we would support this.

I don't think we'll implement this, sorry.
Comment 3 Robert Grønning 2006-12-09 01:43:32 UTC
mp3's id3 tag supports 4 artist
ogg's vorbiscomment supports seemingly unlimited artists
flac's afaik uses vorbiscomment and supports the same amount af artists
i don't know about the wma tag's since i can't seem to find any information on it.

There should be a serious consideration to add this feature to amarok, the need for several artist tags has been there for as long as artist's have cooperated, id3 and vorbiscomment has made a solution to it, and amarok should take advantage of this, sooner or later some audio-player will adopt this feature.
Comment 4 Thomas 2007-02-28 19:02:43 UTC
The %album artist% tag is the one to use for that.  Also, %album artist% may contain "Various Artists" to put it under that one collection.   Foobar2000 (sadly only for windows) has the best handling of these tags.
Comment 5 Thomas 2007-02-28 19:10:47 UTC
BTW, it does constitute a dataloss issue if Amarok is used to update or accidentally update a collection of oggs or flacs that have been tagged using the mentioned separate tag method.  It discards all the extra artist fields, or duplicate fields and only writes one containing the first value.

Also, freedb recommends splitting the artist into mulitple artist entries like this for proper cataloging as well. 

Please reconsider fixing.   
Comment 6 Robert Grønning 2007-03-05 07:58:00 UTC
There are clear advantages in adding this feature to Amarok, and it's clearly possible to do this, only con I can think of is that the collection-scanner would have to be rebuilt.
I think it's inappropriate to close this bugrapport without giving a good explanation on why this bug won't be fixed since this bug obviously (referring to the comments and description) should be considered unless you have a good reason for why it shouldn't be.
Unless there's someone willing to explain further I'll reopen this bug.

Ps. %album artist% on a track should tell the artist of the album, seems very obvious to me.
Comment 7 Alexandre Oliveira 2007-03-05 13:06:37 UTC
If you reopen, we'll "reclose" it. Sorry, the explanation is on comment #2, plus the fact it's something for taglib, and not Amarok.
Comment 8 Robert Grønning 2007-03-05 15:01:02 UTC
I've asked for some guidance at the TagLib mailinglist, I asked if this bugrapport rather should be a feature request towards Taglib and got this answer:

--- quoting  ---
No, TagLib already does support this. Also, comment #2 is wrong. All
file format implementations in TagLib can handle multiple values as
well.
--- stop quote ---

I also believe Comment #2 is invalid since mp3, ogg vorbis and ogg flac support multiple artist tags, these formats are the most frequently used GNU/Linux formats and should be fully supported by amaroK.
Comment 9 Robert Grønning 2007-03-26 23:59:44 UTC
ID3v2.3 supports multiple artists by putting all the artists inside TPE1 and separates them with the "/" character.

ID3v2.4 also supports this, but uses a NULL byte to separate the artists instead of the "/" character.

I'll try to find some information on WMA's tagging support.
Comment 10 Robert Grønning 2007-03-27 11:01:45 UTC
APEv2 supports and handles multiple artist values in the same way as ID3v2.4 does.

Reference:
http://wiki.hydrogenaudio.org/index.php?title=APE_key
http://wiki.hydrogenaudio.org/index.php?title=APE_Item_Value
Comment 11 Robert Grønning 2007-03-27 12:05:02 UTC
ASF and Native FLAC supports and handles artist values in the same way as vorbiscomment does.

Given that I've understood the specifications on these frequently used container formats correctly, this is the resulting list of containers and codecs that supports multiple separated artist values/tags:

<Container>
  <Codec covered by Container> (<common file extension>)

APEv2
  Monkey's Audio (.APE)

Advanced Systems Format
  Windows Media Audio (.WMA)

ID3v2.3 & ID3v2.4
  MPEG-1 Audio Layer 3 (.MP3)

Native FLAC
  Free Lossless Audio Codec (.FLAC,)

vorbiscomment
  Ogg FLAC (.OGM)
  Ogg Vorbis (.OGG)
  Ogg Speex (.OGG)


Imho this list covers all the most commonly used audio containers, I sure hope some developer(s) share my interest in altering Amarok to read the artist tag(s) correctly.


Reference:
http://msdn2.microsoft.com/en-us/library/aa384500.aspx
Comment 12 Erlend Hamberg 2007-03-27 15:36:47 UTC
*** This bug has been confirmed by popular vote. ***
Comment 13 Michael Leupold 2008-06-15 10:33:46 UTC
Amarok 1.4.x is in bugfix-only mode as development is focused on Amarok 2. Unfortunately your feature request can not be implemented in Amarok 1, as Amarok developers do not have the resources for it and risk of regression would be too high. I am therefore moving your request to Amarok 2. I cannot make any guarantee as to whether is will get implemented there or not though. Thank you for your report.
Comment 14 Myriam Schweingruber 2009-08-03 11:30:53 UTC

*** This bug has been marked as a duplicate of bug 199483 ***
Comment 15 Kenneth Perry 2009-08-03 13:39:02 UTC
(In reply to comment #14)
> 
> *** This bug has been marked as a duplicate of bug 199483 ***

Can you please comment on what this has to do with bug 199483? Bug 199483 seems to be Album Artist vs Artist while this is about multiple Artist tags in one file.
Comment 16 Elias Probst 2009-08-21 02:34:09 UTC
Sorry, but I don't think this is really a DUP of bug 199483
Re-opening it.
Comment 17 Myriam Schweingruber 2009-08-24 11:31:47 UTC
Don't we depend on taglib for that? Then it should be reasigned.
Comment 18 Robert Grønning 2009-08-24 17:53:23 UTC
reply to comment #17)
> Don't we depend on taglib for that? Then it should be reasigned.
taglib handle APEv2, ASF, ID3v2.3, ID3v2.4, Native FLAC and vorbiscomment correct, Amarok doesn't.
Comment 19 Jeff Mitchell 2009-08-25 14:24:13 UTC
Until someone comes up with a good (meaning, clean and usable) way to display multiple artists for a track in the playlist *and* the collection browser, we don't support more than one.
Comment 20 Robert Grønning 2009-08-25 23:21:10 UTC
3 example songs:

  Artists: Elvis
  Album: In the Ghetto (1969)
  Track: In the Ghetto

  Artists: Elvis | Lisa Marie Presley
  Album: In the Ghetto (2007)
  Track: In the Ghetto

  Artists: Common | John Legend | Kanye West
  Album: They Say (2006)
  Track: They Say

How this should be displayed in the Collection browser:

  -Common
    -2006 - They Say
      They Say
  -Elvis
    -2007 - In the Ghetto
      In the Ghetto
    -1969 - In the Ghetto
      In the Ghetto
  -John Legend
    -2006 - They Say
      They Say
  -Kanye West
    -2006 - They Say
      They Say
  -Lisa Marie Presley
    -2007 - In the Ghetto
      In the Ghetto

The playlist should allways display all the artists instead of just the first artist, example:
Artist 1, Artist 2, Artist 3, Artist 4 & Artist 5

When there is no more visible space in the GUI to display all the artists:
 1. Use textscroll
 2. Display as many characters as possible and append "…", display the rest on mouseover.
Comment 21 Ryan Saunders 2009-08-26 06:49:54 UTC
I agree with Robert. I don't see any problem (from a user's perspective) of having the same song appear multiple times in the collection browser, if the tree view is sorted based on artist name...that's what I'd expect.
Comment 22 Elias Probst 2009-08-26 10:11:10 UTC
I second that. I don't see any problem displaying a track multiple times in the collection browser, listed for multiple artists.

Some user feedback should be given, if such a track is removed/"managed" - the user should be warned, that "multiple artists" are affected by this operation.

Regarding the playlist browser, the artists could be listed alphabetically like proposed by Robert Grønning.
When it comes to aggregating (display an album, etc.), the album artist should take precedence, so the other artists, no matter whether they are actually first in alphabetical order, should appear from the 2nd position on.

Regarding the editing of metadata, I'd like to point to the mockups I did quite some time ago for Amarok 1.4.x. See https://bugs.kde.org/show_bug.cgi?id=119539#c30
Comment 23 Robert Grønning 2009-08-26 11:29:07 UTC
(In reply to comment #22)
> Some user feedback should be given, if such a track is removed/"managed" - the
> user should be warned, that "multiple artists" are affected by this operation.
I don't see the necessity of this, if you remove a track, it doesn't affect anyhing else.

> When it comes to aggregating (display an album, etc.), the album artist should
> take precedence, so the other artists, no matter whether they are actually
> first in alphabetical order, should appear from the 2nd position on.
This could be solved by sorting the artists after how many songs they've contributed to in that specific album. if 50:50 then fall back to alphabetical sort
Comment 24 Jeff Mitchell 2009-08-26 12:16:04 UTC
The main problem is the playlist. Scrolling or super-long lines aren't really acceptable.
Comment 25 Dario Panico 2009-08-26 13:00:10 UTC
in the playlist should be displayed only TPE1 (id3) artists (usually no more than 2) so artist lines wouldn't be extra-long

the longest string I can think is like:

Red hot chili peppers - The good, the bad & the queen

Not that log for a one third of a 15" monitor
Comment 26 Myriam Schweingruber 2009-08-26 13:27:13 UTC
(In reply to comment #25)
> the longest string I can think is like:
> 
> Red hot chili peppers - The good, the bad & the queen
> 
> Not that log for a one third of a 15" monitor

Well, unless you listen to classical music:

"Symphonieorchester des Bayrischen Rundfunks - Jugendchor des Landkreises Fürstenfeldbruck"

I made this actual combination up, but it is far from unlikely in classical music. Also you shouldn't forget that Amarok also runs on Netbooks, and you don't always have a 12" monitor...
Comment 27 Christian Pontesegger 2009-08-26 13:53:17 UTC
(In reply to comment #26)
> Also you shouldn't forget that Amarok also runs on Netbooks, and you
> don't always have a 12" monitor...

Isn't this discussion some kind of academic?
Without using the multiple artist "feature" of ID3v2 I could simply create an artist frame of 2^32 bytes length (without some stuff for the header).
So what will amarok display for a very long "only one artist" ID3 frame?
I would suggest to do the same for an accumulated multiple artist string.

Actually there is no difference. If I remember correctly ID3 suggests to separate artists by a '/' and put them all in the same frame. Its more a question whether the database in the backend takes care of those multiple artists. Right now it can get quite messy if you think of artists like

Eminem
Eminem ft. DMX
Eminem vs. whatever

which end up as separate artists in the database.
Comment 28 Robert Grønning 2009-08-26 14:27:29 UTC
(In reply to comment #24)
> The main problem is the playlist. Scrolling or super-long lines aren't really
> acceptable.
What does Amarok do in cases like the one described by Myriam Schweingruber:
"Symphonieorchester des Bayrischen Rundfunks - Jugendchor des Landkreises
Fürstenfeldbruck"

I agree with Christian Pontesegger that Amarok should handle multiple artists the same way it handles too long artist names.

How about adding a newline between each artist, so it'll take up vertical space instead of just horizontal space? that might look very good designwise (imho)(In reply to comment #27)

> (In reply to comment #26)
> Actually there is no difference. If I remember correctly ID3 suggests to
> separate artists by a '/' and put them all in the same frame.
See comment #9, #10 and #11 for more info regarding different containerformats way of handling of multiple tagvalues.
Comment 29 Xiong Chiamiov 2009-08-26 17:24:33 UTC
(In reply to comment #24)
> The main problem is the playlist. Scrolling or super-long lines aren't really
> acceptable.

I don't see why this is a problem, considering that we'd be going from "Elvis & Lisa Marie Presley" as an artist name to... "Elvis & Lisa Marie Presley".

(In reply to comment #28)
> How about adding a newline between each artist, so it'll take up vertical space
> instead of just horizontal space? that might look very good designwise
> (imho)

Eh, newlines will play bloody hell with non-default playlist layouts.  For instance, while I was using Amarok 2, I had adjusted it to look a lot more like Amarok 1.4, with each track on one line.  Pushing newlines in would defeat the whole point of that (which is, btw, to be able to vgrep, but that's a tangent that doesn't need exploring again).
Comment 30 Matěj Laitl 2013-01-02 17:11:06 UTC

*** This bug has been marked as a duplicate of bug 119539 ***