I was working on specs, but haven't completed the entire structure and i'm not familiar with soundbank file formats. Brsar's have an almost identical structure with nintendo ds sdat files. a brsar file contains 3 subchunks: SYMB, INFO and FILE. SYMB contains mainly readable ASCII symbols of all sound, group, bank and player entries. Player entries are programming specific and probably to pick the right callback function of the game for dynamic music(which is why the brsar player wii channel crashes on them). INFO contains information of sounds, banks and file entries FILE contains a a padding of 32 zeroes and then all raw file's archived uncompressed. Though there are some junk bytes sometimes in between not sure what their function is.
As for the raw subfiles now: RWAR is like SWAR. Haven't looked at it much, but it's just an archive of RWAV files all containing a single sound file compressed in GC/WII DSP. RWSD: no idea, maybe it's like STRM files in sdat files. RBNK=SBNK: haven't checked out yet RSEQ: did most research on that the midi decoding is almost similar as nds's SSEQ. It contains 2 subchunks: DATA and LABL. DATA contains all midi sequenced data. Sequenced data is like this. A byte lower than 128 is a note event and above 127 is a sequencer instruction(rest, goto, gosub, set tempo,etc.). Except for a few changes they are the same as the nds's specs(look for kiwi.ds). the LABL chunk contains a symbol table with readable text and it has an offset that tells where the sequenced data starts in the DATA chunk. Label names are like HAMMER_START HAMMER_END HAMMER_TRACK0 HAMMER_TRACK1, for RSEQ with a single sequence or an entire archive as DOG_BARK, DOG_SING, DOG_FOOTSTEPS(like SSAR files on the ds)
BTW the rv_forest.brsar doesn't work with the brsar wad player. It's too big for a wii channel anyway. I made a very experimental buggy midi winamp plugin that can decode RSEQ's, but it sounds awful without the proper soundbank. I tested it on rv_forest.brsar myself and heard Able Sisters quite well. i should put some steps back and make the conversions tool first i guess :)
Thank you by Pyrominion at 6:51 PM EST on January 21, 2010
Thanks alot for the info i will start reading up on what i can find. Now im headed in the right direction
RWAV and RWSD both have some minimal support in vgmstream. You can extract these from .brsars with snakemeat's vgmtoolbox, which I think just picks out the files without parsing the archive at all. I've had no big problems with Winamp 2.95 on wine, I test out the Winamp builds of vgmstream there regularly. If you can't get that to work, vgmstream should build fine for you in Linux, just go to the test/ directory and run make. You can also build the audacious plugin (though this may not work in Karmic) with: ./bootstrap && ./configure && make -f Makefile.unix && sudo make -f Makefile.unix install
Requires libmpg123, libvorbis, and audacious development packages, possibly others.
GOOD News! I'm getting closer to rewriting the source for sseq2mid but i had to test the program first. Now i included a build of sseq2mid using loveemu's source file for linux and the makefile here: Linux SSEQ2MID
I extracted an rseq file from a brsar file manually with a hex editor and ran it through my program and it starts similar to the song, then in sseq2mid hex 00 - 7f are notes and 80 is a rest then the rest after that are functions. part of the way clearly after the song starts there is 8a hex and for sseq2mid it is undefined. since 80 is definately rest it cant be part of the notation so it must be a function that needs to be defined. heres a link that describes it well for those intersted. SSEQ and heres rseq2mid for now it was change all three files terms to rseq from sseq and then define offsets for functions and tags and labels and size. If anyone has any info on offsets for rseq files please post them. I need to know the rseq size offset and the amount of bytes it is, 4,6, etc.
My first brsar test program was this http://www.mediafire.com/download.php?fo0zz2gnt4a Put a brsar file in the same map, rename it to sound.brsar and run the first batch file and the files will be extracted in /brsar/file. Not sure if the junk bytes in between have a purpose.
i did some decoding of RSEQ's and figured out the wii-specific events that are not available in the kiwi.ds specifics, but i never made a program that results in rseq2mid. I can fill in the list for you.
update: trying to figure out the entire brsar file format. It creates csv files of all entries and luckily all values are byte aligned to 4 bytes. This makes some values unintentionally little endian and confusing in the csv file.
SYMB table is 90% figured out now with only 2 unknown values per symbol entry and not sure why it's such a weird structure. Could be that i decoded it incorrectly and that the entire structure is a heap structure and that the 2 unknown values are heap-related. It would explain the counter which is always 2n+1 where n is the number of entries
INFO table i figured out only the entire bank entries and the entire player entries. Halfway through sound and file entries
bank entries structure: u32 symbol entry, u32 file entry,u32 zero
player entries structure: u32 symbol entry, u8 flags,u8 bytealignment[3], u32 zero the flags seem to be game related sadly, but the last one always is 0.