» FreeArc: бесплатный open-source архиватор - Часть 3

Цитата:

rep:256

а здесь чего хотели написать?

а что, srep полностью заменяет rep или их нужно комбинировать?
в смысле srep теперь будет external наподобие как BCJ2 от 7 zip?

egor23 там букавку m потерял))) не ту строчку копирнул. сделал так: -m=srep:l256+rep:256m+lzma:256m

эффекта 0(

crotoff

Цитата:

а что, srep полностью заменяет rep или их нужно комбинировать

srep применяется когда размера словаря rep недостаточно
незабывая что при распаковке srep - идут дисковые операции по сути...

блин в упор не пашет srep. не пойму в чем дело - то ли файлы не туда кинул, то ли в арк.ини неправильно добавил

Цитата:

блин в упор не пашет srep. не пойму в чем дело - то ли файлы не туда кинул, то ли в арк.ини неправильно добавил

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

Добавлено:

Цитата:

потом в arc.ini добавил вот это

тут тоже ошибка, у меня было другое

Добавлено:
improved arc.ini section:

[External compressor:srep]
;options = l%d (minimal match length, default=512)
packcmd = srep {options} $$arcdatafile$$.tmp $$arcpackedfile$$.tmp
unpackcmd = srep -d $$arcpackedfile$$.tmp $$arcdatafile$$.tmp

Bulat_Ziganshin да юмор это хорошо, но видно лыжи у меня седня совсем не едут(((

всё же просто - если у тебя возникает ошибка при сжатии, то пускаешь с опциями -di -di+$ и кидаешь сюда консольный вывод. впишите это кто-нибудь в фак

Bulat_Ziganshin просто консольным фриарком я ваще не владею и не пользуюсь) и ошибок при сжатии нет, просто потому что сжатия никакого нет. раз окошко запаковки пустое, то значит непонятна команда - правильно я понимаю??? а раз так, то либо файлы не там, либо в арк.ини не то вписано. в ини вписал то что дано последним, файлы лежат в PowerPack\bin - вот и не пойму в чем же дело. ладно попробую позже на здоровую голову, а то температура еще выше поднимится)))

Цитата:

просто консольным фриарком я ваще не владею и не пользуюсь

в таком случае тебе остаётся только гадать о причинах проблем

Всем привет!
Хочу спросить вот какой вопрос:
Я вот решил попробовать упаковать игру. Да вот проблемма, в ней куча файлов *.bin и *.wav. Если сжимать отдельно файлы *.bin методом -m9b -ld512m и отдельно *.wav методом -mx -ld512m и потом объединить два архива в один, то размер получается самый маленький из всех архивов, нежели всю папку паковать -mx -ld512m или -m9b -ld512m.

Я уже пробовал отключать авто-определение типов файлов -mx -ma- -ld512m
Также редактировал arc.groups в нем перенес *.bin из раздела $iso в раздел $binary. но непомогает.
Пробовал и в консольной версии и в GUI, и с методом -m9x -ma- -ld512m и -m9 -ma- -ld512m. читаю справку, и вроде бы все правильно. Как оказалось *.bin - текстура tga с измененным расширением. А значит:
- *.bin для наименшего размера нужно паковать -m9b.
- *.wav (а также оставшиеся пару *.exe и *.dll) наилучше -mx
по-отдельности - все гладко и ровно, вместе - почему-то путаюсь в командах.

Как задать правильно? Где ошибка?

ruduk
здесь читать как-то удобнее

дай команду lt на оба архива. поудмай. потом запусти упаковку с ключами -di -di+$. дальше уивдишь сам - дело в exe-фильтре. его можно отключить через -mce-. или занести эти файлы в группу $obj


Добавлено:
народ, я хочу сделать huge files test для пропаганды fa/srep. первым элементом в нём должна стать популярная игрушка. что у нас было самое массовое в 2009-м, prototype?

Добавлено:
да, хотелось бы гиг 8. игрушек такого размера довольно много

