» FreeArc (часть 4)

SurferNet
Не помню где, кажется в этом топике, Булат писал, что хочет замутить другой алго (сейчас название не помню), который быстрее МД5 и секурнее.

Bulat_Ziganshin

Цитата:

фрагментирован 159 частей

данная фрагментация получилась при распаковке Arc \ FreeArc, причём файл размазан был по всему диску. Сейчас повторил с другим архивом получил 325 частей на 1778МБ.
Фрагментация не радует.

FreeArc
распаковывал через контекстное меню архив Nero-10.5.10500_trial.tar.arc
указано было c:\temp\Nero-10.5.10500_trial.tar
при распаковке получил c:\temp\Nero-10.5.10500_trial.tar\Nero-10.5.10500_trial.tar

Bulat_Ziganshin
Помогите разобраться с моим багом! Такая проблема появляется только при подключении FreeArc-LZMA-x64 ,без него все работает нормально!

insorg
места не хватает в виндовом TEMP-каталоге, используй -wf:\

Paramon111
exe ухудшает сжатие для всех файлов, кроме exe/dll


Цитата:

Фрагментация не радует.

раньше запись на диск шла порциями по 64кб, сейчас - 1мб. надо будет прикрутить туда setfilesize сразу после создания файла

Добавлено:

Цитата:

указано было c:\temp\Nero-10.5.10500_trial.tar

там указывается каталог

А что, работа над FreeArc прикращена? А то "FreeArc — планы на будущее" такие планы, что уже не поверишь, что такой архиватор могли забросить.

Спасибо! Отлично сработало, но, к сожалению, итоговый размерчик оказался побольше, чем у 7zip:
_HL1_7z_lzma2-dict512m_.7z          1 698 158 967    22.05.12 19:20    ra--
_HL1_-m9x-defPsrep256m_wf_.arc    1 736 032 022    23.05.12 18:41    ra--
Исходя из повторяемости данных там по факту должно в итоге быть не более 1 600 000 000 байт (есть местами дубликаты по 300-400 мб, которые 256 мб словарь не "сокращает", а оставляет дублями, как, например, делает 7zip при 256Мбайт словаре).
Как я могу ещё улучшить результат?


Добавлено:
Для эксперимента задал для srep 1024 мбайта, вышло:
_HL1_srep1024_20120523184538.arc    1 736 031 774    23.05.12 19:49    -a--
т.е., выигрыш остался мизерный.

Bulat_Ziganshin

Цитата:

завтра наверно переделаю с другим RAM-drive

результаты такие-же
Primo Ramdisk Professional Edition 5.2.0
данные на RAM-drive - запись на RAM-drive (RAM-drive 1024МБ)

старый rep
Compressed 1 file, 734,003,200 => 263,593,371 bytes. Ratio 35.9%
Compression time: cpu 13.08 secs, real 15.13 secs. Speed 48,529 kB/s

новый rep
Compressed 1 file, 734,003,200 => 265,662,180 bytes. Ratio 36.1%
Compression time: cpu 12.41 secs, real 14.34 secs. Speed 51,172 kB/s

новый2 rep
Compressed 1 file, 734,003,200 => 264,563,450 bytes. Ratio 36.0%
Compression time: cpu 8.69 secs, real 10.23 secs. Speed 71,719 kB/s


Цитата:

там указывается каталог

туплю

ozerothik, идёт, просто неторопливо.

insorg

Цитата:

есть местами дубликаты по 300-400 мб, которые 256 мб словарь не "сокращает", а оставляет дублями, как, например, делает 7zip при 256Мбайт словаре

Что подразумевается под "дубликатами"? Файлы по 300-400 мб? SREP может найти дубликаты, только в одном файле, а не между двумя файлами. Вывод - нужно объединить "дубликаты" в один большой файл (например, TAR).

Насчет скорости еще хотел сказать.
Исходный файл .abk 400 314 012 байт
7zip ультра lzma2 256m 273 непрерывный 2 потока - 33 394 620 байт (1087с)
freearc -max -mc-rep -mc-exe -mc-dict - 25 454 436 байт (123с)
Разница во времени почти в 9 раз и сжатие на 2% сильней.

Здравствуйте, то ли я что-то не понимаю то ли это какой-то реальный баг:

В результате выполнения команды:
arc create snd.arc snd -m9 -m$wav=tta:s:m3+rep:512mb:128:a99+lzma:ultra:mc10000:512m

