Indeed, when I examine the file in question, I find that there is no ADPC chunk in it, unlike, say, STRM_N_KOOPA_N.brstm
So my question is: is there some sort of workaround that would allow me to split the channels in STRM_N_FACTORY_N.brstm, even without the existence of an ADPC chunk? Thank you in advance.
No workaround, the Mario Kart Wii files are PCM, not DSP ADPCM, and revb doesn't support that.
As it is PCM you can "decode" the file with vgmstream and then split the resulting wav without any loss, using whatever multichannel editing tool you may have handy.
I see. So one way to output, say, the first two channels to a BRSTM file would be to do this:
>test -l 1 -f 0 -2 0 STRM_N_FACTORY_N.brstm decoding STRM_N_FACTORY_N.brstm sample rate 32000 Hz channels: 4 loop start: 630784 samples (19.7120 seconds) loop end: 2690420 samples (84.0756 seconds) stream total samples: 2690420 (84.0756 seconds) encoding: Big Endian 16-bit PCM layout: interleave with short last block interleave: 0x2000 bytes last block interleave: 0x1b00 bytes metadata from: Nintendo RSTM header samples to play: 2690420 (84.0756 seconds)
...then encode the resulting WAV file to BRSTM using some BRSTM encoder (perhaps encoding to an intermediate format such as DSP?). I suppose this is not lossless, though. Is there a lossless way to do this? If not, I can live with it.
Basically, I just want to have an STRM_N_FACTORY_N_1.brstm with the first two channels of STRM_N_FACTORY_N.brstm and an STRM_N_FACTORY_N_2.brstm with the other two. Any pointers on the "best way" to do this would be greatly appreciated.
Oh, yeah, I'd forgotten about that channel splitting capability of test.exe.
I wouldn't recommend reencoding the audio to brstm, I don't know if there are any that will do PCM correctly. What would be nice is for test.exe to support adding the sample looping info the wav so you could rename it .lwav and play that.
The existing options for exporting loop points are for ADX or Ogg... though there's one (-b) that outputs environment variable settings.
Hmm, yeah, I can live with .lwav too. I wrote a small script for converting .brstm to .lwav in Python, but I'm not sure if it's 100% accurate, due to my limited knowledge of the .lwav format.
http://pastebin.com/jr4s0spc
Basically, I add a 64-byte 'smpl' chunk to the end of the .wav file generated by test.exe (60 bytes if you exclude the length of 'smpl') and update the RIFF header chunk size (the 4 bytes after 'RIFF'). Is this how it's done?
EDIT: Oops, the chunk is 68 bytes in size, not 64 (60 bytes if you exclude the length of 'smpl' and the 4 bytes that indicate the size of the chunk)
Yeah, it seems to work just fine. I based my implementation on vgmstream's source code (particularly, the file src/meta/riff.c) to check the offsets it reads, so it should work with vgmstream at the very least. Not sure if it would work with any other .lwav player out there, but my target was vgmstream anyway.
Hi. Me again. Just wanted to post an updated version of the code, 'cause I found a couple of bugs in the original, just in case anyone out there intends to use it: http://pastebin.com/3LA3fUS4