Version: 1.0.2 (using KDE KDE 3.3.0) Installed from: Debian testing/unstable Packages It'd be great to be able to right-click on a file and "Flag as ..." then select from some user-defined list of flags, which are accessible in a sidebar. My user-interaction involves a lot of "hey, I like this, I think i'll burn it to CD" or it's great for the gym so I go 'it's going on the mp3 player', or "i've already got this song, but i'm too lazy to figure out if this one or the other has a higher quality, but i should get to that someday'. It'd be great to have a sidebar of 'Flags' (or whatever name is appropriate), and then the context menu with "Flag as ...", a submenu with all the Flags (ie. "Burn to CD", "Copy to MP3", or "Check for dups", and "New flag"), and when you want to look at all the flagged files, go to the Flags sidebar. This would make life better for me. :) Cheers & Thanks so much for the great work so far.
*** Bug 103642 has been marked as a duplicate of this bug. ***
*** Bug 104132 has been marked as a duplicate of this bug. ***
From the discussion in Bug 103642, there was concern shown that some information would only exist in the database (which may one day disappear). Another approach would be to use XML to complement the database, or to try and attach the information to the files themselves. Vorbis comments clearly have this capability, but I don't know enough about id3 to contribute. There was something mentioned about a 'user defined text information frame', that might help. I would suggest that both be attempted.
Also, I have commented in Bug 84047 which describes a wish which could be fulfilled using these such labels.
*** Bug 105768 has been marked as a duplicate of this bug. ***
*** Bug 102259 has been marked as a duplicate of this bug. ***
*** Bug 107869 has been marked as a duplicate of this bug. ***
*** Bug 110868 has been marked as a duplicate of this bug. ***
As I've said in duplicate 110868, another option would be to synchronize with the "tags" from the last.fm service. That way you could save your tags in case of a system failure as well as use the ones you've already filled in last.fm.
Tags (or flags) would be great! It's very hard to classify your music with just a single genre. Do as del.icio.us do for bookmarks, and Flickr do for photos, and allow us to tag our music in multiple categories. I don't mind to have the info outside the songs. It could even be implemented as some big playlists. If I tag a music as "Brazil samba GoodForJogging" and other as "world balkan GoodForJogging" I'd have 5 playlists, with both musics in the GoodForJogging. Never more limited to id3 stupid genres!
What about storing the Flags/Tags/Keywords in the 'Comment' field of the audio files meta information (Tags)? Don't know if there is a lenght restriction though, but if we append something like '<amarokFlags>Party Jogging Fast</amarokFlags>' it would also be possible to use the same Flags/Tags/Keywords on a different system with amarok by simply copying the file to that system.
It is an idea but it seems kind of clunky to me. The comments field is usually plagued with things like "Ripped by X" or other useless info. Also the labels are supposed to be something personal. What matches for you may not fit another person's tastes.
*** Bug 111787 has been marked as a duplicate of this bug. ***
I really would be content if I could just mark titles in the current playlist temporarily with some symbol so I can find them and do whatever I want to do with them when the playlist has ended. For me it would be sufficient when the flag dissapears when I stop amarok or when I create or open a new playlist. It would be even better if that symbol (or color) would be kept, saved with the playlist but I don't need any categories or mark tracks permanently independently from a playlist.
Allowing for boolean custom tags à la bug 90828 may be the best way to implement this, and to kill two bugs with one patch. =P
I just just adding a "Star" icon, like in Google Gmail, Groups, etc. would be great. Often I just want to add a quick content-free flag. It might mean "burn me, listen to me again, recommend me to friends," whatever - I can usually remember why I flagged an item - I don't need to type any flag comments. Just like in Google Gmail, a star can mean "read me again, forward me to a friend," etc. but those comments just exist in each user's memory. I think this is the easiest and most user-friendly way to flag items. I have thousands of tracks and many albums I haven't listened to enough - if I can just flag these albums/tracks I could easily find them again later.
*** Bug 119136 has been marked as a duplicate of this bug. ***
i think that it would be better it the 'tagging' is 'automatic'. How ? Well. When i listen 'music to dance', i select this tag in the toolbar (in a combo that could be edited). Next, i let amarok 'scoring' the music according to that tag. So, each file gets a 'per'-tag score. Next, in 'Playlists' -> 'Dynamic Playlists' we'll have some per-tag playlist which will give the 50th (or 100th, or 200th) first score's files for that tag That way we could even set the score for a specific tag using classic amarok scoring features.
May I ask what the status of this feature request is? I was hoping for it in the 1.4 series. I can hardly await it. IMHO current playlists are too inflexible. The abbility to assign multiple flags to a file and then select multiple flags to filter files from the whole collection would provide much more possibilities and flexibility.
*** Bug 126460 has been marked as a duplicate of this bug. ***
*** Bug 90828 has been marked as a duplicate of this bug. ***
Here are some design suggestions I thought I should make to help out, comments are welcome: For a nice and powerful implementation of these 'Labels', see digiKam (photo management software for KDE). Amarok should definitely absorb some useful features when Amarok comes out with its own implementation for music files. I summarize some of digiKam's powerful features below (examples adapted for Amarok): A) The labels are hierarchical: a label be a parent of other labels, e.g. you can file both "Alternative Rock" and "Progressive Rock" under the "Rock" label (the powerful searching capabilities are clear I hope) B) Labels can be rearranged without destroying your collection, e.g. suddenly you realize that "Oldies">"1970s">"The Beatles" should be filed under "Oldies">"1960s">"The Beatles"; making the appropriate move will not force you to relabel everything, but instead all songs are relabelled appropriately C) It's easy to filter your playlist/collection by tags: There's some sort of box where the tags are shown in the standard hierarchical collapsable tree KDE widget, with a checkbox next to each tag. You can check a tag and your playlist/collection will be autofiltered to only show songs thus labeled (e.g. you want an impromptu dance, so you check "Dance Music", or maybe just check "Dance Music">"Fast" "Dance Music">"Groovy" and omit "Dance Music">"Slow") D) It can be a very slow process to tag files if you have to do it via a context menu or something. DigiKam has a great solution: In the tagdialog editor, add a tabpane called "Labels"; this tab contains a hierarchical expandable tree KDE widget. To label a bunch of songs, just enter the tagdialog in multiple-song-edit-mode as you normally do, click in the tree widget, and you can keep your hands on the keyboard as you repeat this quick process: 1) type the first letters of the label, and the selector will jump to the label 2) hit spacebar, checking the label 3) repeat for each label you want to apply, then hit alt-N to go to the next song. This speeds up labeling by a factor of 10! [feature found in digiKam by pressing f3 on a photo] E) You can perform powerful searches on your playlist/collection using a set of filters in con-/disjunctiive normal form (abit like Mac OS search), instead of a "contains" query as we currently do e.g. The Collection Browser would have a subpane (exactly like the Files Browser has) which has a dynamically expandable table of search items: [BEGIN UI EXAMPLE: (text in parentheses represent UI elements), one good implementation example is digiKam's advanced search] # (Fieldset){ 1 (Pulldown Menu | Default = "Track Title") (Pulldown Menu | Default = "Contains") (Text Field) # or (Button | Text="+", Function=add a new line like 1 above this line) # } # -AND- # (Button | Text="+", Function=add a new fieldset below this line) # # (Button | Text="Switch and/or", Function=does (query && query) || (query && query...) instead) example: (...) represent pulldown menus songs by Nobuo Uematsu or Madonna, which have a good rating, and which are uplifting (e.g. they can be labeled as Mood>Uplifting>VeryUplifting or Mood>Uplifting>SomewhatUplifting), and which Mark does not veto # { # (Artist) (Contains) "Nobuo Uematsu" # or (Artist) (Contains) "Madonna" # } # -AND- # { # (Rating) (>=) ([4.5 star graphic]) # } # -AND- # { # (Label) (Falls-under) ("Mood > Uplifting") # } # -AND- # { # (Any Label) (Does-not-fall-under) ("Song > Vetoes > Mark") # } [END UI EXAMPLE] However, instead of a hierarchical structure for labels, I recommend a DAG (directed acyclic graph) structure; this lets you do things like file a label under multiple parent labels, | e.g. | "Artist" > "Female" > "Celine Dion" | "Artist" > "Preferences" > "Favorites" > "Emily" > "Celine Dion" | "Artist" > "Preferences" > "Vetoes" > "Mark" > "Celine Dion" | e.g. 2 | "Genre" > "Rock" > "Pop-Rock" | "Genre" > "Pop" > "Pop-Rock" A DAG is hardly more difficult to implement than a hierarchy. Also note the acyclic condition = no cycles which can cause trouble. Infact, a DAG has incredible advantages for Amarok collections!: 1) You never have to copy artist/album/title labels e.g. "Artist" > "Celine Dion" and "Genre" > "Pop" > "Celine Dion" are the same tag, preventing out-of-sync music-tagging nightmares -- If you rename a label, both labels will be renamed! 2) The powerful unifying powers of a DAG can be seen in the examples I gave above: hybrid genres, band members, having the same artist under Oldies>1960s and Oldies>1970s, etc. 3) Users can't become confused: if they aren't comfortable with the power of a DAG structure, a hierarchy is just a special case of a DAG; the user will end up ignoring the special functionality and using it as if it's a regular tree structure 4) Because a DAG can be trivially tree-ified, it can easily be shown via the collapsable hierarchical tree KDE widget Implementation suggestions: - It seems that each tag should exist as an independent unique id value (e.g. large random number); this is necessitated by 1) point B above and 2) if you want to use DAGs - I can't think of anything else right now >_> sorry
Oh, more design suggestions I forgot: - Bootstrap labels onto song metadata; make each current song tag is paired up with a label ID; changing the song metadata (e.g. manually or via Musicbrainz) auto-renames the label. This makes most of the interested things I talked about earlier possible. - Regarding D, digiKam also has a nice way to tag files: Dragging a group of songs from the playlist/collection onto a label in the tree-widget will label the songs with the label you dragged them onto. Nice eh?
More musings: * Regarding browsing by labels: When you right-click to add columns to the playlist or collection browser, you can have a submenu of labels isomorphic to the label tree. When sorting by a custom label column, the sort function should be careful about whether it should sort numberically or alphabetically. (My solution to this would be to make the sort function a wrapper around the regular alphabetic sort function, but that handles the special case where the label name is made of only number characters.) * Regarding useful hierarchical label functions: function is-a-sublabel-of returns: boolean function is-not-a-sublabel-of returns: boolean function sublabel-of returns: label (arbitrary label if many to choose from) Examples of the searching power this gives: + Genre |--+ Rock | \-- Rock-Pop \--+ Pop \-- Rock-Pop consider the example song "ExampleSong", which has a label genre>rock>pop-rock Consider this search query, where (...) indicates a pulldown menu: [checkbox: "Not"] ("Sublabel of") ("/genre") ("contains") [textfield: "Rock"] The query executes this for each song: song.sublabel-of("genre") contains "Rock" The query returns ExampleSong because ExampleSong.sublabel-of("genre") returns "/genre/rock/pop-rock", which contains "Rock" as a substring As you can see, sublabel-of gives a simple an elegant way to bootstrap the old concept of text tag fields into labels.
*** Bug 110739 has been marked as a duplicate of this bug. ***
SVN has now support for labels
It doesn't seem advisable to close this request yet; there are unimplemented details which would benefit from discussion (e.g. the two pages of useful implementation notes I took the time the generate above, which outlines a nice way to make smart playlists and such as well as other things).
multiple requests, or very deep requests are bad because we can't keep track of them. as a general rule, we really dislike bug report essays. (still, we really appreciate the effort, and make time to read them).