Выдается следующий результат:
FreeArc 0.666 creating archive: snd4.arc
Compressed 1,870 files, 51,210,240 => 14,740,340 bytes. Ratio 28.7%
Compression time: cpu 21.01 secs, real 22.82 secs. Speed 2,244 kB/s
All OK

Т.е. следуя этому файлы должны ужаться до примерно до 14мб, но создаваемый архив весит 42 мб !!! В папке snd только *.wav файлы раскиданные по разным каталогам.

Как это понимать? ))

И еще можно ли как-то сжимать файлы упакованный в *.zip контейнер с 0-вым сжатием, т.е. применять особые настройки для файлов находящихся внутри этого контейнера а не к самому контейнеру?

ruduk
Это и означает, что есть похожие и одинаковые файлы.
Обьединять в TAR не катит, ибо это сведёт на нет все прелести удобной упаковки и простой 7z@lzma-dic512Mb будет более удачным вариантом. Нужен solid-вариант.

egor23
в общем, у тебя похоже упирается в банальную скорость rep+crc, оптимизировать i/o тут бесполезно. для интереса попробуй новый rep1 без dll - одна из оптимизаций в rep2 заключалась как раз в том, что я исключил из dll rep_compress(), поскольку он был медленней встроенного

Цитата:

И еще можно ли как-то сжимать файлы упакованный в *.zip контейнер с 0-вым сжатием, т.е. применять особые настройки для файлов находящихся внутри этого контейнера а не к самому контейнеру?

нет


Цитата:

файлы должны ужаться до примерно до 14мб, но создаваемый архив весит 42 мб !!!

arc lt что выдаёт?

Булат, а нельзя ли сделать опцию "Встроить SREP в SFX", чтобы не добавлять в сам ARC, я так понял это сложнее.

Цитата:

Подскажите где можно посмотреть детальную расшифровку методов сжатия?

http://freearc.org/ru/Documentation.aspx
Первая ссылка.

Цитата:

freearc -max -mc-rep -mc-exe -mc-dict

-m насколько я понимаю, должен быть только один, а не 4.

Добавлено:
Bulat_Ziganshin


Цитата:

обновил архив - ускорены I/O и сам REP

Сравнил (пока навскидку) версии 11.01.2012 и 14.01.2012.
Разница в размерах - несколько байт (на сотни мегабайт архива), по времени примерно так:
17,34с -> 17,24с
17,23 с -> 16,97с
В общем, на уровне возможной ошибки.

[more] Середину вырезал, а то слишком длинное сообщение не отправляется

[spoiler]
arc lt snd.arc
FreeArc 0.666 listing archive: snd.arc
Listing archive: snd.arc

Archive type: FreeArc
Total bytes: 51,210,240
Compressed bytes: 42,802,456
Ratio: 83.5%

Directory blocks: 1
Directory, bytes: 163,561
Directory, compressed: 26,518
Solid blocks: 1,806
Avg. blocksize: 28 kb

Compression memory: 384 mb
Decompression memory: 384 mb
Dictionary: 185kb + 185kb

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