Последнее Dragon Age занимает установленная на винте помоему гигов 15, Call of duty MW 2 11 гб, FEAR 2 12.1 Гб с последним патчем), Batman Arkham Asylum 8 Гб помоему, если еще что то вспомню, prototype тож ниче вроде. Call of duty и fear без прекомпа не обойтись). Во Resident evil 5, занимает на винте 7 гб, для сжатия использовал только rep1gb и получилось как раз на 1 болванку 4.18 Гб.

тогда ещё вопрос - что мне жать, iso или установленную?

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

Я вот думаю потестить Star Ocean 4 для XBOX'а - там три диска DVD-9, так что всего должно быть около 24 Гб. И много повторов - т.к. игра консольная, так что первый диск пересекается со вторым, а второй - с третьим. Интереснее всего тестировать tar, в котором файлы расположены в последовательности disk1 disk3 disk2 - это покажет, насколько srep справляется, даже если кеша 1 Гб, всё равно дистанции окажутся огромными. А вообще - скоро выйдет наипопулярнейшая игра этого жанра - Final Fantasy 13 и версия для XBOX'а там - тоже 3xDVD-DL. Так что тоже вариант. Японская версия FF13 будет уже 19 декабря, а вот английской придётся ждать до 9 марта. Судя по википедии.

Bulat_Ziganshin
Respect once again! Thank you for your cooperation! I'll try your advice some other day, maybe tomorrow.

Call of Duty обычно упаковывают без сжатия, или, если по-точнее, в COD4 и COD5 текстуры и звуки упаковали zip'ом, а на диск записали в архиве без сжатия, типа tar. А остальную часть, bik-файлы записали сразу на диск, и они при установке просто копируются в каталог установки. то-есть для COD4, 5 не будет иметь значения паковать установленное или образ.
А вот в Modern Warfare 2 ("COD6") уже используют sid-архивы или пакеты Steam, то-есть запакованные и зашифрованные. И можно попробывать упаковать и уже установленную игру, а потом образ, чтобы проверить насколько сильно сжимаются sid-файлы. То-ли они шифрованные хорошо, то-ли сжато каким-то алгоритмом, но устанавливается (распаковывается и дешифруется) быстро, даже на машинах с 512 ОЗУ. Или там пару раз дублируются файлы, либо текстуры одинаковые и отличаются только цветом. я незнаю. Но есть специальные распаковщики для sid, и я как-то после распаковки оригинального CS:Source и пережатия его FA (где-то тогда, когда была stupid error в grzip модификации) получил на 50% меньший размер установки, а все проделываемые установщиком настройки в реестре сохранил как reg-файл.
Значит - пакуем Call of Duty Modern Warfare 2

Да, небольшой апдейт к той серии тестов:
Было

Цитата:

rep:128+srep08-l128+rep:128+lzma - 3649.819 -> 3142.025 Мб.
Время сжатия lzma: cpu 9351.99 secs, real 8523.16 secs. Speed 449 kB/s

srep08-l256+rep:256+lzma 3794.507 Мб -> 3141.463 Мб
Время сжатия lzma: cpu 7286.25 secs, real 5701.19 secs. Speed 698 kB/s

srep08-l256+srep08-l256+rep:256+lzma - 3798.033 Мб -> 3142.265 Мб
Время сжатия lzma: cpu 8289.27 secs, real 6429.42 secs. Speed 619 kB/s

srep08-l16kb+rep:512+lzma 3828.626 Мб -> 3144.797 Мб
Время сжатия lzma: cpu 7664.74 secs, real 6389.70 secs. Speed 628 kB/s

Добавление:
srep08-l512+lzma 3911.294 Мб -> 3140.587 Мб
Время сжатия lzma: cpu 7210.52 secs, real 5147.89 secs. Speed 797 kB/s

Т.е. srep-512 выиграл у всех - для lzma l512 и правда оказывается оптимальной. Хотя сжатие проводилось, когда все фоновые процессы были совсем отрублены.
Но размер стал меньше на 918 125 байт по сравнению с прошлым лидером srep08-l256+rep:256+lzma .

