This topic was archived here:

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

tyrannojones, posted Wed Dec 14, 2016 8:35 pm (19504)

---

Hey there! Would someone be able to perhaps take a look into these .pac files? Looking for a way to get at the assets inside... It appears to be using a different compression method to the NTSC version of the game, which I find interesting!

https://mega.nz/#F!nZ4V0TqC!sKjWNJu1VTrpkowRTa288Q

aluigi, posted Thu Dec 15, 2016 9:24 am (19509)

---

It's the known add_pac format:
http://aluigi.org/bms/add_pac.bms

Acewell, posted Thu Dec 15, 2016 11:24 am (19511)

---

viewtopic.php?f=9&t=457

even if you extract the files from the pac they are compressed with what looks like lzs
but this lzs bms script doesn't work on them even though it follows the structure perfectly.

http://aluigi.altervista.org/bms/lzs.bms

and daemon1 seems to have it figured out but has not told how to
http://forum.xentax.com/viewtopic.php?p=125101#p125101

aluigi, posted Thu Dec 15, 2016 2:39 pm (19526)

---

Keep us updated when the doubt about the compression is solved.

id-daemon, posted Thu Dec 15, 2016 3:10 pm (19532)

---

Acewell wrote:

and daemon1 seems to have it figured out but has not told how to

I didnt even had a chance to say anything! You expect me to answer in the middle of a night?

id-daemon, posted Thu Dec 15, 2016 3:38 pm (19533)

---

Ok i had some food, and now I can answer!

This is what I did:

I took the quickbms LZS code, and rewritten it looking at the file data. It was all done correct, as luigi's code describes. So I don't know why script is not working, maybe some endianess issue.

Acewell, posted Thu Dec 15, 2016 3:45 pm (19534)

---

id-daemon wrote:

I didnt even had a chance to say anything!

sure you did, you made that post yesterday in a thread about compression
without saying anything about how you solved the decompression problem!

id-daemon, posted Thu Dec 15, 2016 4:21 pm (19537)

---

Acewell wrote:

sure you did, you made that post yesterday

You didn't ask me at that time!

Acewell, posted Thu Dec 15, 2016 5:37 pm (19544)

---

aluigi wrote:

Keep us updated when the doubt about the compression is solved.

nothing definitive, just endianess speculation, is that enough to work with?
i think its just not possible and i'm convinced daemon1 is practicing witchcraft, this is the only logical explanation

id-daemon, posted Thu Dec 15, 2016 6:08 pm (19550)

---

Acewell wrote:

daemon1 is practicing witchcraft

I'm practicing Zen, not witchcraft

Acewell, posted Sat Dec 17, 2016 1:06 pm (19609)

---

aluigi, i think there may be a problem with LZS decompression in QuickBMS,
i searched for other scripts and formats that use it and can't find anything
that extracted successfully to compare against though.

daemon1 basically says he is doing nothing out of the ordinary with the LZS decompression
and he is actually using your code translated to a programming language, see here
http://forum.xentax.com/viewtopic.php?p=125188#p125188


this is the error i'm seeing using "comtype LZS DICT DICT_SIZE" in the lzs.bms script

Code:

Info:  algorithm   159
       offset      0000002e
       input size  0x000e3170 930160
       output size 0x0025129d 2429597
       result      0xffffffff -1

Error: the uncompressed data (-1) is bigger than the allocated buffer (2429597)

Last script line before the error or that produced the error:
  35  clog NAME OFFSET ZSIZE SIZE

with this file included in the attached samples
ch01a_00.dae
but the other samples are producing the same error


help me obi-aluigi, you're my only hope!

id-daemon, posted Sat Dec 17, 2016 2:03 pm (19611)

---

Acewell wrote:

and he is actually using your code translated to a programming language

I used c# instead of c Luigi used, because its better for me. Quickbms decompression routine was also surely written in programming language.

If I can help in something more, let me know.

aluigi, posted Sat Dec 17, 2016 4:38 pm (19614)

---

Well, there is HUGE difference which is clearly visible... there is a 16bit swapping of the data!
In fact if you add "encryption swap 16" before clog in my script it works perfectly.
Now the question is: what bit of the flag at offset 4 says that the data is swapped?

Maybe it works with the endianess of the file? In that case it's a joke to fix it but I want to know if it's sure at 100%

aluigi, posted Sat Dec 17, 2016 4:44 pm (19615)

---

In the meantime I have updated the script to version 0.1.2 with that modification I said above (all the rest of the script is original).
Maybe in the next version of quickbms I can make the lzs_unzip() code compatible with the current endianess of the script, just to make it automatic without the "encryption" command.

Acewell, posted Sat Dec 17, 2016 9:20 pm (19628)

---

aluigi wrote:

In fact if you add "encryption swap 16" before clog in my script it works perfectly.

problem solved thank you, i think this is the first time i've seen that used, i learned something new.
this works with "lzs_unzip" but not "lzs", what is the difference between the two?

aluigi wrote:

Well, there is HUGE difference which is clearly visible... there is a 16bit swapping of the data!

where do you see this 16bit swapping

aluigi, posted Sat Dec 17, 2016 10:44 pm (19629)

---

lzs_unzip and lzs (mppc) are different algorithms.

The 16bit swapping is the part of code after "then reading the whole data block into memory"

id-daemon, posted Sun Dec 18, 2016 12:53 pm (19653)

---

Acewell wrote:

where do you see this 16bit swapping

Its the simple endianess, like I suspected. When reading every 2 bytes, you read them in different order. Its called endianess.

Acewell, posted Sun Dec 18, 2016 1:44 pm (19658)

---

id-daemon wrote:

Its the simple endianess, like I suspected. When reading every 2 bytes, you read them in different order. Its called endianess.

right, but i don't know C, C or C# programming languages, only the bits that look like python.

this is what i was hoping for when you posted your source, that someone else could spot
the difference between your code and the capabilities of QuickBMS and the bms script.

i'm a bit confused about why the endianess (big) didn't take from earlier in the script though,
unless "lzs_unzip" only decompresses little(?) endian by design or something

aluigi, posted Sun Dec 18, 2016 1:56 pm (19660)

---

Regarding the endianess I'm quite sure that the difference is in the code used by the developers and the one used in quickbms (not written by me).
In the former they have probably just used value=(16bit)data which means that the endianess of that value is dependent by the one of the system while in quickbms it's forced in little endian (data[0] | data[1]
Why this has not been spotted before?
Simple, the available samples

id-daemon, posted Sun Dec 18, 2016 2:40 pm (19664)

---

Model tool viewtopic.php?f=5&t=3569