» FreeArc (часть 4)

Цитата:

Кому это надо?

Никому Mpeg2 архиватором ужимать - бредовая затея, имхо. Raw или, возможно, lossless видео можно сильно сжать, но тут другой вопрос - на кой черт это нужно, когда проще его каким-нибудь кодеком обработать

Цитата:

7. может иконку кнопки Add заменить на основную FA ? по аналогии с WinRar.

тогда не мешало бы и кнопку извлечь переделать, а то какой то плейер получается
и кнопка тест тоже не соответствует

Цитата:

Пусть встретилась последовательности нулей длинной k штук. Если k<N, то оставляем её как есть. Иначе заменяем её на k нулей плюс один байт равный k-N.

да, с рабочими вариантами программы стало понятней где ошибка в описании. Надо так:
Цитата:

Иначе заменяем её на N нулей плюс один байт равный k-N.

Цитата:

REP детектит только достаточно длинные последовательности (если не ошибаюсь, от 32 байт; такие zero runs действительно попадаются не часто), причём на каждую ссылку тратит 12 байт.

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

Цитата:

Вас послушать, так lzma вообще лучше использовать в одиночку. Ведь применение, например, dict перед lzma не ставится под сомнение. А zrle делает то же, что dict или rep: уменьшает объем данных сохраняя уровень избыточности, что уменьшает объем работы и увеличивает эффективный размер словаря lzma.

вот с последним предложением согласен. Да и почему именно нули? Можно же таким образом с любыми последовательностями байт сделать.

И в приведенной тобой таблице не понятно как-то. Данные для каждого режима разные что-ли?
Ну и в общем то плюс в этом не хитром алгоритме вижу только в отсутствии потребляемой памяти. С остальным rep и srep на низких значениях параметра -l ИМХО должны справиться лучше.

Добавлено:
P.S. все же всё это стоит проверить на различного рода данных и в достаточном объеме для подтверждения того или иного утверждения.

SerJantX

Цитата:

и кнопка тест тоже не соответствует

я смотрю у всех Test однотипный - книжки, буквы - тест проходим.
вроде нормально.

QSQ
причина - в том, что в 7-zip есть lzma2, который копирует без сжатия несжавшиеся блоки, а в fa - lzma1, который их чуть-чуть растягивает

а можно сделать следующее в FreeArc.

в архиваторе есть модуль freearc-installer.sfx, который запускает setup.exe , но если в архиве были еще файлы то он их не распаковывает в текущую папку.
нужно чтобы работало следующим образом, у меня есть к примеру три файла:
1. setup.exe
2. primer.exe
3. primer.txt

я их архивирую через модуль freearc-installer.sfx , а когда уже распаковываю эти файлы setup.exe должен запуститься сам автоматически и удалиться, а оставшиеся файлы primer.exe и primer.txt должны распаковаться в текущую папку как обычно?(т.е. setup.exe после запуска удаляется , а primer.exe и primer.txt должны просто распаковаться)
как такое реализовать, если такого нет могли бы за отдельную плату подредактировать этот модуль?

Bulat_Ziganshin сжимал lzma (не 2) (она по умолчанию). получил коэффициент 0,854448844
попробовал поставить lzma2, на аналогичном наборе файлов 0,892913479 (сжало хуже).

vishyakov И отвязать программу от фрейм ворка.

Цитата:

arc l "E:\MS Office 2003.arc"
Цитата:
71 files, 96,929,246 bytes, 0 compressed
All OK

arc l "E:\MS Office 2003.7z
Цитата:
155 files, 419,766,875 bytes, 405,828,536 compressed
All OK

arc l "E:\MS_Office_2003.arc
Цитата:
155 files, 419,766,875 bytes, 377,402,843 compressed
All OK


похоже что проблема в имени архива ARC с пробелами, или это всём давно известно ?

Цитата:

что за неправильный архив создался, где мои файлы в нём ?

а нафига ты мне прислал архив 7z, если проблема в архиве arc? да ещё и упакованный в ppmd

проблем в листинге архивов с пробелом в имени нет:

D:\Downloads\!!!>arc l "a b.arc" |tail
2003-10-13 00:36:32 38,479 SevaSoftware\Locana\doc\img_locana_tk_event_monitor.jpg
2003-10-18 11:31:54 38,479 SevaSoftware\Locana\doc\screen_shots\img_locana_tk_event_monitor.jpg
2003-10-18 11:31:56 38,479 SevaSoftware\Locana\screen_shots\img_locana_tk_event_monitor.jpg
2003-10-18 11:31:56 6,547 SevaSoftware\Locana\tst\images\flower1.jpg
2003-10-18 11:31:56 6,950 SevaSoftware\Locana\tst\images\flower2.jpg
2003-10-18 11:31:56 8,165 SevaSoftware\Locana\tst\images\flower3.jpg
2003-10-18 11:31:56 6,896 SevaSoftware\Locana\tst\images\flower4.jpg
2003-08-11 23:19:16 764,836 ProgrammingRuby.chm
----------------------------------------
7,498 files, 62,861,163 bytes, 9,174,197 compressed

