Genres in MusicBrainz


Over the years, “When will MB have genres?” has been a fairly frequently asked question. For any of you who are (still) wondering, the official answer is “soon”. Here’s how it will work (according to my sources).

A minimalist approach

Instead of being designed into the database, genres will be pulled from folksonomy tags .

Somewhere at the UI level (in the page templates and/or javascript), an entity’s tags will be compared to a canonical list of genres. Any matches will be considered that entity’s genre(s).

Why I think this is cool

I think this is a good middle coarse between a controlled vocabulary and folksonomy.

It’s an approach that can be as simple or as complex as we like without getting into schema changes.

If you don’t like the canonical list, you could presumably compile your own and put it in a userscript. Similarly, anybody using the web service could implement their own version of this approach.

I think there are some really cool, really over-complicated things that could be done with tags, but I’m glad MB isn’t doing any of them. At least not right now. :slight_smile:

Related Tickets


I’m not an MB dev. I might have no idea what I’m talking about. Corrections and clarifications would be appreciated.

"Soundtrack" is not a genre

I’ve always wondered why we don’t have this already!
Seems a no-brainer to have a ‘genre’ tag set and then a ‘everything else’ tag set. Thought there was probably a reason I hadn’t thought of yet.

Thanks for the update!


That sounds good. I’d like to see Picard allow the user to choose between “hardcoded” genre or most popular tags, or even a mix of the two (e.g. “genre + x most popular tags”).


Yes, it would be cool if Picard would have access to the information the server has. I hope it will be exposed via the webservice. Having a predefined list of genres in a central place would help a lot and would be much better than just the blacklist currently in the default implementation :slight_smile:


Would love to see this feature, although I always thought it should be in a new field, not just another tag category.

the biggest discussion is how many genres do you allow, there is rock, but there is also psychadelic rock, and neo-psychedelia under that one.

If you make it customization, how do you grantee standards going forward?


I can see this go two ways:

  1. server side: tags get some kind of hierarchy, like instruments have, and a „specifity“ or level setting. For tagging you can select a „how specific do you want it“ setting, and every tag below it will get mapped to a parent (or grandparent…) instead.

  2. Picard just uses a simple mapping relation that translates from server tag to client tag. The software could ship with a number of canned mapping tables, and let you provide one of your own, maybe based on the shipped ones.

I prefer the second approach for its relative simplicity.


Perfect, exactly what I was thinking too.

Using @zag2me’s example, ‘rock’ would be the top-level genre, ‘psychedelic rock’ the next, and ‘neo-psychedelic rock’ under that, etc. Or simply ‘genre’ and ‘sub genre’ or similar.
Then you can pick what you want to tag with in Picard, eg ‘all tags’, ‘just top level genre’, ‘just sub genre’, ‘just bottom level genre’ or something like that.

Obviously it’s going to be an endless fracas in regards to how this genre table is organised and what goes where, but that seems like exactly the kind of ‘fun’ discussion melee that MB editors could get their teeth stuck into :wink:

I don’t really understand your second example sorry @sparkinson. Seems like it might be adding more user-end work for a program that’s already extremely opaque?


If I’m not mistaken, “we enter tags normally, give Picard a mapping of tags that should match to genre X, let people define more matches if they want to, say, store ‘drone doom candypop’ as a genre too”.


Let me flesh out my second option with examples.

This model says to keep everything server side as it is, so let’s take three random existing recordings:

has the tag gabber,

has thrash metal, and

is tagged francophone.

Picard (or similar software) could come with lists of mappings, for example a simple textfile, which would specify how to apply a tag. Let’s say rough.txt contains:

  • gabber: electronic
  • thrash metal: rock
  • francophone: pop

If you used this file, the first recording would be tagged electronic, the second one rock, and the last example as pop. But you can ship multiple files, so a file balanced.txt could contain:

  • gabber: drum and bass
  • thrash metal: heavy metal
  • francophone

The tags of the recordings will be drum and bass, heavy metal, francophone, respectively. Picard can come with a number of those files, and allow you to chose one, or supply your own custom mapping.

All that said, I like the first option I gave better, as it puts more data on the server, does not have issues with old software versions using stale lists, etc. But it would need server support, maybe a schema change.


Randomly stumbled across this today from wikipedia data analysis.

Would provide a good dataset base for any genre implementation.