My personal VGMSequence concept by Katsur at 12:21 AM EDT on October 14, 2025
So I was brain-storming the equivalent of VGMStream, but sequenced, capable of playing raw, unadulterated, original sequenced game music files with soundfonts. Yeah, sounds unlikely, but I was thinking my best, so here we go...
1) TXTP-like file - basics: -Soundfont with samples: specify the location first, then choose the suitable sample bank. It can also scan sample bank file's content of samples used within raw VGM sequence file -MIDI-like sequence file: which file (not PSF, PSF2, USD, etc). No actual header? TXTH file may help. -Header, when specified correctly, may work straight out of VGMSequence's internal compatibility database, such as Squaresoft AKAO Header. -Subsongs (optional; if available and necessary) -Tempo (in case of sequence file lacking specified BPM) 2) Module trackers are also welcome, including UMX (Unreal Music Header), MOD (Protracker MOD Header), XM (FastTracker II Header), MO3 (Unseen MO3 Header), etc. Besides, old PSF/miniPSF alternative format (and its derivatives, such as 2SF/mini2SF) is also supported, with no TXTP needed thanks to miniPSF being smart enough to find psflib 3) The obscure STY+DLS sequence format (Hitman: Codename 47, Gothic, Midnight Club II, etc) is welcome too! 4) It may have its own sequence instruction pattern visualization screen, in vein of XMPlay and OpenMPT. Supports every compatible format, either MIDI sequence with just instructions but without integrated samples, or module trackers with built-in samples and instructions. 5) Bit depth and sample rate are adjustable, up to 32-bit 96000 Hz respectively, and encoding type is synthesized, according to Foobar2000.
Yes, it sounds crazy, I admit it. It needs some research, reverse engineering, sweat&tears, etc. Feedback for improvements appreciated; this is just an estimate concept idea made-up by me.
Motivation? To properly play raw, unconverted video game sequenced music files straight from Sony PlayStation, GameCube, Nintendo DS, etc. with little-to-no hiccups.
edited 12:38 AM EDT October 14, 2025
edited 10:39 AM EDT October 14, 2025 [edit] (5 hours left)
I had the same idea decades ago and a few years back I started developing something like this, originally designed with N64 sequences in mind, but can be anything as long as the implementation details of any given format is exactly known. My concept is as follows:
I have a RIFF-like container format (.YMF) that contains the isolated soundbanks, wavetables and sequences. The data segment is the first chunk in the file ("YMF!") and has all the extracted/isolated data in continuous form. Then comes the format chunk ("FRMT") that has 8-byte sub chunks that tell the actual format and offset of the soundbank, wavetable and sequence, with additional info if necessary. It can have other chunks as well that are necessary if some formats have game-specific quirks or need additional info that's not present in the soundbanks themselves.
The actual hardcore part is writing the playback engine and all the loaders for every format that exists. That's exactly what I did and I can tell you, it's a LOT of work. I'm not sure if the work put into this is actually worth it in the end but the results in some cases are remarkable, especially when you hear N64 music with stereo reverb and without glitches, especially the ugly upsample limit of the N64, which cuts every note that is pitched up more than 200%. But you have to implement *everything* from scratch. The first thing I did was the standard compact MIDI sequence format of the N64 along with the Pointer Table V1 and VADPCM wavetables. But it wasn't long until you hit the first incompatibilities and quirks of the standard implementation. A few examples: HAL-Games have messed up vibrato settings in the soundbank and non-standard MIDI CCs for different things. Some games set instrument properties in-game at runtime. Stuff like this needs special handling. Two solutions for this would be a lightweight scripting language (TXTH) or – as it is currently, another chunk ("MODS") with modifications and stuff but it's not flexible enough. Scripting language would be better. Could be embedded or external if needed.
The reason why the entire project exists at all was Mischief Makers, which has messed up soundbanks. I wanted to know what the hell was going on with this game so I decided to examine the ROM for additional stuff stored near the beginning of the ROM. It has per-song settings for each key-region in the soudbank and per-song reverb settings. Something that's not included in the standard soundbank data and thus makes the handling of additional info mandatory in the first place. But after I had the CMID playback engine and loaders finished, I could suddenly play most of the games with this format just fine. Ripping standard games was now just a matter of 2 minutes, you just isolate the data using a HEX editor, put the offsets in my tool and click "compile YMF". Creating a USF is a nightmare in comparison.
I haven't worked on it in a while because even if it's damn awesome and exciting the first time around when you hear *actual* real time sequences playing flawlessly inside you own tool, it quickly becomes routine and gets boring. Remember, you have to implement every aspect for every format that you wish to support. And there are some nasty sequence formats out there! AudioSeq, BMS, AKAO… AudioSeq and BMS kinda work but only the early ones. I would love to implement AKAO, just to hear Chrono Cross in my tool but I have no motivation at the moment.
edit: features so far, problems, incompatibilities (experimental, unstable, work-in-progress, user-unfriendly)
* Soundbank viewer, shows entire structure in tree-form, instruments, key regions, properties, visual display of key regions. Instruments can be previewed (played) with either PC keyboard or even MIDI-in device.
* Wavetable viewer, shows the waveforms, loop points, same preview (play) as in soundbank viewer possible
* Sequence viewer/player, shows the sequence in tree-form (tracks), can mute tracks, graphically shows note events in table-like viewer, can optionally print all (including low-level) events on a debug graph (timeline), WAV exporter (interleaved or one-file-per-track, can write additional stuff like events as cue lists), shows live track status for the usual stuff like program, bank, pitch bend, reverb send level, SVF state etc, rudimentary (AKA barely functioning) register operations for formats which need crap like this (BMS, AudioSEQ, CSEQ)
* Reverb adjustable, currently FreeVerb but could be anything
* some standard SVF implementation for games with LFO-feature, more like one-fits-all-workaround because it's basically impossible to recreate all the different algorithms of the many formats/games with just one SVF model
* ADSR falloffs adjustable, more like a workaround because every game/format is different
* sequences are not converted to common format but are processed on-the-fly
* soundbank format originally based on N64 SDK's layout but got complex over time, needs fundamental refactoring/abstraction to account for more formats, can currently not represent all necessary features for every game/format
* polyphony of 256 voices (hardcoded), sample rate of 48000 (hardcoded), floating point processing throughout, only linear interpolation at the moment (not a big problem),
* includes a few hard-to-use tools to help extract N64 stuff and search for byte patterns and what not, can compile a YMF from isolated files, but most of the work will always be done with a good old HEX editor, no way around it.
* sequence playback (the heart of the entire thing) already supports a few different formats, *none* of them 100% accurately (not possible, forget about it). CMID is currently the "most compatible", ranging from "playable with quirks" to "nearly perfect". SNG format is playable but has problems (ADSR not yet implemented), AudioSeq has problems, register OPs messed up, BMS has even more problems, some rudimentary register OPs work but, yeah. DCM1 (Tetrisphere, New Tetris) worked perfectly but broke after some core-rewrite, LFO worked but broke after some core-rewrite, CMID's copy-block does not support variable repeat-amounts, Many game-specific note handlings not implemented like how new-note-actions, parameter changes after note-off, note lengths after tempo change, the list goes on and on…
As I said, implementing something like this is a monstrous undertaking!
edited 10:32 AM EDT October 14, 2025 [edit] (12 hours left)