-
Notifications
You must be signed in to change notification settings - Fork 2
Talk:Mediatags
Short into about what I mean with media tags: save more information as genre, artist, ... in a standardized way.
It can be handled by the client, so all we need to do is to discuss how to express things. (And if I am the only one who like the idea)
With the create of dynamic playlists out of collections, it would be interesting to create something like tags: A File can have some tags, like 'chillout', 'noisy', 'fast', ... Inside the tag information can be placed, that does not fit anywhere else.
As soon as you have tags, collections are a very powerful tool: You can easily express things like all fast metal, that is not noisy. Now you can have your dynamic playlist for very situation you need.
It also would be possible to Split the tag field into multiple things, like mood, speed, and whatever you like.
Because I like the idea to be able to express more and it would not require to change code inside the daemon, it would be nice to have a standard way to express these kinds of media tags, imho.
I know that all this can be done with normal playlist, but, you also can do it the other way round. Handle playlists as tags: Just have a field called playlist (if we split the tags), where all playlists a song is in appear.
So, its just about what you like more and in which way you can handle you media more easy. (hey, sed is turing complete, nevertheless xmms2 is written in c ;) )
I don't say, throw away playlists, I just would like to be able express more things with a semantic that is more easy to use for me.
As I meditated about handling all with playlists, I suddenly realized what I missed about handling it with playlists: You can have you noizy, fast, chillout playlists(or idlists in a Tag Namespace eg. taglists) and even can put some together using the collections, but in the process of creation, something is lost: After you create your new collection, it will just be union of id lists and you have know way to get the information of the tag back. If you add a new song to the base taglist, the new Collection won't be updated.
So, perhaps the best way to handle it, would be a new Namespace with idlists, and, what is even more improtant, a way to refer to Collections by name, not only by its data.
Perhaps thats the best way to handle multiple tags, but it would have to be implemented inside xmms2d.
So, what do you like about it, what not. Have you any additional ideas, what would you change ...
- generally
I like the idea of tags : 2
you suck, get away with that shit: 0
- implementaion
have one tag field in media info: 0
split the tags in media info: 1
have a tag Namespace with taglists: 1
have multiple Namespaces: 0
-wabu 16:17, 1 August 2007
It sounds like what you want depends on clients. And I'm not sure a tag field makes sense. Why not use as many fields as you need? Examples: mood: happy,chill; speed: 120bpm; rating: 5 stars. If you want to stick them all in a tag field, you're talking about losing the keys (what do those tags describe now?) and you'll need a delimiter at the simplest level, or array support (which is unimplemented) at the most complex option.
For my own personal use I have a client that reads the URL of an item and creates tags from it. Specifically, it can take a string like Artist Artisson feat. Artisson Twins - Title McTitle (Swedish Fish Remix) and throw tags in the medialib:
- artist: Artist Artisson
- featuring: Artisson Twins
- title: Title McTitle
- mix: Swedish Fish Remix
This does a lot for me. I can do an exact search for artist now (because with most tagging schemes, artist looks like Artist Artisson feat. Artisson Twins) instead of Artist Artisson%. I can easily snatch remixes, originals, or both without a similar hack like Title McTitle%
I'm not even sure this has much to do with what you were describing, but it does afford you some power that crappy tagging schemes don't.
No client other than the CLI supports this. And just supporting it isn't enough--it needs to be done nicely. GUI clients should offer you a way to rate tracks easily, such as clicking on some stars in the playlist. Tags should be similarly easy to add. My own thoughts were to put this into RXMMS2 in a way that looks similar to Alt-3 (File Info) from Winamp 2, but with some text input lines at the bottom for key and value.
I think one way to handle things is a bad idea here. Tags are already a strange and abstract thing. To try to apply some sort of standard to them is a bit backwards. Tags will only have meaning to the user, and each user will tag differently. For example, the way I use artist, featuring, title, and mix tags, is not the way Joe Rockmusicsson Jr. will use them and Joe might not need so many tags or may need more. The one thing we do need, however, is clients to support easy medialib tagging.
Once it's dead simple to tag your music with mood: chill it's dead simple to xmms2 mlib searchadd mood:chill. Where does standardizing on this get us?
-Puzz 18:51, 1 August 2007 (CEST)
Yes, thats what I wanted to express with splitting tags, but you still have to define some standards for clients: otherwise one calls it speed, anohter bpm, one calls it rating, other vote, ... it already is done for rating, but for speed, mood, what ever else you need, we still have to find a standard.
Further more, some songs can have more then one mood, so arrays have to be handed, or we have to use id lists inside a Mood Namespace. That's the problem, I know there are solution for it, but there are too many, and I think it will be confusing if every client uses its own.
-wabu 19:05, 1 August 2007 (CEST)
The only reason to standardize is if these tags are intended to be machine-readable. BPM might make sense for some music-fingerprinting or something. (Maybe OFA will do this?) And mood would only need to be standardized if clients have some internal static collection that expects a mood key. As far as mood goes, isn't a delimiter enough without the added complexity of full-blown arrays? I can't think of any mood words that have a comma or semicolon in them, and that is easy to parse, even in C.
-Puzz 21:05, 1 August 2007 (CEST)
It seems like you would be doing things wrong from the start if you made a playlist of a certain mood rather than a collection. Tag your files to reflect the mood you want in your playlist (noisy, fast, chill) and then you can use them as regular collections. Simply search for mood:noisy AND mood:fast and you have your dynamic annoying party mix german techno playlist all set for your next festival.
-Puzz 21:36, 1 August 2007 (CEST)
Extra-tagging is nice. Mood, style, whatever; users want it.
It would certainly be good to define a set of "standard" tags, such as rating, mood, etc. If only so that clients know the domain of values allowed for them (e.g. rating). However it sounds good to also allow the user to specify her own tag types, assuming her client lets her do so. So we should come up with a method that allows arbitrary tagging, and simply some tags would have "conventions" that the client devs would be invited to follow (or burn in Hell).
In the case of collection-based tags, I have already thought of adding a Tags namespace. It would not necessarily have to be restricted to idlists, since you might want to also allow saving "All music by Pink Floyd" under the 'quality' tag "the most awesome music in the universe and beyond". Or have an "emo" mood tag that contains all the music tagged as "sad", "dark" plus some stuff you add yourself. I think dynamic collections would make sense here, and they are one of the benefits on this approach. However one will have to make it usable interface-wise, naturally.
I think one namespace per type of tag is not the best idea, because it disallows easily adding new types of tags. So a workaround would be something like naming collections according to the scheme "$type:$name", e.g. "mood:sexual" or "tempo:boring".
In the case of property-based tags, I agree that list properties sound nice – conceptually. However I don't believe it makes for a trivial interface. Instead of the current get/set scheme we have, you would need to have a add/get/remove scheme, and renaming would have to be done by removing the previous value and adding the new one; removing all would have to be done by iterating, or adding a new clear action. It's also harder to formalize querying as simply as with a single value: how do you ask for all media that have "mood=suicidal" and that mood only? It cannot be done using primitive match & complement filters, so you need to add complexity.
And naturally, it is incompatible with the current medialib schema, so maybe the best thing to do it poke anders and see if he plans to support this feature in the hypothetical sqlite replacement. Also, it would probably require some rethinking on the collection level. I am not formally against it, but I am not blindly for it either unless the consequences of this addition can be properly explicited.
I believe the most interesting/hard question is to choose between collection- and property-based tags. There are good arguments for both. In favour of collection-based tags: allows dynamic tagging according to filters or other tags, easier handling of lists of tag values. In favour of property-based tags: works out of the box now, might yield better query/listing/matching performance with the current way of things (especially if you want to list values for a tag for a list of media), allows partial matching of tag values. These lists are absolutely not exhaustive.
Maybe a combination of both makes sense. It should just be clear in the interface. But for instance it might be more natural to use a collection when building a set of stuff to play for a party, although an arbitrary tag could also be used for that. In the case of rating, it's pretty clear a property is the way to go. So I guess more thoughts should be given to this question, with clear arguments for both, and also clear definition of what the needs actually are in terms of tagging (conceptually, and in practice).
03:37, 2 August 2007 (CEST) Theefer
Content is available under GNU Free Documentation License 1.2 unless otherwise noted.
- Community
- Development