lastgenre: Remove some bogus 'genres' from whitelist

[gwern]

The lastgenre documentation states that

The plugin chooses genres based on a whitelist, meaning that only certain tags can be considered genres. This way, tags like “my favorite music” or “seen live” won’t be considered genres.

This is a sane approach I agree strongly with. Allowing tags like 'seen live' would be a terrible idea: it tells you little about the musical style or content of the music - pretty much any music can be played live to some degree! Similarly, it would be stupid to allow genre tags like 'CD' or 'DVD' or '8-track tape': those are mediums/sources, not genres.

Unfortunately, in my finished imports, I spotted a few meaningless genre tags, and a read through of my local file /usr/local/lib/python2.7/dist-packages/beetsplug/lastgenre/genres.txt leads to a few more:

• "anime music"/"video game music"/"soundtrack": these 3 are chief offenders which exemplify the problem - any kind of music can and does get used in movies/TV-shows/games, from Jpop to symphonic classical music to choral chants to easy listening to techno. All these 3 tell you is something about the medium in which they used, but nothing about the genre, and should be purged with fire.
• "early music": I don't know if you could call this a genre at all, when it's defined as negation, any music from before the Baroque (or, almost all of human history and almost all countries throughout the world)
• "essential rock": because we wouldn't want to listen to _in_essential rock, apparently
• "niche": not sure where this comes from, it's not in https://en.wikipedia.org/wiki/List_of_styles_of_music:_N%E2%80%93R but it seems to be a minor synonym for https://en.wikipedia.org/wiki/Bassline_%28music_genre%29 and since it's an adjective which describes most music, better deleted.
• "singer-songwriter": this describes something about the performer, but tells you nothing beyond the fact that it must have vocals in it or else there would be nothing to sing.
• "background music": this seems questionable; the WP discussion makes it sound as if music from many genres (Baroque classical is mentioned more than once) count as background music and this is defined by the use not the content, and so is irrelevant to the genre.

(I was irritated to see "beautiful music" and "intelligent dance music" are actual genres. Talk about self-congratulatory.)

So these 8 could be added to the __init__.py as a filter on the whitelist to avoid them being stomped during syncs with the Wikipedia pages, or if people might want to add more, be put in a blacklist which overrides the whitelist.

[sampsyo]

Ha, "niche" is particularly egregious! Must have been a scraping bug somewhere along the way, or perhaps it came from an earlier version of the Wikipedia page. :smiley:

This is obviously a matter of taste, though. I, for example, am not as offended as you are by "early music", since I do think it denotes something specific. The solution here is probably to remove the obvious problems from the current whitelist, since we are not in the habit of regenerating it, and leave other preferences to custom per-user modification. As another example, many people would consider "video game music" as a genre because they have relatively little of it, but if you have a lot as you seem to, you might want to get more specific.

[sampsyo]

Oh, I meant to write: fancy opening a PR with your proposed removals?

[geigerzaehler]

This is obviously a matter of taste, though.

I agree. We should keep the whitelist as open as possible so people who might disagree can keep their genres.

or if people might want to add more, be put in a blacklist which overrides the whitelist.

I think this is a fair approach, adding a blacklist configuration option. We already have a whitelist option, but this is probably overkill in most cases.

[Kraymer]

Given that the whitelist path is customizable, if user don't want a genre she can just edit the file or maintain its own file copy. I like it like it is, and think a blacklist option would add complexity for no obvious gain.

[geigerzaehler]

I think a blacklist option would add complexity for no obvious gain.

I have to disagree. Yes, a blacklist will add complexity, but it’s not too much since it complements the whitelist. Also the gain is obvious: As this issue shows, some (maybe most?) people don’t want to delve into making a custom whitelist. Since the basic whitelist is quite solid it would be much easier to customize it through a blacklist. In particular, if we can just add blacklisted genres to the configuration instead of adding them to a file and then referencing that file.

I see this as a big gain for good user experience.

[Kraymer]

