[M.A.D.M.A.N.]

Всем привет, многим известен алгоритм сжатия LZMA, он считается довольно мощным. Но имеет недостатки. Рассматривая и тестируя исходник на Delphi, стокнулся с интерестным парадоксом, чем меньше размер словаря тем компактнее он жмет некоторые типы данных (графика к примеру), но опять сжимая бинарники с малым словарем сжатие проигрывает и так далее не говоря уж о контекстных битах и всего прочего, что является дополнительными настройками сжималки.

Вопрос состоит в следующем, вообще возможно ли найти золотую середину чтобы нормально (достаточно нормально) сжимала разные типы файлов (графика, текст, приложение и т.д ), а то чудь-чуть не могу WinRAR переплюнуть

[Thrasher]

Тут есть один нюанс - WinRar использует кучу настроек, например там можно галочку поставить "Использовать мультимедиа сжатие". Т.е. пользователь сам выставляет настройки. Так нужно делать и у тебя. Если захочет пользователь сжимать графику, то пусть размер словаря уменьшается. Кстати в WinRar есть выпадающий список с размерами словаря.
А как найти золотую середину (т.е. настройки по умолчанию). Берешь много разных файлов и сжимаешь с разными параметрами. А потом путем анализа вычисляешь оптимальные для всех типов файлов настройки.

[M.A.D.M.A.N.]

Тогда еще один вопрос.
Допустим программа определила, что будут сжиматься текстовики, а на самом деле это графика с другим расширением, тогда по видимому необходимо определять файл по сигнатуре?
--------------------
А насчет идеи с комком разных файлов и аго анализа, большое спасибо, изначально я делал просто, сжимал разные файлы по отдельности и потом никак не мог замешать результаты между собой

[M.A.D.M.A.N.]

Как это понять, чем меньше словарь, тем лучше сжатие?

[Thrasher]

Я наверное неправильно выразился.
Суть любого метода сжатия заключается в построении бинарного дерева и составления уже на его основе словаря. Так вот, в любом случае размер сжатого файла включает в себя размер заголовка + размер словаря + размер сжатых данных. Поскольку графические данные сравнительно плохо сжимаются стандартными методами (для них есть специальные алгоритмы, например тот же JPG), то из-за увеличения словаря происходит увеличение архивного файла. В других случаях, когда сжимаются данные других типов, при увеличении размера словаря, уменьшается размер сжатых данных. Однако может быть такое, что в случае максимального сжатия размер архивного файла может быть больше чем размер этого же архивного файла, но с меньшей степенью сжатия. Поэтому во многих архиваторах, при создании нового архива, указывается будет ли применяться сжатие мультимедиа-данных. В таком случае размер архива будет минимальным, поскольку такая составляющая как словарь, будет иметь минимальный размер.

[M.A.D.M.A.N.]

Ну в общем у меня программа файлы по отделности жмет сильнее WinRAR'a а группу RAR жмет на сто байт сильнее чем моя программа. У него другая структура файла?
у меня шапочка файла в таком роде

Код:

Type TFileHead=Packed Record
    Attr:Word;
    CRC:LongWord;
    Size:LongWord;
    PackedSize:LongWord;
    FileCreateDate:TDateTime;
    FileModifyDate:TDateTime;
    FileOpenDate:TDateTime;
    LongFileName:WideString;
  End;

и потом запись в файл идет друг за другом.
Такой заголовок большой наверное? но он у меня сжиматеся.
Как интерестно в RAR'e сделано, наверняка идет запись шапки, потом запись файла ?

[Thrasher]

Заголовок здесь не причем. Просто у winrar алго сжатия лучше. Он даже не жмет заголовки. Весьма возможно, что он делает непрерывный архив - т.е. все файлы представляются одним потоком и жмутся в таком виде. Тогда словарь получается 1 на всех.

[M.A.D.M.A.N.]

Но опять если непрерывный архив с общим словарем, в таком случае не факт, что он сильно сожмет.

[M.A.D.M.A.N.]

В 7зип спользуется еще размер блока и размер слова, что они дают?
Ну с блоком понятно, а размер слова?

[M.A.D.M.A.N.]

Я понял свою ошибку!!! у меня размером словаря являлся индекс по листу, я забыл сделать 1 shl Index, так что словари у меня устанавливались неверно. Сейчас у меня программа на ~118 Кб обогнала WinRAR при сжатии BMP.