OnKey: オープンソースのMac用歌唱トレーナー、1回の再生で任意の曲のメロディーを学習

OnKeyとは何か、そしてShow HNスレッドが注目した理由

OnKeyは、Daniel Murrell氏が作成したMac用の無料のオープンソース歌唱トレーナーで、再生する曲のメロディーを学習し、それに対するライブ歌唱を採点します。カラオケ採点システムのピッチフィードバック部分を提供しますが、ライセンスされた音楽を一切扱いません。ユーザーの音楽アプリが曲を再生し、OnKeyがそれを聴きます。

プロジェクトはgithub.com/dsmurrell/onkeyにあり、ドキュメントと音声付きデモはsingonkey.appにあります。Show HNの投稿は169ポイント、72コメントに達しました。READMEのタグラインは「Saving shower singers from themselves since 2026.」です。

ピッチトレーナーやカラオケゲームと異なる中核的な主張は、曲が開発者によって事前にチャート化またはプログラムされる必要がないことです。OnKeyは、Mac上で1回のリスニングからメロディー自体を導き出します。

OnKeyが曲を学習する方法: ローカルで実行される4モデルパイプライン

OnKeyには曲データベースがありません。曲が終了すると、ユーザーのMac上でその曲のノートチャートを構築し、以降の再生で再利用します。

パイプラインは曲ごとに3つのステージがあり、ドキュメントでクレジットされているモデルを使用します。

ボーカル分離。 モデルがバックグラウンドミュージックからリードボーカルを分離します。クレジットされたコンポーネントの中にはUVRのMDX-Net Karaoke 2があります。
ピッチ追跡。 CREPEが分離されたボーカルの歌手のピッチを追跡します。
ノート転写。 GAMEノートモデルがそのピッチトラックをノートに変換し、音節ごとに1小節を生成します。

OnKeyはまた、CREPE、GAME、UVRのMDX-Net Karaoke 2と並んでwav2vec 2.0もクレジットしています。

最初の再生では、歌詞のみが表示されます。曲が終了すると学習されます。以降の再生では、ノートバーがプレイヘッドに向かってスクロールし、ライブピッチがその上に描画され、ノートに合っている場所は緑色で表示されます。OnKeyは、保存されたオフセットではなく、音楽自体から曲内の位置を見つけ、ライブで声を追跡します。

採点は、READMEに記載されている2つの点で意図的に寛容です: 1オクターブ下で歌うことはカウントされ、少し遅れることは罰せられません。

要件とインストール

OnKeyには、macOS 14.2以降を実行するApple Silicon Mac（M1以降）が必要です。Intel Mac用のビルドはなく、WindowsやLinux用のビルドもありません。

インストール方法: 最新のGitHubリリースからOnKey.dmgをダウンロードし、開いて、OnKeyをApplicationsにドラッグします。

セットアップでは、2つの権限と1つの設定が求められます。

マイクアクセス、歌手を聞くため。
システムオーディオ録音、音楽アプリを聞くため。
OnKeyがSpotifyとApple Musicをフォローしてもよいかどうか。 Listen onlyを選択すると、音だけで曲を追跡します。

入門ガイドとFAQはsingonkey.app/docsに公開されています。

プライバシー: Macに残るものと、正確に何が外部に出るか

OnKeyは、聴いた音楽を保存しません。再生中に音をメモリ内で分析します。録音と学習した曲はMacに残ります。READMEには1つの注意点が記載されています: スピーカーで歌ったテイクには音楽が一部含まれることがありますが、ヘッドフォンのテイクには含まれません。アカウント、分析、クラッシュレポートはありません。

4つのカテゴリの送信リクエストが文書化されています。

Shazam（Apple）: 音楽アプリの音の短い署名（オーディオではなく、マイクは決して含まれない）。音楽アプリが再生中の曲を報告しない場合に、OnKeyが学習していない曲に名前を付けるために使用されます。
LRCLIB: 曲のアーティスト、タイトル、アルバム、長さ。歌詞を取得するため。
iTunes Search and Lookup（Apple）: アーティストとタイトル、またはShazamが返したID。カバー曲と曲の長さのため。カバー画像はSpotify、Apple、またはYouTubeの画像ホストから取得されます。
GitHub: 起動1分後と1日1回の新しいバージョンのチェック、およびアップデートのダウンロード。

設定には、Shazamのスイッチ、歌詞のスイッチ、アップデートチェックのスイッチがあります。リポジトリファイルscripts/release-hosts.txtには、リリースが接続するすべてのWebアドレスがリストされています。

Hacker Newsのコメンテーターstevageはこれをプロジェクトの際立った品質として挙げました:

このレベルの透明性には本当に感謝しています。これが標準になればいいのに。

フェアユース設計: OnKeyが音楽ライセンスを回避する方法

OnKeyは音楽を提供、ストリーミング、ダウンロードしません。この単一の制約が、残りの法的設計を可能にし、READMEにはユーザーが守るべきルールが記載されています。

