Сжатие и упаковка - обсуждение и сравнения

[introspec]

пока

[Advertiser]

[Vitamin]

ZX7: 30,158 bytes

ApPack: 29,013 bytes

А что это за пакеры? Насколько широко распространены?

Exomizer: 28,372 bytes

Этого кадра знаю. Распространен чуть меньше чем никак.

[introspec]

ZX7 - это самый "модный" пакер на WoS. По сути, это переписанный Bitbuster, но с более качественным упаковщиком чем было в оригинале. Основные достоинства - скорость (думаю, это самый быстрый распаковщик в этих тестах) и наличие нескольких распаковщиков, самый компактный (и, понятно, самый медленный) из которых требует всего 69 байт.

ApPack - это декомпрессор на основе старого досовского компрессора aPACK. Некто Maxim переписал исходный код распаковщика для z80 на Сеге, а затем Metalbrain сотоварищи написали серию распаковщиков оптимизированных по скорости распаковки и размеру распаковщика. Я думаю, что по скорости распаковки ApPack уступит только Bitbuster/ZX7. Поскольку это основной упаковщик в составе La Churrera, я подозреваю, что он гораздо шире используется, чем можно подумать на первый взгляд.

Малая распространённость Exomizer - это довольно странная ситуация, т.к. это самый эффективный компрессор в практически всех моих тестах, с довольно компактным распаковщиком (хотя ему и нужен буфер при распаковке). Распаковщик немного неторопливый, но там можно добавить где-то байт 5 для ускорения на 14% (см. комментарии Metalbrain в распаковщике).

[Vitamin]

затем Metalbrain сотоварищи написали серию распаковщиков

Судя по всему, все эти пакеры (начиная с MegaLZ) в погоне за качеством сжатия и последующей экономией на спичках напрочь потеряли какие-либо сигнатуры сжатых блоков. Значит детектить их можно исключительно по ограниченной разновидности пришпиленного распаковщика.
Для сравнения- все предыдущие компрессоры эту сигнатуру имели (семейство Hrust, MsPack) либо депакер был частью упакованного блока и сам являлся сигнатурой.

[introspec]

Судя по всему, все эти пакеры (начиная с MegaLZ) в погоне за качеством сжатия и последующей экономией на спичках напрочь потеряли какие-либо сигнатуры сжатых блоков. [...] Для сравнения- все предыдущие компрессоры эту сигнатуру имели

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

[Vitamin]

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

Как говорится, "что один человек сделал, другой завсегда сломать может". В силу некоммерческости игр/демок и наличия богатого инструментария для раздербанивания (в отличие от старых времен), защита- пустая трата времени. А вот потерять что-то в таких условиях- очень легко. Имхо.

[introspec]

Как говорится, "что один человек сделал, другой завсегда сломать может". В силу некоммерческости игр/демок и наличия богатого инструментария для раздербанивания (в отличие от старых времен), защита- пустая трата времени. А вот потерять что-то в таких условиях- очень легко. Имхо.

Vitamin, этот спор тут немного неуместен (удали мой ответ если что). Но я не считаю компрессию защитой. Компрессия - это просто компрессия. Если программа распаковывает свои модули на лету - это не защита, а просто борьба с ограничениями памяти. Ни о какой потере информации речи быть не может, так как библиотеки для распаковки лежат тут же, рядом. Ну и вопрос: зачем мне тратить байты (которых и так явно мало) на идентификаторы сжатых блоков, если мне и так всё понятно и никаких возможностей для ошибки просто не существует?

Ну ок, я знаю твою настоящую мотивацию - выдрать муз. трек из демки или игры. Но ситуация тут непростая. Если музыкант не давал разрешения на отдельный релиз его трека - захочу ли я помочь хакеру дополнительной разметкой где и как я упаковал музыку? едва ли. А если музыкант не против релиза - не проще ли (и не лучше ли) спросить оригинальный трек у музыканта?

[alone]

Всего в наборе 26 файлов объёмом 50344 байта. Вот результаты сжатия несколькими современными компрессорами:

Где можно взять эти файлы? Хотя бы интересует результат сжатия mRIP.

[Vitamin]

Ну ок, я знаю твою настоящую мотивацию - выдрать муз. трек из демки или игры.

Это частная мотивация. Настоящая- выдрать вообще все что можно

Если музыкант не давал разрешения на отдельный релиз его трека - захочу ли я помочь хакеру дополнительной разметкой где и как я упаковал музыку? едва ли. А если музыкант не против релиза - не проще ли (и не лучше ли) спросить оригинальный трек у музыканта?

Есть куча софта, оригинальные данные которых утеряны. А восстановление затруднено из-за озвученных тобой соображений.

Ну и вопрос: зачем мне тратить байты (которых и так явно мало) на идентификаторы сжатых блоков, если мне и так всё понятно и никаких возможностей для ошибки просто не существует?

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

[introspec]

Где можно взять эти файлы? Хотя бы интересует результат сжатия mRIP.

Прикладываю свой комплект файлов. Для справки, RAR 5.01 упаковал их до 29244 байт (-m5) или, если паковать в режиме solid архива, до 25056 (-s -m5).