Clementine: 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="Rock0Alternative0" or TPE1="Eminem0Rhianna0"
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

[Clementine-Issue-Importer]

_From davidsansome on April 14, 2011 15:35:02_

Issue 1759 has been merged into this issue.

[Clementine-Issue-Importer]

_From neocrust on April 16, 2011 01:23:45_

Any news?

[Clementine-Issue-Importer]

_From davidsansome on June 27, 2011 09:42:26_

Issue 2026 has been merged into this issue.

[Clementine-Issue-Importer]

_From neocrust on June 27, 2011 10:30:51_

Any news?

It's great feature from Amarok 1.4 and Clementine will be a great fork with this =]

[Clementine-Issue-Importer]

_From wyatt.epp on July 08, 2011 12:12:07_

I'm still using KDE 3.5 and Amarok 1.4 because of this. A few notes:

• Rather than the tab in the "Edit Track Information..." context menu item, the Context view is my primary method of accessing this.[1] The dialogue is useful for mass-editing, however.
• Clicking "Add Labels to $foo" brings up a list of all labels in a dialogue. Labels are added or subtracted with tick boxes. Adding a new Label to the list is provided for with a text entry box.[2] While this interface could probably be improved (lint for trailing whitespace when adding tags, for example), it's at least adequate (if a bit small by default. Would love it to start taller).
• Clicking a Label in the context view switches to a list of tracks with that label sorted by rating.[3]
• Searching in the collection can be done similarly to other tag-specific searches with label: (case insensitive in my case) (e.g. label:chiptune rating:>3.5)
• I would very strongly recommend _against_ attaching this to ID3's TXXX frame. There are a great many MP3s in which this frame is already non-empty (greater than 25% in a sample set of over 42,000 MP3 files that I have examined so far). Tag dictionary pollution can be incredibly time-consuming to clean up because it requires full attention and higher-order thought.

Attachment: AmarokLabel1.png AmarokLabel2.png AmarokLabel3.png

[Clementine-Issue-Importer]

_From luke.schlather on July 08, 2011 14:13:19_

Yeah, we definitely don't want to shove stuff in TXXX. I think Arph is just trying to relate this to 409 when they're clearly very different issues.

Wyatt, your UI sounds good. Do you have an opinion on putting in a songs_labels table vs. shoving labels into a single field in the songs table? Since you're running 1.4, could you take a look at your database and see how they do it? (I would do it myself, but I live in the mountains and don't have enough bandwidth to download a dated system image on a lark.)

[Clementine-Issue-Importer]

_From wyatt.epp on July 08, 2011 17:16:27_

