FileForums

FileForums (https://fileforums.com/index.php)
-   Conversion Tutorials (https://fileforums.com/forumdisplay.php?f=55)
-   -   [Dev]XTool (https://fileforums.com/showthread.php?t=101613)

darkwolves 24-04-2018 13:32

the cpk.bms has nothing whatsoever to do with actual inflation it is designed to extract and decompress the file hence the bigger size that is not inflation that is just a result of decompiling the data..

RamiroCruzo 25-04-2018 06:26

Quote:

Originally Posted by darkwolves (Post 470492)
the cpk.bms has nothing whatsoever to do with actual inflation it is designed to extract and decompress the file hence the bigger size that is not inflation that is just a result of decompiling the data..

Ouch...You really shouldn't reply when you don't know, each file extracted by cpk.bms is infact a Crilayla stream which is extracted by XTool too, so apart from size of tables in .cpk files, their results are identical unless there is encryption on top of streams.

darkwolves 26-04-2018 17:08

Quote:

Originally Posted by RamiroCruzo (Post 470497)
Ouch...You really shouldn't reply when you don't know, each file extracted by cpk.bms is infact a Crilayla stream which is extracted by XTool too, so apart from size of tables in .cpk files, their results are identical unless there is encryption on top of streams.

ok whatever you say i've been using it for a long time i believe what i see from my own personal experiments not what people tell me

Razor12911 26-04-2018 21:32

Quote:

Originally Posted by Andu21 (Post 470375)
Razor, why this happens? Shouldn't the compressed output be less?

Code:

TombRaider_Beginning.pcf                                4.92 GB > 491 MB
TombRaider_Beginning.xtl                                4.99 GB > 660 MB


Can you rerun the test using 0.2, thanks in advance

@Shiv, Ramiro and darkwolves
From my personal experience with crilayla, what darkwolves is saying is right but I'm not going through that source, it's exhausting to translate all that stuff to Delphi, however what Ramiro and Shiv are saying is also correct to a certain extent, it's the same thing, it only differs if the the stream do not start with CRILAYLA, either because they are encrypted or it's just missing, there were a few samples I have received where instead of CRILAYLA header you just find a null header, in this case, xtool approach will not work. But keep up with the debate, it's good.

darkwolves 26-04-2018 23:04

Quote:

Originally Posted by Razor12911 (Post 470516)
Can you rerun the test using 0.2, thanks in advance

@Shiv, Ramiro and darkwolves
From my personal experience with crilayla, what darkwolves is saying is right but I'm not going through that source, it's exhausting to translate all that stuff to Delphi, however what Ramiro and Shiv are saying is also correct to a certain extent, it's the same thing, it only differs if the the stream do not start with CRILAYLA, either because they are encrypted or it's just missing, there were a few samples I have received where instead of CRILAYLA header you just find a null header, in this case, xtool approach will not work. But keep up with the debate, it's good.

i been repacking crilayla games for some time now its funny this is like the third time someone has said i was wrong and razor came in later and told them i was right lol

ShivShubh 26-04-2018 23:52

Quote:

Originally Posted by darkwolves (Post 470520)
i been repacking crilayla games for some time now its funny this is like the third time someone has said i was wrong and razor came in later and told them i was right lol

Or maybe there was just a misunderstanding ? Because I can't properly understand what you are trying to say by this :-

Code:

the cpk.bms has nothing whatsoever to do with actual inflation it is designed to extract and decompress the file hence the bigger size that is not inflation that is just a result of decompiling the data..
CPK bms by aluigi has the algorithm (comtype cpk) decompression function, the compressed streams are actually decompressed during the extraction process which is equivalent to the inflation done by XTool.

Quote:

Originally Posted by Andu21 (Post 470375)
Razor, why this happens? Shouldn't the compressed output be less?

TombRaider_Beginning.pcf 4.92 GB > 491 MB
TombRaider_Beginning.xtl 4.99 GB > 660 MB

Quote:

Originally Posted by Razor12911 (Post 470516)
Can you rerun the test using 0.2, thanks in advance

Results made using XTool 0.2 on TombRaider_Beginning.pdf (904 MB)

Code:

PDF (904 MB) --> precomp (4.92 GB) --> 4x4:b32m:t4:lzma (550 MB)
PDF (904 MB) --> xtool, c32m (4.98 GB) --> 4x4:b32m:t4:lzma (710 MB)
PDF (904 MB) --> xtool, c256m (5.05 GB) --> 4x4:b32m:t4:lzma (686 MB)

Seems like other pdf files will produce similar differences. Precomp has inbuilt PDF scanner so it is able to properly scan and inflate all the PDF streams hence the better output.

darkwolves 27-04-2018 01:53

because it is designed to decompile and extract once extracted it no longer even reads as a cpk file until it is recompressed and encrypted with a cpk tool it would take razor forever to be able to read through all that data and try implementing it into xtool

ShivShubh 27-04-2018 02:29

Quote:

Originally Posted by darkwolves (Post 470524)
because it is designed to decompile and extract once extracted it no longer even reads as a cpk file until it is recompressed and encrypted with a cpk tool it would take razor forever to be able to read through all that data and try implementing it into xtool

Why would it be able to read as cpk file after extraction ? Its obvious it wont be read as CPK. And as far as I think XTool's crilayla is based on cpk bms thats why there's no x64 build for it.

darkwolves 27-04-2018 03:32

Quote:

Originally Posted by ShivShubh (Post 470525)
Why would it be able to read as cpk file after extraction ? Its obvious it wont be read as CPK. And as far as I think XTool's crilayla is based on cpk bms thats why there's no x64 build for it.

if it is extracted it needs to be recompressed by a cpk tool the way razor is making it is were the file inflates not extracts he even said above
how exhausting it is to have to translate all of that

ShivShubh 27-04-2018 04:19

Quote:

Originally Posted by darkwolves (Post 470531)
he even said above how exhausting it is to have to translate all of that

You understood that incorrectly, he meant to say it is exhausting to translate CPK's BMS language into Delphi which is a totally different thing.

darkwolves 27-04-2018 09:44

Quote:

Originally Posted by ShivShubh (Post 470533)
You understood that incorrectly, he meant to say it is exhausting to translate CPK's BMS language into Delphi which is a totally different thing.

oh no i understood that very correctly considering... i have done that enough myself trying to develop my own tool for it his way is faster and its easier so him using a cpk bms would only hinder him and make the project take longer.... and it would only work to a point because some cpk games will not even work with the bms i began using a different tool that extracts all cpk files as well as viewing the content within deeming the cpk bms unreliable

shazzla 01-05-2018 02:46

@Razor12911

its not about ratio ,just for the records :)

XTool V0.2 x64

[External compressor:xprecomp]
header = 0
packcmd = xtool.exe e:precomp:c64mb,t75p:zlib - - <stdin> <stdout>
unpackcmd = xtool.exe d:precomp:t75p - - <stdin> <stdout>

arc a -mxprecomp p:\x.arc "d:\00_win32_audio.zip"

FreeArc 0.67 (March 15 2014) creating archive: p:\x.arc
Compressed 1 file, 1,870,559,418 => 1,870,559,726 bytes. Ratio 100.00%
Compression time: cpu 3.23 sec/real 67.89 sec = 5%. Speed 27.55 mB/s
All OK

arc t p:\x.arc

FreeArc 0.67 (March 15 2014) testing archive: p:\x.arc
Testing 1 file, 1,870,559,418 bytes. Processed 89.0%WARNING: CRC failed in "00_win32_audio.zip".
Tested 1 file, 1,870,559,726 => 1,870,559,418 bytes. Ratio 100.00%
Testing time: cpu 1.78 sec/real 2.32 sec = 77%. Speed 804.75 mB/s
There were 1 warning(s)

dataset : (1.74GB)

https://mega.nz/#!g4phDAiZ!bUFwMndnl...9i3Mnf3PclAKi8

darkwolves 03-05-2018 10:30

@shazzla

i just use msc+srep+lzma on those files and call it a day lol

ZakirAhmad 12-05-2018 09:32

@razor. i tried xtools zlib preprocessor against sevral game files like tomb raider 2013, mass effect 3, splinter cell etc. in all cases, in all cases it produced same result as is produced by precomp042 and also performed better than ztool (speed as well as precompression). hence, i consider it stable.

Razor12911 26-05-2018 15:17

Can someone upload samples from games that utilize Anvil Engine, thank you.

Those
https://en.wikipedia.org/wiki/AnvilNext


All times are GMT -7. The time now is 07:23.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2026, vBulletin Solutions Inc.
FileForums @ https://fileforums.com