Skip to content

MIR の全体像

MIR は Music Information Retrieval(音楽情報検索)の略で、音を音楽的な答えに変える音声解析の領域です。たとえば、テンポ、ビート位置、キー、コード、ピッチ、音色、構造を扱います。

このページは地図です。ドキュメント全体で出会う用語をまとめ、それらがどう積み上がっているかを示すので、どの機能をどこで呼べばよいかが分かります。

ここで挙げる用語をまとめるのには理由があります。これらは単独の機能名ではなく、ほぼすべての MIR タスクが同じ時間-周波数の土台の上に立っています。その共通の土台を一度理解すれば、個々の機能は無関係な長いリストには見えなくなります。

初めてなら、リファレンスではなく見取り図として読む

このページは各要素がどう関係するかを説明します。呼び出しシグネチャは JavaScript APIPython API を、どう計算されるかDSP 実装解説 を参照してください。

共通のパイプライン

MIR 機能の多くは、少数の中間表現から導かれます。これらを利用者が手で組む必要はほとんどなく、libsonare が内部で計算します。それでも流れを知っておくと、なぜ多くの機能が nFfthopLength のようなパラメータを共有するのかが分かります。

共通の解析パイプライン
波形STFT / スペクトログラムメルスペクトログラムクロマオンセット強度MFCC(音色)キーコードBPM / ビートセクションHPSS
ひとつの STFT がすべての分岐に供給されます。セクション解析はリズムではなく音色とハーモニーの課題で、その境界はメル/MFCC とクロマの分岐から出ます。オンセット包絡線は使いません。

中間表現の共有が効くのは、曲全体を一度に解析する場合だけです。analyzeMusicAnalyzer)は STFT とその派生表現を一度だけ計算し、BPM・キー・コード・セクションの各結果で使い回します。

単機能のヘルパーは中間表現を共有しない

detectBpmdetectKeydetectChords、セクション系のヘルパーは、いずれも生のサンプルから処理をやり直します。4 つを続けて呼べば STFT が 4 回、クロマグラムが 2 回、オンセット包絡線がもう 1 回計算されます。音声をキーにしたキャッシュはありません。同じ曲について複数の答えが欲しい場合は、単機能ヘルパーを並べるのではなく、曲全体の解析を 1 回呼んでください。

どの問いに、どの機能か

答えたいこと使うもの土台
どのくらい速い? ビートはどこ?BPM / ビートトラッキングオンセット強度
何のキー?キー検出クロマ
何のコードが鳴っている?コード認識クロマ
サビはどこから始まる?セクション解析MFCC(音色)+クロマ(ハーモニー)+エネルギー
メロディの音は?ピッチ / メロディ追跡ピッチ追跡(後述の「分離とピッチ」を参照)
どんな音色に聞こえる?MFCCメルスペクトログラム
ドラムを他から分離できる?HPSSスペクトログラムの構造
時間ごとの生の周波数成分は?STFT / スペクトログラム波形
録音空間はどんな響きか?ルーム音響解析インパルス応答(IR)の減衰、またはブラインド自由減衰推定

タイミング: BPM、ビート、オンセット、セクション

タイミング系の機能は、段階的に積み上がっています。

機能答える問い
オンセット検出ノート、ドラム、子音などがどこで始まるか。オンセット強度の包絡線に立つスパイクです。
BPMオンセットがどれくらい周期的か。
ビートトラッキングタイムライン上の拍がどこにあるか。
セクション解析イントロ、A メロ、サビ、ブレイクのような長めのスパンがどこで始まり終わるか。上の 3 行と違い、この機能はオンセット包絡線を読みません。境界は音色(MFCC)とハーモニー(クロマ)から出ます。

オンセットがリズム系の起点

BPM、ビート、テンポグラムはすべて同じオンセット強度の包絡線から始まります。BPM 推定の背後にある時間 × テンポの図が欲しい場合は、リアルタイムとストリーミング のテンポグラム系を参照してください。

DETECTOR · ONSET / BEATIDLE
オンセットとビート — 打点から拍へ

オンセット検出は音の打点をすべて捉え、ビート追跡はそこから手拍子を打つような一定の拍を導き出す。表示を切り替え、再生するとプレイヘッドが到達するたびにマーカーが光る。

検出

ハーモニー: キー、コード、クロマ

クロマは周波数成分を 12 のピッチクラス(C・C♯・…・B)に畳み込み、同じ音のすべてのオクターブをまとめます。これがハーモニーの自然な土台になります — キー検出は全体のクロマ分布から調性中心を推定し、コード認識はフレームごとにその瞬間のハーモニーを推定します。

クロマはオクターブと音色の細部を捨ててハーモニーの明瞭さを得る

オクターブをまとめることこそが、クロマをキー/コード解析に向いたものにし — そして同時に、オクターブやスペクトル形状が重要なメロディや音色には不向きにします。表現は問いに合わせて選んでください。

CHROMA · PITCH CLASSIDLE
クロマグラム — ハーモニーを12ビンに畳む

すべての周波数を12のピッチクラスのどれかへ畳み込むため、オクターブは忘れられ、ハーモニーだけが残ります。このクリップは C–Am–F–G を循環します。コードが変わるたびに点灯する行が移るのを見て、再生して進行を追ってください。

スペクトル: FFT、STFT、スペクトログラム

FFT(高速フーリエ変換)は DFT(離散フーリエ変換)の高速実装で、サンプルブロックを周波数成分に変換します。

