This topic was archived here:

https://web.archive.org/web/20230000000000fw_/https://www.zenhax.com/viewtopic.php?t=7119

kofismyfan, posted Thu Dec 21, 2017 12:15 pm (30941)

---

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

aluigi, posted Mon Jan 01, 2018 4:13 pm (31188)

---

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

kofismyfan, posted Fri Jan 05, 2018 6:39 am (31306)

---

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

aluigi, posted Fri Jan 05, 2018 8:16 am (31309)

---

Script 0.2

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

kofismyfan, posted Mon Jan 08, 2018 1:44 am (31391)

---

error::T-T

Code:

 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

Code:

- 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

aluigi, posted Mon Jan 08, 2018 1:38 pm (31412)

---

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

kofismyfan, posted Wed Jan 10, 2018 1:45 am (31445)

---

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

aluigi, posted Thu Jan 11, 2018 9:52 am (31455)

---

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.

aluigi, posted Thu Jan 11, 2018 12:33 pm (31457)

---

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.

kofismyfan, posted Sat Jan 13, 2018 1:00 pm (31507)

---

Thanks!It works!You are my hero!!!!

aluigi, posted Sat Jan 13, 2018 2:32 pm (31510)

---

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

aluigi, posted Mon Jan 15, 2018 6:18 pm (31579)

---

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

aluigi, posted Mon Jan 22, 2018 9:14 am (31794)

---

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).