» FreeArc (часть 4)

В основном проблема между методами tor:6 и lzma:fast. Здесь зазор заполнять нечем.

Добавлено:
У меня
84 = rep:1gb+4x4:tor:6:4mb:h8mb
85 = rep:1g+xlzma:4mb:h512k:fast:128:mc8

Где я пытался сколько можно ускорить Lzma:fast

Добавлено:
Здесь перечислял:
http://forum.ru-board.com/topic.cgi?forum=5&topic=35164&start=1260#19

Ваше мнение?
http://sourceforge.net/projects/sevenzip/forums/forum/45797/topic/3327567

The unarchiver project has an implementation of WinZip JPEG compression.
http://code.google.com/p/theunarchiver/source/browse/#hg%2FXADMaster%2FWinZipJPEG

UriF
записал в планы на 0.75, заодно и wavpack делать придётся. кстати, имей в виду - там только распаковка

У меня архив проходит тестирование, но при распаковке происходит ошибка. Это ведь не нормально? (FA 0.67a)

vishyakov
а у меня подпольный стук

vishyakov
Т. е. не молчите, скажите больше существенных (с вашей точки зрения) подробностей: какая ошибка, как часто появляется, как возможно её воспроизвести (подробно), какой архив и можете ли вы его приватно выложить Булату.

new alpha version:

-mc option: new ways to modify compression method by adding/replacing/removing specified algorithms
Compression page: added "Experimental compressors" frame
arc.ini: updated for precomp042/srep3 compatibility
precomp 0.4.2 and srep 3.0 executables added to the FreeArc\bin directory


Цитата:

New syntax of -mc option (backward-compatible with the old one):

-mc[GROUPS][:]OPERATION

where GROUPS may be empty or list of compression groups, where '$default' means the default group. Examples are:

$obj
$default
$default,$obj

Optional ':' is just a syntax sugar

OPERATION may be one of the following:

'-$group' or '$group-' means "remove $group from compression definition"
'-method' or 'method-' means "remove method from compression definition". RAR-compatible shortcuts like -mca- are also supported
'+method' or 'method+' means "add method at the head of every compression chain", f.e. -mc+precomp042:c-
'method1/method2' means "replace method1 with method2", f.e. -mc:rep/srep:mem256mb

GROUPS may be used to limit OPERATION to the specified groups, f.e. -mc$default,$obj:+precomp042:c-

--------------------------------------------------------------------------------------------------------------

Using these options, FreeArc implements "Exprerimental compressor" checkboxes in the following way:

lzma:1gb: -mc:lzma/lzma:max:512mb
exe2: -mc:exe/dispack070
srep: -mc:rep/srep:mem256mb
precomp: -mc$default,$obj:+precomp042:c-:t-j
intense: -mc$default,$obj:+precomp042:c-:intense:t-j
jpeg: -mc$default,$obj:+precomp042:c-
intense+jpeg: -mc$default,$obj:+precomp042:c-:intense

REP speed improvements:

REP: up to 4x faster due to multithreading and anchored hashing proposed by Eugene Shelwien
REP:c sets size of hashed chunks (f.e. rep:256:c256 is a quick-and-dirty replacement for rep:512)
REP: for rep:512..257/256..129/... default is :c128/64/...
REP: default hashsize = min(1/4,16/chunksize)*BlockSize


Цитата:

D:\>old_fazip rep:1g dll4g.dll nul
100%: 4,531,060,447 -> 3,046,406,598: 67.23% Cpu 358 mb/s, real 327 mb/s
D:\>new_fazip rep:1g:c256 dll4g.dll nul
100%: 4,531,060,447 -> 3,063,642,637: 67.61% Cpu 482 mb/s, real 1299 mb/s

D:\>old_fazip rep:1g:32 dll4g.dll nul
100%: 4,531,060,447 -> 2,245,307,773: 49.55% Cpu 117 mb/s, real 113 mb/s
D:\>new_fazip rep:1g:32:c16 dll4g.dll nul
100%: 4,531,060,447 -> 2,271,868,087: 50.14% Cpu 182 mb/s, real 274 mb/s

Improved method definitions:

-m1: added REP preprocessing (compression improved by 10-20%, speed remained the same thanks to the new ultra-fast REP engine)
-m1: removed separate $exe group in order to reduce number of disk seeks
-m2..m4: modified REP settings, utilizing new REP implementation in order to improve speed/compression ratio
-m3t/mex3t: modified so that compression runs slower but decompression is faster


