AFR (Anvil Forge Recompressor)

[oltjon]

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]

Here is the recent version, credit to Edison007.

[oltjon]

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]

Thank you. Wasn't aware of that.

Will test soon.

[KaktoR]

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.


Unpacking time was slower than standard compression, but not that much: ~2 minutes more.

MD5 Check was fine too.

Will test some more.

[KaktoR]

Another test with very big data

-------------------------------------------------------------------
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]

Another test. Previous test was OK (see Edit).

-------------------------------------------------------------------
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]

Doesn't work for Origins. Well, Origins use a different engine. Maybe 2.5 or 3.0

[Andu21]

The author is working on that, there's an alpha version if you want to try.

[KaktoR]

Can't read russian properly. Could you link me the file with PM or a direct link?

[KaktoR]

Any progress of it?

Or is it now just private like other tools?

[doofoo24]

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]

Originally Posted by doofoo24

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]

Originally Posted by Simorq

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]

Originally Posted by doofoo24

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.