SRip_N64_Sound_Bank_Ripper_(Jesus_LA)

@Nintendo64

Published in 

Nintendo64 scene NFOs

 · 4 years ago

README.TXT

 
SRip: N64 Sound Bank Ripper.  JLA'99 

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 
  /a ratio    Sampling rate adjustment. Default = 1.0 (none) 
  filename    ROM Filename. Any format (byte swapped or not) 

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. 

Contact info. 

Bugs, questions, comments, requests, etc. are welcome. Just send 
email to jla@anubisinc.com 

 
- 
jla