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

[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 ddidderr@web.de 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 hector@marcansoft.com 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.

[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".

[Llammissar]

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.