はじめての人にも分かる BadAutoAlign 解説——ボーカル自動補正の理論と設計

歌ってみたやオリジナル曲のレコーディングで、「音程は合っているのに、なんだかガイドとタイミングが揃わない」「ピッチ修正ソフトで直したら声がケロケロになった」という経験はないでしょうか。BadAutoAlign は、手本となるガイド（Synthesizer V などで作ったガイドボーカルのWAV）を基準に、実録ボーカルのタイミングとピッチをオフラインで一括自動補正するツールです。

この記事では、BadAutoAlign の設計ドキュメント一式（システム概要・処理パイプライン・タイミング補正理論・ピッチ補正理論・検出系・実装仕様・GUI仕様・検証記録）をもとに、その中身を最初から最後まで通して解説します。うまくいった最終形だけでなく、実装して捨てた方式とその理由も含めて書きます。この分野の設計は「何が失敗するか」の知見にこそ価値があるからです。

1. 全体像——何がどう動いているのか

BadAutoAlign の本体は Python で書かれた補正コアで、ユーザーが触るのは Electron 製のスタンドアローンGUIです。GUIは補正処理を一切持たず、裏でコアをサービスモードとして起動し、JSON-RPCで会話します。可視化と人間の介入はGUI、補正の判断と処理はすべてコア、という分担です。

┌─ スタンドアローンGUI (Electron) ─┐
│ 4トラック表示 / マーカー編集       │
└──────┬──────────────────────────┘
       │ JSON-RPC (stdio)
       ▼
┌──────────────────────────────────────────────┐
│ Python コア                                   │
│  ガイドアダプタ → フレーズ分割 → 対応付け      │
│  → タイミング補正 → ピッチ再検出 → ピッチ補正  │
└──────────────────────────────────────────────┘

音声を実際に伸縮させるエンジンには Signalsmith Stretch（MITライセンス）を使い、自作のC ABIラッパー経由で呼び出しています。比較・フォールバック用に WORLD も選べます。ライセンスは全依存を MIT / BSD / ISC / zlib 系のみに絞ってあり、コピーレフトやクレジット表示義務のあるライブラリは一切使っていません。

2. 設計原則——「迷ったら触らない」

ドキュメント全体を貫く原則が3つあります。BadAutoAlign を理解する上でいちばん重要なのはコードではなくこの3つです。

原則1: 迷ったら触らない。 誤補正よりも未補正のほうが復旧コストが低い、という判断がすべての土台です。ガイドにノートが無い区間・無音区間・対応の取れないフレーズは素通しし、各所に最大移動量・信頼度・ピッチ照合などのガードを置き、さらに「動かすと実際に一致が良くなる」ことを確認してから動かす閉ループ検証まで行います。未処理の区間は再合成を通さないため、入力とビット単位で一致します。

原則2: 検証は数値で。 処理前後でガイドとの局所的なズレ（ラグ）とピッチ残差を実測し、改善が数値で示せない変更は採用しない、という開発ルールです。正解が既知の合成テストをテストスイートに常備し、実素材での計測とセットで回します。

原則3: 自動化の限界を明示し、人間に引き継ぐ。 局所的な音響情報だけでは原理的に判別できないケースが存在します（後述）。これを無理に自動化せず、GUIで「要確認」と明示して、手動アンカーで人間が確定する分業にしています。

3. 処理パイプライン——フレーズ単位で独立に

処理の流れはこうです。

入力WAV ───┬─ フレーズ分割（RMSゲート）
ガイドWAV ─┴─ ガイドアダプタ（F0検出→擬似ノート化）
              │
              ▼
        ノート⇔フレーズの対応付け
              │
   ┌──────────┴（フレーズごとに独立処理）──────────┐
   │ 1. ピッチ検出                                  │
   │ 2. タイミング補正                              │
   │ 3. ピッチ再検出（ワープ後の音声で検出し直す）    │
   │ 4. ピッチ補正                                  │
   │ 5. クロスフェード付きスプライス                │
   └──────────────────────────────────────────────┘
              │
              ▼
        出力WAV + レポートJSON

いくつか設計上のポイントがあります。

