Version: (using KDE KDE 3.4.3) Installed from: Ubuntu Packages Please add support for multiple genres / artists / composers / etc. One of the problems with the current ID3 tagging system is that there's no support for multiple unsorted lists as entries in categories. For example: Say Alice and Bob sing a New-Age, Trance song called "The Example" There's no canonical way to enter this data into the ID3 tag system. Some might enter the artists as "Alice, Bob", or "Alice & Bob", or "Alice and Bob" -- and Amarok would display them as a single artist. Likewise the song might be filed under the genre "New-Age, Trance", "New-Age and Trance", etc. -- and Amarok would think of this as a separate genres for all intents and purposes. This produces a categorization nightmare. This is clearly no fault of Amarok's -- rather, it's a fault of the ID3 tag system. Solution: It would be great though, if Amarok would take the initiative to recognize everything that's comma-delimited in the artist or genre fields as separate artists and genres (for the purposes of playlist sorting and collection browsing at the very least). For example, collaborative works would appear under both artists; you have the option of converting all other delimiters like ";" to commas; Amarok would have a preference option to automatically sort artists by alphabetical order and keep them that way; the context browser would recognize songs by multiple artists (so "The Example" would show up in both Alice and Bob's browser; and similar behavior across the board. I think this could be best accomplished by writing two accessor function for metadata: something in the likes of "get-artist-string" and "get-artist-list", where the former returns the ID3 string and the latter (for the time being) parses the ID3 string and returns an array of artist names, and encouraging developers to use them.
(sitenote: Ultimately I implied that this multiple-values-as-unsorted-list support should be applied to all metadata fields.) Another good example of where to apply this is albums: Say "The Example" is not only included in Alice and Bob's hit debut album, but also in the album "The Best of Alice and/or Bob". The mp3/data file would need to exist twice in memory under the current system to exist in both Albums at once. This new feature would eliminate the need for such unpleasant workarounds.
I'd like to see this happen, as well. A lot of the songs I listen to are collaborations between artists, and there's no good way to indicate the fact that there are multiple artists involved - I've taken to listing one in artist and the other as a 'featured artist' in the title, but this is a suboptimal solution. Comma-delimiting is a great way to fix this issue.... the only problem being artists with commas in their name, if such exist?
+1 from me on this. Ideally I'd like this done the same way as Slim Devices do it in their Slim Server program: if you have a track with multiple artist tags, the track is filed under both artists. Additionally, you can specify a seperator char (they suggest ';') if you have your music in a format which only allows a single artist tag. The major free formats, FLAC and Ogg Vorbis, both allow for multiple artist tags, and I'd be happy enough if just that implementation was supported.
I'd be very happy to see support for commas and semicolons in the artist tag. I'd be even happier to see it extended to genre tags as well. +20
*** This bug has been confirmed by popular vote. ***
Ah, many people agree! I should also mention something that I thought was important when I made the original feature request: I just finished listening to a song which had a different composer (artist), arranger, lyricist, and performer (vocalist). Keep in mind that many songs have more than one composer or performer (duets, bands featuring guest vocalists, etc.). If AmaroK takes the initiative to support more metadata fields -- like those available in Windows Media Player -- and additionally implements multiple-entity support for all tags (from multiple composers to performers to genres), then searching through songs will become so much easier and less hackish. No longer will: - "Alice & Bob" by considered a different artist than "Bob" and not show up in the context browser - songs with a "Metal, Rock" genre not show up in the "Rock" genre (if searching/browsing by genre is implemented) - songs be given hackish titles like "Alice - The Example (feat. Bob)"; instead Bob can share the 'performer' field with Alice (performer: Alice, Bob) Hope you guys can do something about this!
Additional things which ought to be changed about the Context Browser ('Current' pane): Imagine I'm listening to a song with artist field = 'Alice, Bob, Cat' -- Instead of "Favorite Tracks by [the single artist] 'Alice, Bob, Cat'", it should list "Favorite Tracks by Alice, Bob, or Cat" -- Instead of "Albums composed by [the single artist] 'Alice, Bob'", it should list the "Albums composed by Alice" and below that the "Albums composed by Bob". These changes are necessary already, because say you have an album by Alice, and one song features Bob as a singer. That song, with artist tag "Alice, Bob", effectively severs the song from the album; the rest of the album won't show up in the context browser, and the "featuring Bob" song will be missing from the context-browser album when other songs are played. Sitenote: Probably the ',' character (and maybe also ';') should be used to separate different artists. The '&' character might already be used in the names of various artists, like "Simon & Garfunkel".
On a trivial note: quoting myself: [[ Another good example of where to apply this is albums: Say "The Example" is not only included in Alice and Bob's hit debut album, but also in the album "The Best of Alice and/or Bob". The mp3/data file would need to exist twice in memory under the current system to exist in both Albums at once. This new feature would eliminate the need for such unpleasant workarounds." ]] After much thinking, having multiple-album support doesn't work well at all and is an unnecessary feature. Still, multiple-artist/composer/performer/lyricist/arranger/genre/etc./etc. support is still a great idea I think.
It seems this is mostly a bootstrapping problem. It seems that a major obstacle would be to find a way to represent the artists in the SQL database, since I imagine storing the fields as ;-delimited strings may slow performance for large collections. Surely there has to be a canonical way to store linked-list data structures in SQL?...
I've only had about 6 months database experience (certainly no 20-year professional DBA, so feel free to override me with a better method), but from my experience the canonical solution to this is to make sure that the artist field isn't part of the primary key for a track (e.g. using a surrogate id column) (note: I have no idea what the current schema looks like), and have an artists table of the form (id, artist string). So instead of Tracks: [artist, title, filename] (Alice & Bob, The Example, /home/user/example.mp3) (Cats (feat. Dogs), It's Raining, /home/user/rain.mp3) It becomes: Tracks: [id, title, filename] (1, The Example, /home/user/example.mp3) (2, It's Raining, /home/user/rain.mp3) Artists: [trackid, artist] (1, Alice) (1, Bob) (2, Cats) (2, Dogs) The same goes for any other tag this for which this feature is desired.
Ah, brilliant -- a simple indirection layer. Could one of the devs who's in charge of the database comment please if you have time, on whether this is enough to implement multiple entities, or what further obstacles remain and in what ways we can help?
Wow, that would be exactly what I'm looking for. It could be great if Amarok could recognize when in the artist field are used this words (that have different meanings): vs., feat.,and, etc.
(I personally have never seen "vs." and "feat." and "and" (oddly enough, it's always &), but I do see "feat." alot.) It seems the best way to do that would be at the Tag Guesser (tagguesser.cpp) level -- the "Guess Tags" button in the metadata editor; i.e. Amarok can assume songs have 1 artist/composer/tag/custom-label until the user mentions otherwise. Plus, you'd be able to specify whether things like "feat." mean an artist or composer or performer -- on a per-track basis.
I'd like to echo comment 3. Instead of trying to automatically use '&', 'and', 'feat.', 'vs.' or any other English based logic to determine multiple items in a tag, why not allow a separator to be set as a preference? I personally like how slimdevices handles this (http://www.slimdevices.com/ ) with their preference to specify a separator for multiple items listed in tags. You may specify a separator character of '|', for example, and then specify the artist tag as 'Artist1|Artist2' which slimserver knows to separate and treat as 2 separate artists for the same song. As an obvious slimdevices user, a lot of my files are tagged this way and it's a little frustrating that Amarok doesn't know about the significance of my separator character.
I don't think having a user definable delimiter is a good idea. There should be one standard delimiter and if it appears in the artists name, it should have to be escaped (like \n in C). It will get too messy if you can change the delimiter and if you move the songs from one profile to another and they both have different delimiters set. I would suggest ; because a , is a lot more likely to be in an artists name.
(I agree: ";" is already used widely because it doesn't conflict with artist names as you said.) I'd like to also point out that it would be wise to bootstrap the tag (old) system on top of the label (user-defined properties which are on/off for any song) system. Not only is doing so extremely elegant, but multiple artists/etc. would naturally happen as a side-effect of this bootstrapping. What do I mean by this for people who don't know what I'm talking about? I mean this: Tags would no longer exist. A song's properties would be determined by which labels it's flagged by. For example, if a song is flagged by both the 'Elton John' and 'Shania Twain' labels, then you don't need to do anything fancy -- you have there a song with two artists. (This also works for things like composers.) Doing an artist query is simple as well. The only concievable problem with this would be that tags are ubiquitous and very ingrained into the idea of a "music file collection" (but that can easily be resolved with a good and relatively simple UI; it's not hard to come up with one). I already suggested this in the label thread, until the devs closed the thread... =p
I strongly disagree with comment #15. Requiring escaped delimiters is a horrible idea; a usability nightmare! Not allowing for user choice of delimiter is anti-KDE. If we wanted a non-configurable desktop we'd be running GNOME.
Hmm... you do make a good point. I think I should be more clear about which parts I agreed with. I think ; should definitely should be the default delimiter. (Sidenote: The question about which delimiters get parsed when importing into a collection isn't a big issue; it would be made part of the tagguesser.cpp sub-program and users could adapt it at will.) The *actual* issue at hand is whether, IF Amarok lets people modify multiple artists/tags by text input (it seems the simplest way), which delimiter should be used during input and display. The reason why ";" is a good delimiter is because it wouldn't ever need to be escaped, unlike "&" -- and escaping delimiters is ridiculous, as you say. I agree that Amarok should be more KDE-like and open to customization (see rejected proposal for customizing currently-playing pulsating-bar color). However, I think the current architecture of Amarok (with ways to change tags on the fly by clicking in the playlist pane and stuff like that) lends itself heavily to not allowing heavy customization in this area. The only way I could see a viable customization option would be a feature like "replace all instances of ; with user-defined string in OSD". Just my 2cents as a user...
The problem I have with user-defined delimiters is that that removes the portability of songs. For example, if there are two users, and one has some music in his home directory by for example, Simon & Garfunkel. The other user has Phillips, Craig and Dean (one artist) and tobyMAC feat. dc Talk (two artists). There is a folder shared by both user 1 and 2 which has the duet done by Alice and Bob. Lets look at the hypothetical situation with user definable tags. User 2 wants feat. for the tobyMAC and dc Talk song and not and because 'and' conflicts with Phillips, Craig and Dean. User one chooses 'and' because & conflicts with Simon & Garfunkel. User 2 renames the song by Alice and Bob to Alice feat. Bob which messes up User 1's setting, etc. Now lets look at it with a predefined ; User 1 renames the Alice and Bob song to Alice;Bob. User 2 renames tobyMAC feat. dc Talk to tobyMAC;dc Talk
In response to comment #19: Why limit the functionality because of a special case? Simply allow users to defined their own delimiters. (Multiple delimiters should be allowed.) If multiple users want to share tracks then they must agree on a common delimiter. They must have already agreed upon some things like shared directory names, file permissions, etc. Why is it such a burden for them to agree on a common delimiter as well? Alice likes to use "feat" Bob like to use "and" They want to share tracks so they choose their delimiter set to be "feat" and "and". Both users use the delimiter they prefer in their own collections, and they can successfully share tracks. If it is a burden for two users to agree on some common delimiters, is it not a much greater burden to FORCE all users to use a delimiter that is not of their choosing? And what about program interoperability? Where will the user be when three of his programs choose to force the use of three different delimiters?
The problem is if there are conflicts. Alice can't use and because it has a conflict with another artist she has. Is there a big sacrifice in having ; be the standard delimiter? What functionality is limited? In fact it is adding functionality because people don't have to worry about delimiters and try and figure out how to fix the fact that they have two artists for one song when it is really one. In many cases, removing confusion is functionality. You can't let users customize everything in a program because it causes a mess. Should we expose settings that allow users to have spaces be delimiters? What about the letter A? There is a lot of potential for confusion with user defined delimiters. Maybe we could have a custom tag artistdisplay that says what the interface should use when displaying both artists (artist=ALice;Bob artistdisplay=Alice feat. Bob) Windows Media Player uses ; to delimit artist names, yet nobody really has a problem with that. Why should anyone have a problem with Amarok setting ; as the default delimiter?
Both ID3v2 and Vorbis solve the storage problem already. The ID3v2.4 spec says: "All text information frames supports multiple strings, stored as a null separated list, where null is reperesented by the termination code for the charater encoding." The vorbis comment spec says: "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" So there is no need to have any separators for storage in the tags, but a GUI change is needed to allow a list of entries to be entered in fields where it is reasonable. I don't know of any music player or tagger supporting that, perhaps Amarok could be the first.
The only problem is that Amarok wold then be the only one supporting those tags. If you sent the file to, say, an MP3 Player that didn't support that, the user would wonder, "Why is the song only showing one of the artists?" If we support multiple tags, why not also support a delimiter. That is supported in other clients such as WMP.
Re: comment #22 I shouldn't have reused the string delimiters from your example. In my mind, the delimiter should be a single character not a string. I'm thinking of delimiters such as ; | , & ^ % # @ Delimiters should be characters that no sane person would put in a normal artist or genre field. Personally, if I tagged something as "Foo featuring Bar" I would not expect or want Amarok to auto split that string into two distinct artists. I want Amarok to split artists and genres only when I specifically enter some special single character like "Foo | Bar" or "Foo ; Bar". I don't have anything against ';' as a default delimiter. In fact, it is the delimiter that I currently use in my collection. I think it would be an excellent choice for Amarok's out-of-the-box field delimiter. However, I feel that the user should be able to add his own delimiters and have the ability to remove ';' as a delimiter.
Regarding comment #22: Using the multiple field capabilities of ID3v2.4 and Vorbis would be great. The real question is the effect on portable devices and players that have roll-your-own tag parsing code. I expect that some devices will crash and others will refuse to parse any of the tag data. Most Vorbis implementations would probably work fine. I'm not so sure about ID3 tagged mp3's. Are there are some mp3 taggers out there that support editing of multiple fields? If not, users would be forced to do all of their mp3 tagging in Amarok.
This is my biggest annoyance in Amarok (and every other player out there). Maybe it is time to have the ID3v2 updated?
I really hope this feature is coming soon... I'd like to add that if an album contains the same artist on all tracks + other artists playing with him, it should appear in this artist's album list and not under "various artists". Take last Santana's albums, it's always duos BUT it is still a Santana album. Just a detail I was thinking of...
Yes, this is the importantst feature that i can imagine since i used Linux. Today i would write a feature request about that (becaus i think no one has the idea before) and look it is still there, over a year... I can't understand why this feature isn't in the player right now. is it possible that the autors of amarok don't like this feature? So i hoped that it comes with 2.0! Only for correctness: it's not true that no player support that. In windows i used "music match juke box" and "win amp" and one of them supports that. I don't know exatly which of them becaus this was ~3!! Years ago. And i have 3 reasons why i don't like that the ";" shoud be the only one that is possibel for the delimiter: 1. Sharing with other Programms or Librarys that use another delimiter 2. I have a 20t+ tracks lib. and i don't want to change all files (becaus if it's a bug in the mass changer then all tags could be damaged) 3. I write often new tags or change some one and to hit ";" wastes more time than "," So what's the Problem to let the user choose? If the most people want's the ";" than it could be the standart and all unexperienced users used that. One reason why i use linux is becaus I CAN CHOOSE!! so that's my point of view, Pietro
[terminology: I use "multiple-entity" to refer to things like "multiple artists" as well as "multiple genres", "multiple composers", "multiple [unofficial tag like lyricist]", etc.] I agree that it's ridiculous that it's been over a year -- are the devs watching this? I've made suggestions in the Labels feature-request which have unfortunately been ignored: namely I outlined what would have been an excellent way to bootstrap a multiple-entity system into Amarok using labels. I also think it's ridiculous we're discussing a "default delimiter"; it would make very little sense to store multiple-entity data in token-delimited format, especially when Amarok is very database-centric. "1. Sharing with other Programms or Librarys that use another delimiter" It's not like you can easily share your collection with other apps anyway; Amarok will not automatically reorganize and retag your mp3s (which is very unfortunate, someone should file a feature request) -- all info is stored in Amarok's internal, personal database. "2. I have a 20t+ tracks lib. and i don't want to change all files (becaus if it's a bug in the mass changer then all tags could be damaged)" This seems like a valid concern, and would only require having a "list of recognized delimiters" you can change (or equivalently a bunch of checkboxes, one for each common delimiter). I agree that users should have options (but I'm not a dev, and I've seen the devs make user-shouldn't-get-options design decisions in the past). "3. I write often new tags or change some one and to hit ";" wastes more time than ","" I disagree, but I don't think this is an interesting point... no offense. So moving on... Not that I much care anymore, but just reminding people that ; is a good choice for "default" (for some meaning of "default" -- keep in mind that we may not even need a delimiter depending on the approach we take in implementing this) because it's used by both Windows Media Player and iTunes (I think), and is never used in tags (as opposed to commas and ampersands). Regardless, I still think the user should have a degree of control over how they interface with the multiple-entity functionality.
This is a feature I'd really like to see implemented in Amarok. I think the best way of doing this would be to use the best of both worlds: - Make Amarok recognize already defined multiple artists/genres/composers based on separators like ; or , or & - Implement support for multiple artists/genres/composers like defined by id3v2.4/Vorbis (other metaformats too?) How it could be done in Amarok: The metainformation dialog should provide support for more than one artist/genre/composer. If it's defined using multiple lines, the information is stored like specified in id3v2.4/Vorbis/... http://eliasprobst.eu/~elias/stuff/screenshots/bugs.kde.org/amarok/meta-multi/multi-artist-composer-genre.png When multiple artists are detected Amarok offers you a "converter" from separator-based multi artists to field-based multi-artists: http://eliasprobst.eu/~elias/stuff/screenshots/bugs.kde.org/amarok/meta-multi/multi-artist-detected.png After splitting it up to multi-field based information storage, it looks like this: http://eliasprobst.eu/~elias/stuff/screenshots/bugs.kde.org/amarok/meta-multi/multi-artist-converted.png To prevent trouble concerning non id3v2.4 capable mediaplayers, the player settings dialog could be extended: http://eliasprobst.eu/~elias/stuff/screenshots/bugs.kde.org/amarok/meta-multi/mediaplayer-propertiers.png So files already using the extended capabilites of id3v2.4/Vorbis/... could be converted to the old format (the one, the media player is capable of), using a specified field separator like ; or , or & or something else. I hope you like this mockups and maybe it's integrated this way or similar into Amarok 2.0.
Thank you immensely Elias for doing those mockups -- they show very clearly what I described in text somewhere above. The "converter" can perhaps be implemented via the tagguesser.cpp module -- the tag guesser needs a good overhaul** anyway (it's annoying to have to hit alt-f alt-n alt-f alt-n, and I doubt we want to be converting all the multi-artist songs in our collections manually, one at a time...). I'd like to reiterate that I think multiple-X (X = custom field, like "Vocalist" or "Lyricist") should be supported, not just the default tag fields. I outlined an elegant way to do this in the "labels" features request, which has since been closed. Random thought: One also needs to make a design decision whether artists are dynamically ordered alphabetically (in your example: 1] Paul would always come before Peter --or-- 2] depends on how you list them) -- #1 is trivially harder to implement; I don't personally care which is used; I'm just mentioning the design decision. *pokes devs because it's been over 14 months since I started this feature request* **and the regex's need to be re-tuned anyway
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. Regarding mobile equipment, if they advertise you mobile device with support for either ID3v2.3/4 and it fails to do so, I believe you have the right to get your money refunded or your mobile equipment traded in for one that supports ID3v2.3/4. 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
I really would like to see this feature, as well. As for Vorbiscomment, i don’t think it would be such an great obstacle, because it supports multiple tags. Even if you don’t edit the tags with amarok, it is possible to edit them with Kid3 or something like that, where you can edit any vorbiscomment field manually. For displaying, I don’t think that would be much of an issue. You could just display them in the Artist field as “Artist1, Artist2“ or something like that. You wouldn’t need seperate fields, then.
Does anybody know whether there is something happening regarding this feature in Amarok 2.0 development? If not, we should discuss this bug at the amarok mailinglist before it is missed as development target for 2.0 because it has a lot of votes. I think it's urgently needed. Regards, Elias P.
as far as i know, it has not been considered yet.
I think something related to this is the case used in the tags. As ALICE Alice and alice all refer to the same artist. ROCK and rock point to the same genre and so on The database should be case insensitive and let the user choose in a configuration dialog which style to choose in his display in this case: ALICE, Alice or alice (not considering odd stuff like aLice) ReGArds, ERic RObert ;-)
Imposing a single style on all artists makes no sense. I want my INXS songs labeled in all caps, but my Smashing Pumpkins songs labeled initial caps. Queries should be case insensitive, but results should be displayed as the song was originally tagged. Saurabh On 26 Nov 2007 17:22:56 -0000, Eric Robert <r.eric@free.fr> wrote: [bugs.kde.org quoted mail]
The solution for this "mess" is the advanced relationship (AR) database of (http://musicbrainz.org/doc/AdvancedRelationships) musicbrainz.org. The idea is to put all the information about a song in a database. And if you are interested in who composed the song, or when re did it. Or information like who played which additional instrument in that particular release. And as "artist" or performer you can add as many as you need. This would improve amaroK a lot. For the beginning it would be enough, if just for the currently playing song is showed the "AR" information. Getting the data form musicbrainz is technically not difficult and they provide the information for retrieving the wanted infos. Later it would be fine, if we could customize the presented information, so that the user can predefine which AR infos the wants to be presented and deselect for him uninteresting AR data-fields. Example: (http://musicbrainz.org/album/fa24f903-6d0e-4790-8851-cb4d934ce512.html) Symphonic Dances: IV. Dance of the Winds and Fires * was composed by Kalevi Aho in 2001 * was conducted by Osmo Vänskä * was performed by symphony orchestra Lahti Symphony Orchestra In the future a further step would then be to activate the links allowing to choose something for your play-list using the AR data. In the example case, if you wanted to add all works form your collection by the same composer or performing orchestra.
i am not entirely shure if my wish is identic with this one: It would be greate if genre tags like "alternative rock, Rap rock" would not only be shown as 2 entries "alternative rock", "Rap rock", but both genres are shown as a subgenre of "rock"; and "rap rock" although as a subgenre of "rap" i would like to see all my music in a genre tree, were i can finde the song with the above genre tag in the "rock" and the "rap" genre and in the "alternative rock" and the "rap rock" subgenre. where "rap rock" is a subgenre of "rock" and "rap". i think this should be managed with a lable technik were every genre is a lable and labels can be labled.
I get the feeling that everyone skipped my last post (#32) so I'll give you a short version of it this time: The following tagtypes supports multiple tagvalues in each tagname: ID3v2.3, ID3v2.4, APEv2, ASF, ID3v2.3, ID3v2.4, Native FLAC and vorbiscomment (Thats pretty much every tagtype there is) Read the rest of the comment here: http://bugs.kde.org/show_bug.cgi?id=119539#c32 or the standalone bug: http://bugs.kde.org/show_bug.cgi?id=137756
Would it also be possible to manually link related artists, so that they appear together in the context browser? For example: It would be nice if when playing a song by either "Keith Jarret" or "Keith Jarret Trio", both artist names' albums appear listed in the context browser. I don't know if this is the right way, or if it would be better to simply tag the solo almbums with "Keith Jarrett", and the trio albums with the three tags of the artists names'. I think the latter is not the optimal, because sometimes groups DO have a different name: Albums by the beatles, and albums by John Lennon, or Paul McCartney would also be listed together in the context browser: but certainly I wouldn't tag a Beatles album by: "Paul McCartney", "John Lennon", "Ringo Starr", and "George Harrison". Do you know what I mean?
I agree this is definitely much-needed. It is extremely difficult to deal with songs having more than one artist, which I have a lot of.
It's been severals YEARS this has been requested. I mean, some people must have died waiting for this, just what is going on? Will someone please tell us why we don't have this yet in AmaroK. Please?
Yes, pleas tell us if it's coming in the future (when ever it is) or not !?! I can't understand this lack of interest from the defs. When you look at the "Most wanted features" lists this Bug/Wish is the 27th most wanted in the whole KDE Project (by Votes). And the top most wanted for Amarok! The 2nd most wanted is exactly the same wish (Bug 90095). And so are wish Nr5 (146800), Nr25 (109084), Nr28 (138550), Nr36 (142755)... There are all near the same and relate with the artist handling behavior. The Sum of this 6 wishes are 2255! So this was on Place 7 in the KDE Wishlist ;)
Well, adding a version might make it visible now. Instead of moaning, why not give a hand in triaging the existing wishes? There are like a bazillion wishes, of which most don't even have a version attached and most seem to be duplicates over duplicates... of maybe 30 wishes over all! No wonder the devs don't look at it, it just takes too much time and effort away from their already heavy workload. Everybody can triage bugs, no need to have any coding skills.
Don't we depend on taglib for that? Then it should be reassigned.
(In reply to comment #46) > Don't we depend on taglib for that? Then it should be reassigned. taglib handle APEv2, ASF, ID3v2.3, ID3v2.4, Native FLAC and vorbiscomment correct, Amarok doesn't.
hi, everybody. i have a word about amarok 2.3. is this bug about sorting songs by genre (whereas there are some of them)? thx.
(In reply to comment #48) > hi, everybody. i have a word about amarok 2.3. > is this bug about sorting songs by genre (whereas there are some of them)? > thx. No it isn't. It's about storing multiple artists, genres, ... per file.
This wish has been granted.This report should be removed.
It is? Great. What release is it in? How do you enable it? I don't see any mention of it online.
6th birthday of this bug is approaching! :) If you need a nice reference for implementing multi-value attributes, take a look at the semantic (Nepomuk based) media player Bangarang.
(In reply to comment #50) > This wish has been granted.This report should be removed. So sorry, please disregard this message, there was a misunderstanding with the Google Code-In student.
*** Bug 173493 has been marked as a duplicate of this bug. ***
Started implementing. Might take a while to finish. Proposals for implementation see here: http://amarok.kde.org/wiki/Proposals/Support_for_multiple_tags
*** Bug 137756 has been marked as a duplicate of this bug. ***
*** Bug 90095 has been marked as a duplicate of this bug. ***
Hi, Just checking...is anybody still working on this? If yes, what is the status? Just curious. I have been waiting for this feature for long time. I know, some have been waiting even longer :)
*** Bug 313199 has been marked as a duplicate of this bug. ***
(In reply to Ralf Engels from comment #55) > Started implementing. Might take a while to finish. > Proposals for implementation see here: > http://amarok.kde.org/wiki/Proposals/Support_for_multiple_tags The wiki has moved to https://community.kde.org/Amarok/Proposals/Support_for_multiple_tags
Use of slash (/) is very common for separating multiple artist names also, e.g. "Alice / Bob"
Unfortunately, that cannot be assumed generally because "AC/DC" is a single artist, not two. I'll note that when I added support for multiple values to tags in FFmpeg, `;` is what is used there.
That problem in inherent to using any character for separating values. You just happen to be able to think of an example for "/" but there is no reason an artist, genre, etc could not have a comma in their name. In fact, here's one that occurred to me before finishing this comment. "Peter, Paul and Mary." But whether or not we can think of example for a character is irrelevant, it is always going to be potential for any character, and so the user will need a way to elect whether or not a given character is used that way, and a either way for a user to escape such characters in their metadata or a way to list exclusions, or some such solution.