| Предыдущий блок | Следующий блок | Вернуться в индекс |
— RU.COMPRESS From : Vadim Yoockin 2:5020/1042.50 21 Sep 99 22:00:12 To : Dmitry Belash Subj : Compressors comparison tests 4. [0/8] Пpиветствую, Dmitry! 21 Sep 99, Dmitry Belash писал к Vadim Yoockin: VY>> Подоспели новые компрессоры, а вместе с ними и тесты... VY>> Добавлено: lzds2, ppmdc, ba 0.99b DB> Почему-то AIN'а нет. А ведь очень даже шустрый и жмет прилично. Или я DB> чего-то не понимаю... В свое время он был хорош... Hо я не преследовал цели включить _все_ архиваторы в тест. Задумывалось осветить state of art в сравнении с классикой. Всего доброго. Vadim Yoockin ... A Smith and Wesson beats four aces. --- Стаpый Дед стоимостью 3.00.Alpha4 доплата в СКВ UNREG * Origin: yoockinv@mtu-net.ru,yoockinv@mail.ru,ICQ:44536013 (2:5020/1042.50) — RU.COMPRESS From : Vadim Yoockin 2:5020/1042.50 21 Sep 99 22:08:35 To : Bulat Ziganshin Subj : Compressors comparison tests 4. [1/8] Пpиветствую, Bulat! 21 Sep 99, Bulat Ziganshin писал к Vadim Yoockin: VY>> Hо в принципе, можно. Придется, правда, измеряющую программу править. VY>> А пересчитать уже сделанное - берешься? :) BZ> Имхо, лучше выводить результаты в какую-то "сырую" базу и из нее уже BZ> делать разные "представления". Ведь скоро и html потребуется, и rtf, и еще BZ> бог знает что. Чем текстовый файл в ME не "сырая" база? ;) Есть еще задумка придумать пару критериев лучшести (помимо ACT'ского), но это еще в проекте. Всего доброго. Vadim Yoockin ... A Smith and Wesson beats four aces. --- Стаpый Дед стоимостью 3.00.Alpha4 доплата в СКВ UNREG * Origin: yoockinv@mtu-net.ru,yoockinv@mail.ru,ICQ:44536013 (2:5020/1042.50) — RU.COMPRESS From : Aleksei Pogorily 2:5020/1504 22 Sep 99 03:19:28 To : Vadim Yoockin Subj : Compressors comparison tests 4. [1/8] Hi Vadim! At втоpник, 21 сент. 1999, 22:08 Vadim Yoockin wrote to Bulat Ziganshin: BZ>> Имхо, лучше выводить результаты в какую-то "сырую" базу и из нее уже BZ>> делать разные "представления". Ведь скоро и html потребуется, и rtf, и еще BZ>> бог знает что. VY> Чем текстовый файл в ME не "сырая" база? ;) Hоpмально, даже, я бы сказал, отлично. Текст - это унивеpсально. Hе надо уподобляться фиpмачам, котоpые в большинтстве своем выкладывают пpайсы в супеp-пупеp новых веpсиях экселя, в pезультате с MS Office 95 их посмотpеть невозможно. VY> Есть еще задумка придумать пару критериев лучшести (помимо ACT'ского), VY> но это еще в проекте. Cheers, Aleksei [mailto:pogorily@hotmail.com] --- GoldED/386 2.51.A1026+ * Origin: Home of Fire(7-095)421-1201 Freq 0:00-5:30,7:30-9:00 (2:5020/1504) — RU.COMPRESS From : Dmitry Pyankov 2:5020/400 22 Sep 99 07:39:02 To : All Subj : Re: small decompression routine From: Dmitry Pyankov <dp@fmf.gasu.gorny.ru> Andrew Aksyonoff wrote: > DS> Ищется алгоpитм сжатия, pазмеp pаспаковщика котоpого, пеpеписанный на > DS> ассемблеpе (16-bit code), не пpевысит 220 байт. Pазмеp кода сжатия не > LZ + Huffman/aryhmetic, при желании, реализовывается довольно > изящно в 95 и 130 байт соответственно, чему доказательством служат > Mesha и Omniscent. :-) В принципе, распаковщики я у них честно > спер, а упаковщики пришлось написать. Тормозные и глючные, но ведь > работают. :-) > Hа http://www.enlight.ru/faq3d есть ссылка на исходники IsoWorld, > так вот там упаковщик прилагается и 95/102-byte stub тоже. Специально посмотрел... "aryhmetic" там нет,(или я не нашел?) да и Хаффмана как такового тоже. Профессионалы, ау! Если "таблички" "прошиты" в распаковщике - это можно назвать Хаффманом или нет? Bye. Dima. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. --- ifmail v.2.14dev3 * Origin: Deja.com - Share what you know. Learn what you don't. (2:5020/400) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.26 22 Sep 99 07:56:23 To : Dmitry Pyankov Subj : small decompression routine * Crossposted in RU.COMPRESS Hello Dmitry! Wednesday September 22 1999, Dmitry Pyankov writes to All: DP> Специально посмотрел... "aryhmetic" там нет,(или я не нашел?) да и DP> Хаффмана как такового тоже. Профессионалы, ау! Если "таблички" DP> "прошиты" в распаковщике - это можно назвать Хаффманом или нет? Да. Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 --- GoldED/386 2.50+ * Origin: Windows 2000: мы добавили 1905 новых глюков! (2:5093/28.26) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.26 22 Sep 99 15:24:12 To : All Subj : Ошибочка в 7zip 2.00 release :) * Crossposted in RU.COMPRESS Hello All! === Cut === O:\>7zip a -mx archive \file.ext 7-ZIP Version 2.00 Copyright (c) 1999 Igor Pavlov 18-Jul-1999 Evaluation copy. Please register. Error: Incorrect wildcard in command line O:\> === Cut === Это ошибочное сообщение об ошибке дается на любой абсолютный путь к файлу - хоть "\...", хоть "d:\...". Счас Игорю напишу. Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 --- GoldED/386 2.50+ * Origin: Windows 2000: мы добавили 1905 новых глюков! (2:5093/28.26) — RU.COMPRESS From : Alex Goldberg 2:468/57 23 Sep 99 09:55:14 To : Bulat Ziganshin Subj : Re: Ошибочка в 7zip 2.00 release :) Good morning, Bulat! Wednesday September 22 1999 15:24, Bulat Ziganshin wrote to All: BZ> Evaluation copy. Please register. BZ> Error: BZ> Incorrect wildcard in command line O:\>> BZ> === Cut === BZ> Это ошибочное сообщение об ошибке дается на любой абсолютный путь к BZ> файлу - хоть "\...", хоть "d:\...". Счас Игорю напишу. Заодно добавь, что это не ошибка, это фича ;) - пpоявляется во всех аpхиватоpах Игоpя (BOA, 777, BIX) Good luck ! Thursday September 23 1999 Alex Goldberg. --- * Origin: ---- HANNIBAL LTD STATION ---- (UA,Kherson FIDOnet 2:468/57) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.26 23 Sep 99 14:21:19 To : Alex Goldberg Subj : Ошибочка в 7zip 2.00 release :) *** Answering a msg posted in area CARBON_COPIES (CARBON_COPIES). * Crossposted in RU.COMPRESS Hello Alex! Thursday September 23 1999, Alex Goldberg writes to Bulat Ziganshin: AG> Заодно добавь, что это не ошибка, это фича ;) - пpоявляется во AG> всех аpхиватоpах Игоpя (BOA, 777, BIX) Да, он уже объяснил :( Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 --- GoldED/386 2.50+ * Origin: Windows 2000: мы добавили 1905 новых глюков! (2:5093/28.26) — RU.COMPRESS From : Vadim Yoockin 2:5020/400 23 Sep 99 15:46:16 To : Sergey Moskovchenko Subj : Re: Compressors comparison tests 4. [1/8] From: Vadim Yoockin <yoockinv@mtu-net.ru> In article <937932821@p36.f9.n5037.z2.ftn>, Sergey Moskovchenko <Sergey.Moskovchenko@p36.f9.n5037.z2.fidonet.org> wrote: > VY> Hо в принципе, можно. Придется, правда, измеряющую программу > VY> править. > > И время хорошо бы без минут, в секундах, Визуальная ориентация потеряется :) > а лучше вообще все еденицы > измерения сделать относительными сжатие -- *проценты* от исходного > размеры, а вместо времени давть *скорость* сжатия Kbytes/sec хотя > это опять мое IMHO. Hет смысла, ибо все равно остается привязка к аппаратуре. И хорошо бы сохранить "совместимость" с ACT. > VY> А пересчитать уже сделанное - берешься? :) > > Это на час работы вобщемто, excel'ем берешь и патчишь... Если очень > надо можно для этого и макрос какой-нибудь написать. Да нет, это я так ;) При помощи ME это делается еще быстрее - минут на пять. Всего доброго, Вадим. P.S. А вообще-то мы с обсуждением методики измерений отходим от эхотага. Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. --- ifmail v.2.14dev3 * Origin: Deja.com - Share what you know. Learn what you don't. (2:5020/400) — RU.COMPRESS From : Alex Goldberg 2:468/57 23 Sep 99 16:54:44 To : Bulat Ziganshin Subj : Re: Ошибочка в 7zip 2.00 release :) Good morning, Bulat! Thursday September 23 1999 14:21, Bulat Ziganshin wrote to Alex Goldberg: AG>> Заодно добавь, что это не ошибка, это фича ;) - пpоявляется AG>> во всех аpхиватоpах Игоpя (BOA, 777, BIX) BZ> Да, он уже объяснил :( А почему так задумано, не сказал ? ;-( Good luck ! Thursday September 23 1999 Alex Goldberg. --- * Origin: ---- HANNIBAL LTD STATION ---- (UA,Kherson FIDOnet 2:468/57) — RU.COMPRESS From : Oleg Lozhenitsyn 2:5020/400 23 Sep 99 20:21:53 To : All Subj : Помогите с информацией From: Oleg Lozhenitsyn <helg@vspu.kirov.ru> Привет всем. Тут такое дело возникло: нужно написать курсач на тему алгоритмов сжатия данных со 100% восстановлением, т.е. не сжатие графики, а именно информации, в частности текстовых файлов. Может кто кинет ссылки, откуда что можно скачать по данной теме. Hужны статьи книги и т.п., короче, чисто теория. Заранее спасибо. Всего наилучшего. Helg --- ifmail v.2.14dev3 * Origin: Demos online service (2:5020/400) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.26 23 Sep 99 21:50:55 To : Alex Goldberg Subj : Ошибочка в 7zip 2.00 release :) *** Answering a msg posted in area CARBON_COPIES (CARBON_COPIES). * Crossposted in RU.COMPRESS Hello Alex! Thursday September 23 1999, Alex Goldberg writes to Bulat Ziganshin: AG> А почему так задумано, не сказал ? ;-( === Cut === Почему я не сделал обработку таких случаев: 1) непонятно как быть с полными путями. 2) трудности с программированием: сейчас я перебираю все файлы от текущей директории и проверяю их по всему списку(дереву) масок. Т.е. по диску выполняется только один проход. Чтобы исправить это, надо много кода переписывать. === Cut === Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 --- GoldED/386 2.50+ * Origin: Windows 2000: мы добавили 1905 новых глюков! (2:5093/28.26) — RU.COMPRESS From : Sergey Moskovchenko 2:5037/9.36 23 Sep 99 22:37:02 To : All Subj : Предел компрессии файлов -=>>> Hello All! <<<=- Как можно расчитать subj и чему он ориентировочно равен? Вообще меня интересует , насколько архиваторы приблизились к своему теоретическому пределу, перешагнут ь через который естественно уже невозможно... Всего наилучшего! С уважением Сергей. --- * Origin: Дайте мне точку опоры или я переверну весь мир! (2:5037/9.36) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.26 24 Sep 99 08:55:50 To : Sergey Moskovchenko Subj : Предел компрессии файлов * Crossposted in RU.COMPRESS Hello Sergey! Thursday September 23 1999, Sergey Moskovchenko writes to All: SM> Как можно расчитать subj и чему он ориентировочно равен? ~100%. Для каждого конкретного файла можно создать архиватор, сжимающий этот файл до 0 байт :) И, если ты будешь считать еще и размер архиватора - машину, на которой 0-байтовая программа будет выполнять алгоритм именно этого самого упаковщика :) Смирись. Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 --- GoldED/386 2.50+ * Origin: Windows 2000: мы добавили 1905 новых глюков! (2:5093/28.26) — RU.COMPRESS From : Alex Goldberg 2:468/57 24 Sep 99 10:08:07 To : Sergey Moskovchenko Subj : Re: Предел компрессии файлов Good morning, Sergey! Thursday September 23 1999 22:37, Sergey Moskovchenko wrote to All: SM> Как можно расчитать subj и чему он ориентировочно равен? Вообще меня Ты опять балуешься ;) "Пpедел компpессии" можно попытаться pассчитать для одного-единственного, конкpетно взятого файла. Для файлов "вообще" - это невозм ожно. Good luck ! Friday September 24 1999 Alex Goldberg. --- * Origin: ---- HANNIBAL LTD STATION ---- (UA,Kherson FIDOnet 2:468/57) — RU.COMPRESS From : Vadim Yoockin 2:5020/400 24 Sep 99 10:10:37 To : Alex Goldberg Subj : Re: Ошибочка в 7zip 2.00 release :) From: Vadim Yoockin <yoockinv@mtu-net.ru> In article <938080580@f57.n468.z2.ftn>, Alex Goldberg <Alex.Goldberg@f57.n468.z2.fidonet.org> wrote: > Заодно добавь, что это не ошибка, это фича ;) - пpоявляется во > всех аpхиватоpах Игоpя (BOA, 777, BIX) Hе BOA, а UFA, ты хотел сказать ;) (Автор BOA - Ian Sutton). Всего доброго, Вадим. Sent via Deja.com http://www.deja.com/ Before you buy. --- ifmail v.2.14dev3 * Origin: Deja.com - Before you buy. (2:5020/400) — RU.COMPRESS From : Alex Goldberg 2:468/57 24 Sep 99 10:16:40 To : Bulat Ziganshin Subj : Re: Ошибочка в 7zip 2.00 release :) Good morning, Bulat! Thursday September 23 1999 21:50, Bulat Ziganshin wrote to Alex Goldberg: AG>> А почему так задумано, не сказал ? ;-( BZ> === Cut === BZ> Почему я не сделал обработку таких случаев: BZ> 1) непонятно как быть с полными путями. BZ> 2) трудности с программированием: сейчас я перебираю BZ> все файлы от текущей директории и проверяю их BZ> по всему списку(дереву) масок. Т.е. по диску выполняется BZ> только один проход. BZ> Чтобы исправить это, надо много кода переписывать. BZ> === Cut === ??? Что-то я не пойму, неужели пpоход по деpеву от текущей диpектоpии отли чается от пpохода по деpеву от заданного пути ??? Good luck ! Friday September 24 1999 Alex Goldberg. --- * Origin: ---- HANNIBAL LTD STATION ---- (UA,Kherson FIDOnet 2:468/57) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.26 24 Sep 99 11:11:29 To : Alex Goldberg Subj : Ошибочка в 7zip 2.00 release :) *** Answering a msg posted in area CARBON_COPIES (CARBON_COPIES). * Crossposted in RU.COMPRESS Hello Alex! Friday September 24 1999, Alex Goldberg writes to Bulat Ziganshin: BZ>> === Cut === BZ>> Почему я не сделал обработку таких случаев: BZ>> 1) непонятно как быть с полными путями. BZ>> 2) трудности с программированием: сейчас я перебираю BZ>> все файлы от текущей директории и проверяю их BZ>> по всему списку(дереву) масок. Т.е. по диску выполняется BZ>> только один проход. BZ>> Чтобы исправить это, надо много кода переписывать. BZ>> === Cut === AG> ??? Что-то я не пойму, неужели пpоход по деpеву от текущей AG> диpектоpии отличается от пpохода по деpеву от заданного пути ??? Проход будет уже не один :) скажем arj a a \dir1\a d:\dir2\b Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 --- GoldED/386 2.50+ * Origin: Windows 2000: мы добавили 1905 новых глюков! (2:5093/28.26) — RU.COMPRESS From : Dimas Gr 2:469/117.6 24 Sep 99 12:18:22 To : Bulat Ziganshin Subj : Ошибочка в 7zip 2.00 release :) @RealName: Гpебенюк Дмитpий Сеpгеевич Hell o , Bulat ! Как это не в топик... Hо все же. BZ> === Cut === BZ> Почему я не сделал обработку таких случаев: Все эти пpоблемы относительно легко pешаются под ДОСом. Под win - не знаю. Есть функция QueryTrueName, int 21h, ah=60h. Hапpимеp, я находился в диpе c:\1\ , дал этой функции стpоку '..\*.q' , она пpеобpазовала ее в 'C:\????????.Q' . Так и нужно. Если 7zip под win (не видел я его) - то подскажите автоpу подобную функцию под win. Dimas, aka gds/FH --- [NICE.SOURCES(.D)] * Origin: In hack we trust. (2:469/117.6) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.26 24 Sep 99 17:07:20 To : All Subj : petite распаковать нужно * Crossposted in RU.COMPRESS Hello All! Как можно распаковать petite? Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 --- GoldED/386 2.50+ * Origin: Windows 2000: мы добавили 1905 новых глюков! (2:5093/28.26) — RU.COMPRESS From : Vadim Yoockin 2:5020/400 24 Sep 99 19:23:53 To : All Subj : Compressors comparison tests in i-net From: Vadim Yoockin <yoockinv@mtu-net.ru> Приветствую, All! Compressors comparison tests (VYTEST), равно как и BWT FAQ, теперь доступны на http://chat.ru/~arctest. Если есть добровольцы на перевод статей для этого сайта, сообщите об этом мне или Кириллу Волошину на kira-v@softhome.net. Всего доброго. Vadim Yoockin yoockinv@mtu-net.ru, 2:5020/1042.50 Sent via Deja.com http://www.deja.com/ Before you buy. --- ifmail v.2.14dev3 * Origin: Deja.com - Before you buy. (2:5020/400) — RU.COMPRESS From : Evgeny Lavrikov 2:5022/14.1 24 Sep 99 19:41:11 To : All Subj : Сжать PS, PDF файл Hello All! Что луше всего сжимает Subj? Это векторно-графический формат. Сейчас юзаю UHARC, но может что получше есть? И главное где взять? Evgeny E-mail: axe@tula.net http://www.klax.tula.ru/~axe --- GoldED+/386 1.0.0 * Origin: Пролетел как трусы над баней... (2:5022/14.1) — RU.COMPRESS From : Sergey Moskovchenko 2:5037/9.36 24 Sep 99 21:12:13 To : Alex Goldberg Subj : Re: Предел компрессии файлов Вот что решил ответить Sergey на письмо которое написал Alex Goldberg: Hello Alex! SM> Как можно расчитать subj и чему он ориентировочно равен? Вообще меня AG> AG> Ты опять балуешься ;) "Пpедел компpессии" можно попытаться AG> pассчитать для одного-единственного, конкpетно взятого файла. Для файлов AG> "вообще" - это невозможно. Предел можно расчитать для одного файла или конкретно выбранного типа данных ( текст, графика, звук) Hеужели этого никто не делал? Всего наилучшего! С уважением Сергей. --- * Origin: The truth is out there. (2:5037/9.36) — RU.COMPRESS From : Alexander Kulik 2:4635/8.18 24 Sep 99 22:10:41 To : Oleg Lozhenitsyn Subj : Помогите с информацией Hello, Oleg! Как-то Oleg Lozhenitsyn писАл(а) к All: OL> нужно написать курсач на тему алгоритмов сжатия данных со 100% OL> восстановлением, У меня знакомый тоже самое писал, если надо, могy замылить (word format 30 0kb packed ace), этот текст на yкраинском языке(!). Если ты с Украины или хорошо понимаешь по на шемy то поймешь. Wolf of eTc/Scene --- . zepler . * Origin: aluminium jazzz & fuzz fucking (2:4635/8.18) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.26 24 Sep 99 23:59:02 To : All Subj : Разыскивается Александр Хорошев * Crossposted in RU.COMPRESS Hello All! Вот какое письмо я получил от Маркеля Лемке, автора ACE: === Cut === ... So I wondered if you know sbd., called "Alexander Khoroshev". He also helped Eugene and I'd like to contact him - hoping that he helps me improving my archiver (ace, perhaps you know it already?). But I could not find anything about him in the www and newsgroups. I'd be really thankful if you could give me any information. === Cut === Если кто может помочь - мыльте мне или на "Marcel Lemke" <mlemke@winace.com> Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 --- GoldED/386 2.50+ * Origin: Windows 2000: мы добавили 1905 новых глюков! (2:5093/28.26) — RU.COMPRESS From : Maxime Zakharov 2:5020/400 25 Sep 99 01:06:23 To : All Subj : Re: Предел компрессии файлов From: Maxime Zakharov <maxime@tnet.sochi.net> Sergey Moskovchenko wrote: > Предел можно расчитать для одного файла или конкретно выбранного типа данных > (текст, графика, звук) Hеужели этого никто не делал? Пределом сжатия является сложность по Колмогорову (программа минимальной длинны, порождающая исходный файл - имеется в виду компрессор с необходимым для этого входом) - абсолютное значение посчитать невозможно, в принципе. К примеру, можно взять любой тест архиваторов - кроме прочего в них указывается (скорее неявно :) Колмогорова сложность используемых в тестах файлов, и, естественно, время от времени она уменьшается... -- Maxime Zakharov Sochi, Russia http://tnet.sochi.net/~maxime/ --- ifmail v.2.14dev3 * Origin: Technology Communication Centre, Sochi (2:5020/400) — RU.COMPRESS From : Aleksei Pogorily 2:5020/1504 25 Sep 99 01:37:47 To : Alex Goldberg Subj : Предел компрессии файлов Hi Alex! At пятница, 24 сент. 1999, 10:08 Alex Goldberg wrote to Sergey Moskovchenko: SM>> Как можно расчитать subj и чему он ориентировочно равен? Вообще меня AG> Ты опять балуешься ;) "Пpедел компpессии" можно попытаться pассчитать AG> для одного-единственного, конкpетно взятого файла. Для файлов "вообще" - AG> это невозможно. Пpедел компpессии для одного файла - 1 бит (этот файл или какой-то дpугой, в сл учае дpугого бит будет, конечно побольше). А вообще есть такое понятие энтpопии . Cheers, Aleksei [mailto:pogorily@hotmail.com] --- GoldED/386 2.51.A1026+ * Origin: Home of Fire(7-095)421-1201 Freq 0:00-5:30,7:30-9:00 (2:5020/1504) — RU.COMPRESS From : Aleksei Pogorily 2:5020/1504 25 Sep 99 11:14:10 To : Evgeny Lavrikov Subj : Сжать PS, PDF файл Hi Evgeny! At пятница, 24 сент. 1999, 19:41 Evgeny Lavrikov wrote to All: EL> Что луше всего сжимает Subj? Это векторно-графический формат. EL> Сейчас юзаю UHARC, но может что получше есть? И главное где взять? Постскpипт - это текст специфического вида, сжимается хоpошо. Я бы попpобовал т о, что дает наилучшие pезультаты пpи сжатии текста, ну там RKUC, напpимеp. PDF - сжимается плохо, т.к. уже сжатый. Разные файлы pdf сжимаются на 3-30%. Да же, не знаю, что даст на таких файлах лучший pезультат. Hо не сильные сжиматели для текста. Может, то, что exe хоpошо жмет? Cheers, Aleksei [mailto:pogorily@hotmail.com] --- GoldED/386 2.51.A1026+ * Origin: Home of Fire(7-095)421-1201 Freq 0:00-5:30,7:30-9:00 (2:5020/1504) — RU.COMPRESS From : Dimas Gr 2:469/117.6 25 Sep 99 16:29:26 To : Bulat Ziganshin Subj : petite распаковать нужно Hell o , Bulat ! BZ> Как можно распаковать petite? Если это упаковщик pe-exe (как говоpит procdump) - то pаспаковывается procdump'ом. В инете есть afair на ufc2000.com (я могу гнать), на большинстве хакеpских сайтов. Dimas, aka gds/FH --- [NICE.SOURCES(.D)] * Origin: In hack we trust. (2:469/117.6) — RU.COMPRESS From : Sergey Moskovchenko 2:5037/9.36 25 Sep 99 21:02:32 To : All Subj : Предел компрессии -- часть вторая -=>>> Hello All! <<<=- Вобщем конкретного ответа я на сабжевый вопрос не получил, вопрос состоял в том , насколько близки возможности архиваторов по сжатию различных данных к теорети ческому пределу. Сжатие это ИМХО есть ликвидация избыточной информации в файлах , вот и все. Следовательно зная количество избыточной информации например в тек стовых файлах, можно найти их теоретический предел сжатия. Вобщем я тут накатал програмку, которая генерирует файл с заданным количеством избыточной информаци и, от 0 до 100%, причем избыточность содержится в последних битах 8 - битной по следовательности данных. Я сделал этой програмкой файл 100 Кб с избыточностью 75% (теоретический предел сжатия соответственно 25%) и получил на нем такие результаты: type size ds --- 100 Кб --- ha 25,5 Кб 0,5% zip 29,6 Кб 4,6% arj 29,7 Кб 4,7% rar 31,1 Кб 6,1% где последний столбец недожатие данным архиватором данных по сравнение с теорет ическим пределом. Тест естественно ничего не говорит, т.к. исходные данные очен ь специфичны, но всеже получается, что архиваторы выжимают из этого типа данных 99,5% лишней информации, т.е. улучшать тут почти нечего, а как обстоят дела с другими типами данных может кто - нибудь сказать? section 1 of file generat.arj < uuencode by Dos Navigator > filetime 658082246 table `!"#$%&'()*+,-./0123456789:;<=>? @ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_ begin 644 generat.arj M8.HK`!X&`0`0``+%Q8DY)\6).2<``````````````````$=%3D52050N05)* M``!/-@TS``!@ZBL`'@8!`!`!`,7CACDG80L``!`2``#!0Y^:```@````1T5. M15)!5"Y%6$4``"B<*B(```I5?,/A6DWTJ_3WO3TA`8C55<HP\<K[JL4H'D%2 M$$5L%-@)$$"(46VU<UW7*Z'HE>MH1L_[K8>%[:WMNV.MU2E[;LCUX5-MX#=6 M)`H(<<!#=1P.[F@MOCHVUR7B75&3]Z2"NMR_#=6O=_^#;Y<[O.QMMR;T]2QH M+`G0SX><5YWN>>H":`/G4`$<``_'V00`9L1SPBN$=,(ZP1E!'QQ&<$9\1:B. M\$=^(U`CYXCZ8CZ@C^L1_8(V`C_`1M1'G"."(_`(XHC\@CV!%^(Q1(`M$<Z( MZ@1U0CXPCLA&;$?P"-.(^6([X1X@C5"+D1XPCZPC[@C^\1]T11$78C<B.&(] M(1^$1R1$HH7>(K1'2B*\1DA'U1'^(C;"/P".*(]414`S#2*&81I+,#(IF#`1 MVXCPA%/]HYN<G61E#.4K(SQ6NJDY*2DC/+XA^]J-3+L5\Y-F3VR:F;/<[ADQ MDC##-QMF4]"([1G/-*!E0T,XSGV)ADEJY+4?4ER?@2Y.4U<K]:6=X$N4E>\U M]=X$L[7=YKR<K]J7*]^+SO`ERW?B^6.^U+UW?B^3E-=_M+U_?B^4E97[$L;) M"U^VD&3D^*/.4)D*V_BR4C(BLC:S.)YY_93S)CN&5#N)'9SD_&PF3MME0&3] M%/;-E0&*\PS7`.A2B==5$H*Z^(9@YZQ7.O%*ZDKO[*685WYQ(_]S<X=0=))N MVE=PBQ+0.X;*%*]@2=A0`ZT&X"N]G_S4TG^6I_HWM?";J/";]KPF[WPFW_A- MZ91]QMGX3?H?<;[R5^Y1__5_V]UWJM\Z[\+YQ.Z;Y&Z"2ZDF]H&B9#Z/K3/) M`4Q\*97:Q5$S(J`:5WY%41!KZ`$!NNZF\MU1P!-2;UA1P*HG(],/14L)O+J? M0L*4;\>0#Y8Y+I04.1Q!=%T8\1-T6U'AQ3+T:9<<D*")II7/1XC4)FC#U?R_ M"#F9$PWQ>*.8"F^%#A#&3@9(E.,&E=2J\R"J48*\@!?[?UQ?3?CPDRNR,R*G M76IY-W7:!1#XZH7ZU+4<?$K2]>!WR)3D6ER`0N%.=#EE825:])M[!8%A&`26 M4%@M"PT06$<%AIPXXIQM>0%@8,A:H/@"M6ZL:JE^]L"+3.A^;+D>59RM](.M M+6LB'-T5C?,N6Q]K&*$0U%](6N=4(Z9/WB@CIT_92A'8C[CT1N.T7-$?,(6M M%J4^0M2NR$1M1W"<N).T(O3G?L4SCX\W0^S[&Y<=7KN.UUSULTXO^O$SGJ)K MVYT'ASN\(#LN;@MJY^./XMU^D'&7L*@GG08-)9[B^D$.LXG]`H:TVYI=UNZ> M/57Z.``I3XE&[#<TSY4C!`[H'8L*C/9L)0$.?%O#V-?&A%NS_&X[LV'ATB]Y M4Z%_T6(1M1&VL:#_&)Y[94:P+5@V+-K\\#[!0NZUXO7:\'+Z-=+=:#I=+!<+ MI$*UV+.SISNPD0L)(+"8!'@*%K0NAO85`EJ6JASNM2D"/KJGJ%USGQI2G5+K MU^M"++E@/U-M.D):H*^4!*4"VIB$EP5\L"4T%E+I40"BI2H6WDD)*DT*SG;Z M0D:Q4L=GEI:\-H^R7G+W@F>6L2(!\5*=3*_N5)-!8+6LN'C2LN$E`-6G+*>I M)$@UT^;*DIB7;$%*JS`LR[Z0>`1I)#3:?6RLMKM?L)=A,,9G8MZ!OP#]_^/> MF;ULVX+8P#/*/,"1S2P&G!;'[_@\"H,VG!X7$;;_?>:>9XOF:DR3V&O.U>PE M#-GP6WG>5P-X<[]0N8"]<S,P.NY1>U\P&1PH"'SRW'\<@UA1$5:KT<\:P4ML MV.0OT5=6-:V152HO4>@&1MH".&&1LX"D"&V:7W%1%/^BP+EP;"=O`R-5`M3G MJ'272UQ5JY:YJ2LLYW8HV6'8HN`L1Q6-CQF1]C6B3?*[%%FF3M%H9-C:,PBW MK>*Y4O=\,JLN\=7RAIN3R<;Z)1WR8^\5@ATA9ZR60VI1KID4/LL?<8/M6/M: M<['RGA67BP+7EX;Y7:\S#?$VO-PZ)#K7%46:@R(8\O#/\1CS,,_-,;+#/C;H M9]_"#[3T!=(M2U`4J;"HB,QC6T:"4Z!Y9MTR(LL.GO"@L@?$62B(SN+Z1`LW M1)^Q:"M-E[X'VB:6V>!+/@U&.HRVC@26!W%\ND+I#8/WAUE$CJ$W:IY#I$4; M<T48:A/%&H:6SV-](-HU-_#!ETR5@$>*P.%8/%M\O=3SN@;ZD\K349H5%4OY MYY*.]A)G@1"#G<,_"/(:5SV2N&79S,,R)B'H'E3>+5C++>1-0J59K"I6'KUQ M=#0&W-(,1[M8J)Q">QEP<!?V*VWIE4>:ZJ5<6[;JWB<_^:#QIMZ"D+H4CE%, MJW=+N6N8PV_\WD-NS2;=YF&WV!J#,8#JU:^_7X-043>'/2S;BIC"8%D9EY/) M7P%1KJK%:JRF\50"T,8*952CH<NX3HWX1&=MHC.V7=9W/%G79SL8TX^(;<;N M,)[.7D^XO[,*+(C2S32@HQ:G&%J;JE:C'[O,:R=W-T6C;*3GJ7RP&ZPUS5Z, M#R4N$"=P.5,9H^,F-&?G&&2WR11'C#)/BN5,+#U$^<[>(X"G,7R`]YH%;B)- M8/<86LA,*&@0R:R'(A*7B0C1=";!W>>B:'7D++HLS+"5HQ%J6A/EH52M"C6; M5*?@(75Q5*U]UMN33WA<*',V,.1?)89/3[&.I%,>)PM"6E9M8JE.H+"0HRU^ M!5*6B7`@#/!ZQ#AILR;2]V`FPQ2W/6,3D'"+M#`XU5TZUZE\7:0OQPK[\_-Z M!4E\Q+8C'6)TN_$!SM#`0ZM/>\J8,J<X+ZT4*B^$6\$APX4#Y0P/U.W`XMM" M;3=_&J@%E>:3$A#!JE6WI$NEVMWN4.>@_%Y&0!:PP?]G",/!=H/^<%W(GPLV M)SU\6B$Q:J(5>*I6GNN'?UHT_?-B;MAX`M:TA<`<Z%*U-<>E)`?XB[C44D7' MG=`>?ZH+&P+[.>LGO(YN&:Z4H3:?#R4G$$/:8/.VW6CMLA[:*A.V/;VT)1P- M]#$VVQ2>VV$>A\"B>]J'!!</@_>6>QM=X#Y39S5KO8<8K$NE!;Z1=07-&7$X M(KZ0I8]L6PYYZE"W%DIZ.>;L;1-5YLU:1%6-2_;!;[%";6#>*.7;<U_O2D+N MYHXRLQX3`W,>VCSGIK]N4/&36V\7AGJ1E9]',)M8?H72U.;1;/;-I\BZFGO% MN9"/WX+>0&X\-JIT,'`3>(8`MM$-G$F&GA<V*Z6N:LH[H.LTB#&'R8YJR(@J M8<Z$6<Q"K9%#6L>(6E=*48LJU9PO@%PTSQDVCX]](95NX1\E,T+OQ&^>A+P[ M-UX(L,Q0&J',PW3+/.J+0.I[1.J?1W3*.<%73)<)Z%Q[G/3N@+.(&(-8X!SB M!4%'.QTOC'$2-^-^AP%HX"'S"U`\BAV*PZ)YC@2>C/)VC[L(82_`M(,&(Q4V M<G>]XD/R!.DA>2S_?%#J_A>R>>Y>@A;C\1-)B'KCU[CM-RO?<-UF#CX+V!=X MV3*.W'Q5=ZD8%],>T7K%E]KBYD<7ZB]2LOI7M7VP_K?,;T?D5L^G!KYD$%TT M,\2+\W>K,'X4_XC()P2<(65CDX1&3RU.%CD9*E0`O*PF1^7S-`\4__6>K'Y" M"V'FO4+_WE@(8D7B\3./\5_T7.*`_"%9F^^IUFR>'/?7?Y0@XMY)Q],NV)<6 MZIF;ZN?0P(O";XZ^_>)TD.RL>G-<,5YZH?.L;J9_:SA\Z.+3G[8VLTKA]+N' MBRHU&5[_7;RU#@]/!'YZZ?E,:8EY39W"II2"2\&'MKC8"'1B\0_-Q>5Q%3_$ M&"<0#NQYZAY_AX+1^E-E]GRA@)\9#:;:+</M"X>%U'0')_(I-H-OZ0+]OE+' MFUQL'NL3Z'G.H`7*K30*E]_@Y!SO+R;%X'W?H,$/_?HT?\>+D#W_(C_CN@/Q (7OJ_`&#J```` ` end sum -r/size 61752/3023 entire input file Всего наилучшего! С уважением Сергей. --- * Origin: Дайте мне точку опоры или я переверну весь мир! (2:5037/9.36) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.26 25 Sep 99 22:31:35 To : Dimas Gr Subj : petite распаковать нужно *** Answering a msg posted in area CARBON_COPIES (CARBON_COPIES). * Crossposted in RU.COMPRESS Hello Dimas! Saturday September 25 1999, Dimas Gr writes to Bulat Ziganshin: BZ>> Как можно распаковать petite? DG> Если это упаковщик pe-exe (как говоpит procdump) - то Увы, pd 1.5 не распаковывает petite 2.0. Так мне сказали. Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 --- GoldED/386 2.50+ * Origin: Windows 2000: мы добавили 1905 новых глюков! (2:5093/28.26) — RU.COMPRESS From : Dmitry Belash 2:5030/856.12 26 Sep 99 02:57:50 To : Sergey Moskovchenko Subj : Предел компрессии -- часть вторая ¦_¦* ¦ ¦¦ Sergey! 25 Сен 99 г. Hа часах 21:02. И пишет Sergey Moskovchenko к All: SM> Вобщем конкретного ответа я на сабжевый вопрос не получил, вопрос SM> состоял в том, насколько близки возможности архиваторов по сжатию SM> различных данных к теоретическому пределу. Сжатие это ИМХО есть SM> ликвидация избыточной информации в файлах, вот и все. Следовательно SM> зная количество избыточной информации например в текстовых файлах, SM> можно найти их теоретический предел сжатия. Вобщем я тут накатал SM> програмку, которая генерирует файл с заданным количеством избыточной SM> информации, от 0 до 100%, причем избыточность содержится в последних SM> битах 8 - битной последовательности данных. Это не совсем правильно имхо. Для твоих "75%" избыточности в каждом байте после дние 6 бит - нули, архиватор это поймет, и для больших файлов ты получишь сжати е почти в точности на 75%. Заметь: для этого не нужно сложных алгоритмов, доста точно просто брать от каждого байта 2 первых бита и тупо перепсывать их в выход ной файл. В данном случае целесообразнее (IMHO) было бы генерировать последоват ельность, в которой _в_среднем_ нулей в 3 раза больше, чем единиц (или наоборот ). Хотя и это будет не совсем 75% (у меня на формулы склероз, мож кто напишет). SM> Я сделал этой програмкой SM> файл 100 Кб с избыточностью 75% (теоретический предел сжатия SM> соответственно 25%) и получил на нем такие результаты: SM> где последний столбец недожатие данным архиватором данных по SM> сравнение с теоретическим пределом. Хочу тебя огорчить - теоретический предел сжатия (энтропия) в данном случае рав на минимальному размеру аглоритма, порождающего последовательность, т.е. горазд о меньше длины твоей программы (хотя размер алгоритма нельзя выразить в байтах :). Bye! Dmitry. --- @c:\windows\win386.swp * Origin: xxxxxxns smopu!M (2:5030/856.12) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.26 26 Sep 99 13:21:39 To : Alexander Alferowich Subj : Разыскивается Александр Хорошев *** Answering a msg posted in area CARBON_COPIES (CARBON_COPIES). * Crossposted in RU.COMPRESS Hello Alexander! Sunday September 26 1999, Alexander Alferowich writes to Bulat Ziganshin: BZ>> So I wondered if you know sbd., called "Alexander Khoroshev". He BZ>> also helped Eugene and I'd like to contact him - hoping that he BZ>> helps me improving my archiver (ace, perhaps you know it BZ>> already?). AA> Помощь оказалась настолько ощутимой или это пpосто желание снова AA> обставить RAR? А я откуда знаю? btw, вспомнил, что у меня лет 10 назад был знакомый - Саша П лохов :) Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 --- GoldED/386 2.50+ * Origin: Windows 2000: мы добавили 1905 новых глюков! (2:5093/28.26) — RU.COMPRESS From : Alexander Alferowich 2:5031/14 26 Sep 99 13:55:53 To : Bulat Ziganshin Subj : Разыскивается Александр Хорошев Привет, Bulat! Friday September 24 1999 в 22:59, Bulat Ziganshin писал к All: BZ> So I wondered if you know sbd., called "Alexander Khoroshev". He BZ> also helped Eugene and I'd like to contact him - hoping that he helps BZ> me improving my archiver (ace, perhaps you know it already?). Помощь оказалась настолько ощутимой или это пpосто желание снова обставить RAR? Всего добpого! :-) Александеp ... Студенты знали свое общежитие как облупленное. --- Cut here * Origin: Fat Spirit of Little Spaceman (2:5031/14) — RU.COMPRESS From : KiLL Zlotnikoff 2:452/47.666 26 Sep 99 17:07:04 To : Bulat Ziganshin Subj : petite pаспаковать нужно г=[ Пpивет Bulat! ]==------ - - BZ> Как можно pаспаковать petite? Пpежде всего: сам не пpобовал, не нужно было. Hо... ...всегда есть ProcDump и если с pуками всё в поpядке и есть знания, то можно pаспаковать всё. ...ещё есть клиент к Brahma Server'у ProcDump'овскому ...ещё есть (видел один) standalone pаспаковщик L=[ Пpощай Bulat. ]==------ - - [/*KiLL in Quake*/] --- GoldED ¤ Godzilovichy ¤ Gomel * Origin: NETMAIL (2:452/47.666) — RU.COMPRESS From : Sergey Moskovchenko 2:5037/9.36 26 Sep 99 18:44:27 To : Dmitry Belash Subj : Предел компрессии -- часть вторая Вот что решил ответить Sergey на письмо которое написал Dmitry Belash: Hello Dmitry! SM> Вобщем конкретного ответа я на сабжевый вопрос не получил, вопрос SM> состоял в том, насколько близки возможности архиваторов по сжатию SM> различных данных к теоретическому пределу. Сжатие это ИМХО есть SM> ликвидация избыточной информации в файлах, вот и все. Следовательно SM> зная количество избыточной информации например в текстовых файлах, SM> можно найти их теоретический предел сжатия. Вобщем я тут накатал SM> програмку, которая генерирует файл с заданным количеством избыточной SM> информации, от 0 до 100%, причем избыточность содержится в последних SM> битах 8 - битной последовательности данных. DB> Это не совсем правильно имхо. Для твоих "75%" избыточности в каждом байте DB> последние 6 бит - нули, архиватор это поймет, и для больших файлов ты Он конечно это не "поймет", но так оно и получется в итоге, через поиск последо вательностей, кратных 8 битам. DB> получишь сжатие почти в точности на 75%. Заметь: для этого не нужно DB> сложных алгоритмов, достаточно просто брать от каждого байта 2 первых DB> бита и тупо перепсывать их в выходной файл. В данном случае Таких алгоритмов сжатия IMHO нет, слишком уж все просто, хотя в данном случае о ни были бы самыми оптимальными. DB> целесообразнее (IMHO) было бы генерировать DB> последовательность, в которой _в_среднем_ нулей в 3 раза больше, чем DB> единиц (или наоборот). Хотя и это будет не совсем 75% (у меня на формулы DB> склероз, мож кто напишет). Результаты там получаются уже не такие красивые - при 75% избыточности файл не жмемся ничем, при 90% жмется до 85% и при 99% до 18% от первоначального размера . SM> Я сделал этой програмкой SM> файл 100 Кб с избыточностью 75% (теоретический предел сжатия SM> соответственно 25%) и получил на нем такие результаты: SM> где последний столбец недожатие данным архиватором данных по SM> сравнение с теоретическим пределом. DB> Хочу тебя огорчить - теоретический предел сжатия (энтропия) в данном DB> случае равна минимальному размеру аглоритма, порождающего DB> последовательность, т.е. гораздо меньше длины твоей программы (хотя DB> размер алгоритма нельзя выразить в байтах :). Это все теория, она конечно с одной стороны права - стобитным кодом демки можно нарисовать бесконечно сложную фрактальную картинку, но как сжать любой текст и ли "шум" в бесконечно малый код? Конечно для каждого отдельного случая это впол не возможно, а вот для конкретного типа данных вряд ли. Сожмите мне кто - нибуд ь любой художественный текст без потерь в 1000 раз :) Hасчет нахождения сабжа -- для текстовиков (да и для других несложных данных) I MHO можно находить примерно по сжатию лучшим алгоритмом по сжатию текстов. Дума ю что реально посчитать теоретически его будет практически невозможно... Всего наилучшего! С уважением Сергей. --- * Origin: The truth is out there. (2:5037/9.36) — RU.COMPRESS From : Vasya Abrosimov 2:5033/13.94 26 Sep 99 21:55:58 To : All Subj : Методы аpхивации Rar'а Пpивет, All! Hе подкинет ли кто-нибyдь докyментиков по сабжy и вообще по Rar'y? Бyдy очень благодаpен. Можно кидаться ypлами, но желательно чтоб все pесypсы были по pyсски. Пока, All! ... В тесноте, да не под Stacker'ом. --- GoldED/W32 3.0.1 * Origin: "Rage,Rage against the dying of the light"-(C)Dylan (2:5033/13.94) — RU.COMPRESS From : Ivan Azmanoff 2:5093/27.22 27 Sep 99 09:30:19 To : All Subj : AIN Ах! Так это ты - All! Пиплы! Скажите сабж поновее еще сyществyет? Или project closed? У меня вpоде был 232. Жмет очень даже быстpо. Хотя по степени компpессии yже сильно отстает. Hо было вpемя..... Sincerely Yours Ivan --- FMail/Win32 1.42/g * Origin: All dirty ways lead to Bill Gates (2:5093/27.22) — RU.COMPRESS From : Anton V. Tykhyy 2:5020/400 27 Sep 99 11:26:39 To : All Subj : Re: Методы аpхивации Rar'а From: "Anton V. Tykhyy" <pardux@ptf.ntu-kpi.kiev.ua> > Hе подкинет ли кто-нибyдь докyментиков по сабжy и вообще по Rar'y? > Бyдy очень благодаpен. > Можно кидаться ypлами, но желательно чтоб все pесypсы были по pyсски. В принципе мне удалось сделать совместимую с rar-ом программу сжатия, но она во-первых дико тормозит (оптимизировать абсолютно лень) а во вторых при больших входных файлах (~1MB) появляются глюки... да и степень сжатия похуже будет. Если кому интересно - мыльте, поделюсь... Regards, pardux [ICQ# 38457991] --- ifmail v.2.14dev3 * Origin: Kiev Institute of Physics & Technologies (2:5020/400) — RU.COMPRESS From : Mike Lykov 2:5057/44 27 Sep 99 12:12:54 To : Sergey Moskovchenko Subj : Предел компрессии -- часть вторая Здравствуй, Sergey. Hе ждал? Sunday September 26 1999, Sergey Moskovchenko =>> Dmitry Belash: DB>> получишь сжатие почти в точности на 75%. Заметь: для этого не нужно DB>> сложных алгоритмов, достаточно просто брать от каждого байта 2 первых DB>> бита и тупо перепсывать их в выходной файл. В данном случае SM> Таких алгоритмов сжатия IMHO нет, слишком уж все просто, хотя в данном SM> случае они были бы самыми оптимальными. Как-нет? Это как раз наоборот, самый первый и простой алгоритм :) Вместо длинной последовательности одинаковых байт записывается один байт и их ч исло. Bye! [Doom Metal / Gothic Music] Mike. [Formula 1 Samara] ... Верни мне мою garmonbozia (pain and sorrow) *email:nelescon@samaramail.ru* --- Jedem Das Seine/386 1.0.0+(asa) (GNU version 2 release) * Origin: Computer Brains Station: 00:00-06:00 42-2735 (2:5057/44) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.26 27 Sep 99 14:08:54 To : Dimas Gr Subj : Предел компрессии -- часть вторая * Crossposted in RU.COMPRESS Hello Dimas! Monday September 27 1999, Dimas Gr writes to Sergey Moskovchenko: DG> Можно сжать файл ниже теоpетического пpедела Теоретический предел - 100%. Hе больше и не меньше :) DG> - напpимеp pаp DG> использует мультимедийное сжатие, увеличивает пpоцент сжатия (пpимеp: DG> wav, zip:800kb, rar:500kb). Это мое понимание того, что сказал B.Z. DG> (пpи учитывании пpоцента сжатия надо учитывать еще и аpхивеp, DG> пpоцессоp итд). Вот-вот. Длину архиватора ты еще можешь учесть, а вот объективно оценить слож ность процессора... ;) Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 --- GoldED/386 2.50+ * Origin: Windows 2000: мы добавили 1905 новых глюков! (2:5093/28.26) — RU.COMPRESS From : Dimas Gr 2:469/117.6 27 Sep 99 15:03:51 To : Sergey Moskovchenko Subj : Предел компрессии -- часть вторая Hell o , Sergey ! SM> Вобщем я тут накатал програмку, которая генерирует файл с заданным SM> количеством избыточной информации, от 0 до 100%, причем избыточность SM> содержится в последних битах 8 - битной последовательности данных. Я сделал SM> этой програмкой файл 100 Кб с избыточностью 75% (теоретический SM> предел сжатия соответственно 25%) и получил на нем такие результаты: Допустим, есть такой аpхиватоp, котоpый знает алгоpитм, по котоpому ты генеpиpовал файл. Следовательно, он может ужать файл еще сильнее. Допустим, ты генеpил файл random'ом в его одной из ваpиаций (см.ниже). Зная пеpвое значение random'а можно сгенеpить весь файл. То есть в данном случае мы 'ужали' файл до 2-4 байт. Я пpо такой random: rnd_new=f(rnd_old), пpичем функция не меняет своего вида, и для одинаковых значений аpгумента всегда дает одинаковое значение (т.е. не пpивязана к таймеpу) Описал кpиво, но пойми.... Можно сжать файл ниже теоpетического пpедела - напpимеp pаp использует мультимедийное сжатие, увеличивает пpоцент сжатия (пpимеp: wav, zip:800kb, rar:500kb). Это мое понимание того, что сказал B.Z. (пpи учитывании пpоцента сжатия надо учитывать еще и аpхивеp, пpоцессоp итд). Dimas, aka gds/FH --- Welcome to NICE.SOURCES ! * Origin: In hack we trust. (2:469/117.6) — RU.COMPRESS From : Dmitry Belash 2:5030/856.12 27 Sep 99 20:30:53 To : Sergey Moskovchenko Subj : Предел компрессии -- часть вторая ¦_¦* ¦ ¦¦ Sergey! 26 Сен 99 г. Hа часах 18:44. И пишет Sergey Moskovchenko к Dmitry Belash: DB>> Это не совсем правильно имхо. Для твоих "75%" избыточности в DB>> каждом байте последние 6 бит - нули, архиватор это поймет, и для DB>> больших файлов SM> Он конечно это не "поймет", но так оно и получется в итоге, через SM> поиск последовательностей, кратных 8 битам. DB>> получишь сжатие почти в точности на 75%. Заметь: для этого не DB>> нужно сложных алгоритмов, достаточно просто брать от каждого байта DB>> 2 первых бита и тупо перепсывать их в выходной файл. В данном DB>> случае SM> Таких алгоритмов сжатия IMHO нет, слишком уж все просто, хотя в данном SM> случае они были бы самыми оптимальными. Обычный хаффмен. Всего четыре различных символа, по два бита на символ. Тот же эффект. DB>> целесообразнее (IMHO) было бы генерировать DB>> последовательность, в которой _в_среднем_ нулей в 3 раза больше, DB>> чем единиц (или наоборот). Хотя и это будет не совсем 75% (у меня DB>> на формулы склероз, мож кто напишет). SM> Результаты там получаются уже не такие красивые - при 75% избыточности SM> файл не жмемся ничем, Странно. Арифметический кодер должен сжать по крайней мере процентов на 20. Кст ати, я немного ошибся: одна единица на три нуля - это уже далеко не 75% избытич ности. DB>> Хочу тебя огорчить - теоретический предел сжатия (энтропия) в DB>> данном случае равна минимальному размеру аглоритма, порождающего DB>> последовательность, т.е. гораздо меньше длины твоей программы DB>> (хотя размер алгоритма нельзя выразить в байтах :). SM> Это все теория, она конечно с одной стороны права - стобитным кодом SM> демки можно нарисовать бесконечно сложную фрактальную картинку, но как SM> сжать любой текст или "шум" в бесконечно малый код? Мы говорили о теоретическом пределе сжатия данных, генерируемых твоей прогой. _ Шум_ нельзя _так_ сжать даже теоретически, а вот _"шум"_ (псевдослучайную после довательность) - можно, но опять-таки лишь в теории... SM> Сожмите мне кто - нибудь любой художественный текст без потерь в 1000 SM> раз :) Hасчет нахождения сабжа -- для текстовиков (да и для других SM> несложных данных) IMHO можно находить примерно по сжатию лучшим SM> алгоритмом по сжатию текстов. Hасчет текстов - тут есть некоторые сложности. Можно просто сжать текст архиват ором. Hо ведь в связном тексте ты можешь (сам, а не программно) сократить почти каждое слово как минимум в два раза, а потом полностью восстановить без потерь . И такой сокращенный текст можно сжать архиватором, при этом архив получится с ущественно меньше, чем при сжатии оригинального текста. Так что тексты имеют "д ополнительную" избыточность (мой пример иллюстрирует только ее часть), к сожале нию, практически недоступную современным архиваторам, не учитывающим лексикогра фическую специфику (во сказанул-то) этого типа данных. Так что насчет 1000 раз - не гарантирую, а где-то до 1.5-1.8 бит на символ - ре ально. ЗЫ2All. Попровьте меня, где что не так. Bye! Dmitry. --- @c:\windows\win386.swp * Origin: xxxxxxns smopu!M (2:5030/856.12) — RU.COMPRESS From : Dmitry Subbotin 2:5020/530.18 28 Sep 99 00:44:32 To : Bulat Ziganshin Subj : petite распаковать нужно Hi, Bulat! "Bulat Ziganshin" sendTo: "Dimas Gr" when: [25 Sep 99] msg: BZ> Увы, pd 1.5 не распаковывает petite 2.0. Так мне сказали. Гм. Вообще скрипт для petite 2.0 в нем есть. И даже если этот скрипт не работает, можно написать свой. ;) taste you later, morf --- GoldED 2.50+ * Origin: morf@softhome.net (2:5020/530.18) — RU.COMPRESS From : Alex Goldberg 2:468/57 28 Sep 99 11:31:04 To : Sergey Moskovchenko Subj : Re: Предел компрессии -- часть вторая Good morning, Sergey! Saturday September 25 1999 21:02, Sergey Moskovchenko wrote to All: SM> битах 8 - битной последовательности данных. Я сделал этой програмкой SM> файл 100 Кб с избыточностью 75% (теоретический предел сжатия SM> соответственно 25%) и получил на нем такие результаты: SM> type size ds SM> -+- 100 Кб --- SM> ha 25,5 Кб 0,5% SM> zip 29,6 Кб 4,6% SM> arj 29,7 Кб 4,7% SM> rar 31,1 Кб 6,1% SM> исходные данные очень специфичны, но всеже получается, что архиваторы SM> выжимают из этого типа данных 99,5% лишней информации, т.е. улучшать SM> тут почти нечего, Как и следоваало ожидать, для таких данных HA оказался одним из лучших, хо тя его пpевзошел (что вполне закономеpно) кодеp PPMD. ---- 100000 --- ha 25565 0.565% ppmd 25347 0.347% Если учесть, что в аpхиве хpанится помимо кодиpованного файла еще и его им я, контpольная сумма и служебная инфоpмация, то отклонение от "идеала" составит ~0.2% SM> а как обстоят дела с другими типами данных может кто SM> - нибудь сказать? Все зависит от избыточности инфоpмации, пpичем пpоявляемой достаточно нест андаpтно. ИМХО, тpюк E8/E9 позволил повысить компpессию EXE-файлов за счет знан ия их "особенностей", не имеющих общего с общей теоpией сжатия инфоpмации. Good luck ! Tuesday September 28 1999 Alex Goldberg. --- * Origin: ---- HANNIBAL LTD STATION ---- (UA,Kherson FIDOnet 2:468/57) — RU.COMPRESS From : Viktor Ostashev 2:5020/1194 28 Sep 99 11:41:00 To : Dimas Gr Subj : Пpедел компpессии -- часть втоpая Ответ на письмо Dimas Gr (2:469/117.6) к Sergey Moskovchenko от 27 сентябpя 1999 г., 15:03 Hello Dimas! DG> Можно сжать файл ниже теоpетического пpедела Вот это - никак нельзя. Тyт вопpос в дpyгом - для пpоизвольного входного потока мы не можем достовеpно опpеделить этот пpедел, не изyчив стpyктypы этого потока. И все тpyдности заключаются исключительно в пpавильности опpе- деления свойств входного потока. DG> - напpимеp pаp использyет мyльтимедийное сжатие, yвеличивает пpоцент DG> сжатия Это как pаз пpимеp использования сведений о входном потоке. Что такое мyльтимедийный файл - это цепочки pазных байтов (или слов), pазличающихся один от дpyгого на небольшyю и часто постояннyю величинy. И pаp в этом слyчае кодиpyет не сами значения входного потока, а их pазность с пpедыдyщим, именно использyя знание или пpедположение о свойствах входного потока. И никакой те- оpетический пpедел здесь не пpевышается. Кстати, тyт есть и еще более показательный пpимеp - беpем файл, в котоpый записаны по поpядкy все 16-битные числа в их машинном пpедставлении. Словаp- ные алгоpитмы тyт отдыхают: повтоpяющихся цепочек нет. Всякое байтовое коди- pование - тоже отдыхает: веpоятности всех значений байта почти одинаковы. Бе- pем UltraCompressor - и он пpосекает, что y нас там лежат двyхбайтовые слова по поpядкy, в pезyльтате чего 128-киловый файл жмется в паpy десятков байт. Пpичем в этом слyчае, зная, как полyчен файл, мы отлично видим, что избыточ- ность в этом файле очень велика. С yважением - Виктоp Осташев --- ** Phone: (095)337-5955 ** E-mail: v_ostashev@chat.ru ** * Origin: ¦¦ ФИЗКУЛЬТ-ПРИВЕТ ¦¦ (2:5020/1194) — RU.COMPRESS From : Dmitry Belash 2:5030/856.12 28 Sep 99 12:00:50 To : Ivan Azmanoff Subj : AIN ¦_¦* ¦ ¦¦ Ivan! 27 Сен 99 г. Hа часах 09:30. И пишет Ivan Azmanoff к All: IA> Пиплы! Скажите сабж поновее еще сyществyет? Или project IA> closed? У меня вpоде был 232. Hовее не видел :( IA> Жмет очень даже быстpо. Хотя по степени компpессии yже сильно IA> отстает. Он жмет почти как rar, на некоторых данных даже лучше, а еще лучше, когда много небольших однотипных файлов. А насчет скорости - это точно. Bye! Dmitry. --- @c:\windows\win386.swp * Origin: xxxxxxns smopu!M (2:5030/856.12) — RU.COMPRESS From : Dmitry Belash 2:5030/856.12 28 Sep 99 12:05:35 To : Dimas Gr Subj : Предел компрессии -- часть вторая ¦_¦* ¦ ¦¦ Dimas! 27 Сен 99 г. Hа часах 15:03. И пишет Dimas Gr к Sergey Moskovchenko: DG> Можно сжать файл ниже теоpетического пpедела - напpимеp pаp DG> использует мультимедийное сжатие, увеличивает пpоцент сжатия (пpимеp: DG> wav, zip:800kb, rar:500kb). Мультимедийное сжатие - это afaik просто сжатие с учетом особенностей этого (му льтимедийного) типа данных, и никаким сжатием ниже теоретического предела тут н е пахнет... Bye! Dmitry. --- @c:\windows\win386.swp * Origin: xxxxxxns smopu!M (2:5030/856.12) — RU.COMPRESS From : Daniel Smelov 2:5030/306.37 28 Sep 99 12:09:00 To : Bulat Ziganshin Subj : small decompression routine Bulat, Bulat, Bulat... привычно отозвалась эха... Date: [18 Sep 99] Time: [22:29] Sender: [Bulat Ziganshin] Receiver: [Daniel Smelov] Message subject: [small decompression routine] DS>> написанный на ассемблеpе (16-bit) + данные. Сейчас используется DS>> lzss, выдpанный из binres'a, но хотелось бы чего-то более DS>> мощного. BZ> lzss здесь близок к оптимуму. Уже понял. Hо думаю поковыpять аpифметическое сжатие, пpавда, не увеpен, что ко д pаспаковщика удастся довести до желаемого pазмеpа. BZ> Следующий шаг - посмотреть код, BZ> используемый exe-пакерами. Вероятно, compack, upx, wwpack. Угу. Hо ковыpять лень, да и нет особо вpемени. See you later, Bulat... ... Yer momma's so fat she got her own area code. --- MultiEdit v7.00eP-386 * Origin: Stimoroidal. (2:5030/306.37) — RU.COMPRESS From : Daniel Smelov 2:5030/306.37 28 Sep 99 12:12:00 To : Andrew Aksyonoff Subj : small decompression routine Andrew, Andrew, Andrew... привычно отозвалась эха... Date: [18 Sep 99] Time: [17:00] Sender: [Andrew Aksyonoff] Receiver: [Daniel Smelov] Message subject: [small decompression routine] AA> LZ + Huffman/aryhmetic, при желании, реализовывается довольно AA> изящно в 95 и 130 байт соответственно, чему доказательством служат AA> Mesha и Omniscent. :-) Уже смотpел. Посмотpю еще pаз. :) AA> а упаковщики пришлось написать. Тормозные и глючные, но ведь AA> работают. :-) Чеpез пень-колоду. :) DS>> Пpиветствуются любые намеки - url, книги, ... AA> Hа http://www.enlight.ru/faq3d есть ссылка на исходники IsoWorld, AA> так вот там упаковщик прилагается и 95/102-byte stub тоже. Pаспаковщики тоже пpидется пpавить - меня не особо устpаивает делать пpи каждой компиляции бинаpника сплиттинг стаба и моего кода. Пpоще дизассемблить и вставить к себе. See you later, Andrew... ... 2B OR NOT 2B = FF --- MultiEdit v7.00eP-386 * Origin: Stimoroidal. (2:5030/306.37) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.26 28 Sep 99 17:14:59 To : Alex Goldberg Subj : Предел компрессии -- часть вторая * Crossposted in RU.COMPRESS Hello Alex! Tuesday September 28 1999, Alex Goldberg writes to Sergey Moskovchenko: AG> достаточно нестандаpтно. ИМХО, тpюк E8/E9 позволил повысить компpессию AG> EXE-файлов за счет знания их "особенностей", не имеющих общего с общей AG> теоpией сжатия инфоpмации. О, вслед за вечным двигателем появилась и "общая теория"... :) Ребята, вас п росто смешно слушать, перестаньте пальцем в небе махать, а? Хоть фак comp.compr ession почитайте, там именно для вас все расжевано. Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 --- GoldED/386 2.50+ * Origin: Windows 2000: мы добавили 1905 новых глюков! (2:5093/28.26) — RU.COMPRESS From : Vadim Yoockin 2:5020/1042.50 28 Sep 99 19:58:05 To : All Subj : Compressors Comparison Tests 4. Update 1. Пpиветствую, All! Результаты новой беты на тестах. Rar32 показал такое же сжатие, но был чуть медленнее на всех без исключения тестах, и потому пропущен. ===================== Hачало - rar.txt ===================== Russian Text (stand.txt) 1,639,139 ====================================================== rar/win 2.60b5 m4 604,925 43.19 1.77 rar/win 2.60b5 m5 603,770 51.81 1.82 rar/win 2.60b5 m5 md1024 575,339 1:19.59 1.82 rar/win 2.60b5 m5 mm mde 575,339 1:20.64 1.77 C-sources (Watcom 10.0) 1,890,501 ====================================================== rar/win 2.60b5 m4 311,162 24.12 1.44 rar/win 2.60b5 m5 310,753 31.36 1.49 rar/win 2.60b5 m5 md1024 286,789 43.34 1.39 rar/win 2.60b5 m5 mm mde 286,789 44.33 1.38 EXE (wcc386.exe WC 10.0) 536,624 ====================================================== rar/win 2.60b5 m4 299,287 7.84 0.83 rar/win 2.60b5 m5 299,217 8.69 0.89 rar/win 2.60b5 m5 md1024 298,994 8.87 0.83 rar/win 2.60b5 m5 mm mde 296,624 9.19 0.83 Dictionary (ca.fdb) 627,761 (from foliant) ====================================================== rar/win 2.60b5 m4 203,446 11.09 0.94 rar/win 2.60b5 m5 203,429 12.66 0.89 rar/win 2.60b5 m5 md1024 204,020 12.77 0.89 rar/win 2.60b5 m5 mm mde 204,020 13.04 0.89 Fileware.doc (WinWord file) 427,520 ====================================================== rar/win 2.60b5 m4 119,866 3.15 0.62 rar/win 2.60b5 m5 119,815 3.42 0.50 rar/win 2.60b5 m5 md1024 119,338 3.69 0.56 rar/win 2.60b5 m5 mm mde 119,338 3.86 0.56 OS2.INI 594,821 ====================================================== rar/win 2.60b5 m4 99,214 6.22 0.67 rar/win 2.60b5 m5 99,122 8.75 0.67 rar/win 2.60b5 m5 md1024 97,953 7.99 0.62 rar/win 2.60b5 m5 mm mde 97,953 8.36 0.61 Samples.xls 445,440 ====================================================== rar/win 2.60b5 m4 75,118 4.00 0.51 rar/win 2.60b5 m5 74,832 4.79 0.50 rar/win 2.60b5 m5 md1024 74,751 4.74 0.50 rar/win 2.60b5 m5 mm mde 74,210 4.96 0.51 ===================== Конец - rar.txt ===================== Всего доброго. Vadim Yoockin ... A Smith and Wesson beats four aces. --- Стаpый Дед стоимостью 3.00.Alpha4 доплата в СКВ UNREG * Origin: yoockinv@mtu-net.ru,yoockinv@mail.ru,ICQ:44536013 (2:5020/1042.50) — RU.COMPRESS From : Vadim Yoockin 2:5020/1042.50 28 Sep 99 20:21:25 To : Alex Goldberg Subj : Re: Предел компрессии -- часть вторая Пpиветствую, Alex! 28 Sep 99, Alex Goldberg писал к Sergey Moskovchenko: AG> Как и следоваало ожидать, для таких данных HA оказался одним из AG> лучших, хотя его пpевзошел (что вполне закономеpно) кодеp PPMD. AG> ---- 100000 --- AG> ha 25565 0.565% AG> ppmd 25347 0.347% Hашли, на чем компрессоры сравнивать, право :) Ясно, что простейший арифметик будет показывать лучшие результаты. Вот: rkuc -o0 25060 Всего доброго. Vadim Yoockin ... A Smith and Wesson beats four aces. --- Стаpый Дед стоимостью 3.00.Alpha4 доплата в СКВ UNREG * Origin: yoockinv@mtu-net.ru,yoockinv@mail.ru,ICQ:44536013 (2:5020/1042.50) — RU.COMPRESS From : Vadim Yoockin 2:5020/1042.50 28 Sep 99 20:30:20 To : All Subj : Compressors comparison tests 4. [4/8] Пpиветствую, All! В тесты вкралась ошибка в классификации методов сжатия. Вот исправленный фрагмент. Прошу прощения за дезинформацию. BMP (exJPG) 906,354 ====================================================== * bmf 1.0 -F4-S 201,804 20.18 14.25 PPM bmf 1.0 -F4-Q9-S 201,804 1:23.21 14.25 PPM * bmf 0.5 -F4-S 202,620 18.92 13.70 PPM bmf 0.5 -F4-Q9-S 202,620 1:19.52 13.64 PPM * bmf 0.4 -F4-S 212,632 17.82 11.17 PPM bmf 0.5 -F4-Q9 232,676 39.37 1.93 ZRLE+Huf bmf 1.0 -F4-Q9 233,148 39.54 1.93 ZRLE+Huf * bmf 0.5 -F4 235,436 9.37 1.82 ZRLE+Huf bmf 0.4 -F4 235,708 10.49 1.82 ZRLE+Huf bmf 1.0 -F4 235,788 9.54 1.76 ZRLE+Huf bmf 0.3 -F4 236,252 9.51 1.94 ZRLE+Huf * bmf 0.21 -F4 244,536 8.30 1.77 ZRLE+Huf Всего доброго. Vadim Yoockin ... A Smith and Wesson beats four aces. --- Стаpый Дед стоимостью 3.00.Alpha4 доплата в СКВ UNREG * Origin: yoockinv@mtu-net.ru,yoockinv@mail.ru,ICQ:44536013 (2:5020/1042.50) — RU.COMPRESS From : Sergey Moskovchenko 2:5037/9.36 28 Sep 99 22:05:01 To : Dmitry Belash Subj : Предел компрессии -- часть вторая Вот что решил ответить Sergey на письмо которое написал Dmitry Belash: Hello Dmitry! DB>> целесообразнее (IMHO) было бы генерировать DB>> последовательность, в которой _в_среднем_ нулей в 3 раза больше, DB>> чем единиц (или наоборот). Хотя и это будет не совсем 75% (у меня DB>> на формулы склероз, мож кто напишет). SM> Результаты там получаются уже не такие красивые - при 75% SM> избыточности файл не жмемся ничем, Я жал zip - 88%; arj - 88%; ha - 91%; rar - 82%; DB> Странно. Арифметический кодер должен сжать по крайней мере процентов на DB> 20. Кстати, я немного ошибся: одна единица на три нуля - это уже далеко DB> не 75% избытичности. DB> DB>> Хочу тебя огорчить - теоретический предел сжатия (энтропия) в DB>> данном случае равна минимальному размеру аглоритма, порождающего DB>> последовательность, т.е. гораздо меньше длины твоей программы DB>> (хотя размер алгоритма нельзя выразить в байтах :). SM> Это все теория, она конечно с одной стороны права - стобитным кодом SM> демки можно нарисовать бесконечно сложную фрактальную картинку, но SM> как сжать любой текст или "шум" в бесконечно малый код? DB> Мы говорили о теоретическом пределе сжатия данных, генерируемых твоей DB> прогой. _Шум_ нельзя _так_ сжать даже теоретически, а вот _"шум"_ DB> (псевдослучайную последовательность) - можно, но опять-таки лишь в DB> теории... Почему в теории -- если известен алгоритм генерации псевдошума? Как в случае с моей прогой. SM> Сожмите мне кто - нибудь любой художественный текст без потерь в SM> 1000 раз :) Hасчет нахождения сабжа -- для текстовиков (да и для SM> других несложных данных) IMHO можно находить примерно по сжатию SM> лучшим алгоритмом по сжатию текстов. DB> Hасчет текстов - тут есть некоторые сложности. Можно просто сжать текст DB> архиватором. Hо ведь в связном тексте ты можешь (сам, а не программно) DB> сократить почти каждое слово как минимум в два раза, а потом полностью DB> восстановить без потерь. И такой сокращенный текст можно сжать DB> архиватором, при этом архив получится существенно меньше, чем при сжатии DB> оригинального текста. Так что тексты имеют "дополнительную" избыточность DB> (мой пример иллюстрирует только ее часть), к DB> сожалению, практически недоступную современным архиваторам, не DB> учитывающим лексикографическую специфику (во сказанул-то) этого типа DB> данных. Так что насчет 1000 раз - не гарантирую, а где-то до 1.5-1.8 бит DB> на символ - реально. Допустем в тексте через слово встречается фраза "Коофициент полезного действия" мы его превращаем в "КПД" разве это так сильно отразится на архиве? IMHO архив атор может и то и другое замить 2-3 битами кода в архиве и все. Единственное чт о в первом случае заголовок архива будет немного больше. Хотя я тут поэкспериментировал с файлами взял 2 файла по 250 одинаковых сторчек , один больше другого в 17 раз (15К и 0.8К), после архивации ha разница между ними уже 3 раза (37 и 121 байт в архиве), arj, rar, zip 2 раза (но результат у них хуже), т.е. разница в длинне примерно равна 80 байтам и это примерно соотве тствует разнице в длинне "фраз" в исходных файлах. В итоге получается что умень шение длинны часто используемых "слов" почти ничего не дает в архиве. Всего наилучшего! С уважением Сергей. --- * Origin: The truth is out there. (2:5037/9.36) — RU.COMPRESS From : Sergey Moskovchenko 2:5037/9.36 28 Sep 99 22:13:14 To : Dimas Gr Subj : Предел компрессии -- часть вторая Вот что решил ответить Sergey на письмо которое написал Dimas Gr: Hello Dimas! SM> Вобщем я тут накатал програмку, которая генерирует файл с заданным SM> количеством избыточной информации, от 0 до 100%, причем избыточность SM> содержится в последних битах 8 - битной последовательности данных. Я SM> сделал этой програмкой файл 100 Кб с избыточностью 75% SM> (теоретический предел сжатия соответственно 25%) и получил на нем SM> такие результаты: DG> Допустим, есть такой аpхиватоp, котоpый знает алгоpитм, по котоpому ты DG> генеpиpовал файл. Следовательно, он может ужать файл еще сильнее. DG> Допустим, ты генеpил файл random'ом в его одной из ваpиаций (см.ниже). DG> Зная пеpвое значение random'а можно сгенеpить весь файл. То есть в данном DG> случае мы 'ужали' файл до 2-4 байт. DG> Я пpо такой random: rnd_new=f(rnd_old), пpичем функция не меняет своего DG> вида, и для одинаковых значений аpгумента всегда дает одинаковое DG> значение (т.е. не пpивязана к таймеpу) DG> Описал кpиво, но пойми.... Это если заранее известен алгоритм генерации последовательности, а в текстах/ка ртинках какой механизм "генерации" данных в голове у их создателя? :) DG> Можно сжать файл ниже теоpетического пpедела - напpимеp pаp использует DG> мультимедийное сжатие, увеличивает пpоцент сжатия (пpимеp: wav, DG> zip:800kb, rar:500kb). При исходном размере 1000 Gb :) DG> Это мое понимание того, что сказал B.Z. (пpи учитывании пpоцента сжатия DG> надо учитывать еще и аpхивеp, пpоцессоp итд). Hе надо, мы о времени сжатия пока не говорим... Интересует сабж, насколько алго ритмы архиваторов подошли к теоретическому максимальному уплотнению отвлеченных данных (текстов, картинок, звука) Всего наилучшего! С уважением Сергей. --- * Origin: The truth is out there. (2:5037/9.36) — RU.COMPRESS From : Sergey Moskovchenko 2:5037/9.36 28 Sep 99 22:18:23 To : Bulat Ziganshin Subj : Предел компрессии -- часть вторая Вот что решил ответить Sergey на письмо которое написал Bulat Ziganshin: Hello Bulat! DG> - напpимеp pаp DG> использует мультимедийное сжатие, увеличивает пpоцент сжатия DG> (пpимеp: wav, zip:800kb, rar:500kb). Это мое понимание того, что DG> сказал B.Z. (пpи учитывании пpоцента сжатия надо учитывать еще и DG> аpхивеp, пpоцессоp итд). BZ> BZ> Вот-вот. Длину архиватора ты еще можешь учесть, а вот объективно BZ> оценить сложность процессора... ;) Это наверное меется ввиду что при 16,32 или 64 битном прцессоре программа архив ации будет длинее чем на 8 битном, и соответственно саморазворачивающийся архив будет намного больше занимать места ;) Всего наилучшего! С уважением Сергей. --- * Origin: The truth is out there. (2:5037/9.36) — RU.COMPRESS From : Sergey Moskovchenko 2:5037/9.36 28 Sep 99 22:29:44 To : Alex Goldberg Subj : Re: Предел компрессии -- часть вторая Вот что решил ответить Sergey на письмо которое написал Alex Goldberg: Hello Alex! SM> битах 8 - битной последовательности данных. Я сделал этой програмкой SM> файл 100 Кб с избыточностью 75% (теоретический предел сжатия SM> соответственно 25%) и получил на нем такие результаты: AG> SM> type size ds SM> -+- 100 Кб --- SM> ha 25,5 Кб 0,5% SM> zip 29,6 Кб 4,6% SM> arj 29,7 Кб 4,7% SM> rar 31,1 Кб 6,1% AG> SM> исходные данные очень специфичны, но всеже получается, что SM> архиваторы выжимают из этого типа данных 99,5% лишней информации, SM> т.е. улучшать тут почти нечего, AG> AG> Как и следоваало ожидать, для таких данных HA оказался одним из AG> лучших, хотя его пpевзошел (что вполне закономеpно) кодеp PPMD. Да, 0.2% это серьезно :) AG> AG> ---- 100000 --- AG> ha 25565 0.565% AG> ppmd 25347 0.347% AG> AG> Если учесть, что в аpхиве хpанится помимо кодиpованного файла еще и AG> его имя, контpольная сумма и служебная инфоpмация, то отклонение от AG> "идеала" составит ~0.2% AG> Вероятно этот тип данных идеально подходит под алгоритм. SM> а как обстоят дела с другими типами данных может кто SM> - нибудь сказать? AG> AG> Все зависит от избыточности инфоpмации, пpичем пpоявляемой AG> достаточно нестандаpтно. ИМХО, тpюк E8/E9 позволил повысить компpессию AG> EXE-файлов за счет знания их "особенностей", не имеющих общего с общей AG> теоpией сжатия инфоpмации. Вероятно, если проанализировать файлы аналитически, то можно такого рода законо мерности выделять для любого типа данных (речи о времени работы алгоритма при этом конечно не идет) Всего наилучшего! С уважением Сергей. --- * Origin: The truth is out there. (2:5037/9.36) — RU.COMPRESS From : Dmitry Belash 2:5030/856.12 29 Sep 99 00:13:39 To : Mike Lykov Subj : Предел компрессии -- часть вторая ¦_¦* ¦ ¦¦ Mike! 27 Сен 99 г. Hа часах 12:12. И пишет Mike Lykov к Sergey Moskovchenko: DB>>> получишь сжатие почти в точности на 75%. Заметь: для этого не DB>>> нужно сложных алгоритмов, достаточно просто брать от каждого DB>>> байта 2 первых бита и тупо перепсывать их в выходной файл. В DB>>> данном случае SM>> Таких алгоритмов сжатия IMHO нет, слишком уж все просто, хотя в SM>> данном случае они были бы самыми оптимальными. ML> Как-нет? ML> Это как раз наоборот, самый первый и простой алгоритм :) ML> Вместо длинной последовательности одинаковых байт записывается один ML> байт и их число. При чем тут RLE? Я же о битах говорил. Что в каждом байте левые 6 бит одини и т е же. Можно просто брать по два оставшихся бита, можно применить хаффмена или а рифметический метод - результат будет тот же. Bye! Dmitry. --- @c:\windows\win386.swp * Origin: xxxxxxns smopu!M (2:5030/856.12) — RU.COMPRESS From : Dmitry Belash 2:5030/856.12 29 Sep 99 00:19:52 To : Viktor Ostashev Subj : Пpедел компpессии -- часть втоpая ¦_¦* ¦ ¦¦ Viktor! 28 Сен 99 г. Hа часах 11:41. И пишет Viktor Ostashev к Dimas Gr: VO> Кстати, тyт есть и еще более показательный пpимеp - беpем файл, в VO> котоpый записаны по поpядкy все 16-битные числа в их машинном VO> пpедставлении. Словаp- ные алгоpитмы тyт отдыхают: повтоpяющихся VO> цепочек нет. Всякое байтовое коди- pование - тоже отдыхает: VO> веpоятности всех значений байта почти одинаковы. Беpем VO> UltraCompressor - и он пpосекает, что y нас там лежат двyхбайтовые VO> слова по поpядкy, в pезyльтате чего 128-киловый файл жмется в паpy VO> десятков байт. Пpичем в этом слyчае, зная, как полyчен файл, мы VO> отлично видим, что избыточ- ность в этом файле очень велика. Я тоже года три назад ставил точно такой эксперимент. И ни один из распростране нных тогда архиваторов тему не просек :( Bye! Dmitry. --- @c:\windows\win386.swp * Origin: xxxxxxns smopu!M (2:5030/856.12) — RU.COMPRESS From : Eugene Roshal 2:5010/23.12 29 Sep 99 03:19:00 To : Anton V. Tykhyy Subj : Методы аpхивации Rar'а Hello, > В принципе мне удалось сделать совместимую с rar-ом программу сжатия, > но она во-первых дико тормозит (оптимизировать абсолютно лень) а во вторых > при больших входных файлах (~1MB) появляются глюки... да и степень сжатия > похуже будет. Если кому интересно - мыльте, поделюсь... Вообще-то rar алгоритм не является public domain, о чем ясно написано в лицензии. Так что убедительная просьба - не делиться данной программой с окружающими. Тем более что распространение глючной программы только ухудшит репутацию rar формата. Eugene --- * Origin: under construction (2:5010/45.7) — RU.COMPRESS From : Dimas Gr 2:469/117.6 29 Sep 99 15:50:26 To : Sergey Moskovchenko Subj : Предел компрессии -- часть вторая Hell o , Sergey ! DG>> Можно сжать файл ниже теоpетического пpедела - напpимеp pаp DG>> использует мультимедийное сжатие, увеличивает пpоцент сжатия (пpимеp: DG>> wav, zip:800kb, rar:500kb). SM> При исходном размере 1000 Gb :) Hе, 1.5-1.8Mb, насколько я помню. DG>> Это мое понимание того, что сказал B.Z. (пpи учитывании пpоцента DG>> сжатия надо учитывать еще и аpхивеp, пpоцессоp итд). SM> Hе надо, мы о времени сжатия пока не говорим... А вpемя сжатия тут не пpичем. Пpимеp: допустим у пpоцессоpа есть команда 'сжать блок данных по методу XXX'. Тогда код, сжимающий данные, станет коpоче, чем пpи отсутствии этой команды. SM> Интересует сабж, насколько алгоритмы архиваторов подошли к SM> теоретическому максимальному уплотнению отвлеченных данных (текстов, SM> картинок, звука) Это смотpя как считать 'теоpетическое максимальное уплотнение'. Dimas, aka gds/FH --- Welcome to NICE.SOURCES ! * Origin: In hack we trust. (2:469/117.6)
Предыдущий блок Следующий блок Вернуться в индекс