Genre Groomers...Help!

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.

Sit back and enjoy the ride.

1 Like

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!

Hi @brian,

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?

Thanks @brian, as always, for your efforts.

PS Couldn’t find an FAQ on Genres. Is there one?

Instrumentation should have its own dataset, definitely wouldn’t want to see it mixed with genres.

The proposal I outlined above (+ some ideas that came later in the thread, like the idea of configurable genre mappings) were implemented in 1.1 in August.

Roon has instrumentation as a field at the work level. Unless new information arrives that convinces us otherwise, that’s where we intend to keep it. As you noted, this is based completely on string munging. Rovi does not give us instrumentation data. We don’t support editing of this field right now, but we will in the future.

The main problem with using genres to represent instrumentation is that instrumentation is inherently not an album-level property: an album can contain several performances with different instrumentations, and it should be possible to pick them apart. Sooloos didn’t have the data model richness required to put it in the right place, and the instrumentations-as-genres hack was born. Our standards for data modeling are higher now.

The UI portrays instrumentation as a simple string, but under the hood, it’s actually a list of instruments and ensembles with quantities that can be determinate or indeterminate.

So for instance, we can parse this title:

“Music for Mallet Instruments, Voices and Organ, for 3 female voices, 3 marimbas, 3 glockenspiels, vibes & organ”

and know that there are 3 glockenspiels, an organ, 3 vocalists, a vibraphone, and 3 marimbas. There’s a hierarchy to our model of instruments, so we also know that this piece contains keyboards and percussion, even though those words don’t explicitly appear.

“Violin Concerto” turns into “1 Orchestra + 1 Violin”, which I know isn’t technically correct 100% of the time–but is a decent starting point for automatically populating data that can be repaired as a human later.

“Adagio for Strings” turns into [indeterminate quantity] strings.

I went through the parsing and hierarchy exercise as a research project, and we couldn’t decide how to handle the complexity in the UI, in focus, or in editing. So we decided to crunch the complex representation down to a rather short string and stick it in the UI. So for the three examples above, you get “Mixed Ensemble”, “Orchestra + Solo Instrument”, and “String Ensemble” as summaries.

There’s basically two paths to consider: the ambitious one and the simple one.

The simple path treats instrumentation as a work-level string. We pre-populate it somehow, and it’s editable. The existing parsing/munging stuff just becomes a means to generate strings automatically.

The ambitious path treats instrumentation as structured data–a list of elements that can represent instruments or ensembles, with determinate or indeterminate quantities. This system would have an understanding of containment hierarchy (e.g. a string quartet consists of two violins, a viola, and a cello), and classification hierarchy (e.g. a trumpet is a brass instrument is a wind instrument).

Both mechanisms could accomplish tasks like “show me the string quartets” equally well. The difference is that the first one would literally just match the word “String Quartet” against a string field, and the second would look for all instrumentations that contained a “String Quartet” among their elements.

Only the ambitious mechanism could handle focuses like “Show me all orchestral works that include a saxophone”.

Looking deep into the future, once we have a mechanism for including user-submitted metadata, the ambitious path is clearly much more powerful–we can model each composition’s instrumentation exactly, and use distributed editorial judgements to improve the accuracy and specificity of the data over time.

In the near term, the simple way is more immediately useful, because to most people, only a handful of instrumentations are relevant, and editing a simple string is much easier for someone working alone to groom their content.

We do intend to make instrumentation editable. As a general rule, we don’t release editing features for data model that we view as being in flux or incomplete (including work + performance level data as of today). Because we haven’t released editing support for those, we are free to change them around, fix the many problems, and make improvements. Once users have made an investment in grooming data that is structured in a certain way, things quickly end up set in stone, since we really can never make a decision that throws away a user’s edits.

@mike, btw, we should make sure that a good explanation of the current genre system ends up in the knowledge base you’re working on.

Very interesting discussion, but my attention was caught by something you said:

“The main problem with using genres to represent instrumentation is that instrumentation is inherently not an album-level property: an album can contain several performances with different instrumentations, and it should be possible to pick them apart”.

Er, surely “genre” is also not inherently an album-level property? In fact the ID3v2 TCON ‘genre’ tag is explicitly associated with a track. So it’s perfectly possible to have an album with a mixture of genres.