Хотя ещё может быть, что srep+rep или rep+srep - избыточны по сравнению с одним srep, и мешают сжатию lzma... Но это я буду уже завтра проверять, если ничего не помешает...

Bulat_Ziganshin жать надо установленную. бэтмена, прототип и колл оф дути смысла нет. бетмен из 7,5 гб почти 3 Гб bik-видео - даже на 1 двд без потерь сделать не вариант - у меня 5,3 Гб получалось тока. прототип и того хуже там видео еще больше. колл оф дути последний равно как и предыдущие без прекомпа никак не взять, ФИАР 2 тоже самое - прекомп нужен(если не распаковывать архивы игры - если распаковать то там уже все поинтереснее будет). Резидент просто с репом влазиет на двд, но можно попробовать с srep впихнуть два звука - тогда это будет интересно. Драгон Эйдж можно канеш попробовать, но там тоже много видео и звука, который фиг пожмешь. пока на ум не приходят игры где можно попробовать)

ЗЫ у кого работает srep киньте мне arc.ini - может я все-таки не так вписал)))

ЗЗЫ кстати думаю можно попробовать на NBA 2K10 - если ее получится впихнуть на 1 двд, то это будет круто - пока никто это не смог сделать)))

NattyBampo
http://freearc.org/download/testing/arc.ini

Bulat_Ziganshin

Цитата:

http://freearc.org/download/testing/arc.ini

Цитата:

http://freearc.org/download/testing/find_stream_match

404 - File or directory not found.

http://freearc.org/download/testing/arc.ini.zip

как обычно проблема в mime. find_stream_match перезаливать не буду, нафиг он кому нужен

Bulat_Ziganshin спасибо заработало - значит не так вписал))) буду тестить

Bulat_Ziganshin

Цитата:

да, хотелось бы гиг 8. игрушек такого размера довольно много

но не у всех есть повторы на больших растояниях

У консольных-приставочных - ещё какие - Star Ocean 4 я как то обычным rep:1.5 gb тестил, разбив каждый диск на куски и сравнивая каждый с каждым - по моим прикидкам вышло, что раза в 1.5 должно было бы ужаться как минимум - если бы словарь был не 1.5 Гб, а все 24. С Final Fantasy 13 вполне вероятна та же история - она ведь тоже на трёх DVD+DL, если для X-BOX'а (впрочем, в те времена, когда у меня был лишь 1 Гиг операивки, и я не мог задействовать rep без торомзов на полную катушку, со словарём больше 500-700 Мб - те же явления происходили с играми на одном ДВД - например, имеетюся определённые пороги словарая rep? после которых даже Shadow Hearts 1 стала сжаиматьcя не до 1900-2000 мб, а до 1500 - или около того (приходилось использовать лишний rep - rep:4mb:32+rep:368mb:32+lzma давали те же 1595 миллионов байт, что и rep:512mb:96+lzma, а вот rep:384mb:96+lzma - лишь 1890 (только rep:512mb:96+lzma хватало для достижения тех 1590)). Хотя Причём была она на одном диске DVD, и всего 3 гб весила. Так что для старых систем с 1 Гб оно помогло бы... Хотя эти тесты - двухлетней давности - но просто повторение ситуации, когда вместо DVD5 будут DVD9 вполне вероятно. Или когда 2xDVD5 станут 2xDVD9 - прошерстить обычным rep'ом те же Shadow Hearts 2 c 2-мя DVD-5 вообще нереально в 32-битной системе - не сжимается отдельный диск меньше, чем до 2-2.5 Гб - а повторы наверняка будут (так что и ещё один rep:1700mb не поможет - придётся образы пилить на несколько частей и переставлять, и искать какие куски совпадают, а какие не очень)... Так что смотри результаты Rogue Galaxy выше - для консольных игр на 2-х и более ДВД оно очень актуально... Star Ocean 4 также ещё наверняка покажет ужатие в 1.5 раза по сравнению с обычным rep - тут главный вопрос, насколько быстро пойдёт распаковка srep...

