soundlog
soundlog — builder, parser and stream-processor for retro sound-chip register-write logs
soundlog is a small crate for building and parsing register-write
logs for retro sound chips. It currently supports the VGM
(Video Game Music) file format.
Key features:
- Builder API to construct VGM documents programmatically.
- Parser support to read VGM data into a structured
VgmDocument. - Type-safe APIs: chip specifications and VGM commands are modeled as Rust types to help prevent invalid register writes at compile time.
- Stream processing:
VgmStreamprovides a low-memory, iterator-based processor that can accept either chunked binary input (viapush_chunk) or a pre-parsedVgmDocument(viafrom_document) and yields parsedVgmCommandvalues as they become available. - Callback-based processing:
VgmCallbackStreamwrapsVgmStreamto provide callback registration for chip register writes with automatic state tracking and event detection (KeyOn, KeyOff, ToneChange). - Memory limits: Configurable limits for data block accumulation (default 32 MiB) and parsing buffer size (default 64 MiB) prevent unbounded memory growth from untrusted input.
- Chip state tracking: Monitor register writes to track key on/off events and extract tone information (frequency, pitch) from sound chip registers in real-time.
Quick start — building a VGM player
use ;
use ;
use ;
use StreamResult;
// Load a .vgm file from disk
// let vgm_bytes: Vec<u8> =
// std::fs::read(PathBuf::from("song.vgm")).expect("failed to read file");
let vgm_bytes = Vec::new;
# // Build a minimal VGM in memory (or load a .vgm file as Vec<u8>)
# let mut builder = new;
# builder.add_vgm_command;
# let vgm_bytes: = builder.finalize.into;
// Parse the header to obtain chip configuration
let header = from_bytes.expect;
let instances = header.chip_instances;
// Create a callback stream directly from the raw bytes
let mut callback_stream = from_vgm.expect;
// play once; omit for infinite loop
callback_stream.set_loop_count;
// 2-second fadeout at 44.1 kHz after final loop
callback_stream.set_fadeout_samples;
// Enable state tracking for every chip registered in the VGM header.
// Only chips that are actually enabled (non-zero clock) in the header are tracked.
callback_stream.track_chips;
// Register a callback for YM2612 register writes.
// DAC Stream and DataBlock details are handled internally by VgmCallbackStream —
// just write the register values directly to your sound chip hardware here.
callback_stream.on_write;
// Drive the stream until EndOfStream.
// The stream loops up to the configured loop count, then continues for the
// fadeout period (if set) before ending.
for result in &mut callback_stream
VgmStream overview
VgmStream is designed for streaming/real-time consumption of VGM data:
- It yields
VgmCommandvalues wrapped in stream results as it parses input and as it generates writes from DAC streams. - It understands DAC stream control commands (e.g.
SetupStreamControl,SetStreamData,SetStreamFrequency,StartStream,StartStreamFastCall,StopStream) and will expand stream-generated writes into the output timeline at the correct sample positions. - It also supports YM2612 direct DAC writes and expands them into corresponding
Ym2612Port0Address2AWriteAndWaitN,SeekOffsetcommands on the stream timeline. - While processing
Wait*commands, the internal scheduler computes the outputs of the DAC stream (including YM2612Ym2612Port0Address2AWriteAndWaitN) and normalises the timeline into register-write commands andWaitSamples. This process converts DAC stream events into explicit write commands and normalised waits, thereby preserving per-sample timing when multiple streams are active concurrently. - DataBlock compression (e.g. bit-packed and DPCM streams) is automatically decompressed and expanded by the crate so compressed streams and their associated decompression tables are applied transparently.
- Memory limits are enforced to protect against malicious or malformed files:
- Data block size limit (default 32 MiB, configurable via
set_max_data_block_size()) - Parsing buffer size limit (for chunked parsing via
push_chunk()) (default 64 MiB, configurable viaset_max_buffer_size())
- Data block size limit (default 32 MiB, configurable via
Examples
VgmBuilder as builder
use ;
use Gd3;
use ;
use UncompressedStream;
use ;
let mut builder = new;
// Register the chip's master clock in the VGM header (in Hz)
builder.register_chip;
// Attach a DataBlock detail
builder.attach_data_block;
// Add chip register writes using a chip-specific spec
builder.add_chip_write;
builder.add_vgm_command;
// ... add more commands
// Set loop offset (1: WaitSamples(44100))
builder.set_loop_offset;
// Set GD3 metadata for the document
builder.set_gd3;
// Finalize the document (An `EndOfData` tag is automatically added)
let document: VgmDocument = builder.finalize;
// `into()` converts the finalized `VgmDocument` into VGM-format binary bytes
let _bytes: = document.into;
VgmDocument as parser
use ;
use ;
// Read VGM bytes from somewhere
let bytes: = /* read a .vgm file */ Vecnew;
// For this example we construct a VGM byte sequence using the builder
// and then parse it back.
let mut b = new;
b.add_vgm_command;
b.add_vgm_command;
let doc = b.finalize;
let bytes: = .into;
// Parse the bytes into a `VgmDocument`
let document: VgmDocument =
.try_into
.expect;
// Example: map commands to their sample counts and sum them.
let total_wait: u32 = document
.iter
.map
.sum;
assert_eq!;
VgmStream::from_document
The from_document constructor is convenient when you already have a
parsed VgmDocument (for example: constructed programmatically via the
VgmBuilder). The stream will expand DAC-stream-generated writes into
the emitted command sequence and split waits so emitted writes are
interleaved at the correct sample positions. All wait commands
(WaitSamples, WaitNSample, Wait735Samples, Wait882Samples, Ym2612Port0Address2AWriteAndWaitN)
are converted to WaitSamples for consistent processing.
use ;
use StreamResult;
use ;
use Ym2612Spec;
use ;
// Build a minimal document that contains a data block and stream control
// commands. (Builder helpers for data blocks / stream setup exist on the
// `VgmBuilder` type; see the vgm module docs for details.)
let mut b = new;
// Example: append a YM2612 chip register write using the chip-specific spec
b.add_chip_write;
// (pseudo-code) append data block, configure stream and start it
// b.attach_data_block(...);
// b.add_vgm_command(SetupStreamControl { /* ... */ });
// b.add_vgm_command(StartStream { /* ... */ });
b.add_vgm_command;
b.add_vgm_command; // 6 samples (5+1)
b.add_vgm_command; // 735 samples
b.add_vgm_command; // 882 samples
let doc: VgmDocument = b.finalize;
// Create a stream from the parsed document. The iterator will yield
// parsed commands as well as any stream-generated writes expanded into
// the timeline.
let mut stream = from_document;
stream.set_loop_count; // Prevent infinite loops
while let Some = stream.next
VgmStream — feeding raw byte chunks
If you cannot generate the VgmDocument all at once, you can use push_chunk.
This is useful when working with microcontrollers that have insufficient memory.
The required 'DataBlock' is allocated within the library. Please bear in mind the remaining memory.
Providing input via push_chunk is the only difference from the from_document example above.
As with that example, you should iterate over the stream and handle the StreamResult variants
(Command, NeedsMoreData, EndOfStream and Err) in the same way.
Note: When using push_chunk, ensure that the chunks start at the data_offset of the VGM header
— i.e. the serialised command/data region that begins at offset 0x34 + header.data_offset.
use VgmStream;
use StreamResult;
let mut parser = new;
// Typically, the chunk size would be fixed at 1KB or similar.
let chunks = vec!;
for chunk in chunks
VgmCallbackStream overview
VgmCallbackStream wraps VgmStream to provide automatic chip state tracking
and event-driven callbacks for real-time VGM processing:
- Automatic State Tracking: Enables per-chip state management for 35+ supported sound chips, automatically detecting register writes and maintaining internal state.
- Event Detection: Emits
StateEventnotifications for key musical events:KeyOn: Channel starts playing with tone/frequency informationKeyOff: Channel stops playingToneChange: Frequency changes while channel is active
- Flexible Callbacks: Register chip-specific callbacks using type-safe spec types
(e.g.,
Ym2612Spec,Sn76489Spec) to handle register writes with sample timing and associated events. - Real-time Processing: Low-overhead design suitable for streaming playback, with callbacks invoked automatically as commands are processed.
- Comprehensive Chip Support: (WIP) Works with all major sound chips including FM synthesizers (YM2612, YM2151, OPL series), PSG chips (SN76489, AY-8910), PCM chips, and more.
This enables building advanced VGM analysis tools, real-time visualizers, and custom playback engines with minimal boilerplate code.
See also: the Chip State Tracking section below for current implementation status and a list of supported chips.
use ;
use ;
use ;
// Build a simple VGM document with YM2612 commands
let mut b = new;
b.register_chip;
// Sound chip initialisation
// ..snip..
// Key on channel 1
b.add_chip_write;
b.add_vgm_command;
b.add_vgm_command;
let doc = b.finalize;
// Grab the header's chip instances.
let instances = doc.header.chip_instances;
// Create VgmCallbackStream from VgmDocument
let mut callback_stream = from_document;
// Automatically enable state tracking for every chip registered in the VGM header.
// This initializes per-instance state trackers using the clock values recorded in
// the document header; it is equivalent to calling `track_state` for each instance.
// Useful when a VGM contains multiple chip instances.
callback_stream.track_chips;
// If you prefer to enable tracking for a single chip instance manually,
// Enable state tracking for YM2612 at NTSC Genesis clock
// callback_stream.track_state::<soundlog::chip::state::Ym2612State>(
// Instance::Primary, 7_670_454.0
// );
// Register callback for YM2612 writes
callback_stream.on_write;
// Process stream - callbacks fire automatically
for result in callback_stream
Looping and EndOfData overview
- VgmDocument is a data representation only: When you construct a document using
VgmBuilderand callfinalize(), the builder will ensure the command stream contains an explicitEndOfData— if none is present it appends one. - VgmStream is intended to act as a player-like iterator. When created from a parsed
VgmDocumentwithVgmStream::from_document(), it can automatically loop at the documented loop point. Itsset_loop_count()API controls how many playthroughs are performed:set_loop_count(Some(n))— limit playback tonplaythroughs (for example,Some(1)means play once and stop;Some(2)means play one full run and then one loop iteration).set_loop_count(None)— infinite looping (the stream will jump back to the loop point on EndOfData and continue indefinitely).
- When the stream reaches an
EndOfDatacommand it handles looping and end-of-stream semantics internally. If a finite loop count is configured and the limit is reached the stream will stop; if an infinite loop is configured it will jump to the loop point and continue. - Bytes-mode (raw chunk input via
push_chunk) does not implicitly rewind or re-feed earlier bytes. The parser maintains a small internal buffer and parses incrementally; it does not replay previously-consumed bytes for you. If you feed the stream usingpush_chunk()and want to loop playback, you must re-supply the bytes starting at the loop point yourself (reset your chunk source to that offset and callpush_chunkagain). See the byte-feeding example above for a usage pattern. VgmCallbackStreamwrapsVgmStreamand invokes callbacks for register writes and other commands as they are emitted. Note thatVgmStreamconsumes theEndOfDatacommand internally while implementing loop behavior; as a result theon_end_of_datacallback registered onVgmCallbackStreamwill not be invoked in normal operation. To detect playback termination observe the iterator reachingEndOfStream(or the iterator returningNonein the callback wrapper).- Fadeout support: configure
set_fadeout_samples(Some(n))on the stream to allow the stream to continue emitting commands fornsamples after the final loop end, which can be used to implement graceful fadeouts. When fadeout is active the stream records the loop end sample and will keep yielding commands (or generated waits) until the fadeout period elapses, after whichEndOfStreamis returned.
Chip State Tracking (WIP)
The chip::state module provides real-time state tracking for sound chips,
detecting key on/off events and extracting tone information from register writes.
- Chips with a check in the
Testcolumn have unit or integration tests that exercise their state-tracking behavior to a reasonable extent. - The specifications for key on/off detection — including total level extraction — are not yet stabilized.
- The values returned by
StateEventshall not be compatible across versions. Please note that the timing and values of events may differ between versions.
Implemented Chips
| Chip | Channels | Key On/Off | Tone Extract | System | Test |
|---|---|---|---|---|---|
| SN76489 (PSG) | 3 tone + 1 noise | ✅ | ✅ | Master System, Game Gear, etc. | ✅ |
| YM2413 (OPLL) | 9 FM | ✅ | ✅ | MSX, SMS FM Unit | ✅ |
| YM2612 (OPN2) | 6 FM | ✅ | ✅ | Sega Genesis/Mega Drive | ✅ |
| YM2151 (OPM) | 8 FM | ✅ | ✅ | Arcade systems, etc. | ✅ |
| SegaPcm | N/A | N/A | N/A | Sega PCM chip | - |
| Rf5c68 | N/A | N/A | N/A | RF5C68 PCM chip | - |
| YM2203 (OPN) | 3 FM + 3 PSG | ✅ | ✅ | NEC PC-8801, etc. | ✅ |
| YM2608 (OPNA) | 6 FM + 3 PSG | ✅ | ✅ | NEC PC-8801, etc. | ✅ |
| YM2610b (OPNB) | 6 FM + 3 PSG + ADPCM | ✅ | ✅ | Neo Geo, etc. | ✅ |
| YM3812 (OPL2) | 9 FM | ✅ | ✅ | AdLib, Sound Blaster | ✅ |
| YM3526 (OPL) | 9 FM | ✅ | ✅ | C64 Sound Expander, etc. | ✅ |
| Y8950 | 9 FM + ADPCM | ✅ | ✅ | MSX | ✅ |
| YMf262 (OPL3) | 18 FM | ✅ | ✅ | Sound Blaster 16, etc. | ✅ |
| YMF278b (OPL4) | 18 FM + PCM | ✅ | ✅ | YMF278B | ✅ |
| YMF271 (OPX) | 12 FM + PCM | ✅ | ✅ | YMF271 | NOT WORKING |
| K051649 | 5 | ✅ | ✅ | Konami SCC | ✅ |
| SCC1 (K052539) | 5 | ✅ | ✅ | Konami SCC (same as K051649) | ✅ |
| YMZ280b | N/A | N/A | N/A | YMZ280B PCM | - |
| RF5C164 | N/A | N/A | N/A | RF5C164 PCM | - |
| PWM | N/A | N/A | N/A | Sega PWM | - |
| AY8910 | 3 tone + noise | ✅ | ✅ | ZX Spectrum, MSX, etc. | ✅ |
| GbDmg | 4 | ✅ | ✅ | Game Boy | ✅ |
| NesApu | 5 | ✅ | ✅ | NES | ✅ (1) |
| MultiPcm | N/A | N/A | N/A | Sega MultiPCM | - |
| UPD7759 | N/A | N/A | N/A | uPD7759 ADPCM | - |
| OKIM6258 | N/A | N/A | N/A | OKIM6258 ADPCM | - |
| OKIM6295 | N/A | N/A | N/A | OKIM6295 ADPCM | - |
| K054539 | N/A | N/A | N/A | Konami K054539 PCM | - |
| HUC6280 | 6 | ✅ | ✅ | PC Engine/TurboGrafx-16 | ✅ |
| C140 | N/A | N/A | N/A | Namco C140 PCM | - |
| K053260 | N/A | N/A | N/A | Konami K053260 PCM | - |
| Pokey | 4 | ✅ | ✅ | Atari 8-bit computers | ✅ |
| QSound | N/A | N/A | N/A | Capcom QSound | - |
| SCSP | N/A | N/A | N/A | Sega Saturn SCSP | - |
| WonderSwan | 4 | ✅ | ✅ | WonderSwan APU | ✅ |
| VSU | 6 | ✅ | ✅ | Virtual Boy VSU | ✅ |
| SAA1099 | 6 | ✅ | ✅ | SAM Coupé, etc. | ✅ |
| ES5503 | N/A | N/A | N/A | Ensoniq ES5503 | - |
| ES5506 | N/A | N/A | N/A | Ensoniq ES5506 | - |
| X1010 | N/A | N/A | N/A | Setia X1-010 | - |
| C352 | N/A | N/A | N/A | Namco C352 | - |
| GA20 | N/A | N/A | N/A | Irem GA20 | - |
| Mikey | N/A | N/A | N/A | Atari Lynx | - |
| GameGearPsg | 3 tone + 1 noise | ✅ | ✅ | Game Gear PSG (same as SN76489) | ✅ |
- (1) The NES APU state tracker does not currently support Famicom Disk System (FDS) expansion audio.
License
MIT License