Well, I had nothing to do with the design; only ideas for minor improvements. All credit goes to the Amarok devs of old for what you see there! (Though I'd totally be up for a moderate-major design overhaul if someone was interested in discussing it with me. Not feeling up to soloing because my C++ is mediocre at best).

Anyway, for sake of discussion here is the full schema [1] for Amarok 1.4 (should be roughly the same regardless of type, but I'm using sqlite). Unfortunately the full schema dump jumbles things up a bit, so in brief we're most interested in the tables labels:
CREATE TABLE labels (
id INTEGER PRIMARY KEY,
name VARCHAR(255),
type INTEGER);
CREATE UNIQUE INDEX labels_name ON labels( name, type );

and tag_labels (indented to ease reading):
CREATE TABLE tags_labels (
deviceid INTEGER,
url VARCHAR(1024),
uniqueid VARCHAR(32),
labelid INTEGER
REFERENCES labels( id ) ON DELETE CASCADE);
CREATE INDEX tags_labels_labelid ON tags_labels( labelid );
CREATE INDEX tags_labels_uniqueid ON tags_labels( uniqueid );
CREATE INDEX tags_labels_url ON tags_labels( url, deviceid );

Now, the old Amarok code is rather...not especially commentful, and it's a fairly complex codebase to boot, but basically what I see happening is the tags_labels uses the deviceid, URL, and uniqueid to reference files and associate them to labels via the left join of labels.id and tags_labels.labelid

Some relevant example code from src/collectiondb.cpp [2] looks to be in CollectionDB::addLabel() (lines 5972-5999). I'll note at this point that if you grep your way back to the beginning, the labels.type in Amarok 1.4.10 ends up being:
enum labelTypes { typeUser = 1 }; //add new types add the end!

...yeah. I think this was mostly just a contingency plan in the event that they decided to integrate e.g. last.fm tags too. I don't personally consider this particularly wise, but it was never used for anything anyway.

Now as for how Clementine should handle it...
Looking at the database schema for yesterday's head, I don't see any way of uniquely identifying a track without filename and path. While this is suboptimal (doing some sort of fast hash of the file or part of it would likely be an easy fix), we can see that the old method is still quite available.

Though the two-table design may seem like overkill to some (not all: there are five tables each for songs, magnatune, and spotify) it's a simple canonical method of expressing this sort of relationship that scales without hundreds of columns of sparse content.

While putting it in a single column in the songs table would be very simple, to be blunt, I think it's a very bad idea. Every query of labels would have to brute force search at O(n) where n is the number of songs in your database-- I don't think FTS can save you from that.

Attachment: oldrokschema collectiondb.cpp

[Clementine-Issue-Importer]

_From [email protected] on July 13, 2011 14:05:17_

Portability of the songs is what matters. Therefore i would like to see the ability to show columns of custom tags. look at foobar2000, then you know what i mean.

[Clementine-Issue-Importer]

_From luke.schlather on October 01, 2011 16:49:17_

sqlite3 automatically creates a tablename.ROWID index we can use to uniquely identify songs, so a simple schema would look something like this:

CREATE TABLE songs_labels (
songid INTEGER,
labelid INTEGER,
FOREIGN KEY (songid) REFERENCES songs(ROWID) ON DELETE CASCADE,
FOREIGN KEY (labelid) REFERENCES labels(ROWID) ON DELETE CASCADE,
UNIQUE (songid,labelid)
);

CREATE TABLE labels (
label text NOT NULL UNIQUE
);

So getting all the songs for the label with label.ROWID=2 is simply

SELECT songs.title LEFT JOIN songs_labels ON songs_labels.songid = songs.ROWID WHERE songs_labels.labelid = 2;

For the regular playlist browser, we should be able to display the tags on a track as a column the user can check or uncheck. This SQL would show ids, titles, and labels/labelids for the songs in playlist with id 7:

SELECT playlists.ROWID,playlists.name,songs.ROWID,songs.title,group_concat(labels.label) FROM playlists LEFT JOIN playlist_items ON playlists.ROWID = playlist_items.playlist LEFT JOIN songs ON playlist_items.library_id=songs.ROWID LEFT JOIN songs_labels ON songs_labels.songid=songs.ROWID LEFT JOIN labels ON songs_labels.labelid=labels.ROWID WHERE playlists.ROWID = 7 GROUP BY songs.ROWID;

I'm poking around trying to figure out where to add the join on songs_labels to get this into the actual display.

[Clementine-Issue-Importer]

_From alphadeltapapa on January 16, 2012 00:17:49_

I think when Clementine gets this feature it will have reached feature parity with Amarok 1.4 (and surpassed it in some ways, of course).

[Clementine-Issue-Importer]

_From davidsansome on February 26, 2012 07:52:12_

Issue 2750 has been merged into this issue.

[Clementine-Issue-Importer]

_From neocrust on February 26, 2012 08:29:45_

Any news?

[Clementine-Issue-Importer]

_From davidsansome on March 07, 2012 02:46:00_

Issue 2785 has been merged into this issue.

[Clementine-Issue-Importer]

_From [email protected] on August 14, 2012 19:12:09_

Any updates? This is really one of the last few Amarok 1.4 features that I'm desperately looking forwards to. I'd attempt to work on it myself, but alas, my project stack is overflowing these days.

[Clementine-Issue-Importer]

_From neocrust on August 14, 2012 20:06:39_

Its too difficult for developers =]

Just use gmusicbrowser.

[Clementine-Issue-Importer]

_From arnaud.bienner on August 15, 2012 09:07:19_

@neocrust: If you're so clever, do it yourself and send us a patch ;) We will be glad to integrate it :)

[Clementine-Issue-Importer]

_From the.binary.buddha on January 02, 2013 16:24:01_

If I knew how to code C, I would.

[Clementine-Issue-Importer]

_From [email protected] on August 16, 2013 20:37:24_

I hate to be the "ping" guy, but I guess once a year isn't too harsh.

Any chance this might make it onto any developer's TODO list? At this point this is the only Amarok 1.4 feature that I dearly miss every day. Pretty please? :-)

[Clementine-Issue-Importer]

_From GcHoyman on August 18, 2013 10:25:52_

I've been using the comment field, to add a user definable tag that is stored with the file
I can add a filter to a smart playlist
I use this to exclude songs I don't want to hear as often
what's lacking is a way to group the library file browser by comment
this would allow me to more quickly edit comment tags in big bunches
for me this is a reasonable work around

far easier than redesigning databases & the like :D

[Clementine-Issue-Importer]

_From JimiJames.Bove on September 11, 2013 21:55:37_

I switched to Clementine from quodlibet and definitely miss this feature. I still have QL and Ex Falso installed for organization purposes.

[Clementine-Issue-Importer]

_From alphadeltapapa on September 22, 2013 16:33:03_

I finally gave up and made a Python script that applies custom tags to
MP3, AAC, and Ogg files in the correct format for each filetype. I
also made a few supporting shell scripts so I can quickly tag the
currently playing track and autocomplete tags that I've used before.
These don't show up inside Clementine, but they will be permanent. I
also made a script to create playlists from the custom tags, and those
work in Clementine. So in a way it's a hacky workaround, but on the
other hand it's a lot faster than clicking around in the Clementine UI
every time I want to tag a file, and it's independent of any
particular player software.

Anyway, if anyone would like a copy of the scripts, feel free to let
me know. I've thought about making them a bit more generic and
suitable for posting somewhere, but I'll gladly share them as-is.

[Clementine-Issue-Importer]

_From yerikb on November 24, 2013 19:24:53_

Ping, any updates on this?

[Xaavier]

I am looking at clementine instead of gmusicbrowser and I like it. One thing I miss is this custom metadata feature. Embedded in the music file or in the DB does not matter very much to me but I'd rather have it in the DB than having to touch (and backup) 1.5TB of music.
I need an extra field to store the location of the physical CDs. I have many CDs stored in boxes stored in cabinets and there's no way I could keep them sorted alphabetically.

[shapirus]

Just another traditional yearly ping. With huge collections tag-based navigation is the most (if not the only) convenient way of browsing.

[er314]

Hi, for information,
I'm a foobar2000 user (who will eventually switch to a Linux open source alternative), and foobar2000 big strength is its handling of custom tags.
In terms of open source implementation, I observe that Quod Libet does load them without a hitch. So this might be a good inspiration, for a mature and cross-everything custom tag format.

[Burrito-Bazooka]

I'd also like to see this in Clementine. How difficult would it be?

[adenisiuk]

I'd also like to see this in Clementine. How difficult would it be?

[JulianVolodia]

I summarize most of things and start to work on this issue. I add some comments how I plan to implement it.

Part I
1. Two new tables in the database:
- changes in DB:
- creation of labels table (id, label, parent) - parent nullable (only one parent available, checking if we are making cyclic relation should be resolved in UI and check in every save)
- creation of table songs-to-labels (many-to-many) (song_id <--> label_id)
- changes in existing tables if it would be necessary
- changes in UI:
- right-click (at song form playlist, collection etc.) -> label -> choose from dropdown / new label dialog
- display column in the playlist view

Part II

• A search mechanism
  It was mentioned here: https://github.com/clementine-player/Clementine/issues/13
  In way of cleaning code, I think search should be big module introducted as resolve of mentioned issue. I do not know it is good to do elastic search here... but my friend told me that brute force would fit here.

Part III
"and don't forget the possibility to create dynamic playlists based on labels.. that's exactly what I'm waiting for;-)"
I think after creating lists as results of searching feature, it could be easier to implement.

--- notes:
I finally gave up and made a Python script that applies custom tags to
MP3, AAC, and Ogg files in the correct format* for each filetype. [...]
I think it is not that way - we need to have labels which are not related with files...

@shapirus :
_labels should be attachable not only to songs, but to all hierarchy entities: albums, album/artists, artists, and maybe even years._
Maybe you think about tags-like labels... in big thinking I imagine - everything could have label, sth like hashtag... But for most of users it wouldn't be useful I think...
to year - you maybe want to have some notes about each year, label should be sth like 'note' but very short (i think even 20 characters will fit ;) ) longer would be a problem - even for user :) better to make hierarchy i think :) here I have some concept that you could create new Label or use existing, but like in the google gmail - it should be very easy, simple cause of thinking about User Experience, for example - labeling with real-time fitting existing labels when you are typing ;)
My opinion: I agree with many, but not to years i think... and it should be collections.
And not everything at once :) Now only songs I think :) We must debug implementation, test it, and get feedback from that feature, and make it ASAP, cause it too long to do it 2 years :) And have *maximal* density of feature at one object to test it well and then just reimplement for another types of objects (artists etc.)