Цитата:

тут главный вопрос, насколько быстро пойдёт распаковка srep...

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

второй вопрос - насколько улучшится srep от добавляения точных матчей (сейчас он в отличие от rep матчит только блоками по L байт, выравненными на L-байтную границу)

Bulat_Ziganshin я так понимаю при распаковке окошко srep вылазить будет???

Bulat_Ziganshin,

Цитата:

народ, я хочу сделать huge files test для пропаганды fa/srep. первым элементом в нём должна стать популярная игрушка

Когда сделаете, стоит ждать что-то вроде инструкции по использованию связки fa/step/inno??? Или кто уже знает, поделитесь, пожалуйста! Кстати, в репаке игры Rogue Warrior от деда заметил step.dll... Очень хотелось бы знать что да к чему, и овладеть вышеупомянутой связкой...

Цитата:

дык нет вопросов - давай по старой схеме: я выкладываю архив у себя на фтп, ты качай да изучай, вес - 3Гб.
вот ltПодробнее...

опиши проблему. без лирики.

а сколько у тебя там wav-файлов? есть подозрение, что память фрагментируется из-за того, что их слишком много. может, для пробы перепакуешь архив с -mc-tta ?

wav-файлов действительно много: 18.712 в 397 папках.

Описываю проблему еще раз:

Если коротко - при распаковке архива с помощью unarc.dll весрии 3.3 или 3.4 - процесс молча исчезает не завершив работу и прихватив с собой инносетап, т.е. не сообщая ни ему ни системе какой-либо код ошибки. Происходит это во время распаковки wav-файлов. Кроме того скорость распаковки архивов с тта гораздо ниже в версии 3.4 по сравнению с 3.3

Теперь подробнее:
1) Берем, в данном случае, 6 архивов, пожатых разными способами. Максимальная требуемая ОЗУ для распаковки составляет 384Мб у 3х из них, у остальных - и того меньше. Один архив сжат методом тта+что-то (жал не я), для распаковки требует пару Мб.
Вот их lt
[more]
FreeArc 0.60 RC (November 18 2009) listing archive: data1.arc
Pos Size Compressed Files Method
-----------------------------------------------------------------------------
31 0 0 25 storing
31 3.072.554 150.183 260 dict:3032kb:80%:l8192:m400:s100+lzp:3032kb:92%:145:h22:d1mb+ppmd:16:384mb
150.214 1.886 393 1 mm+grzip:3kb:m1:l2048:h12:a
150.607 1.563 166 1 mm+grzip:3kb:m1:l2048:h12:a
150.773 1.563 167 1 mm+grzip:3kb:m1:l2048:h12:a
150.940 1.563 165 1 mm+grzip:3kb:m1:l2048:h12:a
151.105 1.068 79 1 mm+grzip:2kb:m1:l2048:h11:a
151.184 1.068 79 1 mm+grzip:2kb:m1:l2048:h11:a
151.263 1.563 162 1 mm+grzip:3kb:m1:l2048:h12:a
151.425 1.068 79 1 mm+grzip:2kb:m1:l2048:h11:a
151.504 1.068 79 1 mm+grzip:2kb:m1:l2048:h11:a
151.583 1.563 167 1 mm+grzip:3kb:m1:l2048:h12:a
151.750 1.068 79 1 mm+grzip:2kb:m1:l2048:h11:a
151.829 911 144 1 mm+grzip:2kb:m1:l2048:h11:a
151.973 1.406 194 1 mm+grzip:2kb:m1:l2048:h11:a
152.167 911 145 1 mm+grzip:2kb:m1:l2048:h11:a
152.312 1.406 180 1 mm+grzip:2kb:m1:l2048:h11:a
152.492 1.307 301 1 mm+grzip:2kb:m1:l2048:h11:a
152.793 1.068 99 1 mm+grzip:2kb:m1:l2048:h11:a
152.892 1.068 124 1 mm+grzip:2kb:m1:l2048:h11:a
153.016 1.307 276 1 mm+grzip:2kb:m1:l2048:h11:a
153.292 1.307 276 1 mm+grzip:2kb:m1:l2048:h11:a
153.568 1.307 276 1 mm+grzip:2kb:m1:l2048:h11:a
153.844 1.307 276 1 mm+grzip:2kb:m1:l2048:h11:a
154.120 10.284 421 1 mm+grzip:11kb:m1:l2048:h14:a
154.541 1.068 142 1 mm+grzip:2kb:m1:l2048:h11:a
154.683 1.068 149 1 mm+grzip:2kb:m1:l2048:h11:a
154.832 1.068 125 1 mm+grzip:2kb:m1:l2048:h11:a
154.957 1.068 226 1 mm+grzip:2kb:m1:l2048:h11:a
155.183 210 80 1 mm+grzip:1kb:m1:l2048:h10:a
155.263 274 74 1 mm+grzip:1kb:m1:l2048:h10:a
155.337 274 73 1 mm+grzip:1kb:m1:l2048:h10:a
155.410 274 76 1 mm+grzip:1kb:m1:l2048:h10:a
155.486 274 73 1 mm+grzip:1kb:m1:l2048:h10:a
155.559 812 151 1 mm+grzip:2kb:m1:l2048:h11:a
155.710 85.201.087 40.445.336 427 rep:83mb+exe+delta+lzma:83mb:normal:bt4:128
40.601.046 8.378 5.686 1 tta
40.606.732 8.378 5.686 1 tta
40.612.418 11.386 6.800 1 tta
40.619.218 13.628 8.338 1 tta
40.627.556 10.682 6.867 1 tta
40.634.423 5.006 3.535 1 tta
-----------------------------------------------------------------------------
751 files, 88.376.119 bytes, 40.637.927 compressed

