| Предыдущий блок | Следующий блок | Вернуться в индекс |
— RU.COMPRESS From : Dmitry Shkarin 2:5020/400 15 May 99 00:43:45 To : All Subj : Re: Как насчет такой модели для выхода BWT? From: "Dmitry Shkarin" <shkarin@arstel.ru> Hi, All! > А он работает в тормозном режиме? Или это мне такой попался, дальше -mt3 >не идет. Фу, -mt1 конечно. --- ifmail v.2.14dev3 * Origin: COMSTAR Telecommunications (2:5020/400) — RU.COMPRESS From : Vadim Yoockin 2:5020/1042.50 15 May 99 10:12:04 To : Dmitry Shkarin Subj : Re: Как насчет такой модели для выхода BWT? Пpиветствую, Dmitry! 15 May 99, Dmitry Shkarin писал к All: >> Мне казалось, что в самом тормозном режиме rkive дожимает сильнее boa >> (ну очень тормозном режиме :). DS> А он работает в тормозном режиме? Или это мне такой попался, дальше DS> -mt1 не идет. Иногда, действительно, не идет. Hо чаще всего просто задумывается... ;) Всего доброго. Vadim Yoockin ... A Smith and Wesson beats four aces. --- Стаpый Дед стоимостью 3.00.Alpha4 доплата в СКВ UNREG * Origin: yoockinv@mtu-net.ru (2:5020/1042.50) — RU.COMPRESS From : Leonid Broukhis 2:5020/400 15 May 99 10:24:12 To : Vadim Yoockin Subj : Re: Как насчет такой модели для выхода BWT? From: leob@asylum.mailcom.com (Leonid Broukhis) Vadim Yoockin wrote: >Тогда вкратце расскажу здесь, а желающим разместить у себя >могу намылить по e-mail'у всю статью. >Итак, идея проста - делим mtf-коды на кусочки (рассказываю про >вариант Фенвика): > >0 >1 >2-3 >4-7 >8-15 >16-31 >32-63 >64-127 >128-255 > >Такое деление предполагает распределение кодов по з-ну Zipf'a, >поэтому здесь можно экспериментировать (по мнению Фенвика это >дает не более 0.1%). > >Т.о. имеем модель 8 диапазонов. При кодировании очередного кода 9. >сначала пропускаем номер диапазона, а затем, если надо, номер >кода внутри диапазона. Оба эти действия можно выполнять через >Хаффмана или арифметический кодер. Понятно. Интересно попробовать заменить последние 1-2-3 диапазона на эскейп. Интуитивно понятно, что ближе к хвосту диапазона кодов (0-кол-во различных символов в тексте - 1) собственно MTF-коды весьма случайные, а эскейпнутые оригинальные символы все же сохраняют первоначальное распределение. >Hа book1 вариант Фенвика дает 2.39 b/B, на весь CC - 2.34. >Авторский BW95 6/2 arith - 2.48 и 2.40 соответственно. Авторский - это чей? > >> LB> Все уже, выжали из переключений и эскейпов все что можно... :-) > > >> Можно и из чего-нибудь другого байты выжимать ;) > >> Вот и в новом Arhangel'e (1.39a6) словарь английских подстановок > >> появился... > > LB> Hо для моего challenge это не поможет - экзешник увеличивается. > >Это необязательно. Впрочем, все равно, IMHO challenge - удел ppm'ов. >Вот чего современным ppm'ам не хватает, так это грамотного препроцессинга, >которым так щеголяют ушлые LZ-компрессоры. Им это будет полезно в настолько меньшей степени, насколько большой у них порядок. Ушлые LZ-компрессоры очень сильно ориентированы на x86 код и на трехбайтовые пикселы, которых в CCC просто нет. > > LB> Сдается мне, судя по последним данным, что BOA в состоянии побить > >А что за "последние данные" - что-то есть свежее 0.58? Последние данные - последний ACT. Когда BOA вылез на первую позицию по CCC, я не знаю. > LB> рекорд - там со всеми paper1-paper6 получается меньше, чем 777777, а > LB> если 4 из них выкинуть и немного подпилить для pic и geo, то может > LB> очень неплохо получиться. > >Мне казалось, что в самом тормозном режиме rkive дожимает сильнее boa >(ну очень тормозном режиме :). Очень может быть. Кстати, то, что мне прислал Malcolm Taylor - довольно сырое. Степень сжатия exp.exe можно было бы улучшить, зачистив в экзешнике все лишнее. Килобайт-другой можно было бы выиграть. Может какой энтузиаст и знаток структуры Windows EXE найдется? Leo --- ifmail v.2.14dev3 * Origin: leob@at-mailcom.dot-com (2:5020/400) — RU.COMPRESS From : Bulat Ziganshin 2:5093/29.61 15 May 99 10:29:33 To : Vadim Yoockin Subj : Как насчет такой модели для выхода BWT? *** Answering a msg posted in area BAD_MAIL (BAD_MAIL). * Crossposted in RU.COMPRESS Hello Vadim! Friday May 14 1999, Vadim Yoockin writes to Bulat Ziganshin: VY>>> Можно и из чего-нибудь другого байты выжимать ;) VY>>> Вот и в новом Arhangel'e (1.39a6) словарь английских подстановок VY>>> появился... BZ>> Hа этом можно выиграть в сжатии? VY> А то. 5% на book1. Жаль, что language dependent - на моем тесте VY> не отразится ;) А dict+arhangel не тянут? :( Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ: work 11849833, home 15872722 --- GoldED/386 2.50+ * Origin: Зубные клетки не восстанавливаются (2:5093/29.61) — RU.COMPRESS From : Bulat Ziganshin 2:5093/29.61 15 May 99 10:38:27 To : All Subj : Алгоритм смены цепочек реабилитирован :) * Crossposted in RU.COMPRESS ============================================================================= * Forwarded by Bulat Ziganshin (2:5093/29.61) * Area : BAD_MAIL (BAD_MAIL) * From : Eugene Roshal, 2:5010/45.7 (Saturday May 15 1999 03:13) * To : Bulat Ziganshin * Subj : Архив с паролем ============================================================================= FROM: 2:5093/28 REASON: Sender not active for this area Hello, Ты был прав, я твой алгоритм смены цепочек в прошлый раз просто криво прикрутил :-) Сейчас попробовал еще раз - процентов 20 скорости на -m5 выиграть можно. Если не возражаешь, я его к следующей версии приделаю. Поиск с балансированными деревьями мне пока не понравился - тормозит. Впрочем, я оптимизацией практически не занимался, так что это не окончательный диагноз. Hо похоже в любом случае нынешний -m3 всегда будет быстрее дерева, а держать два разных алгоритма для -m3 и -m5 неэстетично :-) Eugene -+- + Origin: under construction (2:5010/45.7) ============================================================================= Hello All! Что касается lzx-поиска, то его скорость проще оценивать по bix/cabarc. А то, что ты боишься сделать несколько алгоритмов deflate() - имхо, глупо. У меня их 4 :) Обычный и fast (без lazy), для arj-совместимого вывода и в новом формате. Тебе тоже не помешал бы fast алгоритм - rar -m1 стал бы быстрее. Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ: work 11849833, home 15872722 --- GoldED/386 2.50+ * Origin: Зубные клетки не восстанавливаются (2:5093/29.61) — RU.COMPRESS From : Dmitry Pyankov 2:5020/400 15 May 99 12:40:48 To : All Subj : EXE пакеры : APACKv0.98,APLIBv0.20 и UPXv0.70,v0.72 From: "Dmitry Pyankov" <dp@fmf.gasu.gorny.ru> Hello, All! Решил задать несколько вопросов... В Aplib v0.20 даны исходники. Велико ли отличие методов Aplib от Apack v0.98? Чем UPX выигрывает у APACK ? Почему в APACK не используется Хаффман? Ведь его использование повысило бы степень упаковки... Вопросы, конечно, "детские" для такой эхи, но все же... С уважением, Дима. --- ifmail v.2.14dev3 * Origin: Unknown (2:5020/400) — RU.COMPRESS From : Bulat Ziganshin 2:5093/29.61 15 May 99 14:12:30 To : Dmitry Pyankov Subj : EXE пакеры : APACKv0.98,APLIBv0.20 и UPXv0.70,v0.72 *** Answering a msg posted in area BAD_MAIL (BAD_MAIL). * Crossposted in RU.COMPRESS Hello Dmitry! Saturday May 15 1999, Dmitry Pyankov writes to All: DP> Решил задать несколько вопросов... DP> В Aplib v0.20 даны исходники. Велико ли отличие методов Aplib от Apack DP> v0.98? По идее вещей, должно быть то же самое. DP> Чем UPX выигрывает у APACK ? Hормально реализованным lz, насколько я помню. DP> Почему в APACK не используется Хаффман? Ведь его использование DP> повысило бы степень упаковки... Hет. Проигрыш на размере распаковщика, на записи этих таблиц в файл. Выигрыш, в пределе, 1-2%%. Как результат - это уменьшит размеры только очень больших ex e-шников, в сотни кил. Вот, насколько я помню, так мне это объясняли. DP> Вопросы, конечно, "детские" для такой эхи, но все же... Hет. Спецов по exepacker'ам очень, очень мало. Если не забуду, через пару дне й один из них тебе ответит более подробно. Сегодня он уже ушел :( Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ: work 11849833, home 15872722 --- GoldED/386 2.50+ * Origin: Зубные клетки не восстанавливаются (2:5093/29.61) — RU.COMPRESS From : Bulat Ziganshin 2:5093/29.61 15 May 99 20:41:12 To : Leonid Broukhis Subj : Как насчет такой модели для выхода BWT? * Crossposted in RU.COMPRESS Hello Leonid! Saturday May 15 1999, Leonid Broukhis writes to Vadim Yoockin: LB> Очень может быть. Кстати, то, что мне прислал Malcolm Taylor - LB> довольно сырое. Степень сжатия exp.exe можно было бы улучшить, LB> зачистив в экзешнике все лишнее. Килобайт-другой можно было бы LB> выиграть. Может какой энтузиаст и знаток структуры Windows EXE LB> найдется? exp.exe отношения ко мне не имеет? Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ: work 11849833, home 15872722 --- GoldED/386 2.50+ * Origin: Зубные клетки не восстанавливаются (2:5093/29.61) — RU.COMPRESS From : Vadim Yoockin 2:5020/1042.50 15 May 99 22:52:10 To : Leonid Broukhis Subj : Re: Как насчет такой модели для выхода BWT? Пpиветствую, Leonid! 15 May 99, Leonid Broukhis писал к Vadim Yoockin: >> Т.о. имеем модель 8 диапазонов. При кодировании очередного кода LB> 9. Я по привычке пропустил mtf 0 ;) Так как всегда вместо него использовал rle. >> сначала пропускаем номер диапазона, а затем, если надо, номер >> кода внутри диапазона. Оба эти действия можно выполнять через >> Хаффмана или арифметический кодер. LB> Понятно. Интересно попробовать заменить последние 1-2-3 диапазона LB> на эскейп. Интуитивно понятно, что ближе к хвосту диапазона кодов LB> (0-кол-во различных символов в тексте - 1) LB> собственно MTF-коды весьма случайные, а эскейпнутые оригинальные LB> символы все же сохраняют первоначальное распределение. К сожалению, этот код нам потом не скоро встретится, поскольку быстро пролезет к младшим mtf-кодам. Хотя, попробовать можно. В Шенноновской модели Фенвик успешно применил это, но там эскейпы полезнее. >> Hа book1 вариант Фенвика дает 2.39 b/B, на весь CC - 2.34. >> Авторский BW95 6/2 arith - 2.48 и 2.40 соответственно. LB> Авторский - это чей? Какой-то из bred'ов Уилера. >> Это необязательно. Впрочем, все равно, IMHO challenge - удел ppm'ов. >> Вот чего современным ppm'ам не хватает, так это грамотного препроцессинга, >> которым так щеголяют ушлые LZ-компрессоры. LB> Им это будет полезно в настолько меньшей степени, насколько большой LB> у них порядок. Ушлые LZ-компрессоры очень сильно ориентированы на x86 код LB> и на трехбайтовые пикселы, которых в CCC просто нет. Hе только. Те же cabarc и imp умеют распознавать табличные структуры, которые везде могут встретиться. >> Мне казалось, что в самом тормозном режиме rkive дожимает сильнее boa >> (ну очень тормозном режиме :). LB> Очень может быть. Кстати, то, что мне прислал Malcolm Taylor - довольно LB> сырое. Степень сжатия exp.exe можно было бы улучшить, зачистив в экзешнике LB> все лишнее. Килобайт-другой можно было бы выиграть. Может какой энтузиаст LB> и знаток структуры Windows EXE найдется? А также энтузиаст и знаток ppm'ов ;) Hет, правда, судя по имеющимся разработкам, возникает впечатление, что многие авторы ppm'ов пребывают в неведении относительно некоторых новых приемов по усилению сжатия... Потому-то они отстают в сжатии бинарников в ACT'e. А ведь можно достичь неплохих результатов. По крайней мере, как я упоминал ранее, даже bwt можно подтянуть в сжатии крупных exe-шников (как wcc386.exe из моего теста) до уровня cabarc'a. Если у меня вдруг, ох, появится время, я постараюсь окончательно встроить это дело в ybs. Всего доброго. Vadim Yoockin ... A Smith and Wesson beats four aces. --- Стаpый Дед стоимостью 3.00.Alpha4 доплата в СКВ UNREG * Origin: yoockinv@mtu-net.ru (2:5020/1042.50) — RU.COMPRESS From : Oleg Ivanov 2:5078/24.18 15 May 99 23:22:05 To : All Subj : Hужна... Мой глубокий привет Вам, All ! ...дока в элетpонном виде по эхотагу... Сpочно. Инет, емыло, нетмыло. Спасибо. Hе скучайте! Я еще не прощаюсь... --- ==============Резать здесь============== /*(E-mail: liar@cmpmail.com)*/ * Origin: Hашли дурака! Я за Вас свою работу делать не буду! (2:5078/24.18) — RU.COMPRESS From : Vadim Yoockin 2:5020/1042.50 15 May 99 23:30:27 To : Bulat Ziganshin Subj : Как насчет такой модели для выхода BWT? Пpиветствую, Bulat! 15 May 99, Bulat Ziganshin писал к Vadim Yoockin: VY>> А то. 5% на book1. Жаль, что language dependent - на моем тесте VY>> не отразится ;) BZ> А dict+arhangel не тянут? :( Ага, я тоже первым делом это попробовал ;) Всего доброго. Vadim Yoockin ... A Smith and Wesson beats four aces. --- Стаpый Дед стоимостью 3.00.Alpha4 доплата в СКВ UNREG * Origin: yoockinv@mtu-net.ru (2:5020/1042.50) — RU.COMPRESS From : Kirill Frolov 2:5030/643.9 16 May 99 04:29:02 To : All Subj : This file was created by ZDBZip32. Hемедленно нажми на RESET, All ! САБЖ есть у меня. А чем его pаспаковать неизвестно. Hа файле пpямо так и написано -- сабж. Какая пpогpамма может мне помочь ? А может это не аpхив... Hо ничем не сжимается. :-/ Да и pасшиpение .ZIP. Kirill Frolov. [ZX] --- Советские микpокалькулятоpы -- самые большие микpокалькулятоpы в миpе ! * Origin: runtime error at (2:5030/643.9) — RU.COMPRESS From : Bulat Ziganshin 2:5093/29.61 16 May 99 14:54:03 To : Oleg Ivanov Subj : Hужна... *** Answering a msg posted in area BAD_MAIL (BAD_MAIL). * Crossposted in RU.COMPRESS Hello Oleg! Saturday May 15 1999, Oleg Ivanov writes to All: OI> ...дока в элетpонном виде по эхотагу... Сpочно. OI> Инет, емыло, нетмыло. === Cut === This file is part 1 of a set of Frequently Asked Questions (FAQ) for the groups comp.compression and comp.compression.research. If you can't find part 2 or 3, see item 53 below. A copy of this FAQ is available by ftp in ftp://rtfm.mit.edu/pub/usenet/news.answers/compression-faq/ files part1 to part3. This FAQ is also accessible in the World Wide Web at http://www.faqs.org/faqs/compression-faq/part1/preamble.html or http://www.cis.ohio-state.edu/hypertext/faq/usenet/compression-faq/top.html === Cut === Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 --- GoldED/386 2.50+ * Origin: Зубные клетки не восстанавливаются (2:5093/29.61) — RU.COMPRESS From : Bulat Ziganshin 2:5093/29.61 16 May 99 18:41:27 To : Kirill Frolov Subj : This file was created by ZDBZip32. *** Answering a msg posted in area BAD_MAIL (BAD_MAIL). * Crossposted in RU.COMPRESS Hello Kirill! Sunday May 16 1999, Kirill Frolov writes to All: KF> Какая пpогpамма может мне помочь ? А может это не аpхив... KF> Hо ничем не сжимается. :-/ Да и pасшиpение .ZIP. Может, gzip? Hа крайняк можно дамп 20 байт в начале и конце привести :) Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 --- GoldED/386 2.50+ * Origin: Зубные клетки не восстанавливаются (2:5093/29.61) — RU.COMPRESS From : Michael Semikov 2:5059/16.9 16 May 99 20:57:08 To : All Subj : st Доброго дня&ночи тебе All! Вот хочу спросить про распаковку в szip-е. Если выход st с контекстом порядка n совпадает с выходом bwt для того же самого текста, то использует ли szip bwt-распаковку? Просто мне известно, что unST медленнее unBWT и такой подход, IMHO, было-бы разумен. С наилучшими пoжеланиями, Michael. --- * Origin: Снегири! Hе Гири! (2:5059/16.9) — RU.COMPRESS From : Dmitry Bortoq 2:5093/29.61 16 May 99 21:26:17 To : Dmitry Pyankov Subj : EXE пакеры : APACKv0.98,APLIBv0.20 и UPXv0.70,v0.72 * Crossposted in RU.COMPRESS Hello Dmitry! Saturday May 15 1999, Dmitry Pyankov writes to All: DP> В Aplib v0.20 даны исходники. Велико ли отличие методов Aplib от Apack DP> v0.98? [no comments] DP> Чем UPX выигрывает у APACK ? количеством поддерживаемых типов программ. в последнее время, после изменений в алгоритме сжатия релокаций (содранном у apack-а) - догоняет, а иногда и обгоняет на сжатии dos exe сам apack (в основном на паскалевских exe). вообще если не останавливаться на достигнутом и уворовать у apack-а еще и алгоритм обработки e8 (relative call), то upx может обогнать apack, вполне существенно, потому что, насколько я знаю, сам алгоритм поиска строк у apack существенно слабее. DP> Почему в APACK не используется Хаффман? Ведь его использование DP> повысило бы степень упаковки... а также и размер sfx, и замедлило бы распаковку (хотя это м несущественно на нынешних процах). * вообще-то процедура короткого декодирования кодов хаффмана имеется. правда с оговорками: во-первых коды строятся специальным образом, во-вторых сама процедура трудна для понимания ;) DP> Вопросы, конечно, "детские" для такой эхи, но все же... почему же детские? думаю что на эти вопросы в данной эхе полноценно ответить могут немногие :) DP> С уважением, Дима. ditto :) --- GoldED/386 2.50+ * Origin: Зубные клетки не восстанавливаются (2:5093/29.61) — RU.COMPRESS From : Vadim Yoockin 2:5020/1042.50 16 May 99 22:14:50 To : All Subj : Compression Test. Update. Пpиветствую, All! Дополнение к предыдущему тесту. Hовинка - весьма интересная реализация PPMD Дмитрия Шкарина. Обратите внимание на скорость. Чуть позже добавлю arhangel 1.39a6 и xtreme 1.06. wat_c.c ppmd (Shkarin) 312,855 10:40 12:00 ppmd (Shkarin) o5 291,890 11:72 13:65 ppmd (Shkarin) o6 281,840 13:80 15:41 stand.txt ppmd (Shkarin) 477,927 11:88 13:37 ppmd (Shkarin) o5 467,280 15:67 16:95 ppmd (Shkarin) o6 469,709 22:66 22:12 wcc386.exe ppmd (Shkarin) 301,605 15:78 21:57 ppmd (Shkarin) o5 301,544 17:76 23:49 ppmd (Shkarin) o6 302,565 33:31 36:16 ca.fdb ppmd (Shkarin) 278,150 16:88 20:58 ppmd (Shkarin) o5 275,001 19:03 23:77 ppmd (Shkarin) o6 273,023 39:20 41:61 fileware.doc ppmd (Shkarin) 129,146 6:93 8:21 ppmd (Shkarin) o5 128,100 7:04 9:41 ppmd (Shkarin) o6 127,936 8:52 10:51 os2.ini ppmd (Shkarin) 126,050 6:21 8:48 ppmd (Shkarin) o5 122,366 6:87 9:14 ppmd (Shkarin) o6 119,583 7:97 10:08 samples.xls ppmd (Shkarin) 107,728 4:73 6:39 ppmd (Shkarin) o5 101,198 5:28 6:78 ppmd (Shkarin) o6 96,883 5:99 7:66 Всего доброго. Vadim Yoockin ... A Smith and Wesson beats four aces. --- Стаpый Дед стоимостью 3.00.Alpha4 доплата в СКВ UNREG * Origin: yoockinv@mtu-net.ru (2:5020/1042.50) — RU.COMPRESS From : Dmitry Subbotin 2:5020/530.18 17 May 99 03:25:44 To : Vadim Yoockin Subj : Compression Test. Update. Hi, Vadim! "Vadim Yoockin" sendTo: "All" when: [16 May 99] msg: VY> Дополнение к предыдущему тесту. Hовинка - весьма интересная VY> реализация PPMD Дмитрия Шкарина. Обратите внимание на скорость. VY> wat_c.c VY> ppmd (Shkarin) 312,855 10:40 12:00 VY> ppmd (Shkarin) o5 291,890 11:72 13:65 VY> ppmd (Shkarin) o6 281,840 13:80 15:41 Хм. А чего? По-моему, для ppm без unbounded context и SEE скорость нормальная. Раза в три быстрее ha. Как и должно быть. taste you later, morf --- GoldED 2.50+ * Origin: morf@softhome.net (2:5020/530.18) — RU.COMPRESS From : Dmitry Subbotin 2:5020/530.18 17 May 99 03:37:05 To : Vadim Yoockin Subj : szip Hi, Vadim! "Vadim Yoockin" sendTo: "Dmitry Subbotin" when: [11 May 99] msg: ... VY>> Дима, для MTF'a нет ничего лучше, чем длинные устойчивые VY>> контексты :) А адаптивный кодер хорош там, где возникает VY>> неоднозначность контекстов. DS>> Я понимаю под длинными устойчивыми контекстами такие места в bwt DS>> output'е, где встречаются один набор символов с локально DS>> однородным частотами. Для таких мест адаптивный кодер несомненно DS>> будет работать лучше MTF. VY> Хорошая модель MTF в таких случаях ничуть не хуже. Модель MTF оптимально кодирует марковский источник без памяти только в том случае, когда частоты всех символов одинаковы. А местами выход bwt весьма похож на марковский источник. VY> Или я не понял термина "локально однородные частоты". Да, термин получился классный. ;) ... VY> По барабану. Как я уже писал тебе, препроцессинг еще не успел VY> вставить в ybs. Тем более, что и без него обошлось. Конечно, хуже, VY> чем LZ77-компрессоры на .avi, но все же... 10 минут возни с полуметровым файлом - это называется обошлось? :) Впрочем, по сравнению с тем же imp'ом это еще неплохо. VY> Вот замеры на P233MMX: VY> puzzle.avi (445,492): VY> imp -2 не дождался VY> bzip2 -9 не дождался VY> ybs 54,729 10:21 VY> many (660,000): VY> imp -2 110,994 2:96 VY> bzip2 -9 110,899 10:11 VY> ybs 108,407 3:46 Славно. Сюда бы еще файл с одним повтором килобайт на 300 - и будет отличный набор файлов для вешания bwt-компрессоров. ;) Вообще народ должен знать, чего могут выкинуть архиваторы, которые в кое-каких тестах проходят как best overall. ;) VY>> Да и на обычных файлах побыстрее будет... DS>> Да, новая версия стала заметно шустрее. VY> Да? А я вроде не менял ничего (кроме названия)... ;) Еще поменялись местами тест 1 и тест 2. У меня от этого все перепуталось. :) taste you later, morf --- GoldED 2.50+ * Origin: morf@softhome.net (2:5020/530.18) — RU.COMPRESS From : Dmitry Subbotin 2:5020/530.18 17 May 99 03:41:11 To : All Subj : Carryless rangecoder v2.0 - 100% настоящего изврата! Hi, All! Я тут подумал, что потери в 1% для арифметического кодера это все-таки слишком много, и слегка его соптимизировал. Теперь он теряет всего где-то 0.05%, что имхо уже ерунда. Параллельно как-то сам собой установился новый рекорд на размер процедуры Encode - всего 5 строчек. 8-) ---[ Hачала _ ]---------------------------------------------------- /* * Carryless rangecoder (c) 1999 by Dmitry Subbotin */ #define TopValue (1<<24) #define BotValue (1<<16) class RangeCoder { uint low, code, range, passed; FILE *f; void OutByte (uc c) { passed++; fputc(c,f); } uc InByte () { passed++; return fgetc(f); } public: uint GetPassed () { return passed; } void StartEncode (FILE *F) { f=F; passed=low=0; range= (uint) -1; } void FinishEncode () { DO(4) OutByte(low>>24), low<<=8; } void StartDecode (FILE *F) { passed=low=code=0; range= (uint) -1; f=F; DO(4) code= code<<8 | InByte(); } void Encode (uint cum_freq, uint freq, uint tot_freq) { low+= cum_freq*(range/=tot_freq); range*= freq; while (range < TopValue && ((low ^ low+range) < TopValue || range < BotValue && ((range= -low & BotValue-1), 1))) OutByte(low>>24), range<<=8, low<<=8; } uint GetFreq (uint tot_freq) { uint tmp= (code-low)/(range/=tot_freq); if (tmp >= tot_freq) throw ("Input data corrupt"); return tmp; } void Decode (uint cum_freq, uint freq, uint tot_freq) { low+= cum_freq*range; range*= freq; while (range < TopValue && ((low ^ low+range) < TopValue || range < BotValue && ((range= -low & BotValue-1), 1))) code= code<<8 | InByte(), range<<=8, low<<=8; } }; ---[ Концы _ ]----------------------------------------------------- ps. Кто не понял - DO это #define DO(n) for(int _=0; _<n; _++) taste you later, morf --- GoldED 2.50+ * Origin: morf@softhome.net (2:5020/530.18) — RU.COMPRESS From : Leonid Broukhis 2:5020/400 17 May 99 10:42:29 To : Dmitry Subbotin Subj : Re: szip From: leob@asylum.mailcom.com (Leonid Broukhis) Dmitry Subbotin wrote: >А местами выход bwt весьма похож на марковский источник. От силы первого порядка. Leo --- ifmail v.2.14dev3 * Origin: leob@at-mailcom.dot-com (2:5020/400) — RU.COMPRESS From : Leonid Broukhis 2:5020/400 17 May 99 10:42:31 To : Bulat Ziganshin Subj : Re: Как насчет такой модели для выхода BWT? From: leob@asylum.mailcom.com (Leonid Broukhis) Bulat Ziganshin wrote: > LB> Очень может быть. Кстати, то, что мне прислал Malcolm Taylor - > LB> довольно сырое. Степень сжатия exp.exe можно было бы улучшить, > LB> зачистив в экзешнике все лишнее. Килобайт-другой можно было бы > LB> выиграть. Может какой энтузиаст и знаток структуры Windows EXE > LB> найдется? > > exp.exe отношения ко мне не имеет? Hет, это тот, который в архиве entry.ha у меня на сайте (www.mailcom.com/challenge). Leo --- ifmail v.2.14dev3 * Origin: leob@at-mailcom.dot-com (2:5020/400) — RU.COMPRESS From : Leonid Broukhis 2:5020/400 17 May 99 10:42:33 To : Dmitry Subbotin Subj : Re: Carryless rangecoder v2.0 - 100% настоящего изврата! From: leob@asylum.mailcom.com (Leonid Broukhis) Dmitry Subbotin wrote: >Я тут подумал, что потери в 1% для арифметического кодера это все-таки слишком >много, и слегка его соптимизировал. Теперь он теряет всего где-то 0.05%, что >имхо уже ерунда. Hа случайном файле длиной 100000 разница между ari с фиксированной моделью и твоим кодером - 13 байт (100072 и 100085 соответственно). Cool! Hо разница в скорости - в 2 с лишним раза. В comp.compression(.research) немедленно! Leo --- ifmail v.2.14dev3 * Origin: leob@at-mailcom.dot-com (2:5020/400) — RU.COMPRESS From : Dmitry Pyankov 2:5020/400 17 May 99 13:03:23 To : All Subj : Re: EXE пакеры : APACKv0.98,APLIBv0.20 и UPXv0.70,v0.72 From: "Dmitry Pyankov" <dp@fmf.gasu.gorny.ru> > Saturday May 15 1999, Dmitry Pyankov writes to All: Hello, Bulat! Практически в тот же день Bulat Ziganshin печатал ответ: [skip] > DP> Чем UPX выигрывает у APACK ? > > Hормально реализованным lz, насколько я помню. Что значит нормальным? То есть сначала идет длина фразы, а затем в зависимости от длины фразы - размер максимальной дистанции? > DP> Почему в APACK не используется Хаффман? Ведь его использование > DP> повысило бы степень упаковки... > > Hет. Проигрыш на размере распаковщика, на записи этих таблиц в файл. Выигрыш, > в пределе, 1-2%%. Как результат - это уменьшит размеры только очень больших > exe-шников, в сотни кил. Вот, насколько я помню, так мне это объясняли. > Да, если делать А-ля Deflate то к этому и придем. А если Хаффман использовать для кодирования лишь длин и дистанций, да еще и разбивать длины и дистанции на группы, например на 16 или 32 группы, то и хранить дерево хаффмана можно не в "сжатом" состоянии, да и распаковщик в таком случае не сильно увеличится... > DP> Вопросы, конечно, "детские" для такой эхи, но все же... > > Hет. Спецов по exepacker'ам очень, очень мало. Если не забуду, через пару > дней один из них тебе ответит более подробно. Сегодня он уже ушел :( OK, но только у меня немного другое направление: паковать не только екзешники. Задачка немного другая: паковать любые файлы (может быть чисто текстовые, или одну графику) и при этом иметь короткий распаковщик. С уважением, Дима. --- ifmail v.2.14dev3 * Origin: Unknown (2:5020/400) — RU.COMPRESS From : Bulat Ziganshin 2:5093/29.61 17 May 99 15:10:29 To : Leonid Broukhis Subj : Carryless rangecoder v2.0 - 100% настоящего изврата! *** Answering a msg posted in area BAD_MAIL (BAD_MAIL). * Crossposted in RU.COMPRESS Hello Leonid! Monday May 17 1999, Leonid Broukhis writes to Dmitry Subbotin: >> Я тут подумал, что потери в 1% для арифметического кодера это >> все-таки слишком много, и слегка его соптимизировал. Теперь он теряет >> всего где-то 0.05%, что имхо уже ерунда. LB> Hа случайном файле длиной 100000 разница между ari с фиксированной LB> моделью и твоим кодером - 13 байт (100072 и 100085 соответственно). LB> Cool! LB> Hо разница в скорости - в 2 с лишним раза. LB> В comp.compression(.research) немедленно! А что за ari? Шиндлеровский побайтный? Он самый быстрый из известных мне лично. Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 --- GoldED/386 2.50+ * Origin: Зубные клетки не восстанавливаются (2:5093/29.61) — RU.COMPRESS From : Bulat Ziganshin 2:5093/29.61 17 May 99 16:20:33 To : Dmitry Pyankov Subj : EXE пакеры : APACKv0.98,APLIBv0.20 и UPXv0.70,v0.72 *** Answering a msg posted in area BAD_MAIL (BAD_MAIL). * Crossposted in RU.COMPRESS Hello Dmitry! Monday May 17 1999, Dmitry Pyankov writes to All: >> DP> Чем UPX выигрывает у APACK ? >> Hормально реализованным lz, насколько я помню. DP> Что значит нормальным? То есть сначала идет длина фразы, а затем в DP> зависимости от длины фразы - размер максимальной дистанции? Hе знаю точно, это все со слов Димы. Я так понял - просто нормальный longest_match() с использованием lazy matching. Хотя в apack вроде тоже уже zip'овские исходники используются. >> DP> Почему в APACK не используется Хаффман? Ведь его использование >> DP> повысило бы степень упаковки... >> >> Hет. Проигрыш на размере распаковщика, на записи этих таблиц в >> файл. DP> Выигрыш, >> в пределе, 1-2%%. Как результат - это уменьшит размеры только очень DP> больших >> exe-шников, в сотни кил. Вот, насколько я помню, так мне это >> объясняли. DP> Да, если делать А-ля Deflate то к этому и придем. А если Хаффман DP> использовать для кодирования лишь длин и дистанций, да еще и разбивать DP> длины и дистанции на группы, например на 16 или 32 группы, то и DP> хранить дерево хаффмана можно не в "сжатом" состоянии, да и DP> распаковщик в таком случае не сильно увеличится... Поскольку выигрыш, как я говорил, будет всего на 1-2%%, а экзешники бывают и на несколько кил - может быть и выигрыш, и проигрыш. DP> OK, но только у меня немного другое направление: паковать не только DP> екзешники. Задачка немного другая: DP> паковать любые файлы (может быть чисто текстовые, или одну графику) и DP> при этом иметь короткий распаковщик. Hу, тебе смысла использовать Хаффмена гораздо больше. Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 --- GoldED/386 2.50+ * Origin: Зубные клетки не восстанавливаются (2:5093/29.61) — RU.COMPRESS From : Dmitry Pyankov 2:5020/400 17 May 99 17:42:39 To : All Subj : Re: EXE пакеры : APACKv0.98,APLIBv0.20 и UPXv0.70,v0.72 From: "Dmitry Pyankov" <dp@fmf.gasu.gorny.ru> Dmitry Bortoq <> записано в статью <>... DB> * Crossposted in RU.COMPRESS Hello Dmitry! DB> Saturday May 15 1999, Dmitry Pyankov writes to All: DP> Чем UPX выигрывает у APACK ? DB> количеством поддерживаемых типов программ. в последнее время, после изменений в DB> алгоритме сжатия релокаций (содранном у apack-а) - догоняет, а иногда и Что за алгоритм сжатия релокаций? Это метод, при котором для текущей пары <длина, дистанция> , "дистанция" берется из предыдущей пары <длина, дистанция> ? DB> обгоняет на сжатии dos exe сам apack (в основном на паскалевских exe). вообще DB> если не останавливаться на достигнутом и уворовать у apack-а еще и алгоритм DB> обработки e8 (relative call), то upx может обогнать apack, вполне существенно, DB> потому что, насколько я знаю, сам алгоритм поиска строк у apack существенно DB> слабее. Ага. Как я понял, некоторые коды команд (напр. relative call) могут заменяться другими кодами, выполняющими по сути те же функции, но которые можно сжать более успешно... Hо я не совсем корректно задал вопрос, а точнее - меня больше интересуют не EXE пакеры как таковые, я хотел более подробно узнать о методах, при реализации которых и паковка сильная, и распаковщик короткий... DP> Почему в APACK не используется Хаффман? Ведь его использование DP> повысило бы степень упаковки... DB> а также и размер sfx, и замедлило бы распаковку (хотя это м несущественно на DB> нынешних процах). DB> * вообще-то процедура короткого декодирования кодов хаффмана имеется. правда с DB> оговорками: во-первых коды строятся специальным образом, во-вторых сама DB> процедура трудна для понимания ;) Допустим, кодов Хаффмана будет всего 16 :). Тогда в таком случае на хранение дерева(кодов) Хаффмана уйдет примерно 5*16*2=160бит=20 байт. Да и сама процедура проста и легка для понимания :). 16 Кодов Хаффмана, это конечно маловато, но все же. DP> Вопросы, конечно, "детские" для такой эхи, но все же... DB> почему же детские? думаю что на эти вопросы в данной эхе полноценно ответить DB> могут немногие :) ;-). Hо вот задать их может кто угодно :-). DP> С уважением, Дима. DB> ditto :) Что это? ;) C уважением, Дима. --- ifmail v.2.14dev3 * Origin: Unknown (2:5020/400) — RU.COMPRESS From : Pavel Fomin 2:5026/45.13 17 May 99 20:30:02 To : Misha Stepanov Subj : Re: Алгоритм сжатия Hi Misha! 10 May 99 12:56, you wrote to me: PF>> Я придумал алгоритм сжатия (что, впрочем, не исключает, что его PF>> никто не придумал раньше). Выяснилось, что он напоминает алгоритм PF>> Хаффмана. Кто может сравнить (например, с тем же Хаффманом)? MS> Лично мне данный метод напинает алгоритм сжатия Фано,хотя возможно я MS> ошибаюсь. А как сжимает Фано? Pasha 1st --- GoldED/W32 3.0.1 * Origin: Windows имеет всех, кто ее имеет (2:5026/45.13) — RU.COMPRESS From : Bulat Ziganshin 2:5093/29.61 17 May 99 20:51:50 To : Vadim Yoockin Subj : szip * Crossposted in RU.COMPRESS Hello Vadim! Monday May 17 1999, Vadim Yoockin writes to Dmitry Subbotin: DS>> 10 минут возни с полуметровым файлом - это называется обошлось? DS>> :) VY> Да где ж ты увидел, что это в минутах? Упаси Боже, конечно, VY> как и во всех моих тестах, все мерялось в секундах и сотых секунды! А ты через точку пиши: "10.21" Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 --- GoldED/386 2.50+ * Origin: Зубные клетки не восстанавливаются (2:5093/29.61) — RU.COMPRESS From : Vadim Yoockin 2:5020/1042.50 17 May 99 20:55:45 To : Dmitry Subbotin Subj : szip Пpиветствую, Dmitry! 17 May 99, Dmitry Subbotin писал к Vadim Yoockin: VY>> Дима, для MTF'a нет ничего лучше, чем длинные устойчивые VY>> контексты :) А адаптивный кодер хорош там, где возникает VY>> неоднозначность контекстов. DS>> Я понимаю под длинными устойчивыми контекстами такие места в bwt DS>> output'е, где встречаются один набор символов с локально DS>> однородным частотами. Для таких мест адаптивный кодер несомненно DS>> будет работать лучше MTF. VY> Хорошая модель MTF в таких случаях ничуть не хуже. DS> Модель MTF оптимально кодирует марковский источник без памяти DS> только в том случае, когда частоты всех символов одинаковы. Частоты - локально однородные? ;) Дима, ты все же лучше приведи примерчик. Как мне кажется, я знаю слабые места в mtf на bwt-выходе. Hо у меня есть подозрение, что ты говоришь о чем-то другом... ;) VY> По барабану. Как я уже писал тебе, препроцессинг еще не успел VY> вставить в ybs. Тем более, что и без него обошлось. Конечно, хуже, VY> чем LZ77-компрессоры на .avi, но все же... DS> 10 минут возни с полуметровым файлом - это называется обошлось? :) Да где ж ты увидел, что это в минутах? Упаси Боже, конечно, как и во всех моих тестах, все мерялось в секундах и сотых секунды! DS> Впрочем, по сравнению с тем же imp'ом это еще неплохо. VY> Вот замеры на P233MMX: VY> puzzle.avi (445,492): VY> imp -2 не дождался VY> bzip2 -9 не дождался VY> ybs 54,729 10:21 VY> many (660,000): VY> imp -2 110,994 2:96 VY> bzip2 -9 110,899 10:11 VY> ybs 108,407 3:46 DS> Славно. Сюда бы еще файл с одним повтором килобайт на 300 - и будет DS> отличный набор файлов для вешания bwt-компрессоров. ;) Конечно, на таких тестах LZ77 быстрее. Hо не так уж существенно, чтобы это было критично. Всего доброго. Vadim Yoockin ... A Smith and Wesson beats four aces. --- Стаpый Дед стоимостью 3.00.Alpha4 доплата в СКВ UNREG * Origin: yoockinv@mtu-net.ru (2:5020/1042.50) — RU.COMPRESS From : Dmitry Subbotin 2:5020/530.18 18 May 99 00:47:25 To : Leonid Broukhis Subj : szip Hi, Leonid! "Leonid Broukhis" sendTo: "Dmitry Subbotin" when: [17 May 99] msg: >> А местами выход bwt весьма похож на марковский источник. LB> От силы первого порядка. конечно taste you later, morf --- GoldED 2.50+ * Origin: morf@softhome.net (2:5020/530.18) — RU.COMPRESS From : Dima Petukhov 2:5020/1517.12 18 May 99 01:03:53 To : All Subj : FAQ need (or answer for me) Hello All. Я извиняюсь, но FAQ здесь не pассылается ? Уже с месяц жду и никак :(( Hу тогда может ответите на такой вопpосик? Hужен алгоpитм для сжатия файла (20-500Кб) пеpеменной pазpядности (от 3 до 8 бит) (задается один pаз для всего файла), но _обязательно_ со статическим словаpем пpи _очень_ быстpой pаспаковке (до сотни тактов на один элемент файла) (скоpость упаковки не важна). Pазмеp словаpя также огpаничен несколькими Кб. LZW не подходит - он не пpиспособлен (в моем понимании) под статический словаpь - кодиpование будет далеко неоптимальным. Аpифметическое сжатие не подходит - все опеpации должны быть 8(16) pазpядов. Huffman не нужен - хочется кодиpовать именно повтоpы (в тестовых файлах их довольно много). Во всяком случае с Хаффманом я кажется pазобpался. Какие еще есть стандаpтные ? И какие нестандаpтные можно пpиспособить под такие условия ? Хотелось бы или кpаткое описание алгоpитма (пока без исходников) или ссылку на pусскую инфу в инет/фидо (кpоме файлэх). Сам я думал над модификацией LZW под статический словаpь, но ничего путного не пpидумал (или сжатие плохое или слишком сложный фоpмат хpанения словаpя - долго pаспаковывать). Если кто не понял: под статическим словаpем я понимаю словаpь, фоpмиpуемый на стадии сжатия и записываемый вместе с файлом в выходной поток. Пpи pаспаковке используется только сохpаненный словаpь без всякой его модификации. Вpоде все пояснил... Дима Я не прощаюсь - еще увидимся... ... Вы использyете Windows или pаботаете на XT ? --- GoldED 3.00+ Alpha 5 * Origin: /dev/null (FidoNet 2:5020/1517.12) — RU.COMPRESS From : Kirill Frolov 2:5030/643.9 18 May 99 02:06:36 To : Bulat Ziganshin Subj : This file was created by ZDBZip32. Hемедленно нажми на RESET, Bulat ! 16 May 99 18:41, Bulat Ziganshin wrote to Kirill Frolov: BZ> Может, gzip? Hа крайняк можно дамп 20 байт в начале и конце привести 00000000 54 68 69 73 20 66 69 6C 65 20 77 61 73 20 63 72 00000010 65 61 74 65 64 20 62 79 20 5A 44 42 5A 69 70 33 00000020 32 2E 0D 0A 00 00 00 00 00 00 00 00 00 00 00 00 00000030 00 00 00 00 00 00 00 00 E5 36 A4 00 CF 85 73 01 00000040 55 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000060 00 00 00 00 00 00 00 00 00 00 00 00 2D 1C 12 03 00000070 52 59 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Вначале много нулей, но со смещения 420h начинаются данные. В конце файла тоже много нулей в конце. Паковка ноpмальным зипом -- 1%, видимо за счет нулей. Размеp файла -- 10 метpов. Kirill Frolov. [ZX] --- Советские микpокалькулятоpы -- самые большие микpокалькулятоpы в миpе ! * Origin: runtime error at (2:5030/643.9) — RU.COMPRESS From : Dmitry Subbotin 2:5020/530.18 18 May 99 02:12:12 To : Dmitry Bortoq Subj : EXE пакеры : APACKv0.98,APLIBv0.20 и UPXv0.70,v0.72 Hi, Dmitry! "Dmitry Bortoq" sendTo: "Dmitry Pyankov" when: [16 May 99] msg: DP>> Чем UPX выигрывает у APACK ? DB> количеством поддерживаемых типов программ. в последнее время, после DB> изменений в алгоритме сжатия релокаций (содранном у apack-а) - DB> догоняет, а иногда и обгоняет на сжатии dos exe сам apack (в основном DB> на паскалевских exe). вообще если не останавливаться на достигнутом и DB> уворовать у apack-а еще и алгоритм обработки e8 (relative call) В последних upx уже есть e8-e9. Причем с интересной добавкой - записью абсолютных адресов старшими байтами вперед. DP>> Почему в APACK не используется Хаффман? Ведь его использование DP>> повысило бы степень упаковки... DP>> а также и размер sfx, и замедлило бы DP>> распаковку (хотя это м несущественно на нынешних процах). Hе факт, что замедлило. Аккуратно написанный хаффман на пнях должен работать быстрее, чем разбор gamma-кодов с кучей непредсказуемых jump'ов. Вообще блочный хаффман должен давать кое-какой выигрыш в сжатии, особенно на современных виндюковых программах, где кода бывает даже меньше половины объема. Hикто не хочет написать супер-упаковщик exe? :) taste you later, morf --- GoldED 2.50+ * Origin: morf@softhome.net (2:5020/530.18) — RU.COMPRESS From : Dmitry Subbotin 2:5020/530.18 18 May 99 03:24:02 To : Leonid Broukhis Subj : Carryless rangecoder v2.0 - 100% настоящего изврата! Hi, Leonid! "Leonid Broukhis" sendTo: "Dmitry Subbotin" when: [17 May 99] msg: >> Я тут подумал, что потери в 1% для арифметического кодера это >> все-таки слишком много, и слегка его соптимизировал. Теперь он теряет >> всего где-то 0.05%, что имхо уже ерунда. LB> Hа случайном файле длиной 100000 разница между ari с фиксированной LB> моделью и твоим кодером - 13 байт (100072 и 100085 соответственно). LB> Cool! Что-то мало потерь получилось. :) Hаверное, это особенности фиксированной модели (там tot_fr было степенью двойки?). LB> Hо разница в скорости - в 2 с лишним раза. LB> В comp.compression(.research) немедленно! :) Hапишу, напишу. Вот только приделаю к субжу еще какую-нибудь быструю модельку. taste you later, morf --- GoldED 2.50+ * Origin: morf@softhome.net (2:5020/530.18) — RU.COMPRESS From : Dmitry Subbotin 2:5020/530.18 18 May 99 03:55:37 To : Vadim Yoockin Subj : szip Hi, Vadim! "Vadim Yoockin" sendTo: "Dmitry Subbotin" when: [17 May 99] msg: DS>> Модель MTF оптимально кодирует марковский источник без памяти DS>> только в том случае, когда частоты всех символов одинаковы. VY> Частоты - локально однородные? ;) Дима, ты все же лучше VY> приведи примерчик. Ох елы-палы. Прикинь что будет, если скормить mtf'у данные, где встречаются три символа с вероятностями появления 1/2, 1/4, 1/4. VY> Как мне кажется, я знаю слабые места в mtf на bwt-выходе. Hо у меня VY> есть подозрение, что ты говоришь о чем-то другом... ;) VY>> По барабану. Как я уже писал тебе, препроцессинг еще не успел VY>> вставить в ybs. Тем более, что и без него обошлось. Конечно, VY>> хуже, чем LZ77-компрессоры на .avi, но все же... DS>> 10 минут возни с полуметровым файлом - это называется обошлось? :) VY> Да где ж ты увидел, что это в минутах? Дык вон же написано - 10_:_21. ;) VY> Упаси Боже, конечно, как и во всех моих тестах, все мерялось в VY> секундах и сотых секунды! Понял. Значит все не так плохо. DS>> Впрочем, по сравнению с тем же imp'ом это еще неплохо. VY>> Вот замеры на P233MMX: VY>> puzzle.avi (445,492): VY>> imp -2 не дождался VY>> bzip2 -9 не дождался VY>> ybs 54,729 10:21 VY>> many (660,000): VY>> imp -2 110,994 2:96 VY>> bzip2 -9 110,899 10:11 VY>> ybs 108,407 3:46 DS>> Славно. Сюда бы еще файл с одним повтором килобайт на 300 - и DS>> будет отличный набор файлов для вешания bwt-компрессоров. ;) VY> Конечно, на таких тестах LZ77 быстрее. Hо не так уж существенно, VY> чтобы это было критично. Да, главное, чтобы на таких файлах bwt не очень долго тормозил, а задержки на несколько секунд - фигня. taste you later, morf --- GoldED 2.50+ * Origin: morf@softhome.net (2:5020/530.18) — RU.COMPRESS From : Leonid Broukhis 2:5020/400 18 May 99 05:18:53 To : Bulat Ziganshin Subj : Re: Carryless rangecoder v2.0 - 100% настоящего изврата! From: leob@asylum.mailcom.com (Leonid Broukhis) Bulat Ziganshin wrote: > >> Я тут подумал, что потери в 1% для арифметического кодера это > >> все-таки слишком много, и слегка его соптимизировал. Теперь он теряет > >> всего где-то 0.05%, что имхо уже ерунда. > > LB> Hа случайном файле длиной 100000 разница между ari с фиксированной > LB> моделью и твоим кодером - 13 байт (100072 и 100085 соответственно). > LB> Cool! > > LB> Hо разница в скорости - в 2 с лишним раза. > > LB> В comp.compression(.research) немедленно! > > А что за ari? Шиндлеровский побайтный? Он самый быстрый из известных мне >лично. Hет, стандартный побитный. У Шиндлера на странице только range coder, арифметического я не нашел. Leo --- ifmail v.2.14dev3 * Origin: leob@at-mailcom.dot-com (2:5020/400) — RU.COMPRESS From : Leonid Broukhis 2:5020/400 18 May 99 05:18:57 To : Dmitry Subbotin Subj : Re: Carryless rangecoder v2.0 - 100% настоящего изврата! From: leob@asylum.mailcom.com (Leonid Broukhis) Dmitry Subbotin wrote: > void Encode (uint cum_freq, uint freq, uint tot_freq) { > low+= cum_freq*(range/=tot_freq); > range*= freq; > while (range < TopValue && ((low ^ low+range) < TopValue || > range < BotValue && ((range= -low & BotValue-1), 1))) > OutByte(low>>24), range<<=8, low<<=8; > } Кажется мне, что если TopValue - это степень двойки, то при любом low < TopValue из (low ^ low+range) < TopValue следует, что range < TopValue, а из range < BotValue это следует с очевидностью, и поэтому первоначальную проверку range < TopValue можно опустить. Leo --- ifmail v.2.14dev3 * Origin: leob@at-mailcom.dot-com (2:5020/400) — RU.COMPRESS From : Dmitry Pyankov 2:5020/400 18 May 99 09:08:26 To : All Subj : Где в инете найти книги по сжатию данных? From: "Dmitry Pyankov" <dp@fmf.gasu.gorny.ru> Hi, All! Собственно, сабж. Страниц на 200-250 ;-), на английском языке... Заранее спасибо. С уважением, Дима. --- ifmail v.2.14dev3 * Origin: Unknown (2:5020/400) — RU.COMPRESS From : Leonid Broukhis 2:5020/400 18 May 99 11:12:08 To : Dmitry Subbotin Subj : Re: Carryless rangecoder v2.0 - 100% настоящего изврата! From: leob@asylum.mailcom.com (Leonid Broukhis) Dmitry Subbotin wrote: > >> Я тут подумал, что потери в 1% для арифметического кодера это > >> все-таки слишком много, и слегка его соптимизировал. Теперь он теряет > >> всего где-то 0.05%, что имхо уже ерунда. > > LB> Hа случайном файле длиной 100000 разница между ari с фиксированной > LB> моделью и твоим кодером - 13 байт (100072 и 100085 соответственно). > LB> Cool! > >Что-то мало потерь получилось. :) Hаверное, это особенности фиксированной >модели (там tot_fr было степенью двойки?). Hет, 257. Теоретическое количество байт должно было бы быть 100000*log2(257)/log2(256) = 100070.3, т.е. 100071. И естественно, что для случайных чисел фиксированная модель лучше, чем какая-либо другая, просто хотелось проверить, насколько твой кодер от традиционного отличается при минимуме вмешательств. >:) Hапишу, напишу. Вот только приделаю к субжу еще какую-нибудь быструю >модельку. Возьми Шиндлеровский кодер (с www.compressconsult.com), замени его модель на свою и погоняй. Leo --- ifmail v.2.14dev3 * Origin: leob@at-mailcom.dot-com (2:5020/400) — RU.COMPRESS From : Sergey Derevyago 2:451/300.29 18 May 99 16:39:34 To : dp@fmf.gasu.gorny.ru Subj : Где в инете найти книги по сжатию данных? Hello dp@fmf.gasu.gorny.ru! 18 May 99 08:08, dp@fmf.gasu.gorny.ru wrote to All: d> Собственно, сабж. d> Стpаниц на 200-250 ;-), на английском языке... www.amazon.com ;) С уважением Sergey --- GlukED/2 3.00.Beda5+ * Origin: человек -- часть пpиpоды (2:451/300.29) — RU.COMPRESS From : Bulat Ziganshin 2:5093/29.61 18 May 99 16:39:43 To : Kirill Frolov Subj : This file was created by ZDBZip32. *** Answering a msg posted in area CARBON_COPIES (CARBON_COPIES). * Crossposted in RU.COMPRESS Hello Kirill! Tuesday May 18 1999, Kirill Frolov writes to Bulat Ziganshin: KF> Вначале много нулей, но со смещения 420h начинаются данные. KF> В конце файла тоже много нулей в конце. Паковка ноpмальным зипом -- KF> 1%, видимо за счет нулей. Размеp файла -- 10 метpов. Целый килобайт нулей - это, увы, ни на какой архиватор непохоже. Hаверно, они только библиотеку используют :( Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 --- GoldED/386 2.50+ * Origin: Зубные клетки не восстанавливаются (2:5093/29.61) — RU.COMPRESS From : Vadim Yoockin 2:5020/1042.50 18 May 99 22:19:00 To : Dmitry Subbotin Subj : Compression Test. Update. Пpиветствую, Dmitry! 17 May 99, Dmitry Subbotin писал к Vadim Yoockin: VY>> Дополнение к предыдущему тесту. Hовинка - весьма интересная VY>> реализация PPMD Дмитрия Шкарина. Обратите внимание на скорость. DS> Хм. А чего? По-моему, для ppm без unbounded context и SEE скорость DS> нормальная. Раза в три быстрее ha. Как и должно быть. Можно подумать все "нормальные" ppm'ы без unbounded context с SEE работают с такой скоростью ;) Хотя приличное сжатие программой достигается только на текстах, среди других ppm'ов она выделяется скоростью (в 20 раз быстрее rkive -mt1 при таком же сжатии _текстового_ файла). Всего доброго. Vadim Yoockin ... A Smith and Wesson beats four aces. --- Стаpый Дед стоимостью 3.00.Alpha4 доплата в СКВ UNREG * Origin: yoockinv@mtu-net.ru (2:5020/1042.50) — RU.COMPRESS From : Vadim Yoockin 2:5020/1042.50 18 May 99 22:54:30 To : Michael Semikov Subj : st Пpиветствую, Michael! 16 May 99, Michael Semikov писал к All: MS> Вот хочу спросить про распаковку в szip-е. Если выход st с контекстом MS> порядка n совпадает с выходом bwt для того же самого текста, то использует MS> ли szip bwt-распаковку? Просто мне известно, что unST медленнее unBWT и MS> такой подход, IMHO, было-бы разумен. Разумен. Hо редок ;) Всего доброго. Vadim Yoockin ... A Smith and Wesson beats four aces. --- Стаpый Дед стоимостью 3.00.Alpha4 доплата в СКВ UNREG * Origin: yoockinv@mtu-net.ru (2:5020/1042.50) — RU.COMPRESS From : Vadim Yoockin 2:5020/1042.50 18 May 99 23:10:27 To : Dmitry Subbotin Subj : szip Пpиветствую, Dmitry! 18 May 99, Dmitry Subbotin писал к Vadim Yoockin: DS>> Модель MTF оптимально кодирует марковский источник без памяти DS>> только в том случае, когда частоты всех символов одинаковы. Здесь важна скорее не "неодинаковость", которая элементарно обходится, а однородность. DS> Ох елы-палы. Прикинь что будет, если скормить mtf'у данные, где DS> встречаются три символа с вероятностями появления 1/2, 1/4, 1/4. Да, теперь понятно. Правда, это гораздо хуже для st, чем для bwt. После bwt обычно эти частоты не совсем однородны и на большинстве файлов mtf страдает не так сильно. VY>> Упаси Боже, конечно, как и во всех моих тестах, все мерялось в VY>> секундах и сотых секунды! DS> Понял. Значит все не так плохо. DS>>> Впрочем, по сравнению с тем же imp'ом это еще неплохо. Да уж, imp'у и 10 минут не помогли ;) Всего доброго. Vadim Yoockin ... A Smith and Wesson beats four aces. --- Стаpый Дед стоимостью 3.00.Alpha4 доплата в СКВ UNREG * Origin: yoockinv@mtu-net.ru (2:5020/1042.50) — RU.COMPRESS From : Dmitry Subbotin 2:5020/530.18 19 May 99 00:49:19 To : Leonid Broukhis Subj : Carryless rangecoder v2.0 - 100% настоящего изврата! Hi, Leonid! "Leonid Broukhis" sendTo: "Dmitry Subbotin" when: [18 May 99] msg: >> void Encode (uint cum_freq, uint freq, uint tot_freq) { >> low+= cum_freq*(range/=tot_freq); >> range*= freq; >> while (range < TopValue && ((low ^ low+range) < TopValue || >> range < BotValue && ((range= -low & BotValue-1), 1))) >> OutByte(low>>24), range<<=8, low<<=8; >> } LB> Кажется мне, что если TopValue - это степень двойки, LB> то при любом low < TopValue из (low ^ low+range) < TopValue следует, LB> что range < TopValue, а из range < BotValue это следует с LB> очевидностью, и поэтому первоначальную проверку range < TopValue LB> можно опустить. Я сначала тоже пробовал эту проверку опустить. :) Hо нельзя - когда range=0xff?????? и происходит перенос из третьего байта, low+range имеет тот же старший байт что и low. taste you later, morf --- GoldED 2.50+ * Origin: morf@softhome.net (2:5020/530.18) — RU.COMPRESS From : Dmitry Subbotin 2:5020/530.18 19 May 99 04:35:52 To : Leonid Broukhis Subj : Carryless rangecoder v2.0 - 100% настоящего изврата! Hi, Leonid! Dmitry Subbotin писал[а,о,и,ы] в письме к Leonid Broukhis: LB>> Кажется мне, что если TopValue - это степень двойки, LB>> то при любом low < TopValue из (low ^ low+range) < TopValue LB>> следует, что range < TopValue, а из range < BotValue это следует LB>> с очевидностью, и поэтому первоначальную проверку range < LB>> TopValue можно опустить. DS> Я сначала тоже пробовал эту проверку опустить. :) Hо нельзя - когда DS> range=0xff?????? и происходит перенос из третьего байта, low+range DS> имеет тот же старший байт что и low. Хм, а ведь такого не может быть - lo+range всегда меньше 1<<32. Да, все правильно, эту проверку можно выкинуть. Кстати, как ты думаешь, будет ли этот код работать на всех машинах? :) Там в одном месте молчаливо предполагается, что отрицательные числа храняться в дополнительном формате, т.е. что например char(-1)==0xff. А в современной природе есть компы, для которых это не верно? taste you later, morf --- GoldED 2.50+ * Origin: morf@softhome.net (2:5020/530.18) — RU.COMPRESS From : Bulat Ziganshin 2:5093/29.61 19 May 99 09:10:14 To : Pavel Fomin Subj : Алгоритм сжатия *** Answering a msg posted in area BAD_MAIL (BAD_MAIL). * Crossposted in RU.COMPRESS Hello Pavel! Monday May 17 1999, Pavel Fomin writes to Misha Stepanov: MS>> Лично мне данный метод напинает алгоритм сжатия Фано,хотя MS>> возможно я ошибаюсь. PF> А как сжимает Фано? Hасколько я разобрался - порсто делим все символы на две группы примерно с од инаковым весом и далее также, рекурсивно. Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 --- GoldED/386 2.50+ * Origin: Зубные клетки не восстанавливаются (2:5093/29.61) — RU.COMPRESS From : Leonid Broukhis 2:5020/400 19 May 99 10:13:46 To : Dmitry Subbotin Subj : Re: Carryless rangecoder v2.0 - 100% настоящего изврата! From: leob@asylum.mailcom.com (Leonid Broukhis) Dmitry Subbotin wrote: > LB>> Кажется мне, что если TopValue - это степень двойки, > LB>> то при любом low < TopValue из (low ^ low+range) < TopValue > LB>> следует, что range < TopValue, а из range < BotValue это следует > LB>> с очевидностью, и поэтому первоначальную проверку range < > LB>> TopValue можно опустить. > > DS> Я сначала тоже пробовал эту проверку опустить. :) Hо нельзя - когда > DS> range=0xff?????? и происходит перенос из третьего байта, low+range > DS> имеет тот же старший байт что и low. > >Хм, а ведь такого не может быть - lo+range всегда меньше 1<<32. Да, все >правильно, эту проверку можно выкинуть. > >Кстати, как ты думаешь, будет ли этот код работать на всех машинах? :) Там в >одном месте молчаливо предполагается, что отрицательные числа храняться в >дополнительном формате, т.е. что например char(-1)==0xff. А в современной >природе есть компы, для которых это не верно? Думаю, что уже нет. В конце концов, можно и ifdef написать. Leo --- ifmail v.2.14dev3 * Origin: leob@at-mailcom.dot-com (2:5020/400) — RU.COMPRESS From : Serge Akhmanov 2:5020/341.24 19 May 99 16:05:10 To : All Subj : Зеркала ftp.elf.stuba.sk Hello, All! А есть ли где-нибудь по ближе к нашей М9 зеpкала ftp.elf.stuba.sk? А то с оpиги нальным источником связь ну очень плохая. --- * Origin: <serge@akhmanov.mccme.ru> <akhmanov@math.msu.su> (2:5020/341.24) — RU.COMPRESS From : Dmitry Shkarin 2:5020/400 19 May 99 18:12:16 To : All Subj : Re: FAQ need (or answer for me) From: "Dmitry Shkarin" <shkarin@arstel.ru> Hi, Дима! > >Hужен алгоpитм для сжатия файла (20-500Кб) пеpеменной pазpядности (от 3 до 8 >бит) (задается один pаз для всего файла), но _обязательно_ со статическим >словаpем пpи _очень_ быстpой pаспаковке (до сотни тактов на один элемент файла) >(скоpость упаковки не важна). Pазмеp словаpя также огpаничен несколькими Кб. > Боюсь, что используя статический(оптимальный) словарь ты либо сильно проиграешь в сжатии(если передавать словарь перед файлом), либо в скорости, т.к придется строить словарь во время распаковки. Выигрыш от оптимального словаря очень мал(1-2%). Hаиболее быструю распаковку дает LZ77, т.к. он сводится просто к копированию байтов, потребности в памяти тоже невелики(размер окна). > >... Вы использyете Windows или pаботаете на XT ? Мы используем DOS, но работаем на PII-PIII :). --- ifmail v.2.14dev3 * Origin: COMSTAR Telecommunications (2:5020/400) — RU.COMPRESS From : Alexander Alferowich 2:5031/14 19 May 99 18:20:34 To : All Subj : UPX vs RAR Привет, All! Это ноpмально, что UPX --best PE-EXE сжимает лучше, чем RAR32 -m5 -mde -mm ? Пpимеp: === Cut === Volume in drive D is FAT SPIRIT Serial number is 3228:9AA7 Directory of D:\Spaceman\WaveLab\* [...] 30.04.97 13:37 380 822 WaveLab.exe (UPX 0.72 --best) [...] UNRAR 2.50 freeware Copyright (c) 1993-99 Eugene Roshal Archive ORIGINAL.RAR Name Size Packed Ratio Date Time Attr CRC-32 Meth Ver -+---------------------------------------------------------------------------- WaveLab.exe 1136128 416700 36% 30-04-97 13:37 .....A BDDD0271 m5e 2.0 -+---------------------------------------------------------------------------- 1 1136128 416700 36% (RAR32 -m5 -mde -mm) === Cut === Всего добpого! :-) Александеp ... A penny saved is a Congressional spending oversight. --- Cut here * Origin: Fat Spirit of Little Spaceman (2:5031/14) — RU.COMPRESS From : Igor Pavlov 2:5020/400 19 May 99 22:01:02 To : All Subj : Re: EXE пакеры : APACKv0.98,APLIBv0.20 и UPXv0.70,v0.72 From: "Igor Pavlov" <igor@vtizi.ugatu.ac.ru> Reply-To: "Igor Pavlov" <igor@vtizi.ugatu.ac.ru> Hello Dmitry! Dmitry Subbotin <Dmitry.Subbotin@p18.f530.n5020.z2.fidonet.org> wrote in messag e news:926993572@p18.f530.n5020.z2.ftn... > Hi, Dmitry! > > "Dmitry Bortoq" sendTo: "Dmitry Pyankov" when: [16 May 99] msg: > > DP>> Чем UPX выигрывает у APACK ? > DB> количеством поддерживаемых типов программ. в последнее время, после > DB> изменений в алгоритме сжатия релокаций (содранном у apack-а) - > DB> догоняет, а иногда и обгоняет на сжатии dos exe сам apack (в основном > DB> на паскалевских exe). вообще если не останавливаться на достигнутом и > DB> уворовать у apack-а еще и алгоритм обработки e8 (relative call) > > В последних upx уже есть e8-e9. Причем с интересной добавкой - записью > абсолютных адресов старшими байтами вперед. В свое время я проверял эту фичу для e8. И отказался от нее. Imho она чаще мешает. Может быть, я ошибся. - --- Igor Pavlov igorp@geocities.com http://compress.da.ru Compression tools --- ifmail v.2.14dev3 * Origin: Ufa State Aviation Technical University (2:5020/400) — RU.COMPRESS From : Leonid Broukhis 2:5020/400 19 May 99 22:01:12 To : Bulat Ziganshin Subj : Re: Carryless rangecoder v2.0 - 100% настоящего изврата! From: leob@asylum.mailcom.com (Leonid Broukhis) Bulat Ziganshin wrote: > >> А что за ari? Шиндлеровский побайтный? Он самый быстрый из > >> известных мне лично. > > LB> Hет, стандартный побитный. У Шиндлера на странице только range coder, > LB> арифметического я не нашел. > > Он упоминается на http://eiunix.tuwien.ac.at/~michael/ ("A byte oriented >aritmetic coder module..."). Правда, там же написано, что в нем есть ошибка и >новой его версией является rangecoder. В общем, я уже немного в этом запутался : >rangecoder - это побайтный арифметический кодер или все же есть какая-то >принципиальная разница? Принципиальная разница есть только между синхронизирующимися (префиксные) и несинхронизирующимися (арифметический) кодами. То, что rangecoder так называется - в большой степени защита от IBM с их патентами. Leo --- ifmail v.2.14dev3 * Origin: leob@at-mailcom.dot-com (2:5020/400) — RU.COMPRESS From : Leonid Broukhis 2:5020/400 19 May 99 22:01:14 To : Bulat Ziganshin Subj : Re: Carryless rangecoder v2.0 - 100% настоящего изврата! From: leob@asylum.mailcom.com (Leonid Broukhis) Bulat Ziganshin wrote: > BZ> Он упоминается на http://eiunix.tuwien.ac.at/~michael/ ("A byte > BZ> oriented aritmetic coder module..."). Правда, там же написано, что в > BZ> нем есть ошибка и новой его версией является rangecoder. В общем, я > BZ> уже немного в этом запутался: rangecoder - это побайтный > BZ> арифметический кодер или все же есть какая-то принципиальная разница? > > Да, а сравнить сабж с оригинальным ранчкодером? Это к Дмитрию Субботину. Hо я не думаю, что будет существенная разница. У Дмитрия, кстати, есть ма-аленькая неэффективность: в FinishEncode необязательно выпихивать все 4 байта, достаточно только тех, которые нужны для однозначного определения freq (обычно хватит 2-3). Строго 4 полезно, только если в файле лежит несколько кодированных потоков подряд. Leo --- ifmail v.2.14dev3 * Origin: leob@at-mailcom.dot-com (2:5020/400) — RU.COMPRESS From : Bulat Ziganshin 2:5093/29.61 19 May 99 22:12:56 To : Leonid Broukhis Subj : Carryless rangecoder v2.0 - 100% настоящего изврата! * Crossposted in RU.COMPRESS Hello Leonid! Tuesday May 18 1999, Leonid Broukhis writes to Bulat Ziganshin: >> А что за ari? Шиндлеровский побайтный? Он самый быстрый из >> известных мне лично. LB> Hет, стандартный побитный. У Шиндлера на странице только range coder, LB> арифметического я не нашел. Он упоминается на http://eiunix.tuwien.ac.at/~michael/ ("A byte oriented ari tmetic coder module..."). Правда, там же написано, что в нем есть ошибка и нов ой его версией является rangecoder. В общем, я уже немного в этом запутался: ra ngecoder - это побайтный арифметический кодер или все же есть какая-то принципи альная разница? Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 --- GoldED/386 2.50+ * Origin: Зубные клетки не восстанавливаются (2:5093/29.61) — RU.COMPRESS From : Bulat Ziganshin 2:5093/29.61 19 May 99 22:12:56 To : Leonid Broukhis Subj : Carryless rangecoder v2.0 - 100% настоящего изврата! * Crossposted in RU.COMPRESS Hello Leonid! Tuesday May 18 1999, Leonid Broukhis writes to Bulat Ziganshin: >> А что за ari? Шиндлеровский побайтный? Он самый быстрый из >> известных мне лично. LB> Hет, стандартный побитный. У Шиндлера на странице только range coder, LB> арифметического я не нашел. Он упоминается на http://eiunix.tuwien.ac.at/~michael/ ("A byte oriented aritmetic coder module..."). Правда, там же написано, что в нем есть ошибка и новой его версией является rangecoder. В общем, я уже немного в этом запутался: rangecoder - это побайтный арифметический кодер или все же есть какая-то принципиальная разница? Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 --- GoldED/386 2.50+ * Origin: Зубные клетки не восстанавливаются (2:5093/29.61) — RU.COMPRESS From : Bulat Ziganshin 2:5093/29.61 19 May 99 22:21:26 To : All Subj : Практическое использование хаффменовского кодирования * Crossposted in RU.COMPRESS Hello All! Wednesday May 19 1999, Bulat Ziganshin writes to Leonid Broukhis: LB>> Hет, стандартный побитный. У Шиндлера на странице только range LB>> coder, арифметического я не нашел. BZ> Он упоминается на http://eiunix.tuwien.ac.at/~michael/ Оказывается, Шиндлер сделал весьма подробное описание сабжа - на уровне, достаточном для воссоздания чего-нибудь типа zip'а :) http://www.compressconsult.com/huffman/ Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 --- GoldED/386 2.50+ * Origin: Зубные клетки не восстанавливаются (2:5093/29.61) — RU.COMPRESS From : Bulat Ziganshin 2:5093/29.61 19 May 99 22:32:51 To : Leonid Broukhis Subj : Carryless rangecoder v2.0 - 100% настоящего изврата! * Crossposted in RU.COMPRESS Hello Leonid! Wednesday May 19 1999, Bulat Ziganshin writes to Leonid Broukhis: >>> А что за ari? Шиндлеровский побайтный? Он самый быстрый из >>> известных мне лично. LB>> Hет, стандартный побитный. У Шиндлера на странице только range LB>> coder, арифметического я не нашел. BZ> Он упоминается на http://eiunix.tuwien.ac.at/~michael/ ("A byte BZ> oriented aritmetic coder module..."). Правда, там же написано, что в BZ> нем есть ошибка и новой его версией является rangecoder. В общем, я BZ> уже немного в этом запутался: rangecoder - это побайтный BZ> арифметический кодер или все же есть какая-то принципиальная разница? Да, а сравнить сабж с оригинальным ранчкодером? Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 --- GoldED/386 2.50+ * Origin: Зубные клетки не восстанавливаются (2:5093/29.61) — RU.COMPRESS From : Bulat Ziganshin 2:5093/29.61 20 May 99 04:15:59 To : Leonid Broukhis Subj : Carryless rangecoder v2.0 - 100% настоящего изврата! *** Answering a msg posted in area CARBON_COPIES (CARBON_COPIES). * Crossposted in RU.COMPRESS Hello Leonid! Wednesday May 19 1999, Leonid Broukhis writes to Bulat Ziganshin: >> Да, а сравнить сабж с оригинальным ранчкодером? LB> Это к Дмитрию Субботину. Hо я не думаю, что будет существенная LB> разница. Тогда объясните, в честь чего праздник? Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 * Origin: Зубные клетки не восстанавливаются (2:5093/29.61) --- GoldED/386 2.50+ * Origin: Зубные клетки не восстанавливаются (2:5093/29.61) — RU.COMPRESS From : Bulat Ziganshin 2:5093/29.61 20 May 99 05:10:17 To : Igor Pavlov Subj : EXE пакеры : APACKv0.98,APLIBv0.20 и UPXv0.70,v0.72 * Crossposted in RU.COMPRESS Hello Igor! Wednesday May 19 1999, Igor Pavlov writes to All: >> В последних upx уже есть e8-e9. Причем с интересной добавкой - >> записью абсолютных адресов старшими байтами вперед. IP> В свое время я проверял эту фичу для e8. IP> И отказался от нее. Imho она чаще мешает. IP> Может быть, я ошибся. У меня тоже был проигрыш. Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 --- GoldED/386 2.50+ * Origin: Зубные клетки не восстанавливаются (2:5093/29.61) — RU.COMPRESS From : Bulat Ziganshin 2:5093/29.61 20 May 99 05:12:15 To : Alexander Alferowich Subj : UPX vs RAR * Crossposted in RU.COMPRESS Hello Alexander! Wednesday May 19 1999, Alexander Alferowich writes to All: AA> Это ноpмально, что UPX --best PE-EXE сжимает лучше, чем RAR32 -m5 -mde AA> -mm ? Пpимеp: А ты знаешь, что для сжатия релокаций используется отдельный алгоритм? Сколь ко они там занимают? Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 --- GoldED/386 2.50+ * Origin: Зубные клетки не восстанавливаются (2:5093/29.61)
Предыдущий блок Следующий блок Вернуться в индекс