初期実装では以下に限定:

• BPM検出
• オンセット検出（周波数帯域別）
• 基本的な譜面生成（ChartData JSON出力）

将来の拡張（今回は対象外）:

• 音源分離（Demucs/Spleeter）
• LLMによる有機的な配置判断
• 楽曲構造分析

アーキテクチャ

flowchart TB
    subgraph input [入力]
        AudioFile[音声ファイル .wav]
        Options[オプション: 難易度等]
    end

    subgraph analysis [音響分析]
        BPM[BPM検出]
        Onset[オンセット検出]
        Band[周波数帯域フィルタ]
    end

    subgraph mapping [レーン配置]
        LowBand[低音域 → レーン0-1]
        MidBand[中音域 → レーン2-5]
        HighBand[高音域 → レーン6-7]
    end

    subgraph output [出力]
        ChartJSON[ChartData JSON]
    end

    AudioFile --> BPM
    AudioFile --> Band
    Band --> Onset
    Options --> mapping
    BPM --> ChartJSON
    Onset --> LowBand
    Onset --> MidBand
    Onset --> HighBand
    LowBand --> ChartJSON
    MidBand --> ChartJSON
    HighBand --> ChartJSON

実装内容

1. BPM検出

librosa.beat.beat_track() を使用:

import librosa

y, sr = librosa.load('song.wav')
tempo, beat_frames = librosa.beat.beat_track(y=y, sr=sr)
# tempo: 検出されたBPM（例: 128.0）
# beat_frames: ビート位置のフレーム番号

2. 周波数帯域別オンセット検出

バンドパスフィルタで周波数帯域を分離し、各帯域でオンセット検出:

from scipy.signal import butter, sosfilt

def bandpass_filter(y, sr, low_freq, high_freq):
    sos = butter(4, [low_freq, high_freq], btype='band', fs=sr, output='sos')
    return sosfilt(sos, y)

# 低音域（ベース・キック）: 20-250Hz
y_low = bandpass_filter(y, sr, 20, 250)
onsets_low = librosa.onset.onset_detect(y=y_low, sr=sr, units='time')

# 中音域（スネア・メロディ）: 250-2000Hz
y_mid = bandpass_filter(y, sr, 250, 2000)
onsets_mid = librosa.onset.onset_detect(y=y_mid, sr=sr, units='time')

# 高音域（ハイハット・シンバル）: 2000-8000Hz
y_high = bandpass_filter(y, sr, 2000, 8000)
onsets_high = librosa.onset.onset_detect(y=y_high, sr=sr, units='time')

3. レーン配置ルール

周波数帯域 → レーンの固定マッピング:

• 低音域（20-250Hz） → レーン 0, 1
• 中音域（250-2000Hz） → レーン 2, 3, 4, 5
• 高音域（2000Hz以上） → レーン 6, 7

同じ帯域内での連続ノートは、交互にレーンを切り替えて配置（同じレーンに連続しすぎないように）。

4. ノート密度調整

オンセットをそのまま全て配置すると密度が高すぎる場合があるため、間引き処理を行う:

• 最小間隔（例: 100ms）より短い間隔のノートは間引く
• 難易度オプションで間引き率を調整

5. ChartData JSON出力

既存の ChartData 型に合わせた形式で出力:

{
  "metadata": {
    "title": "Generated Chart",
    "artist": "Unknown",
    "audioFile": "assets/audio/song.wav",
    "bpm": 128,
    "timeSignature": [4, 4],
    "offset": 0
  },
  "notes": [
    { "lane": 0, "timing": 500 },
    { "lane": 3, "timing": 750 },
    ...
  ]
}

ファイル構成

scripts/
└── chart-generator/
    ├── main.py              # CLIエントリーポイント
    ├── analyzer.py          # BPM検出、オンセット検出
    ├── chart_builder.py     # レーン配置、ChartData生成
    └── requirements.txt     # 依存パッケージ

依存パッケージ