Цитата:

D:\>old_arc a a -m1 MsOfficeBCJ.obj
Compressed 1 file, 810,411,321 => 435,620,877 bytes. Ratio 53.7%
Compression time: cpu 13.10 secs, real 1.76 secs. Speed 459,651 kB/s
D:\>new_arc a a -m1 MsOfficeBCJ.obj
Compressed 1 file, 810,411,321 => 369,825,442 bytes. Ratio 45.6%
Compression time: cpu 12.68 secs, real 1.84 secs. Speed 441,616 kB/s

D:\>old_arc a a -m2 MsOfficeBCJ.obj
Compressed 1 file, 810,411,321 => 354,958,875 bytes. Ratio 43.7%
Compression time: cpu 37.72 secs, real 5.41 secs. Speed 149,680 kB/s
D:\>new_arc a a -m2 MsOfficeBCJ.obj
Compressed 1 file, 810,411,321 => 353,083,639 bytes. Ratio 43.5%
Compression time: cpu 36.54 secs, real 5.11 secs. Speed 158,553 kB/s

D:\>old_arc a a -m3 MsOfficeBCJ.obj
Compressed 1 file, 810,411,321 => 340,430,540 bytes. Ratio 42.0%
Compression time: cpu 80.15 secs, real 12.00 secs. Speed 67,514 kB/s
D:\>new_arc a a -m3 MsOfficeBCJ.obj
Compressed 1 file, 810,411,321 => 338,976,484 bytes. Ratio 41.8%
Compression time: cpu 78.91 secs, real 11.33 secs. Speed 71,530 kB/s

D:\>old_arc a a -m4 MsOfficeBCJ.obj
Compressed 1 file, 810,411,321 => 326,333,902 bytes. Ratio 40.2%
Compression time: cpu 184.19 secs, real 24.19 secs. Speed 33,503 kB/s
D:\>new_arc a a -m4 MsOfficeBCJ.obj
Compressed 1 file, 810,411,321 => 324,126,352 bytes. Ratio 39.9%
Compression time: cpu 182.58 secs, real 24.01 secs. Speed 33,748 kB/s


D:\>old_arc a a -m3t -t enwik8
Compressed 1 file, 100,000,000 => 25,840,442 bytes. Ratio 25.8%
Compression time: cpu 9.02 secs, real 1.58 secs. Speed 63,488 kB/s
Testing time: cpu 12.03 secs, real 2.14 secs. Speed 46,704 kB/s
D:\>new_arc a a -m3t -t enwik8
Compressed 1 file, 100,000,000 => 25,221,121 bytes. Ratio 25.2%
Compression time: cpu 12.00 secs, real 2.18 secs. Speed 45,869 kB/s
Testing time: cpu 8.42 secs, real 1.61 secs. Speed 61,993 kB/s

Other changes:

CRC in arc/unarc/dll/sfx became 2x faster (500->1000 mb/s); CRC in facompress.dll still runs at 1600 mb/s
I/O: reading files to compress in 1mb chunks (optimized for Vista/Win7)
DICT: fixed bug with error -6 at end of decompression (detectable with -m=bcj+dict -t)
i18n: NEW Portuguese Standard translation by Nuno Rego!

Цитата:

Fossius
Сто раз писали "Предлагайте варианты для гуя". И так понятно, что над этим надо работать.
Булат посмотрите пожалуйста в сторону PeaZIP, в стиле обычного проводника винды - это удобно и привычно. А опционально можно сделать в духе винрара.

Я бы взглянул в сторону HaoZip, и думаю что его создатель может поделиться исходниками т.к. FreeArc и HaoZip нисколько не конкуренты...

Вот это да, нам раскрыли глаза... Оказывается функционал заключается в GUI с drag'n'drop.
А мы то дурачки радуемся фильтру dispack, матчфайндеру ht4, возможности снижать потребление памяти при использовании внутренних алгоритмов путем указания tempfile в цепочке....

Fossius
Хао в духе винрара и сделан.
Можно сделать "профи" - показывается в духе проводника, а "лайт" - стиль привычного винрара.

Цитата:

Баг замечен давно был, приходится юзать с промежуточными/временными файлами, багрепорт на такое хз как сделать, если только видео записывать =)  

