Music preserved as code, not as audio

An NSF file contains the player routine and the data, so it is executed rather than decoded. That is why the format survives emulator changes.

An NSF file doesn't play back — it runs

There is a quiet distinction at the heart of how NES music gets preserved, and it matters more than it first appears. An MP3 is decoded: the file contains audio samples that a player reconstructs into waveforms. An NSF — the NES Sound Format — is executed: the file contains the actual player routine and register-write data from the original game, and when it runs, it drives the sound hardware directly, exactly as the game would have done. The output is not stored in the file. The output is generated fresh, every time, by code that talks to the chip.

That single design decision is why NSF files from the 1990s remain musically authoritative today, while contemporary audio rips — and there were many, captured to cassette, DAT or early CD-Rs — can only approximate what the hardware sounded like in the room where they were recorded.

What the file actually contains

NSF is a thin wrapper around a block of 6502 machine code and a small header. The header carries metadata — song count, title, composer, playback speed, and crucially a set of flags indicating whether the cartridge used expansion audio chips — but the body is a binary routine lifted almost directly from the game's own ROM. A host player calls that routine at a fixed tick rate, typically sixty times per second for NTSC hardware, and the routine writes values into the 2A03's registers on each call, advancing envelopes, changing pitches, triggering new notes. It is not a description of the music. It is the music engine, extracted.

This is different from what a MOD or XM tracker file contains. Those formats describe patterns, instruments and sequences in a portable, player-agnostic way. An NSF delegates nothing to the player except the timing of the interrupt — it handles its own sequencing, its own envelope logic, its own table lookups. The player is a very thin shell around the chip.

The format was developed in the late 1990s within the growing community of emulator writers and ROM researchers, and it spread as NES emulation matured. Because the 2A03's register map is fully documented in the NesDev wiki, a faithful emulator can replicate every register write the routine issues, and the audio it generates will match original hardware as closely as the emulator's underlying synthesis model allows. The NSF does not become outdated as emulators improve — it keeps producing better output as the emulator catches up to the hardware, because the code inside it never changes.

Why accuracy is structural, not incidental

This is the counterintuitive thing about NSF preservation: the file's fidelity improves over time without the file itself being touched. Early 2A03 emulators modelled the pulse channels simply, approximated the non-linear mixer behaviour, and dropped details like the DPCM channel's tendency to steal CPU cycles mid-routine. Each of those was a known inaccuracy, and as emulator authors refined their models, the same NSF files began to sound progressively more like real hardware. The routine inside the NSF was already issuing the right register writes. The emulator just needed to respond to them correctly.

NSF is a thin wrapper around a block of 6502 machine code and a small header.

The contrast with audio rips is stark. A WAV file recorded through a console in 1993 carries exactly the fidelity of that recording chain — the capacitors on that particular unit, the cable, the ADC — and no more. It cannot benefit from a better understanding of the chip published in 2011. An NSF, running in a 2025 emulator with cycle-accurate APU timing, is closer to source than any period recording could be.

That is why the NSF format, and the later NSFe extension that added proper metadata fields including per-track durations and a copyright notice field, became the archival standard rather than a curiosity. NSFe also formally accommodates the expansion chips — Konami's VRC6 and VRC7, Sunsoft's 5B, Namco's 163, and the others — by extending the flag byte into a richer identifier block, so a single format handles the whole cartridge-era output.

Composers, whether they knew it or not

None of the composers working at Famicom and NES-era Konami, Nintendo, Sunsoft or Namco ever authored an NSF file. Koji Kondo wrote for the Super Mario Bros. engine; Hirokazu Tanaka wrote for Metroid's. What they produced was 6502 code interleaved with music data — a player routine inseparable from the score. The NSF format captures exactly that unit: routine and data together, the minimum coherent piece.

This means the preserved form of their work is closer to their actual output than a transcription or an audio recording. A transcription is an interpretation. An audio recording is a snapshot. An NSF is the code. When Junko Ozawa's Famicom compositions run inside an NSF player, the arithmetic she depended on — the way the hardware's envelope counter reaches zero and silences a note — is still the arithmetic running on the emulated register set. The music's behaviour, not just its sound, is preserved.

The tracker scene, which still writes original music for the 2A03, treats this as a given. Tools like FamiTracker and its 0CC fork export NSF directly, which means contemporary compositions enter the same archival format as original cartridge code. A piece written in 2023 and a player routine extracted from a 1987 Famicom game sit in the same format, executed by the same mechanism. The format makes no distinction between historical and contemporary, only between code that addresses the chip and code that doesn't.

The limits the format inherits

An NSF is as accurate as the code inside it — and that code was sometimes wrong. Some extraction processes were imperfect; early rips occasionally missed bank-switching calls or initialisation sequences, producing a file that ran but played incorrectly. The community has corrected most of these over the years, and the primary repositories have been updated as better rips became available. The format itself is not the problem; a bad rip is a bad rip, correctable.

What the format cannot do is represent music that was never discrete from the game engine. Some compositions used hardware timer values that depended on frame-timing events triggered by game logic — defeated enemies, screen transitions, items collected — and extracting the sound routine cleanly left those dependencies dangling. These pieces exist in NSF collections in simplified form, stripped of their conditional behaviour. The archive is near-complete but not total, and no format revision will recover what was structurally entangled with the game itself.

That is a small residue of a mostly solved problem. For the vast majority of the 2A03 repertoire, the NSF format has done something that audio formats cannot: it kept the music as a process rather than a recording, and it let that process get better.