librosa>=0.10.0
numpy>=1.24.0
scipy>=1.10.0
soundfile>=0.12.0

CLI使用例

# 基本的な使い方
python scripts/chart-generator/main.py input.wav -o output.json

# タイトル・アーティスト指定
python scripts/chart-generator/main.py input.wav -o output.json \
  --title "My Song" --artist "Artist Name"

# 難易度調整（ノート密度）
python scripts/chart-generator/main.py input.wav -o output.json \
  --density normal  # easy / normal / hard

将来の拡張ポイント

今回の実装を土台として、以下の拡張が可能:

1. 音源分離の追加: Demucsを導入し、stem別のより正確なオンセット検出
2. LLM統合: 分析結果をLLMに渡して配置戦略を決定
3. 楽曲構造分析: イントロ/Aメロ/サビを検出し、セクション別の配置変化
4. ピッチ検出: メロディの高低をレーン位置に反映

良い質問です。stem分離なしでも(1)の基本機能は十分に実現可能です。整理します。

stem分離なしでできること

stem分離がないと難しいこと

• 「ドラムだけ」「ベースだけ」の正確なタイミング取得
• 「同じ楽器の音を同じレーンに」という配置
• ボーカルメロディの正確なピッチ追跡

代替アプローチ: 周波数帯域フィルタリング

stem分離の代わりに、周波数帯域で音を分類する方法があります。

低音域（20-250Hz）  → ベース・キック的 → レーン 0-1
中低音域（250-500Hz） → スネア・低めのメロディ → レーン 2-3  
中音域（500-2000Hz） → ボーカル・メロディ → レーン 4-5
高音域（2000Hz以上）  → ハイハット・シンバル → レーン 6-7

# バンドパスフィルタで周波数帯域ごとにオンセット検出
y_low = librosa.effects.split(y, top_db=30)  # 低音域
onset_low = librosa.onset.onset_detect(y=y_low, sr=sr)

この方法のメリット・デメリット

メリット:

• 追加の依存（Demucs/Spleeter）が不要
• 処理が高速
• シンプルな実装

デメリット:

• 精度はstem分離より劣る（楽器が周波数帯域で完全に分離されるわけではない）
• 「同じ楽器」の判定は近似的

了解です。スコープを絞った初期実装のプランに更新します。

プランを初期実装のスコープに絞りました。

更新後のプラン概要

実装内容:

1. BPM検出 - librosaで楽曲のテンポを自動検出
2. 周波数帯域別オンセット検出 - バンドパスフィルタで低音/中音/高音を分離し、各帯域の音の立ち上がりを検出
3. レーン配置 - 周波数帯域に応じてレーン0-7に固定マッピング
4. ChartData JSON出力 - 既存のゲームで読み込める形式で出力

ファイル構成:

scripts/
└── chart-generator/
    ├── main.py           # CLIエントリーポイント
    ├── analyzer.py       # 音響分析
    ├── chart_builder.py  # 譜面生成
    └── requirements.txt  # 依存パッケージ

使い方（完成後）:

python scripts/chart-generator/main.py input.wav -o output.json --title "曲名"

生成ロジック

1. 音声分析（analyzer.py）

処理フロー

音声ファイル読み込み (librosa) │ ↓ BPM検出 (librosa.beat.beat_track) │ ↓ 周波数帯域別オンセット検出 ├─ low (20-250Hz) → ベース・キック ├─ mid (250-2000Hz) → スネア・メロディ └─ high (2000-8000Hz) → ハイハット・シンバル

周波数帯域

各帯域に対してバンドパスフィルタ（Butterworth）を適用し、個別にオンセット検出を行う。

BPM検出

• 検出範囲: 90-200 BPM
• 範囲外の場合は倍/半分に自動調整（例: 60 BPM → 120 BPM）

2. 譜面生成（chart_builder.py）

レーン配置

周波数帯域を8レーンにマッピング：

低音(キック/ベース) │ 中音(メロディ/スネア) │ 高音(ハイハット) [0] [1] │ [2] [3] [4] [5] │ [6] [7]

