User Name		Tags: bold: [b]bold[/b] italics: [i]italics[/i] emphasis: [em]emphasis[/em] underline: [u]underline[/u] small: [small]small[/small] Link: [url=http://www.google.com]Link[/url] [img=https://www.hcs64.com/images/mm1.png]
Password
Subject
Message	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 LPF-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, LPF 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! [small][i]edited 10:32 AM EDT October 14, 2025[/i][/small] [small][i]edited 8:36 PM EDT October 14, 2025[/i][/small]

HCS Forum Index
Halley's Comet Software
forum source