What you think about it @Chocobozzz , @hatstand ? Best regards.

[shapirus]

I think that labels should be attachable not only to songs, but to all hierarchy entities: albums, album/artists, artists, and maybe even years. Not sure how easy, if at all possible, it can be to fit into your proposed approach, though.

[Wyatts]

@JulianVolodia It's great to hear you're willing to work on this! Thanks so much!

I'm not sure there's much benefit to associating labels with entities other than individual songs when the basic workflow allows you to apply labels to any arbitrary selection anyway.

Consider: what do you gain when you associate a label with an artist over associating it with all of that artist's songs?

The best I can think of is it automatically applies it to new additions to your library but, in my experience, that _dramatically_ constrains its use in every scenario I can think of because it creates a hierarchical association.

Broadly-speaking, there's very little that's universal even among an artist's songs on a single album, and those sorts of outliers are as annoying as they are common if you're trying to manage a clean semantic space. The real frequency of outliers that don't fit into a rigid hierarchy is a major part of why the ideal semantic user ontology _in practice_ is mostly flat (though support for aliasing and implication can be very helpful) and unitary with respect to the items being handled.

To draw from a potential real-world example, if you were to associate something like... say, "Japanese Vocals" with the artist Utada Hikaru, that works for the most part. But she has songs and even a whole album where she's singing in English. You're further constrained by not knowing if a new album is going to clash with the union of label sets until you listen to it.

