Bug 89314 - Allow 'flagging' of files (labels)
Summary: Allow 'flagging' of files (labels)
Alias: None
Product: amarok
Classification: Applications
Component: general (show other bugs)
Version: 1.0.2
Platform: Debian testing Linux
: NOR wishlist
Target Milestone: ---
Assignee: Amarok Developers
: 90828 102259 103642 104132 105768 107869 110739 110868 111787 119136 126460 (view as bug list)
Depends on:
Reported: 2004-09-11 21:22 UTC by Brian Hunt
Modified: 2006-11-07 11:14 UTC (History)
15 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Note You need to log in before you can comment on or make changes to this bug.
Description Brian Hunt 2004-09-11 21:22:56 UTC
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.
Comment 1 Alexandre Oliveira 2005-04-11 17:06:03 UTC
*** Bug 103642 has been marked as a duplicate of this bug. ***
Comment 2 Stefan Siegel 2005-04-18 17:37:32 UTC
*** Bug 104132 has been marked as a duplicate of this bug. ***
Comment 3 Alexandre Oliveira 2005-04-19 12:28:47 UTC
*** Bug 104132 has been marked as a duplicate of this bug. ***
Comment 4 Will Hardy 2005-05-10 07:12:19 UTC
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.
Comment 5 Will Hardy 2005-05-10 07:14:44 UTC
Also, I have commented in Bug 84047 which describes a wish which could be fulfilled using these such labels.  
Comment 6 Alexandre Oliveira 2005-05-16 21:34:58 UTC
*** Bug 105768 has been marked as a duplicate of this bug. ***
Comment 7 Alexandre Oliveira 2005-05-16 21:36:29 UTC
*** Bug 102259 has been marked as a duplicate of this bug. ***
Comment 8 Stefan Siegel 2005-06-22 13:15:40 UTC
*** Bug 107869 has been marked as a duplicate of this bug. ***
Comment 9 Alexandre Oliveira 2005-08-17 17:52:04 UTC
*** Bug 110868 has been marked as a duplicate of this bug. ***
Comment 10 Divided By 0 2005-08-17 19:37:36 UTC
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.
Comment 11 Paulo Eduardo Neves 2005-08-24 23:29:08 UTC
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!

Comment 12 Carsten Schlipf 2005-08-25 13:52:45 UTC
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.
Comment 13 Divided By 0 2005-08-25 14:11:50 UTC
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.
Comment 14 Alexandre Oliveira 2005-08-30 21:43:54 UTC
*** Bug 111787 has been marked as a duplicate of this bug. ***
Comment 15 Janet 2005-11-28 14:45:26 UTC
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.
Comment 16 Isaiah Damron 2005-12-04 07:56:13 UTC
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
Comment 17 dcc 2005-12-20 06:44:04 UTC
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.
Comment 18 Alexandre Oliveira 2005-12-28 20:57:21 UTC
*** Bug 119136 has been marked as a duplicate of this bug. ***
Comment 19 Bonnaud Frédéric 2006-04-13 16:18:38 UTC
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. 
Comment 20 Carsten Schlipf 2006-04-27 15:43:15 UTC
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.
Comment 21 Alexandre Oliveira 2006-04-30 00:45:31 UTC
*** Bug 126460 has been marked as a duplicate of this bug. ***
Comment 22 Seb Ruiz 2006-06-30 02:25:08 UTC
*** Bug 90828 has been marked as a duplicate of this bug. ***
Comment 23 Mats Ahlgren 2006-09-05 14:13:31 UTC
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)

(...) 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")
# }


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
Comment 24 Mats Ahlgren 2006-09-05 14:21:17 UTC
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?
Comment 25 Mats Ahlgren 2006-09-05 17:07:37 UTC
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.
Comment 26 Alexandre Oliveira 2006-09-21 02:55:57 UTC
*** Bug 110739 has been marked as a duplicate of this bug. ***
Comment 27 Maximilian Kossick 2006-10-29 18:01:14 UTC
SVN has now support for labels
Comment 28 Mats Ahlgren 2006-11-07 05:01:47 UTC
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).
Comment 29 Seb Ruiz 2006-11-07 11:14:14 UTC
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).