同じ帯域内の連続ノートは交互にレーンを切り替えて配置する。

難易度と密度調整

最小間隔の計算式：

最小間隔(ms) = 60000 / BPM / (note_division / 4)

間引きロジック

• 時間順にソートし、最小間隔未満のノートを除外
• レーンに関係なく時間差でフィルタするため、同時押しは発生しにくい

方法案（優先度高）

1) 帯域ごとの間引き → 近接クラスタで同時押し化

• 各帯域で別々に最小間隔を適用し、最後にマージする
• マージ時に ±X ms 以内に集まったオンセットを「同時押し候補クラスタ」として扱う
  → 1~2レーンの複数ノートにする（上限は2〜3を推奨）
• これで「異なる帯域が同時に鳴る時だけ同時押し」が起きる
  (例: kick+snare, snare+hat)

利点: 同時押しが「音響的理由」に限定されるので過多になりにくい。

2) 強さベースの同時押し（ピーク強度で増やす）

• onset strength（検出強度）や RMS のピークが大きいタイミングだけ同時押し
• 例えば強度が p90 以上の時は “追加レーン” を 1 本だけ足す
  → 同じ帯域内で交互レーンとは別に、隣接レーンも使う

利点: 強い拍だけ厚くなるので、曲の抑揚と一致しやすい。

3) ビート上の限定同時押し（拍ごとの確率）

• 拍グリッドにスナップした上で
  • 小節頭/拍頭にのみ同時押しを許可
  • その中でも 確率 10〜20% 程度
• さらに “同時押しが連続しない” ルールを追加
  • 例: 直前が同時押しなら次は必ず単押し

利点: 単調な連続同時押しを抑制できる。

補助的な抑制ルール（同時押し過多の防止）

A) 同時押しの最大数を上限で制限

• 1 タイミングに 2 ノートまで を基本
• hard のみ 3 まで許可、easy/normal は 2 まで

B) 同時押し密度のクールダウン

• 「同時押し発生後 N ms 以内は同時押し禁止」
  (例: 250ms)

C) レーン偏り防止

• 同時押しは 左右対称 or 中央寄せ で出す
  (視認性向上 & 連続同時押しでも押しやすい)

現状ロジックに対する最小変更の方針

• “全帯域まとめて間引き” をやめる
  → まず帯域ごとに間引く
• その後、近接時刻クラスタを検出し、
  “クラスタ内で1つだけ追加レーンを生成” する
  → これだけでも同時押しが「適度」に出る

具体的な調整パラメータ例（目安）

• 同時押し化ウィンドウ: ±30〜40ms
• 同時押し確率: 10〜20%（beat head のみ）
• 追加レーン数: +1（2ノートまで）
• クールダウン: 200〜300ms
• 強度閾値: p85〜p95

はい、帯域は今のまま 3 つ（low/mid/high）でOKです。
この方法は「帯域を増やす」話ではなく、**“帯域ごとに間引いてからマージし、近いタイミングをクラスタ化して同時押しにする”**という処理順の変更が主眼です。

現状の帯域分割とレーン割り当てはそのまま使えます。
必要ならあとで 4 帯域以上に細分化するのは別の改善軸です。

改善案あります。別の判定軸（音量・強度）はアリで、むしろメリハリを付けるには有効です。実装コストと効果のバランスで3案出します。

低コストで効く案

• 帯域ごとの“密度”で同時押し許可
  一定時間窓（例: 1秒）内のオンセット数が閾値以上なら同時押し可、未満は単押し固定。
  → 静かなパートは自然に単押し化。

• 小節/拍頭だけ同時押し許可
  BPMグリッドにスナップ後、拍頭/小節頭でのみ同時押しを許可＋確率（10〜20%）。
  → 常時同時押しにならない。

音量・強度を使う案（おすすめ）

