Tomb Raider Legend - sample files

[AnonBaiter]

Perhaps I shouldn't have sticked with the option of having to concatenate the files into one the first place...

[aluigi]

My mistake on the previous calculation, the correct offset+size was 0x09433000 + 1147008 which is 0x954b080 which is the exact size of layer1.000, BUT the next offset (used by layer1.001) is 0x09000000 and not 0x954b080.
I think I can instruct the script to work on this mess, stay update.

[aluigi]

Script 0.2
Use it on layer1.000 and it will do everything by itself.

[AnonBaiter]

The script is a lot better now! Thanks mate.

[AnonBaiter]

tomb.raider.legend_xbox360_dll.rar

Just now I found out that the XBOX360 version of Legend had these .dll files. Since these are actually XEX2 files, I just thought that maybe it will lead to something interesting so I decided to post them here.

Oh, and the archive files on said version also contain some seemingly encrypted/compressed/obfuscated files so I might as well post it here.

[AnonBaiter]

Double post, but in case of compartibility problems here are the samples:

layer1_xbox360.rar
layer2_xbox360.rar

And if you want some context on what I mean by "compartibility problems", see here:

Code: Select all

. 0000000000002076
. 00000000 getarr  OFFSET     0x000000007e9f2800 0:8310
. 00000000 getarr  SIZE       0x000000000152dbce 1:8310
. 00000000 getarr  LANG_ID    0x00000000ffffffff 2:8310
. 00000000 getarr  NAME_CRC   0x00000000077d3b58 3:8310
  000000007e9f2800 22207438   FFFFFFFF/077D3B58.dat

Error: incomplete input file 0: E:\TRL\XBOX360\layer1.000
       Can't read 602112 bytes from offset 000000007fc5f800.
       Anyway don't worry, it's possible that the BMS script has been written
       to exit in this way if it's reached the end of the archive so check it
       or contact its author or verify that all the files have been extracted.
       Please check the following coverage information to know if it's ok.

  coverage file 0   155%   3333192935 2143680512

Last script line before the error or that produced the error:
  59  log NAME OFFSET SIZE

[aluigi]

There is no LANG_ID field in my script so you are using something else.

[AnonBaiter]

Oh, my mistake. I was using an edited script.
Anyway, here's the error from an unmodifieds script:

Code: Select all

.
. 0000000000002076
. 00000000 getarr  OFFSET     0x000000007e9f2800 0:8310
. 00000000 getarr  SIZE       0x000000000152dbce 1:8310
  000000007e9f2800 22207438   0000000000002076.dat

Error: incomplete input file 0: E:\TRL\XBOX360\layer1.000
       Can't read 602112 bytes from offset 000000007fc5f800.
       Anyway don't worry, it's possible that the BMS script has been written
       to exit in this way if it's reached the end of the archive so check it
       or contact its author or verify that all the files have been extracted.
       Please check the following coverage information to know if it's ok.

  coverage file 0   155%   3333192935 2143680512

Last script line before the error or that produced the error:
  51  log "" OFFSET SIZE

Besides, the modified script makes no difference when run into quickbms aside from a few tweaks(DUMMY being LANG_ID, etc.)

[aluigi]

It's impossible that you are still parsing the archive layer1.000 if you are extracting the file 0x2076 (layer1.001 is loaded from file 0x1e7 and layer1.002 from 0.376), the archives are open sequentially so you can't have a 000.
And it's not possible to have the offset 0x7e9f2800.

In my opinion you are still using a wrong script.

[AnonBaiter]

Ehh...
But these files came from the XBOX360 version, so what are you trying to say?

Code: Select all

28/08/2016  01:26    <DIR>          $SystemUpdate
28/08/2016  01:26           397.312 amahlin.dll
28/08/2016  01:26           462.848 bolivia.dll
28/08/2016  01:26           135.168 boliviaredux.dll
28/08/2016  01:26           102.400 comp_entry.dll
28/08/2016  01:26           102.400 comp_exit.dll
28/08/2016  01:26           102.400 container.dll
28/08/2016  01:26         9.973.760 default.xex
28/08/2016  01:26           430.080 flashback.dll
28/08/2016  01:26           364.544 grave.dll
28/08/2016  01:26           331.776 himalayas.dll
28/08/2016  01:26           102.400 lara_depot.dll
28/08/2016  01:29     2.143.680.512 layer1.000
28/08/2016  01:30     1.105.502.208 layer1.001
28/08/2016  01:33     2.137.892.864 layer2.000
28/08/2016  01:35     1.383.538.688 layer2.001
28/08/2016  01:35           299.008 mansion.dll
28/08/2016  01:35    <DIR>          movies
28/08/2016  01:35           692.224 russia.dll
28/08/2016  01:35           331.776 tokyo.dll
28/08/2016  01:35           299.008 vehonehub.dll
28/08/2016  01:35           266.240 vtrainhub.dll