What does Roon do in this situation? Does it aggregate all the track genres into a collection of genre tags for the album? Thanks.

Er, surely “genre” is also not inherently an album-level property? In fact the ID3v2 TCON ‘genre’ tag is explicitly associated with a track. So it’s perfectly possible to have an album with a mixture of genres.

Every file tag is explicitly associated with a track, including obviously non-track-level things like “Album Artist”–this is a technical compromise inherent to file-based tagging, and not–by itself–a good argument for making all data track-based.

Prior to the advent of file-based tagging, there is ample historical precedent for genre as an album-level classification.

  • It’s how records were sold in record stores.
  • It’s how every major music metadata database (including the “big 3”: Rovi, MusicBrainz, and Discogs) treats the data
  • It’s how record labels describe their content when publishing their catalogs to retailers.

What we take away from this is: track-level genre distinctions within an album are an artifact of people managing files using file-level tags, and not something inherent to the way music is published or cataloged.

So, like the other metadata databases out there, we’ve put genre at the album level. When importing data from file tags, we aggregate track-level genre tags and pull them up to the album level.


@brian, one thing I’d love to see emerge in time is the ability to copy artist based genre data to albums by that artist where there is otherwise no genre data provided by Roon via its resources .e.g an unidentified album. Such data could then be regarded as user provided metadata much as if they’d captured the genre assignments themselves in Roon (they are, only they’re copying it from the albumartist and then tweaking from there).

Additionally, if an album is unidentified and thus has no genre information in Roon, make it possible for a user to then have Roon show the Local Genres for that album. It should ideally be a globally toggle-able setting that can also be turned on/off at the album level in which case the album attribute overrides the global setting for that album.

Additionally, if an album is unidentified and thus has no genre information in Roon, make it possible for a user to then have Roon show the Local Genres for that album.

We thought about this use case when building the genre system, but approached it a little bit differently.

This is how we intended for it to be accomplished:

  • Turn on display of Roon’s genres and Local genres globally
  • Go into the genre mappings editor, run through your list of genre tags, and decide how to map (or if to map) each one.
  • For any album where that causes a problem, go edit the album individually.

Basically, we’re pushing you to make the choices at the genre level, not the album level.

Any junky/sloppy stuff in the tags can be hidden, so they never show in Roon.

Common tag genres like “Jazz”, “Rock”, etc can be mapped to their Roon equivalents, so they don’t create clutter.

Situations where your tags have more specific information than Roon’s database work really well–maybe we only have “Jazz” but your tags have “Jazz” and “Post-Bop”. Your album can display both side by side even though Roon had some data.

Personally, I prefer to either map my genres from tags to something from Roon’s world, or hide it entirely, because I am used to Rovi’s tree, but I know there are plenty of people who re-arrange the genre tree, too.

1 Like

Thanks @brian, that makes things a lot clearer. I’ve turned on display of Local genres and will check my mappings. Other than the odd but of crud here and there my genre assignments originated from a combination of’s genre and style tags, so I’m expecting the mappings to be just about 1:1 from the outset. I also find Rovi’s genre clarifications works for me… probably because I’ve been tagging according to their genre and style metadata for years already.

and this leads me to my next request… Can the genre mapping be made to include an option to list only those genres for which there is not a match in Roon?

I’m glad the OP understands how frustrating it can be when the genres aren’t classified correctly lol!

I’m surprised by the lack of sub-genres for house and dubstep, not to mention the lack of trap lol + who calls Grime British Rap?? looool

I’ve looked through the forums and people are saying to check an option to use local tags for genres? That option isn’t there for me though :S Under “Genre Mappings” in “Library”, it tells me to select “Use Genres From File Tags” in the Import settings, but I can’t seem to find it there?

Well, it seems to be there - however, I’m looking at it via Roon on a PC. Is this one of those occasions where using Roon on a tablet is not revealing all the controls?

It’s there in tablets too.

My mistake sorry! I must have overlooked it xD

It is possible to browse tracks by genre, and not by the whole album?

I don’t think Roon tracks genres by track (as it were), so even though in the Track Browser you can use Focus to view selected genres, I think that these are only genres at the album level…

Could that be submitted as a feature request then, to give tracks genres and not just albums?

Please go ahead and submit it in the Features Request forum. No guarantees that it will get implemented, but the Roon folks will take note of it there.