ガイドアダプタ。 ガイドのWAVはまずピッチ検出にかけ、音程の安定した区間を切り出し、ピッチが大きく跳ぶ場所でさらに分割して「擬似ノート列」を作ります。以降の処理はすべて、このノート列を基準に進みます。ガイドのピッチ解析は時間がかかるので、ファイルと解析パラメータをキーにディスクへキャッシュされ、2回目以降は一瞬で終わります。

タイミングが先、ピッチが後。 処理順が「タイミング補正→ピッチ再検出→ピッチ補正」なのは、タイムワープをかけると最初に検出したピッチカーブの時刻がずれてしまうからです。ピッチ補正は、ワープ後の音声で検出し直したピッチに対して行います。

フレーズ粒度は一致しない前提。 合成ガイドは息継ぎが短く、長い連続フレーズになりがちです。そこでフレーズ同士を1対1に対応させるのではなく、ガイドのノート単位で「最もよく重なるボーカルフレーズ」に割り当てます。十分に重ならないノートは「対応する音声なし」として警告付きでスルーします。

ヌルテストの保証。 フレーズ内でワープが恒等写像・ピッチ補正も閾値未満なら、そのフレーズはエンジン自体を通しません。だから「ずれの無い入力は出力が入力とビット一致」します。処理したフレーズは10msのクロスフェードで出力へ書き戻しますが、フレーズ境界はもともと無音なので劣化は実質ありません。

4. タイミング補正・前編——3つの失敗

タイミング補正はこのツールの中核で、最終形にたどり着くまでに3つの方式を実装しては捨てています。

失敗1: ノート単位アンカー

最初の実装は素直でした。ボーカルの発声開始点をガイドの各ノート開始に個別対応させ、対応点（アンカー）ごとに動かす方式です。実素材で2つの致命傷が出ました。

ひとつは掛け違い。ピッチと有声フラグだけの対応付けは、同じ高さの連続音節や細切れのノートで1音節ズレた対応を作ります。誤アンカーは音をまるごと隣の音節の位置へ動かすため破壊的です。

もうひとつは計測ジッタがそのまま音になること。短いノートが密集するレガート区間では、発声の頭の計測自体に±50〜100msのノイズが避けられず、隣接ノートに+99ms→-110msのような物理的にあり得ない交互シフトが適用されて「ガタつき」になりました。ここで得た教訓——歌声は連続体であり、隣接ノートのズレが交互に±100msも振れることはない——が、のちの平滑カーブ方式の根拠になります。

失敗2: フレームDTW

次はフレーズ全体をフレーム単位のDTW（動的時間伸縮法）で対応付ける方式。話者非依存の音素特徴（CMVN正規化MFCC＋Δ）やピッチクラスまで特徴を強化すると±1500ms級の異常値は消えましたが、パスの「にじみ」が残りました。DTWは1音節が複数ノートへ連続的に流れることを妨げないため、長い持続や息継ぎで対応が滑り、ノート単位の精密なアンカーには不向きでした。

失敗3: ギャップスライドと繰り返しフレーズの罠

3つ目は、無音ギャップで区切られたセグメントを伸縮なしで平行移動する方式（エディタのカット＆スライド相当）。合成テストは通りましたが、実素材で繰り返しフレーズ問題に直面します。ポピュラー音楽は同型の楽節を繰り返すため、±1拍分（BPM170なら8分音符=約176ms）ズレた位置に、音量の形もピッチも高相関の「偽の一致」が存在するのです。

検定を厳しくして誤爆をゼロにすると、有効なスライドもゼロになりました。局所的な音響情報だけでは繰り返しの曖昧性は原理的に解消できない。この結論が、GUIでの「人間との分業」設計に直結しています。

5. タイミング補正・後編——最終形の理論

最終形の要点は、「どの音がどのノートか（対応付け）」と「どれだけずれているか（ラグ推定）」を分離したことです。

音節単位の離散アライメント

