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.
3 Likes
@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 allmusic.com’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.