レトロゲーム音楽を扱っていると、見慣れない拡張子に出会います。.vgm、.nsf、.spc、.gbs、.mod——そして .mid。
これらは「どれも古いゲーム音楽のファイル」に見えますが、記録している中身がまったく違います。違いを理解すると、「なぜこの形式は編集できないのか」「なぜMIDIだと音が変わるのか」が一気に腑に落ちます。
📌 この記事の3行まとめ
① 形式は大きく3種類。①音そのもの ②演奏の命令 ③演奏プログラムごと
② チップチューンの形式が原曲どおりに鳴るのは、チップへの命令や状態を記録しているから
③ MIDIだけは音を持たない。再生環境が変われば音も変わる
3つのタイプに分けて理解する
まず大枠です。すべてのファイル形式は、次の3タイプのどれかに当てはまります。
タイプ①：音の波形そのものを記録するWAV、MP3、FLAC、OGGなど。再生機器が何であれ同じ音が出ます。その代わり、後から一部の楽器だけ差し替えるようなことはできません。
タイプ②：演奏の命令だけを記録するMIDIが代表です。「この高さの音を、この長さで鳴らせ」という指示だけが入っており、音そのものは入っていません。だから再生環境（音源）が変われば音も変わります。
タイプ③：チップへの命令、または演奏プログラムごと記録するVGM、NSF、SPC、GBSなど、チップチューン系の形式です。再生にはその音源チップのエミュレーションが必要ですが、その代わり当時の実機と同じ音が再現できます。
チップチューンの形式が「原曲そのままの音」で鳴るのは、③だからです。②のMIDIでは、どうしても再現に限界があります。
形式ごとの比較
| 形式 | 対象 | 中身 | 再生に必要なもの | 編集のしやすさ |
|---|---|---|---|---|
| VGM | 各種音源チップ全般 | チップへのレジスタ書き込みログ＋タイミング | 対応チップのエミュレーション | 中（ログの編集が必要） |
| NSF | ファミコン | 6502のプログラム＋データ | CPU＋APUのエミュレーション | 低（プログラムの解析が必要） |
| SPC | スーパーファミコン | 音源側メモリ64KBと各種レジスタの状態スナップショット | SPC700＋DSPのエミュレーション | 低（状態から復元） |
| GBS | ゲームボーイ | プログラム＋データ | CPU＋APUのエミュレーション | 低 |
| MOD / XM / IT | トラッカー全般 | サンプル＋譜面（パターン） | トラッカー、または対応プレイヤー | 高（譜面もサンプルも編集可） |
| MIDI | 音源非依存 | ノート・音量・音色番号などの演奏イベント | 何らかの音源 | 高 |
| WAV / MP3 | 汎用 | 音の波形 | 一般的なプレイヤー | 低（ミックス済み） |
VGM：レジスタ書き込みのログ
VGM（Video Game Music）は、音源チップに対して行われたレジスタ書き込みを、時間情報と一緒に記録した形式です。
イメージとしては、演奏の「操作ログ」です。「0.016秒後にチャンネル1の周波数レジスタへこの値を書き込め」「その0.016秒後に音量レジスタへこれを書け」——という命令が延々と並んでいます。
利点は明確です。チップの種類を問わず、同じ仕組みで扱えること。ファミコン系、メガドライブ系、PC-98系、アーケード系まで、多数の音源チップに対応しています。再生側は、指定されたチップをエミュレートして、記録どおりに書き込むだけです。
.vgz は、VGMをgzipで圧縮したものです。中身は同じです。
一方で、編集は少し面倒です。ログはあくまでレジスタ書き込みの列なので、そのままでは「どこからどこまでが1つの音符か」が分かりません。書き込みを解析して、ノート単位の情報へ復元する処理が必要になります。
NSF・GBS：演奏プログラムごと保存する
NSF（NES Sound Format）は、ファミコンのサウンドドライバのプログラムそのものを含んでいます。6502のコードとデータが入っており、再生側はCPUとAPUをエミュレートしてそれを実行します。
つまり、NSFの再生とは当時のゲームのサウンド部分だけを動かしているのと同じです。だから、曲の切り替えや、ゲームによって異なるドライバの挙動まで再現されます。
GBS（Game Boy Sound System）も同じ考え方で、ゲームボーイ用です。
この方式の弱点は、編集がほぼ不可能なことです。中身はプログラムなので、譜面として取り出すにはドライバの実装を解析する必要があります。ゲームごとにドライバが違うため、汎用的な変換ツールを作るのは非常に困難です。
SPC：メモリの「スナップショット」
SPCは少し変わっています。曲データではなく、音源側の状態を丸ごと保存したものです。
具体的には、スーパーファミコンの音声処理を担うSPC700 CPU、そのメモリ64KB、DSPのレジスタ、タイマーの状態——これらを、曲が鳴っている瞬間にそのまま切り取ったものです。再生側はこの状態を復元して、そこから実行を続けます。
だからファイルサイズがほぼ一定（64KB＋α）で、曲の長さに関係ありません。メモリの中身がすべてだからです。
編集の難しさはNSFと同じ理由ですが、SPCには興味深い解決策があります。曲を再生しながら、DSPに対して行われたレジスタ書き込みを採取するという方法です。
- どのボイスが、いつ、どの音程で発音したか
- どのサンプルが使われたか
- 音量とピッチがどう変化したか
これらは、ドライバの実装を解読しなくても、書き込みを見ているだけで分かります。ゲームごとに異なるサウンドドライバの仕様に依存せず、共通の形式へ落とし込めるわけです。当社の ChipWave が採用しているのもこの方式で、権利をお持ちのSPCから8トラックのピアノロールへ変換できます。
MOD系：サンプルと譜面が同居する
MOD、XM、S3M、IT といったトラッカー用の形式は、サンプル（音の素材）と譜面（パターン）を1つのファイルに入れています。
これが非常に扱いやすい構造です。譜面を編集すれば曲が変わり、サンプルを差し替えれば音色が変わる。どちらも独立して触れます。
厳密には「音源チップの再現」ではないため、狭義のチップチューンとは区別されることもありますが、制作の自由度では最も高い形式です。デモシーンやトラッカー文化はここから育ちました。
MIDI：音を持たないからこそ、汎用的
MIDIは、演奏イベントだけを記録します。「チャンネル1で、C4の音を、ベロシティ100で、この時刻に鳴らせ」という指示の列です。
音そのものは一切入っていません。だから、
- 同じMIDIでも、再生する音源が違えば音が変わります
- ファイルサイズが極端に小さい
- 譜面としてそのまま編集できる
「レトロゲーム音楽のMIDIファイル」を再生して、なんとなく違う音がするのは、これが理由です。原曲は音源チップ固有の音色で鳴っていたのに、MIDI再生では手持ちの音源の音色に置き換わってしまうためです。
逆に言えば、MIDIは作曲の中間形式として優れています。MIDIキーボードで打ち込んで、あとから音源を差し替える——という流れは、現代のDTMの標準的なやり方です。
どの形式を使うべきか
目的から逆引きすると、次のようになります。
| やりたいこと | 適した形式 |
|---|---|
| 実機と同じ音で配布したい | VGM（対応チップの場合） |
| SNSやサイトで手軽に聴かせたい | MP3 / OGG（レンダリング済み） |
| 他のDAWへ持っていきたい | MIDI（音色は別途） |
| 譜面と音色を両方あとで直したい | MOD系、または制作ツールのプロジェクトファイル |
| ゲームに組み込みたい | ループ対応の OGG、または各エンジンの形式 |
制作中はプロジェクトファイル、配布時は用途に応じて書き出す——これが基本方針です。ゲームに組み込む場合はループの扱いが重要になるので、ゲームBGMのループの作り方もあわせてご覧ください。
MegaTune・ChipWaveでの扱い
当社の2本のアプリは、それぞれ異なる形式に対応しています。
- VGM / VGZの読み込みと、ピアノロール上でのノート単位の編集
- VGM 1.70での書き出し（実機準拠）
- DACのPCM素材、GD3曲名タグの取り込み
- Z80 RAMとROMの見積り表示
- プロジェクトは
.mdseq（ポータブルなJSON形式）で保存 - MIDIキーボードからの入力にも対応
- 権利をお持ちのSPCスナップショットの解析。DSPへのレジスタ書き込みを採取して8トラックのピアノロールへ変換
- WAV / AIFF / CAFの読み込みと、BRRへの自動変換
.brrの直接読み込みと書き出し
「読み込めるだけ」で終わらせず、編集して書き戻せるところまでを制作フローに含めています。
機種ごとの音源の違いはチップチューン完全ガイドに、各チップの仕組みはファミコン・ゲームボーイ・FM音源・スーパーファミコンの各記事にまとめています。
