New hook for custom import matching logic

[jtpavlock]

@ali-ramadhan continuing our discussion here:

I think we also need it to improve matching for other data sources (e.g. Discogs), although the current matching logic isn't too MusicBrainz-focused. I've been getting great matches with Discogs already. This new hook can help match on e.g. composer but I think the MusicBrainz or Discogs plugin itself needs to pull the composer data first? Curious what your thoughts are on how to proceed.

So how I imagine it currently:
Plugins can use the hook to return a dictionary of attributes to weights, similar to MATCH_TRACK_FIELD_WEIGHTS, then, get_match_value() would call this hook, compiling the different weights, and then determine the ultimate match values. The matching logic happens after the tracks/albums have already imported their metadata, so it shouldn't be an issue of ordering around that. Also, match.py should implement the hook too and just add the default field_weights in its own hook implementation, similar to how track.py both defines and implements read_custom_tags for reading default tags.

Let me know if that makes sense or if you have any other questions.

[ali-ramadhan]

I think I follow but I have a few questions in mind.

Plugins can use the hook to return a dictionary of attributes to weights, similar to MATCH_TRACK_FIELD_WEIGHTS

It will be great if plugins can dictate MATCH_TRACK_FIELD_WEIGHTS. Would plugins also be able to dictate MATCH_ALBUM_FIELD_WEIGHTS?

then, get_match_value() would call this hook, compiling the different weights, and then determine the ultimate match values.

Would plugins be able to determine how match values are computed? Or would plugins just be able to determine the weights?

The application I have in mind is: when matching on track duration I think the penalty should be zero if the track durations match to within 5% for example, then the penalty should linearly increase with the duration mismatch. Would a plugin be able to implement this.

Maybe this is a higher-level design question. MusicBrainz and Discogs plugins may want to use different weights and use different names for fields, but they shouldn't both implement the same duration matching logic. So perhaps duration matching logic should just be in Moe? Or implemented via a separate hook that a MusicBrainz or Discogs plugin can override if desired?

[ali-ramadhan]

Yeah I think I'm also leaning towards option 2. At least for now. We could see what plugins people come up with in the future and adjust. But yeah maybe for the short-term I'm thinking of how to match on track duration.

Are you thinking the new hook is even necessary with the approach of option 2? We can always revisit if we decide to not implement a hook right now.

[jtpavlock]

If you're just after the track duration matching, I don't think a new hook is necessary. Like you said we can always revisit adding a new hook later when another usecase pops up.

[ali-ramadhan]

Agreed! For the next step I can open a PR to add duration as a MetaTrack property and add some logic for matching track duration. Then I can open a PR for moe_musicbrainz to populate MetaTrack.duration?

[jtpavlock]

Yeah, that sounds good to me. Sorry it took a bit more discussion to get at what you were originally trying to do.

[ali-ramadhan]

No worries, it's great to be able to discuss this! I have a PR ready to open now.