Mapping of remixers from own tags

[Machine]

@brian : First of all let me say that if there was no “Roon Experience” everything would be much easier so you might re-think…

…haha, ok forget that

Let’s get back serious. What I want to say with this is that your plans have really demanding and tricky challenges.

So here are my questions, thoughts, answers on this

Part of what we are doing to make Roon more friendly to people with groomed collections is introducing a special kind of edit called “prefer local metadata”, which effectively flips the bottom two (local + provider) layers. This will be a field-level operation, but we’ll make batch edit mechanism so you can multi-select the whole library and check off a list of fields for which you would prefer to trust local data if you want to do it across the board.

This sounds really great.
So will we be able to select the tag-names we used and map them to the corresponding fields that you open for using local metadata? I think this will be necessary as people are using custom-tags, if there were just certain tag names mapped hardcoded this might get problematic.

As you can imagine there are a ton of little exceptions. For fields that contain release specific information (upc, asin, country, catalog#, label), we are planning to start trusting local tags over our own sources by default, since when that (statistically rare) data is present, it seems to be cleaner and more reliable than what our automatic systems can discern.

I agree with you I think no one will use such tags with garbage in it.
Same question as for the previous section applies of course. I know of people using catalog#, catalogno, catalognumber etc. for instance.

Track credits are also a special case. We don’t choose the whole local/remote list as a unit (this is almost what we were doing up until this week’s build, except we were considering negative information from our providers to still count as “having data” if the track was identified by one of them–no good).

Yes this was really not the best way of handling it but from what I have seen until now for track artists and composers this is way better. Others also confirmed that I read.

We also don’t merge the track credits list entry-by-entry because misspellings (or near misses) create noisy duplicates everywhere. We tried this kind of merging in an earlier version of the product, and it was detrimental to the overall experience.

I see the difficulty here. And you really have the problem of misspellings problem from both sides, from the user and from the metadata-providers at least regarding track names. Didn’t check that for composers or artists until now.

Also, credits from tags are by nature “crippled” since they are strings, not identifiers, so we can’t unambiguously match them up in cases where two people with the same name exist in your library, so when we can get data with proper identifiers, we prefer to use it.

So the way we merge track credits from local/provider data is on a category-by-category basis:

If your local data provides composers, and our provider doesn’t, we use local composers, else provider.If your local data provides main performers, and our provider doesn’t, we use local main performers, else provider.

I really see a problem child here. It’s called artist name variation. Especially in electronic music a lot of artists, and so also remixers, use artist name variations. In order to match that up correctly, also from a more general point of view it really depends on what the metadata-provider delivers and if this is right. In Discogs API for instance you have the possibility to somehow dissolve artist name variations.
That means if in the track credits the artist is CL2 you get back Chris Liebing instead. You can do that but this is not what is written as track artist on the album then. So if you want to mirror the credits of your album you have to use the artist name variations. Will these be handled as own artists then?

As far as I understood this process of checking against the provider and deciding is only valid if we don’t use the future “prefer local metadata” functionality, right? Will there ever be a match to your ID’d artists than if I prefer to use my artist tags??

Currently, we classify remixing-related roles (when data comes to us from our providers) in the production category. The problem is–with our default merging behavior, you would only see the remix guy in cases where there are no other production credits coming from our provider. It seems strange to lump REMIXED BY in with “Script Supervisor” or “Cover Art”.

What category do you think REMIXED BY goes in?

I can see an argument for categorizing them as composer or performer. Production seems wrong to me. Maybe there’s a case for making a new category solely for remixers…but the bar is pretty high for doing that, and I’m not completely convinced (yet) that remixers are “special enough” to justify dedicated handling everywhere.

I completely agree with you here that it should not be in the “Production” category, especially given your examples which are real production tasks/jobs.
I also see your problem creating a new category, special code has to be added everywhere you work with the categories.
So this is really a good question. Regarding the composer and performer categories. Are there any other roles in there other than “Composer” or “Performer”? And you just wrote in another post when they’re displayed and when not

Wrong playing artist displayed from DJ-Mix/compilation

Composer tags are there in all of them and if you look in the track credits they are there in all the tracks. How is it decided to display or not? It depends on an internal metric of interestingness and some contextual information from the album genres (Classical/Jazz/Vocal albums are more likely to show composer credits than other genres). We use interestingness metrics to govern many aspects of composer and work display because if we showed them in every situation where we have data (keep …

because I think a remixer should always be displayed if it is a remix and the information is there. Sure one can write this info also in the trackname, but then there will be no way at all to have a roon-like experience with that.