Author Topic: Proposal: Extend 'Genre' hierarchy with 'Subgenre'  (Read 93699 times)

alec.tron

  • Sr. Member
  • ****
  • Posts: 752
i'll answer in a few days time. Anyone else please chip in if you want to add anything
Bump - would be curious to hear what/if some walk-able path popped up in your head about this ?

Also, I would really love to see this realized:
https://getmusicbee.com/forum/index.php?topic=21629.msg126937#msg126937
which ties into this topic of how to deal with genre/subgenre display and how to best visualize cascading/hierarchical genre definitions.

Cheers.
c.

zigzag10

  • Jr. Member
  • **
  • Posts: 60
Bit late, but I'm another one who would love to see subgenres linked to genres - as outlined in this suggestion

alec.tron

  • Sr. Member
  • ****
  • Posts: 752
Hai.
I still would really really wish for a way to have a 3rd degree genre (or even better free classifications/taxonomy for any/custom tag clouds too...  so one could also set-up musical instrument or other tags taxonomy systems inside of MB [https://en.wikipedia.org/wiki/Musical_instrument_classification]  :D ).
Probably not likely, seeing how old this request is and since Steven said he doesn't know how much time he can put into MB in the future, but thought I'd ping it again nontheless in case there's a chance in the near or far future ;)  


Also, some more thoughts, while on it - in fake xml syntax below to illustrate the idea: for better manageability, this would be grand too and people could cascade their music world/taxonomy themselves (and even for all metadata categories, if one were to add a mapping table, i.e. where to derive the taxonomy-able tag cloud from... i.e. the fake 'Tag id="DISCOGS_STYLES"' field/source declaration below):

Code
<Genre Categories,  Tag id="Genre">
  <Genre Category Name="Electronic" ChildName=Genre" />
    <Child="House"/>
    <Child="Techno"/>
    <Child="Drum n Bass"/>
<Genre, Tag id="Genre">
  <Genre Name="Drum n Bass" ChildName="SubGenre" />
    <Child="Halftime"/>
    <Child="Jungle"/>
    <Child="Techstep"/>
<SubGenre, Tag id="DISCOGS_STYLES">
<SubGenre Name="Jungle" ChildName="Style" />
    <Child="Atmospheric Jungle"/>
    <Child="Ragga Jungle"/>

The beauty being that a track tagged as "Atmospheric Jungle" as a style, would automatically also appear in the parent categories groups (top to bottom: Jungle -> Drum'n'bass -> Electronic ), with a single tag value.
The olde downside still being that tags have to be unique, and only belong to a single hierarchy per unique string...
Churs.
c.
Last Edit: July 04, 2020, 11:10:52 AM by alec.tron

Steven

  • Administrator
  • Sr. Member
  • *****
  • Posts: 34312
so today, you tag Genre and MB can derive and group those genres into Genre Category
Are you proposing that people instead tag Sub-Genre and MB derives/ groups Genre and Genre Category?

I assume today you tag Genre, so how would the transition from tagging Genre to Sub-Genre work?

alec.tron

  • Sr. Member
  • ****
  • Posts: 752
Hey Steven,
hope you're good wherever you are!

Atm I am using what would classify as genre, subgenre & style values interchangeably inside the same Genre tag field already anyway (out of necessity), which means I am using redundant tags to have them appear across a variety of genre/subgenre/style based playlists/groupings.
So this proposal should work with the existing  'single genre field for everything' paradigm we've had for yonks (and this suggestion shouldn't change anything in terms of end-user behaviour), but adds an additional angle for people who want to use a deeper (than 2 levels) taxonomy system built in XML for their file tag source(s)/clouds.

I'll stick to the Genre tag based example:
Atmospheric Jungle -> Jungle -> Drum'n'bass -> Electronic
level depth for now.
As is - I have all of these as Genre tags on a file: Atmospheric Jungle; Jungle; Drum'n'bass
And the last parent layer, i.e. Genre Category "Electronic" (IF i have '  <Genre Name="Drum'n'bass" Category="Electronic" /> ' set), is done via the xml definition only as is already.
Correct ?

My understanding/idea is that this XML based relationship definition that already exists could be extended, and without forcing anyone needing to 'transition' into using sub-genres or the likes...


So what I am proposing is to:
- add functionality for additional n'th level relational / taxonomy definitions coming from the (or a new dedicated) xml directly, definable by the user, that work with the users' existing, unique tags (without changing the current core system for the any MB user [i.e. the 2 layers Genre Category & Genre way] )
This is what a fake xml syntax, for a 4 level deep taxonomy relation could look like, if all but the last hierarchy level were to do their NameCheck against the 'Genre' field (as long as each levels' returns is unique and each possible value is only "parented" once in the xml... So if I want "Drum n Bass" & "Jungle" to each be allowed to have further children,  in slghtly adjusted fake xml syntax (with generic names & tag ID  defintion in the same row... ):
Code
<HierarchicalName="Electronic" Tag id="Genre"/> 
    <Child="House"/>
    <Child="Techno"/>
    <Child="Drum n Bass"/>
<HierarchicalName="Drum n Bass" Tag id="Genre"/>
    <Child="Halftime"/>
    <Child="Jungle"/>
    <Child="Techstep"/>
<HierarchicalName="Jungle" Tag id="Genre"/>
    <Child="Atmospheric Jungle"/>
    <Child="Ragga Jungle"/>
<HierarchicalName="Atmospheric Jungle" Tag id="MyOwnCustomSubGenreField"/>




- the Genre Category (or a new 'Relationship Browser') browser pane would need to be able to display taxonomy definitions ( i.e. nested/hierarchical structure, IF each value is unique...!). i.e. as long as this is defined in the xml (the nesting functionality we do have in the Navigator panel already, i.e. endlessly nested playlist structures...)
Code
[-] Electronic
   [+] Ambient
   [-] Drum'n'Bass
      [-] Jungle
         [-] Atmospheric Jungle
   [+] House
   [+] Techno
[+] etc
[-] World Music
   [+] Africa
   [+] India
   [-] Latin
      [-] Cumbia
         [-] Chicha
      [+] Samba
         ...
[+] etc


- and finally, if the above is worth considering, if it would even be possible to open such a grouping / taxonomy system to work with other tags/tag-groups as well  - i.e. the '<SubGenre, Tag id="DISCOGS_STYLES">' part or the instrument example in the previous xml code mockup, so one could define per hierachy/nesting level, which source tag is used to retrieve the xml defined tag values. Meaning that I as a user have the option to set any parent/child level relation inside the xml, have these display as parent/child groups in the browser pane, and fill these with tracks base on unique tag cloud values derived from custom field per parenting level...
i.e. the Tag id="MyOwnCustomSubGenreField" hint  above, or the instrument taxonomy use case, along the lines of something like this:
Code
<HierarchicalName="String Instruments" Tag id="Instruments"/>
    <Child="Bowed String Instruments"/>
    <Child="Plugged String Instruments"/>
<HierarchicalName="Bowed String Instruments" Tag id="Instruments"/>
    <Child="Cello"/>
    <Child="Contrabass"/>
    <Child="Viola"/>
    <Child="Violin"/>
<HierarchicalName="Violin" Tag id="Instruments"/>
    <Child="Piccolo Violin"/>
    <Child="Pochette "/>
    <Child="Five String Violin"/>

whereas the above could then look like this in the hierarchical browser pane:
Code
[-] String Instruments
   [-] Bowed String Instruments
      [+] Cello
      [+] Contrabass
      [+] Viola
      [-] Violin
         [-] Piccolo Violin
         [-] Pochette
         [-] Five String Violin
   [+] Plugged String Instruments
[+] etc


Hope that makes sense, as in my head this would not require any transition whatsoever, but each user could decide if they wanted to dive deeper into structuring taxonomies for a tag cloud or even groups of tags (be it genres or instruments just being 2 examples) as they see fit for their musical world, and people craving for a 3rd/4th/5th/n'th level could add this logic to the xml themselves, if the taxonomy definition inside the XML was structured slightly differently (I think :D)  & if we had a browser pane to support this.

Cheers, thanks for considering this again & all the best.
c.
Last Edit: July 04, 2020, 03:14:11 PM by alec.tron

hiccup

  • Sr. Member
  • ****
  • Posts: 7785
In the past I created and shared a sheet that contains genres and their sub-genres.
(obviously a personal and subjective list, and probably in need of some updates by now)

I noticed that the download link I then posted is now obsolete, so just in case it helps in getting some traction and perhaps discussion on the general idea I thought to post a new download link here:

download Genre-Subgenre sheet

alec.tron

  • Sr. Member
  • ****
  • Posts: 752
Neat!

There's as many ways & permutations of genre/subgenre definitions as there's people (or nearly, imo :D ) as the factor of ones own exposure & appreciation of a given style will always drive how developed each genre/subgenre arm is and how it is categorized in ones own mental map of music definitions (especially the grey areas & newly developing or ultra-niche genres...).
So I don't think this can be done universally...
For me personally the Genre Categories, especially for the World/Folk areas isn't structred enough (i.e. Compas & Flamenco being their own 'Categories' - but - I do love african & latin, and especially carribean sub genres from the last 100 ish years as well, and especially the later is a weak / undeveloped area of many music taxonomy systems unfortunately...)

But, if the more free/user define-able approach outlined above holds value to Steven and could be realistic, we could fairly quickly put that sheet into an xml syntax & it could be a good starting point for people and everyone can customize from there potentially maybe.
;)

Churs.
c.

zkhcohen

  • Sr. Member
  • ****
  • Posts: 346
This is an extremely powerful customization option and AFAIK MusicBee would be the first to implement it.

+1

Steven

  • Administrator
  • Sr. Member
  • *****
  • Posts: 34312
Atm I am using what would classify as genre, subgenre & style values interchangeably inside the same Genre tag field already anyway (out of necessity), which means I am using redundant tags to have them appear across a variety of genre/subgenre/style based playlists/groupings.
...
I see what you mean now and its a clever idea. Although I can see it as a useful addition, the concerns are I think it will end up being something only a very few people who are reading this topic would be aware of it. And secondly I think a a predefined structure packaged with musicbee is something that could be included with MB so its more easily discoverable and up and running with little effort but is there any consensus on the categorisations and would people be using the tagged genres the same way? Probably not, so probably a lot of effort for someone to get this up and running.
I dont want to rule it out as there seems to be some interest in this topic. So I will see what the further responses are and also take time for my own thought on this proposal.

alec.tron

  • Sr. Member
  • ****
  • Posts: 752
Thanks a lot for your thoughts!
And indeed - it probably would be a fair bit of work.

A few more of my thoughts:
- initially it will probably be explored by the ones in this thread here and the core MusicBee audience, true. But, IF it had  the suggested 'hierarchical browser pane' inside Musicbee's Thumbnail Browser (to go with the restructured XML that allows heirachical/taxonomy mapping) and a meaningful / well defined default XML (for Genres, Moods, Instruments - all would be possible to set up as demo/default xml files to help people understand the system and have additional value right away) as a starting point, this would be easily discoverable & usable, as well as tickling curiousity, by/for everyone I would think

- I'm not sure I understand the point here:
"I think a a predefined structure packaged with musicbee is something that could be included with MB so its more easily discoverable and up and running with little effort"
correctly - but as far as I understand it: for sure! - pre packacking a few examples when introducing an (optional) core change like this would be mandatory imo (and I'm happy to help create these demo / default sets (based on what we have in the configuration.xml already, IF there were a new xml or syntax for hierachical relationships) probably with others that are interested in this - i.e. hiccups genre xls table is a great starting point for a 3 layer taxonomy system, that could work really well as an introduction / as broad as possible genre default useful for many). But yes, to be fully valid for ones' music library, this would require customization at some point, but this is also the good point, that people can adjust this easily, if their world-view or genre/metadata adopt & morph over time. And, most MB users do heavy customization already with their metadata, which in turn this suggestion would work with hand in hand.

- also - as zkhcohen pointed out, this will be extremely powerful, and if open to work with any metadata field the users wants it to, I would think this will appeal to a new set of professionally oriented users, i.e. musicians & producers for their sample libraries, as well as music/sound scientists as there simply is no tool to do this yet (I think - at least I have not found one yet...) as it can be used for any music file based metadata relationship mapping.

- additionally - and I'm dreaming here - IF there also were a UI to customize & set up the xml (and manage the pitfals like unique nested name requirements etc in a visual/easy to understand manner ), this could go a long way to make less geeky/tech savy users comfortable to use & customize this as well for their music world

- as for the extra work, you don't seem to be too phased by funding offers, but if there was crowd-funding project organized to make this more viable and this could sway you, let me know and let's chat via PM as I'd be happy to set something up for that

I'll shut up now, and keep my fingers crossed more people show interest in this ;)
All the best.
c.


ps. one least tech note for the suggested panel... :D
As this could become overkill quickly (if a large hierarchical structures get shown per default without any context or meaning), I'd suggest to only spawn a given hierarchy tree IF a tag necessitating that hierarchical tree actually exists in a library.
Meaning, this hierarchical tree:
Code
[-] Electronic
   [-] Drum'n'Bass
      [-] Jungle
         [-] Atmospheric Jungle
would only be shown IF I had a file tagged with "Atmospheric Jungle", and the track tagged with "Atmospheric Jungle"would appear in all of the above 4 hierarchical categories (acting like smart playlists for the specific tags as well as the childrens' content)

If  I only had 1 (or more files) tagged with "Drum'n'Bass" in my whole library though (but no file tagged with "Atmospheric Jungle" or "Jungle"), I would then only see this hierarchy:
Code
[-] Electronic
   [-] Drum'n'Bass
And not the additional empty hierarchical layers as these have no meaning for me or my library and should therefore not be shown...
Meaning, there can be all sorts of hierarchy definitions inside the xml, but the taxonomy/hierarchy shown in MB in this proposed hierarchy view/panel always is in sync with the data actual inside of the MB library.
Last Edit: July 11, 2020, 11:08:17 AM by alec.tron

Steven

  • Administrator
  • Sr. Member
  • *****
  • Posts: 34312
I am leaning towards doing something. But as mentioned I do think there needs to be something that is 'ready to go'
So if a user adds this new "Relationships" panel (or whatever we end up calling it), it needs to have a hierarchy already in place even if its a starting point. So that could be a basic hierarchy of genres for example so at least the user gets the point even if it doesn't work that well to start with for that persons' genre usage.
Although I agree XML is probably the right technical solution for defining the hierarchy, again it might be easier if a simple text file with indenting?

Steven

  • Administrator
  • Sr. Member
  • *****
  • Posts: 34312
This is what a hierarchy could look like:
Code
<Genre>
Blues
  Blues
    African Blues
    British Blues
    Jump Blues
EDM
  House
    Acid House
    Disco House
World
  <Location>
  Africa
    Ghana
  Europe
    Spain
    Portugal
notice at the top level <Genre> is used, but under World, the <Location> tag is used. I would expect the lowest level leaf nodes needs to match whats actually tagged. So some files would need to have tag values of "African Blues", "Jump Blues" etc, and some files would need a genre of "World" and location value of "Ghana", "Spain" etc. The hierarchy values at higher levels wouldn't need to match any tag values. But mixing tags like this would really just be for power users. Just having <Genre> as the default would probably suffice for most
Last Edit: July 12, 2020, 08:06:08 AM by Steven


hiccup

  • Sr. Member
  • ****
  • Posts: 7785
For those interested, I updated my genre hierarchy list.

An important change is that I added 'Roots' as a genre category that now contains: Blues, Country and Gospel.
Also some genres and sub-genres were added.

I find Folk/Ethnic/Region still a bit problematic and difficult to force into this hierarchy in a way that makes sense and is practical.
The way it is now is e.g. breaking my own adage of not mixing genres and locations in the same taxonomy.

This surely needs some more thought and a plan, but I will probably need to make some changes in how regions/locations are used (or even present) in this sheet.

download Genre-Subgenre sheet
 

 
Last Edit: July 12, 2020, 01:39:50 PM by hiccup

alec.tron

  • Sr. Member
  • ****
  • Posts: 752
I am leaning towards doing something.
Yay!

But as mentioned I do think there needs to be something that is 'ready to go'
Happy to set that up if that helps, based on the current genre / instrument names in the configuration.xml, or 3d party / hiccup's suggestion. Let me know if that would be helpful @Stephen and I'll set that up once you have decided on a syntax.


Although I agree XML is probably the right technical solution for defining the hierarchy, again it might be easier if a simple text file with indenting?
Syntax wise, I have no preference. What I would recommend is to stay as explicit as possible. i.e. that every parent (and every leaf node where necessary for the hierarchie under that leaf, until the next definition overwrites the previous) should always come with its' own tag/field declaration where to derive from. See example below.


The way it is now is e.g. breaking my own adage of not mixing genres and locations in the same taxonomy.
When you say 'now' do you mean inN Stephen's example ?
As what he is suggesting is valid for all tags, not just genres. So you could have a  "Relationships" panel that only establishes parent/child relationships for genres, and it's up to you how far you want to customize those - name, or branching/depth wise.
But, this goes far beyond just a 3rd layer to manage genres....
If I understand Stephen correctly, and this was my hope, that I could have relationship trees & integrated auto oplaylists generated for every tag there is on my files.
i.e. this is what I would attempt for my library in the  "Relationships" panel:
Code
Genres
<Genre>
Blues
African Blues
British Blues
Jump Blues
EDM
House
Acid House
<DISCOGS_STYLES>
Disco House
<DISCOGS_STYLES>
WhereFrom
<Location>
Africa
Ghana
Europe
Spain
Portugal
InstrumentsInvolved
<Instruments>
Bowed String Instruments
Cello
Contrabass
Viola
Violin
        Piccolo Violin
        Pochette
        Five String Violin
Plugged String Instruments
...

whereas the above would then look like this in the  "Relationships" panel
Code
[+] Genres

[+] WhereFrom

[-] InstrumentsInvolved
      [-] Bowed String Instruments
         [+] Cello
         [+] Contrabass
         [+] Viola
         [-] Violin
            [-] Piccolo Violin
            [-] Pochette
            [-] Five String Violin
   [+] Plugged String Instruments

One worry - with large libraries, this panel, if set up with multiple taxonomy tree definitions, all acting like smart-playlists and also grouping the childrens' content - this could become quite compute intensive, no ?
So maybe it should be possible to use multiple text/xml files one can switch between ? i.e. instead of declaring all in one text file, for the above examples I would have 3 text files, one for the Genre Taxonomy, one for WhereFrom / Location, and a third for InstrumentsInvolved / Instruments.
This approach would also make sharing & swapping/testing these taxonomy definition text files easier if the "Relationships" panel could toggle/switch between multiple files in the same directory for example.

Churs & all the best.
c.
Last Edit: July 12, 2020, 04:05:22 PM by alec.tron