対応付けには、日本語歌唱の「1ノート≒1モーラ」構造を利用します。ボーカルを音節（モーラ）単位に分割し、ガイドノート列と音節列を、挿入・欠落ペナルティ付きの Needleman-Wunsch 型DP（生物情報学で配列同士を対応付けるのに使われるアルゴリズム）で順序を保って対応付けます。コストはピッチクラス差（オクターブ非依存）・位置差（近い候補を弱く優先=「迷ったら動かさない」方向の事前分布）・長さ比・母音特徴距離の合成です。

フレームDTWと違って「1音節=1ノート」の構造制約を強制できるため、音数が一致すれば先頭からの1対1対応に自然に収束し、合わなければ明示的な挿入・欠落になります。ただしこの対応表は、レポートとGUI表示、照合の証拠として使うにとどめ、最終的なワープの駆動には使いません。個別計測はジッタが大きい、というのが失敗1の教訓だからです。

芯（P-center）——「合っている」の定義

物理的な発声開始と、人間が知覚する「音の頭」は一致しません。音声学ではこれを P-center（perceptual center） と呼びます。歌声のような緩やかな立ち上がりでは知覚的な頭が物理的開始より平均+23〜51ms遅れ、人間同士でも±40ms程度ばらつくという研究があります（Polfreman, ISMIR 2013 ほか）。

ここからの帰結は「アンカーの定義は両側対称に」。ボーカル側だけ有声化開始点（しゃくりの起点）、ガイド側はピッチ安定点——という非対称は、しゃくり分の系統的な後ろズレを生みます（実測で確認済み）。そこで芯の推定はガイドとボーカルに同じ検出器を適用し、検出器の癖を両側で相殺します。芯の検出自体は「ピッチが安定音高の圏内に入って持続し始めた時刻」と「中帯域エネルギーの最速上昇点」の遅い方を採ります。前者がしゃくりを構造的に除外してくれます。

ラグの計測——包絡相互相関

最終的なラグ推定の主役は、母音のエネルギーが支配的な中帯域（300〜3000Hz）のエネルギー包絡です。dB化して滑らかにした包絡同士を、フレーズ内で0.2秒刻みに局所照合します。各時刻でボーカル包絡の±0.4秒窓をガイド包絡に対しスライドさせ、正規化相関が最大になるズレを「その時刻のラグ」として採る、という方式です。VocALign や Revoice Pro と同じ原理で、DAWの波形比較でユーザーが見る「合っている」と同じ定義を最適化することになります。

ここにも「測らない」判断が入っています。窓内の包絡の起伏が6dB未満（無音・平坦）、または最大相関が0.6未満のサンプルは捨てます。ラグが定義できない場所では測らない。ノート単位の芯計測よりはるかにノイズが少なく、レガートでも密にサンプルが取れます。

平滑ラグカーブ——点ではなく曲線で

ラグのサンプル列から、滑らかなラグカーブを頑健に推定します。処理は段階的です。

1. 加重メディアン局所回帰でカーブを引く（信頼度と距離で重み付け）
2. カーブから80ms以上離れた外れ値を捨てて一度だけ再フィット
3. ラグの絶対値を最大移動量（既定120ms）でクリップ
4. 隣接区間のラグ変化率に25%の上限（局所テンポ歪みの上限）
5. 不感帯: ラグがごく小さい区間はゼロ（恒等写像）に落とす
6. 閉ループ検証: 各点で「その量だけ動かすと包絡相関が実際に改善する」ことを確認し、改善しない点はゼロに落とす
7. 遷移をガウシアンでなだらかに接続
8. カーブ全体が最小移動量未満ならワープ自体を行わない

不感帯は「合っている所は触らない」の曲線版です。フレーズの一部だけがずれている場合に、すでに合っている区間へカーブの微小ノイズが乗るのを防ぎます。閉ループ検証は、大きなミスマッチの近傍で計測が汚染され、良好な隣接区間まで引きずられる事故への最終防衛線です。

出来上がったカーブは区分線形のアンカー列に変換され（フレーズ両端は恒等で固定）、Signalsmith Stretch のストリーミングAPIで可変レートストレッチとして適用されます。出力長はフレーズ長と厳密に一致させます。

ガード一覧

タイミング側のガードをまとめるとこうなります。それぞれ性質の違う事故を一層ずつ防いでいます。