очень просто - убираешь лишние опции, лишние файлы пока ошибка не перестанет проявляться

Добрый день
Есть желание написать ebuild для freearc. Поэтому несколько вопросов отсюда
http://www.linux.org.ru/forum/general/7894692?lastmod=1340361987112#comment-7898078

Bulat_Ziganshin
Будь другом, подскажи.
Имеется образ ISO с игровыми файлами Wolfenstein2009 (не установка, а просто папка с игрой).
В "изначальном" репакерском установщике (который был упакован при помощи FreeArc) это всё ужато до 2,91 гига, но там настолько тупой установщик и структура подпапок, что я от него отказался в пользу своей сборки.
Теперь к вопросу.
Я хочу его максимально эффективно ужать, чтобы получить аналогичный размер, НО...
Так просто до такого размера ничего не получается ужать, там используется некий алгоритм PreComp с добавлением Srep.
Собственно, по синтасису я более менее разберусь (тем более, что с прошлого моего вопроса команда у меня осталась в заметках), а сейчас меня интересует вот что:
Я хочу (по твоему совету) промежуточные данные поместить на Ram-диск, но могу выделить на него не более 8 гигов (всё же ещё нужна память и для упаковки и для работы системы), и, следовательно вопрос: уместятся ли все промежуточные данные в 8 гигов при попытке сжатия плохожмущегося обычным способом 6-гигового файла?


з.ы.
Источник (в 3 частях) выглядит так:

FreeArc 0.67 (May 22 2012) listing archive: data1.bin

Archive type: FreeArc
Total bytes: 4,049,156,024
Compressed bytes: 1,127,225,672
Ratio: 27.8%

Directory blocks: 1
Directory, bytes: 59,107
Directory, compressed: 17,142
Solid blocks: 2
Avg. blocksize: 1931 mb

Compression memory: 4096 mb
Decompression memory: 4096 mb
Dictionary: precomp:4096mb+lzma:64mb

Archive locked: -
Archive comment: -
Recovery info: -
SFX size: -
Headers encrypted: -
Encryption algorithms: -

Pos Size Compressed Files Method
-----------------------------------------------------------------------------
31 0 0 22 storing
31 4,049,156,024 1,127,225,672 1,439 precomp+srep:mem512m:m3f:a1:l512+lzma:64mb:normal:bt4:128
-----------------------------------------------------------------------------
1,461 files, 4,049,156,024 bytes, 1,127,225,672 compressed
All OK


FreeArc 0.67 (May 22 2012) listing archive: data2.bin

Archive type: FreeArc
Total bytes: 985,693,840
Compressed bytes: 976,175,484
Ratio: 99.0%

Directory blocks: 1
Directory, bytes: 802
Directory, compressed: 406
Solid blocks: 2
Avg. blocksize: 470 mb

Compression memory: 2542 mb
Decompression memory: 254 mb
Dictionary: lzma:254mb

Archive locked: -
Archive comment: -
Recovery info: -
SFX size: -
Headers encrypted: -
Encryption algorithms: -

Pos Size Compressed Files Method
-----------------------------------------------------------------------------
31 0 0 2 storing
31 985,693,840 976,175,484 17 exe+delta+lzma:254mb:normal:bt4:128
-----------------------------------------------------------------------------
19 files, 985,693,840 bytes, 976,175,484 compressed
All OK


FreeArc 0.67 (May 22 2012) listing archive: data3.bin

Archive type: FreeArc
Total bytes: 976,277,188
Compressed bytes: 967,844,690
Ratio: 99.1%

Directory blocks: 1
Directory, bytes: 620
Directory, compressed: 378
Solid blocks: 2
Avg. blocksize: 466 mb

Compression memory: 2542 mb
Decompression memory: 254 mb
Dictionary: lzma:254mb

Archive locked: -
Archive comment: -
Recovery info: -
SFX size: -
Headers encrypted: -
Encryption algorithms: -

Pos Size Compressed Files Method
-----------------------------------------------------------------------------
31 0 0 2 storing
31 976,277,188 967,844,690 13 exe+delta+lzma:254mb:normal:bt4:128
-----------------------------------------------------------------------------
15 files, 976,277,188 bytes, 967,844,690 compressed
All OK

uglypod
попробую как-нибудь, идея здравая, глупо что я сам не догадался

