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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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
*** This bug has been confirmed by popular vote. ***
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.
*** This bug has been marked as a duplicate of bug 199483 ***
(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.
Sorry, but I don't think this is really a DUP of bug 199483 Re-opening it.
Don't we depend on taglib for that? Then it should be reasigned.
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.
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.
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.
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.
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
(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
The main problem is the playlist. Scrolling or super-long lines aren't really acceptable.
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
(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...
(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.
(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.
(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).
*** This bug has been marked as a duplicate of bug 119539 ***