The result is either you end up polluting your semantic space with items that don't actually match, or you just don't end up using that feature very much. (It's somewhat a question of engineering trade-off, then: is it worth implementing and maintaining? Judgement call.)

It doesn't solve the implementation problem, but I did think of an alternative approach that might work: when a label is added to an entity that isn't a song, it becomes an import filter. If a new addition to the library matches that filter, it receives the label as it's ingested. The critical difference is this is still _applied_ at the item level, so if the label doesn't fit some of the items, you can fix it trivially without having to add negation hacks or complementary subsets to work around the subset relationship.

Another area that needs addressed is UX and UI. How do you expose that you're labelling an artist or album group vs. their constituent parts? How do you propose to make it intuitive enough that people will use it? That's not a condemnation _per se_, but it's important to consider.

[JulianVolodia]

@Wyatts, I am glad that you agree with me :) First of all - labels should be only for songs.

In next comment I will prepare small use case to show you what I thought about. I try to think like listener asking myself: "What the hell is the label? What I can use it for at first glance at it?" just imagining the UI in my head ;)

to be continued...

[JulianVolodia]

Hmmm... I have an idea but sth in 'real world' appear and I lost time to write about that feature 3 h ago ;)

Think that you can add any way of grouping, labeling adding different infos about that artist - not song actually...
Sond could be 'sad', bud artist could be 'awesome', and it do not tell you that each of his work is awesome. You just want to label him as 'awesome'. In search mechanism I imagine, that you have each category (firstly songs, then albums, then artists...) presented as labeled as 'awesome', 'foolish', 'sad', 'programming', 'concentrate', 'german' (artist), 'classic i thought', 'buy my lovely girlfriend' (eg. about album), 'cold war' (eg. about year) - sth like comments which express your feelings, but also:

• could be added to each of element mentioned,
• should be short
• shouldn't be saved to file metadata.

UX and UI - we should make a research. And first - have labels only for songs... then we will find the proper way to do it.
I thought about list of rounded rectangles appearing when you are over the song title, artist, year or sth...
View of song, or album, or artist would have the kind of button to show that labels.

Each displayed label should have "x" sign to remove it, and list would contain empty place with "+" to adding that. That's is only sketch of very beginning idea. We must "eat that big, ugly frog" cause it voilent for many people I thought. Any contribution are welcomed (PRs, comments, patches and so on).

Have a nice day and please explain more about that @Wyatts :

It doesn't solve the implementation problem, but I did think of an alternative approach that might work: when a label is added to an entity that isn't a song, it becomes an import filter. If a new addition to the library matches that filter, it receives the label as it's ingested. The critical difference is this is still applied at the item level, so if the label doesn't fit some of the items, you can fix it trivially without having to add negation hacks or complementary subsets to work around the subset relationship.

[Burrito-Bazooka]

The reason I wanted it to be attached to files is so that the methods I use to organise my music is not entirely dependent on Clementine. My own specific use case is to mark out mixes/sets and lyricless or foreign-language songs from the rest of my music, because I sometimes listen to these while working - lyrics I understand distract me.

And I do not want this organisation of my music to be lost if/when I switch music players, nor do I want to maintain playlist files, which depend on the locations of files. If I change the files' names (e.g. using Picard to fix mistagged files), the playlist files will become invalid.

But I like this new idea too.

[JulianVolodia]

@Burrito-Bazooka , I understand that but _even if we save it to file, another player must be compatibile_ to understand that:

• that is the label (or label list which is more common case)
• how to read that label list
• save it the same way

If you know how different software technically done sth with music files, and it could be standard for each of: mp3, flac, ogg, acc - post it here :)

You should fix mistagged files with Picard before adding to Clementine. Why are you have problem with labels when you loose it? Your every playlist will be crashed : P

Of course, we could try to be compatible in another players/taggers but first of all - we must have something which work, and say - that it useful and usable. ;)

@Burrito-Bazooka , I will listen to any of your ideas, cause your bounty make me look at that for a (longer) while : P

[er314]

Hello,
As previously said, in terms of cross-players compatibility, I have observed that Quod Libet does load the custom tags created with foobar2000, without a hitch.
So this might be a good open-source (Quot Libet, not foobar2000 :-) inspiration , for a mature custom tag format.

[JulianVolodia]

@Burrito-Bazooka 2 things:

My own specific use case is to mark out mixes/sets and lyricless or foreign-language songs from the rest of my music, because I sometimes listen to these while working - lyrics I understand distract me.

I have the same, I understand - you would make a playlist which will be compatible with another software based on search by label.

And I do not want this organisation of my music to be lost if/when I switch music players, nor do I want to maintain playlist files, which depend on the locations of files...