6. ピッチ補正——ケロらせないための理論

ピッチ補正を素直に実装すると「ガビガビ」「ケロケロ」になります。BadAutoAlign の対策は3つに集約されます。

スナップしない——中央値オフセット方式

検出ピッチをノート音高へ張り付ける「スナップ」はケロケロ声の元です。代わりに、ノート区間ごとに検出F0の中央値とターゲット音高の差分を求め、ずれの直流成分だけを取り除きます。補正カーブはノート内で一定なので、ビブラート・しゃくり・微細な揺らぎは差分に含まれず、そのまま保存されます（Melodyneのドリフト補正に相当する考え方です）。

中央値を使う理由も明確で、ノート内のピッチ分布はしゃくりやビブラートで非対称になりますが、中央値は区間の「芯の音高」を頑健に代表します。平均だとしゃくりに引かれてしまいます。カーブは時間方向に平滑化し、ノート頭の80msは補正強度をランプインしてしゃくりの表情を保持。さらに補正強度は既定0.85で、完全一致より自然さを優先しています。300セントを超えるオフセットは「検出誤り（オクターブ違い等）」とみなしてスキップします。意図的なオクターブ下ハモはここで保護されます。

無声音とブレスを触らない

ガビつきの主因は、サ行・タ行などの無声子音とブレスへのピッチシフト適用です。有声判定は「検出器の有声フラグ ∧ 信頼度 ∧ RMSゲート ∧ ZCR（ゼロ交差率）」の合成で行い、無声フレームの補正量はゼロ。有声・無声の境界はソフトマスクでクロスフェードします。

エンジン——検証で見つけた罠

シフトエンジンの第一候補は Signalsmith Stretch です。周波数領域処理で位相コヒーレンスを保ち、タイムストレッチとピッチシフトを同一エンジンで実行できます。ただしここに開発中の面白い罠がありました。PyPIにある既存バインディングは呼び出しごとに内部で seek/flush するワンショットAPIで、チャンクごとにパラメータを変える用途に使えないことが検証で判明したのです（チャンク処理と全体処理の結果が一致しない）。そこでヘッダをベンダリングし、薄いC ABIラッパーを自作しました。

もうひとつの罠が乱数シードです。既定コンストラクタは実行のたびに異なるシードで初期化されるため、同じ入力でも出力が毎回微妙に変わります。A/B比較・テスト・GUIの再補正のため、固定シードで生成して決定性を確保しました。同一入力・同一パラメータなら出力はビット単位に再現されます。

検出グリッドの平均律整列

地味ですが効いた工夫がもう一つ。pYIN検出器の周波数ビンは下限周波数から一定刻みで並ぶため、下限を65Hzのような切りの良い数字にするとビン中心が平均律からずれ、正しい歌唱に対して最大±5セント級の系統バイアスが検出に乗ります。そこで下限を C2 の正確な周波数にします。

fmin = 65.40639  # C2。pYINのビン格子が平均律に整列し、検出バイアスがゼロになる

これでビン格子が平均律に整列し、10セント分解能でも品質要件（残差10セント未満）を満たせるようになりました。分解能を粗くできたことで、検出は約4倍高速になっています。

7. 検出系——すべての土台

補正の質は検出の質で決まります。BadAutoAlign の検出系は4つの部品からできています。

ピッチ検出（F0）。 pyin（追加依存なし）・rmvpe（歌声向け最高精度のニューラル検出器）・crepe の3つを統一インターフェースで抱え、既定では使える順に自動選択します。検出後は信頼度・RMS・ZCRの共通ゲートを通します。ちなみにpYINの計算量はフレーム数×ビン数の2乗に比例するため、初期設定（5セント分解能・細かいホップ）では3分の曲に15分以上かかっていました。平均律整列でバイアスを消した上で分解能を10セントに粗くし、いまは全パイプラインで約40秒です。

中帯域エネルギー包絡。 300〜3000Hzのバンドパス→フレームRMS→dB→ガウシアン平滑。母音のエネルギーが支配的な帯域で、ラグ計測と芯検出の両方の土台です。

