Some great thoughts on genres here and I’m really looking forward to this being implemented. My thoughts:
There are benefits to both user-defined and Roon-defined genres, and the best solution will be to have the best of both worlds.
In terms of the data structure: what I would like to see in Roon is some kind of genre hierarchy, as described above, of 12 or so main genres. This is what I had in my old music software. Then, if I clicked on “rock”, I would get about 10 sub-genres such as blues, metal, psychedelic rock, indie, etc.
In terms of where the data comes from: this is more tricky. I had “groomed” metadata before migrating to Roon, but in a way it was refreshing to break this mould and to see how Roon has tagged the genres. However I suspect that as time goes on, I would like to have a more organised genre system again. The main thing is, I don’t want to “lose” the wider rich metadata that Roon gives by editing it myself and “taking it off the grid”. Also, I don’t want to lose the genre and artist associations that Roon has by changing the genres to something that Roon doesn’t recognise.
What about genre and style tags. I used to look at Discogs and followed the genre en style tags. I noticed that Roon don’t show the style. Example the album:
Eye In The Sky - The Alan Parsons Project has the genre Rock, Pop and the style Progressive Rock and Soft Rock. So It would be nice to play al albums with Progressive Rock.
@brian Ok, let’s leave tags aside. But I still don’t get it.
You are saying
All genres, Rovi’s and Roon’s and mine, live in one namespace.
Your curating consists only of defining a more sensible genre structure and mapping the equivalence relationship between Rovi and Roon genres.
The metadata you bring in automatically is only from Rovi and includes only album assignments to Rovi genres. Same as now.
Through your genre equivalence mapping, you automatically create an album assignment to Roon genres, perhaps more rational but not dramatically different.
Correct? So far, this new structure doesn’t dramatically improve on the current system. The improvement comes in enabling other things:
User editing of both genre structure and album assignment can be non-destructive and intent-preserving. Even pretty radical editing. (It is intentional that I use the general “structure” rather than the specific “hierarchy”.)
If you locate other metadata sources, you can add their genres to the namespace and define their mapping to Roon genres and leverage their data. (Possibly adding conflict resolution?)
And possibly in the future, use the cloud for crowd sourcing genre assignments from Roon users…
All genres, Rovi’s and Roon’s and mine, live in one namespace.
Yes. Genre identity = genre name.
Your curating consists only of defining a more sensible genre structure and mapping the equivalence relationship between Rovi and Roon genres.
Yes. The Rovi<->Roon mapping is an equivalence relation, but future sources<->Roon might require lightweight curation work.
The metadata you bring in automatically is only from Rovi and includes only album assignments to Rovi genres. Same as now.
Yes.
Through your genre equivalence mapping, you automatically create an album assignment to Roon genres, perhaps more rational but not dramatically different.
Yes.
Correct? So far, this new structure doesn’t dramatically improve on the current system.
Agreed. The intent here is to accommodate users with editing/grooming needs, and pre-existing genre data.
For people happy with the automatic behavior who never edit, this changes nothing.
The genre vs. style question is interesting. When I rip my CDs in dbPowerAmp, Rovi/AMG styles (= sub-genres) are written to a STYLE tag.
That is interesting. I’m aware of the STYLE tag, but after some investigation, I failed to figure out who (which apps/use cases) were populating it, using it, etc.
This example is a user interface trick on their website, not something fundamental to the underlying data.
In Rovi/AllMusic’s data model, all of those things are “genres”.
What they have done there, is taken toplevel genres and put them under a “genres” heading, and everything else under a “styles” heading.
You can tell that this is what’s going on by looking at the URLs:
Those two letters at the front of a Rovi ID (“ma” in this case) are a type code for the entity that the ID describes. Both genres and styles are in the “ma” namespace, and indeed, you can format the URL with genre or style and view all of them.
We could certainly do similar UI tricks to differentiate toplevel from non-toplevel genres. I don’t think we do anything like this at the moment, but we have in the past.
To get back to the tags, briefly: someone mentioned the possibility of tags forming their own hierarchy, and as a software architect I am tempted by elegant data models, but as a music lover I advice against it. I don’t want to spend too much time curating.
I thought of one example, which could be used to justify either personal genre editing (with a non-tree structure, a DAG) or tagging. I am currently listening to a lot of music that I would classify with a genre Nordic-Asian-folk-jazz-chamber-avant-garde. This categorization is different from flagging all those individual genres (Nordic, Asian, folk, jazz, chamber, avant-garde) because multiple genres are OR-ed, I would get the union. Similarly, it is not enough to focus on Lena Willemark and Anders Jormin, because those artists do a lot of other stuff, so again I would see the union set. And it would miss Silk Road Ensemble and others.
So that’s a logically consistent argument. But does that mean I would actually do it? Doubt it, at least I wouldn’t do it very often. Because listening.
So genre hierarchies are fine. But tags can stay simple.
@AndersVinberg LOL, Well, I guess I do classify as a geek, database nerd and sql jockey. I am also all for uncluttered interfaces, however, I do like having the ability to “do more” in advanced settings.
I have not done any research other than casual questioning; but, and this may be just in my circle, when I presented a list of choices in a selection check box this afternoon (like in tag manager); everybody I talked to assumed it was an AND function not an OR.
@Rugby Yes, as a geek you just disqualified yourself. And I’m disqualified too.
Roon (and Sooloos) actually has a reasonable model: multiple values in the same category are ORed, while values in separate categories are ANDed. So if search for “Thelonius Monk” and “John Coltrane” you get albums by both of them, the OR function. ANDing such values would often end up with the empty set. And similarly, if you ask for “24 bit PCM” and “DSD” you would get many high res albums – if those were ANDed you would see nothing. But if you ask for “Thelonius Monk” and “DSD” those values are ANDed. This seems to fit most people’s intuitive expectation. The case where you want the intersection of Thelonius Monk and John Coltrane does exist but is a pretty rare exception.
I have said many times that more is better where this is concerned. Having the ability to simultaneously use AND as well as OR conditions is fundamental to being able to leverage the metadata provided by Roon and enhancing the UI. Whilst some may argue it’s better to cater to the lowest common denominator it would seem to me that the kind of user that will see value in using Roon as a means of managing their listening is hardly the lowest common denominator.
I suspect that even the ‘lowest common denominator’ can tell the difference between OR and AND particularly when presented by a well designed software package. The key is presenting it in a way that enables the less ‘geeky’ not to have to understand. Roon is, for me, an intuitive program and I look forward to further developments in how I can explore and manage my collection. Not sure I’d want to have to make any sort of decision on this one tho! I’m with good vs bad!
As being a (medical) informatician with lots of experience in (hierarcies in) medical terminology I would sugest the following:
See genres as a specific hierarchy of a set of tags.
Roon can offer a specific hierarchy of a specific set of tags being the “Roon” genres.
Let users be able to make their own hierarchies (not only one) and choose their own names of the hierarchies and of each node (tag) in different hierarchies. Your work on classifying tracks, works and albums fits needlessly into our work on relation-oriented inference systems in the medical domain. In our experience it is more important to name the relationships instead of naming the nodes. A hierarchy is a set of a specific kind of directed relationships (kind-of hierarchy). You have already chosen for a semantic network approach. This way of handling genres fits very well in that approach
Then I will be able (as a bassoonplayer) to make a hierarchy of Bassoon at the top and Bassoon concerts, Bassoon groups, Bassoon solo, Bassoon with a few other instruments as subgroups.
Just started working seriously with Genres within Roon. At present it’s all a bit obscure to me, but I need more time to digest, so please forgive any naivety here.
I’m interested in whether you @brian have made any decisions as to how to rework the system, and indeed whether it has already changed since you started this thread.
I’m also interested in where Instrumentation should be. As a “Genre” in Sooloos I used it extensively, not grooming every album, but only using it to mark my particular areas of interest (String Quartet, for example). As @pieterdvr mentioned something similar above, I wonder whether this is something people other than us two use.
But bearing in mind that Instrumentation is simply not a genre in the real world, where should it be within Roon? (Putting it in Genre in Sooloos worked, but it’s still not really correct. But maybe we should just live with it there in Roon too?)
I know that Roon makes intelligent guesses in listing the instrumentation of works, based on their title. But does Rovi give you Instrumentation metadata also? And once you have a structure in place for Instrumentation, can you please merge all these data sources and make it editable?