I cannot connect it with more than one label ;) Maybe later Clementine try to find that song after rename? ;) another issue... (quest :D )

@er314 if you write it to file you will have quite nice increase of disk i/o ;)

[JulianVolodia]

@er314 - good example would be saving tags and recognize it by every app you mention. I think you show that compatibility between apps are not "assured" (maybe I use wrong word, sorry!).

[er314]

Hi,
my aim was just to give my modest end-user feedback ; to explain a little better :

• from an enduser perspective, foobar2000 handling of custom tags just works great for me,
  . feature-wise : you have some simple query language, or you just input plain text and you get the matching results from your custom tags contents ; plus you can add any of your custom tags as custom columns when displaying the albums & tracks ; plus you can create autoplaylists from your queries
  . it's extremely fast , even on my sluggish server : initial loading of the software is slow, but then clearly there's an in-memory database or something, the query results are instant and the HD is bypassed
  . resilience-wise : the tags are saved in the files, so when you copy/backup the files, you copy/backup the tags. it's the exif for music :-)
  . works with mp3 and flac. don't know others
• from a developer perspective : sorry, not much to say here :-) , but nevertheless,
  . Quot Libet does read these tags, so even though foobar is closed software, it seems that at least one Open Source project was able to make an open format out of it :-)
  . I wish I won't have to write my own python script for, someday, converting my foobar tags into Clementine tags ;-)

[JulianVolodia]

As I said, import/export as dependency do another software should be another module (eg. plugin?).

custom tags as custom columns

We are talking about only "label" column for now, so it is different issue I think... @Wyatts what you think?

Quot Libet is specific. I could say anything more, cause I do not know that well. But I think it is another issue. Anybody could (dis)agree?d

And maybe, you are the best person to write issue about that custom tags (no. 1) and import/export to foobar/QL format files. But I think we have discuss about ocean of issues - we should CHOP that work. Maybe my knowledge is too small, but I hope it's the right way...

[JulianVolodia]

@hatstand @Chocobozzz @Wyatts @er314 @Burrito-Bazooka please decide:

• tags/labels saved into file from now in spirit of compatibility with QL/foobar,
• labels as small feature saved into db and then maybe plug-in to import/export to QL/foobar format of files (some redundancy, re-scan of files, hash/size of sizes saved to DB to fast-check if sth is changed)...

I bet 2nd.

@Xaavier what do you think about them - i think with second you probably would have your imagine come true and @er314 would also be able to use "foobar-like tags".

[Wyatts]

Woah, lots to catch up on. Okay...

@JulianVolodia
Right, I can see how it's possible you might want to say an artist is "awesome", but is it truly important to attach that label to the _artist_ (as an object) instead of the artist's songs? I don't believe it is.

The function of labels is to enable users to search for _music_ in terms of arbitrary features they've selected. When users consider their collections, it's in terms of songs first. So while they certainly might say "this artist is awesome", the real meaning is "this artist's songs are awesome".

Maybe it's theoretically nice to have, but in practice I can't imagine any user wanting to search for songs from all "awesome" artists while excluding albums and songs that are "awesome" from artists _not_ in that list. It's a contortion with no practical benefit for a pattern of search behaviour that I've never seen.

This is why I suggest import filters as a middle ground: it lets you make those sorts of assertions that have far-reaching effect on your future library, but doesn't lock you into a situation where they can go wrong ("awesome" artist makes songs I don't think are awesome) and doesn't force a label search to build a union of sets (which greatly complicates querying).

I didn't want to bring this up, but since you mentioned "comments which express your feelings": I wonder if its possible to draw a distinction between factual labels and subjective labels. Amarok's current labels widget will automatically fetch "provisional labels" from last.fm tags. They are terrible. Seriously, people abuse the _crap_ out of them. You'll see things like "I want to marry the singer" or "Dan's favourites" or "If this song was a pokemon I'd catch it". It's the worst.