音節（モーラ）分割。 3種類の境界手掛かりの和集合で切ります。(1)無声子音や息継ぎの後の有声化開始点、(2)母音品質の変化点（MFCC特徴のノベルティのピーク。レガート内の母音遷移を拾う）、(3)ピッチ跳躍（同一母音で音高だけ変わる場合）。ただしビブラートでノベルティが誤発火して過分割になるため、「連続していて・同一音高で・境界にエネルギー谷が無い」断片は同一音節にマージします。同じ音高で歌い直す「ああ」のような連続モーラは、再アーティキュレーションのエネルギー谷が境界に現れるので分割が保持される——という仕組みです。

音素特徴。 CMVN正規化したMFCC＋Δの24次元。正規化によって話者や音色（SynthVと生声）の絶対差は消え、母音・子音の対比だけが距離に残ります。音節アライメントの母音特徴距離に使います。

8. 実装のかたち——サービスとレポート

コアはモジュール分割されたPythonパッケージで、GUIとの間は stdio 上の行区切りJSON-RPCで会話します。stdoutはプロトコル専用で、処理ログや進捗はすべてstderrへ流します（これを混ぜるとプロトコルが壊れます）。GUIのプログレスバーは、このstderrに流れる「フレーズ何個中何個」という実進捗をパースして表示しています。

→ {"id": 2, "method": "process", "params": {
     "input": "vocal.wav", "guide": "guide.wav", "output": "out.wav",
     "options": { "pitch_strength": 0.85 },
     "manual_anchors": [{"src_s": 12.34, "dst_s": 12.20, "note_index": 41}]
   }}
← {"id": 2, "ok": true, "result": {レポート}}

そして設計上の主役級がレポートJSONです。フレーズごとの対応表（どのノートがどの音節に対応したか、判定とコスト）、ラグの計測値と適用値、ノートごとの補正量・残差・スキップ理由がすべて記録されます。

"notes": [{
  "index": 0, "midi_pitch": 57.0,
  "offset_cents_before": 31.0, "applied_cents": 26.4,
  "timing_shift_ms": -15.8,     // 計測値（芯対芯）
  "timing_applied_ms": -40.6,   // 実際に適用した移動量
  "timing_residual_ms": 3.1,    // まだ残っているズレ（null=計測不能）
  "skip_reasons": ["shift_exceeds_max"]
}]

「補正しなかった」ことにも必ず理由（shift_exceeds_max、anchor_pitch_mismatch など）が付くので、結果に疑問があったときに「計測が悪いのか・判断が悪いのか・適用が悪いのか」を切り分けられます。GUIのマーカー表示も、このレポートをそのまま可視化したものです。

9. GUIの使い方——目ではなく、耳で合わせる

ここからは、GUI版を実際に使う流れに沿ってUI・UXを紹介します。設計思想を一言で言えば「表示の軸は『何をしたか』ではなく『何を操作すべきか』」——そして操作の軸は「見た目ではなく、耳で合わせる」です。

読み込みから補正まで

画面はガイドボーカル・補正対象ボーカル・補正結果・オケ（再生専用）の4レーン構成です。WAVは各レーンへのドラッグ&ドロップで読み込みます。各レーンの左側には音量ノブとミュートがあり、再生しながらリアルタイムに効くので、「オケ＋補正結果だけを聴く」「ガイドとボーカルを重ねて聴き比べる」といったモニタリングの切り替えが片手でできます。

ヘッダで補正の種類（タイミング／ピッチ／両方）を選んで実行すると、処理の実進捗（フレーズ何個中何個まで進んだか）がプログレスバーに出ます。波形表示は仮想化描画なので、曲全体の俯瞰から数十ミリ秒単位の拡大まで、ホイール操作で軽快にズームできます。

補正が終わったら——マーカーが作業リストになる

補正が完了すると「補正完了: 要確認 N箇所（黄x/赤y）」と表示され、ノートごとのマーカーが色分けされます。

グレーは触る必要がありません。ユーザーがやることは、黄と赤を上から順に潰していくだけです。何箇所直せば終わるのかが最初から数字で見えるので、「どこまでやれば完成なのか分からない」という手動ピッチ修正にありがちな消耗がありません。