Pos Size Compressed Files Method
-----------------------------------------------------------------------------
31 0 0 55 storing
31 468,502 247,216 11 dict:463kb:80%:l8192:m400:s100+lzp:463kb:92%:145:h19:d1mb+ppmd:16:384mb
247,247 75,270 29,021 1 tta:s+rep:75kb:128:a99+lzma:75kb:normal:bt4:128:mc10000
276,268 19,374 15,776 1 tta:s+rep:20kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
292,044 62,956 26,161 1 tta:s+rep:63kb:128:a99+lzma:63kb:normal:bt4:128:mc10000
318,205 62,956 26,161 1 tta:s+rep:63kb:128:a99+lzma:63kb:normal:bt4:128:mc10000
344,366 64,624 54,474 1 tta:s+rep:65kb:128:a99+lzma:65kb:normal:bt4:128:mc10000
398,840 64,624 26,762 1 tta:s+rep:65kb:128:a99+lzma:65kb:normal:bt4:128:mc10000
425,602 49,884 28,643 1 tta:s+rep:50kb:128:a99+lzma:50kb:normal:bt4:128:mc10000
454,245 55,212 24,358 1 tta:s+rep:55kb:128:a99+lzma:55kb:normal:bt4:128:mc10000
478,603 55,212 24,358 1 tta:s+rep:55kb:128:a99+lzma:55kb:normal:bt4:128:mc10000
502,961 123,620 52,887 1 tta:s+rep:123kb:128:a99+lzma:123kb:normal:bt4:128:mc10000
555,848 123,620 52,887 1 tta:s+rep:123kb:128:a99+lzma:123kb:normal:bt4:128:mc10000
608,735 186,222 93,095 1 tta:s+rep:185kb:128:a99+lzma:185kb:normal:bt4:128:mc10000
701,830 17,896 15,687 1 tta:s+rep:19kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
717,517 17,896 15,451 1 tta:s+rep:19kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
732,968 17,896 15,678 1 tta:s+rep:19kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
748,646 17,896 15,768 1 tta:s+rep:19kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
764,414 17,896 15,843 1 tta:s+rep:19kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
780,257 17,896 15,831 1 tta:s+rep:19kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
796,088 17,896 15,362 1 tta:s+rep:19kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
811,450 21,036 19,109 1 tta:s+rep:22kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
830,559 21,052 18,792 1 tta:s+rep:22kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
849,351 21,052 18,084 1 tta:s+rep:22kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
867,435 21,052 19,119 1 tta:s+rep:22kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
886,554 21,052 17,064 1 tta:s+rep:22kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
903,618 21,052 17,064 1 tta:s+rep:22kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
920,682 21,052 18,230 1 tta:s+rep:22kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
938,912 21,052 18,401 1 tta:s+rep:22kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
957,313 21,052 17,087 1 tta:s+rep:22kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
974,400 21,052 17,087 1 tta:s+rep:22kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
991,487 32,420 28,294 1 tta:s+rep:33kb:128:a99+lzma:33kb:normal:bt4:128:mc10000
1,019,781 16,956 14,753 1 tta:s+rep:18kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
1,034,534 16,956 14,671 1 tta:s+rep:18kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
1,049,205 16,956 14,671 1 tta:s+rep:18kb:128:a99+lzma:32kb:normal:bt4:128:mc10000

***************************************************
***************************************************
***************************************************

tta:s+rep:15kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
42,671,497 14,908 12,810 1 tta:s+rep:16kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
42,684,307 14,908 12,810 1 tta:s+rep:16kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
42,697,117 13,884 10,600 1 tta:s+rep:15kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
42,707,717 13,884 10,600 1 tta:s+rep:15kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
42,718,317 13,884 10,868 1 tta:s+rep:15kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
42,729,185 13,884 10,868 1 tta:s+rep:15kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
42,740,053 12,860 9,852 1 tta:s+rep:14kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
42,749,905 12,860 9,852 1 tta:s+rep:14kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
42,759,757 12,860 10,342 1 tta:s+rep:14kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
42,770,099 12,860 10,342 1 tta:s+rep:14kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
42,780,441 13,884 11,023 1 tta:s+rep:15kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
42,791,464 13,884 11,023 1 tta:s+rep:15kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
-----------------------------------------------------------------------------
1,870 files, 51,210,240 bytes, 42,802,456 compressed
All OK

[/spoiler]


Вообще у меня при использовании -tta или -mm результаты выходят отвратительные - 98%, тот же -m9 выдает 64%. Вот и попробавл скомбинировать с lzma - результат пишет потрясающий, но файл создает в 3 раза больше [/more]

в идеале было бы хорошо если бы в SFX добавлялись внешние модули (SREP, precomp...) при необходимости

