Harry Potter and the Sorcerer's Stone .BWAV support by Puterboy1 at 9:16 PM EDT on July 5, 2020
I think these sound file types need vgmstream's support. The TXTH file made by Warthog1336 seems to have fine audio at the beginning but static and crackles at the end: https://zenhax.com/download/file.php?id=6477
And in case you are wondering, these samples are from the PS2 port.
BWAV structure goes like this: assume current position is zero. all values described below are 32-bit integers unless noted otherwise. 0x00(plus current position) - 32-bit float value(what) 0x04(plus current position) - unknown value (always 2) 0x08(plus current position) - 32-bit float, again 0x0c(plus current position) - unknown value (always 1) 0x10(plus current position) - unknown value (always 0x20) 0x14(plus current position) - unknown value (always 0x20) 0x18(plus current position) - unknown value, number seems to change for every sound entry within a BWAV file (explained later) 0x1c(plus current position) - size of sound entry 0x20(plus current position) - above plus 32 bytes added 0x24(plus current position) - all zero, goes up to 12 bytes 0x30(plus current position) - seems to be "PCM samples" 0x34(plus current position) - sample rate stored into two identical 16-bit values 0x38(plus current position) - unknown value (always 1? or does this number go up depending on sound entry? needs further research) 0x3c(plus current position) - same value as in 0x20 0x40(plus current position) - same value as in 0x20 current position is then added to 0x44, added to value as described in 0x20, then we get to next sound entry. sound entry within BWAV file is governed by current position, and said position goes right until BWAV file ends. sound entry header needs to be read this way for seamless sound playback.
i can't add this format to vgmstream because i can't handle C programming, maybe someone else with experience in that language plus vgmstream's code structure can pick up what i have managed to come up with instead.
Examining some of the .bwav files: BWAV seems to be container file for repeated PSX ADPCM samples, each bwav contains between 2 to 5 repeated PSX ADPCM samples. First 0x24 bytes of each sample look like header (information), remaining bytes are the ADPCM. So, BWAV is headered PSX ADPCM (file). Why the data redundancy, I do not know. Sometimes, $(0x1c) and $(0x20) differ in 0x20, sometimes they do not (i.e. other values, even 0x0). Some of those or other values could contain frequency/sample rate information.
If that will be enough to please you, I will do as you say.
Edit: Will the .bwav files found in this archive suffice?: http://gcn.joshw.info/h/Harry%20Potter%20%26%20The%20Sorcerer%27s%20Stone%20%5BHarry%20Potter%20to%20Kenja%20no%20Ishi%5D%20%282003-12-09%29%28Warthog%29%28Electronic%20Arts%29%5BGC%5D.7z
BWAV structure from these files is the same as described on second post with some differences. will recite what i've studied alongside some modifications.
BWAV structure (GameCube version) 0x00(plus current position) - 32-bit float value(what) 0x04(plus current position) - unknown value, can be either 1 or 2 0x08(plus current position) - 32-bit float, again 0x0c(plus current position) - unknown value, always 1 0x10(plus current position) - header size minus 0x24 0x14(plus current position) - see above 0x18(plus current position) - unknown value, always 1 0x1c(plus current position) - all zero 0x20(plus current position) - unknown value, seems to change with each passing sound entry 0x24(plus current position) - same value as in 0x20 0x28(plus current position) - all zero 0x2c(plus current position) - sample rate 0x30(plus current position) - unknown value, seems to change with each passing sound entry 0x34(plus current position) - size of entire sound entry, without header 0x38(plus current position) - channel coefficient 0x58(plus current position) - unknown value, seems to change with each passing sound entry 0x5c(plus current position) - all zero 0x60(plus current position) - same value as in 0x58 except byte order has been changed around for some reason 0x64(plus current position) - all zero 0x68(plus current position) - unknown value, seems to change with each passing sound entry 0x6c(plus current position) - total number of channels 0x70(plus current position) - same value as in 0x34 0x74(plus current position) - same value as in 0x34
BWAV structure (Xbox version) 0x00(plus current position) - 32-bit float value(what) 0x04(plus current position) - unknown value, can be either 1 or 2 0x08(plus current position) - 32-bit float, again 0x0c(plus current position) - unknown value, always 1 0x10(plus current position) - header size minus 0x24 0x14(plus current position) - see above 0x18(plus current position) - unknown value, always 2 0x1c(plus current position) - unknown value, always 1 0x20(plus current position) - sample rate 0x24(plus current position) - all zero 0x28(plus current position) - unknown value, always 4 0x2c(plus current position) - all zero 0x30(plus current position) - size of entire sound entry, without header 0x34(plus current position) - all zero 0x38(plus current position) - same value as in 0x30 0x3c(plus current position) - unknown value, seems to change with each passing sound entry 0x40(plus current position) - total number of channels 0x44(plus current position) - same value as in 0x30 0x48(plus current position) - same value as in 0x30
(reposting this part again with some modifications based on what i've found out about the BWAV format.) current position is then added to 0x24, added to value as described in 0x10, added to value as described in 0x30/0x34, then we get to next sound entry. sound entry within BWAV file is governed by current position, and said position goes right until BWAV file ends. sound entry header needs to be read this way for seamless sound playback.