8bitゲーム音楽を探していると、.nsf という拡張子のファイルに行き当たります。数十曲入って数十KBしかない。MP3では絶対にありえないサイズです。
理由は単純で、NSFは音声を保存していないからです。中に入っているのは、音を鳴らすためのプログラムそのもの。この記事では、その仕組みと、NSFで何ができて何ができないのかを整理します。
📌 この記事の3行まとめ
① NSFは録音でも楽譜でもなく、6502のプログラム＋データ。再生にはCPUと音源チップのエミュレーションが要る
② 1ファイルに複数曲が入る。曲の切り替えは「何曲目を鳴らすか」をプログラムに指示している
③ NSFeは同じ仕組みに曲名・演奏時間・フェード情報などのメタデータを足した拡張形式
NSFは、3つのタイプのどれでもない
音楽ファイルは、おおまかに3つに分けられます。
| タイプ | 中身 | 例 |
|---|---|---|
| 波形を保存 | 音そのものの記録 | WAV、MP3、FLAC |
| 演奏指示を保存 | 「いつ・どの音を・どの強さで」 | MIDI |
| 音を作る手順ごと保存 | プログラム＋データ | NSF、GBS、SPC、VGM |
NSFは3番目です。しかも同じ3番目のVGMとも性格が違います。VGMは「音源チップのレジスタに、いつ何を書いたか」のログで、再生には音源チップのエミュレーションだけがあれば足ります。
NSFは違います。6502 CPUのプログラムがそのまま入っていて、それを実行しないと音が出ません。当時のゲームで音楽を鳴らしていたサウンドドライバごと、ファイルに詰め込んである形です。
だから、NSFの再生には最低2つが必要です。
- 6502 CPUのエミュレーション（プログラムを実行する）
- APU（音源チップ）のエミュレーション（プログラムが書いたレジスタを音にする）
数十KBで数十曲鳴るのは、音を「記録」せず「毎回その場で計算して鳴らしている」からです。
NSFファイルの構造
NSFは128バイトのヘッダから始まります。主な項目は次のとおりです。
| 項目 | 役割 |
|---|---|
| マジックナンバー | NESM で始まる識別子 |
| 総曲数 / 開始曲 | 1ファイルに何曲入っていて、既定でどれを鳴らすか |
| ロードアドレス | プログラムをメモリのどこへ置くか |
| INITアドレス | 「n曲目を準備せよ」と呼ばれる入口 |
| PLAYアドレス | 1フレームごとに呼ばれる入口 |
| 曲名 / 作者 / 著作権 | 32バイトずつの文字列 |
| 再生速度 | NTSC / PALのフレーム間隔 |
| バンク切替 | 8KB単位のバンク割り当て |
| 拡張音源フラグ | VRC6、VRC7、FDS、MMC5、Namco 163、Sunsoft 5Bなど |
ヘッダの後ろは、まるごとプログラムとデータです。
再生側の動きはこうです。まずINITアドレスを「何曲目を鳴らすか」を指定して呼び、次にPLAYアドレスを1フレームに1回（NTSCなら毎秒約60回）呼び続けます。曲の進行は、このPLAYルーチンが自分で管理します。
💡 なぜフレーム単位なのか
当時のゲームは、画面の描画割り込み（VBlank）に合わせて処理を進めていました。音楽もその割り込みの中で1ステップずつ進みます。8bitゲーム音楽のテンポが「1フレーム＝1/60秒」の倍数に張りつきがちなのは、この仕組みが理由です。
拡張音源というフラグ
日本国内向けのファミコンには、カートリッジ側に追加の音源チップを載せられる仕組みがありました。NSFのヘッダには、その拡張音源を使うかどうかのフラグがあります。
| 拡張音源 | 追加される音 |
|---|---|
| VRC6 | 矩形波2＋ノコギリ波1 |
| VRC7 | FM音源6ch |
| FDS | 波形メモリ1ch |
| MMC5 | 矩形波2＋PCM |
| Namco 163 | 波形メモリ最大8ch |
| Sunsoft 5B | 矩形波3 |
再生側がこのフラグに対応していないと、拡張音源のチャンネルは鳴りません。「同じNSFなのに、プレイヤーによって音が薄い」ことがあるのは、たいていこれが原因です。拡張音源についてはファミコンの音源の仕組みでも扱っています。
NSFeは何を足したのか
NSFの弱点は、メタデータが貧弱なことでした。ヘッダに入るのはファイル全体の曲名・作者・著作権だけで、個々の曲名も演奏時間も入りません。数十曲入ったファイルを開いても、リストは「1、2、3……」と番号が並ぶだけです。
NSFeはこれをチャンク構造に作り替えた拡張形式です。追加されたのは主に次の情報です。
- 曲ごとのタイトル
- 曲ごとの演奏時間とフェードアウト時間
- 曲ごとの作者情報
- プレイリスト（鳴らす順番と、隠し曲の除外）
- 各曲の解説テキスト
音を鳴らす仕組み自体はNSFと同じです。再生の中身は変えず、扱いやすさだけを足したのがNSFeだと考えると分かりやすくなります。
「聴ける」と「編集できる」の間にある壁
ここが、NSFを扱ううえでいちばん誤解されやすいところです。
NSFを開いて曲が鳴ったとしても、そのファイルの中に音符の並びは存在しません。あるのは6502のコードと、そのコードだけが読み方を知っているデータテーブルです。テーブルの形式はゲームごと、サウンドドライバごとにバラバラで、共通仕様はありません。
つまり、NSFを「開いて音符を編集する」には、ファイルを解析するのではなく、実際に実行して、その結果を観測するしかありません。
具体的には、こういう手順になります。
- NSFの曲をエミュレータで最初から再生する
- プログラムがAPUのレジスタへ書き込む内容を、1フレームずつ記録する
- 記録したレジスタ列から、音程・発音タイミング・音量・デューティ比・ノイズ周期を復元する
- 復元した値を、5チャンネル分のノートとして並べ直す
「解析」ではなく「再エミュレーションによる観測」です。だからこの方式には、原理的な限界もあります。
⚠ 復元で戻らないもの
元の曲がどんな構造（パターン、ループ、マクロ、アルペジオのテーブル）で書かれていたかは戻りません。復元できるのは「結果として鳴った音」であって、「作曲者が書いた譜面」ではありません。同じ音でも、元データは何通りにも書けます。
それでも、耳コピの下敷きとしては十分に実用的です。ピッチとタイミングが取れているだけで、聴き取りの作業は大きく減ります。
どんなときにNSFを使うか
| やりたいこと | NSFは向くか |
|---|---|
| 8bitゲーム音楽を小さいファイルで保存・再生したい | ◎ 数十KBで数十曲 |
| 実機やハードウェアで自作曲を鳴らしたい | ◎ 標準的なプレイヤーと実機が対応 |
| 他のDAWへ音符データとして持っていきたい | △ 一度ノートへ復元する工程が要る |
| 拡張音源を含む曲を配布したい | ○ 再生側の対応状況に注意 |
| ステレオや高音質で配布したい | ✕ WAVやMP3を使う |
他の形式との関係はVGM・NSF・SPC・MIDIの違いに整理しています。
権利について
NSFファイルの多くは、市販ゲームから抽出されたものです。ファイル形式が公開されていることと、中身の音楽が自由に使えることは別です。
- 配布・公開されているNSFの多くは、第三者の著作物を含みます
- 読み込み・変換・再配布は、権利をお持ちの範囲で行ってください
- 自作曲をNSFとして書き出して配布するのは問題ありません
実際に触ってみるには
当社が開発した M-NES: 8bitチップチューン作曲 は、この記事で説明した流れをそのままアプリにしたものです。
- 原曲再生：内蔵の6502 CPU＋APUエミュレーションで、NSF / NSFeをそのまま鳴らす
- 曲リスト：複数曲入りファイルから1曲ずつ選択。NSFeなら曲名と演奏時間も表示
- 取り込み：選んだ曲を再エミュレートし、レジスタ書き込みを追跡して5トラックのノートへ復元
- 書き出し：独自の6502ドライバを埋め込んだNSF / NSFeと、48kHzモノラルWAV
8bit音源そのものの仕組みはファミコンの音源の仕組みに、最初の1曲の組み立て方はチップチューンの作り方入門にまとめています。
