пока
Вид для печати
пока
Цитата:
Сообщение от introspec
А что это за пакеры? Насколько широко распространены?Цитата:
Сообщение от introspec
Этого кадра знаю. Распространен чуть меньше чем никак.Цитата:
Сообщение от introspec
ZX7 - это самый "модный" пакер на WoS. По сути, это переписанный Bitbuster, но с более качественным упаковщиком чем было в оригинале. Основные достоинства - скорость (думаю, это самый быстрый распаковщик в этих тестах) и наличие нескольких распаковщиков, самый компактный (и, понятно, самый медленный) из которых требует всего 69 байт.
ApPack - это декомпрессор на основе старого досовского компрессора aPACK. Некто Maxim переписал исходный код распаковщика для z80 на Сеге, а затем Metalbrain сотоварищи написали серию распаковщиков оптимизированных по скорости распаковки и размеру распаковщика. Я думаю, что по скорости распаковки ApPack уступит только Bitbuster/ZX7. Поскольку это основной упаковщик в составе La Churrera, я подозреваю, что он гораздо шире используется, чем можно подумать на первый взгляд.
Малая распространённость Exomizer - это довольно странная ситуация, т.к. это самый эффективный компрессор в практически всех моих тестах, с довольно компактным распаковщиком (хотя ему и нужен буфер при распаковке). Распаковщик немного неторопливый, но там можно добавить где-то байт 5 для ускорения на 14% (см. комментарии Metalbrain в распаковщике).
Судя по всему, все эти пакеры (начиная с MegaLZ) в погоне за качеством сжатия и последующей экономией на спичках напрочь потеряли какие-либо сигнатуры сжатых блоков. Значит детектить их можно исключительно по ограниченной разновидности пришпиленного распаковщика.Цитата:
Сообщение от introspec
Для сравнения- все предыдущие компрессоры эту сигнатуру имели (семейство Hrust, MsPack) либо депакер был частью упакованного блока и сам являлся сигнатурой.
А, ок, теперь я понял вопрос. Ну, не знаю. С моей т.зр. нужно отличать архиваторы файлов от упаковщиков внутренних данных. Ни одна из перечисленных программ архиватором не являлась, насколько я знаю. Я не вижу смысла специально облегчать жизнь людям решившим раздербанить мою игру или мою демку.Цитата:
Сообщение от Vitamin
Как говорится, "что один человек сделал, другой завсегда сломать может". В силу некоммерческости игр/демок и наличия богатого инструментария для раздербанивания (в отличие от старых времен), защита- пустая трата времени. А вот потерять что-то в таких условиях- очень легко. Имхо.Цитата:
Сообщение от introspec
Vitamin, этот спор тут немного неуместен (удали мой ответ если что). Но я не считаю компрессию защитой. Компрессия - это просто компрессия. Если программа распаковывает свои модули на лету - это не защита, а просто борьба с ограничениями памяти. Ни о какой потере информации речи быть не может, так как библиотеки для распаковки лежат тут же, рядом. Ну и вопрос: зачем мне тратить байты (которых и так явно мало) на идентификаторы сжатых блоков, если мне и так всё понятно и никаких возможностей для ошибки просто не существует?Цитата:
Сообщение от Vitamin
Ну ок, я знаю твою настоящую мотивацию - выдрать муз. трек из демки или игры. Но ситуация тут непростая. Если музыкант не давал разрешения на отдельный релиз его трека - захочу ли я помочь хакеру дополнительной разметкой где и как я упаковал музыку? едва ли. А если музыкант не против релиза - не проще ли (и не лучше ли) спросить оригинальный трек у музыканта?
Где можно взять эти файлы? Хотя бы интересует результат сжатия mRIP.Цитата:
Сообщение от introspec
Это частная мотивация. Настоящая- выдрать вообще все что можно:)Цитата:
Сообщение от introspec
Есть куча софта, оригинальные данные которых утеряны. А восстановление затруднено из-за озвученных тобой соображений.Цитата:
Сообщение от introspec
Раньше каналы связи были гораздо хуже и винты меньше, а место под идентификаторы находили. А сейчас у всех интернет-эмули-пентевы-винты, а экономят на байтах (само улучшение сжатия как явление оченно хорошо). Парадокс...Цитата:
Сообщение от introspec
Прикладываю свой комплект файлов. Для справки, RAR 5.01 упаковал их до 29244 байт (-m5) или, если паковать в режиме solid архива, до 25056 (-s -m5).Цитата:
Сообщение от alone
Тут я с Витамином согласен. В погоне за несколькими десятками или сотнями байт, появляются дикие тормоза и долгий декранчинг, который жутко иной раз раздражает.Цитата:
Сообщение от Vitamin
На мой взгляд, для игр и дем (там, где ждать пользователю точно не хочется много), депакер должен быть прежде всего мгновенным (как мой ;-)), а уж во вторую очередь должна учитываться эффективность.
Я думаю, что во всём нужна мера. Не в каждой ситуации скорость критична. Не в каждой ситуации быстрого распаковщика хватает, чтобы всё запихнуть.Цитата:
Сообщение от Titus
Практика показывает, что в большинстве случаев долгие депакинги раздражают, и вполне можно запихнуть, если даже 100-200 байт будет лишними. Для исключительных случаев (а их меньшинство) можно воспользоваться более тормозным но сильным пакером.Цитата:
Сообщение от introspec
Это надо прочувствовать то невероятное ощущение, когда начал загружать программу, и она за 2-3 секунды вся загрузилась и запустилась мгновенно.
Сравни, например, того же моего Murray Mouse и, и его же но пожатого другими пакерами или группами. Уже не говорю о монстрах типа Navy Seals.
Для игр упаковка вообще не нужна. С DivIDE неупакованная игра загрузится быстрее, чем упакованная.Цитата:
Сообщение от Titus
А вот и не факт, если депакер распаковывает быстрее, чем идет перброс данных из вашего IDE-контроллера в память.Цитата:
Сообщение от Blade
Не распакует быстрее. Чтение с IDE это INIR:INIR, или раскрытый цикл с INI.
mRIP при настройках FF FA FF FA FA FA FA FF FF - 29133 (депакер 220 байт)
ZXRar в режиме Rar, Header off и при тех же настройках - 29103 (депакер 386 байт)
Похоже, они не годятся для таких маленьких файлов из-за того, что надо хранить деревья для каждого файла.
Если файлы склеить в один, то ZXRar даёт 26077 при тех же настройках (для сравнения, WinRar - 24955).
Значит разница будет копеечная, ибо распаковщики есть со скоростью от LDIR до LDIR*2.Цитата:
Сообщение от Blade
Вот поэтому я и писал о пользе, по прежнему, от сравнительно простых упаковщиков. Но у меня не получается сделать 24955 в rar. ОК, мою прошлую цифру я привёл по совсем старому rar (оказалось, что у меня валялась третья версия в путях). Поставил 5.01, получилось 26195 (solid архив, т.е. то же самое склеивание). Ты без учёта заголовков как-то посчитал, да?Цитата:
Сообщение от alone
Без заголовков. Это число WinRar выводит сам в пункте "Информация". У меня v3.50.
Соображения понятные, вот только речь идет не о сотнях байт, а о килобайтах, что хорошо видно по тестам в этом треде.Цитата:
Сообщение от Titus
---------- Post added at 12:26 ---------- Previous post was at 12:18 ----------
Вообще, конечно, вспоминая долгие годы в обнимку с магнитофоном и 48к, я бы предпочёл всё же чтобы игры упаковывали. Тем более что мне всегда казалось, что DivIDE принципиально не будет поддержана ни на одном отечественном клоне.Цитата:
Сообщение от Blade
---------- Post added at 12:42 ---------- Previous post was at 12:26 ----------
У меня всего 48кб памяти на всё про всё. Склеить не получится никак :)Цитата:
Сообщение от alone
Даже если сэкономлен килобайт, в большинстве случаев это непринципиально.Цитата:
Сообщение от introspec
Мгновенная распаковка - это круто)
В New Wave 48K это имело смысл, т.к. в каждой подгрузке по два эффекта, из которых один работает, другой хранится в упакованном виде. Ни один пакер, кроме Exomizer'а, не справлялся с задачей.
Это чисто исключительные случаи, когда ну никак иначе не лезет.Цитата:
Сообщение от alone
Есть предложение, при возможности аттачить тестовыеЦитата:
Сообщение от alone
файлы. Я вот, кстати, не понял про архив rar от introspecа.
Внутри написано, что:
Solid archive testfiles.rar
Это что, при коротких файлах он принудительно солид делает?
Upd: а, всё, дошло.
Еще:
сравнение размеров и скорости распаковки
http://psndcj.blogspot.ru/2010/09/blog-post.html
В тестах psndcj, наверняка, использовался "старый" упаковщик Hrust, поэтому он и идёт ноздря-в-ноздрю с MegaLZ, даже отстаёт по коэффициенту сжатия немного. Думаю, если использовать новый упаковщик LVD (он называется mhmt), хруст должен выйти победителем теста psndcj по сжатию.Цитата:
Сообщение от GM BIT
А лвдшный упакованный блок можно распаковать старым депакером хруста?
Можно. Но, скорее всего, скорректировав заголовок. И, возможно, у LVD файл сжимается с последними 6 байтами, а у хруста1 они незапакованными хранятся. Надо у LVD спрашивать.Цитата:
Сообщение от Shadow Maker
upd: а не надо спрашивать, и так видно, что без заголовка, и файл жмется весь, до последнего байта.
Интроспек, а в архиве ваши наработки или чьи-то? Или если это ваш тестовый корпус для сравнения компрессоров, то можно узнать, с чем идет эксперимент?
Если это рипы музона и плейеров из разных игрушек, то можно проверить, что будет при сжатии в 2 или 3 архива (отдельно код, музло, графика). Есть шансы улучшить результат.
23055 солид (+537 на хедерный хлам), и на пк компрессоров получше наверное вагон и маленькая тележка -- сжал чем пользуюсь. Но в данном случае жать универсальным компрессором -- не лучший вариант. "Вполуручную" скорее всего получится сделать круче. И, возможно, намного (если хорошо знать исх. материал).Цитата:
Прикладываю свой комплект файлов. Для справки, RAR 5.01 упаковал их до 29244 байт (-m5) или, если паковать в режиме solid архива, до 25056 (-s -m5).
Так вроде нет никакой проблемы со склейкой воедино под 48к, почему не получится? Другое дело, что это необязательно лучший вариант -- сжав код и музон (и графику) по отдельности, есть вероятность выиграть в суммарном размере.Цитата:
У меня всего 48кб памяти на всё про всё. Склеить не получится никак
Это мои рипы чужой биперной музыки. Разбивание на архивы и перегруппировка не слишком актуальны, т.к. это потребует подробного анализа, на который у меня нет времени. Разумеется, компрессор общего назначения жмёт хуже чем специализированный. Но тест сжатия чем-то вроде RAR, отлаженного для широкого применения, даёт неплохое представление о неэффективности выбранного представления на спектруме.Цитата:
Сообщение от AM
Склейка же не пройдёт потому, что на 48к машине нет 50к памяти :)
AM, Во-первых, табличка наглядная.
Во-вторых, я мало себе представляю человека, который такой разносторонне одаренный, что будет специализированно для своих данных изобретать компрессор.
В-третьих, хватит уже беспредметно. Есть какой-то конкретный компрессор для спектрума, который пакует данные introspec'a лучше и распаковывает быстрее? Прекрасно, показываем, делимся. А то "у меня РАР для ПЦ зажал круче" это ни о чем.
introspec, спокойнее, дышим ровнее. Никто никому ничего не должен. Не стоит так бурно реагировать.
Я делал не раз компрессоры именно для своих данных)Цитата:
Сообщение от Shadow Maker
Быстрее всех скорее всего распаковывает любые данные мой Pro Turbo Cruncher.
Андрей, тебе это интересно было, так ведь? Именно написать упаковщик, чтобы быстро распаковывал и с хорошим сжатием. Однако таких как ты - единицы (а жаль!).
Многие хотят не заморачиваться над именно преобразованием своих данных, чтобы лучше сжало и соответствующие изменения пакера, а хотят универсальный наиболее хорошо жмущий, чтобы взял, зажал и все отлично. Многим интересен хороший компрессор, но единицы хотят его сами же и писать для каждого релиза :) (ну или они слишком тупые, типа меня, чтобы сначала прочитать кучу инфы, осознать, потом написать и в итоге это займет времени больше, чем сам релиз раза в три).
Такие дела :)
Ну а если главное чтобы табличка была наглядная, то ее можно например раскрасить покрасивее.
---------- Post added at 21:58 ---------- Previous post was at 21:53 ----------
В итоге это к теме "шашечки или ехать". Если надо ехать -- давайте конкретные данные, посмотрим что можно с ними сделать. Если шашечки (у кого длиннее компрессор) или флейм -- извините.Цитата:
Сообщение от Shadow Maker
Это общая тема об обсуждении существующих пакеров и готовых универсальных решений. Так что ехать никуда не надо, просто обсуждаем кого лучше где. Обсуждаем по-доброму.
Речь просто о постановке задач и наличии свободного времени. В 1990е я тоже написал несколько простых компрессоров (уверен, все они были существенно хуже перечисленных в этой теме). Сейчас написание хорошего компрессора может запросто занять месяц или больше работы, на исследование наборов данных, на сбор статистики, на эксперименты со схемой упаковки и т.п.Цитата:
Сообщение от Shadow Maker
Как может помочь таблица вроде той, что я тут привёл?
Пример 1: месяц назад я писал 1к интру, для которой мне нужно было сжать 3к графики. Выигрыш в несколько процентов может быть важным на больших наборах данных, но, в данном случае, разница между лучшим и худшим компрессором не превышала 50 байт (от 538 до 587 байт). Поэтому оказалось, что для решения данной задачи, компрессор zx7 оказался оптимальным инструментом, благодаря намного более компактному распаковщику.
Пример 2: данные, которые я выложил в этом треде - это треки для моей слегка протухшей биперной демы. Когда я выбирал оптимальный компрессор для этой демы в прошлом году, mhmt ещё не существовал, и мои знания о современных компрессорах были ограничены. В моих прошлогодних тестах выиграл MegaLZ. Дема протухла из-за недостатка времени и очень жёстких проблем с памятью. В этом году я повторил свои тесты с более широким наборов компрессоров и вижу, что заменив MegaLZ на Hrust, и используя mhmt, я получаю около килобайта дополнительной памяти. Что интересно, использование Exomizer в этом случае оказывается неоправданным, т.к. выигрыш в объёме сжатых данных оказывается нивелирован требованием дополнительной памяти для буфера распаковки.
Вы почему-то упорно пытаетесь ловить десятки байтов подбором компрессора, в то время как нередко можно получить намного больший выигрыш -- без сжатия и без месяца на сбор соотв. статистики и эксперименты.
"Есть какой-то конкретный компрессор для спектрума, который пакует данные introspec'a лучше и распаковывает быстрее? Прекрасно, показываем, делимся."Цитата:
Сообщение от AM
В академических целях написан оптимальный компрессор для формата aPack/aPLib. Оставлю здесь, вдруг кому пригодится :)
https://gitlab.com/eugene77/oapack
UPD 2025: добавлен "ускоренный" режим (с минимальным ущербом для сжатия).