• オンセット強度（onset strength）を使う
  各オンセットに“強さ”を持たせ、強いピークだけ同時押し許可。

  • 強度が p85 以上 → 同時押し可
  • それ以外 → 単押し
    → 派手な音だけ厚くなるので意図に近い。

• RMSエネルギー（音量）を使う
  オンセット近傍のRMSが高いときだけ同時押し許可。
  → “大きい音” を反映しやすい。

仕上げの抑制ルール（併用推奨）

• クールダウン: 同時押し発生後 200〜300ms は同時押し禁止
• 最大数: easy=1, normal=2, hard=2〜3
• 確率: 強度条件を満たしても 10〜30% で間引く

質問

• 実装に進めるなら、どの軸を使うのがいいですか？
  1. 密度ベース
  2. onset強度
  3. RMS音量
  4. 併用（強度 + クールダウン）

方針が決まれば、analyzer.py に強度を出す処理を追加して chart_builder.py で同時押し判定に使う形にできます。

オンセット強度 + RMS音量の併用で、同時押しの許可条件を追加しました。
静かなパートは単押しになり、強いピークや大きい音量のときだけ同時押しが出るようにしています。

その理解で合っています。BPMだけでは“位相（1拍目の位置）”が決まらないので、
グリッドに沿ってクォンタイズするなら 拍の開始位置（オフセット） を推定する工程が必要です。

おすすめの流れ

• BPM取得（今のまま）
• 拍位置の推定
  • librosa.beat.beat_track で beat frames を取得
  • 最初の拍を「グリッドの起点（0拍目）」にする
• グリッド生成
  • 取得した BPM と拍起点から、4分/8分/16分のグリッドを展開
• クォンタイズ
  • 1/16グリッドに**±許容幅内だけ**吸着

特に「0:00:00が1拍目と限らない」点は重要で、
グリッドの位相合わせがないと “ズレたままの正確なクォンタイズ” になります。

もし進めるなら、

• beat positions を使って 位相を推定
• その位相基準で 許容幅付きクォンタイズ
  を入れると自然に仕上がります。

必要なら、その実装を analyzer.py / chart_builder.py に組み込む案も出します。

結論から言うと：

• beat_track の結果は「拍が検出できるところ」から始まるので、
  先頭がボーカルソロだけだと 最初の beat frame が数十秒後になることは普通にあります。

その場合どうなるか？

• そのまま使うと、冒頭は“位相が分からない”状態になります。
  つまり、厳密な意味でのグリッド基準クォンタイズは 適用できない（またはズレたまま適用してしまう）ので、
  冒頭はクォンタイズを弱く／しないのが自然です。

対処パターン（おすすめ順）

1. 最初の beat から前後にグリッドを“外挿”する

   • 最初の beat 時刻を起点に、BPM間隔で 過去方向にグリッドを展開
   • これで冒頭にも位相を与えられる
   • ただし BPMが正しいことが前提（誤差があるとズレる）

2. 冒頭はクォンタイズを弱く／無効にする

   • 例：最初の beat より前は “許容幅を狭く” する or “クォンタイズしない”
   • ボーカルの自然な揺れを残せるメリットもある

3. beat_track 以外の“位相推定”も使う

   • onset strengthの周期性や、セクション全体のスペクトル変化から位相推定
   • 実装は少し重いが、冒頭の位相推定が改善される

要するに、**「beat が数十秒後に出る → 冒頭は位相不明」**が起きます。
この場合は

• 外挿してクォンタイズ
• or 冒頭はクォンタイズしない／弱める

のどちらかが実用的です。

もし実装するなら、

• 最初の beat 時刻を起点に過去へグリッド展開
• 前半はクォンタイズ許容幅を小さく

という“保険付き”のやり方が安定します。

はい、その理解で合っています。

• beat_track が返す 最初の beat 時刻を起点にグリッドを作る
• その時刻以降だけノートをグリッドに吸着
• それより前のオンセットは クォンタイズしない

この方針なら複雑化せず、冒頭のボーカルソロも自然に残せます。
実装まで進めますか？