<<>> SRip: N64 Sound Bank Ripper. JLA'99 v0.1 usage: SRIP [/c offset] [/t offset] [/q] [/f width] [/o header] [/n template] [/a ratio] filename /c offset Offset of Sound Bank Control Block (.ctl) /t offset Offset of Sound Bank Table Block (.tbl) Default = 0 /q Quiet operation /o header Header filename. Default = CONTROL.H /f width Width of generated fields in header file. Default = 10 /n template Struct naming template. Default = %t%2i%2s %t Struct Name %b Bank %i Instrument %s Sound %c Struct Id /s srate Force sampling rate to given value /a ratio Sampling rate adjustment. Default = 1.0 (none) filename ROM Filename. Any format (byte swapped or not) Fixed in these version. * SRip now rips more Roms!!! It now understands the format found in Nintendo games like Mario64. The .ctl and .tbl files differ a great deal from the regular format, that's why the previous version of SRip wouldn't understand it. Unfortunately, the header file Control.h is not understandable. * A bug that prevented SRip from understanding byte swapped files (.v64 format) * Added a sample rate option (/s) so you can manually specify any sample rate. To rip a ROM file you can simply type: SRip ROMFILE.BIN SRip will try to locate the control and table blocks (.ctl and .tbl) and if it succeeds it will rip the first set. A header file CONTROL.H will be generated automatically, containing the instrument definitions. Additionally if a valid table block was found, .wav files will be created in the current directory (be careful, though. You can end up with a directory full of files!!) If you do not want wave files to be generated, you can force the .tbl file to be ignored with the /t 0 switch. Although SRip only rips the first set of .ctl/.tbl blocks found, you are not limited to that. You can always use the additional offsets (displayed by SRip while searching) to rip those blocks. Example: C:\> SRip KIGOLD.ROM .ctl offset not specified...Guessing possible values for the .ctl file. Press any key to abort. Found possible .ctl offset: 0x8F9FA0 Found possible .tbl offset: 0x907580 Found possible .ctl offset: 0x9AF4B0 Found possible .tbl offset: 0x9B9AD0 Ripping from .ctl offset 0x8F9FA0, .tbl offset 0x907580 Ripping Bank File Ripping 98/98 instruments (SR: 22050, Original: 22050) Dumping structs (1361 of 1361) to CONTROL.H 229 .wav files extracted In this case, SRip only ripped the first set (0x8F9FA0/0x907580) thus being equivalent to having done SRip /c 0x8F9FA0 /t 0x907580 KIGOLD.ROM But if you wanted to rip the second set, you just need to enter: SRip /c 0x9AF4B0 /t 0x9B9AD0 KIGOLD.ROM Ripping from .ctl offset 0x9AF4B0, .tbl offset 0x9B9AD0 Ripping Bank File Ripping 1/1 instruments (SR: 22050, Original: 22050) Dumping structs (1701 of 1701) to CONTROL.H 255 .wav files extracted and that's it! Customizing the output. The header filename (by default CONTROL.H) can be changed with the /o switch. The width of the fields can be changed with the /f switch, in case the generated names are too long and columns get scrambled. You can use the /n switch to customize how the struct names are generated, although the default template suits most needs. You can adjust the sample rate of the generated .wav files. Just use the /a switch and specify a ratio, like 0.5 (to decrease by half the original sample rate) or like 2.0 (to duplicate it) You can use other ratios, but some cards won't properly play these .wavs The .wav filenames are always generated with the template %f%b%3i%2s, I might add filename templates later. (%f is the type of wave format @=Raw, A=vadpcm) The technical stuff. A N64 Sound Bank File consists of two blocks. A control block (.ctl containing all the control (of course!) information about each sound, like envelope, detuning, keymap, sample rate, sample volume, sample pan and of course pointers to the actual waveform data) and a waveform table block (.tbl, that contains only the waveform data, either in vadpcm encoded format, or as raw 16 bit samples) These two blocks are usually found inside a N64 ROM together, the .ctl block followed by the .tbl block. The .ctl block is actually easy to locate, since it starts with the magic number 0x4231 ("B1": the revision number). Unfortunately the .tbl block is not as easy to pinpoint, since it does not have a distinctive marker. The only assumption that we can do is that it immediately follows the .ctl block and that it contains a valid gain/code byte every nine bytes (ie. bit 2 and 3 are off... in most cases). In some cases, several .ctl blocks use the same .tbl block. You will easily notice that whenever SRip finds only one .tbl block but multiple .ctl blocks. The guessing algorithm has been vastly improved. It now will also detect "nintendo style" .ctl and .tbl blocks. These blocks do not conform to the previous explanation, they are entirely different and I don't understand most of its fields. Any info? Contact info. Bugs, questions, comments, requests and info are welcome. Just send email to jla@anubisinc.com - jla