search

clementine-player / Clementine

:tangerine: Clementine Music Player
https://www.clementine-player.org/
GNU General Public License v3.0
3.72k stars 671 forks source link

Custom tags / labels #788

Open Clementine-Issue-Importer opened 10 years ago

Clementine-Issue-Importer commented 10 years ago

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

JulianVolodia commented 8 years ago

@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 commented 8 years ago

@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 commented 8 years ago

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

JulianVolodia commented 8 years ago

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 commented 8 years ago

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

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

@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 :

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 commented 8 years ago

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 commented 8 years ago

@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 commented 7 years ago

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 commented 7 years ago

?

StargazerA5 commented 6 years ago

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

classic0 commented 4 years ago

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

JulianVolodia commented 4 years ago

@StargazerA5 @classic0 @mgalvey in your opinion:

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

JulianVolodia commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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.