Or perhaps you could be right... in any case, do you have any suggestions?

[aluigi]

Here I have the 16 samples that you provided, those with the size capped at about 150Mb, is this a different version?

[AnonBaiter]

Yes. I even stated it came from the XBOX360 version.

[aluigi]

Try script 0.2.1.
These archives used zlib compression, that's the reason of the reading error (read SIZE bytes instead of read ZSIZE bytes).

[AnonBaiter]

Now it works! Thanks mate.
Now onto the next games(Anniversary, Underworld)...

[AnonBaiter]

Here is a sample of all .mul files from their respective versions. I heard there was a tool that could decode .mul files, but that's just the PC version.

Just to clarify, there are two files for each version: one for the FFFF flag, and the other for the 0000 flag.

The FFFF flag means that there are no loops; the audio file is played at one time.
The 0000 flag means that there might be looping instances; the audio file is played more than one time and might contain some markers.

They were tagged this way for recognizing which one is looped and which one is not. Besides, the files themselves are actually some kind of multiplexed audio format.

EDIT: Without further ado, here's the unfinished script:

Code: Select all

math ADPCM_FORMAT = 2 # 1 is for Gamecube, 2 is for PlayStation 2, 3 is for Xbox and PC
math XBOX360_FORMAT = 0 # the mul block byte varies between 0x20 and 0x10(and sometimes more than that), which can get confusing very fast
math BITS = 4

get FREQUENCY long
get LOOP_INDICATOR long
get TOTAL_SAMPLES long
get CHANNELS long
get FSIZE asize
putvarchr MEMORY_FILE FSIZE 0
log MEMORY_FILE 0 0

for l = 0 < CHANNELS
   putvarchr MEMORY_FILE FSIZE 0
   log MEMORY_FILE 0 0
   putvarchr MEMORY_FILE2 FSIZE 0
   log MEMORY_FILE2 0 0
   putvarchr MEMORY_FILE3 FSIZE 0
   log MEMORY_FILE3 0 0
   set OFFSET 0x800
   set EXTRA 0x10
   do
      goto OFFSET
      getdstring DUMMY EXTRA
      set EXTRA 0
      get SIZE long
      if SIZE > FSIZE
         break
      endif
      get LAYER long
      get DUMMY2 longlong
      savepos OFFSET
   while OFFSET < FSIZE
next l

/*
getdstring ZERO 0x18
set OFFSET 0x800 # was originally get OFFSET long
get ZERO longlong
get DUMMY long # I can't figure out what that thing does
getdstring CHANNEL_BLOCKSIZES 0x90
if ADPCM_FORMAT == 1
   getdstring COEFF_LEFT 0x2E
   getdstring COEFF_RIGHT 0x2E
else
   break
endif

if ADPCM_FORMAT == 1
   getdstring MUL_BLOCK 0x40
elif ADPCM_FORMAT == 2
   getdstring MUL_BLOCK 0x20
else
   break
endif
*/

[AnonBaiter]

Well, the Xbox and PC versions nearly use the same codec so I had to increase that number to 3 to avoid confusion. Sorry.

[aluigi]

The "endian guess" in your previous script is wrong because there is no argument: endian guess VARIABLE

[AnonBaiter]

[AnonBaiter]

Here is a sample of the PS3 version of Tomb Raider Underworld.

The reason I`m uploading this is because the extracted output out of the BIGFILE.### files in the PS3 version has some weird offsets and sizes in them. For example, a !WAR file on BIGFILE.000 has this 0x5dff000 offset as shown by the script rather than the supposed offset of the file(0x5d9c000).

Sorry if I took so long to reply, I just wanted to catch what was missing.