Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: improve apple music fuzzy matching #3011

Draft
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

anshg1214
Copy link
Member

No description provided.

@anshg1214 anshg1214 requested a review from MonkeyDo October 26, 2024 16:59
@anshg1214 anshg1214 requested a review from MonkeyDo November 18, 2024 13:41
Copy link
Member

@MonkeyDo MonkeyDo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't done a lot of thorough testing of Apple Music overall, but this seems like an improvement.
However in some cases it appears to be too restrictive and ignoring decent matches.

I went back to this forum comment which has a good example.
The new system does not find an acceptable result to play this track (https://listenbrainz.org/player/?recording_mbids=26a654d4-c528-4d39-90a2-28958d30c828) whereas the existing system does.

I believe this is because by trying to match the album name we might ignore a track with the right name and artist but from a different album (in this case, expecting "Sobredosis de amor y salsa" and ignoring a match from "Greatest Hits" album).

I think the mechanism should prefer the correct album but still play a decent match (right title+artist) in case we don't get the perfect match with matching album name.

@MonkeyDo
Copy link
Member

To test the example above I made this gist to test the fuzzysort results using https://rawgit.com/farzher/fuzzysort/master/test/test.html

https://gist.github.com/MonkeyDo/f6d44f54c449ef39957a92dab4a3ba78

@MonkeyDo
Copy link
Member

I'm also seeing that the newest version 3.1.0 automatically handles accents and such (we are currently using 3.0.1) so we might be able to drop the use of deburr
https://github.com/farzher/fuzzysort?tab=readme-ov-file#v310

@MonkeyDo
Copy link
Member

The PR is definitely going to need some extra thorough testing.
It's not working as intended, here's another example:

https://test.listenbrainz.org/player/?recording_mbids=7db2b74f-6827-4ebf-b951-6576fcab570b
Should match the first result which is the correct song (https://music.apple.com/us/album/you-cant-say-kingston-doesnt-love-you/1631013553?i=1631013573), however it matches nothing, not even with the regexp.

In this case, I notice in particular that the apostrophe is different between the candidate matches and the apple search results, which is the only thing I could think of to explain why it can't find it, although I haven't dug deep.

Here's a gist with the candidate matches and the rest of the code, to be run in the console of https://rawgit.com/farzher/fuzzysort/master/test/test.html

https://gist.github.com/MonkeyDo/42576ec929463653cf72754455a37e47

@MonkeyDo
Copy link
Member

I thing is clear to me, the regexp hack we have to match a string will not work in a lot of cases (like the different apostrophe character I mentioned).
What are our other options? Some library?

@anshg1214 anshg1214 marked this pull request as draft November 26, 2024 06:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants