» Архиваторы. Сравнение сжатия

Viewgg
Полностью согласен насчет PAQ, RK и т.д.
У меня они, кстати, есть, но пользоваться ими невозможно. И скорость жутко медленная, и нет гарантии правильной распаковки (практически все free, и видимо мало тестируются).
А вот насчет CAB я не согласен. Иногда (в основном на файлах типа EXE, DLL) он даже лучше RARа.
UHARC я бы тоже не исключал. Он, конечно, самый медленный из распространенных, но жмет хорошо и даже иногда встречается на CD.

arsvrn

Цитата:

UHARC я бы тоже не исключал. Он, конечно, самый медленный из распространенных, но жмет хорошо и даже иногда встречается на CD.

Согласен. Мне не раз попадались варезные рипы игр по 150-180 Мб, которые при распоковке оказывались чуть ли не 700Мб -айтными дистрибутивами.

arsvrn
19:52 17-01-2005
Цитата:

И скорость жутко медленная, и нет гарантии правильной распаковки (практически все free, и видимо мало тестируются).

Как это

Цитата:

практически все free

???
WinRK уже давно платный. А потом,

Цитата:

нет гарантии правильной распаковки

Так ведь обратное преобразование у них существует и притом единственное...

arsvrn

Цитата:

А вот насчет CAB я не согласен. Иногда (в основном на файлах типа EXE, DLL) он даже лучше RARа.

Иной раз даже просто поразительно, насколько лучше. Вот на днях запаковал разные дистрибутивчики и по одной из программок получил такие результаты, что от изумления чуть не упал, поскольку такого эффекта раньше не получал: zip заимел размер 663927, rar 659544, 7z 440768, cab 230761 байт! В составе дистрибутива 7 файлов общим размером 3230381 байт. Естественно, настройки соответствующих архиваторов были на максимум сжатия.

В тему CAB-а.
Действительно, иногда оказывается очень неплохим - как-то надо было в дискетку запихнуть дистрибутив драйвера - ни zip, ни rar не влезли. А Вот cab - как раз оказался, + нет проблем при распаковке (IMHO не последнее дело).
Сам юзаю zip (по старинке исключительно + скорость работы ИМХО важно) cab и arj !
Ага, вот такую вот древность приходится пользовать.

Вопрос к all (сорри, может это и офф, но... может в курсах ?) -
у какого из архиваторов (я знаю и пользуюсь в arj + нашел здесь про rar) есть такая штука, как создание PROTECTED archive (ну, избыточность для восстановления) + работа из CMD (консоли) + нормальное понимание русского языка (кажется за это rar и не покатил, консольный естественно).
Просто ищу, чего можно к батнику самолепной архивации прикрутить...

Заранее благодарен за конструкивную инфу.

P.S. ИМХО рассуждения, что по модему инфа (изначального объема 200) сжатая до 50 льется быстрее зажатой до 100 в 2 раза не совсем верно... Модемы тоже жмут при передаче, правда - слабо, но все-таки жмут...

TCPIP

Цитата:

WinRK уже давно платный

Это единственный не бесплатный. И потом, есть бесплатный консольный RK 1.04, который почти не отличается от WinRK.

Цитата:

Так ведь обратное преобразование у них существует и притом единственное...

А никогда не пробовал запаковать и тут же (для проверки) распаковать?
У меня бывали случаи типа "ошибка в архиве...".
Хотя реально я пользуюсь только RARом, иногда ACE или 7z, ну и ZIPом для распаковки. Все остальные лежат на всякий случай, вдруг попадется такой архив...

dragonD
05:33 18-01-2005
Цитата:

Модемы тоже жмут при передаче, правда - слабо, но все-таки жмут...

Попробуйте как-нибудь скачать образ СD сжатый RAR'ом и не сжатый вовсе. И засеките время... Денек сэкономите.
arsvrn
09:15 18-01-2005
Цитата:

У меня бывали случаи типа "ошибка в архиве...".

С RK? Печально. Но, сейчас я не думаю, чтобы он мог себе такое позволить... Хотя, ты прав, с этими "новшествами" (несмотря на то, что RK уже сто лет существует) надо быть настороже.

Цитата:

RK 1.04

Кажется даже 1.04a не открывает архивы WinRK 2.

В тему CAB-а: если сжимаемый файл не один, то моя фишка TAR+CAB окажется ещё эффективнее, поскольку CAB не поддерживает непрерывность, а предварительно загнав всё в TAR, мы как бы создаем "непрерывный" CAB-архив. При сжатии TAR используется алгоритм LZX-21 - пожалуй, лучший алгоритм CAB. Игорь Павлов строил свой сверхмощный LZMA, насколько мне известно, на LZ-77, а я, если бы был программистом, наверное ,сделал бы на основе LZX (CAB)

Цитата:

А вот насчет CAB я не согласен. Иногда (в основном на файлах типа EXE, DLL) он даже лучше RARа.

Может быть. Попробую аккуратно потестировать на этих типах файлов, когда будет время, OK? Кстати, такой тест будет уникальным, поскольку CAB, RAR и TAR+CAB вместе ещё никто не тестировал! Кстати, LZMA+BCJ2 (умолчальный алгоритм 7-ZIP для сжатия EXE, DLL и т.д.) тоже жмёт сильнее RAR, и интересно сравнивать ещё и с ним.
Lomster
Разве там тестируют, например, LZMA и PPMD в сравнении? Или разницу при сжатии малого количества больших файлов и большого количества маленьких (а иногда это решающий вопрос, когла WinACE опережает и RAR и даже 7z при сверхбысторм сжатии!)

Добавлено:
И еще. Народ, никто из вас не слышал об этом ?
А то они хвастают сильным сверхбыстрым сжатием...

Viewgg
21:00 18-01-2005
Цитата:

И еще. Народ, никто из вас не слышал об этом ?

Да, это LZ-архиватор Роберта Яня, основная особенность от остальных LZ-чиков (ARJ, ACE, CAB, RAR, ZIP) --- препроцессинг.

Кстати, возможность сжатия в JAR есть в WinACE (как и CAB, за что я его , в свое время, появления WinRAR 2.9 и выше с 4 меговым словарем, очень любил --- использовал WinACE для сжатия в CAB).

Вообще, вдруг не знаете, все архиваторы есть на ftp.elf.stuba.sk/pub/pc/pack
Цитата:

Разве там тестируют, например, LZMA и PPMD в сравнении? Или разницу при сжатии малого количества больших файлов и большого количества маленьких

А разве нет? Разве при сравнении сжатия текстовых файлов и PE-файлов делается не это?

Цитата:

Да, это JavaARchiver

Про джаву сам придумал? Она тут ну совсем никаким боком. JAR - это просто анаграмма ARJ, а также еще переводиться как "котелок". Это внедрение новых (относительно arj) методов которые придумали авторы arj. Из-за полной несовместимости решили начать новый проект. Имеет довольно продвинутую систему chapterов (версионности файлов - можно хранить в архиве несколько файлов с одним и тем же именем). Широкого использования не получил, несмотря на полную поддержку сервиса arj и лучшее сжатие.

Sav
01:45 19-01-2005
Цитата:

Про джаву сам придумал?

Нет, не сам. Но, ты прав... Смешались в кучу кони, люди.
Действительно Янь тут ни при чем.

Цитата:

JAR
Compressed file package for classes and data. This is a special .ZIP format unrelated to the ARJ .JAR archive format. The JAR file format is based on the standard ZIP file format with an optional manifest file

В этих архивах идет сановский JVM

Тот, о котором мы говорим, то есть архиватор JAR действительно не имеет никакого отношения к Java и является продолжением ARJ Яня.

Цитата:

JAR has a similar command and option feature set to the PC archiver ARJ, but it is not archive compatible with ARJ. JAR comes in a 16 bit DOS version and a 32 bit Windows version. This format is unrelated to the Sun .JAR archive format.

Цитата:

переводиться как "котелок".

Да нет, скорее как банка. Котелок, это скорее pot.

Viewgg
Ничего особенного в этом JAR нет. Сжимает получше ARJ, но до современных архиваторов ему очень далеко. И по скорости тоже.
TCPIP

Цитата:

Кажется даже 1.04a не открывает архивы WinRK 2

Точно, не открывает. Но, по моему, WinRK жмет практически так же, как и RK (проверял не очень внимательно), а пользоваться им неудобно. У меня RK и остальные прикручены к FARу и TotalCommander.

Viewgg

Цитата:

моя фишка TAR+CAB

Ты всерьез полагаешь, что это твоя фишка? Как же тогда вообще появилось непрерывное сжатие? Скажем, у того же RAR?

Цитата:

поскольку CAB не поддерживает непрерывность

Странно. Я отчего-то всегда был уверен, что CAB ничего кроме непрерывного сжатия вообще не умеет.

DimmY
Оставь, пожалуйста! Эту фишку я как раз сделал, зная о непрерывном сжатии того же RAR.
А вот насчёт CAB ты меня удивил. Скажу честно, не знал.

Я так и думал, что этот JAR ерунда.

Viewgg
Не понял тебя... Что значит "оставь"? Просто идея непрерывного сжатия в RAR появилось (насколько я знаю) именно таким путем, какой описал ты. Только несколько раньше.

DimmY
А я её опять использовал, только позже

Цитата:

Оставь, пожалуйста!

Это я насчёт

Цитата:

Ты всерьез полагаешь, что это твоя фишка?

arsvrn

Цитата:

Ничего особенного в этом JAR нет. Сжимает получше ARJ, но до современных архиваторов ему очень далеко.

Ну как сказать...

На момент появления финального релиза JAR v1.02 (в сентябре 1997) это был один из самых крутых архиваторов. Вышедший одновременно с ним WinRAR v2.02 значительно проигрывал и по сжатию, и по скорости. Жаль только, что с тех пор ни одной версии JAR так больше и не вышло.

Benchmark
Насчет скорости - согласен, насчет сжатия - нет. Специально сейчас проверил. Папку Office10 из OfficeXP (там и .exe и .dll и .hlp и т.д.) архивировал JAR, WinRAR 2.03 и консольным RAR 2.03 (2.03 по алгоритму сжатия не отличается от 2.02) с опциями максимального сжатия. Исходный объем папки 136 МБ, RAR - 56.3 МБ, JAR - 60.8 МБ.
По времени действительно JAR раз в 5 быстрее.

arsvrn
Я тут по твоему совету тестирую UHARC 1.15e (построен на ядре 0.4, но является GUI-архиватором). Так вот, жмёт он чуть лучше, чем 7z, но ненамного. Но дело не в этом. Самый сильный алгоритм там - PPM. Имеет ли он какое-нибудь отношение к алгоритму PPMD 7-ZIPа или PPMII WinRARа? А то обычно эти алгоритмы используются для текстов... Может, вопрос немного не в тему, но все остальные темы совсем глухие... Подскажите, пожалуйста, кто знает! А то вдруг надо вместо LZMA жать PPMD (хотя на практике он кроме текстов всё жмёт хуже).

Добавлено:
Да, народ, насчёт CAB. Где вы откопали такой дистрибутив, чтобы RAR жал его хуже, чем CAB? Непрерывное сжатие, максимальная компрессия, словарь 4096, автовыбор алгоритма сжатия исполняемых файлов позволяют на EXE, DLL WINRARу обогнать CAB и отстать от 7z , причём отрывы довольно весомые.

arsvrn

Цитата:

Насчет скорости - согласен, насчет сжатия - нет. Специально сейчас проверил. Папку Office10 из OfficeXP (там и .exe и .dll и .hlp и т.д.) архивировал JAR, WinRAR 2.03 и консольным RAR 2.03 (2.03 по алгоритму сжатия не отличается от 2.02) с опциями максимального сжатия. Исходный объем папки 136 МБ, RAR - 56.3 МБ, JAR - 60.8 МБ.
По времени действительно JAR раз в 5 быстрее.

Возможно, это ведь еще и от сжимаемых данных зависит. Я вот точно помню, что архив, который JAR делал за 3-4 минуты, WinRAR создавал минут 15 при примерно одинаковом уровне сжатия. Единственное, чего мне не хватало в JAR - это sfx архивов.

В общем, жаль, что автор его забросил.

Ну, ничего, есть и другие. Кстати, на разных сайтах совершенно противоречивые данные о том, кто всех круче жмёт. А JAR забросили, наверное, потому, что неперспективный, да и ARJ Software загнила.

Viewgg

Цитата:

А JAR забросили, наверное, потому, что неперспективный, да и ARJ Software загнила.

JAR автор забросил в связи с низким уровнем продаж, хотя по некоторым данным работал над бета-версией JAR 2.0. Но мне кажется, что тут все наоборот - низкий уровень продаж стал следствием того, что проект никак не развивался.

Ну а сам ARJ был окончательно "добит" проектом open-source ARJ.

Viewgg

Цитата:

Да, народ, насчёт CAB. Где вы откопали такой дистрибутив, чтобы RAR жал его хуже, чем CAB? Непрерывное сжатие, максимальная компрессия, словарь 4096, автовыбор алгоритма сжатия исполняемых файлов позволяют на EXE, DLL WINRARу обогнать CAB и отстать от 7z , причём отрывы довольно весомые.

Так уж случилось, что тот дистрибутив, обнаруживший поразительные при сжатии результаты, не для публичного обозрения ;(. И если очень надо удостовериться, что так оно и было, как сообшалось в посте, то милости просим договариваться через ПМ.

Хотя полагаю, что случай тот совсем не единичный.

Viewgg
15:20 26-01-2005
Цитата:

Да, народ, насчёт CAB. Где вы откопали такой дистрибутив, чтобы RAR жал его хуже, чем CAB?

Ну, за примерами далеко ходить-то и не надо:
KpT_RegetDxMix208

А почему многие крутые архиваторы (PAQ, UHARC, кажется, WinRK, Durilca) используют PPM как основной алгоритм, тогда как WinRAR использует PPMII только для текстов, да и справке к 7-zip про метод PPMD говорится, что он хорош для текстов, а главный алгоритм - LZMA? При этом 7z чуть-чуть отстаёт от того же UHARC и других "монстров"? Кстати, видел любопытную вещь: на каком то сайте в тесте GIMP в 7z PPMD чуть-чуть обогнал LZMA. В жизни вот ситуация обратная...
Цитата:

Если избыток данных небольшой, скорость сжатия ниже, чем у LZ.

Ну, эти монстры долго и думают...
И ещё вопрс: почему полно архиваторов (те, что я называл выше + PPMonstr Шкарина) используют один и тот же PPMD, а результаты сжатия у всех разные?
За чем всё-таки будущее: LZ или PPM? Недостатком PPM является низкая скорость как прямого, так и обратного преобразований. LZ-алгоритмы обычно обладают очень быстрой распаковкой и вообще более высокой скоростью, но LZMA (наверное, лучший из этих алгоритмов) пока от "PPM-монстров" немного отстаёт.
TCPIP
Ох, какое ты наукообразие развёл! Попроще объяснить нельзя? Это на compression.ru такие статьи пишут...

Viewgg
19:06 27-01-2005
Цитата:

тогда как WinRAR использует PPMII только для текстов

Потому что PPM-методы очень эффективны именно для текстов. Однако всегда можно подобрать такую модель, что она будет давать лучшие результаты, в плане сжатия, чем LZ или BWT.

Цитата:

За чем всё-таки будущее: LZ или PPM?

Здесь мне тяжело сказать, я не специалист... Однако, насколько я понимаю, у PPM --- очень широкое поле применения в плане работы с символами: шифрование, распознавание образов и речи, матлингвистика.


Цитата:

PPMonstr Шкарина) используют один и тот же PPMD

В PPMonstr используется cPPM II --- complicated PPM II.
Цитата:

Ох, какое ты наукообразие развёл

Это не я, это Ратушняк сотоварищи. А я лишь выдернул краткое изложение...

Очень рекомендую: Д. Ватолин, А. Ратушняк, М. Смирнов, В. Юкин Методы сжатия данных --- М.: Диалог-МИФИ, 2003

TCPIP
На Compression.ru статьи и выбранные места книги тех же авторов, а также Шкарина.

Я тут давно собирался выложить результаты тестирования архиваторов. Никак не доведу до конца, так как времени нет. Пока выкладываю всё, что сделал. Тесты расположены в хронологическом порядке (по мере того, как проводил)

---

Первый тест - популярные архиваторы. Аутсайдеры типа ZIP в тест не вошли. Ниже представлены результаты.

---

Тестирование архиваторов:
WinRAR 3.40
WinACE 2.11
7-zip 4.13beta

Настройки сжатия - умолчально-максимальные. Все архивы непрерывные.
Размер для удобства в Мб, в TXT и HTM размер архивов в Кб
В дистрибутивах взято по большому кол-ву файлов для использования непрерывности.
* Здесь использовались 2 алгоритма сжатия, т.к. ppmd - алгоритм специфический.
** На ультре сжатие затянулоь очень надолго, так что конца я не дождался. Уровень сжатия - макимальный.






Distrib RAR ACE 7z

DOC 6.41 2.62 2.65 lzma-2.60 *
ppmd-2.78

EXE 9,54 2,82 2,84 2,43

JPG 6.00 5.92 5.94 5.91

GIF 6.93 6.39 6.40 6.41

BMP 33.8 12.5 11.5 16.7 **

MP3 24,6 23,9 23,9 23,9 **

TXT 3.84 646 730 lzma-644*
ppmd-582

DLL 10,1 2,90 2,92 2,56

HLP 11,9 6,10 6.05 lzma-5,63 *
ppmd-6.06

HTM 6.31 680 813 lzma-645
ppmd-526


Web 8.62 3.10 3.14 lzma-2,88
ppmd-2,88



Batva 42.4 10.4 9.58 7,26



Комментарии и некоторые частные выводы.
EXE - файлы брались из папки WINDOWS (все, что были найдены).
Batva - папка установленного пакета драйверов NVidea. Там в оновном HLP и DLL, немного EXE и прочей чуши.
Выбор большого размера дистрибутива для BMP- возможная ошибка. Сказалась тормознутость 7-zip. Все файлы 1-2 Мб.
Размер MP3 был сознательно взят меньше. Тем не менее, обычная ультра начала затягиваться и была прервана.
Тем не менее, на BMP сверхбыстрое сжатие ACE оказалось наиболее эффективным, что возможно и в жизни.
Жать MP3, как и JPEG, смысла не имеет, что понятно.
Удивительно, что алгоритм PPMD проиграл LZMA на DOC. В жизни на маленьких файлах или наборах, а не на больших объёмах,
как в тесте, обычно ситуация иная. На TXT всё "как надо".
В целях экономии времени всякие PDF не брались, т.к. они, как и MP3 с JPEG, уже сжатые. Очевидно ненужная или несжимаемая батва
не бралась по тем же причинам.
Для тестов HTM брались чистые HTM - файлы. Поскольку реальные Web-страницы состоят не только из HTML, взяты страницы вместе с *.files
Удивительно, но "текстовый" алгоритм PPMD не уступил мощному LZMA, хотя картинок очень много.
На GIF 7-zip немного проиграл. Бывает.

Подведём итоги.
7-zip - лучший. Этого и следовало ожидать. Единственное, его тормознутость мешает ему жать иногда на ультре при больших объёмах. Кроме того, он плохо
жмёт BMP, GIF и крайне медленно жмёт всякие MP3 и большие количества JPEG. Малоэффективно его сжатие для уже сжатых файлов (что, в общем, понятно)
Часто помогает WinACE, дающий всегда сверхбыстрое сжатие с высокой эффективностью для BMP и больших файлов.
А WinRAR можно послать в пппопппу! Впрочем, создатели WinACE, заявляющие, что их сжатие самое крутое, неправы.
Я уже отмечал, когда хорош этот экзотический архиватор. Проверено практикой: большая BMP или WAV - бери WinACE, он вынесте другие архиваторы на один-несколько мегабайт.

---

Второй тест - сравнение UHARC с лидерами предыдущего теста. Этот тест проведён в две стадии - тестирование версий 0,4 и 0,6 (по мере того, как эти версии у меня появились ). Автор тестов благодарен arsvrn за идею использовать UHARC в тестах, а также за некоторую техническую помощь в настройке вспомогательных программ. Этот тест не доведён до конца, однако результат предсказуем: UHARC лидер при сжатии текстовых (TXT -> HTM) и мультимедийных данных. Будет время и желание, доведу до конца.

---

UHARC 1.15e (0.4)
7-zip 4.13beta

Размер в Мб, кое-где в Кб. Алгоритм LZP по предварительныым оценкам и по названию Preset слабоват,
так что я его не тестировал.

Distrib LZMA PPMD ALZ PPM

EXE 27.8 7.00 7.86 7.80 7.50
DLL 9.96 2.58 - 2.78 2.78
DOC 6.61 2.63 2.81 2.58 2.56
TXT 3.23 579 518 607 535
JPEG 3.61 3.48 - 3.46 3.46
MP3 11.8 11.6 - 11.6 11.6
HTM 1.84 299 223 307 274
(без графики)
WEB 8.62 2.88 2.88 2.88 2.86
(полные Web-страницы)
*ASPI 331 129 - 127 126
(дистрибутив, Кб)

Выводы.
В общем, иногда UHARC жмёт лучше, чем 7z, а иногда нет. В целом как архиватор 7-zip посимпатичней, поудобней и
пофункциональней, ну а сжатие в общем похожее.
About UHARC presets.
(установлено экспериментально по размеру архива)
В Sehr hoch используется PPM, в Hoch, Normal и Schnell - Alz (Best, Normal и Fast, соответственно). Ну а Schwach
(слабый) - это LZP. Он действительно самый слабый по предварительной оценке.

Сжатие BMP в сравнении не только с 7-zip, но и с WinACE - лидером в этой области.

Distrib Alz PPM ACE LZMA
8.23 2.65 2.68 2.77 3.81

Вот WinACE больше и не лидер!

Глобальный вывод.
Да, UHARC действительно хорошо жмёт. Правда, иногда преимущество минимально, так что использовать его нерационально.
Но по сжатию часто это лидер. Однако, он уступает 7z на EXE и DLL, TXT и HTM.
__________________________________________________________________________________________________________________________

Часть 2. UHARC 0.6
UHARC 1.15e (0.4)
7-zip 4.15beta

Как наиболее сильный алгоритм сжатия, в UHARC 0.4 использовался PPM.
7-zip участвует в тестах только там, где он обогнал UHARC 0.4. На этот раз те типы данных, которые жать
практически бессмысленно (MP3, JPEG), в тесте не участвовали в целях экономии времени.

Distrib 04 06PPM 06ALZ 7z

EXE 4.00 1.13 1.08 1.12 1.11 (lzma)
DLL 9.96 2.78 2.61 2.70 2.58 (lzma)
DOC 5.05 2.39 2.39 2.39 -
TXT 2.41 416 395 459 397 (ppmd)
HTM
WEB

Сжатие BMP




Выводы.
UHARC 0.6 довели до кондиции, так что он практически всегда жмёт лучше, чем 7-zip, а в предыдущей версии
преимущество было сомнительным, и часто 7-zip выигрывал на важных типах данных.
Разница по сравнению с предыдущей версией существенная, алгоритм PPM в UHARC на сжатии текстов довели до уровня сжатия PPMD
7-zip и даже обогнали, а в предыдущей версии 7-zip оказывался лидером в этой области.
Сжатие DOC в новой версии практически не улучшилось; впрочем, в предыдущей версии оно и так было хорошим,
лучше, чем мог предоставить 7-zip. Интересно, что разницы между ALZ и PPM (который обычно даёт лучшее сжатие) здесь практически не наблюдается.
Сжатие EXE в новой версии UHARC оптимизировано хорошо; правда, на DLL 7-zip продемонстрировал минимальное преимущество.
__________________________________________________________________________________________________________________________

Планы: отдельно тестировать мультимедийное сжатие.
В предыдущих тестах рассматривалось сжатие наиболее часто встречающися типов данных. Но UHARC позиционируется также как мультимедийный архиватор,
и на сжатии BMP преимущество было продемонстрировано. Интересно провести тесты для других типов данных, возможно, сравнение сжатия со
включенным и выключенным Multimedia Detection.
Также интересно сопоставить UHARC с такими монстрами, как WinRK и PAQ6 (при возможности). Особенно важно такое сравнение для мультимедийны данных.

---

Добавлю, что по предварительным оценкам WinRK жмёт практически не лучше, чем UHARC 0.6, но затраты времени при упаковке и распаковке на порядок больше, поэтому использовать его нерационально.
Также отмечу, что 7-zip - плохой мультимедийный архиватор, но удобен для сжатия иных типов данных.
Выбор автора:
UHARC 0.6
7-ZIP 4.15

---

Замечания и пожелания можно выражать прямо здесь.

Viewgg
Странно , не заметил я чтобы 7-зип на ультре долго работал , жал им
базу данных прописки и телефона - первая 300 метров , вторая 900 ,
по времени оказалось чуть медленнее рара , обьём словаря в 7-зипе был
выставлен в 64мб , также вопрос почему не игрался с настройкой винрара ?
у него помимо настройки словаря и солид , ещё есть и на этих базах они дают неплохую разницу.
Также неплохо было ещё попробовать WinRk , по тестам с какого то сайта он лидирует
и к тому же гуёвый.

п.с. сам пользую 7-зип ТС плагин для большего сжатия , винрар - для просто сжатия.

prostouser

Цитата:

Также неплохо было ещё попробовать WinRk

Оценочно пробовал. Жмёт долго, а преимущества практически нет. Сайт:
http://www.maximumcompression.com
Только я сильно сомневаюсь...