aleksey-saenko / MusicRecognizer

An Android application for music recognition that uses AudD and ACRCloud services to perform song identification.
GNU General Public License v3.0
513 stars 14 forks source link

[Feature Request] Integrate Shazam API #42

Open Julian-1-2-3-4-5 opened 10 months ago

Julian-1-2-3-4-5 commented 10 months ago

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 commented 10 months ago

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 commented 2 months ago

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

aleksey-saenko commented 2 months ago

@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 https://github.com/marin-m/SongRec/issues/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 commented 2 months ago

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.

haarp commented 4 days ago

I too would love to see Shazam integration at some point, even if it means using unofficial APIs. Their database is simply much larger and useful than most others.

Alternatively, there's also SoundCloud. They have an app and an API, although I know nothing of their licensing terms or how one would interact with the API.