audio2score-mcp

録音済みのオーディオファイルを編集可能な楽譜に変換します: audio → MIDI → MusicXML。

MusicXML をターゲットにするのは、それが「音楽記譜のSVG」だからです — オープンでテキストベースの形式であり、それを生成したパイプラインを所有していなくても、あらゆる記譜アプリ（MuseScore、Sibelius、Guitar Pro、Finale、Dorico）で開いて編集し、再エクスポートできます。このプロジェクトが生成するのは .mid ファイルと .musicxml ファイルだけです。それ以外（PDF、オーディオ、タブ譜）へのオープン・編集・エクスポートは、お好きな記譜アプリで手動で行います — このプロジェクトが意図的にその部分をラップしない理由は、下記の「連携するフォーマット」を参照してください。

実行方法は2つあります: 素のCLIスクリプトとして実行するか、同じステップを Claude が呼び出せるツールとして公開する MCP サーバーとして実行するかです。

内容一覧

• transcribe.py — オーディオファイル → MIDI、Spotifyの basic-pitch を使用

• to_score.py — MIDIファイル → MusicXML、music21 を使用

• score_to_notes.py — スコアファイル（MIDI、MusicXML、または music21 が読めるもの）→ daw-mcp の batch_set_notes 形式のJSONノート配列

• mcp_server.py — 上記3つをツール（transcribe_audio、midi_to_score、score_to_notes）としてラップするMCPサーバー

各ステップは、ディスク上に存在する独立した成果物であり、隠れた中間生成物ではありません。MIDIと記譜の間に段差があるのは意図的です: 自動トランスクリプションはロッシー（情報を損なう）なので、生のMIDIはスコアになる前に一度目を通す（または手動で修正する）価値があります。

score_to_notes.py は意図的にフォーマット非依存であり、MIDI専用ではありません — music21.converter.parse() はMIDIとMusicXMLをまったく同じように扱うので、transcribe.py の .mid でも外部OMRツールの .mxl でも同じコードパスを通ります。このプロジェクトには MusicXML→MIDI や MusicXML→PDF の別ツールはありません — .musicxml ができれば、どの記譜アプリもすでにそれを開いてエクスポートできるため、そこを作ることはすでにインストール済みの機能の重複にすぎません。

Related MCP server: whisper-mcp

ファイルの置き場所

推奨: 入力ファイルは workspace/ に置いてください（リポジトリ内ローール、gitignore済み — .gitignore 参照 — ここに置いたもの、入力も含め、コミットされることは一切ありません）。ただし必須ではありません。どのパスでも動作します。出力はすべて 入力ファイルの隣、同じベース名・異なる拡張子で配置されます:

workspace/song.mp3          <- you put this here (any format basic-pitch/librosa reads: mp3, wav, ogg, flac...)
workspace/song.mid          <- transcribe_audio writes this
workspace/song.musicxml     <- midi_to_score writes this (open in MuseScore/Guitar Pro/Sibelius/Finale/Dorico)
workspace/song.notes.json   <- score_to_notes writes this (feed into daw-mcp's batch_set_notes)

表示するには: .mid または .musicxml をそのまま、お手元の記譜アプリで開いてください — このプロジェクトがアプリを起動してくれるわけではありません。MuseScoreが .musicxml を「壊れている」と言う場合は、ファイルが壊れていると判断する前に、後述のポリフォニーに関する注意を参照してください。

セットアップ

特に Python 3.11 が必要です — basic-pitch が TensorFlow 2.15 を引き込みますが、そのホイールは cp311 までです。3.12 と 3.13 では解決に失敗します。生成される venv は約2GB になります（軽量バックエンドではなくフル TensorFlow）。

uv venv --python 3.11 venv
uv pip install -r requirements.txt --python venv/Scripts/python.exe

依存関係は正確にピン留めされています（basic-pitch==0.4.0、music21==10.5.0、setuptools==65.5.0、mcp==2.0.0）— このプロジェクトには自動テストスイートがありません。その代わりが、検証済みと完全に一致する新しい環境です。特に setuptools は、それより新しいバージョンだと basic-pitch が必要とする推移的な resampy のインポートを壊すため、ピン留めされています。

使い方: CLI

venv/Scripts/python.exe transcribe.py "C:\path\to\song.mp3"
# -> C:\path\to\song.mid

venv/Scripts/python.exe to_score.py "C:\path\to\song.mid"
# -> C:\path\to\song.musicxml

venv/Scripts/python.exe score_to_notes.py "C:\path\to\song.mid"
# -> C:\path\to\song.notes.json  (daw-mcp's batch_set_notes format - also
#    takes a .musicxml/.mxl directly, e.g. from OMR, no separate step needed)

出力は常に入力の隣、同じベースファイル名・異なる拡張子で配置されます。3つのスクリプトはすべて 既存のファイルは上書きしません — 再実行したい場合は先に削除または移動してください。エラー（入力がない、ライブラリの失敗）は stderr に明確なメッセージを出力して非ゼロで終了します。黙って失敗することはありません。

実際の目的に必要なツールだけを実行してください — 既定で3つ全部を連続実行しないこと。 各ツールはちょうど1つのファイルを生成します。必要な数以上に実行すると、誰も頼んでいないファイルが増えるだけです。

最初の2行の .mid は、本当の「出力」というよりは避けられないチェックポイントです — basic-pitch はMIDIしか生成できないため、後続の結果を信用する前に一度見ておく価値があります（その理由は下記「既知の問題」を参照）。

実行例

架空ではなく実際の実行です。入力: 合成モノラルWAVで、Cメジャーのアルペジオ（C4-E4-G4-C5。アタックが明瞭になるよう短いディケイ包絡線のある四分音符）— 手打ちMIDIではなく実在する波形ファイルというこのプロジェクトの意味で「実オーディオ」であり、録音ではなく合成なので、著作権のあるファイルを公開リポジットに置くことなく転写を再現できます。

$ venv/Scripts/python.exe transcribe.py c_major_arpeggio.wav
WARNING:root:Coremltools is not installed. ...
WARNING:root:tflite-runtime is not installed. ...
WARNING:root:onnxruntime is not installed. ...
Wrote c_major_arpeggio.mid

$ venv/Scripts/python.exe to_score.py c_major_arpeggio.mid
Wrote c_major_arpeggio.musicxml

$ venv/Scripts/python.exe score_to_notes.py c_major_arpeggio.mid
Wrote c_major_arpeggio.notes.json

3つの WARNING:root 行は、オプションのバックエンド（CoreML、TFLite、ONNX）がインストールされていないことを basic-pitch が知らせているものです — 害はありません。実際に使われるバックエンドは TensorFlow であり、また、これこそが transcribe.py v1.1.1 が mcp_server.py のstdoutストリームを破壊することなく、正しく隠すようになった理由の例です（CHANGELOG.md 参照）。この警告は端末にだけ表示され、MCPプロトコルのチャネルには入りません。

c_major_arpeggio.notes.json、 daw-mcp でそのまま使える出力:

[[0.0, 60, 83, 1.0], [1.25, 64, 80, 1.0], [2.3333, 67, 80, 1.0], [3.5, 72, 78, 0.5], [4.0, 72, 78, 0.5]]

4つのノートを入力しました（C4、E4、G4、C5）。basic-pitch は4つすべてのピッチとベロシティを正しく検出し（60/64/67/72、アルペジオと完全一致）ましたが、最後のノート（C5）を1つではなく連続する2つのエントリに分割しました — 減衰エンベロープの末尾がなぜか2つ目のonset部位として読まれたようです。これは、上記「What's this」セクションで警告している自動トランスクリプションの欠落であり、自然な（平坦でない）音量形状を持った最初のノートで実際に発生しました: .musicxml や .notes.json を盲信せず、特に持続音や減衰するノート周辺では .mid を確認してください。

c_major_arpeggio.musicxml はどの記譜アプリでも問題なく開けます（整形式であることを確認済み: 正しい MusicXML 4.0 DOCTYPE、C4/E4/G4/G4/C5/C5/C5 の <step>/<octave> ピッチ — 分割された C5 は小節線をまたぐタイで結ばれた音符として表示されます。これは1小節に収まらない音符に対する標準的なMusicXML表現であり、追加のバグではありません）。

使い方: MCPサーバー

Claude Code の設定に audio2score として登録されています — 新規インストール後は Claude Code を再起動してください（MCPサーバーは起動時に読み込まれます）。

3つのツール、3つのスクリプトをそのまま反映

• transcribe_audio(audio_path) → .mid パスを返す

• midi_to_score(midi_path) → .musicxml パスを返す

• score_to_notes(score_path) → .notes.json パスを返す（daw-mcp の batch_set_notes ノート配列形式。MIDI または MusicXML を受け入れます）

CLIと同じ動作（同じ上書きガード、同じエラー）で、MCPサーバーは薄いラッパーであり、別の実装ではありません。

呼び出しが止まったように見える場合の1つのポイント: transcribe_audio の呼び出しがタイムアウトしたりキャンセルされたりしたように見えても、トランスクリプションはバックグラリでまだ動いている可能性があり、.mid ファイルへの書き込みは完了します。最初の呼び出しが成功しなかったように見えても、リトライすると上書きガード（"already exists"）に当たります。これはバグではありません — リトライする前に .mid がすでに存在するか確認してください。

自分でどこかにサーバーを登録するには、MCP 設定（mcpServers）に次を追加します。両方のフィールドには絶対パスを使用してください — クライアントは working ディレクトリを定義せずに stdio サーバーを起動するため、相対パスは解決できません:

"audio2score": {
  "type": "stdio",
  "command": "<absolute path to>\\venv\\Scripts\\python.exe",
  "args": ["<absolute path to>\\mcp_server.py"],
  "env": {}
}

これがしないこと

• スコア/MIDI → オーディオ、PDF、タブなどの出力はしない。まあ MusicXML → MIDI 変換も行いません — 理由と代わりに使うものは下の「連携するフォーマット」を参照

• ステム分離や複数楽器への分離はしない

• 自動テスト入suiteは意図的にありません — 検証は常に実オーディファイルに対する実際の実行です

連携するフォーマット

.musicxml が存在すれば、このプロジェクトは意図的にそこで止まります — どの記譜アプリもすでに MusicXML を標準で開き、メニューから必要なもの（PDF、オーディオ、タブ、MIDI）を書き出せます。それらの書き出しを自動ラップする試みは実行され、ほぼリバートされました（最終的な経緯は CHANGELOG.md の v1.2.0 から v2.0.0 を参照）。結局、score_to_notes.py が MusicXML を直接、追加の変換手順なしに受けてられることが確認できたので、自動化する価値のある方向は1つもないことが分かりました。

OMR の出力は、basic-pitch のオーディオトランスクリプション以上に疑ってかかってください — 中間の .xml/notation を信頼する前にチェックし、Audiveris がすべての PDF で成功するとは期待しないでください（上記のタブ譜ブックの失敗を参照）。

既知の問題: MuseScore が転写された .musicxml を「破損」として拒否することがある

高度にポリフォニックな転写では、MuseScore Studio が「破損」として開くことを拒否する .musicxml が生成されることがあります。根本原因: music21 自身の MusicXML ライターが、楽曲に多数の同時ボイス(5以上)が必要な場合に、一部の <note> 要素の <voice> タグを省略します。実際の45秒の録音で検証済みで、密集した、しばしば重なり合う音符に転写されました(basic-pitch が実際のオーディオの倍音/アーティファクトを拾う副作用であり、クリーンな単一メロディーラインではありません)。これは music21 のライターの問題であり、このプロジェクトのコードの問題ではないことを確認済みです:to_score.py は parse() + write() の2行の呼び出しで、独自の音符/ボイスロジックはなく、書き出す前に明示的に score.makeNotation() を呼び出しても修正されません。同じファイルを music21 自体で再パースすると、警告が出るだけで(Cannot put in an element with a missing voice tag)、それらの音符をデフォルトでボイス1に設定して回復します。MuseScore のインポーターは単により厳格で、許容する代わりに完全に拒否します。 回避策:「それでも開く」をクリック - 問題なく読み込まれます。ただ、それらの特定の音符が元々検出されたボイスではなくボイス1になるだけで、これは軽微なレイアウト上の問題であり、データの損失ではありません。クリーンで低ポリフォニーの入力(手書きのメロディーMIDIを転写し、ゼロのボイスタグ問題で再検証済み)では発生しません。これは、乱雑で密集した実際のオーディオ転写出力に固有の問題です。