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).
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.
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.
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
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.
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.
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
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”.
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.
