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

[Feature Request] Integrate Shazam API #42

Open
Julian-1-2-3-4-5 opened this issue Dec 29, 2023 · 4 comments
Open

[Feature Request] Integrate Shazam API #42

Julian-1-2-3-4-5 opened this issue Dec 29, 2023 · 4 comments

Comments

@Julian-1-2-3-4-5
Copy link

I don't know much about how this app works, but how hard would it be to integrate the shazam api as well, which audire uses?
It would combine the ease of use of a free api and in my experience sometimes better results with the way more functions that this app provides and the better design.

@aleksey-saenko
Copy link
Owner

Hello. I like the idea of adding support for different recognition services and giving the user the ability to choose.

Shazam has an interesting client-side implementation that creates special fingerprint for each audio recording right on the user's device. This solution has several advantages over others, but it requires implementation, as you need to generate these fingerprints.

There are two ways to do this. The first is official and legal. Apple, as the developer of Shazam, provides a library (a ready app module) that developers can integrate into their app to easily and reliably perform recognition. It even handles network interaction. However, there are a couple of problems here. Firstly, the source code of this library is closed (Audile claims to be open source). Secondly, when using this library, you need to provide the Apple developer's token with each request. Participating in the Apple Developer Program costs $99 per year, so, Shazam is not free service.

The second way to use Shazam API is reverse engineering, trying to do it yourself what the official library does. This method is used by AudiRe, and its code, in turn, is based on SongRec. The algorithm replication for creating fingerprints looks good and could be used since it's published under the GNU license. Nevertheless, I am bothered by how the network interaction looks. In general, there is a question of whether this approach could be considered an unfair use of the service.

This is the reason why Shazam was not originally chosen as the API. In the future, if this application continues to evolve towards adding additional services, we can return to this issue and consider the legality of the second way in detail. Adapting the app to support several services with the possibility of flexible switching is a lot of work. If someone wants to take on these issues and work on the integration of Shazam, then Audile is open to code contributions.

@NikunjKhangwal
Copy link

Since the app matured quite a lot and got ACRcloud support now, do you have any thoughts on this?

@aleksey-saenko
Copy link
Owner

@NikunjKhangwal
After integrating ACRCloud, it really became a bit easier to add new providers. For an experiment, I even made a small draft with Shazam using SongRec developments, and overall it works. It remains only to unify format for audio recordings so that different providers can be used for saved recordings or even use them in chains or in parallel in the main session.

In general, I would say that now this is more of a legal issue rather than a technical one. There are 2 problems:

1 - Using (publishing) a compatible algorithm for fingerprinting. There are already several ready-made implementations. But Shazam doesn't approve of this at all: part1, part2.
The author of SongRec, for example, relies on some law in France marin-m/SongRec#12.
This legal aspect seems complicated to me.

2 - Using Shazam remote API (their fingerprint database). The problem is that all unofficial implementations I've seen rely on undocumented endpoint and use each time a random user-agent and geolocation, I guess, to avoid client blocking. Also, it's likely that this endpoint will be disabled at some moment, recently it stopped providing song lyrics. Overall, I think Shazam would not approve such use of the service.

So I'm not ready to implement Shazam support yet. If anyone has any thoughts on this, I'm ready to discuss.

@NikunjKhangwal
Copy link

Hmm, well this will always be a problem. Api is probably not the biggest issue because community can always come up with new things. But i understand no one wants to get into legal trouble and give up on such hard worked project.

Shazam integration would've been great because then the app could've became a viable FOSS alternative to Shazam which is free. The two services provided are both paid or limited. But at the same time the reasons mentioned are legitimate.

I guess unless someone can come up something, the idea of shazam has to scraped altogether sadly.

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

No branches or pull requests

3 participants