I saw you were looking for the sample count value. brstm doesn't have fixed offsets at which you can find these things. However, if you look in the header chunk (starts with the text HEAD), the sample count is at 0x2c in that chunk.
When the files were created (by the developers, not the rippers), the header was messed up. When VGMstream reads the header it sees "44100" (or "48") so it plays them as such. If you rename the files to *.spmbrstm (if that's wrong, blame HCS. I asked him just now) then they should play at the correct speed. Hope that helps. Mouser X over and out.
It should be .brstmspm because that's what works with vgmstream.
GENH is used when the stream files themselves don't contain all the information needed to decode them. This information is elsewhere, either in a table in some other file or hard coded into the decoder somehow, or maybe (as in the Super Paper Mario case) the information is there but incorrect.
Earlier there were various hacks to solve this, generally involving renaming the files with a particular extension that helped the player to decide what to do (stuff like the .I400 extension), or mashing in the header information from elsewhere into a combined file (like .zwdsp).
GENH is meant to be a standard way of storing the common metadata needed to decode the stream. If there must be a hack then we might as well embrace the artificiality of it and make a unified format that can be applied to various codecs and systems.
I finally got around to making a brstm creator, which I have entitled Revolution B. You can find it and some details on the ripping tools page.
Before using it to replace a brstm in a game, it is important that you attempt to extract dsp from an existing brstm, so that revb can do some checking. If it fails (won't say "Done!" when finished) do let me know so I can add support for whatever the oddity is.
Typical usage would look like this: brstm --build song.brstm songL.dsp songR.dsp
That should be suitable to generate a brstm for Super Smash Bros Brawl.
Currently revb doesn't fill in the ADPC table, which I think is used for seeking. I don't think it is used for looping, though, and I don't see any reason why seeking would be done, so it probably isn't important. If something seems odd I may have to fix this.
oppo noticed an issue, though not quite my fault, Nintendo's brstm driver appears to only be able to seek to a loop start at the beginning of a block. For Brawl this works out to 14336 samples.
Revolution B 0.2 on the ripping tools page. See history for changes, importantly it now produces a warning if the loop start is not on a block boundary, and reports how many samples of silence can be added to the beginning to resolve the problem.
I've made a batch file that automatically converts any audio file read by goldwave or vgmstream to brstm files
problem is it's just one step away from being fully automated
my current code is: for %%a in (*.adx) do ( Setlocal EnableDelayedExpansion vgmstream -o "%%~na.wav" -l 1 -f 0 "%%a" @set /P end=End Loop Point: @set /P start=Start Loop Point:
Is there any way that vgmstream can output the loops as variables or something that would fully automate this process? I'd really like being able to simply drop this batch file in a folder full of mp3s or adxs, run it and come back to a folder full of brstms
Closest we have is the -x and -g options, which print out command lines for adxencd and oggenc with loop stuff. But what kind of loop points do you expect for mp3s? However, this won't help with getting proper loop points, you'd need a preprocessor that pads out the file according to where the loop start is supposed to be. I could throw together something that does this, and I've been thinking of it, might get to it shortly.
basic steps a simple automatic converter batch file would take with files that already have loop points:
use vgmstream to decode file up to one second past the end loop point, and output loop points to command prompt have command prompt output loop points to external script adjust loop points, making the start loop point a multiple of 14336 by finding the next multiple of 14336 and increasing both loop points accordingly eg: start: 97512 -> 100352 end: 724679 -> 727519 input new loop points to command prompt use goldwave to split output wave file into 2 separate files, one for the left channel and one for the right encode both wav files with dspadpcm make brstm file with revb
If you wanted to add custom loop points to an mp3 or similar nonlooped audio file you would:
convert file to .wav with goldwave enter custom loop points manually use goldwave to split output wave file into 2 separate files, one for the left channel and one for the right encode both wav files with dspadpcm write brstm header with revb If the start loop point is divisible by 14336(something like a $start/14336 = int($start/14336)), you're finished. If it's not:
use vgmstream to decode file up to a second past the end loop point, and output loop points to command prompt have command prompt output loop points to an external script adjust loop points to have the start loop point a multiple of 14336 input new loop points to command prompt use goldwave to split output wave file into 2 separate files, one for the left channel and one for the right encode both wav files with dspadpcm make brstm file with revb (yes you're encoding twice, but unless you get brawl compatable loop points before hand it's the only method I could think of)
but the -x and -g options don't actually tell adxencd or oggenc to encode the output dump.wav file, they just show you the commands to do so (if i'm wrong tell me, that's what it does on my computer)
And if you decide to add an option to output the loop points (which i really hope you do) could you output the total number of samples in a song and whether it loops or not as a 1 or 0? I'd need those to make the little brstm converter batch file I'm making fully automatic and virtually n00b proof. If I had that the batch file would be able to convert any file readable by vgmstream or goldwave into a brstm with proper loop points automaticlly
The idea of the -x and -g option is that you decode with test.exe, but you direct the output to a batch file, like: test.exe -x fred.dsp out.wav >> blah.bat And then you run blah.bat. >> appends to the end of a file. I'd probably do something similar if adding a dspadpcm output, and it'd have the loop params or not according to that. There'd also be a switch to enable the loop aligning.
oh, I didn't think of directing the output to another batch file
The problem with having an adxencd, oggenc, and dspadpcm output is that it's not as versatile as simply outputing loop points as variables. If you want to put loop points into your own script instead of using test.exe's predetermined commands, you can't.
I would suggest an option that does something like test.exe -option file.adx >> 1.bat which would output that file's information which might look like: "set loop=1 & set lstart=103944 & set lend=4839137 & set ttlsamp=4839137" to 1.bat
then have a "call 1.bat" in your original batch file to import the variables which you can then use in your script
Ok, I put something like that in r663. You have a fname variable as well, so you just have to call it once (with the -b option). Let me know if there's anything more.
Sir-Sabin: No, I've resigned to making the existing tools more useful. Maybe some day when I know more about synthesis and have a huge amount of free time.
Oh, I just saw that the source is embedded in the exe. I've just added support for multiple channels myself, thanks for releasing the source aswell! :D