@Burrito-Bazooka
That's an open problem. Not just in Clementine or music players, but in the entire area of metadata theory. If we narrow it to music, an important problem is there's no standard for how to encode these things in the tag formats in use (I have some ideas about this, but it's complicated and off-topic here).

This also highlights the tension between objective/subjective labels outside of personal contexts. i.e. If something is instrumental or has a harpsichord lead, that's just kind of a brute fact; but if one of my flatmates is sharing his collection, I don't care that he thinks half his library is "music for banging" or whatever (TMI, dude).

@er314
Quod Libet may very well be a good example to follow. If nothing else, I have a lot of respect for Christoph and team managing to _implement_ ID3v2.4 as close to completely as possible. Now, it _may_ be worth looking at how they do that and including similar label write-back as an option, but that's secondary to getting the feature working in Clementine.

Mind if I ask what you use "custom tags as custom columns" for? That's way out of scope for this bug, but intriguing.

@JulianVolodia
I would say file separate new bugs for export and write-back and have them dep this one. We don't even _have_ labels right now, so it's not really the time to make this decision, IMO.

[JulianVolodia]

Thanks @Wyatts !

So while they certainly might say "this artist is awesome", the real meaning is "this artist's songs are awesome".

It depends on possible use case and user. I don't believe I know how many uses could have very _common_ and "usable in general" labels than special-designed labels. Maybe they just heard that artist is awesome and want to make sth like note? This is my way of thinking about labels. For now I understand that you agree that doing Part I,II & III from my early post is good way.

Of course they should search for music using them. But in next step (not now) maybe we want to allow them to make that strange things.

Bugs are here, ehm - how to set dependency/blocking status? ;) I hope I have done it good way. If any more should be - please comment here and specify.

5288

5289

...and remember:

"If this song was a pokemon I'd catch it"

you made my day ---.---

[er314]

@er314 - Mind if I ask what you use "custom tags as custom columns" for? That's way out of scope for this bug, but intriguing.

Sure ! I happily answer any non technical questions :-)
I'll detail my main use cases of custom tags :

• I enjoy classical music. But, contrary to rock music (where, for instance, I know that I really enjoy "Whole Lotta Love" by Led Zeppelin), with classical music if I want to listen to great sonatas by Mozart, it's harder to remember that I really enjoy "sonata K309, I. Allegro con spirito" , especially the version performed by Maria Joao Pires. So, I tag the classical music with tags rating_compo and rating_perf.
  Then, I can do a query where genre = classical and ensemble = solo piano and composer = mozart and rating_compo >= 8 and rating_perf >= 8
• Also, sometimes, I would like to remember which music I have recently added to my library. So I tag all my music with the tag "added", which I set to the date yy-mm-dd when added.
  Then in the library view, in addition to the standard view by genre/then/artist/then/album, I have defined a view by tag-added/then/artist/then/album (for sorting fully chronologically) , and a view by genre/then/tag-added/then/artist/then/album (for sorting chronologically within each genre) **
• Another useful custom tag : in genre = rock I have all the more or less rock music, but then, for each rock album (so for all tracks of a given album), I have a "substyles" tag, which details the... substyles of the given album. This allows me, for instance, to filter the display on all the "substyles contains psychedelic" albums of my library.
• Finally, regarding "custom tags as custom columns", I display rating_compo and rating_perf in the playlist. So that, when I put classical records in the playlist, I can see directly what are the "highlights" of these albums.

That's about it :-)

** : cherry on the cake : when defining the view expression, you can "process" your tags, so here for the tag "added" I do : $left(%<added>%,5) , and as a result, for sorting purposes, I don't use the full yy-mm-dd, instead I use yy-mm, so that things are grouped by month added . This is the perfect rendering :-)

Ok, so this is non technical, but nevertheless, advanced usage of custom tags :-)

[hatstand]

Storing these in the database makes more sense with an option to synchronise to files like we currently do for ratings and statistics.

I think adding custom labels/tags for anything other than songs is just feature creep.

