FileForums
Page 1 of 3 1 23
Show 40 post(s) from this thread on one page

FileForums (https://fileforums.com/index.php)
-   Conversion Tutorials (https://fileforums.com/forumdisplay.php?f=55)
-   -   AFR (Anvil Forge Recompressor) (https://fileforums.com/showthread.php?t=99628)

oltjon 16-10-2017 16:17
AFR (Anvil Forge Recompressor)
 
AFR (Anvil Forge Recompressor) - The forge-container recompressor

A recompressor for .forge (scimitar) containers from games on the Anvil Engine (mostly Assassin's creed series).
Implemented multi-threaded recovery and cls-filter for FreeArc.
cls-afr.dll supports the Threads key in the cls.ini file - specifies the number of threads to restore. Default: NumCPU-1, maximum: 16.


// Comparison with a 64-bit version of ztool (plzo).
Unpacking time:

tell your opinions


thanks Edison007 for this tool


https://mega.nz/#!9yRlybYB!D_U30YjAN...LAXwbJHpEV-9lA

danswano 18-10-2017 11:38
1 Attachment(s)
Here is the recent version, credit to Edison007.

oltjon 22-10-2017 05:32
1 Attachment(s)
small update.

added -dc option (disables LZO check for decompression, processing is slightly faster, but on broken (?) archives with it will be APPCRASH).
added in some places of verification.
code refactoring.
cosmetic changes.
added to the set arc.ini (I did not think that it would be difficult to write one line in the ini, meh).

credit to Edison007.

KaktoR 22-10-2017 06:00
Thank you. Wasn't aware of that.

Will test soon.

KaktoR 01-11-2017 09:14
Code:
afr:a2
Compressed block count (subblocks) = 4168 (59251)
LZO1X-W3(15) subblocks count      = 0
LZO1X-999 subblocks count          = 41043
LZO2A-999 subblocks count          = 0
LZO1C-999 subblocks count          = 0
Uncompressed subblocks count      = 18208

Compressed subblocks size:  981113389 -> 1323071148
Uncompressed subblocks size: 505081644
Other data size:            1399003

Total data+table:            1487831040 -> 1830059387

WARNING! In file found corrupted LZO-streams. Check your data!
Edit:
Compression time with AFR:a2 was quiet fast, only ~2 minutes more.
https://i.imgur.com/g7umKUY.png

Unpacking time was slower than standard compression, but not that much: ~2 minutes more.
https://i.imgur.com/AIz7PqD.png
MD5 Check was fine too.

Will test some more.

KaktoR 01-11-2017 11:01
Another test with very big data

Code:
-------------------------------------------------------------------
Compressed block count (subblocks) = 196168 (1276451)
LZO1X-W3(15) subblocks count      = 16738
LZO1X-999 subblocks count          = 1068641
LZO2A-999 subblocks count          = 0
LZO1C-999 subblocks count          = 0
Uncompressed subblocks count      = 191072

Compressed subblocks size:  15970647521 -> 32687257445
Uncompressed subblocks size: 3858606509
Other data size:            151950822

Total data+table:            19986310656 -> 36709629424

WARNING! In file found corrupted LZO-streams. Check your data!

Time: 1634.073 secs


Errorlevel=0
  9.9%
Compressing 36,709,341,539 bytes with _Compressors\SREP64 -m3f Input Output
  9.9%SREP 3.92 beta (July 23, 2013): input size 35008 mb, memory used 2713 mb, -m3f -l512 -c512 -a4/4 -hash=vmac -b8mb
100%: 36,709,341,539 -> 15,088,619,311: 41.10%.  Cpu 170 mb/s (205.688 sec), real 103 mb/s (339.510 sec)  9.9%
Sorting matches... Second pass 100.0%
Will report back soon...

Edit: Unpacking was OK, but took over 30 minutes (unfortunately haven't count the time exactly...).

KaktoR 01-11-2017 16:01
Another test. Previous test was OK (see Edit).

Code:
-------------------------------------------------------------------
Compressed block count (subblocks) = 300214 (1181278)
LZO1X-W3(15) subblocks count      = 0
LZO1X-999 subblocks count          = 942635
LZO2A-999 subblocks count          = 0
LZO1C-999 subblocks count          = 0
Uncompressed subblocks count      = 238643

Compressed subblocks size:  14949576065 -> 25849003845
Uncompressed subblocks size: 4192660686
Other data size:            822001363

Total data+table:            19968963226 -> 30875715102

WARNING! In file found corrupted LZO-streams. Check your data!

Time: 1356.039 secs


Errorlevel=0
 10.0%
Compressing 30,875,131,802 bytes with _Compressors\SREP64 -m3f Input Output
 10.0%SREP 3.92 beta (July 23, 2013): input size 29444 mb, memory used 2196 mb, -m3f -l512 -c512 -a4/4 -hash=vmac -b8mb
100%: 30,875,131,802 -> 7,407,115,894: 23.99%.  Cpu 192 mb/s (153.406 sec), real 104 mb/s (283.003 sec) 10.0%    %
Sorting matches... Second pass 100.0%

KaktoR 02-11-2017 06:19
Doesn't work for Origins. Well, Origins use a different engine. Maybe 2.5 or 3.0

Andu21 02-11-2017 07:16
The author is working on that, there's an alpha version if you want to try.

KaktoR 02-11-2017 08:10
Can't read russian properly. Could you link me the file with PM or a direct link?

KaktoR 06-12-2017 07:07
Any progress of it?

Or is it now just private like other tools?

doofoo24 24-12-2017 22:36
testing afr:a2 on ac unity and syndicate forge file...
ac uinty afr:a2 40.1gb to 51.3gb with srep+lzma 27.5gb
ac syndicate 54.2gb to 84.4gb with srep+lzma 13.1gb
work great...
the setting afr:a2+srep:m3f:a2+lzma:a1:mfbt4:d384m:fb273:mc100 00:lc8

* note if i use 4x4:lzma the setup always crash while if i use ztool with 4x4:lzma it mange to decompress faster...
GREAT TOOL AFR is there update to work on game like far cry 4/wath dog ?

Simorq 25-12-2017 05:52
Quote:
Originally Posted by doofoo24 (Post 465188)
testing afr:a2 on ac unity and syndicate forge file...
ac uinty afr:a2 40.1gb to 51.3gb with srep+lzma 27.5gb
ac syndicate 54.2gb to 84.4gb with srep+lzma 13.1gb
work great...
the setting afr:a2+srep:m3f:a2+lzma:a1:mfbt4:d384m:fb273:mc100 00:lc8

* note if i use 4x4:lzma the setup always crash while if i use ztool with 4x4:lzma it mange to decompress faster...
GREAT TOOL AFR is there update to work on game like far cry 4/wath dog ?
SrepInit('',512,0) to SrepInit('',128,0) no crash

doofoo24 25-12-2017 07:26
Quote:
Originally Posted by Simorq (Post 465191)
SrepInit('',512,0) to SrepInit('',128,0) no crash
but it will write more temp data and will take more time, the whole point for using 4x4 is to increase speed and save time btw i'm using 1024 for srep...

Simorq 25-12-2017 08:20
Quote:
Originally Posted by doofoo24 (Post 465192)
but it will write more temp data and will take more time, the whole point for using 4x4 is to increase speed and save time btw i'm using 1024 for srep...
There is not much difference between 1024 and 128.
More speed is achieved with Srep64.


All times are GMT -7. The time now is 15:14.
Page 1 of 3 1 23
Show 40 post(s) from this thread on one page

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