Well, the oddball genre is definitely coming from “Use Work genres…” After a whole bunch of poking and prodding, I figured out that the specific song was also on a single, and that is where the other genre came from. I did a search in Wikidata for the work name, and it gave a single result which was a single. The search did not find the album I’m actually working with. Must be my misunderstanding of how Wikidata works. I’ll get there.
So, the plugin works as designed, and now I have some thinking to do. My first thought is that I would rather have only the genre attributed to the work as it is on the album. My second thought is that more is always better. My third thought is that all the tracks on an album should be the same. My fourth thought is that they could all be different. My fifth thought is that I’m spiraling.
Just a thought, but what about a limiter for the work genre to only include the genres as listed in the current work? Seems like it would add an order of magnitude of difficulty, and I’m not sure how useful it would be. Or, maybe a selectable number of genres from each source to include, like the “Maximum number of Genres” setting in the Metadata/Genres menu in Picard itself; that might be more useful.
The upshot is;
The plugin works as advertised, and is awesome.
Suggestion for an option to select the number of genres to add from each source.
I have to rethink what I’m actually looking for in a plugin to assign genres to my tracks.
This is way better than the Last.FM plugin for genres.
I too, am still figuring it all out. I think they have attempted to design a database from the ground up that can cover any type of audio entity. This means its very generalized, and generalization can sometimes look very confusing when thinking of specific cases. But I think I understand the dream
Heh… The last thought is always a doozy! Nah I appreciate having the additional input through the process and I can tell you’re quite methodical
For sure this is not always going to be true. For just the release group genres maybe it would be, but in some cases, you can have different artists contributing on different tracks on the same album; I saw this in some hip-hop tracks, but there’s prolly many other examples.
With works, I am still not sure I understand all the cases very well. Honestly I am not even sure what you are asking. If you can lay out a specific example here I can try to get my head around it.
I thought about this when I was starting out. I think what happened was that after getting the new abilities to pare down the sources in all the various ways, the problem of “too many” genres kind of went away from the testing I was doing. But, maybe it could still be a useful feature. Only thing is: how do we chose what genres get tossed out? Seems like it would have to be quite arbitrary & then what if you throw out the most relevant one? Also, if you get the “right” ones, can there really be too many? So, I dunno…
I am very stoked though that the earlier issues seem to be resolved and overall it’s shaping up now. I was hoping to be able to use the plugin to do some actual work on my own library over the holidays coming up here & now it looks like that may actually be possible!
One thing I do still occasionally see is a genre drop. Its pretty rare and I don’t think the issue is with this plugin. The issue seems to be that in certain cases when an invalid response comes in from one of the webservice calls, the plugin may not get notified. It is supposed to get notified. I saw this before when working on the 1.2. I am still trying to get a clean log of this to open a ticket. Thing is - you only notice it when testing tracks that already have the full set of genres, so its a little disturbing. Like I said though its pretty rare. Something to keep an eye out for though.
I’d be an engineer of some sort, if I could have handled the math when I was younger. I could do the math part now, but I’m too old to change careers to Engineering.
Screenshot
The album identified as Q2920172 has only 1 genre associated with it; “folk music.” All works in the album are assigned this genre. Work 1 has an additional genre; “Pop Music.” If you search the title in Wikidata, there is a single released in 1984, by that name; “Im Nin’alu.” This release has the genre “Pop Music.” Searching for the titles of work 5, “Galbi,” is also a single released in 1984, but there is no genre listed. Works 2, 3, 4, and 6, 7 and 8 finds either no results, or results that are not musical.
Yeah, it’s not going to work from Wikidata, because the genres are not weighted, they are sorted by name. I thought it was weighted, until I looked more closely at the list of Genres for an artist.
EDIT: You can ignore this;
I am still experiencing some weirdness when I change options on the plugin, and refresh the album on the main screen. For example; My first lookup in Picard had everything turned on in the plugin, and it found everything. Turn off everything except “use Release group…” then refresh, and it returns only release group options. Turn everything back on, then refresh, and it ignores artist genres. I can’t get the artist genres to show up again, unless I select only the “use Artist genre” option. If no one else can replicate, I’ll assume that it’s just me, and figure it out from there. I’ve cleared cache and restarted Picard a couple of times. A full shutdown/boot of Windows fixed it the last time it happened.
I think the only other thing I could possibly ask for is a mechanism to make certain that the final list of genres has no duplicates.
EDIT add forgotten link.
EDIT EDIT I’m a bonehead. I was still in troubleshooting mode; I didn’t clear the check for "Use artist genres only if no release group genres exist. Everything works great.
Genre entities in wikidata can have parents and children.
See http://tinyurl.com/y7vkp8yr for a query showing the relationships between genres
You could potentially run something like that query and save it the first time the plugin runs.
To get rid of some of the more strange genre you could look up the genre in the list and do some processing.
When you find a genre you could look at all the parents and find the shortest path to a small list of base genres such as rock etc.
if the shortest path is more than 5 that genre is too specific and instead use the parent.
You could also do things such as if you have a genre and sub-genre in your list you probably only want the sub-genre.
This is helpful insight. Thank you. So, I was aware about the parent-child thing just from working on the code, but I was not so much aware of the overall wikidata structure - even just as it pertains to genres.
So right now, in the plugin, the genres are pulled in like so:
if 'relation_list' in response.metadata[0].artist[0].children:
for relation in response.metadata[0].artist[0].relation_list[0].relation:
if relation.type == 'wikidata' and 'target' in relation.children:
So it seems the plugin is currently traversing child relationships without bounds on the degree of separation, regard to genre vs sub-genre vs base genre, etc. Is there any sort of documentation, or is just all in the context of the general wikidata node structuring? Eg, any idea what “target” means in the child relationship & why we key on that vs something else?
I think you are mixing things up here. The .children in this code are the child nodes in the XML. @dns_server was talking about relationships between genres in the Wikidata model.
What the plugin does is just going over the Wikidata URL relationships and using them to query Wikidata.
That’s just the structure of the data as returned from MusicBrainz . For URL relationships the target attribute stores the URL. The code above just makes sure that attribute exists before accessing it.
I don’t know… my mom is 69 and last year she finished a 2-year long odyssey in re-training and getting state certified for her new career. Funny part is she didn’t have to work, she was already retired & just wanted to further shore up her nest egg, I guess. Thing about software engineering tho is its heavily fad oriented and as such its very discriminatory in favor of youth b/c the thinking is they know the new techs better. This even though the best developers are inevitably the older guys who’ve been through all the battles & are more likely to stay put. When I was an engineering manager, I would tend to hire the older ones myself (if I could find them) just for these reasons. Prolly not as big a problem in some other engineering fields tho. But I digress…
So I noticed you are referring to a “work” as like a track on the album. Do I understand you correctly & if so - is that right? I read the musicbrainz definition here: Work - MusicBrainz, but I still am not totally sure, lol. Also for this scenario - how do feel the plugin could do better?
You’re so right! I was barking up the wrong tree, quite literally. @dns_server disregard that. I will try to come back with some more questions on the appropriate tree later…
One thing I would like is to add all the identifiers in other databases to the tags.
So if we can add an option to write the wikidata id, wikipedia page, vaif id etc.
We could also follow the other plugins and also include _ tags to be used for scripting just in case they are useful.
Your mother is awesome. Most people her age just work at Walmart for a little extra spending money. I looked at the cost for the classes and time, and compared it to expected salary for my expected working time, and I don’t see a very good ROI. I’ve looked into working towards a degree one class at a time, and may end up doing that, at least for my own edification. I’ll be more serious once the little one is out of elementary school in a couple of years.
That’s what I was doing; Work=Track, and it is wrong!.? Picard shows a release ID for the “album,” and a track ID for the individual song." But I have two tracks that also have a Work ID assigned, and I’m more lost than before. I’m mangling the nomenclature, and I apologize.
I was trying to figure out how to explain what would be better, and I discovered that track 1, which has an extra genre, also has a “MusicBrainz Work Id” associated with it. Track 5, also has a “MusicBrainz Work Id,” but that ID does not have a genre. So, your plugin finds the “MusicBrainz Work Id” and adds the associated genre.
I thought it would be good to have the plugin only use genres associated with the Work ID for the Album, and ignore Work IDs from the individual Track. If that doesn’t make sense, my mind is fried, and I got nothing, so Happy Holiday, if you partake.
I second this. I like data, and tags available for scripting.
Cheers, mate… (said without the cool Aussie accent). I do and have been into a wee bit of spiked egg nog this very eve! Makes coding so much more fun, too! (J/K - not coding tonight.) But yeah there’s many considerations. I also have little ones and understand all that entails!
I see what you are saying. This could be doable - to put in a switch for which work types you want to allow. I will look into that. I think you’re right that a work can be a track or an album, or even groups of recordings… so its very broad.
This sounds interesting. I will look into this.
I think we are accumulating enough ideas to probably open up a separate feature expansion ticket.
I did find one bug in the current PR which is for the “blank” separator case. This is easy to fix, but it got me thinking again about these. I think that separators/delimiters are not actually needed for the ID3 v2.4 spec, as that spec allows for multi-valued fields (i believe it uses a NULL or 0x0 to delimit them), and I think Picard will use that if the metadata genre field is a list and that ID3v24 box is checked in the Tags options. So, it may be useful to key off of that and gray out the plugin’s delimiter setting if its on? I will dig into this a bit more…
4th commit to this PR now… This cleans up the options UI a bit, removes & handles the blank delimiter, disables the delimiter according to the Tags setting for ID3v24, and adds code to remove unneeded MB API calls for cases where a particular genre source is disabled - thereby speeding things up for those cases.
