[researching] High Voltage Software audio system

[AlphaTwentyThree]

Hey folks,

I've just encountered some files with a strange header in Astro Boy: The Videogame for PSP. They seem to be compressed but I can't figure out how to process them. I've attached three examples.

Here's a picture of why I suspect a compression (should say "Ambience"):


Thanks for helping me out!

[BloodRaynare]

Looks like Run-length encoding (RLE) to me.

[DKDave]

Hey folks,

I've just encountered some files with a strange header in Astro Boy: The Videogame for PSP. They seem to be compressed but I can't figure out how to process them. I've attached three examples.

Thanks for helping me out!

As you might guess, these are a pain! I assume these are from the .r4s archives that start with "BIGB" ? I've encountered a few variations of that format in various games on different platforms, like Bionicle, Catwoman ... The compression is one that QuickBMS doesn't do, although it is fairly simple RLE as BloodRaynare mentioned.

I wrote a decompression routine a while ago based on some code I found. I've attached my very crappy QuickBMS script with my crappy slow custom decompression routine. The extracted FILE2 is a table referring to FILE1, which refers to the data in FILE3. I notice in this game that some of the audio is Sony PS ADPCM and some are normal RIFF WAVE files. Each RIFF/WAVS segment in FILE1 contains actual filename, format info, and offset to the audio file in FILE3, although I haven't fully documented that yet.

So, still some work to do on it, but my script should decompress the data and give you something to work with.

bigb.zip

[AlphaTwentyThree]

Wow, that's quite the progress on the matter! Thanks a lot.
In the process of writing a script that processes these three files further. I'll try to directly implement it into your script and post it here if the results are usable, we'll see.

[AlphaTwentyThree]

Found a file that isn't processed correctly - the uncompressed data is truncated at the start: https://www.mediafire.com/file/9bk6nhwf ... 91.7z/file

I've written a script that works for the music, which is what I was after. The problem with the other files is that the internal name is the same among different languages so the script breaks. If you have an idea how to fix that, you can adjust the script. I've reached my main goal so I won't work on this any further.
If you're interested, here's what I've come up with. The wavs don't seem to have any offset markers for the uncompressed portion but they are saved sequentially so it works by just running through the wave files and saving them in the same order (see line 51/77). Again, as long as there are no duplicate wavs name references that is.

Code: Select all

get BNAME basename
string BNAME -= 1
string F1 P "%BNAME%1"
string F2 P "%BNAME%2"
string F3 P "%BNAME%3"
OPEN FDSE F2 0
OPEN FDSE F1 1
OPEN FDSE F3 3 EXIST
if EXIST == 0 # no sound files
   cleanexit
endif

get FSIZE asize
set i 1
for t = 1
   get TYPE short
   get IDENT short
   savepos TEST
   if TEST == FSIZE
      break
   endif
   get OFFSET long
   if IDENT == 0x8000 # streams only
      putArray i 0 OFFSET
      putArray i 1 TYPE
      math i += 1
   endif
next t
xmath FILES "i - 1"
set w 1
for i = 1 <= FILES
   getArray OFFSET i 0
   getArray TYPE i 1
   if i != FILES
      xmath n "i + 1"
      getArray SIZE n 0
   else
      xmath SIZE "OFFSET + 0x20" # last control file
   endif
   math SIZE -= OFFSET
   if TYPE == 275 # RIFF file
      goto OFFSET 1
      getDstring TEMP 4 1 # RIFF
      get SIZE long 1
      math SIZE += 8
      getDstring TEST 4 1
      if TEST == "WAVS"
         xmath NAMEPOS "OFFSET + 0x2c"
         goto NAMEPOS 1
         getCT NAME binary 0x2e 1
         putArray w 0 NAME
         string NAME P "%NAME%.wavs"
         log NAME OFFSET SIZE 1
         math w += 1
      endif
   endif
next i
xmath FILES "w - 1"
set SEARCH 0
for i = 1 <= FILES # _should_ be correct
   goto SEARCH 3
   FindLoc OFFSET string \x57\x41\x56\x45\x66\x6D\x74\x20 3 "" # WAVEfmt
   math OFFSET -= 8
   goto OFFSET 3
   get DUMMY long 3 # RIFF
   get SIZE long 3
   math SIZE += 8
   getDstring DUMMY 0xc 3
   get CODEC short 3
   if CODEC == 0xfffe || CODEC == 0x720
      set EXT ".at3"
   elif CODEC == 1
      set EXT ".wav"
   else
      set EXT ".lwav"
   endif
   getArray NAME i 0
   string NAME += EXT
   log NAME OFFSET SIZE 3
   xmath SEARCH "OFFSET + SIZE"
next i

[AlphaTwentyThree]

Alright, found a variant that isn't supported yet in "Ben 10: Protector of Earth" (PSP): https://www.mediafire.com/file/dttrsa2l ... r4.7z/file
I'm not trying to understand your script so maybe you could just update it?

[DKDave]

Thanks, always good to have more info to update things. I've done a bit more research and found a few more things. The header isn't always the same size, was just an assumption I made. There are also 2 separate uncompressed data blocks after the 2 compressed ones, not just the 1 I initially assumed. Some files use one or the other, and sometimes both.

If the RIFF type is "WAVE", the data is in block 1 as PS audio, "WAVS" uses data block 2 as normal .wav files.

Each RIFF info segment has an "strm" chunk which gives the data offset and size of the file from the start of the relevant uncompressed block. However, the size only works corectly for PS audio, for .wav you can get the size from the actual file. Not sure why they did it like that.

I noticed the same filename issue, but I can't see any flag for a language identifier, so that's another thing to add to my list to fix at some point.

So I'll try to update it with everything I've found out.

[AlphaTwentyThree]

Thanks Dave!

[AlphaTwentyThree]

I've renamed the thread to the appropriate title - I've randomly checked their first game and yes, it uses the same engine: https://www.mediafire.com/file/r5pxd65t ... re.7z/file

@ aluigi: Since there are 70 games that supposedly use this engine, I'm hereby requesting the compression to be implemented into QuickBMS.