マーカー操作——補正基準そのものを、耳で微調整する

ここがこのGUIの核心です。マーカーは単なる目印ではなく、補正の基準点（アンカー）そのものです。つまりマーカーをずらすことは「表示を直す」操作ではなく、補正の基準を微調整する操作になります。

その微調整を支えるのが試聴の作りです。マーカーは押している間だけ、その位置からガイド側・ボーカル側それぞれの音が鳴ります（ミュートや音量ノブをバイパスして等倍で直結。離すと止まります）。まず長押しでガイドとボーカルを聴き比べて、ズレの正体を耳で確かめる、というのが基本動作です。

そのままドラッグに移ると、今度はスクラブ再生が始まります。動かしている位置の短い断片（既定80ms、UIで可変）がフェード付きで鳴り続け、あわせて元位置からのオフセットがミリ秒表示されます。波形の山を見た目で重ねる「アバウトな視覚合わせ」ではなく、発音の頭が聴感上どこにあるのかを、耳で確かめながら決められるということです。第5章で書いたとおり、人間が知覚する「音の頭」（P-center）は波形上の物理的な立ち上がりとはズレています。だから最後の微調整は目より耳のほうが正確で、GUIはその耳での判断が最短でできるように組んであります。

離した位置は手動アンカーとして確定します。ほかにダブルクリックの「ピン留め」——位置はそのままに、ガード無視で完全適用する操作——もあり、「あと+80msズレ」と表示されている箇所への最短の直し方です。赤（対応なし）のノートは、ガイド側をダブルクリックするとボーカル側にマーカーが生成され、同じようにドラッグで確定できます。

再補正——人間の判断を最優先で織り込む

マーカーを直したら「再補正」を押します。手動アンカーは全ガードを免除して最優先で適用され、その周辺の自動判断より人間の判断が勝ちます。第4章で述べたとおり、繰り返しフレーズの曖昧さや構造的な歌い回しの違いは自動では原理的に解決できません。「自動で大部分、要確認箇所は耳で確定」という分業のための出口が、この手動アンカー＋再補正のループです。仕上がったら「保存」で補正結果のWAVを書き出して完了です。

10. 検証——数値で語る

最後に、この設計が実際どこまで効いたのかを。開発では正解既知の合成テスト（擬似ボーカルに既知のずれを与えて補正後残差を評価）22件をpytestに常備し、あわせて実素材——SynthVガイド＋実録ボーカル約3分——でガイドとの局所ラグを楽曲全体でサンプリングして、補正前後の分布で判断しました。

ノート個別アンカー時代はシフト計測が最大±1563msまで暴れ、掛け違いの兆候が7件出ていたのが、平滑カーブ＋各種検証の最終形では異常値が消滅しました。残っている50ms超のズレの大半は、ガードが「触るべきでない」と判断して意図的に残した箇所（構造的な歌い回しの違い）です。ピッチはフレームレベルの残差中央値が50セント→30セントへ改善。揺らぎを保存する方針なのでゼロにはなりません——そしてそれが狙いです。

既知の限界も明記されています。区間内でズレ量が流動するケース（+290ms→+151msと変化して直後に反転するような歌い方）は、滑らかなワープでは追従できず、追従させるとガタつきが再発するため自動補正の対象外。繰り返しフレーズの±1拍ズレも局所情報では判別不能。どちらも手動アンカーの領域です。

おわりに

BadAutoAlign の設計を一言でまとめるなら、「賢く動かす」ことより「間違って動かさない」ことに投資したツール、ということになります。個別に測ると信用できない計測値を平滑カーブに束ね、測れない場所では測らず、動かして良くならないなら動かさず、それでも残る原理的な曖昧さは隠さずに人間へ引き継ぐ。派手さはありませんが、実素材で数値を取りながら失敗を3回やり直した末にたどり着いた、作り手・伊達五十嵐なりの現場の答えです。

ツール本体はソフトウェアページで配布しています。歌ってみたの整音やセルフレコーディングの効率化に、役立ててもらえたら嬉しいです。