採譜は動いた。伴奏にはならなかった — OSSでカラオケ音源を作れなかった記録

友人が「歌ってみた」用の音源を、耳コピで自分から作っていると聞きました。そんな作り方があるのかと思ってから、ずっと気になっていました。同じことを機械にやらせたらどこまで行くのか、1曲ぶん試して、できませんでした。

これは失敗の記録です。ただし「精度が足りませんでした」という話ではありません。むしろ逆で、採譜は想定よりずっと動きました。それでも聴けるものにならず、私が考えていた「うまくいかない理由」は検証の途中で3回変わりました。3回とも、その時点では確信を持って間違えていました。

多楽器採譜の精度がこの先上がっても、この問題は解けません。 採譜はもう足りているからです。

なぜ「原盤を触らない」道を選んだのか

カラオケ音源は、原盤（レコード会社が持っている、その音源そのもの）を加工したものではありません。その曲を別に演奏し直したものです。

ここから道が2つに割れます。

道	やること	生まれる録音
原盤からボーカルを抜く	音源分離でボーカルを消す	原盤の派生。権利関係は元のまま
採譜して作り直す	譜面に起こして自分で鳴らす	自分で生成した録音

下の道なら手元の録音として扱えるはずだ、というのが出発点でした。私は弁護士ではないので線引きの細部には踏み込みません。ただ、「作り直す」に技術がどこまで届くのかは測れます。測ったのがこの記事です。

対象は wacci「恋だろ」1曲（4分50秒）。

見立て1「採譜がポップスに届かない」は外れました

組んだのは3工程です。

工程	使ったもの	ライセンス
音源分離	Demucs htdemucs	MIT
採譜	Basic Pitch（Spotify）	Apache-2.0
合成	FluidSynth 2.2.5 + FluidR3_GM.sf2	—

MT3 や Omnizart も候補にはありましたが、実測していません。Basic Pitch で十分な結果が出たので、比較する理由が消えました。

私は最初、1段目で詰まると思っていました。多楽器が同時に鳴るポップスの採譜は解けていない、というのが一般論です。MT3 の README にも「歌声で学習していないのでボーカル入りを渡すと変な結果になる」と書かれています。

外れました。分離してから採譜すれば、その制約は消えます。

まず分離そのものが効いているかを、原曲・ボーカル・伴奏の3本を並べて確かめました。同じピッチ検出を3本にかけて、出てきた音高のヒストグラムを比べます。

• vocals と no_vocals の重なり 0.09（高いほど伴奏がボーカル側に漏れている）
• confidence 中央値は vocals が 0.976。原曲 0.865 / 伴奏 0.893
• 上位に来る音域は、原曲も伴奏も A1〜E2 のベース音域。vocals にその低音は残らない

1本だけ見ても判断できません。私は最初、音高が E・F#・G#・B に集中しているのを見て「分離が壊れている」と疑いました。E メジャーの曲を歌えば、そうなるだけでした。

分離した stem に Basic Pitch をかけた結果がこれです。

stem	音符	毎秒	想定音域内	多い音名
bass	794	2.8	88%	B, A, E, C#, G#
other	3228	11.2	79%	E, B, A, G#, C#
vocals	894	3.1	95%	E, B, F#, G#

「MIDI ファイルが出た」を成功に数えないよう、判定基準は先に決めておきました。

#: 楽器として妥当な音域 (MIDI)
EXPECTED = {
    "bass": (28, 55),      # E1 〜 G3
    "other": (48, 84),     # C3 〜 C6
    "vocals": (45, 79),    # A2 〜 G5
}

そのうえで決め手になったのは調性でした。3つの stem は互いに独立して採譜されているのに、上位の音名がすべて E メジャーの構成音（E F# G# A B C# D#）で揃いました。偶然ではこうなりません。

速度も障害になりませんでした。Demucs は CPU で実時間の 2.2 倍速です。4分50秒の曲が2分12秒で分離できます。GPU は要りません。

1段目は動いています。

見立て2「壁は合成の質だ」も外れました

次に疑ったのは合成です。採譜が正しくても、鳴らす音が安っぽければ聴けたものにはならない、と考えました。

そこで音色を段階的に上げて、そのつど聴いてもらいました。

版	合成方法	判定
resynth	サイン波（bass + other）	使えない
piano	FluidSynth ピアノ（bass + other）	使えない
guide	FluidSynth ピアノ（主旋律のみ）	うーん
musicbox	FluidSynth オルゴール（主旋律のみ）	微妙

実際の音です。4つとも同じ区間（60〜90秒）を切り出しています。原盤には触れていません。採譜した譜面から私が生成した録音です。

1. サイン波 — 判定「使えない」

2. FluidSynth ピアノ（伴奏） — 判定「使えない」

3. FluidSynth ピアノ（主旋律のみ） — 判定「うーん」

4. オルゴール（主旋律のみ） — 判定「微妙」

サイン波とオルゴールでは、音そのものはまったくの別物です。それでも判定はほとんど動きませんでした。「使えない」が「微妙」になっただけです。

この頭打ちが答えでした。 音色が原因なら、音色を上げたぶんだけ評価が上がるはずです。上がらないということは、私が触っている軸と、聴いた人が失望している軸が別だということになります。

音色以外の手も打ってはいます。other stem は毎秒 11.2 音ありますが、同時に多くの音が鳴っているわけではありませんでした。短い音が連続しているだけです。シンセパッドやリバーブの尾を音符として拾っています。