FreeArc 0.60 RC (November 18 2009) listing archive: data2.arc
Pos Size Compressed Files Method
-----------------------------------------------------------------------------
31 0 0 364 storing
31 408 361 1 rep:1kb+exe+delta+lzma:32kb:normal:32:mc16
392 10.254.060 10.080.937 8 rep:10mb+tor:10mb:c3
10.081.329 89.788 79.349 1 tta
10.160.678 44.944 29.940 1 tta
10.190.618 197.764 54.293 1 tta
10.244.911 44.998 32.779 1 tta
10.277.690 536.528 410.243 1 tta
10.687.933 461.878 225.995 1 tta
... много тта (вырезано)
1.528.272.454 94.880 44.892 1 tta
1.528.317.346 365.900 192.552 1 tta
1.528.509.898 365.900 200.195 1 tta
1.528.710.093 39.122 26.499 1 tta
1.528.736.592 62.566 26.758 1 tta
1.528.763.350 121.018 68.989 1 tta
1.528.832.339 93.844 60.963 1 tta
1.528.893.302 66.508 45.781 1 tta
-----------------------------------------------------------------------------
11.633 files, 2.761.800.128 bytes, 1.528.939.052 compressed

FreeArc 0.60 RC (November 18 2009) listing archive: data3.arc
Pos Size Compressed Files Method
-----------------------------------------------------------------------------
31 0 0 18 storing
31 11.173 1.544 2 rep:12kb+exe+delta+lzma:32kb:normal:32:mc16
1.575 113.786 44.020 1 tta
45.595 119.712 44.829 1 tta
90.424 81.194 28.974 1 tta
119.398 90.082 30.844 1 tta
150.242 101.934 37.732 1 tta
187.974 101.934 37.071 1 tta
225.045 84.156 32.382 1 tta
257.427 130.082 55.116 1 tta
... много тта (вырезано)
438.014.621 206.260 132.769 1 tta
438.147.390 140.519 93.850 1 tta
438.241.240 74.318 48.713 1 tta
438.289.953 63.019 43.821 1 tta
438.333.774 82.429 52.063 1 tta
-----------------------------------------------------------------------------
7.463 files, 657.121.984 bytes, 438.385.806 compressed

