Сжатие и упаковка. hrum3.5, hrust1, hrust2, laser compact x.x.

[Hrumer]

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

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

[introspec]

Приведу пример чтобы не быть голословным. При сжатии графики для недавней 1к интры мне нужно было упаковать файл в 3072 байта. Размер кода по сравнению с размером графики был вторичен. Самое лучшее сжатие было достигнуто Exomizer (638 байт). Остальные упаковщики сгруппировались где-то в районе 670-690 байт. Но самый компактный распаковщик для Exomizer требует 169 байт, в то время как распаковщик для самого примитивного компрессора в моих тестах (zx7) требовал всего 69 байт. Т.е. увеличение размера распаковщика может запросто нивелировать выигрыш от повышенного коэффициента сжатия, раз уж мы думаем о упаковщиках для сайз-кодинга.

[Shadow Maker]

Еще бы конечно хотелось, чтобы он всегда распаковывал то, что наупаковывал. Что упакованные данные не затираются распакованными. Очень помогло бы, а то упаковываешь бывало блок, и все вроде работает на первый взгляд после распаковки, но на самом деле - где-то в середине что-то наехало и не распаковало. Особо актуально для больших блоков, когда места нет.

[Hrumer]

Еще бы конечно хотелось, чтобы он всегда распаковывал то, что наупаковывал. Что упакованные данные не затираются распакованными. Очень помогло бы, а то упаковываешь бывало блок, и все вроде работает на первый взгляд после распаковки, но на самом деле - где-то в середине что-то наехало и не распаковало. Особо актуально для больших блоков, когда места нет.

Ага, в exomizer2, если не ошибаюсь, сообщается, что: "товарищ, тут накладка в 3 байта, имей в виду, я тебя предупреждал".

[alone]

Надо давать возможность при распаковке выделять память без наложения, а то сейчас даже не спрашивают.

[BlastOff]

Краткое описание алгоритма, про который рассказывал Хрумер, в приложении.

[Advertiser]

[jerri]

када ждать новую версию ?

[Hrumer]

Не скоро. Там и так много чего перепроверить надо, а еще и LVD несколько лет назад сделал mhmt с алгоритмом OLZH c с форматом хранения MegaLZ, hrum3.5 or hrust1.x format (default is MegaLZ), чем сильно поднял планку, которую тяжело перепрыгнуть. Буду пока laser compact ускорять.

[jerri]

Hrumer, а если просто перевыпустить Hrum 3.х под вин?

[Hrumer]

у hrum3 и так уже есть порт 1:1 и есть с OLZH.(не мои) А если имеешь ввиду hrust3, то вопросы то те же остаются, там надо протестить как дистанции для длины =2 кодировать (768 байт дистанции, похоже, это чересчур, правильнее 256 или 512, настраиваемо(?) с увеличением len при длине дистанций 256 или 512), убрать явную неоптимальность кодирования дистанций для len>2 (там, кажется, вообще перекрытие кодов идет для дистанций <=512), и там еще куча всего...