Custom tags / labels

[Clementine-Issue-Importer]

From luke.schlather on September 21, 2010 22:51:43

Add support for labels like Gmail's. My memory says Amarok supported some sort of custom tags. Would allow people to organize their music in intuitive ways.

Original issue: http://code.google.com/p/clementine-player/issues/detail?id=788

[Clementine-Issue-Importer]

From john.maguire on September 22, 2010 05:57:14

Summary: Custom tags / labels
Labels: -Type-Defect -Priority-Medium Type-Enhancement Priority-Low Component-MusicLibrary

[Clementine-Issue-Importer]

From davidsansome on January 13, 2011 12:48:58

Issue 1286 has been merged into this issue.

[Clementine-Issue-Importer]

From marcansoft on January 27, 2011 10:12:26

I agree, this enables quite a few nice use cases. For example, with Amarok 1.4 I used to tag instrumental songs as such, so I could make a smart playlist that picked up only those. Same with different styles of music (not necessarily something that can be done with just the genre field). I find this much more robust and intuitive than maintaining actual playlists for each category, and it's also by nature more powerful since you can easily combine criteria in a smart playlist.

[Clementine-Issue-Importer]

From jf8011 on February 02, 2011 14:19:46

This is the feature I now miss most from Amarok 1.4. Combined with smart playlists it allows for the creation of very specific playlists.

[Clementine-Issue-Importer]

From john.maguire on April 07, 2011 14:30:38

Issue 1288 has been merged into this issue.

[Clementine-Issue-Importer]

From Arpheno on April 08, 2011 07:58:20

I Would like to see the priority increased on this issue. Also, I will be investigating the subject.

[Clementine-Issue-Importer]

From luke.schlather on April 08, 2011 09:03:55

So basically, what we need is:

1. Two new tables in the database; a labels table and a songs-to-labels association table.
2. UI - right-click -> label -> choose from dropdown / new label dialog.
3. Display column in the playlist view.
4. A search mechanism.

On #1 it might be cheaper since these will mostly be displayed to use a delimited
list of IDs stored as a single field in the songs table, though that will make searching a little kludgey.

As far as search, do we want something that passively integrates with the search box, a way to specify directly "show songs with these tags" or both?

[Clementine-Issue-Importer]

From zzanzare on April 08, 2011 09:14:59

and don't forget the possibility to create dynamic playlists based on labels.. that's exactly what I'm waiting for;-)

[Clementine-Issue-Importer]

From Arpheno on April 09, 2011 04:31:20

I'm still not entirely sure if this is what I am expecting of it, I was told multiple values for one property are called labels. So what I want is this:(ID3v2.4 informal standard)
4.2. Text information frames
The text information frames are often the most important frames,
containing information like artist, album and more. There may only be
one text information frame of its kind in an tag. 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.

There's hardly one song in my library that does not look like:
TCON="Rock\0Alternative\0" or TPE1="Eminem\0Rhianna\0"
where TCON is the genre frame and TPE1 could be seen as the "main artist" frame.

Does the ability to assign labels include the ability to read from ID3v2.4 compliant null seperated lists? Right now the support for ID3v2.4 is not really exuberant, maybe on the same level as iTunes, which really is a pity.

Could someone with more insight to the topic explain what the database looks like and which files are responsible for its behaviour, so I have something I could start with. I'm an apprentice coder in c++ but I do well in C and python and the syntax is partly very confusing.
Thank you

[Clementine-Issue-Importer]

From zzanzare on April 09, 2011 04:39:02

I believe this issue is more about the Labels as they were in Amarok 1.4. These labels are (to my knowledge) non-ID3 and completely custom and only kept in the collection database, not in the song file itself.. correct me if I'm wrong..

Attachment: Screenshot-Track Information: Mariella by Kate Nash - Amarok.png

[Clementine-Issue-Importer]

From marcansoft on April 09, 2011 05:34:37

That is correct, labels here are meant as "tags" in the Web 2.0 sense - lists of words (or possibly short phrases) that can be used to group together songs by different categories. They are kept in the database, not as ID3 tags.

[Clementine-Issue-Importer]

From Arpheno on April 09, 2011 05:39:12

So please unmerge the topics that were merged into here as they do not relate. I strongly reject player specific data storage because my music must be portable at any rate.

[Clementine-Issue-Importer]

From Arpheno on April 09, 2011 05:41:11

sorry for my double post, but i feel issue 1288 shuold instead be merged into here: http://code.google.com/p/clementine-player/issues/detail?id=409&q=ID3&colspec=ID%20Type%20Status%20Priority%20Milestone%20Owner%20Summary%20Stars

[Clementine-Issue-Importer]

From luke.schlather on April 11, 2011 08:13:32

This issue should probably be blocking the ID3 tag issue, since there are standards other than ID3 and I think we should have an internal representation before we start thinking about how to write it to files. (And the last comment in 409 also notes that implementing 409 probably requires changes across the whole application, this bug is probably one of those changes.)

[Clementine-Issue-Importer]

From Arpheno on April 12, 2011 02:21:33

The thing is, ID3 easily allows for custom tags/labels, you can add more than the average user would want ( MEGABYTES ). Your roadmap you gave in your earlier reply is wrong I think, because we do not need another table in the database at all. We're good to go with our current database. The only thing that needs to be changed is the type of object we're pointing at. Although I have no clue about the internals of the database because I'm simply not clever enough to decypher it, what must be there on the lowest level is some kind of string based representation of an information frame
(TPE1, TCON, YOURFAVOURITEUSERGENERATEDLABEL,randomTAG, LULZ). What must basically happen is, that we change the type of the object being pointed at to be a list instead of a string. Instead of the current Array-based approach ( from what it looks like, given the immutability of the set of tags one can write into a file/internal representation) this would much more look like a hash table on the song-level.
However I agree with you that a good internal representation is the first step to achieving a solid datastructure.Sadly the model of representing music was not thought to be very extendable in clementine and it only allows for certain information frames to be read by the tag parser ( TCON, APIC, TPE1,etc etc) The TagLib routines are responsible for most of this as far as I have seen. What you're suggesting is already an overhaul of the complete database structure but without critical changes like multiple entries for one frame.

For me the situation folds out like this:!!!!!!!!TL;DR;!!!!!!!!!!!!!!!!!!!!
The current database model has limits,
therefore we should make it better.
We should gather ideas what a good database model would look like,
and find a good internal representation.
Standards are a good way to make clementine compatible with other players.
Only overhaul the database once and do it well.
/TLDR

This issue will be solved if full ID3v2.4 compability is achieved.
thank you