If we don't assign this wishlist, we'll get in trouble with "The Binner"

*** This bug has been confirmed by popular vote. ***

*** Bug 93980 has been marked as a duplicate of this bug. ***

This is a truly colossal amount of work.

.. but it'd make amarok even more outstanding than it already is :)

*** Bug 114349 has been marked as a duplicate of this bug. ***

It also happens that '&' is used as artist separator.

BTW: what about changing this bug title to sth a bit more meaningful? 

*** Bug 115519 has been marked as a duplicate of this bug. ***

Dont forget 'ft.'
I am so glad I did not double-post :-D

I would suggest leaving either the Ampersand (&) or the word "and" meaning nothing (ie, just leave it as is, don't apply a meaning to it) . This because some artist names contain an ampersand of "and": Bob Marley & the Wailers, Me First and the Gimme Gimmes, Cliff Richard and the Drifters / Shadows, and a lot more I don't care to mention. Most, if not all, of these artists / bands have no "solo" releases... (Grouping Cliff Richard's Shadows & Drifters might be a good but difficult idea, but in any case it would be nonsensical to let Drifters and Shadows show up in the artist list seperately, since they don't exist without Cliff Richard.) 
Perhaps sign words like "Ft.", "Vs." and "... Remix" / "Remixed by ..." (or similar) would also be good choices.

Also, this bug / feature request was merged with mine, so I would like to state the other part of my request, which is of similar nature: 
Give songs a (possible) one to many relation to albums, when songs appear on multiple albums / compilation (something that happens quite often in fact): 
(example from my own request: "Some songs appear on multiple albums by the same artist, eg on a studio album, and on a best of album, and on a compilation. All three songs are completely the same, so it is a waste of disc space to have them thrice. Instead, setting album to "Album-Title, Best of Artist, Genre Jewels" should list the song in all three albums.)"
This would also allow the context panel to show information / track listings about all album's a (version of) a song appears on.

3rd point, I make it up at this moment:
Give songs a "Live" checkbox, or a "Studio / Live / Cover" checklist, to avoid confusion between live versions and studio versions of songs. This seems quite easy, but could also be solved by setting the title "title (live)" as user.

Further thinking gave new ideas, because my previous suggestion of multiple albums per song gives complications when the track has more than one number... better would be merging the tracknumber and album fields, allowing (unformatted) entries like 

"Album A":3,"Album B":9,"Best of Artist":10,"Definitive Genre Collection":1

Which would let the track appear on all 4 albums with the respective tracknumbers.

Nice ideas, but I don't think there are "portable" though..

Musicbrainz could be queried for much of this data. It now supports <a href="http://wiki.musicbrainz.org/AdvancedRelationshipsDocumentation">Advanced Relationships</a> which means it now collections and organizes this type of information. 

http://musicbrainz.org/showartist.html?artistid=16007 is an example of some of this information. It displays a collaboration between artsits, and gives the real name of these artists.

In my opinion, better handling for name prefixes (ignore DJ and MC, some others perhaps, completely in the artist name?) is also needed, for example DJ Hixxy should be same as plain Hixxy.

The above comments suggest heuristic methods which may work well for one person and not for another. Finding exceptions to those rules is very easy. Heuristics are supposed to make Amarok "just work", but when we cannot turn the heuristic on by default, this goal is lost.

For example, when talking about ignoring DJ and MC prefixes, the end-user could just as well right click one of the alternative spellings of this artist, Edit Information and solve the inconsistensy to whatever style he/she prefers. This is a one-time step, and the effort it involves is less than the danger of applying a constant heuristic.

In contrast to that, separating artists by commas etc. is a feature which is not merely a "lazy" way of doing something; there's really no way to do this in the current Amarok and it is indeed desired. However, did you consider not applying a constant text-based heuristic, but instead starting to use one of the ID3v2 Involved persons frames (section 4.2.2)? Sure, heuristics could be the next step, but it needs to build on top of a stable effort-involving way.

*** Bug 127254 has been marked as a duplicate of this bug. ***

Since automatic parsing of multi-artist names is very hard and not likely to happen in amaroK anytime soon, maybe a partial solution could be implemented instead. As suggested in comment #3 to bug 127254, an "album artist" tag could be used to the list of tags recognized by amaroK. It would then be possible to sort the music collection not only by "Artist / Album", but also "Album Artist / Album", thus filing an album under one artist's name regardless of who is named as in the "artist" tag of the individual tracks. Common use cases this would solve are:

1. An album by Alice where one track is by "Alice featuring Bob". Currently, such an album can either be marked as a compilation and thus listed under "Various Artists" or not, in which case most of the tracks will appear under "Alice" and one lonely track will be listed under "Alice featuring Bob". Clearly, filing the entire album under Alice's name is desirable.

2. An album mixed by DJ Alice containing songs by Bob, Eve and many other artists. Each track should retain its original "artist" tag, but the entire album should be filed under "DJ Alice". It should *not* go under "Various Artists", as the mix is clearly associated with one DJ and should be listed under their name.

I see three shortcomings in this approach:

1. It is not automatic - the user will need to set the "album artist" manually. Clearly, there is no way around this short of implementing smart automatic parsing, which this proposal is trying to avoid.

2. It does not allow for a 1-to-N relationship, thus a track by "Alice feat. Bob" will be assigned to Alice only, not to Bob. This should be OK in most cases, as if Bob is involved with a single track on Alice's album, he is probably playing a minor role. 1-to-N would still be nice, but much more complicated (in terms of implementation as well as usability).

3. There is no standardized way to store the "album artist" in common music file formats. I have found suggestions to use either the TPE2 (Band/Orchestra/Accompaniment) or TXXX (User defined) tags for MP3 and a field name of ALBUM ARTIST for Ogg Vorbis. All of those seems to have been implemented in various pieces of software, but there is no common standard. AmaroK should probably go with what is most widely used out there, increasing chances for a standardization on that approach.

Despite it not being perfect and not solving all problems, I think this idea is sufficiently simple to implement and fixes enough problems to be considered for the next version of amaroK.

This is a special case of:
bug 119539 - Request: Support for multiple genres / artists / composers / etc. (113 votes)

(Albeit this bug has been around much longer...)

Many of the things mentioned here (like how & and 'and' should not be used as delimiters) have been mentioned in bug 119539 as well.

The only sensible way of implementing this wish is with decent MusicBrainz integration. Without human-edited data how else could you possibly differentiate between "Bob Marley and The Wailers" and "Green Day and U2"?

For instance by applying some convention. Like using , to separate artists...

Plenty of people tag music in many ways, one can not expect all those tags to be alwyas interpreted correctly. But there should be *some* way to tag music and have it working correctly...

Instead of having every Amarok user retag their music via this proposed new method, MBIDs should be implemented in Amarok (as suggested in bug #122281). People can then automate their tagging with MusicBrainz Picard and Amarok could quite simply list tracks under the correct multiple artists. Seriously, look into MusicBrainz, it could provide a relatively simple solution to this problem.

Scratch that, bug #122281 is about submitting MBIDs to last.fm, completely irrelevent here. MBIDs are in the already in your files if you tag via MB.

I have recently switched from MP3 to Ogg Vorbis and in the process discovered that Vorbis has a very nice and simple way of handing multiple artists built in. Quoting from http://www.xiph.org/vorbis/doc/v-comment.html:



Field names are not required to be unique (occur once) within a comment header. As an example, assume a track was recorded by three well know artists; the following is permissible, and encouraged:

              ARTIST=Dizzy Gillespie 
              ARTIST=Sonny Rollins 
              ARTIST=Sonny Stitt 



This way, software reading an Ogg Vorbis file does not have to parse and split a human-readable string but instead directly reads a list of artists from the media file. I have tagged all my Ogg files in this way. While Amarok only shows the first artist and ignores the additional entries, I think this is the way forward - make the artist information a list of strings and store it as such in media files. I don't have a good idea of how to do this for MP3, but for Ogg, it seems easy.

as noted in comment 18, bug 119539 would provide much better solution.
besides, it sorta has been decided not to implement parsing of arbitrary characters or words (like commas, semicolons, ampersands or "featuring").

(New member & first-time poster)

Two cents worth:

Should the focus be Amarok itself or the (currently optional) sql backend?

If you lump these requests into "Advanced Features" that require an sql database, then you can shift the focus of the effort to designing the database.  Then programming the frontend (Amarok or any other) becomes relatively simple.

Re comment #25:

As far as I am aware, Amarok *requires* an SQL database. You just have the choice of which backend to use, but you must pick one. And of course you are right - the database tables must be redesigned to make space for multiple artists before the GUI can support this feature. I am hopeful that this will happen some day and am using multiple artist tags in all my ogg files already (see comment #23).

Another (better?) long-term solution to this problem is to take advantage of ID3v2.3 and ID3v2.4's ability to contain several separated artists.

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.

Apparently all the popular audio containers supports separated artists in their tags (APEv2, ASF, ID3v2.3, ID3v2.4, Native FLAC and vorbiscomment).

I've reported bug #137756 with more information regarding this, and hope that the Amarok developers will implement this feature, there's no other music playback app afaik that takes advantage of audio containers multiple separated artist support.

The audio containers listed above also supports multiple tags/values other than the artist tags/values.

This would really set Amarok apart from the rest of the players.

http://bugs.kde.org/show_bug.cgi?id=137756

and regarding comment #27 it could be great if amarok could deal with all the 4 kind of TPE tag:
(from kid3)
TPE1: Lead performer(s)/Soloist(s)
TPE2: Band/orchestra/accompaniment
TPE3: Conductor/performer refinement
TPE4: Interpreted, remixed, or otherwise modified by

and manage them in the collection in different ways.

example:
Tagging
TPE1: Gwen Stefani
TPE4: Akon 
TALB: The sweet escape
TIT2: The sweet escape
Context browser when playing a song of one of those artist (not necessary this one)
Gwen Stefani
*her albums*
...
The sweet escape
*compilation featuring her*
...
*her participations*
...
Akon
*his albums*
...
*compilation featuring him*
...
*his participations*
The sweet escape
...

Hi folks,

i think there sould be support for conepts like multiple artists, different albums and tracks and so on. However i don't think that effort should be put in supporting all these mechansisms for a metadata format like id3 which simply is unadequate for doing such things. Every heuristic to parse an id3-part of an mp3 would, in my opinion, merely be an insufficient hack. So I would even go that far to say WONTFIX (to point 1. and 2. of the inital Bug-report): Due to the shortcomings of id3. WORKARAOUND by converting your files to e.g ogg-vorbis as the amarok developers will implement mechanismes for handling concepts as multiple atrists for adequate formats only. These formats will be: format1 format2 and so on

Point 3 of the initial bug: The problem of homonyms and such things could in my eyes only be overcome with a semantic web or an n to m relation for homonyms in the amarok databse 

Eventually, parsing some sort of data according to some heuristic would simply cause several follow-up bugs/whishes

Cheers

Phil

> WORKARAOUND by converting your files to e.g ogg-vorbis

This means some loss, unfortunately. Loss of the music quality. MP3 and OGG are not lossless formats. Rather noticeable price for the simple textual classification. Not to mention the cost of such conversion when a lot of songs are to be handled.

I do not quite understand why using some rare character as separator would be so troublesome. But if so, then the better idea is to handle adding separate 'stickers' to the mp3 files (so blahblah.mp3 may have metadata saved in blahblah.meta or sth similar). 

Well ok , u're right that convering means a loss of quality and that it is effort to do.

The idea of attaching a metafile...
Well, that's what the database should be for.
I know the meatfile would have the advantage of beeing portable in a quite simple way...
However, even if the metafile was easy to copy it didn't mean that other applications would be able to handle it (nor would they be able to handle some rare character as a delimiter for multiple artists). And before we start to convince them to support such hacks we should rather convince them to use a differnt format of metagging. (e.g an existing format or a new format, yet to be developed, some XML coul be ideally used to serve that purpose). Swapping an id3-tag against some other metatagging format should be easy, as even id3 is not an offical standard of an mp3, as wouldn't be any other tagging format...

<a href="http://bugs.kde.org/show_bug.cgi?id=90095#c28">Comment #28</a> seems to have the best solution.  The idea of converting my 15,000ish mp3's to ogg vorbis is just not something that is going to happen. I don't mind however retagging my files over time.  The simplest solution may be just tagging the id3 artist tag with all the artists name separated by slashes "Gwen Stefani/Akon" artists are "Gwen Stefani" and "Akon", and allowing for a double slash "//" to be treated as a single slash as part of the artist name.  So "Gwen Stefani//Akon" the artist would be saved as "Gwen Stefani/Akon".  It would be simple enough to throw this in the options so it could be turned on or off.  Of course as mentioned, the database design still needs to be done first.  This was also mentioned in <a href="http://bugs.kde.org/show_bug.cgi?id=90095#c27">comment #27</a> that this convention is already used by some players.  I would also agree that the multiple artists in the ogg vorbis tag should be supported as well.

in relation with my previous comment (http://bugs.kde.org/show_bug.cgi?id=90095#c28) I'd like to say a pair of things:
1. Have you ever tried kid3? It's a complete and powerful tag editor (different function than amarok) but with a (a lot) simplified interface it could be able to allow user to do more complex things 
e.g. 
amarok tag editor
artist field: <userinput> option "Add artist" >> Drop down menu with option to explain in a simple way TPE2, TPE3 and TPE4 and let user choose in which one he has to put the artist name he wants to add.
2. When Amarok2 will come to life it will have to deal with strigi (I suppose) and using it power to organize artists, albums and songs realtionship could be a BIG improvement to a more human handling of informations.
e.g. I really don't know :-) use id3 tag as strigi tag i.e. manage them in the same way
3. This issue has to be extended to song-writers.
e.g. Alice sings a song written by Bob
it has to appear in realtion to Bob, Bob has to be in my collection, it could happen in different ways: Bob is only a song-writer, Bob sings his own song, Bob sings other songs.
In italian music it happens quite often that a famous singer writes a song for another one, maybe featuring him and this way the song has to be related to both artists.

https://bugs.kde.org/show_bug.cgi?id=137756#c11 :
------------------------------------------------
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.
------------------------------------------------
Multiple artists is supported in the following containers: APEv2 (.ape), ASF (.wma), ID3v2.3 (.mp3), ID3v2.4 (.mp3), NativeFLAC (.flac) and Vorbiscomment (.ogg and .ogm).

This is the real long-term sollution, instead of trying to "detect" multiple artists (Remember there are more languages than English).

Here is the main bug:
https://bugs.kde.org/show_bug.cgi?id=137756

So to sum up, here is a proposed solution:

1. Add one-to-many relationships between songs and artists, and albums and artists. This would most likely be a major refactoring in the database design and collection code.
2. Add per-format ways to store multiple artists. OGG files can use multiple artist tags, while MP3 files use the standard "/" delimeter, etc. I don't see any problems with using a slash to separate artists.
3. Modify the interface accordingly.

That, in my opinion, should be the scope of this feature request.


Auto-detecting multiple artists from nonstandard tags could be an optional feature that the user can run on his/her collection to have it parse things like "Ft." and likewise in arist tags, turn them into a standard format, and update the database. This way all the "guessing" code will be optional and only used when the user says to. The rest of amarok operates on the standard (format-dependent) ways of separating artists. This comes later.

MusicBrainz was brought up as a way to find out automatically (and faultlessly) about multiple artists. This too should be a separate proposal, as it builds incrementally onto the proposed solution I outlined.

Tyler, this is all very well, but this bug is form Amarok 1.4, which is not maintained anymore. You should have a look at bug 199483 instead.

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

Ah well much of it applies to Amarok 2 as well, and this bug is much more general than bug 199483. There is still no handling of multiple artists for a track (album is different). Marking it as a duplicate ignores the larger (and still relevant) scope of this bug. bug 119539 is an even more general bug that includes multiple genres, etc. support and is inclusive of this bug, but it was probably also from 1.4.

#36
why not to change the version? this bug is clearly more complex and general than #199483

This cleary is not a duplicate of bug #199483. As pointed out in several comments, it deals with a different issue altogether (multiple artists *per song*). Also, the bug definitely is still there in Amarok 2. Reopening.

I have several thousands of mp3 songs, without any sort of metadata infomation (ID3 tag) attached, with the following filename format:
   "<Artist Name> - <Track Name>.mp3"


As this is a pretty standard filename format for mp3 songs, one would expect Amarok could retrieve the artist and track from file name in order to obtain album covers, lyrics etc. Sadly, Amarok wasn't able to do that...

Any thoughts ?

(In reply to comment #40)
> I have several thousands of mp3 songs, without any sort of metadata infomation
> (ID3 tag) attached, with the following filename format:
>    "<Artist Name> - <Track Name>.mp3"
> 
> As this is a pretty standard filename format for mp3 songs, one would expect
> Amarok could retrieve the artist and track from file name in order to obtain
> album covers, lyrics etc. Sadly, Amarok wasn't able to do that...

Which Amarok version are you talking about? This report is about the developer version Amarok 2.2-git. Are you sure you talk about the same one?

(In reply to comment #41)
> (In reply to comment #40)
> > I have several thousands of mp3 songs, without any sort of metadata infomation
> > (ID3 tag) attached, with the following filename format:
> >    "<Artist Name> - <Track Name>.mp3"
> > 
> > As this is a pretty standard filename format for mp3 songs, one would expect
> > Amarok could retrieve the artist and track from file name in order to obtain
> > album covers, lyrics etc. Sadly, Amarok wasn't able to do that...
> 
> Which Amarok version are you talking about? This report is about the developer
> version Amarok 2.2-git. Are you sure you talk about the same one?

Amarok 2.1.1, my bad. Srry

*** Bug 226100 has been marked as a duplicate of this bug. ***

*** Bug 165843 has been marked as a duplicate of this bug. ***

*** Bug 257018 has been marked as a duplicate of this bug. ***

Updated information to the feature request:

1. We now have an album artist handled in the database.
2. Amarok will try to handle "Artist A feat. B".
3. Amarok will parse multiple artists from ID3V2. It should also be able to understand multiple artists in Ogg if they are in one tag and multiple lines.
However the UI won't be able to handle those types of artists. You cannot enter them and I really don't know how they are displayed.
4. Amarok could in principle try to guess tags from the filename during scanning.
That is currently not done because it's not always working.
A much better solution is to use the "guess meta data from filename" option in the metadata editor.

This bug could probably be considered a duplicate of 119539 or vice-versa

Overall the handling of the various Artist tags is confusing, but I think that the ID3v2 specification by itself is nearly enough to solve most of the problems. Like it was mentioned here, some tags allow for more than one entry by using the '/' character or a NULL one. Plus, there are a few overlooked tags that would immensely help with organising the audio - the Original Artist (TOPE) and Original Album (TOAL) tags.

Here's an example - we have a compilation album. It combines tracks from multiple albums and artists. Let's say this compilation was made by "The Compiler", the compilation is named "Best of X". There are two tracks, one that was originally by "Alice" from "Apricot" album, and the second one is by "Bob" from "Banana" album. When playing the tracks, you would probably want to see the original author and album, as the name of the compiling person or the name of the compilation is not as important. However, in the music library and on disk, you'd want to have them all found via the compilation, as otherwise you'd end up with the compilation being scattered all across the library. So, keeping with the ID3 specifications, we use "The Compiler" as the artist, "Best of X" as the album, "Alice" as the Original Artist and "Apricot" as the Original Album.

It would be different if it was a remix album, though. Let's say we have the album "Cherry Remix" by "The Remixer". The tracks that were remixed come from "Cherry" by "Charlie". So the Artist is "The Remixer", the Album is "Cherry Remix", the Original Artist is "Charlie", the Original Album is "Cherry". But in that case, you'd want to see the name of the remixer and the name of the remixed album, and not the originals (especially when you have the originals in your music library already - that would be very confusing). That's why it would be a good idea to utilise the semi-official compilation flag (TCMP) to mark if it's a compilation album or a remix album. If it's set to 1, show the original artist and album everywhere, otherwise show the regular artist and album tag information.

And then, if there are more than one remixer or more than one compiler, then the Album Artist unofficial tag should be used. There would be more problems if there was a compilation of remixes and you still wanted to save the information about the original tracks, but I guess that in that case the original track information would have to be sacrificed for the remix information, as it's more important (and the compilation tag set to true, of course).

This is essentialy a duplicate of bug 119539 with some fancy parsing stuff that cannot get into mainline Amarok. (perhaps we could allow for scripts to process metadata)

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