FreeArc 0.60 RC (November 18 2009) listing archive: data4.arc
Pos Size Compressed Files Method
-----------------------------------------------------------------------------
31 0 0 2 storing
31 28.402.074 19.393.706 10 rep:28mb+exe+delta+lzma:28mb:normal:32:mc16
19.393.737 386.585.352 383.416.580 7 rep:96mb+tor:16mb:c3
-----------------------------------------------------------------------------
19 files, 414.987.426 bytes, 402.810.286 compressed

и еще 2 подобных архива...
[/more]
2) Объединяем эти архивы в один джойном, для чего используем последнию доступную версию фа или одну из более старых.
3) Все офорляем в инносетап, лепим арк к сетапу и устанавливаем
4) Во время установки/распаковки:
если использовать unarc.dll весрии 3.3, визуально доходит до половины распаковки и молча отваливается, т.е. не выдввая никаких предупреждений или ошибок. За собой валит инносетап.
если использовать unarc.dll весрии 3.4, визуально доходит дальше, но скорость распаковки очень и очень сильно падает, до 1мб/сек или меньше. В этом месте выглядит как зацикливание на распаковке одних и тех же файлов (меряю размер папки с помощью ТС - она колеблется, но цифры одни и те же, сначала рост, затем сброс до той же "начальной" цифры и снова рост) на протяжении где-то 20-30 мин, после чего точно также молча падает.

Далее, архив "пересобрал" так, чтобы архив с тташными вав-ками был последним. Это решило проблему, но все же с весрсией 3.3 распаковка на вав-ках заметно медленнее чем на других архивах, причем в разы. А версия 3.4 в том же месте вообще dramatically slow! Я просто не выдержал дожидаться полной распаковки. Т.е. выглядит так, что версия 3.4 хуже чем 3.3 в смысле скорости распаковки, по крайней мере тта, но обе версии содержат одну и ту же ошибку.

В связи с вышесказанным есть ли все еще смысл в "для пробы перепакуешь архив с -mc-tta" ?

Цитата:

второй вопрос - насколько улучшится srep от добавляения точных матчей (сейчас он в отличие от rep матчит только блоками по L байт, выравненными на L-байтную границу)

Не знаю насчёт других данных, но на этих 7.5 Гб результат вышел такой:

srep-16kb+lzma:192mb:max 4.572.251.124 => 3.297.545.899 bytes. Ratio 72.1%
Compression time: cpu 8767.70 secs, real 7578.52 secs. Speed 603 kB/s

rep:512+srep-512+lzma 4.002.779.320 => 3.294.577.644 bytes. Ratio 82.3%
Compression time: cpu 7674.43 secs, real 6768.63 secs. Speed 591 kB/s

rep:256+srep-512+lzma 3.927.490.696 => 3.294.442.325 bytes. Ratio 83.8%
Compression time: cpu 7988.63 secs, real 6647.13 secs. Speed 591 kB/s

rep:256+srep-256+lzma 3.926.065.808 => 3.294.808.056 bytes. Ratio 83.9%
Compression time: cpu 7974.75 secs, real 6673.66 secs. Speed 588 kB/s

srep-512+lzma 4.101.289.228 => 3.293.144.163 bytes. Ratio 80.2%
Compression time: cpu 7210.52 secs, real 5147.89 secs. Speed 797 kB/s


Разумеется, первым четырём разультатам могли мешать множество вкладок файрфокса или симонкей, так что время вышло большее. Но сжимаемость ну просто очень мало пострадала. Даже если матчить болками по 16Кб, выравненными под те же 16 Кб.

При этом l128 - далеко не лучший вариант по любому:
srep-128+lzma 3.916.538.436 => 3.294.102.320 bytes. Ratio 84.1%
Compression time: cpu 8419.50 secs, real 6596.33 secs. Speed 594 kB/s

