Show Posts
Okay, there is a serious issue in Brawl Box 0.68 when it comes to BRSTM creation and when you upload them to brawlcustommusic.com. The files uploaded to that site have static in the right audio channel, but when played back on Brawl Box 0.67 and 0.68, they sound perfectly normal. I know 0.68 is responsible because I tested a BRSTM I made from 0.67 and it had no such issues. I don't know what is causing this, but it's rather baffling.
I found this issue a long while back; about time I share my findings.
The RSTM stereo header generated by BrawlBox in versions 0.68 (and above) has a misaligned pointer somewhere in the channel codec info (at [B0..B7], the pointer reads 000000AA instead of 000000A8), with channel #2 data being shifted accordingly (to the right by 2 bytes), which causes vgmstream (plugin for Winamp and XMPlay) and similar software to fail at reading the DSP coefs for channel #2 properly, resulting in static-ish audio.
Whereas a Wii game might handle this misalignment without glitching out, with vgmstream it's another story.
Compare the two files below with a hex editor to see what I mean:
- From BrawlBox v0.67b: http://www.mediafire.com/?bxcmv22n81popi9
- From BrawlBox v0.68 and higher: http://www.mediafire.com/?pv7rw6u3beu6cwd
As generated by v0.68 and higher, channel #1 codec info appears to have an extra 2 bytes of "unused" data (00 00) at the end. Channel #2 codec info begins right after these 2 bytes, and thus is no longer aligned by 4 bytes (as before in v0.67b). Wii might handle this fine - and so does my BRSTM template for HexEdit (based on vgmstream and BrawlBox IIRC) which deals with all the pointer stuff - but, in any case, vgmstream doesn't. The "fix" would be to make sure that this size computation error doesn't happen in BrawlBox any more.
Hopefully that's enough information.