STFT(短時間フーリエ変換)はそれを短く重なり合うウィンドウで繰り返し、周波数成分を時間方向にも追えるようにします。

スペクトログラムはその可視化です。横軸が時間、縦軸が周波数、明るさが強度を表します。

どこでも繰り返し出てくるパラメータが 2 つあります。

  • nFft はウィンドウサイズです。大きいほど周波数分解能は細かくなりますが、時間はぼやけます。
  • hopLength はウィンドウ間のステップです。小さいほどフレームが増え、動きが滑らかになります。

周波数分解能と時間分解能のトレードオフは、libsonare 固有の癖ではなく本質的なものです。

STFT · SPECTRALIDLE
STFT — 時間と周波数を同時に見る

220 Hz から 4 kHz へ上昇するトーン。各列が1つの短時間スペクトルで、明るいほどその周波数のエネルギーが大きい。

知覚特徴量: メル、MFCC、CQT、VQT

メルスペクトログラムは、周波数分解能を人間の聴覚に合わせてひずませます。低域は細かく、高域は粗く扱います。

MFCC(メル周波数ケプストラム係数)はコンパクトな「音色の指紋」です。メルスペクトログラムを取り、その大きさを対数で圧縮し、各フレームを少数の数値にまとめます。これらの数値は、正確なピッチではなく全体的なスペクトル形状を捉えます。

CQT(定 Q 変換)と VQT(可変 Q 変換)は、音楽的に等間隔なビンを使います。ビンは幾何級数的に並び、1 オクターブあたりの本数は binsPerOctave で決まります。既定は 12(半音ごと)ですが、クロマやチューニングの用途では 24 や 36 もよく使われます。Hz 等間隔より、ピッチ関係そのものが重要な場面で活きます。

これらの変換は、プレビューやデバッグのために逆向きにも実行できます — 逆変換特徴量 を参照してください。

分離とピッチ: HPSS とピッチ推定

HPSS は Harmonic/Percussive Source Separation、つまり倍音成分と打撃成分の分離です。スペクトログラム上の形の違いを使って、持続的なピッチ素材と過渡的な打撃を分けます。

成分スペクトログラム上の形
倍音成分主に水平の線
打撃成分主に垂直の線

先に分離しておくと、ドラムとピッチ楽器が互いの解析を乱しにくくなり、下流タスクの精度が上がることが多いです。

HPSS · FULL MIXIDLE
HPSS — 旋律と打楽器を分ける

スペクトログラムでは、持続する音程の音は横方向のすじを、打楽器の打点は縦方向のすじを描きます。HPSS はまさにそれを利用します。時間方向のメディアンフィルタは横(倍音成分)を、周波数方向のメディアンフィルタは縦(打撃成分)を残します。表示を切り替えると、Full は両方、Harmonic はすじ(和音とベース、打楽器なし)、Percussive は縦すじ(ドラム、旋律なし)になります。再生すると各レイヤーを単独で聴けます。先に分離しておくと、後段のビート追跡やピッチ追跡がきれいになることがよくあります。

レイヤー

ピッチ推定は基本周波数を追跡します。基本周波数とは、倍音列のいちばん下の成分、言い換えれば波形が繰り返す周期の逆数です。最も強い周波数とは限りません。明るい金管の音や小型スピーカーで鳴るベースでは上の倍音のほうが優勢ですし、基本周波数の成分がスペクトルにまったく無くても、人はその高さを聞き取ります。だからこそ推定器は、最大ピークではなく波形の周期から F0 を求めます。メロディ、ボーカル、単音楽器、チューニング確認、採譜系のワークフローで使えます。

隣接領域: ルーム音響

ルーム音響解析は MIR に隣接する領域です。音符、リズム、楽曲構成ではなく、録音に含まれる空間の性質を記述します。

クリーンなインパルス応答が手元にある場合は、直接 IR 解析を使います。この経路では RT60(残響が 60 dB 減衰するまでの時間)、EDT、C50、C80、D50、バンド別減衰を測定します。

通常録音しかない場合は、ブラインド音響推定を使います。この経路は残響の手がかりを信頼度つきで返します。録音の中に自由減衰の証拠が乏しい、あるいはまったくないこともあるためです。詳しくは ルーム音響解析 を参照してください。

実装メモ

libsonare はブラウザ(WASM)、JavaScript、Python、ネイティブバインディング、CLI、C++ API のいずれからも MIR 関連機能を呼び出せます。

多くの機能は STFT、クロマ、スペクトルエネルギー曲線といった中間表現を共有します。ただしこの共有は MusicAnalyzer の内部に閉じています。曲全体の analyze は各中間表現を一度だけ計算し、BPM、キー、コード、セクションの結果で使い回します。単機能のエントリポイントは呼び出しをまたぐキャッシュを持たないため、それぞれが必要なものをサンプルから作り直します。

ブラウザデモは対話的な利用を前提にしています。ただし、それぞれが見せている役割は少し違います。

デモ主な役割
楽曲分析スタジオファイル全体の MIR。BPM、キー、コード、セクションなどをまとめて解析します。
リアルタイム系の表示StreamAnalyzer 経由で、BPM/キー/コードを時間とともに更新しながら推定します。
マスタリングスタジオラウドネス計測、リファレンス比較、レポート出力など、計測寄りの API を扱います。

同じライブラリの上に役割の違うデモを載せることで、解析と仕上げの両方で何を再利用できるかを示しています。

関連: イントロダクションオーディオ基礎JavaScript APIルーム音響解析DSP 実装解説librosa 互換性