объясните, пожалуйста, как использовать внешний упаковщик, в частности packjpg
в arc.ini ничего не трогал, файл оригинальный
packjpg.exe сложил в папку с arc.exe (path на эту папку прописан)
пробовал методы 5p и 9p - эффекта нет (

в arc.ini ещё указан некий timer (пробовал убрать, не помогло)
packcmd = timer packjpg $$arcdatafile$$.jpg
где взять его?

Bulat_Ziganshin
переделовал - на RAM-drive - запись на RAM-drive
т.к. результат получился хуже чем - данные на HDD (закешированы) - запись на RAM-drive


Цитата:

для интереса попробуй новый rep1 без dll - одна из оптимизаций в rep2 заключалась как раз в том, что я исключил из dll rep_compress(), поскольку он был медленней встроенного

вот эта оптимизация полезная

Цитата:

1. данные на HDD (закешированы) - запись на RAM-drive (RAM-drive 288МБ)

старый rep
Compressed 1 file, 734,003,200 => 263,593,371 bytes. Ratio 35.9%
Compression time: cpu 12.56 secs, real 12.80 secs. Speed 57,358 kB/s

новый rep
Compressed 1 file, 734,003,200 => 265,662,180 bytes. Ratio 36.1%
Compression time: cpu 12.36 secs, real 12.58 secs. Speed 58,356 kB/s

новый2 rep
Compressed 1 file, 734,003,200 => 264,563,450 bytes. Ratio 36.0%
Compression time: cpu 8.42 secs, real 8.80 secs. Speed 83,439 kB/s

Arc.exe без dll

данные на HDD (закешированы) - запись на RAM-drive (RAM-drive 288МБ)

старый rep
Compressed 1 file, 734,003,200 => 263,593,371 bytes. Ratio 35.9%
Compression time: cpu 16.25 secs, real 16.47 secs. Speed 44,569 kB/s

новый rep
Compressed 1 file, 734,003,200 => 265,662,180 bytes. Ratio 36.1%
Compression time: cpu 9.88 secs, real 10.09 secs. Speed 72,719 kB/s

новый2 rep
Compressed 1 file, 734,003,200 => 264,563,450 bytes. Ratio 36.0%
Compression time: cpu 9.05 secs, real 9.27 secs. Speed 79,218 kB/s

ещё гляну на фрагментированном файлике

Ahf
в настройках метода сжатия есть Экспериментальные методы

Цитата:

-m насколько я понимаю, должен быть только один, а не 4.

Смотри, берем тот же файл .abk
-max - 26 206 164 (129c)
-max -mc-rep - 26 148 447 (117c)
-max -mc-rep -mc-exe - 25 454 436 (113c)
Как видишь разница есть. mc-dict можно не писать, он в этом варианте только тормозит процесс.
Лучше сжать этот файл я не смог.

StaticZ
как видите, тут сжатых 42 мб. или вы что-то напутали или fa ошиболчно печатает статистику при сжатии. попробуйте снова, если что - закиньте мне ваш архив для проверки

Попался мне архивчик с использованием precomp и нужно его распаковать.
Код: FreeArc 0.67 (May 22 2012) listing archive: data1.arc

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:m
3f:a1:l512+lzma:64mb:normal:bt4:128
-----------------------------------------------------------------------------
1,461 files, 4,049,156,024 bytes, 1,127,225,672 compressed
All OK

Цитата:

Около двух лет наблюдаю за развитием FreeArc.
За это время он не снискал особой популярности среди обычных людей, скорее больше среди репакеров игр.

Цитата:

Мне кажется в этой ситуации лучший выход был бы сменить вектор развития.
Как возможный вариант - развитие томов восстановления в виде кодов рид-соломона.

спасибо, насмешил. ты констатируешь, что fa популярен только среди гиков (согласен), и тут же предлагаешь переделать его под других гиков. и это как раз тогда, когда он худо-бедно разворачивается лицом к народу!

вот что я собираюсь делать:
- поддержку 7z/zip/zipx форматов на лучшем уровне, чем в 7-zip и других бесплатных программах
- поддержку формата arc в 7-zip (и транзитом в winrar/winzip/pa/hao)
- дальнейшее улучшение формата arc, чтобы сделать его "предложением, от которого невозможно отказаться". в частности, многотомность и в перспективе - par2 или что-то типа него

Я вижу, так же как и вижу что выводится неправильная статистика, поэтому и говорю возможно баг, а записи или отображения статистики это я уж не знаю - т.к. только начала пользоваться этим архиватором, даже до конца во всем еще и не разобрался. Так что Вам лучше должно быть видно...


Попробовал и не один час и разные варианты - от сжатия wav'ов -tta или -mm становиться только заметно хуже...

Цитата:

можно конкретней, в чём проблема? у меня такой принцип - "precomp042" и т.п. означают конкретные версии precomp, а "precomp" заменяется на "precomp042" или другую свежую версию. это позволяет сжимать с -m=precomp и не думать, какая там сейчас версия последняя - например, не менять батники

единственное в чём возможно я неправ - это надо перенести определение precomp в стандартный arc.ini

Именно, только через арк.ини. Тк не всегда это удобно, да еще и там jpg сжатие отключено. Только вот большая проблема в том, что unarc.dll теперь не распаковывает эти архивы - пишет что неизвестный метод сжатия "precomp042:c-:t-j". В этом то и вся суть...

StaticZ
я же вам написал - попробуйте ещё раз и если будет неправильный вывод, пришлите мне архив для тестирования

Bulat_Ziganshin


Цитата:

кстати, оптимальные настройки rep-препроцессинга для различных режимов многопоточного сжатия:

-m1: rep:257
-m2: rep:65
-m3: rep:33
-m4: rep:96:d4m:s32

По какому критерию(ям)?