Question regarding LZX/D recompression.
 

Hi all,

So I've been giving the "Dead Space" series a crack and it seems as though the majority of assets across the 3 main installments are stored within ".STR" archives, that seem to be compressed with LZX (with "Dead Space 3" using LZXD).

I've tried using the xmemcompress XTool plugin to inflate the compressed streams (as I was under the impression xmemcompress could be used for LZX re-compression), but alas no dice. The only streams I can pickup are a couple using the zlib/reflate codecs but these are only a few KB in size. The sample below, when decompressed is almost twice its size, coming at ~60mb, and compresses much better even when only srep & lolz are applied (18.1 MB (unpacked/decompressed assets) vs 24.8 MB (original compressed archive)).

If anyone who's had success with re-compressing LZX/D could offer any insight I'd greatly appreciate it.

You will need a database in order to use the xcompress XTool plugin.

Weird that BMS2XTL does not work for this file, although the BMS script extracts the archive just fine.

There's Razor's old LZXRec too however that does not work on this file.

My only guess is that maybe the sample is using the "dk2" comtype, which is the only other compression algorithm referenced in the BMS script (assuming you're talking about "dead_space_3.bms"), but what "dk2" refers to is anyones guess, a quick search online doesn't yield much information.

Tried making a database for every "*.STR" archive using the BMS script and it seems like bms2xtl is working as it can find functions in the console output, but no ".XTL" database is generated, not sure if this is the same issue you experienced but its a tad odd.

Bms2xtl will not generate database files for data sets stored with no compression.
I don't know what the script does but for the sample you provided because when you extract the streams using quickbms without bms2xtl, they produce the exact same size as if compression was set to none.

Interesting, so I'm guessing this means that xmemcompress isn't the algorithim being used on the sample (I'd also wager this could be extrapolated to apply to other "*.STR" archives, at least in the case of Dead Space 1, given that was one of the larger "STR" archives).

I'm starting to think whatever this "DK2" algorithm turns out to be is likely to be the key to recompressing these archives.

"DK2" is probably Dungeon Keeper 2. (I googled for "dk2" "quickbms".)