[JulianVolodia]

@er314 i think the sentence:

Finally, regarding "custom tags as custom columns", I display rating_compo and rating_perf in the playlist. So that, when I put classical records in the playlist, I can see directly what are the "highlights" of these albums.

... is the main explain and should be moved to another place, could do it, @er314 ? Thanks in advance.

@hatstand I appreciate that ou agree with my plan and accept adding synchro in 2nd step? :)

PS and maybe somebody want to talk how we should export them to file (how to save many labels, into one cell on many?)...

[fischbone]

Hi, just FYI this feature is easily available in iTunes using the "Grouping" field for a given track. If I put my tags in that field and then look at the file in Windows Explorer, the tags show up in the "Group Description" property (at least for MP3s). This has made it easy to keep my tags assigned to individual songs and have them be portable across music players.

EXCEPT, no music player on Ubuntu currently searches the Grouping field; thus, the years of organizing my library along mood, month, situation, etc would be lost if I switched to Clementine. Please incorporate this into Clementine! Once it is incorporated, I will switch to Ubuntu in a heart beat.

[JulianVolodia]

?

[StargazerA5]

Following up on this. It would be extremely useful to be able to better organize my rather large library. Thank you!

[classic0]

Still anyone hasn't picked up on it yet? Would be really nice

[JulianVolodia]

@StargazerA5 @classic0 @mgalvey in your opinion:

• having metadata saved in file (that would change hash checksum of file, but will pass untouched if something with tags/labels DB will be failed, or just you will remove it
• having only DB and later (never know...) save that labels aka synchro DB with actual filesystem entries/files,

will be better? How much libs do you hold there?

[JulianVolodia]

PS if one of you want to give it a try with some basic pull request - go ahead :)

Provide patches tested against main development branch.
1) fork repo
2) clone to your disk or access via Github webpage
3) edit files and commit them
4) create pullrequest mentioning that "fixes # xyz issue"

[melsophos]

To my opinion, this is the major lack of Clementine and it would be great to see this option.

@StargazerA5 @classic0 @mgalvey in your opinion:

* having metadata saved in file (that would change hash checksum of file, but will pass untouched if something with tags/labels DB will be failed, or just you will remove it

* having only DB and later (never know...) save that labels aka synchro DB with actual filesystem entries/files,

will be better? How much libs do you hold there?

The first option is better because it would allow retrieve the information from other software and, as you point out, prevent problems if DB is corrupted.

[shapirus]

it would allow retrieve the information from other software

it will not, unless there is a widely accepted standard on the format in which the tag/label data is saved in the file.

Further, these labels only make sense for the user who added them. When the file is shared with someone else, this information becomes useless, not to mention that it may be undesirable to disclose it at all.

The best way to handle this, in my opinion, would be to save the tags/labels info in the database, never touch the audio files, and have an option to export the labels in CSV or other standard format that could be used to import them to any other software.

[melsophos]

it would allow retrieve the information from other software

it will not, unless there is a widely accepted standard on the format in which the tag/label data is saved in the file.

It could make sense if one just sets up an informal standard. Everyone refers to this as "labels", so let's add a custom tag in the file with this name. I agree that it's a problem if other softwares use other conventions, but for the moment there is none. Only Amarok has "labels", but they are not saved to the file. And here is my point: if Amarok was saving them to the file, and if Clementine was using the same convention (which I want to stress again is not that silly since everyone uses the same name when looking for this feature), then I would be able to re-import all my labels in Clementine instead of loosing them.

Another possibility would be to let the user choose the name of the tag, since this name can easily be changed by a tag editor software (like Ex Falso).

[StargazerA5]

Personally I'd prefer not modifying the file any more than necessary. I've had a large music collection for many years and had a few cases where disks went bad and introduced corruption. Trying to figure out where things have gone wrong is much harder when you can't compare hashes because the files get changed frequently. Much better, IMHO, to store the data in the database.