As this issue shows, some (maybe most?) people don’t want to delve into making a custom whitelist.

But in the end, if you're not satisfied with default behaviour, you still have to make a custom list, whether it's black or white (as already stated, we cannot aim to have an objectively perfect whitelist as it is a matter of taste).

In particular, if we can just add blacklisted genres to the configuration instead of adding them to a file and then referencing that file

OK, I agree that's more user friendly to not have to edit an external file and do it in config.yaml. But it creates an assymetry between the whitelist (ref to file) and blacklist (list). Sure you can rename the options, but the assymetry is still there.

In my case I maintain a very short whitelist (two dozen of genres) (+ canonicalization), that does explain why I'm not a big proponent of blacklist. But I can see how it could help people who just want correct tags (and don't matter the size of the library genres set) and are allergic to some genre wordings ! (I have no idea if they are that many, though)

[sampsyo]

An inline blacklist in the config file is a little bit confusing from a UI standpoint but is probably still worth it (an external text file would seem to be overkill).

[gwern]

Oh, I meant to write: fancy opening a PR with your proposed removals?

Done: https://github.com/sampsyo/beets/pull/944

as already stated, we cannot aim to have an objectively perfect whitelist as it is a matter of taste

It doesn't have to be perfect, it just has to be better. Or does anyone really think the plugin should be pulling and adding to music files genre tags like 'soundtrack'?

[Kraymer]

Or does anyone really think the plugin should be pulling and adding to music files genre tags like 'soundtrack'?

Actually 'soundtrack' is one of the 26 genres I keep in my whitelist

All these 3 tell you is something about the medium in which they used, but nothing about the genre, and should be purged with fire

Makes more sense to me to have Pulp fiction OST album sorted into the Soundtrack genre than spread across Funk, Rock etc. (I optimize my tags related to the way I browse/listen to my music). I see you don't share this opinion and I get your point of view but it just illustrates that what it's better for you may not be for others.

So it kinda hurts that amongst the 1400+ genres that we have, only 6 are removed, and except niche none of those strike me as particularly inadequate (I even used one!).

[sampsyo]

I'm totally fine with adding back "Soundtrack", BTW, for exactly that reason—I just thought some action was better than inaction. It's important to remember, though, that the defaults need not make everyone happy. :smiley:

[Kraymer]

About blacklist : I forgot to consider in my previous comment that in the default configuration, the default whitelist path is not visible. So editing the internal whitelist is not as straightforward as I initially thought for the average (non contributor) user and I understand better @geigerzaehler pov.

So if we could find a way to better promote the default whitelist path - so that user can simply edit it to remove the genres she dislikes - then there would be no (or less?) need for the blacklist option, right? For example whitelist option default value could be install_dir/beetsplug/genres.txt instead of True (and setting it to empty string would mean False). By typing beet config -d, user could get the path easily and start its custom copy. Or path could be added to beet config -p or a new config command option could be created to ease the genres edition ...

About reducing whitelist size : genres are so subjective, trying to remove some entries by considering all possible use cases is tricky if not impossible. We're not talking about genres per se, but about the genre tag and how it is used by people to classify/parse their music.

I just thought some action was better than inaction

I would have vote for inaction on this one ! but I won't struggle it ;)

[sampsyo]

Copying the file out of the installation directory is still a little cumbersome. We might be better off just documenting:

curl -O https://raw.githubusercontent.com/sampsyo/beets/master/beetsplug/lastgenre/genres.txt

as the canonical way to obtain/edit the whitelist.

[gwern]

Makes more sense to me to have Pulp fiction OST album sorted into the Soundtrack genre than spread across Funk, Rock etc. (I optimize my tags related to the way I browse/listen to my music).

I agree, if you want to listen to your Pulp Fiction OST tracks together, that should be possible. Fortunately, there is already a way to organize your music exactly as you want: it's called the 'album' tag.

[Kraymer]

We might be better off just documenting

yes a little hint in the doc would be nice !

[sampsyo]

Done, for now at least.