NotShazam - Go言語で再構成したShazamアルゴリズム
(github.com/cgzirim)- SeekTuneは、Shazamの楽曲認識アルゴリズムを実装したプロジェクトで、SpotifyとYouTube APIを統合して楽曲の検索とダウンロードを可能にする
- 実行にはGolang、FFmpeg、NPM、YT-DLPが必要で、Docker Composeまたはネイティブ環境でサーバーとクライアントを起動できる
- Spotify連携は、開発者アプリのClient IDとClient Secretを
server/.envに設定する方式で、アプリが必要なアクセストークンを自動取得してキャッシュする - デフォルトのデータベースはSQLiteで、環境変数に
DB_TYPE=mongoを指定するとMongoDBを利用でき、ユーザー名・パスワードがない場合はmongodb://localhost:27017に接続する - CLIはSpotifyリンクのダウンロード、ローカル音声の保存、録音ファイルのマッチング、指紋と楽曲の削除をサポートし、YouTube IDのない保存項目はフロントエンドでマッチ結果として表示されない
プロジェクト概要
- SeekTuneは、Shazamの楽曲認識アルゴリズムを実装したアプリケーション
- 実装はREADMEのリソースセクションにある資料をもとにしている
- SpotifyとYouTube APIを統合して楽曲を見つけてダウンロードできる
- デモと制作過程のリンクが提供されている
インストールと実行方法
-
必要なツールはGolang、FFmpeg、NPM、YT-DLP
-
リポジトリのクローンコマンドは次のとおり
git clone https://github.com/cgzirim/seek-tune.git cd seek-tune -
Spotify API設定
- Spotifyアプリを作成し、Client IDとClient Secretを取得する必要がある
serverディレクトリに.envファイルを作成し、次の値を設定する
SPOTIFY_CLIENT_ID=your-client-id SPOTIFY_CLIENT_SECRET=your-client-secret- アプリは必要なアクセストークンを自動的に取得してキャッシュする
-
Dockerでの実行
- DockerとDocker Composeが必要
- ビルドと実行は次のコマンドで行う
docker-compose up --build- 実行後、アプリには
http://localhost:8080でアクセスできる - 停止には次のコマンドを使用する
docker-compose down -
ネイティブ実行
- バックエンド依存関係のインストール
cd server go get ./...- クライアント依存関係のインストール
cd client npm install
CLIの使い方
- クライアントアプリは
clientディレクトリで実行するnpm start - バックエンドは別ターミナルで実行する
cd server go run *.go serve [-proto <http|https> (default: http)] [-port <port number> (default: 5000)] - Spotifyリンクから楽曲をダウンロードできる
go run *.go download <https://open.spotify.com/.../...>;- Spotifyモバイルアプリでコピーしたリンクは動作しない
- デスクトップまたはWebアプリでコピーしたリンクを使用できる
- ローカルの楽曲ファイルやディレクトリをデータベースに保存でき、すべての音声形式をサポートする
go run *.go save [-f|--force] <path_to_song_file_or_dir_of_songs>-fまたは--forceは、YouTube IDが見つからなくても楽曲を保存する- YouTube IDがないと、フロントエンドはマッチ結果を表示しない
- 楽曲や録音ファイルのマッチを検索できる
go run *.go find <path-to-wav-file> - 指紋と楽曲の削除をサポートする
go run *.go erase go run *.go erase db go run *.go erase all- デフォルトではデータベースのみ削除する
erase allはデータベースと楽曲ファイルを一緒に削除する
*.goが動作しない場合は./...を使用できる
出力例
- ダウンロード例では、Spotifyのトラック情報を取得した後、トラックをダウンロードして指紋を保存する
$ go run *.go download https://open.spotify.com/track/4pqwGuGu34g8KtfN8LDGZm/… Getting track info... Now, downloading track... Fingerprints saved in MongoDB successfully 'Voilà' by 'André Rieu' was downloaded Total tracks downloaded: 1 - マッチング例では、
Voilà - André Rieu.wavに対して上位20件のマッチと最終予測を出力する- 最上位の結果は
Voilà by André Rieuで、スコアは5390686.00 - 検索時間は
856.386557msと表示される - 最終予測も
Voilà by André Rieuと表示される
- 最上位の結果は
データベースの選択
- デフォルトのデータベースはSQLite
- MongoDBを使うには、MongoDBをインストールして接続用環境変数を設定する
DB_TYPE: MongoDBを使うため"mongo"に設定DB_USER: MongoDBユーザー名DB_PASS: MongoDBパスワードDB_NAME: 使用するMongoDBデータベース名DB_HOST: MongoDBサーバーのホスト名またはIPアドレスDB_PORT: MongoDBサーバーのポート番号
- データベース接続URIは環境変数から構成される
DB_USERまたはDB_PASSがない場合、デフォルトでmongodb://localhost:27017に接続する
参考資料とライセンス
- How does Shazam work - Coding Geek: メインリソース
- Song recognition using audio fingerprinting
- How does Shazam work - Toptal
- Creating Shazam in Java
- プロジェクトはMIT Licenseで配布されている
1件のコメント
Hacker News のコメント
Shazam 技術の一部はスタンフォード大学キャンパスの CCRMA から生まれたもので、ここは初期のコンピューター史とも深く結びついた特別な場所だ。
初期のコンピューター技術の応用に、オーディオ関連のものがやけに多いのは興味深い。John Bardeen のミュージックボックス、トランジスタ初の商用応用だった補聴器、Palo Alto の HP ガレージで作られていたオーディオ発振器、iPod から続く iPhone、アナログ電話回線を運んでいた銅線の上に築かれたインターネット、Bell Labs まで、例は次々に続く。
もしかすると人間は、まず kHz 帯域の扱い方を覚えてから MHz/GHz 帯域へ進む、という仮説もかなり魅力的に聞こえる。
オーディオ信号は比較的簡単に電気信号へ変換できるが、グラフィックスは画面に表示するところからずっと複雑だ。電気信号を音波に変えるスピーカーも、核となる構造だけ見れば非常に単純な装置だ。
それにオーディオは人に強い印象を与えるので、電子工学やコンピューターの力を見せるなら、自分でもオーディオを選んだと思う。
これが Shazam の本当の再現なら、少なくとも 2025年3月までは Apple の特許下にある可能性がある: https://patents.google.com/patent/US7627477
その特許は米国で 2004-10-21 に出願されている。法律の専門家ではないが、米国ではこの特許に不利な根拠になり得るように見える。
おそらく元記事にある Google Drive の PDF キャプチャがその資料だったのだと思う。
ただしこの方式が機能するには、地球上のあらゆる音楽の署名が必要になる ;)
Shazam 共同創業者の Avery Wang が DAFx17 で行った発表が良かった。
アルゴリズムの理論的背景を少し扱い、背景ノイズのような実際の問題も見ている: https://www.youtube.com/watch?v=YVTnj3OIhwI
最近 Shazam の精度が落ちたように思うし、むしろ SoundHound のほうが良い結果を返す。
Shazam ではアジア圏の音楽伝統に属する結果が多く出るが、それ自体は良いとして、問題は曲が間違っていることだ。選択対象の音楽範囲を広げたのならアルゴリズムも改善すべきだろうし、今はハッシュテーブルの衝突が増えている感じがする。
参考: https://github.com/cgzirim/not-shazam/…
結論としては、BeatFind と Shazam が最も多くの曲を知っていたが、互いに補完的な面もあり、すべてのサービスがそれぞれ自分だけが認識した曲を少なくとも1曲は持っていた。
テストには複数のジャンルと知名度のレベルの曲を混ぜたが、サンプル数がもっと大きければなお良かったと思う。また、人の話し声のようなノイズや、壁越しに聞こえるフィルタリングされた音楽はテストしていない。
面白いことに “Night Driver” は “1 Shazams” と表示されたので、おそらく自分が最初に Shazam した人だったようで、“THEY'RE TAKING THE HOBBITS TO ISENGARD!” はホビットをどこへ連れていくのかは皆知っているのに、サービスはどれも認識できなかった。
プロジェクトは書いたり直したりしやすそうには見えるが、個人的にはまだ公開するには少し早いと思う
実行方法の案内が不正確に見えるし、MongoDB が必要なのに接続・使い方の説明が抜けている。できれば DB を差し替え可能にし、sqlite のような負担の少ない選択肢を提供したほうがよい
MongoDB を置き換えられないなら、Dockerfile と docker composeを用意して、簡単に実行・テストできるようにするべき。クライアント側の
npm installで重大な脆弱性が 8 件出るのだが、実際には問題ではない可能性があるとしても、テストを続けるのをためらってしまう特許や著作権を気にしないとしても、名前は変えたほうがよい。GitHub 自体が米国にあるので、DMCA が来ればプロジェクトを下げられる可能性がある
最後に、WAV ファイルから曲を追加する機能もあるとよい。テストしたい音声がすべて Spotify や YouTube にあるわけではない
落ち込ませるつもりではなく、こうした細かな仕上げが足りないと、人々はプロジェクトを無視したり低く評価したりしがちだということ。時間があれば PR を送るかもしれないし、音楽以外の領域で音声マッチングを実験したいので、このプロジェクトがいちばん修正しやすそうに見える
設定ガイドを改善し、柔軟性のためにファイルベースの DB を追加する案と、
npmの脆弱性解消を優先するつもり。WAV ファイルを直接フィンガープリント化する機能も良いアイデアなので、優先的に見るプロジェクト名の法的リスクも理解しており、変更する予定。良い名前の提案があれば受け付けたい
リポジトリはまだ詳しく見ていないが、検索対象になるデータがどこから来るのかが気になる
ライブラリをロードするのか、それともどこかで確保した大規模ライブラリを検索するのかが気になる
こういうものをぜひ作ってみたいというバケットリストがあったので、本当に素晴らしい
フィンガープリントをコミュニティベースで共有する方法があると、かなり良さそう
記憶では BitTorrent は分散ハッシュテーブルを使うが、ハッシュはコンテンツ全体に基づくので、出典表記がめちゃくちゃな派生作品のオリジナルを探す用途にはあまり役に立たない
画像のオリジナル探しには Tineye がたまに使える
Spotify の曲を入れるなら、結果も Spotify の曲として出すほうが自然ではないか？
Google のスマートフォンには内蔵の音楽認識機能があり、この分野で最もよく実装されているものだと聞いた
どのようなアプローチを使っているのか知っている人がいるか気になる。別件だが、SoundHound は Shazam より優れているといつも感じていた
そのためスマートフォンが常にアクティブである必要はなく、その後は何らかの既存の検出アルゴリズムを使えばよかったのだと思う。自分にはその超低消費電力の段階が魔法のように感じられたが、詳細を読んだことはない