#: これより短い音は捨てる (秒)
MIN_DURATION = 0.2
#: これより弱い音は捨てる。弱い誤検出を落とす
MIN_VELOCITY = 50

この間引きで 3228 音が 1770 音まで落ち、濁りは多少ましになりました。多少です。

抜けていたのは編曲でした

カラオケ音源とオルゴールアレンジが実際どう作られているのかを調べました。どちらも人が編曲して打ち込んでいました。

カラオケ音源の制作会社であるシーミュージックの三木康司社長が、制作の実態をこう話しています。

データ入力はすべて耳コピで行っていますよ。そのためレコード会社からMIDIデータをもらう、なんてことはありませんが、発売前の曲を事前にもらって作業を進めることはよくありますよ。 — シーミュージック 三木康司 氏 / DTMステーション（藤本健）

データがない状態から、人が耳コピしています。専門の職能として成立している仕事です。

オルゴールも同じでした。YouTube に大量にある「オルゴールアレンジ」の多くは、実際のオルゴールで鳴らしたものではありません。オルゴール風の音を使って自由に編曲されたものです。

原曲をなぞることと、その楽器用に作り直すことは、別の作業です。

オルゴールアレンジが聴けるものとして成立するのは、オルゴールで鳴らして成立する形に編曲し直しているからです。音を減らし、動きを整え、音域を移す。採譜した結果の音色だけ差し替えても、そこには届きません。

私が組んだのは「機械が採譜して、そのまま鳴らす」でした。真ん中が空です。ピアノ用の間引き処理は入れましたが、あれは編曲と呼べるものではありませんでした。ただの密度調整です。編曲だと思っていた自分がいちばん雑でした。

冒頭の友人がやっていたのも、この真ん中の列でした。耳で音を取る部分は機械が肩代わりできます。取った音をその楽器で成立する形に組み直す部分を、友人は手でやっていたわけです。私は聞いた時点で、そこを工程として数えていませんでした。耳コピという一語で、2つの作業をまとめて呼んでいたからです。

「できない理由」は3回変わりました

並べると、自分の間違え方に形があります。

時点	そのとき考えていた理由
最初	採譜がポップスに届かない
分離してから採譜したら精度が出た	採譜は動く。合成が壁
音色を上げても評価が変わらない	合成でもない。編曲の工程が抜けている

最初の2つは、どちらも「精度が足りない」という同じ形をしています。精度の話は測りやすく、改善の方向もはっきりしているので、原因の候補として最初に出てきます。

抜けている工程は、そういう形では現れません。工程が無いと、その工程の出来は測れないからです。実際に手がかりになったのは「音色を上げたのに評価が変わらなかった」という、何も改善しなかった実験でした。改善が止まったこと自体がデータでした。

追記: 編曲を行うモデルは、もうありました

記事を書いたあとに調べました。見立てはまた崩れました。編曲まで行うモデルは、すでに公開されています。

モデル	入力	出力
AccoMontage（ISMIR 2021）	lead sheet（主旋律 + コード進行）	ピアノ伴奏
AccoMontage-3（NeurIPS 2024）	lead sheet	ピアノ伴奏 → マルチトラック編成（楽器を指定できる）

どちらもコードが公開されています。ただし動かしていません。MT3 や Omnizart と同じで、ここに書いたのは論文とリポジトリの記述であって、私の実測ではありません。

引っかかったのは入力の形でした。これらが受け取るのは lead sheet、つまり主旋律とコード進行です。私のパイプラインが出したものは違いました。stem ごとの生の MIDI で、bass 794 音符、other 3228 音符、vocals 894 音符が時間順に並んでいるだけです。渡せません。

間に要るのは、採譜結果を lead sheet に直す工程です。主旋律を確定して、コード進行を推定する。この実験は、その材料をすでに半分持っていました。vocals stem の採譜が主旋律の候補になっていて（想定音域内 95%、既存の譜面とも一致）、3 stem が E メジャーで揃ったことで調性も取れています。足りないのはコード進行だけです。other stem の 3228 音符から各小節の和音を推定する工程が、どこにも入っていません。

4回目の間違いは、待つ相手をモデルだと思っていたことでした。 採譜結果を lead sheet に変換する工程、つまり主旋律を1本に決めてコード進行を推定するところは、モデルの登場を待たなくても自分で書ける範囲に見えます。次はそこです。

この結論の有効期限

2026年8月時点の、OSS を組み合わせた場合の話です。「できなかった」を日付なしで書くと、数年後に読んだ人に「今でもできない」と誤読されます。

覆る条件は3つです。

何が変われば	効き方
採譜結果を lead sheet に変換する工程を書く	本丸。編曲モデル側の入口が lead sheet なので、ここが繋がれば届く見込みがある
MIDI から音を作る合成が人手なしで自然になる	音色の壁は下がるが、編曲は残る
多楽器採譜の精度が上がる	効きません。採譜はもう足りている

3行目が、この記事でいちばん残したいところです。この分野のニュースは採譜や分離の精度で語られることが多く、私も2回そこに理由を求めて外しました。ここが良くなっても、私が詰まった場所は動きません。

同じ場所を掘る人の手間が、これで少し減れば十分です。

手元に残ったのは、採点用の譜面をそのまま鳴らすガイドメロディだけでした。聴こえた音を出せば必ず満点になる伴奏です。カラオケとしては、たぶん世界一やさしい。