学習した転写を自分だけに留めておく。 各曲のメロディーの転写は個人練習用であり、共有または公開すべきではありません。
テイクを投稿するには内蔵のShare機能を使用する。 Shareは、音楽なしの声とピッチラインの短いビデオを生成し、歌手はInstagramの音楽ライブラリ（その使用のためにライセンスされている）から曲を追加できます。ヘッドフォンテイクが推奨されます。音楽が再生されている画面録画を投稿しないでください。
バーやイベントにはライセンスされたカラオケサービスを使用する。 OnKeyの歌詞は無料のコミュニティデータベースから来ています。
音楽を保存するようにOnKeyを変更しない。

権利者はhello@singonkey.appに連絡でき、LEGAL.mdが詳細をカバーしています。

これは、スレッド内の他のビルダーが遭遇した問題への直接的な対応です。コメンテーターfourneauは、まさにこの理由で停滞したカラオケ採点プロジェクトを説明しました:

私のカラオケプロジェクトは、音楽の権利を確保する余裕がなく、オーディオを得るための良い法的解決策がないように思えたため、行き詰まりました。

Fourneauはまた、DAMとJoySoundのカラオケシステムがすでに2つのことを行う採点モードを搭載していると指摘しました: オンチューで歌うのを助け、他の歌手と匿名でランク付けします。

ソースからのビルドとリリースの検証

OnKeyはMITライセンスであり、READMEにはメンテナのバイナリを信頼したくない人のための完全なソースビルドが文書化されています。Xcodeコマンドラインツール、Rust、Node、Python 3を備えたApple Silicon Macが必要です:

git clone https://github.com/dsmurrell/onkey && cd onkey npm install && npm --prefix ui install python3 -m venv .venv && .venv/bin/pip install -r scripts/requirements-models.txt PYTHON=.venv/bin/python scripts/fetch-models.sh npx tauri build

fetch-models.shステップはモデルをダウンロードし、SHA-256でチェックします。自己ビルドコピーでは1つの機能が失われます: 新しい曲に名前を付けるためにShazamに尋ねることができません。これはメンテナのApple署名が必要だからです。SpotifyとApple Musicは再生中の曲を自分で報告するため、これはYouTube再生とListen onlyモードにのみ影響します。

公式リリースはMurrellのApple Developer IDで署名され、Appleによって公証されています。spctl -a -vv /Applications/OnKey.appは、インストールされたアプリに誰が署名したかを示します。

ライセンスの商標条件について: 変更されたバージョンはOnKeyと呼んだり、そのアイコンを使用したりできません。また、コードを基に構築する場合は、リポジトリにリンクするクレジットが歓迎されます。CONTRIBUTING.mdにはテストとリリースのチェックサムを確認する方法が文書化されており、THIRD_PARTY_NOTICES.mdには完全な通知とライセンステキストが含まれています。

コメンテーターが賞賛した点

スレッドの熱意は3つのことに集中していました: アイデア、曲のチャート化が不要なこと、プライバシー文書の透明性です。

コメンテーターwnissenは、曲が開発者のサポートを必要としないことを気に入りました:

なんて楽しいアイデアでしょう！曲が開発者によってプログラムされる必要がないのが大好きです。

wnissenはまた、これをリズムゲームのRock Band時代と比較し、練習へのインセンティブを与えたが必ずしも歌唱力を向上させなかったと述べ、相対ピッチ知覚をテストするためのYale Music Labのピッチ知覚クイズをthemusiclab.org/quizzes/tdで指摘しました。

他の反応は実用的な用途を持つ人々から来ました: infossgmllcは合唱団の娘がチェックアウトすると言い、abktyaは一日中歌う妻と娘に適していると言い、nopurposeは外部アプリがSafariタブのYouTubeと対話できることに驚きを表明しました。

コメンテーターbita_nidirは、Linuxとバイオリンサポートを含む同じプロジェクトを20年間個人的なTODOリストに持っており、コードに存在するApple Siliconの制約について尋ね、プルリクエストを送ることを申し出ました。

スレッドからの批判と未解決の質問

リソース使用とTauriスタック

最も鋭い技術的批判はコメンテーターviraptorから来ました。彼はアプリが完全にバイブスコードされていると主張し、ネイティブのSwiftアプリがより小さくスムーズである可能性があるのに、なぜTauriを介してWebviewを使用するのか疑問視しました:

人々は物事を書きやすく、維持しやすくするためにelectron/tauri/whateverを使用しましたが、とにかくバイブスしているだけなら、リソースを尊重することに戻れませんか？

コメンテーターは、アイデアが好きで、過去に同様のことをする有料アプリを使用したことがあると付け加えました。これは実装選択への批判であり、コードがどのように書かれたかについての検証された主張ではありません。

プラットフォームの制限: Apple Siliconのみ

