Decompression of SMBA RM files

[Sonikku A]

So I noticed that Super Monkey Ball Adventure used the same engine as Crash Twinsanity. And similar to that the RM/SM archives contain the graphical data
However for whatever reason, the PS2 version the RM files are compressed, while PSP's isn't. As such, support from the Twinsanity editor only is for the PSP version, but given graphical downgrades, I'd like the PS2 version to be cracked as well
Here's the PS2 RM file and PSP RM file:
For those wondering, the GC version uses the Lego engine, so it won't help in this case

[grandshot]

Format is simple and described in twinsanity editor sources. Represents a Chunk Package, where chunks contain other chunks.
Structure is:

Code: Select all

int32 type;
uint32 num_files;
For psp: uint32 num_files;
For ps2: uint16 num_files; uint16 unknown;
uint32 chunk_size;

if type is 0x01000100 then its the chunk table which having info about other files in package, in count of num_files:

Code: Select all

uint32 file_offset;
uint32 file_size;
uint32 file_id;

Main difference between versions - ps2 files packed in PACK containers, with NRV2b compression. Difficult is that file_size value in chunk tables definite only uncompressed size. PACK containers have only 32 bit value, after "KCAP" magic, which doesnt looks like compressed file size.
Well, it's possible to calculate byte ranges of compressed data by "KCAP" magic's and known offsets, but thats the "real crooked nail".

[Sonikku A]

Format is simple and described in twinsanity editor sources. Represents a Chunk Package, where chunks contain other chunks.
Structure is:

Code: Select all

int32 type;
uint32 num_files;
For psp: uint32 num_files;
For ps2: uint16 num_files; uint16 unknown;
uint32 chunk_size;

if type is 0x01000100 then its the chunk table which having info about other files in package, in count of num_files:

Code: Select all

uint32 file_offset;
uint32 file_size;
uint32 file_id;

Main difference between versions - ps2 files packed in PACK containers, with NRV2b compression. Difficult is that file_size value in chunk tables definite only uncompressed size. PACK containers have only 32 bit value, after "KCAP" magic, which doesnt looks like compressed file size.
Well, it's possible to calculate byte ranges of compressed data by "KCAP" magic's and known offsets, but thats the "real crooked nail".

So in my severely limited knowledge, that means it's only partially compressed? Sounds weird

[grandshot]

No, only if file starts with "KCAP" then it compressed.
In easy words, from chunks we know file offsets and file sizes. For PSP version we can just go to offset and read bytes equal to file_size. For PS2 version it's no work, because actial size of compressed data is smallest then file_size. We will read more bytes than needed, or, if that is the last file, get error what end of file reached before required bytes was readed.

[Sonikku A]

Not sure if this is even remotely the same NRV2b compression used. Or how to modify this compressor/decompressor https://github.com/mdrngrng/nrv2b