Metadata handling - Multi-value tags (i.e. more than 1 genre)

Why is this something that is still not implemented in Traktor?

It seems like a lot of effort has been put into Smart Lists yet something as basic as this is still not implemented.

Perhaps it's looked as a major change that not everybody would want, if that is the case make it an "option". This would allow people to view the browser in the old format or new format. Even if the new format was "read only", i.e it didn't allow writing of tags forcing people to use 3rd party programs to update them.

As radiokrishna demonstrates, look how many genres he would have to click on to browse a Deep House track, all these tracks should be under one "Deep House" genre but also displayable in the other respective genres.

 

This kind of multi-value feature can be very tricky to develop.
The data format that's usually expected for a tag is single values (typically: ID3 tags contain simple chains of characters, hence the coma separated values like "House, Deep House" etc.).

For Traktor, supporting multi-values would have multiple requirements, like:
- they'd need to handle the separator between the different values, which is probably something the users would want to customize depending on the tag format of their files. I could understand that this kind of in-depth configuration is not necessarily something you'd want to expose to the user: if you pile up this kind of advanced config, you create a messy user-experience
- internally, if the entire Traktor codebase assumes that tags are single value, it would be a huge code change to migrate to multi-values - like weeks and weeks of work, with risks of breaking the user search experience if you introduce a bug. It's simply not worth the risk & time investment if not enough people are asking for it

If this is really painful to you guys, I guess we can try to implement this with third-party softwares.
I'm thinking of making my program https://github.com/16pierre/traktorBeetsIntegration stand-alone (i.e. remove the dependency on the "beets" tool). It could definitely do something like:
- go through all your tracks
- read the genre tags and split the genres with a given separator
- add the track to a playlist for each of its genres

I'm also thinking of introducing support for "sub-genres", with sort of nested folders like "house -> tech house, deep house etc.".
Anyway, if this kind of stuff interests you (like: you're not afraid to edit some json configuration and run a python script on your laptop etc.), I could give it a shot

 

Thanks for your input on this.



- they'd need to handle the separator between the different values, which is probably something the users would want to customize depending on the tag format of their files. I could understand that this kind of in-depth configuration is not necessarily something you'd want to expose to the user: if you pile up this kind of advanced config, you create a messy user-experience


I would simply provide a drop-down option as to what separator to use, Keep the options limited such as , ; / (sorry couldn't write the name of the characters as the forum said I was spamming )


So something like....




- internally, if the entire Traktor codebase assumes that tags are single value, it would be a huge code change to migrate to multi-values - like weeks and weeks of work, with risks of breaking the user search experience if you introduce a bug. It's simply not worth the risk & time investment if not enough people are asking for it



As I mentioned in my previous post, I don't think it would have to modify the existing code as such, it could be additional code for an alternative display. Obviously I don't have an insight to Traktors code but logically this shouldn't be a lot of work.


The genre field is stored in the collection.nml file. At some point Traktor's code uses this field to collate the tracks to display by genre. It's at this point where the second option would parse the fields with the separator before returning to the existing code.


This way you get to keep the standard display that everyone is familiar with but have option to display Multi Genre which would use the additional code. If there are bugs than you can simply switch the option back to the original display, thus not breaking anything.


And again without knowing Traktor's code this may sound simpler than it actually is.

 

Thanks for the offer!
But this is already possible with itunes xmls. I've been rolling all my required genre tags, derived from multi value tags, into 100s of separate playlists. But, this is a step that should not be necessary in 2021... - see points below.

Re-writing the browser / library to correctly deal with multi-value tags is not trivial (especially with an ageing source / code base that was written more than a decade ago...), agreed.

But, this:

Would be true, if it was still the year 1999

Many (metadata) container formats have been spec'd/engineered with multi-values in mind. (eg vorbis)
ID3 is a tad tricky - as it was originally conceived without multio-value metadata in mind... but it became apparent, that this is a vital feature. So, the 'agreed upon' way came when "v2.4 was published on November 1, 2000, and remains the latest version. A major new addition is that a text frame can contain multiple values, separated with a null byte" - see links in the first post, and many a media players / metadata editors do apply the same convention to v2.3 without any issues (other than people mis-understanding what is actially happening) for a decade plus.

Also - to clear up a general misconception - there is no comma/semicolon in the tags itself even though Traktor also displays it as such (i.e. depending on the program & configuration people use, these NUL / separators in id3 can be displayed as , ; / or \\, but displaying these with a comma has become the norm. Either way, this regularly confuses people...).
Also - Traktor uses Taglib (https://taglib.org/) to read/write metadata, which does handle NUL separated multi-value on id3 2.3 & 2.4 as expected - it's Traktor that does not interprete these as per the file specs.
And that, after this being established for over 20 years now, should not be the case anymore.
Let's see. I'm still hoping that this long standing issue will be fixed some time soon - especially now that there is a browser/library rewrite in the works...
c.

 

Interesting references, thanks ! The kind of feature flag you're suggesting makes a lot of sense

 

This is an interesting point which I saw the other day, pretty sure it was on an old post on these forums but may have been somewhere else.

I use MediaMonkey on Windows which does a great job of displaying multi-genre. I also use it to tag my files directly from Discogs which works really well.

MediaMonkey uses a semi-col0n as a separator but I was curious whether this was just what was displayed in the front end and whether it used something else when writing to a physical file. Loading up an MP3 in a editor shows that the header is also a semi-col0n in this instance, i.e the semi-col0n is actually written to the tag.




As you say though, different programs can use different separators and as we both agree it seems limited to a handful that are actually used. These options should be available to Traktor so the user can decide what separator to use for their requirement.

I think there will be cases where people have files from different sources which may use different separators which could cause issues. Not sure if the recommendation would be for the user to sort out all their files to a certain type of whether Traktor could parse from all the common separators as it's unlikely that a Genre would have non alpha numeric in their name.

The only separator it shouldn't split on is a "space" as genres such as UK Garage or Alt Rock wouldn't work.

 

This wouldn't be such an issue if Traktor just did away with the pitiful (and since Smart Playlists, unnecessary) smart folders under the Collection.

 

I strongly disagree - this would just obfuscate & hide the actual underlying issue and only help those who feel visually hindered or confused by the smart folders.
The whole functional aspect would still be as broken, and Traktor would still not handle metadata as per the file conventions...
c.

 

Perhaps unnecessary for some but not for the many who are requesting this change. Smart Playlists are unusable for me mainly due the the lack of multi-genre.

 

I'll have to have a good dig through this thread but after a couple of sessions finally looking into smartlists and posting about it in another thread I have to say I'm deeply disappointed that they're not in fact very smart at all it seems ;(

 

This would be a great feature. I have many tracks that dont sit in one genre. At the moment I have to export my genres as playlists to browse properly