OnKeyにはM1以降のMacが必要です。コメンテーターmkesperはLinux版を求め、hungryhobbitはより鋭く同じ点を指摘し、MacとLinuxは現在十分に似ているのでポートを検討する価値があると述べました。

コメンテーターbusssardは、Macのみの制約を回避する可能な道を提供しました: om-intelligence.chでホストされている彼自身のボーカル記譜プロジェクトで、曲を歌える記譜に変換し、彼の枠組みでは統合できる可能性があります。

言語カバレッジ

コメンテーターrobofanaticは、OnKeyが任意の言語の曲で動作するか、英語のみか尋ねました。READMEは言語カバレッジに直接対処していません。そのパイプラインは、歌詞ではなく分離されたボーカルオーディオとCREPEピッチ追跡で動作し、歌詞自体はLRCLIBから来ています。

ピッチ、音程、そして「オフキー」の意味

コメンテーターTZubiriは、相対音程が絶対周波数よりも重要だと主張しました:

音程を正しくすることがより重要だと思います。任意の開始周波数を取ることができ、音程が正しければ、周波数自体が完璧でなくても正しく聞こえます。一方、このような周波数ベースのアプローチを使用すると、相対的な基準ではなく絶対的な基準のフレームを持つことになります。

OnKeyは、1オクターブ下で歌うことを正しいとカウントすることで部分的にこれを考慮していますが、その表示は、抽象的に音程の正確さを採点するのではなく、学習されたノート位置とあなたのピッチを比較します。

コメンテーターcriddellは用語の問題を提起しました: 彼にとって、「オフキー」は、ターゲットノートに対してシャープまたはフラットであることではなく、曲のキー外のノートを歌うことを示唆しています。彼は、YouTubeの一部のトラックが完全にシャープに見えるのは、おそらくミキシングまたはマスタリング中にスピードアップされたためであり、それらがオフキーとしてカウントされるかどうか尋ねました。

教育学: 視覚フィードバックはリスニングを置き換えるか？

リズム学生を教えているコメンテーターsligbadは、視覚フィードバックへの依存について警告しました:

これらの種類のツールは役立つと思いますが、視覚的なメトロノームへの依存を断ち切る必要があるリズム学生の数は大変です。苦労の一部は、自分自身に本当に耳を傾け、自分の間違いに気づく方法を学ぶことです。

彼らは、ビルダーとユーザーの両方を対象とした警告を追加しました: 練習ツールの作成と維持に費やす時間が、最も重要なことであるより多くの練習から逸れないようにしてください。

コメンテーターenzoaguadoは、歌うことは正しいノートを打つことよりもはるかに多いという関連する範囲の議論をしました。呼吸管理、難しい曲での怪我を避けるためのボーカルテクニック、ベルティング、トワング、ヘッドボイス、チェストボイス、ボーカルフライなどのテクニック、およびプロソディとリズムトレーニングを、ピッチスコアラーがカバーしない意欲的な歌手が必要とするスキルとしてリストしました。彼らの評決は、このようなツールは良い入り口であり、歌うことが何を含むかの味を提供するが、これらの他の側面をカバーするか、少なくとも名前を挙げることが役立つだろうというものでした。

機能リクエストと未回答の質問

ゲーミフィケーション。 コメンテーターpheraphは、おそらくそれを楽しむ娘のために、難易度レベルと組み合わせたスコアまたは星評価を提案しました。OnKeyはすでにスコアと行ごとのレポートを生成しますが、コメントはその上に進行レイヤーを求めています。
誤ってラベル付けされたセクションの除外。 コメンテーターhensenjuangは、ボーカル分離がリードメロディーの代わりにバックボーカルを拾った場合、セクションを採点から除外できるかどうか尋ねました。
楽器サポート。 コメンテーターjulianromanoは、OnKeyを楽器に拡張できるかどうか尋ねました。
ピッチ検出の詳細。 コメンテーターHummingBirdGifは、ピッチ検出がどのように実装されているか尋ねました。READMEは、ピッチ追跡にCREPE、ノートバーにGAMEノートモデルを使用して、コンポーネントレベルでこれに答えます。

スレッドが浮き彫りにしたより広い議論

アプリ自体を超えて、議論には2つのテーマが流れていました。

第一に、AI支援アプリ構築の賛否。プログラミングのバックグラウンドと機械学習の博士号を持つコメンテーターdrltaidevは、Claude Codeができることに感銘を受け、自分ではほとんどコードを書かなくなったと述べましたが、 downsideも指摘しました: 誰もがアイデアの自分のバージョンを構築できるようになり、生き残るのは必ずしも最良のバージョンではないということです。彼らはまた、歌うことがピッチよりもはるかに多くを含むという範囲の批判に同意しました。

第二に、ソフトウェアがネットワーク上で送信するものを正確に述べることの価値。スレッドで最もアップボートされた反応は、機能リクエストではなく、OnKeyの4つの送信リクエストタイプの開示への感謝であり、それが出荷されるソフトウェアの標準であればいいのにという願いでした。