Bulat_Ziganshin
Я думаю, лучше всего если вы cabal соберете, и выложите на hackage. Из кабала ебилдик я как-нибудь сделаю

На русском

Что, правда такие слова есть в русском языке? Вы где учились, на Юпитере? ))))

Paramon111

Цитата:

Что, правда такие слова есть в русском языке? Вы где учились, на Юпитере? ))))

нажато
Цитата:

Сообщить модератору

Архивировал 16 гб образ убунтовской виртуалки:

Код: 3 540 988 392  7z -mx -md256m
3 216 460 052  arc -mx (rep:1600m+lzma:177m)
2 980 064 981  srep + 7z -mx -md256m
2 956 691 497  srep + arc -m9x (lzma:254m)

Вот такая история



при распаковке все нормально.
Я конечно понимаю , что это ошибка пизипа.
Но все таки

Bulat_Ziganshin

Цитата:

Я конечно понимаю , что это ошибка пизипа. Но все таки.

Можно вас попросить скомпилировать консольную версию 0.666 с UTF-8 для списков файлов по умолчанию? У PZ свои муки, но возможно только этого (при использовании -scl) ему будет достаточно.
Цитата:

decoding of names of archived objects containing extended characters, form version 3.0.1, is supported for file types handled using 7z/p7zip backend (using backend's -sccUTF-8 option).

juvaforza
а в arc.ini прописать?

Bulat_Ziganshin
Я думал об этом, правда не понял каким образом. Читал невнимательно.

Bulat_Ziganshin
Здравствуй!
В первую очередь благодарю за прекрасный архиватор, который является основным для меня. Желаю удачи и наилучших пожеланий на пути движения разработки к совершенству! =)

А теперь внесу свой вклад в это самое улучшение: возникла проблема с использованием ключа -ep1, который по-идее должен архивировать объекты - файлы или папки - складывая их напрямую в корень архива, исключая только путь, который ведёт к ним на диске. С файлами всё порядке, а вот папки помещаются пустыми, а их содержимое выпотрашивается в корень архива. Версия FreeArc'а последняя, от 22 мая.
Пример: <FreeArc.exe a -ep1 -sfxfreearc.sfx -- 1.arc.exe 1 2 1.txt>. "1", "2" папки с файлами, "1.txt" случайный файл.
В итоге получаем пустые папки 1 и 2, их содержимое и файл 1.txt прямо в корне архива. Очевидно, в цикле парсинга строки, содержащей путь к объектам, содержащимся в объектах, указанных в командной строке / файле-списке, алгоритм обрезает на один уровень больше чем нужно.
На всякий случай, WinRAR всё ложит нормально.

Также вопрос: планируется ли какая-либо интеграция с arclite'ом для Far'а, т.к. он теперь официально заменил MultiArc и, по-моемому, также лучше?

привет
может кто поможет мне использовать

bikunpack.exe с FreeArc

заранее спасибо

alifais2000
Читай http://freearc.sourceforge.net/rus/FreeArc040-rus.htm

V2driver

Я не могу понять, что это ссылка

Я сказал, как я могу использовать bikunpack.exe с FreeArc

alifais2000
Там всё написано.

alifais2000
http://freearc.sourceforge.net/rus/FreeArc040-rus.htm#_Toc185595018 ---> Вот что тебе нужно!

Цитата:

Также вопрос: планируется ли какая-либо интеграция с arclite'ом для Far'а, т.к. он теперь официально заменил MultiArc и, по-моемому, также лучше?

спросите у автора arclite, он у меня спрашивал как ему поддержку fa реализовать


Цитата:

Пример: <FreeArc.exe a -ep1 -sfxfreearc.sfx -- 1.arc.exe 1 2 1.txt>. "1", "2" папки с файлами, "1.txt" случайный файл.
В итоге получаем пустые папки 1 и 2, их содержимое и файл 1.txt прямо в корне архива. Очевидно, в цикле парсинга строки, содержащей путь к объектам, содержащимся в объектах, указанных в командной строке / файле-списке, алгоритм обрезает на один уровень больше чем нужно.
На всякий случай, WinRAR всё ложит нормально.

вижу, что я неправильно понял раровское описание. поставил на переделку, поскольку моя цель - совместимость с rar, но займусь этим в след. версии, типа 0.71