ZenHAX

i want rip the music from this game,but how could i extract file from the .toc.w32 file archive ?(sorry about my poor english T-T)
FILE sampler:
https://mega.nz/#!bFdwHSbB!3kX5BUiyBqillrnaPfxT7-rO3r6118Kc4vw5827q71I

http://aluigi.org/bms/trickstar.bms

If you get any error (but even if you don't!) use this script on chunks.big.w32 and chunks1.big.w32, then upload the 4 generated files:
http://aluigi.org/bms/filecutter.bms

thanks for your help，but it does not work T-T,and here is the link for the 4 generated files:https://yadi.sk/d/viFz6mxe3RCnSN

Script 0.2

Note that some extracted files with dat extension are some sort of archives, they contain DDS and other stuff.

error……T-T

 offset   filesize   filename
--------------------------------------
- enter in folder E:\final
  coverage file 0     0%   0          2096698944 . offset 00000000
- open input file E:\final\chunks.toc.w32
- enter in folder E:\final
- open input file E:\final\chunks.toc.names w32
- enter in folder E:\final
- open input file E:\final\chunks.big.w32
  3752b4c0 9552       00000000.dat
- enter in folder E:\final
  coverage file 1     0%   9616       2096698944 . offset 00000000
- open input file E:\final\chunks1.big.w32
  0d963740 49888      00000001.dat
- enter in folder E:\final
  coverage file 1     0%   49952      1674576832 . offset 00000000
- open input file E:\final\chunks.big.w32
  00000000 50         00000002.dat

Error: incomplete input file -1:
       Can't read 50 bytes from offset 00000000.
       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.


Last script line before the error or that produced the error:
  74  log "" 0 SIZE MEMORY_FILE

- select the BMS script to use
- select the input archives/files to extract, type * or "" for whole folder and subfolders
- select the output folder where extracting the files
- open input file E:\final\chunks1.big.w32
- open script E:\final\trickstar(1).bms
- set output folder E:\hero rip

  offset   filesize   filename
--------------------------------------
- enter in folder E:\final
  coverage file 0     0%   0          1674576832 . offset 00000000
- open input file E:\final\chunks1.toc.w32

- error in src\file.c line 256: fdnum_open()
Error: No such file or directory

Last script line before the error or that produced the error:
  12  open FDSE TMP

Press ENTER or close the window to quit

The second error is correct because you must open only the toc or the first big file (no need to "improve" the script to remove the '1' from the name).

While for the first issue I have no idea since I don't have the full files and the script is correct.
There is only one field that doesn't have sense (NUM) but it didn't seem to affect anything.

Maybe try running quickbms with the -V option and paste the final 100 lines

the full filehttps://mega.nz/#!LY9BkK5Z!Jpp9NRwq_4F9_IigAQahdRXoIgCPq0uzzDhg0pljqzo

The bug was a stupid typo in the script, I used "CHUNKS" instead of "SIZE" in one instruction... yeah sometimes it happens.
Script 0.2.1.

Since now I have the full files let me know if there is something strange, not working or wrong and I can check it.

I have made another update for the script.

I have also tested a new option of quickbms that dumps the content of the unparsed data of the input file and there is big amount of such data, maybe I will check it again later but don't know.

Thanks！It works！You are my hero！！！！

Unfortunately the script is not complete yet.
There is a lot of data that is not extracted.

Finally I'm back with an update.
Now the whole 100% of the input file is extracted so problem solved

Still remain some "misteries" that don't affect the current extraction like:

• why the ZSIZE field is ever smaller than the real one, it's necessary to trust only the SIZE one
• the SIZE2 field looks like a sort of additional content of the same file (for example a DDS image), it was the cause of the incomplete coverage of the archive in previous script
• the NUM field which looks totally useless
• there are some extracted files with "dat" extension that are small archives, they have no "magic" identifier so no way to avoid false positives trying to parse them, anyway the script can extract them if you open one of them (one of the correct ones)

Script 0.4.
Now the names of the files are their name hash, better than the sequential number used before I guess.

P.S.: the files with "vap" extension contain the string "dwnDxtBitmap" in them, in case it's useful. "trr" files have the "trrn" magic and contain various IPD1 files and the "HUNK" string. "cl5" files have an "HUNK" string too at offset 0x10. The remaining "dat" are those sort of archives that you can extract using the same script on them. "fsb" obviously are a job for fsbext

I have released a new version of the script that works exactly like version 0.4, so you DO NOT need to re-download it.
I tell you just in case you see it and think it's "better", no it's the same result

It simply uses a feature of quickbms 0.8.3 for handling the multiple archives without "sorting" the information first, and dumps the chunked files directly to disk rather than rebuilding in a MEMORY_FILE (it may work in reimport mode).