C:\!\FreeArchiver\Tests>arc l ruby.arc |tail
2003-10-13 00:36:32 38,479 SevaSoftware\Locana\doc\img_locana_tk_event_monitor.jpg
2003-10-18 11:31:54 38,479 SevaSoftware\Locana\doc\screen_shots\img_locana_tk_event_monitor.jpg
2003-10-18 11:31:56 38,479 SevaSoftware\Locana\screen_shots\img_locana_tk_event_monitor.jpg
2003-10-18 11:31:56 6,547 SevaSoftware\Locana\tst\images\flower1.jpg
2003-10-18 11:31:56 6,950 SevaSoftware\Locana\tst\images\flower2.jpg
2003-10-18 11:31:56 8,165 SevaSoftware\Locana\tst\images\flower3.jpg
2003-10-18 11:31:56 6,896 SevaSoftware\Locana\tst\images\flower4.jpg
2003-08-11 23:19:16 764,836 ProgrammingRuby.chm
----------------------------------------
7,498 files, 62,861,163 bytes, 9,174,197 compressed

Добавлено:
отбой. сархиваировал твои файлы в arc - те же чудеса. буду разибраться

Добавлено:
разобрался. ты напоролся на известную багу в arc - если в архиве arc можно найти несжатый архив другого формата, то он откроет именно внутренний архив:

D:\Downloads\!!!>Arc.exe lt ms
FreeArc 0.67 (February 2 2011) listing archive: ms.arc

Archive type: Cab
Total bytes: 96,929,246
Compressed bytes: 0
Ratio: 0.0%

Directory blocks: 0
Directory, bytes: 0
Directory, compressed: 0
Solid blocks: 0
Avg. blocksize: 92 mb

Compression memory: 0 b
Decompression memory: 0 b
Dictionary: -

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

Pos Size Compressed Files Method
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
71 files, 96,929,246 bytes, 0 compressed

Здравствуйте что можете посоветовать по сжатию файлов после обработки прикомпом и срепом как более максимально сжать?

Цитата:

Иначе заменяем её на N нулей плюс один байт равный k-N.

Да, разумеется.


Цитата:

И в приведенной тобой таблице не понятно как-то. Данные для каждого режима разные что-ли?

Нет, одни и те же. Я приукрасил таблицу, чтоб понятней было. Ссылка та же: ZRLE.rar


Цитата:

Можно же таким образом с любыми последовательностями байт сделать.

Можно конечно, хотя таких на порядок меньше.


Цитата:

И отвязать программу от фрейм ворка.

Не охота возиться. Задача была предложить и обосновать идею, а работающая программа - это так, бонус. Кому сильно надо, тот запустит или напишет сам. Вообще, взаимодействие с внешними пакерами так, как сделано в FA - через файлы - жутко не эффективно. Вот бы можно было оформлять DLL-плугины...

Цитата:

разобрался. ты напоролся на известную багу в arc - если в архиве arc можно найти несжатый архив другого формата, то он откроет именно внутренний архив:

а что значит несжатый ?
т.е. если я упакую cab - то потом данные свои распоковать не смогу ?

Добавлено:
хм, а как же создание архива ARC без пробелов в имени и успешном листинге ?

Цитата:

arc l "E:\MS_Office_2003.arc
Цитата:
155 files, 419,766,875 bytes, 377,402,843 compressed
All OK

Hell_Dog2011

Цитата:

что можете посоветовать по сжатию файлов после обработки прикомпом и срепом

1) для начала, все-таки читать доку (например, FreeArc040-rus.htm --> разделы "Выбор алгоритмов сжатия", "Параметры алгоритмов сжатия", чтобы узнать что и как можно подстроить в методах "под себя"),
2) скачать и установить себе последнюю версию FreeArc,
3) пробовать файлы на сжимаемость - попробовать сжать файлы разными методами, вместе или по-отдельности, попробовать сжать экспериментальными методами (которые как-раз написаны для использования прекомп и среп, читайте форум),

Bulat_Ziganshin, мог бы дать ответ или может кто-то из мемборов сможет мне помочь, если необходимо готов заплатить.


можно сделать следующее в FreeArc.

в архиваторе есть модуль freearc-installer.sfx, который запускает setup.exe , но если в архиве были еще файлы то он их не распаковывает в текущую папку.
нужно чтобы работало следующим образом, у меня есть к примеру три файла:
1. setup.exe
2. primer.exe
3. primer.txt

я их архивирую через модуль freearc-installer.sfx , а когда уже распаковываю эти файлы setup.exe должен запуститься сам автоматически и удалиться, а оставшиеся файлы primer.exe и primer.txt должны распаковаться в текущую папку как обычно?(т.е. setup.exe после запуска удаляется , а primer.exe и primer.txt должны просто распаковаться)
как такое реализовать, если такого нет могли бы за отдельную плату подредактировать этот модуль?

Цитата:

Нет, одни и те же. Я приукрасил таблицу, чтоб понятней было

в прошлом варианте у тебя графы время и размер были перепутаны, что сбило меня с толку (ну или lister в тотал коммандере криво xls показывает)


Цитата:

Можно конечно, хотя таких на порядок меньше

но конечный эффект алгоритма же все равно повысится.


Цитата:

Вот бы можно было оформлять DLL-плугины..

у меня такие мечтания тоже были... пока Булат не сказал про cls фильтры) Так что это возможно) Примеры и реализацию смотри в исходниках FreeArc'а

Hell_Dog2011
в опциях сжатия выбираешь макс. сжатие и отмечаешь снизу галочки srep и precomp

Aroyl

Цитата:

Разархивировал .arc, попробовал напрямую srep -d, то же самое - ошибка, прекращение распаковки.

Цитата:

Вопрос с установкой решился. Вроде бы помогло увеличение объема файла подкачки (Win7x86, родные 4Гб, своп поставил "рекомендовано системой").

Цитата:

Ещё возможная проблема (подсмотрел на сайте где брал) - кеширование антивирусом распаковываемого файла

может проблема всё таки в памяти? проверьте её, а то очень сомнительно, что антивирус косячит, кэширует то он скорее всего на HDD.

Bulat_Ziganshin
в моём такого нету может у меня не та версия(666) вот моя.

Profrager
http://freearc.org/download/testing/unarc2011-09-26.7z - теперь в загружаемых cls dll выполняются вызовы CLS_INIT и CLS_DONE, и выгружаются сами dll. проверь плиз. вместо op==-1 надо перехватывать op==CLS_DONE

там есть тестовая cls-test.dll (исходник simple_codec.cpp), которая это демонстрирует:


Код: C:\>UnarcDllExample.exe t a.arc

simple_codec.cpp: 1

event("filename", 0, 0, "Arc.exe")
event("read", 0, 0, "")
event("read", 0, 0, "")
event("read", 0, 0, "")
event("read", 0, 0, "")
event("read", 0, 0, "")
event("read", 0, 0, "")
event("read", 0, 0, "")
event("write", 3, 0, "")
event("write", 3, 0, "")
event("quit", 0, 0, "")
FreeArcExtract() was successful

simple_codec.cpp: 2

Benchmark measuring effect of -nommap option on system with 8Gb RAM:

First test, 5.5 gb file compressed down to 4.4 gb:
Cpu 57.299 mb/sec, real 56.471 mb/sec -m1
Cpu 57.263 mb/sec, real 56.599 mb/sec -m1 -nommap
Cpu 58.545 mb/sec, real 57.968 mb/sec -m2
Cpu 57.594 mb/sec, real 56.189 mb/sec -m2 -nommap
Cpu 48.428 mb/sec, real 48.010 mb/sec -m3
Cpu 46.168 mb/sec, real 39.404 mb/sec -m3 -nommap

As you see, memory-mapped files (i.e. lack of -nommap option) has no effect on -m1 (in fact, MMF not used at all in -m1), there is a small improvement of 3-4% in -m2, and 20% in -m3

MMF files are used to retrieve matches to compare, that explains the result: -m1 doesn't do it at all (it verifies matches by SHA1 hash). -m2 retrives only small amount of real matches (500 thousands here), and -m3 retrives huge amount of match candidates (13 millions for this file) that is much faster with direct memory access instead of read call


Second test, 22gb file compressed down to 7gb:
Cpu 76.367 mb/sec, real 73.785 mb/sec -m1
Cpu 91.401 mb/sec, real 52.799 mb/sec -m2
Cpu 91.136 mb/sec, real 56.497 mb/sec -m2 -nommap
Cpu 72.282 mb/sec, real 36.478 mb/sec -m3
Cpu 68.879 mb/sec, real 35.693 mb/sec -m3 -nommap

Here we see about 10% speed improved in -m2 without MMF. srep is memory-hungry here, and may be it is the effect of larger OS memreqs to support MMF operation. but actually i don't know the reason, only had to say that i've tested several times and results were the same


Third test, the same 22gb file placed to Intel SSD 120 gb disk, that is 2x faster on linear reads, and has 100x smaller access time:
Cpu 77.116 mb/sec, real 75.453 mb/sec -m1
Cpu 92.865 mb/sec, real 56.718 mb/sec -m2
Cpu 90.861 mb/sec, real 73.738 mb/sec -m2 -nommap
Cpu 73.316 mb/sec, real 45.534 mb/sec -m3
Cpu 68.548 mb/sec, real 45.869 mb/sec -m3 -nommap

Here, memory-mapped files degrade -m2 performance even more

Hell_Dog2011
да, это только в 0.67

Bulat_Ziganshin

Цитата:

Here, memory-mapped files degrade -m2 performance even more

а обратили внимание на счётчик, например в Диспетчере задач, Mem Use, что со временем памяти показывается вся доступная.
На что это оказывает влияние это уже другой вопрос, на который я не могу ответить.

Добавлено:
Aroyl

Цитата:

Вот ссылка на репак: Dragon Age Origins - Diamond Edition
Нужен только первый образ - DAODE_RusEng_RePack_DVD1.iso
Файл с которым я мучался называется Daodata1.arc, лежит в каталоге Data.
Внутри него daomain.dat - обработаный srep'ом архив, содержащий 2 файла - daotemp1.arc (19Гб) и daotemp2.arc(5Гб), каждый из которых содержит внутри множество файлов. Я распаковывал последовательно и проблема была практически на ка

У меня проблем с распаковкой Daodata1.arc и daomain.dat не возникло.

Цитата:

Внутри него daomain.dat - обработаный srep'ом архив, содержащий 2 файла - daotemp1.arc (19Гб) и daotemp2.arc(5Гб)

про это не понял после daomain.dat получаю daomain.arc 18.5ГБ (без сжатия) внутри которого два архива arc без сжатия, точно уже непомню примерно 5ГБ и 13.5ГБ.
зачем было так делать мне непонятно.

Немного тестов на распаковку с -mXXX

srep294.exe -m1f daomain.arc daomain.arc.srep294_m1f

srep294.exe -d daomain.arc.srep294_m1f nul
Compression ratio: 19913271662 -> 12259186550: 61.56%. Cpu 129.241 mb/sec, real 48.617 mb/sec. Matches 0 371681 4110533, I/Os 0, MiBs 0 1415 6140

srep294.exe -d -nomd5 -m128k daomain.arc.srep294_m1f nul
Compression ratio: 19913271662 -> 12259186550: 61.56%. Cpu 357.891 mb/sec, real 50.095 mb/sec. Matches 0 371681 4110533, I/Os 3998, MiBs 0 436 2967

srep294.exe -d -nomd5 -m512k daomain.arc.srep294_m1f nul
Compression ratio: 19913271662 -> 12259186550: 61.56%. Cpu 311.145 mb/sec, real 46.650 mb/sec. Matches 0 371681 4110533, I/Os 1436, MiBs 0 475 3627

srep294.exe -d -nomd5 -m2m daomain.arc.srep294_m1f nul
Compression ratio: 19913271662 -> 12259186550: 61.56%. Cpu 302.217 mb/sec, real 46.532 mb/sec. Matches 0 371681 4110533, I/Os 414, MiBs 0 781 4659

Bulat_Ziganshin

Цитата:

http://freearc.org/download/testing/unarc2011-09-26.7z - теперь в загружаемых cls dll выполняются вызовы CLS_INIT и CLS_DONE, и выгружаются сами dll. проверь плиз. вместо op==-1 надо перехватывать op==CLS_DONE

спасибо, все работает (ток я unarc.dll компилил с SVN'а - очень удобно смотреть что поменялось в коде).

Цитата:

кстати, FA поддерживает и использование stdin/stdout

только этот метод какой-то не очень стабильный. И это не упрек в сторону фриарка, т.к. сам пытался реализовать клиент-хост передачу данных через stdin/out, и натыкался все на те же грабли - в некоторых случаях работает, в некоторых - нет. Так что вовсе отказался его использовать.

Цитата:

я попробовал zrle5 на 3 своих тестовых файлах - везде получилось хуже. можешь сам посмотреть

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

Добавлено:

Цитата:

http://freearc.org/download/testing/dll100.7z
http://freearc.org/download/testing/dll700.7z
http://freearc.org/download/testing/MsOfficeBCJ.7z

последние 2 архива не доступны для скачивания.

Добавлено:
З.Ы. я пока тож плюс в rle не смог получить.

Цитата:

Ерунда какая-то с последним FreeArc:
1. В GUI настройки при смене верхних пресетов вверху меняются.
2. Нигде не слова о том что надо packjpg.exe положить в папку freearc/bin (нужен подход как в megui с автообновлением компонентов)
3. Подаю на вход чистого packjpg 1.jpg, на выходе - получаю 80%. Запускаю с тем же файлом freearc с -m5p (или -m9p), packjpg пишет в консоле что вроде как работает, но на выходе архив 101%. WTF ?
4. freearc.ini данный здесь не до конца совместим с последней версией freearc, в частности те же -m5p не работают (а в -m81 jpg preprocess вроде как нет).
5. Почему бы не включить эти m81-m87 в официальную версию, в том числе сделать их доступными и через GUI ?

1. не понял
2. не нужно
3. вероятно ты используешь свой нестандартный ini-файл или ini-файл от предыдущих версий. в моём _майском_ arc.ini packjpg при -m5p не используется, вместо него джипеги сжимает precomp
4. это верно
5. первое - можно. второе - ты предлагаешь снова начать цикл смены gui? думаю достаточно того, что ты сам можешь их вставить в freearc.ini или просто набрать "81" в строке выбора метода сжатия

Цитата:

У меня проблем с распаковкой Daodata1.arc и daomain.dat не возникло.

так дело именно в том, что проблемы возникают у одного из 10.000. если б проблемы были у большинства - всё было б ясно, а так они оказываются в дураках

вот из моего расследования:
U:\>fc /b lp2.pcf.srep-r G:\lp2.pcf.srep-r
Сравнение файлов lp2.pcf.srep-r и G:\LP2.PCF.SREP-R
91DDA103: 2B 6B
BD1C6103: 9C DC

потом объясню. но по похожим адресам и номеру бита похоже на конкретную микросхему памяти

Bulat_Ziganshin

Цитата:

1. улучшения в -m3 пока не удалось реализовать. по большому счёту, если тебе не хватает памяти для кеширования всех необходимых частей файла, то остаётся только стиснуть зубы и ждать либо использовать -m1.

для меня выходом будет stdin/stdout но там сейчас не доделки, и хотелось бы чтобы у FreeArc\Arc\unarc был полноценный stdin/stdout.

Цитата:

compression made about 20% faster

Цитата:

3. потетстируй с -m1/2/3, с и без -nommap. особенно меня интересует окончательная разница в сжатии (после lzma) результатов -m1 vs -m3

1. Подопытный Nero-9.2.6.0_trial.tar 1883МБ, srep294_x64.exe \ srep293_x64.exe

[more=Результаты..]
srep294_x64.exe
Compression ratio: 1974371328 -> 549575868: 27.84%. Cpu 44.383 mb/sec, real 27.736 mb/sec -m1f -a1
Compression ratio: 1974371328 -> 550257240: 27.87%. Cpu 57.646 mb/sec, real 32.215 mb/sec -m1f -a2
Compression ratio: 1974371328 -> 550609420: 27.89%. Cpu 66.365 mb/sec, real 34.859 mb/sec -m1f -a4
Compression ratio: 1974371328 -> 550972564: 27.91%. Cpu 65.573 mb/sec, real 34.517 mb/sec -m1f -a8
Compression ratio: 1974371328 -> 551412320: 27.93%. Cpu 61.014 mb/sec, real 33.182 mb/sec -m1f -a16

Compression ratio: 1974371328 -> 549575868: 27.84%. Cpu 55.251 mb/sec, real 38.371 mb/sec -m2f -a1 -nommap
Compression ratio: 1974371328 -> 550257240: 27.87%. Cpu 74.593 mb/sec, real 46.822 mb/sec -m2f -a2 -nommap
Compression ratio: 1974371328 -> 550609420: 27.89%. Cpu 88.861 mb/sec, real 52.172 mb/sec -m2f -a4 -nommap
Compression ratio: 1974371328 -> 550972564: 27.91%. Cpu 89.808 mb/sec, real 51.446 mb/sec -m2f -a8 -nommap
Compression ratio: 1974371328 -> 551412320: 27.93%. Cpu 78.048 mb/sec, real 48.029 mb/sec -m2f -a16 -nommap

Compression ratio: 1974371328 -> 506471682: 25.65%. Cpu 48.303 mb/sec, real 33.788 mb/sec -m3f -a1 -nommap
Compression ratio: 1974371328 -> 506648001: 25.66%. Cpu 60.344 mb/sec, real 39.296 mb/sec -m3f -a2 -nommap
Compression ratio: 1974371328 -> 506368182: 25.65%. Cpu 65.778 mb/sec, real 41.099 mb/sec -m3f -a4 -nommap
Compression ratio: 1974371328 -> 506046268: 25.63%. Cpu 60.867 mb/sec, real 39.451 mb/sec -m3f -a8 -nommap
Compression ratio: 1974371328 -> 506086777: 25.63%. Cpu 52.410 mb/sec, real 35.309 mb/sec -m3f -a16 -nommap

Compression ratio: 1974371328 -> 549575868: 27.84%. Cpu 55.155 mb/sec, real 41.736 mb/sec -m2f -a1
Compression ratio: 1974371328 -> 550257240: 27.87%. Cpu 74.725 mb/sec, real 52.050 mb/sec -m2f -a2
Compression ratio: 1974371328 -> 550609420: 27.89%. Cpu 90.516 mb/sec, real 59.269 mb/sec -m2f -a4
Compression ratio: 1974371328 -> 550972564: 27.91%. Cpu 88.798 mb/sec, real 58.401 mb/sec -m2f -a8
Compression ratio: 1974371328 -> 551412320: 27.93%. Cpu 79.622 mb/sec, real 54.392 mb/sec -m2f -a16

Compression ratio: 1974371328 -> 506471682: 25.65%. Cpu 49.846 mb/sec, real 38.536 mb/sec -m3f -a1
Compression ratio: 1974371328 -> 506648001: 25.66%. Cpu 62.710 mb/sec, real 45.758 mb/sec -m3f -a2
Compression ratio: 1974371328 -> 506368182: 25.65%. Cpu 68.082 mb/sec, real 48.649 mb/sec -m3f -a4
Compression ratio: 1974371328 -> 506046268: 25.63%. Cpu 63.402 mb/sec, real 46.188 mb/sec -m3f -a8
Compression ratio: 1974371328 -> 506086777: 25.63%. Cpu 53.588 mb/sec, real 40.582 mb/sec -m3f -a16


srep293_x64.exe
Compression ratio: 1974371328 -> 549575868: 27.84%. Cpu 39.487 mb/sec, real 25.627 mb/sec -m1f -a1
Compression ratio: 1974371328 -> 549655828: 27.84%. Cpu 48.788 mb/sec, real 29.296 mb/sec -m1f -a2
Compression ratio: 1974371328 -> 549804900: 27.85%. Cpu 49.866 mb/sec, real 29.706 mb/sec -m1f -a4
Compression ratio: 1974371328 -> 550104920: 27.86%. Cpu 42.247 mb/sec, real 26.812 mb/sec -m1f -a8
Compression ratio: 1974371328 -> 550462548: 27.88%. Cpu 30.940 mb/sec, real 21.729 mb/sec -m1f -a16

Compression ratio: 1974371328 -> 549575868: 27.84%. Cpu 50.322 mb/sec, real 35.912 mb/sec -m2f -a1 -nommap
Compression ratio: 1974371328 -> 549655828: 27.84%. Cpu 69.658 mb/sec, real 44.501 mb/sec -m2f -a2 -nommap
Compression ratio: 1974371328 -> 549804900: 27.85%. Cpu 78.778 mb/sec, real 48.540 mb/sec -m2f -a4 -nommap
Compression ratio: 1974371328 -> 550104920: 27.86%. Cpu 72.872 mb/sec, real 45.830 mb/sec -m2f -a8 -nommap
Compression ratio: 1974371328 -> 550462548: 27.88%. Cpu 60.517 mb/sec, real 40.697 mb/sec -m2f -a16 -nommap

Compression ratio: 1974371328 -> 506471682: 25.65%. Cpu 45.032 mb/sec, real 32.006 mb/sec -m3f -a1 -nommap
Compression ratio: 1974371328 -> 506624945: 25.66%. Cpu 56.944 mb/sec, real 37.609 mb/sec -m3f -a2 -nommap
Compression ratio: 1974371328 -> 506363370: 25.65%. Cpu 57.202 mb/sec, real 38.023 mb/sec -m3f -a4 -nommap
Compression ratio: 1974371328 -> 506079623: 25.63%. Cpu 49.148 mb/sec, real 33.963 mb/sec -m3f -a8 -nommap
Compression ratio: 1974371328 -> 506113814: 25.63%. Cpu 37.110 mb/sec, real 27.593 mb/sec -m3f -a16 -nommap

Compression ratio: 1974371328 -> 549575868: 27.84%. Cpu 52.475 mb/sec, real 40.153 mb/sec -m2f -a1
Compression ratio: 1974371328 -> 549655828: 27.84%. Cpu 71.551 mb/sec, real 50.395 mb/sec -m2f -a2
Compression ratio: 1974371328 -> 549804900: 27.85%. Cpu 80.076 mb/sec, real 54.672 mb/sec -m2f -a4
Compression ratio: 1974371328 -> 550104920: 27.86%. Cpu 73.551 mb/sec, real 51.224 mb/sec -m2f -a8
Compression ratio: 1974371328 -> 550462548: 27.88%. Cpu 61.911 mb/sec, real 45.383 mb/sec -m2f -a16

Compression ratio: 1974371328 -> 506471682: 25.65%. Cpu 46.320 mb/sec, real 36.544 mb/sec -m3f -a1
Compression ratio: 1974371328 -> 506624945: 25.66%. Cpu 59.463 mb/sec, real 43.992 mb/sec -m3f -a2
Compression ratio: 1974371328 -> 506363370: 25.65%. Cpu 60.430 mb/sec, real 44.560 mb/sec -m3f -a4
Compression ratio: 1974371328 -> 506079623: 25.63%. Cpu 50.544 mb/sec, real 38.975 mb/sec -m3f -a8
Compression ratio: 1974371328 -> 506113814: 25.63%. Cpu 37.992 mb/sec, real 31.027 mb/sec -m3f -a16


Дожатие LZMA

arc.exe a Nero-9.2.6.0_trial.tar.srep294_m1f_a1.arc -mlzma:128m:bt4:128 Nero-9.2.6.0_trial.tar.srep294_m1f_a1
FreeArc 0.67 (November 17 2010) creating archive: Nero-9.2.6.0_trial.tar.srep294_m1f_a1.arc
Compressed 1 file, 550,249,940 => 208,237,262 bytes. Ratio 37.8%
Compression time: cpu 714.16 secs, real 718.73 secs. Speed 766 kB/s
All OK

arc.exe a Nero-9.2.6.0_trial.tar.srep294_m3f_a1.arc -mlzma:128m:bt4:128 Nero-9.2.6.0_trial.tar.srep294_m3f_a1
FreeArc 0.67 (November 17 2010) creating archive: Nero-9.2.6.0_trial.tar.srep294_m3f_a1.arc
Compressed 1 file, 506,463,502 => 204,878,047 bytes. Ratio 40.4%
Compression time: cpu 663.89 secs, real 665.47 secs. Speed 761 kB/s
All OK

arc.exe a Nero-9.2.6.0_trial.tar.srep294_m1f_a4.arc -mlzma:128m:bt4:128 Nero-9.2.6.0_trial.tar.srep294_m1f_a4
FreeArc 0.67 (November 17 2010) creating archive: Nero-9.2.6.0_trial.tar.srep294_m1f_a4.arc
Compressed 1 file, 551,279,632 => 208,328,827 bytes. Ratio 37.7%
Compression time: cpu 718.45 secs, real 723.58 secs. Speed 762 kB/s
All OK

arc.exe a Nero-9.2.6.0_trial.tar.srep294_m3f_a4.arc -mlzma:128m:bt4:128 Nero-9.2.6.0_trial.tar.srep294_m3f_a4
FreeArc 0.67 (November 17 2010) creating archive: Nero-9.2.6.0_trial.tar.srep294_m3f_a4.arc
Compressed 1 file, 506,359,874 => 204,878,513 bytes. Ratio 40.4%
Compression time: cpu 664.78 secs, real 666.84 secs. Speed 759 kB/s
All OK

arc.exe a Nero-9.2.6.0_trial.tar.srep294_m1f_a16.arc -mlzma:128m:bt4:128 Nero-9.2.6.0_trial.tar.srep294_m1f_a16
FreeArc 0.67 (November 17 2010) creating archive: Nero-9.2.6.0_trial.tar.srep294_m1f_a16.arc
Compressed 1 file, 552,068,596 => 208,342,870 bytes. Ratio 37.7%
Compression time: cpu 720.98 secs, real 724.55 secs. Speed 762 kB/s
All OK

arc.exe a Nero-9.2.6.0_trial.tar.srep294_m3f_a16.arc -mlzma:128m:bt4:128 Nero-9.2.6.0_trial.tar.srep294_m3f_a16
FreeArc 0.67 (November 17 2010) creating archive: Nero-9.2.6.0_trial.tar.srep294_m3f_a16.arc
Compressed 1 file, 506,059,929 => 204,863,352 bytes. Ratio 40.4%
Compression time: cpu 667.92 secs, real 672.72 secs. Speed 752 kB/s
All OK


Распаковка SREP

srep294_x64.exe -d -nomd5 Nero-9.2.6.0_trial.tar.srep294_m1f_a1 nul
Compression ratio: 1974371328 -> 550253040: 27.87%. Cpu 456.172 mb/sec, real 339.629 mb/sec. Matches 0 43298 168801, I/Os 0, MiBs 0 359 1217

srep294_x64.exe -d -nomd5 Nero-9.2.6.0_trial.tar.srep294_m1f_a2 nul
Compression ratio: 1974371328 -> 550932144: 27.90%. Cpu 426.891 mb/sec, real 103.853 mb/sec. Matches 0 42933 168237, I/Os 0, MiBs 0 369 1216

srep294_x64.exe -d -nomd5 Nero-9.2.6.0_trial.tar.srep294_m1f_a4 nul
Compression ratio: 1974371328 -> 551288832: 27.92%. Cpu 426.891 mb/sec, real 109.521 mb/sec. Matches 0 43065 169346, I/Os 0, MiBs 0 370 1214

srep294_x64.exe -d -nomd5 Nero-9.2.6.0_trial.tar.srep294_m1f_a8 nul
Compression ratio: 1974371328 -> 551650704: 27.94%. Cpu 438.749 mb/sec, real 111.386 mb/sec. Matches 0 43196 169019, I/Os 0, MiBs 0 371 1215

srep294_x64.exe -d -nomd5 Nero-9.2.6.0_trial.tar.srep294_m1f_a16 nul
Compression ratio: 1974371328 -> 552092176: 27.96%. Cpu 467.999 mb/sec, real 115.355 mb/sec. Matches 0 42807 169475, I/Os 0, MiBs 0 370 1212

srep294_x64.exe -d -nomd5 Nero-9.2.6.0_trial.tar.srep294_m3f_a1 nul
Compression ratio: 1974371328 -> 506474882: 25.65%. Cpu 435.723 mb/sec, real 122.378 mb/sec. Matches 0 41955 172483, I/Os 0, MiBs 0 380 1241

srep294_x64.exe -d -nomd5 Nero-9.2.6.0_trial.tar.srep294_m3f_a2 nul
Compression ratio: 1974371328 -> 506651057: 25.66%. Cpu 408.931 mb/sec, real 122.757 mb/sec. Matches 0 41436 172576, I/Os 0, MiBs 0 384 1240

srep294_x64.exe -d -nomd5 Nero-9.2.6.0_trial.tar.srep294_m3f_a4 nul
Compression ratio: 1974371328 -> 506371254: 25.65%. Cpu 418.410 mb/sec, real 123.105 mb/sec. Matches 0 41443 172875, I/Os 0, MiBs 0 384 1237

srep294_x64.exe -d -nomd5 Nero-9.2.6.0_trial.tar.srep294_m3f_a8 nul
Compression ratio: 1974371328 -> 506049292: 25.63%. Cpu 437.231 mb/sec, real 123.797 mb/sec. Matches 0 41399 173040, I/Os 0, MiBs 0 387 1239

srep294_x64.exe -d -nomd5 Nero-9.2.6.0_trial.tar.srep294_m3f_a16 nul
Compression ratio: 1974371328 -> 506089673: 25.63%. Cpu 412.940 mb/sec, real 115.477 mb/sec. Matches 0 41332 173304, I/Os 0, MiBs 0 387 1235
[/more]

Цитата:

последние 2 архива не доступны для скачивания.

http://freearc.org/download/testdata/dll100.7z
http://freearc.org/download/testdata/dll700.7z
http://freearc.org/download/testdata/MsOfficeBCJ.7z


Цитата:

SVN'а - очень удобно смотреть что поменялось в коде)

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


Цитата:

stdin/stdout
только этот метод какой-то не очень стабильный.

а в чём нестабильность выражается?

Да, половину слов не скопировал
1. В GUI настройки при смене верхних пресетов вверху галочки внизу не меняются.
3. Стандартный ini из последней версии. Что из GUI, что через -m5p размер не уменьшается.
5. С точки зрения удобства людей наиболее лучшие по скорости/уровню сжатия режимы m81-m87 просто обязаны быть в GUI и более того, выбраны по умолчанию. Возможно даже заменить ими стандартные -m1.. Или сделать подход как в x264, есть пресеты вида superfast, medium, slow, и другие, и в разные моменты времени их внутренности меняются, но названия остаются. Так и здесь, ввести superfast, который плавно мигрирует с -m1 на -m81.

Что хочу сказать по поводу packjpg. Дикий тормоз, на фоне того же x264 с теми же алгоритмами арифметического сжатия. Если x264 на i7-860 выдаёт на 2Mpx FullHD -medium в районе 12fps, то та же 16Mpx jpg имеет в 8 раз больший объём, и должна сжиматься как минимум за полсекунды, но 4.5секунды это перебор, тем более там нет никакого motion compensation, как в x264, и просто расжимаются DCT коэффициенты из VLC и пережимаются в AC. Так что поле для оптимизация вижу как минимум раз в 10, неплохо бы автору packjpg взять некоторые готовые процедуры из кода x264.

Лог -m9p

Код:
C:\Program Files (x86)\FreeArc\bin>arc a 1jpg.arc 1.jpg -m9p
FreeArc 0.67 (May 22 2012) creating archive: 1jpg.arc
Compressing 1 file, 4,307,553 bytes. Processed 0%
Compressing 4,307,553 bytes with precomp042 -c- -t-j -intense -o$$arcpackedfile
$$.tmp $$arcdatafile$$.tmp

Precomp v0.4.2 - ALPHA version - USE FOR TESTING ONLY
Free for non-commercial use - Copyright 2006-2011 by Christian Schneider

Input file: $$arcdatafile$$.tmp
Output file: $$arcpackedfile$$.tmp

Using PACKJPG.DLL for JPG recompression.

--> packJPG DLL v2.4WIP4 (11/06/2008) by Matthias Stirner <--
More about PackJPG here: http://www.elektronik.htw-aalen.de/packjpg

100.00% - New size: 4307589 instead of 4307553

Done.
Time: 4 seconds, 477 milliseconds

Recompressed streams: 0/16
zLib streams (intense mode): 0/16

None of the given compression and memory levels could be used.
There will be no gain compressing the output file.

Errorlevel=2
10%
Compressing 4,307,566 bytes with srep -m3f -mem256mb $$arcdatafile$$.tmp -

SREP 3.0 (January 30, 2012): input size 4 mb, memory used 33 mb, -m3f -l512 -c256 -a4
100%: 4,307,566 -> 4,301,537: 99.86%. Cpu 88 mb/s, real 59 mb/s
Second pass: 100%

Errorlevel=0
Compressed 1 file, 4,307,553 => 4,321,369 bytes. Ratio 100.3%
Compression time: cpu 1.01 secs, real 6.88 secs. Speed 626 kB/s
All OK

Цитата:

я попробовал zrle5 на 3 своих тестовых файлах - везде получилось хуже.

Да действительно, на одиночных файлах не получается. Я кажись догадался, в чем дело. Я когда жал каталог windows, zrle стоял до разбиения на солид-блоки. Соответственно, каждый блок содержал в среднем больше файлов, отсюда и получился плюс.

Однако, это навело меня на мысль, может быть имеет смысл ставить некоторые процессоры до разбиения на solid-блоки...

SREP 2.95 alpha:

* -mem option limits amount of RAM used for future-LZ decompression
* -vmfile and -vmblock options fine-tunes VM file used in -mem mode

Tests with the same 22gb->7gb file:

Код: : Cpu 211.560 mb/sec, real 165.110 mb/sec. Matches 0 174390 1449482, I/Os 0, RAM 0/1919, VM 0/0, R/W 0/0
-mem1g : Cpu 203.116 mb/sec, real 151.955 mb/sec. Matches 0 174390 1482625, I/Os 0, RAM 0/983, VM 0/1000, R/W 1560/1560
-mem500: Cpu 193.556 mb/sec, real 136.138 mb/sec. Matches 0 165382 1621776, I/Os 0, RAM 0/460, VM 0/1656, R/W 3768/3768
-mem200: Cpu 146.510 mb/sec, real 99.487 mb/sec. Matches 0 70888 2376056, I/Os 0, RAM 0/160, VM 0/2136, R/W 12120/12120
-mem100: Cpu 76.815 mb/sec, real 54.448 mb/sec. Matches 0 29368 4950862, I/Os 0, RAM 0/60, VM 0/2360, R/W 36760/36760