srep-128+rep:128+lzma 3.879.943.240 => 3.297.288.815 bytes. Ratio 84.9%
Compression time: cpu 7724.89 secs, real 6584.84 secs. Speed 589 kB/s

rep:128+srep-128+rep:128+lzma 3.827.112.122 => 3.294.651.845 bytes. Ratio 86.0%
Compression time: cpu 9351.99 secs, real 8523.16 secs. Speed 449 kB/s

Тут проход rep-ом даже ухудшил результат...

srep-16kb+rep:512+lzma 4.014.605.104 => 3.297.558.308 bytes. Ratio 82.1%
Compression time: cpu 7664.74 secs, real 6389.70 secs. Speed 628 kB/s
Толку в смысле степени сжатия от rep:512 - даже минус, хотя в смысле времени вроде стало лучше. Вот только результаты в смысле времени у такого rep'а - сводят выигрыш на нет (хотя это конечно из-за a99, которая наверно избыточна):
srep-16kb->rep:512(:a99) выдаёт 4.572.251.124 => 4.014.604.842 bytes. Ratio 87.8%
Compression time: cpu 979.48 secs, real 1350.09 secs.

Т.е. lzma после srep-16kb даёт cpu 8767.70 secs, real 7578.52, lzma после srep-16kb+rep:512 - cpu 7664.74 secs, real 6389.70 secs. Разница - 1102.96 secs cpu, 1188.82 secs real - примерно столько же, сколько уходит на rep:512:a99:h27:1700mb . И сжимаемость даже ухудшается - хоть и всего на 12 кб...

В результате выходит, что rep после srep'а смысла не имеет - на этих данных и с дожатием lzma:192mb:max:lc8... Хотя можно в принципе посмотреть варианты rep без a99 - да больно оно долго будет, повторять половину тестов... Что можно глянуть, так это srep+lzma:959mb:mc29:h896mb - ведь тут встроена хорошая замена rep. Ещё можно испробовать lc8 к этому - а может, уменьшить mc до 3-ех - для высокой скорости такого lzma. Помимо этого есть ещё вариант rep+srep - он-то как раз вроде выглядит полезнее. Но наверное в фриарк с srep-препроцессором его не встроишь - он должен идти первым при сжатии и последним при распаковке, иначе придётся разбираться с лишним tempfile'ом...

Но в принципе, возможно стоит расчищать место да переходить к тестированию 24 Гб SO4... Ссылку на скачивание сейчас дать не могу - убрали её... Хотя может и можно как-нибудь исхитриться с тем торрентом - DHT ещё работает...

Короче, есть три варианта дальнейших тестов - rep+srep, srep+lzma:959mb или уже переходить к 24 Гб... Что предпочтительнее - второе имеет смысл (ведь моё впечатление от ht4 - rep встроенный в lzma, только matchfinder чуть послабее)?

Добавлено:
Так, похоже моим результатам в смысле времени и скорости lzma особо доверять не стоит - в последнем сеансе у меня было открыто слишком много окон и вкладок Firefox'а да Seamonkey (а может ещё что в фоне мешало - тот же торрент кажется был всё таки запущен) - а когда их в сумме штук 20-30, то они у самой системы окусывают много ресурсов, и Freearc медленнее работает... Но совсем не использовать инет пока что-то сжимается по два часа на файл, а файлов этих с десяток - для меня уже слишком .

Вот ещё пара результатов, которые окончательно мне это подтвердили:

srep256+lzma 4.011.245.268 => 3.293.358.015 bytes. Ratio 82.1%
Compression time: cpu 9240.61 secs, real 8069.13 secs. Speed 497 kB/s

srep256+srep256+lzma 3.997.881.040 => 3.293.098.543 bytes. Ratio 82.3%
Compression time: cpu 9118.75 secs, real 7554.55 secs. Speed 529 kB/s

Причём при сжатии второго файла активности было куда как меньше.