-
Notifications
You must be signed in to change notification settings - Fork 154
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
Ingesting the same song twice won't return results at lookup #22
Comments
This is a known issue. What happens is that when you ingest the same song twice, you end up with the same fingerprint codes ingested in each case, but you get different track IDs each time and therefore it considers them to be different tracks. When querying, the scores in the matching algorithm are identical or very similar and the server doesn't whether (a.) they represent the same track; or (b.) they represent different tracks. In the case (b.) there is no clear winner because the scores are so similar and so the server must reject the match to minimize the chances of returning a false positive. At this point in time the solution is to try to avoid ingesting the same track twice if possible. We are working on a more robust solution which will allow duplicate tracks to be handled. |
Has anyone tried ingesting the same mp3 file twice ?
When I ingest it once, if I query for a fragment of it, it returns the correct track id
When I ingest it again, and use the fp utility for querying, it won't return any results.
I tried to do some debugging on it and noticed that in return for the query, the script receives both track ids, but at some point near the end, it discards them both and returns no result.
Anyone knows what's going on?
The text was updated successfully, but these errors were encountered: