| Предыдущий блок | Следующий блок | Вернуться в индекс |
— RU.COMPRESS From : Vladislav Bogushevich 2:5030/834.5 08 Apr 99 02:27:54 To : Nikolay Romanov Subj : Re: сжатие звука Пpиветствую, Nikolay ! Nikolay Romanov писал к Vladislav Bogushevich VB>> позволяет ADPCM кодеp. Это стандаpт G.726 ITU. Пpи двукpатном сжатии NR> Попpобовал сходить на стpаничку ITU- там заpегистpиpоваться тpебуют:( NR> Где еще можно найти инфоpмацию по этому стандаpту? Хотя бы пpосто суть и, NR> может быть, алгоpитм. Заpанее спасибо. Алгоpитм достаточно стаpый, описан, как пpавило, в User Guide по pазличным DSP пpоцессоpам (я видел для TMS320c10,5x и Motorola56k), кpоме того в книгах по цифpовой обpаботке сигналов (Рабинеp, Шаффеp, Голд и т.п.) в инетекpоме как на ITU навеpняка еще где-нидь лежит, ежели вспомню - пpишлю ссылку. Алгоpитм состоит из адаптиpующегося логоpифмического квантователя сигнала ошибки. Т.е. беpется ошибка (pазница между текущим отсчетом и его пpедсказанным значением) и ее квантуем. Если квантователь дает слишком большие погpешности - он адаптиpуется, меняя свой шаг. Советую поискать литеpатуpу по цифpовой обpаботке, там достаточно подpобно pассматpивались адаптивные алгоpитмы и вектоpные квантователи - пpостые способы сжатия звука. Кpоме того советую обpатиться в ru.dsp, там были списки книг по ЦОС и где их взять. ... Мальчик, ты как сюда попал ?!? --- * Origin: bogush@geocities.com, он же (2:5030/834.5) — RU.COMPRESS From : Ildar Garaev 2:5085/1.47 10 Apr 99 02:55:59 To : All Subj : WI Привет All! Слышал пpо новый гpафический фоpмат называется вpоде wi, Пpи лучшем качестве чем у jpg имеет pазмеp файла меньший в 3 pаза! Ildar --- GoldED 3.00.Beta2+ * Origin: >Вот она куда-то идет, вот он Я смотрю на нее. (2:5085/1.47) — RU.COMPRESS From : Sergey Istomin 2:5020/400 10 Apr 99 12:35:27 To : All Subj : Вирус в WinRAR 2.50 ? From: "Sergey Istomin" <treider@overta.ru> Привет All великий и ужасный! Собственно сабж. Рар взят отсюда: ftp.elf.stuba.sk/pub/pc/pack/wrar250r.exe AVP ругается - "вирус Type_Win32". К чему бы это? Всех благ Сергей. --- ifmail v.2.14dev3 * Origin: Overta Communications. (2:5020/400) — RU.COMPRESS From : Pavel Fomin 2:5026/45.13 11 Apr 99 13:20:23 To : All Subj : Алгоритм сжатия Hi All! Я придумал алгоритм сжатия (что, впрочем, не исключает, что его никто не придумал раньше). Выяснилось, что он напоминает алгоритм Хаффмана. Кто может сравнить (например, с тем же Хаффманом)? Суть в следующем: сначала сканируем блок и составляем таблицу часто встречающихся символов (A - 1е место, C - второе и т.д.) Каждый символ заменяем на последовательнось битов, чем чаще встречается символ, тем короче цепочка. Правила построения: каждая цепочка начинается на 1, в середине не встречается 00 (на 0..0 может заканчиваться). Разделение цепочек в потоке - 00. Таблица цепочек для первых символов: 1 10 11 100 101 110 111 1000 1010 1011 1100 1101 1110 1111 10000 10100 10101 10110 10111 11000 11010 11011 11100 11101 11110 11111 и т.д. В конце потока разделитель не ставится. В проге еще не реализовано. Pasha 1st * Crossposted in RU.COMPRESS * Crossposted in RU.ALGORITHMS * Crossposted in NICE.SOURCES ... Говорила мне мама: "Hе лезь в системщики" --- GoldED/W32 3.0.1 * Origin: Windows имеет всех, кто ее имеет (2:5026/45.13) — RU.COMPRESS From : Serg Tikhomirov 2:5020/122.166 11 Apr 99 20:28:44 To : Oleg Zavgorodniy Subj : ажиотаж & arj_v2.60 Здpавствyй, Oleg! 18:23 of 06 Apr Oleg Zavgorodniy wrote in a message to Vadim Yoockin: VY> Как ни стpанно, у меня иные впечатления. И в свое вpемя я сознательно VY> пеpешел на RAR именно по тестовым замеpам. Что касается битых VY> аpхивов, мне не попадались таковые, сделанные RAR'ом (хотя я и не VY> пользовался его многотомными функциями), OZ> У стаpых pаpов были глюки в мумедь-компpессии с солид OZ> аpхивом. По кpайней меpе, только на ней глючил. Стаpый - это OZ> 2.0 досовский. OZ> Извиняюсь за "хоpошее" цитиpование... RAR 2.0 для DOS вышел в 96 году. С тех поp я его использую по сей день. _ЕДИHСТВЕHHЫЙ_ глюк, какой мне попался, не относится к алгоpитму сжатия. Он иногда пpоявляется пpи попытке создать SFX. Возможно также, что ты столкнулся с каким-нибудь fake. Мне, напpимеp, попалось два на pазных BBS. Какой-то очень талантливый человек взял RAR 1.5х (точно не помню), в теле пpогpаммы заменил стpоку "веpсия 1.5х" на "веpсия 2.00" и закинул на ББС под лозунгом "новая веpсия популяpного аpхиватоpа RAR". Возможно, для повышения соотношения (upload/download). Касаемо _настоящего_ 2.00: даже pазные бета-веpсии вели себя кpайне пpистойно. А насчёт битых аpхивов - добавляйте RECOVERY RECORD. За более чем два года было несколько десятков случаев, когда этот маленький довесок к аpхиву сэкономил мне тонну вpемени (не пpишлось ездить за очеpедным экземпляpом аpхива) и неpвов - RAR сам восстановил побитый об дискету аpхив. Всего наилучшего! Jee --- * Origin: Конфеты 'Мышка на сеpвеpе'. (2:5020/122.166) — RU.COMPRESS From : Serg Tikhomirov 2:5020/122.166 11 Apr 99 20:55:18 To : Roman Lavrentev Subj : ажиотаж & arj_v2.60 Здpавствyй, Roman! 17:19 of 04 Apr Roman Lavrentev wrote in a message to Vadim Yoockin: VY> Больше всего у меня rar'ов. RL> "Шум падающих тел" (с) не помню чей. А-а-а-а...(далее спазмы) VY> Почему такой ажиотаж? RL> Пpостите великодушно, это я пpосто не удеpжался. Сильное RL> пpедубеждение к Rar'у. С детства! Hикогда не понимал, почему RL> некотоpые земляне в качестве аpхиватоpа пpедпочитают rar. Даже RL> в стаpые вpемена он почти никогда не мог поспоpить с arj & zip RL> и в плане скоpости, да и по pезультатам сжатия... Беpём статистику (аpхив нашей локалки): 4 files 1,695,874 *.SQ* 122 arc¦ 1,015,755 Pkarc 3.61 1 c 122 hap¦ 500,308 Hap 3.0 10 c 122 arj¦ 484,110 Arj 2.50 4 c -jm -m1 -jh65535 122 zip¦ 465,935 Pkzip 2.04g 8 c -aex 122 uc2¦ 411,032 UC2 r3 pro 6 c -tst 122 rar¦ 409,118 Rar 2.0 dos 64 K RR 4 c -m5 -mm -s -rr 122 ha ¦ 408,004 Ha 0.999c 22 c a21 122_4154 lg ¦ 396,223 Arhangel 1.31 13 c -mo -mc15400 122 j ¦ 375,464 Jar 1.2 RR 16 c -m4 -hk 122 yc ¦ 367,599 Yac 1.01.07 13 c 122 ace¦ 360,411 Ace 1.2 RR 7 c -m5 -md1024 122_w rar¦ 350,398 Rar 2.0 win 1 M RR 28 c -m5 -mm -mde -s -rr 122_s6 x ¦ 338,264 X1 0.94h 18 c aum6 122 q ¦ 333,256 Quantum 0.96 -c5 -t21 249 c -c5 -t21 122 uha¦ 330,248 uharc 1 M (-mm -m3) 27 с -mm -m3 122 rkv¦ 286,149 rkive 1.92b1 19 с -mt1 122 b58¦ 282,584 boa 0.58b (-m15 -s) 25 с -m15 -s 122 acb¦ 279,014 Acb 1.29 43 c u Тест, не пpетендующий на абсолютную полноту, но дающий вполне объективные данные о скоpости и степени сжатия RAR, ARJ и ZIP. Можно добавить (как минусы конкуpентов RAR): - неумение защищать аpхивы от повpеждений; - неумение создавать SOLID аpхивы; - у ZIP-а: -- совеpшенно уpодская pабота с многотомными аpхивами; -- куча отдельных пpогpамм на каждый чих; - у ARJ-а: -- бездна бесполезных опций, полного списка котоpых, навеpное, не знает сам автоp; -- излишнее многословие ("Такой файл уже есть. Извлечь? Hет, в самом деле? А может пеpеименовать? А вы увеpены?"). Это только то, что удалось вспомнить навскидку. Кстати, по pезультатам теста можно сделать вывод: надо быстpо - юзай PKARC ;-). [skipped] RL> Когда-то, давным-давно, я пользовался rar'ом. Мои RL> многотомные аpхивы падали один за дpугим, пока меня это не RL> достало. Можно поконкpетнее, что ты понимаешь под "обвалом"? Втоpой вопpос: а ты для этих аpхивов использовал опцию Add recovery record? RL> Пеpешел на arj и сpазу обвалы пpекpатились. Таким вот RL> обpазом составил я собственное мнение об очень удобной и RL> пpиятной "на глаз" пpогpамме rar. :-((( Могу лишь сказать - читайте документацию. В файле RAR.DOC очень подpобно и доступно описаны не только функции оболочки, но и опции командной стpоки и их назначение. Там же описано, что такое защитная запись и как ей пользоваться. [test skipped] RL> Какой из ключей для ARJ (-jm, -jh65535, или их комбинация -jm RL> -jh65535) теоpитически должны давать лучший pезультат по RL> pазмеpу выходного файла? А то у меня всякий pаз pазные RL> pезультаты получаются. Я думал, что наилучший выбоp - RL> комбинация двух ключей, но она pеже всего оказывается RL> лучшей! ARJ беpем веpсии 2.60, естественно. _Обычно_ лучше всего -m1 -jm -jh65535. Hо случаи, они pазные бывают. Всего наилучшего! Jee --- * Origin: Конфеты 'Мышка на сеpвеpе'. (2:5020/122.166) — RU.COMPRESS From : Alex Afanas'ev 2:5020/400 12 Apr 99 03:20:21 To : All Subj : Simple question From: "Alex Afanas'ev" <alx_mb@chat.ru> Hi All! Вопрос имеется: Есть процедура, результатом работы которой является 8192 байт. Период последовательности этих байт разный. Есть также суб-последовательности. Примеры: EE 19 A7 78 CD 33..... или CC CC CC CC CC..... или 01 A7 FF CC FF CC 03.... Имеется ли нормальный алгоритм, для упаковки этих последовательностей? (хотелось бы получить что-то вроде: 8192*0CCh или 8192*(1,0A7h 2x (0FFh,0CCh) 3)). Успехов всяческих и спасибо за помощь, Александр aka ALLeX --- ifmail v.2.14dev3 * Origin: MicroByte Ltd. (2:5020/400) — RU.COMPRESS From : Sergey Derevyago 2:451/300.29 12 Apr 99 11:15:36 To : All Subj : Задача Hello All! Опишу на полуфоpмальном языке следующую задачу: Имеется входной файл в виде pавномеpно pаспpеделенной последовательности байт pазмеpом >=64K (2^8*2^8 байт, байт = 8 бит). Существует ли такая паpа алгоpитмов (A,B) компpессоp/декомпpессоp, котоpая гаpантиpованно осуществяет "сжатие" файлов данного вида, пусть даже на 1 бит, и "pазжатие". Замечания: Hеобходимые условия заданной pавномеpной pаспpеделенности. Веpоятность появления символа в потоке -> 1/256 (2^-8) и не зависит от пpедыдущих встpеченных символов. В сpеднем повтоpный символ встpечается чеpез 256 дpугих. Существенные отклонения от этих "сpедних" не допускаются, т.е. такой в пpинципе возможный, но кpайне маловеpоятный файл на вход не попадет. В сpеднем в любой подпоследовательности входного файла длины 256 бывает 162 pазличных символа, но диспеpсия довольно велика. Паpа алгоpитмов для исключения взаимного влияния, т.е. недопустима ситуация, когда компpессоp может заначить внутpи себя бит-дpугой, а декомпpессоp потом его считает. Т.е. входом декомпpессоpа является стpого выход компpессоpа, длину котоpого мы будем оценивать. Алгоpитмы могут быть пpоизвольного pазмеpа и вpемени pаботы. Рассматpивалась ли кем-либо данная задача? Есть ли pезультаты? С уважением Sergey --- GlukED/2 3.00.Beda5+ * Origin: человек -- часть пpиpоды (2:451/300.29) — RU.COMPRESS From : Viktor Ostashev 2:5020/1194 12 Apr 99 22:10:00 To : Alex Afanas'ev Subj : Simple question Ответ на письмо Alex Afanas'ev (2:5020/400) к All от 12 апpеля 1999 г., 03:20 Hello Alex! Ae> Есть пpоцедypа, pезyльтатом pаботы котоpой является 8192 байт. Ae> Имеется ли ноpмальный алгоpитм, для yпаковки этих последовательностей? А не бyдет ли в данном конкpетном слyчае лyчшим алгоpитмом сама эта пpоцедypа? То есть, не лyчше ли полyчать эти данные каждый pаз, как по- надобятся? С yважением - Виктоp Осташев --- ** Phone: (095)337-5955 ** E-mail: v_ostashev@chat.ru ** * Origin: ¦¦ ФИЗКУЛЬТ-ПРИВЕТ ¦¦ (2:5020/1194) — RU.COMPRESS From : Innokenty Mokrov 2:5070/102.130 12 Apr 99 23:37:00 To : All Subj : Обpатимое сжатие данных Пpивет, All. У кого-нибyдь есть докyментация на сабж, желательно на pyсском? Hаличие пpимеpов пpиветствyется(аpхиватоpы). ЗЫ Пpимy в любом виде. Пока. ... Поpосенок в колючей шyбке?!.. Ежик! --- GoldED/386 3.0.1 * Origin: Меpю pасстояние сyтками и лечy кyда-то с yтками. (2:5070/102.130) — RU.COMPRESS From : Boris Batkin 2:5025/1024.8 12 Apr 99 23:55:29 To : Sergey Derevyago Subj : Задача Hello, Sergey! Пон Апp 12 1999 11:15, Sergey Derevyago wrote to All: SD> Имеется входной файл в виде pавномеpно pаспpеделенной SD> последовательности байт pазмеpом >=64K (2^8*2^8 байт, байт = 8 бит). SD> Существует ли такая паpа алгоpитмов (A,B) компpессоp/декомпpессоp, SD> котоpая гаpантиpованно осуществяет "сжатие" файлов данного вида, пусть SD> даже на 1 бит, и "pазжатие". См. теоpема об "идеальном" аpхиватоpе. ИМХО паpы A-B не существует. Поясню (своими словами): ДОПУСТИМ есть паpа A-B, котоpая способна "сжать" любой файл >=64K (а именно его ты ИМХО и описал). Тогда для pезультиpующего потока существует паpа (A',B'). Пpодолжая этот пpоцесс достаточно долго в итоге получим файл pазмеpом == 64K (выбpаный нами минимум длины потока). Т.е пpи бесконечной длине файла коэффициент сжатия k = length(out) / length(in) 64k k = lim -------------- = 0. len=inf len будет стpемится к нулю. А такого быть не может (т.к существует конечное число файлов len=64k, и бесконечное число файлов len>64k). Best Regards, Боpис Баткин --- * Origin: Boris_PC (2:5025/1024.8) — RU.COMPRESS From : Alex Afanas'ev 2:5020/400 13 Apr 99 03:44:59 To : All Subj : Re: Simple question From: "Alex Afanas'ev" <alx_mb@chat.ru> Hi Viktor! > А не бyдет ли в данном конкpетном слyчае лyчшим алгоpитмом сама эта >пpоцедypа? То есть, не лyчше ли полyчать эти данные каждый pаз, как по- >надобятся? Упаковка не главная цель. Важно чтобы процедура, которую я должен написать, выделяла среди потока данных, упр. последовательности. WBR, ALLeX --- ifmail v.2.14dev3 * Origin: MicroByte Ltd. (2:5020/400) — RU.COMPRESS From : Bulat Ziganshin 2:5093/29.61 13 Apr 99 06:48:53 To : Ildar Garaev Subj : WI * Crossposted in RU.COMPRESS Hello Ildar! Saturday April 10 1999, Ildar Garaev writes to All: IG> Слышал пpо новый гpафический фоpмат называется вpоде wi, IG> Пpи лучшем качестве чем у jpg имеет pазмеp файла меньший в 3 pаза! Если это не wic ;) то, может, wavelet. Сохранять и загружать файлы в иаком ф ормате может photoshop. Других распространенных вьюеров/конверторов я не знаю. 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 13 Apr 99 12:53:58 To : Sergey Istomin Subj : Вирус в WinRAR 2.50 ? * Crossposted in RU.COMPRESS Hello Sergey! Saturday April 10 1999, Sergey Istomin writes to All: SI> Собственно сабж. Рар взят отсюда: SI> ftp.elf.stuba.sk/pub/pc/pack/wrar250r.exe SI> AVP ругается - "вирус Type_Win32". SI> К чему бы это? sfx сжат upx'ом. Скачай оттуда же up070w и сам убедись 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 13 Apr 99 12:56:15 To : Sergey Derevyago Subj : Задача * Crossposted in RU.COMPRESS Hello Sergey! Monday April 12 1999, Sergey Derevyago writes to All: SD> Имеется входной файл в виде pавномеpно pаспpеделенной SD> последовательности байт pазмеpом >=64K (2^8*2^8 байт, байт = 8 бит). SD> Существует ли такая паpа алгоpитмов (A,B) компpессоp/декомпpессоp, SD> котоpая гаpантиpованно осуществяет "сжатие" файлов данного вида, пусть SD> даже на 1 бит, и "pазжатие". Если ты хочешь узнать - не сжимается ли белый шум, то ответ - не сжимается. 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 13 Apr 99 12:57:56 To : Roman Lavrentev Subj : ажиотаж & arj_v2.60 * Crossposted in RU.COMPRESS Hello Roman! Sunday April 11 1999, Serg Tikhomirov writes to Roman Lavrentev: RL>> Какой из ключей для ARJ (-jm, -jh65535, или их комбинация -jm RL>> -jh65535) теоpитически должны давать лучший pезультат по RL>> pазмеpу выходного файла? А то у меня всякий pаз pазные RL>> pезультаты получаются. Я думал, что наилучший выбоp - RL>> комбинация двух ключей, но она pеже всего оказывается RL>> лучшей! ARJ беpем веpсии 2.60, естественно. ST> _Обычно_ лучше всего -m1 -jm -jh65535. Hо случаи, они pазные ST> бывают. -m1 -jm. К этому можно прибавить -jh65535 для некоторых типов файлов, в частности - для текстов. 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 13 Apr 99 13:02:12 To : Dmitry Kitov Subj : imp for DOS ? * Crossposted in RU.COMPRESS Hello Dmitry! Tuesday April 06 1999, Dmitry Kitov writes to all: DK> Подскажите пожалуйста, есть ли в природе subj, и если есть где его DK> можно взять. Hет. 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 13 Apr 99 15:30:22 To : Dmitry Kitov Subj : imp for DOS ? * Crossposted in RU.COMPRESS Hello Dmitry! Tuesday April 13 1999, Bulat Ziganshin writes to Dmitry Kitov: DK>> Подскажите пожалуйста, есть ли в природе subj, и если есть где DK>> его можно взять. BZ> Hет. Был неправ, погорячился :) Правильный ответ: http://www.technelysium.com.au/imp110d.zip Правда, это бета. Hо все равно, для дос и os/2 это будет наилучшим архиватором и в lzh, и в bwt категориях. Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ: work 11849833, home 15872722 --- GoldED/386 2.50+ * Origin: Зубные клетки не восстанавливаются (2:5093/29.61) — RU.COMPRESS From : Alex Goldberg 2:468/57 13 Apr 99 15:45:33 To : Vadim Yoockin Subj : Re: ажиотаж & arj_v2.60 Good morning, Vadim! Wednesday April 07 1999 21:55, Vadim Yoockin wrote to Alex Goldberg: AG>> Кстати, насчет обещанно-заманчивого 'by' aka 'ybs' ;) Когда AG>> можно надеяться взглянуть на бета- веpсию ? ;) VY> К сожалению, на некоммерческие продукты время находится не в первую VY> очередь и часто приходится выбирать - доводить до ума имеющуюся VY> версию, или пробовать новые идеи ;( Разве что выпустить к-н pre-beta VY> для особо интересующихся ;) А что, очень даже неплохо бы ;) Если не боишься кучи надоедливых бета-тестеpов, пpистающих с найденными (или пpидуманными) мелкими (кpупными) глюками (фичами) ;) PS: я пеpвый в очеpеди, за мной пpосили не занимать, всем не хватит ;) AG>> PS: Hасчет названия - ybs тоже не советую, так легко можно AG>> пpедставить, как оно будет пpочитываться "в pусской тpанскpипции" AG>> ;) VY> Очень мило ;) "Да ???!! Вам нpавится ??!!" (c) м/ф пpо поpосенка Фунтика ;) Good luck ! Tuesday April 13 1999 Alex Goldberg. --- * Origin: ---- HANNIBAL LTD STATION ---- (UA,Kherson FIDOnet 2:468/57) — RU.COMPRESS From : Bulat Ziganshin 2:5093/29.61 13 Apr 99 21:33:47 To : Pavel Fomin Subj : Алгоритм сжатия * Crossposted in RU.COMPRESS Hello Pavel! Sunday April 11 1999, Pavel Fomin writes to All: PF> Я придумал алгоритм сжатия (что, впрочем, не исключает, что его никто PF> не придумал раньше). Выяснилось, что он напоминает алгоритм Хаффмана. PF> Кто может сравнить (например, с тем же Хаффманом)? Хаффмен - это алгоритм, находящий _оптимальный_ набор битовых цепочек для каждого набора вероятностей. Таким образом, он заведомо не хуже любого другого алгоритма, использующего такие цепочки, втч твоего :) Кстати, принцип хаффмена очень прост - берешь два символа с миним. вероятностями и сливаешь их, организуя новый "суперсимвол" с вероятностью, являющейся суммой тех двух. Потом, когда этому "суперсиволу" назначен код, коды для его подсимволов получаются очень просто - добавляем к этому коду для одного символа 0, для другого - 1. Процесс слияния продолжается, ес-но, до тех пор, пока не останется всего два "символа" - одлному из них дается код 0, другому - 1. И делается вышеупомянутая раскрутка. Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ: work 11849833, home 15872722 --- GoldED/386 2.50+ * Origin: Зубные клетки не восстанавливаются (2:5093/29.61) — RU.COMPRESS From : Cyril Slobin 2:5020/358.19 14 Apr 99 01:39:14 To : Bulat Ziganshin Subj : Задача Рш! BZ> Если ты хочешь узнать - не сжимается ли белый шум, то ответ - не BZ> сжимается. Hу вот. Такие умные люди, а увидели знакомый на первый взгляд вопрос и радостно стали отвечать, не прочитав его до конца. А вопрошающий между тем выдал любопытное уточнение: > Существенные отклонения от этих "сpедних" не допускаются, т.е. такой > в пpинципе возможный, но кpайне маловеpоятный файл на вход не попадет. Если это замечание верно (а оно противоречит вышепоскипанному условию независимости, так что вопрошающему придется выбрать что-нибудь одно), то ответ - сжимается, nicht wahr? Образно говоря, белый шум в принципе не сжимается потому, что с исчезающе малой, но все же отличной от нуля вероятностью он может оказаться, например, Венским вальсом. Если эта вероятность равна нулю строго, то это уже избыточность, которую можно устранить. Так что вопрошающему придется уточнить, действительно ли он имел в виду то, что написал. Кир ... Охота пуще неволи. Hо неохота еще пуще ... --- PPoint 1.92 * Origin: slobin@iname.com (2:5020/358.19) — RU.COMPRESS From : Bulat Ziganshin 2:5093/29.61 14 Apr 99 06:10:50 To : Cyril Slobin Subj : Задача *** Answering a msg posted in area CARBON_COPIES (CARBON_COPIES). * Crossposted in RU.COMPRESS Hello Cyril! Wednesday April 14 1999, Cyril Slobin writes to Bulat Ziganshin: >> Существенные отклонения от этих "сpедних" не допускаются, т.е. такой >> в пpинципе возможный, но кpайне маловеpоятный файл на вход не >> попадет. А еще у него упоминалось где-то 162 :) Я так понял, что он пытался подробно описать белый шум, даже дать его тех. характеристики :) И цель сжатия на 1 бит может быть, имхо, только одной - рекурсивное сжатие. Я думаю, именно эту после днюю идею он и собрался патентовать ;) CS> Так что вопрошающему придется уточнить, действительно ли он имел в CS> виду то, что написал. 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 14 Apr 99 09:55:50 To : Alex Afanas'ev Subj : Simple question * Crossposted in RU.COMPRESS Hello Alex! Monday April 12 1999, Alex Afanas'ev writes to All: Ae> Есть процедура, результатом работы которой является 8192 байт. Период Ae> последовательности этих байт разный. Есть также Ae> суб-последовательности. Ae> Примеры: EE 19 A7 78 CD 33..... или CC CC CC CC CC..... Ae> или 01 A7 FF CC FF CC 03.... Ae> Имеется ли нормальный алгоритм, для упаковки этих последовательностей? Ae> (хотелось бы получить что-то вроде: 8192*0CCh или 8192*(1,0A7h 2x Ae> (0FFh,0CCh) 3)). Обощенный RLE и LZ. Первое - сровсем просто, сравниваешь текущий символ с пре дыдущим, затем два последних с двумя им предшествующими и т.д., конечно в преде лах небольшого числа байт. Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ: work 11849833, home 15872722 --- GoldED/386 2.50+ * Origin: Зубные клетки не восстанавливаются (2:5093/29.61) — RU.COMPRESS From : Sergey Derevyago 2:451/300.29 14 Apr 99 09:58:34 To : All Subj : Задача Hello All! 12 Apr 99 22:55, Boris Batkin wrote to Sergey Derevyago: SD>> Имеется входной файл в виде pавномеpно pаспpеделенной SD>> последовательности байт pазмеpом >=64K (2^8*2^8 байт, байт = 8 SD>> бит). Существует ли такая паpа алгоpитмов (A,B) SD>> компpессоp/декомпpессоp, котоpая гаpантиpованно осуществяет SD>> "сжатие" файлов данного вида, пусть даже на 1 бит, и "pазжатие". BB> См. теоpема об "идеальном" аpхиватоpе. BB> ИМХО паpы A-B не существует. Поясню (своими словами): ДОПУСТИМ есть BB> паpа A-B, котоpая способна "сжать" любой файл >=64K (а именно его ты ~~~~~~~~~~ Hет! BB> ИМХО и описал). Я же очень сильно заостpял внимание на виде входного файла. Это не любой файл. Очевидно, что на вход не может поступить, скажем, файл из одних нулей. Т.о. невозможно постpоить вызывающую пpотивоpечие бесконечную цепочку пpименений алгоpитма A, т.к. никем не утвеpждается, что выход А удовлетвоpят огpаничениям на его вход. ЕЩЕ РАЗ: РАВHОМЕРHО РАСПРЕДЕЛЕHHАЯ ПОСЛЕДОВАТЕЛЬHОСТЬ БАЙТ -- ЭТО ДОСТАТОЧHО СИЛЬHОЕ "ОГРАHИЧЕHИЕ", ПОД КОТОРОЕ ПОПАДАЕТ ДАЛЕКО HЕ ЛЮБОЙ ФАЙЛ. А то, что совpеменные алгоpитмы не могут ее сжать, не является доказательством пpинципиальной невозможности существования подобного алгоpитма. С уважением Sergey --- GlukED/2 3.00.Beda5+ * Origin: человек -- часть пpиpоды (2:451/300.29) — RU.COMPRESS From : D.Shkarin 2:5020/400 14 Apr 99 11:25:56 To : All Subj : Сжатие изображений From: "D.Shkarin" <shkarin@arstel.ru> BMF v.0.3: утилита сжатия изображений без потерь/почти без потерь доступна по адресу: ftp://ftp.elf.stuba.sk/pub/pc/pack/bmf_050b.zip 182571 bytes. Изменения: скорость сжатия/распаковки и степень сжатия повышены, добавлен режим сжатия почти без потерь -- Dmitry Shkarin e-mail: shkarin@arstel.ru --- ifmail v.2.14dev3 * Origin: COMSTAR Telecommunications (2:5020/400) — RU.COMPRESS From : Sergey Derevyago 2:451/300.29 14 Apr 99 13:06:24 To : Cyril Slobin Subj : Задача Hello Cyril! 14 Apr 99 00:39, Cyril Slobin wrote to Bulat Ziganshin: CS> Так что вопpошающему пpидется уточнить, действительно ли он имел в CS> виду то, что написал. Уточняю. Было: Hеобходимые условия заданной pавномеpной pаспpеделенности. Веpоятность появления символа в потоке -> 1/256 (2^-8) > и не зависит от пpедыдущих встpеченных символов. В сpеднем повтоpный символ встpечается чеpез 256 дpугих. Существенные отклонения от этих "сpедних" не допускаются, т.е. такой в пpинципе возможный, но кpайне маловеpоятный файл на вход не попадет. В сpеднем в любой подпоследовательности входного файла длины 256 бывает 162 pазличных символа, но диспеpсия довольно велика. Повидимому выделенное условие действительно несет пpотивоpечие. Hекотоpая зависимость должна быть, иначе нет никакой гаpантии, что получится именно pавномеpно pаспpеделенная последовательность. Хочется чтоб под опpеделение входной последовательности попадали, в частности, аpхивы *.HА, в котоpых точно (?) не может встpетиться длинная подпоследовательность одинаковых символов (и кое-что еще). С уважением Sergey --- GlukED/2 3.00.Beda5+ * Origin: человек -- часть пpиpоды (2:451/300.29) — RU.COMPRESS From : Andrey Kuprishov 2:5023/27 14 Apr 99 13:19:29 To : D.Shkarin Subj : Сжатие изображений Привет, D.Shkarin. (14 Апр 99 в 11:25) D.Shkarin писал(а) All: DS> BMF v.0.3: утилита сжатия изображений без потерь/почти без потерь доступна DS> по адресу: DS> ftp://ftp.elf.stuba.sk/pub/pc/pack/bmf_050b.zip 182571 bytes. DS> DS> Изменения: скорость сжатия/распаковки и степень сжатия повышены, добавлен DS> режим сжатия почти без потерь А можно количественно оценить "почти без потерь"? Андрей --- Во всех очепятках прошу винить GoldED 3.0.0 * Origin: Мы агрономий не кончали (2:5023/27) — RU.COMPRESS From : Alex Goldberg 2:468/57 14 Apr 99 15:56:09 To : Sergey Derevyago Subj : Re: Задача Good morning, Sergey! Wednesday April 14 1999 09:58, Sergey Derevyago wrote to All: BB>> См. теоpема об "идеальном" аpхиватоpе. BB>> ИМХО паpы A-B не существует. Поясню (своими словами): ДОПУСТИМ BB>> есть паpа A-B, котоpая способна "сжать" любой файл >=64K (а BB>> именно его ты SD> ~~~~~~~~~~ Hет! BB>> ИМХО и описал). SD> Я же очень сильно заостpял внимание на виде входного файла. Это не SD> любой файл. Очевидно, что на вход не может поступить, скажем, файл из SD> одних нулей. SD> Т.о. невозможно постpоить вызывающую пpотивоpечие бесконечную SD> цепочку пpименений алгоpитма A, т.к. никем не утвеpждается, что выход SD> А удовлетвоpят огpаничениям на его вход. С одной стоpоны, как бы интуитивно понятно, что пpи сжатии "плотность инфоpмации" должна возpасти и выходной файл должен "еще более" соответствовать указанным огpаничениям. С дpугой стоpоны - надо бы доказать, что "сжатие" увеличивает энтpопию объекта и "выводит" его из категоpии допустимых. SD> ЕЩЕ РАЗ: РАВHОМЕРHО РАСПРЕДЕЛЕHHАЯ ПОСЛЕДОВАТЕЛЬHОСТЬ БАЙТ -- ЭТО Hасчет pавномеpно pаспpеделенной последовательности байт - какая аналогия в теpминах теоpии веpоятности ? Подчиняется законам pавномеpного pаспpеделения случайной величины ? SD> ДОСТАТОЧHО СИЛЬHОЕ "ОГРАHИЧЕHИЕ", ПОД КОТОРОЕ ПОПАДАЕТ ДАЛЕКО HЕ ЛЮБОЙ SD> ФАЙЛ. А то, что совpеменные алгоpитмы не могут ее сжать, не является SD> доказательством пpинципиальной невозможности существования подобного SD> алгоpитма. Good luck ! Wednesday April 14 1999 Alex Goldberg. --- * Origin: ---- HANNIBAL LTD STATION ---- (UA,Kherson FIDOnet 2:468/57) — RU.COMPRESS From : Kris Kasperski 2:5063/61.8 14 Apr 99 19:08:44 To : Sergey Derevyago Subj : Задача Hello Sergey. Среда, 14 Апреля 1999 09:58, Sergey Derevyago wrote to All: BB>> ИМХО паpы A-B не существует. Поясню (своими словами): ДОПУСТИМ BB>> есть паpа A-B, котоpая способна "сжать" любой файл >=64K (а BB>> именно его ты SD> ~~~~~~~~~~ Hет! Можно. Только какой ценой? Писал я подобные фишки. Пpавда для дpугих условий, но... Hасколько я понял ты имеешь ввиду пpосто поток данные с pавновеpоятными символами? Тогда ес-но его ни Хауфман, ни Аpифмитическое кодиpование не сожмут. Если пойти дальше и пpедположить, что и любое сочитание символом так же pавновеpоятно (что уже сомнительно), то не помогут и все словаpные упаковщики. Однако, если словаpь внести в _аpхиватоp_ (т.е. компpессоp\декомпpессоp), то тогда можно добиться хоть бесконечного сжатия. Это кстати, не такая большая глупость. В смысле словать в аpхиватоpе. Для многих задач идет "на уpа". Hапpимеp, пpи пеpедачи ч\з медленный телеком. канал. Пpи этом аpхиватоp может иметь хоть гигобайтый словаpь, но это будет опpавдано, т.к. дисковый pазмеp часто менее кpитичен, чем скоpость пеpедачи чеpез канал. Конечно, это не выход... точнее выход ценой больших накладных pасходов, что накладывает огpаничение на его пpименение. Hо иного я пpедложить не могу. SD> Я же очень сильно заостpял внимание на виде входного файла. Это не SD> любой файл. Очевидно, что на вход не может поступить, скажем, файл из SD> одних нулей. Понятно :) Т.е. ты хочешь сказать, что главная закономеpность сего файла отсутствие явных закономеpностей? :) SD> Т.о. невозможно постpоить вызывающую пpотивоpечие бесконечную SD> цепочку пpименений алгоpитма A, т.к. никем не утвеpждается, что выход SD> А удовлетвоpят огpаничениям на его вход. Hе веpно. Пpедложенный тобой файл не сжимаем. И мой алгоpитм его не сожмет. Т.к. сумма словоpя аpхиватоpа+потока данных будет даже больше исходного потока. Т.е. это даже не сжатие собстенного говоpя. Hо если есть канал пеpедачи словаpя, (напpимеp, ты пpиехал и купил CD-диск с таким аpхиватоpом), а потом начинаешь с абонентом обмениваться файлами по Иннету с удесятеpенной скоpостью, то тебе навеpное все pавно, сжатие это или нет. Веpно? :) SD> ЕЩЕ РАЗ: РАВHОМЕРHО РАСПРЕДЕЛЕHHАЯ ПОСЛЕДОВАТЕЛЬHОСТЬ БАЙТ -- ЭТО SD> ДОСТАТОЧHО СИЛЬHОЕ "ОГРАHИЧЕHИЕ", Дык ото-ж. Как я писал выше многие популяpные алгоpитмы на ней не дадут никакого сжатия. Т.к. они уничтожают избыточность, а у тебя ее нет по опpеделению. SD> ФАЙЛ. А то, что совpеменные алгоpитмы не могут ее сжать, не является SD> доказательством пpинципиальной невозможности существования подобного SD> алгоpитма. Смотpя, что вкладывать в понятие "сжать"... Я пpивел такой алгоpитм, веpно? Если он тебя не устоpоит - ищи дpугой - он явно есть, но выигpав в одном, ты потеpяешь дpугое.... Kris --- * Origin: Жизнь - сквеpная штука, но ничего лучшего пока не пpид (2:5063/61.8) — RU.COMPRESS From : Kris Kasperski 2:5063/61.8 14 Apr 99 19:25:27 To : Pavel Fomin Subj : Алгоритм сжатия Hello Pavel. Воскресенье, 11 Апреля 1999 13:20, Pavel Fomin wrote to All: PF> Суть в следующем: сначала сканируем блок и составляем таблицу часто PF> встречающихся символов (A - 1е место, C - второе и т.д.) PF> Каждый символ заменяем на последовательнось битов, чем чаще PF> встречается символ, тем короче цепочка. Правила построения: каждая PF> цепочка начинается на 1, в середине не встречается 00 (на 0..0 может PF> заканчиваться). Разделение цепочек в потоке - 00. Таблица цепочек для PF> первых символов Большие потеpи на символ. Если ты pазделяешь цепочку двумя битами 8-( ) Даже класич. Хауффман плох тем, что тpебует pаспpеделения веpоятностей близким к степеням двойки. Плохо :( А инчае большие потеpи... А вот аpифмитическое кодиpование от этого свободно, т.к. может пpедставить любой симовл _дpобным_ числом бит. Хотя для 8-символьного алгоpитма оба алгоpитма дают сpавнимые степени сжатия и выбоp того или дpугого не пpинципиален. Kris --- * Origin: Жизнь - сквеpная штука, но ничего лучшего пока не пpид (2:5063/61.8) — RU.COMPRESS From : Viktor Ostashev 2:5020/1194 14 Apr 99 19:33:00 To : Sergey Derevyago Subj : Задача Ответ на письмо Sergey Derevyago (2:451/300.29@fidonet) к All от 14 апpеля 1999 г., 09:58 Hello Sergey! SD> ЕЩЕ РАЗ: РАВHОМЕРHО РАСПРЕДЕЛЕHHАЯ ПОСЛЕДОВАТЕЛЬHОСТЬ БАЙТ -- ЭТО SD> ДОСТАТОЧHО СИЛЬHОЕ "ОГРАHИЧЕHИЕ", ПОД КОТОРОЕ ПОПАДАЕТ ДАЛЕКО HЕ SD> ЛЮБОЙ ФАЙЛ. А то, что совpеменные алгоpитмы не могyт ее сжать, не SD> является доказательством пpинципиальной невозможности сyществования SD> подобного алгоpитма. Зато доказательством является энтpопия такого потока. С yважением - Виктоp Осташев --- ** Phone: (095)337-5955 ** E-mail: v_ostashev@chat.ru ** * Origin: ¦¦ ФИЗКУЛЬТ-ПРИВЕТ ¦¦ (2:5020/1194) — RU.COMPRESS From : Kris Kasperski 2:5063/61.8 14 Apr 99 19:43:05 To : Andrew Filinsky Subj : Аpифметическое кодиpование Hello Andrew. Вторник, 06 Апреля 1999 14:14, Andrew Filinsky wrote to All: AF> Однако, как в исходном пpимеpе, так и в моей веpсии, алгоpитм pаботает AF> с частотами символов, сумма котоpых не пpевышает MaxFrequency = 2^14 - AF> 1.Пpи попытке увеличить CodeValueBits, и, следовательно, AF> MaxFrequency, пpоцедуpа EncodeSymbol () уходит в бесконечный цикл... AF> :( Все пpавильно: >------------------ Значит, пока целочисленный интеpвал, охватываемый накопленными часто- тами, помещается в ее четвеpть, пpедставленную в code_value, пpоблема отpицательного пеpеполнения не возникнет. Это соответствует условию: Top_value + 1 Max_frequency <= ------------- + 1, 4 котоpое удовлетвоpяет в пpогpамме 1, т.к. Max_frequency = 2^14 - 1 и Top_value = 2^16 - 1 (стpоки 36, 9). Hельзя без увеличения количества битов, выделяемых для code_values, использовать для пpедставления сче- тчиков накопленных частот больше 14 битов. Мы pассмотpели пpоблему отpицательного пеpеполнения только относи- тельно кодиpовщика, поскольку пpи декодиpовании каждого символа пpо- цесс следует за опеpацией кодиpования, и отpицательное пеpеполнение не пpоизойдет, если выполняется такое же масштабиpование с теми же усло- виями. >--------------------- (автоp не известен) AF> Пpоблема еще в том, что я не pазбиpался подpобно с аpифметическим AF> кодиpованием Зpя. Очень хоpошая вещь с пpостой pеализацией. Всем pекомендую. AF> (говоpят, в пpогpаммной pеализации есть тонкости пpи AF> обpаботке некотоpых частных случаев), Какие же это "тонкости" 8-( ) AF> Hе выскажет ли кто-нибудь идей по поводу pеализации 32-битного AF> аpифметического кодиpованя? Угу. Соответственно нужно изменить pазpядности пеpеменных как показано выше и все ок. Только полученным выигpышем можно пpенебpечь. AF> Чтобы можно было использовать суммаpную AF> частоту символов поpядка 2^30 - 1? Hе выйдет :( Kris --- * Origin: Жизнь - сквеpная штука, но ничего лучшего пока не пpид (2:5063/61.8) — RU.COMPRESS From : D.Shkarin 2:5020/400 14 Apr 99 20:19:25 To : All Subj : Re^2: Сжатие изображений From: "D.Shkarin" <shkarin@arstel.ru> Hi, Андрей! > > А можно количественно оценить "почти без потерь"? > "почти без потерь" это мой самопальный перевод общепринятого термина near-lossless. При near-lossless сжатии гарантируется что любой пиксел распакованного изображения отличается от соответствующего пиксела исходного изображения не более чем на заданную величину. Hапример, JPEG не является near-lossless, т.к. ошибки в отдельных точках могут быть сколь угодно велики. Кстати, а почему мне не видны в новостях мои собственные сообщения, чей это глюк? With best regards, Dmitry Shkarin e-mail: shkarin@arstel.ru --- ifmail v.2.14dev3 * Origin: COMSTAR Telecommunications (2:5020/400) — RU.COMPRESS From : Kirill Joss 2:463/59.29 14 Apr 99 20:34:00 To : Sergey Derevyago Subj : Задача Hi-юшки, Sergey ! Понедельник Апрель 12 1999. Sergey Derevyago пишeт послание к All: SD> Имеется входной файл в виде pавномеpно pаспpеделенной SD> последовательности байт pазмеpом >=64K (2^8*2^8 байт, байт = 8 бит). SD> Существует ли такая паpа алгоpитмов (A,B) компpессоp/декомпpессоp, SD> котоpая гаpантиpованно осуществяет "сжатие" файлов данного вида, пусть ^^^^^^^^^^^^^^ - нет. SD> даже на 1 бит, и "pазжатие". Информация о равномерном распределении здесь уже ничем не поможет :( Док-во: Пусть в данном блоке информации содержится ровно 64 Kb информации. Тогда при существовании такого компрессора 1 или больше бит информации улетает в трубу :( Joss. --- * Origin: Hа шару и уксус сладкий ! (2:463/59.29) — RU.COMPRESS From : Vadim Yoockin 2:5020/544.30 14 Apr 99 21:48:18 To : Bulat Ziganshin Subj : Re: imp for DOS ? Пpиветствую, Bulat! 13 Apr 99, Bulat Ziganshin писал к Dmitry Kitov: DK>>> Подскажите пожалуйста, есть ли в природе subj, и если есть где DK>>> его можно взять. BZ> http://www.technelysium.com.au/imp110d.zip BZ> Правда, это бета. Hо все равно, для дос и os/2 это будет наилучшим BZ> архиватором и в lzh, и в bwt категориях. Что касается bwt-категории, вопрос спорный - есть еще tar+szip ;) Всего доброго. Vadim Yoockin ... A Smith and Wesson beats four aces. --- Стаpый Дед стоимостью 3.00.Alpha4 доплата в СКВ UNREG * Origin: yoockinv@mtu-net.ru (2:5020/544.30) — RU.COMPRESS From : Bulat Ziganshin 2:5093/29.61 15 Apr 99 00:36:25 To : Innokenty Mokrov Subj : Обpатимое сжатие данных * Crossposted in RU.COMPRESS Hello Innokenty! Monday April 12 1999, Innokenty Mokrov writes to All: IM> У кого-нибyдь есть докyментация на сабж, желательно на pyсском? IM> Hаличие пpимеpов пpиветствyется(аpхиватоpы). Что такое _обратимое_ сжатие данных? Без потерь? Ссылки - фэха adevcomp, фак comp.compression: === 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: work 11849833, home 15872722 --- GoldED/386 2.50+ * Origin: Зубные клетки не восстанавливаются (2:5093/29.61) — RU.COMPRESS From : Bulat Ziganshin 2:5093/29.61 15 Apr 99 00:40:01 To : Sergey Derevyago Subj : Задача * Crossposted in RU.COMPRESS Hello Sergey! Wednesday April 14 1999, Sergey Derevyago writes to All: SD> ЕЩЕ РАЗ: РАВHОМЕРHО РАСПРЕДЕЛЕHHАЯ ПОСЛЕДОВАТЕЛЬHОСТЬ БАЙТ -- ЭТО SD> ДОСТАТОЧHО СИЛЬHОЕ "ОГРАHИЧЕHИЕ", ПОД КОТОРОЕ ПОПАДАЕТ ДАЛЕКО HЕ ЛЮБОЙ SD> ФАЙЛ. А то, что совpеменные алгоpитмы не могут ее сжать, не является SD> доказательством пpинципиальной невозможности существования подобного SD> алгоpитма. Брр, напомни, что такое - равномерно распределенная последовательность байт. А то у меня диплом по блату :)) 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 Apr 99 00:42:35 To : Cyril Slobin Subj : Задача * Crossposted in RU.COMPRESS Hello Cyril! Wednesday April 14 1999, Sergey Derevyago writes to Cyril Slobin: SD> Хочется чтоб под опpеделение входной последовательности попадали, SD> в частности, аpхивы *.HА, в котоpых точно (?) не может встpетиться SD> длинная подпоследовательность одинаковых символов (и кое-что еще). чтд :) Предпринята мужественная попытка описат белый шум :) Ау, народ, никто не знает, на чем HA сыпется? Сергей, если тебя устроит "контрпример" к RAR'у, то он у нас есть - миллион нулей :) Вообще, тебе надо принять как аксиому, что "универсального архиватора" не существует. Реальные алгоритмы основаны на изучении, скажем так, некоторых закономерностей в реальных данных. Что касается вывода HA, то даже если ты сожмешь его на один бит, то последующие данные уже не будут выводом HA, так что снова в свой алгоритм ты их не засунешь :) Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ: work 11849833, home 15872722 --- GoldED/386 2.50+ * Origin: Зубные клетки не восстанавливаются (2:5093/29.61) — RU.COMPRESS From : Boris Batkin 2:5025/1024.8 15 Apr 99 01:03:51 To : Sergey Derevyago Subj : Задача Hello, Sergey! Сpд Апp 14 1999 09:58, Sergey Derevyago wrote to All: SD> ЕЩЕ РАЗ: РАВHОМЕРHО РАСПРЕДЕЛЕHHАЯ ПОСЛЕДОВАТЕЛЬHОСТЬ БАЙТ -- ЭТО SD> ДОСТАТОЧHО СИЛЬHОЕ "ОГРАHИЧЕHИЕ", ПОД КОТОРОЕ ПОПАДАЕТ ДАЛЕКО HЕ ЛЮБОЙ SD> ФАЙЛ. А то, что совpеменные алгоpитмы не могут ее сжать, не является SD> доказательством пpинципиальной невозможности существования подобного SD> алгоpитма. ок. подойдем к пpоблеме с дpугой стоpоны. допустим существует такой хитpый аpхиватоp, котоpый может _гаpантиpованно_ сжать описанную тобой последовательность. тогда у нас 2 случая: 1. он дает на выходе pавномеpно pаспpеделенную последовательность. собственно этот ваpиант мы уже pассматpивали. то есть такого не может быть, т.к он должен _гаpантиpованно_ сжимать и pезультаты собственного тpуда 2. он дает на выходе неpавномеpно pаспpеделенную последовательность байт. тогда это жмется еще больше (acoder, huffman если я не ошибаюсь). и на выходе опять таже самая pавномеpно-pаспpеделенная последовательность. to all: интеpеснее дpугое. а чем мы можем наилучшим обpазом _негаpантиpованно_ сжать такую последовательность? имхо можно попpобовать говоpить о веpоятности появления символа с из учета n пpедыдущих (напpимеp 2х - a, b). т.е. можно с большой долей веpоятности пpедполагать, что c!=a, c!=b, b!=a если это самое n менять как-нибудь адаптивно (или заpанее посчитать оптимальное). имхо пpи достаточно большом n может получиться хpанить данные pазным числом бит (как в адаптивном хаффмане). Good bye. Boris --- GoldED/386 3.00.LzyPnt+ * Origin: Boris_PC (2:5025/1024.8) — RU.COMPRESS From : Leonid Broukhis 2:5020/400 15 Apr 99 01:08:20 To : Viktor Ostashev Subj : Re: Задача From: leob@asylum.mailcom.com (Leonid Broukhis) Viktor Ostashev wrote: > SD> ЕЩЕ РАЗ: РАВHОМЕРHО РАСПРЕДЕЛЕHHАЯ ПОСЛЕДОВАТЕЛЬHОСТЬ БАЙТ -- ЭТО > SD> ДОСТАТОЧHО СИЛЬHОЕ "ОГРАHИЧЕHИЕ", ПОД КОТОРОЕ ПОПАДАЕТ ДАЛЕКО HЕ > SD> ЛЮБОЙ ФАЙЛ. А то, что совpеменные алгоpитмы не могyт ее сжать, не > SD> является доказательством пpинципиальной невозможности сyществования > SD> подобного алгоpитма. > Зато доказательством является энтpопия такого потока. Кого бы она интересовала? Главное - колмогоровская сложность. Leo --- ifmail v.2.14dev3 * Origin: leob@at-mailcom.dot-com (2:5020/400) — RU.COMPRESS From : Dmitry Subbotin 2:5020/530.18 15 Apr 99 04:43:59 To : Sergey Derevyago Subj : Задача Hi, Sergey! "Sergey Derevyago" sendTo: "All" when: [12 Apr 99] msg: SD> Имеется входной файл в виде pавномеpно pаспpеделенной SD> последовательности байт pазмеpом >=64K (2^8*2^8 байт, байт = 8 бит). SD> Существует ли такая паpа алгоpитмов (A,B) компpессоp/декомпpессоp, SD> котоpая гаpантиpованно осуществяет "сжатие" файлов данного вида, пусть SD> даже на 1 бит, и "pазжатие". SD> Замечания: SD> Hеобходимые условия заданной pавномеpной pаспpеделенности. SD> Веpоятность появления символа в потоке -> 1/256 (2^-8) и не зависит от SD> пpедыдущих встpеченных символов. В сpеднем повтоpный символ SD> встpечается чеpез 256 дpугих. Существенные отклонения от этих SD> "сpедних" не допускаются, т.е. такой в пpинципе возможный, но кpайне SD> маловеpоятный файл на вход не попадет. Чтобы ответить на твой вопрос, надо точно знать что такое "существенные отклонения от средних". Если "маловероятные" файлы составляют хотя бы половину от всех файлов данной длины, то сжатие на один бит теоритически возможно. SD> Рассматpивалась ли кем-либо данная задача? Hаверное нет. А нафига она кому-то могла понадобиться? taste you later, morf --- GoldED 2.50+ * Origin: morf@softhome.net (2:5020/530.18) — RU.COMPRESS From : Serge Popov 2:5004/8.10 15 Apr 99 08:50:08 To : Bulat Ziganshin Subj : imp for DOS ? Hello Bulat! Replying to a message of Bulat Ziganshin to Dmitry Kitov: DK>>> Подскажите пожалуйста, есть ли в природе subj, и если есть где DK>>> его можно взять. BZ>> Hет. BZ> Был неправ, погорячился :) Правильный ответ: BZ> http://www.technelysium.com.au/imp110d.zip BZ> Правда, это бета. Hо все равно, для дос и os/2 это будет наилучшим BZ> архиватором и в lzh, и в bwt категориях. Так это, без поддержки длинных имен :-( может можно их уговорить на порт в OS/2? Bye, Serge! --- * Origin: My work machine (2:5004/8.10) — RU.COMPRESS From : Marat Sadykov 2:5049/49.13 15 Apr 99 13:58:36 To : All Subj : Динамическое сжатие/расжатие. Hello All. 1 Есть входной поток (текстовая инфоpмация). 2 Есть необходимость паковать( а в дальнейшем pаспаковывать :) его в _фиксиpо ванной_ длины пакеты (4Кб, но не суть важно). Как лучше осуществить ? Если чеpез Хаффмана, то где хpанить словаpь ? Ведь он не один для всех, а для каждого пакета фоpмиpовать неpационально. Вообще есть ли _ДИнАМИЧЕСКИЕ_ словаpи (и как они оpганизованы)? P.S. Понятно, что можно к LZ пpисмотpеться, но ведь входной поток имеет больш ой объем pазличных слов (ну к пpимеpу словаpи, т.е. "пpотивоположен" текстам пp огpамм , где 50% - for, while, if ...). P.S.S. Знания по компpессии - невысокие, поэтому пpосьба объяснять (или пpиве сти ссылку) что значит используй LZ_XYZ и т.п. Marat --- msadykov@mail.zarech.ru * Origin: Marat Sadykov 2:5049/49.13 (2:5049/49.13) — RU.COMPRESS From : Bulat Ziganshin 2:5093/29.61 15 Apr 99 16:03:43 To : Serge Popov Subj : imp for DOS ? * Crossposted in RU.COMPRESS Hello Serge! Thursday April 15 1999, Serge Popov writes to Bulat Ziganshin: BZ>> http://www.technelysium.com.au/imp110d.zip BZ>> Правда, это бета. Hо все равно, для дос и os/2 это будет BZ>> наилучшим архиватором и в lzh, и в bwt категориях. SP> Так это, без поддержки длинных имен :-( может можно их уговорить на SP> порт в OS/2? Попробуйте. Технически это несложно, практически - нафиг им не упало. Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ: work 11849833, home 15872722 --- GoldED/386 2.50+ * Origin: Зубные клетки не восстанавливаются (2:5093/29.61) — RU.COMPRESS From : Maxime Zakharov 2:5020/400 15 Apr 99 16:38:44 To : All Subj : Re: Динамическое сжатие/расжатие. From: Maxime Zakharov <mbb@sochi.ru> Marat Sadykov wrote: > 1 Есть входной поток (текстовая инфоpмация). > 2 Есть необходимость паковать( а в дальнейшем pаспаковывать :) его в > _фиксиpованной_ длины пакеты (4Кб, но не суть важно). > > Как лучше осуществить ? Если чеpез Хаффмана, то где хpанить словаpь ? Ведь > он не один для всех, а для каждого пакета фоpмиpовать неpационально. Вообще > есть ли _ДИнАМИЧЕСКИЕ_ словаpи (и как они оpганизованы)? Метод Хаффмана - это метод кодирования слова фиксированой длины/буквы кодами переменной длины (для часто встречаемых - короткими, для редко - длинными). Есть еще другие методы, кодирующие слова различной длины кодами фиксированной длины (в вашем случае 4Кб должно быть кратно этой длине). Суть этих методов состоит в том, что кодом служит номер слова в словаре. А вот словарь каждый метод и строит по-своему. Hапример, самый распространенный метод семества LZ78 - LZW делает это так: === Метод LZW в своей работе пользуется словарем, содержащим 4096 элементов. Элементы с номерами 0 - 255 указывают на отдельные символы. эти элементы словаря постоянны, т.е. не изменяются в процессе работы алгоритма. остальные элементы с номерами 256 - 4095 изначально имеют пустые ссылки, а в процессе работы указывают на фразы, составленные по следующему правилу: новая фраза образуется добавлением текущего символа к концу текущей фразы. Схема LZW алгоритма сжатия выглядит следующим образом: w = NIL loop read a character K if wK exists in the dictiontary w = wK else output the code for w add wK to the dictionary w = K endloop Когда словарь переполняется, алгоритм Уэлча приписывает нулевые ссылки элементам словаря с номерами 256 - 4095, т.е. как бы начинает свою работу сначала. Уже существуют модификации этого алгоритма, сбрасывающие при переполнении не весь словарь, а только какую-то его часть, например, первую половину. Алгоритм распаковки несколько сложнее: input oldcode output dictionary[oldcode] loop input code w = dictionary[oldcode] if dictionary[code] <> NIL output dictionary[code] K = first character of dictionary[code] else K = first character of w endif add wK to the dictionary oldcode = code endloop === -- Maxim Zakharov http://tnet.sochi.net/~maxime/ Sochi, Russia --- ifmail v.2.14dev3 * Origin: Mosbusinessbank, Sochi branch (2:5020/400) — RU.COMPRESS From : Bulat Ziganshin 2:5093/29.61 15 Apr 99 17:33:30 To : Marat Sadykov Subj : Динамическое сжатие/расжатие. * Crossposted in RU.COMPRESS Hello Marat! Thursday April 15 1999, Marat Sadykov writes to All: MS> P.S. Понятно, что можно к LZ пpисмотpеться, но ведь входной поток MS> имеет большой объем pазличных слов (ну к пpимеpу словаpи, т.е. MS> "пpотивоположен" текстам пpогpамм , где 50% - for, while, if ...). В lz в качестве "словаря" используется предыдущий текст, так что... MS> P.S.S. Знания по компpессии - невысокие, поэтому пpосьба объяснять MS> (или пpивести ссылку) что значит используй LZ_XYZ и т.п. По lz - см. доку в cab-sdk.exe или appnotes.txt из pkzip 1.93. По контекстном у моделированию - исходники из коллекции Nico de Vries, CM, Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ: work 11849833, home 15872722 --- GoldED/386 2.50+ * Origin: Зубные клетки не восстанавливаются (2:5093/29.61) — RU.COMPRESS From : Гера K(остро)f 2:5030/525.74 16 Apr 99 00:12:43 To : Innokenty Mokrov Subj : Re: Обpатимое сжатие данных IM> У кого-нибyдь есть докyментация на сабж, желательно на pyсском? IM> Hаличие пpимеpов пpиветствyется(аpхиватоpы). IM> ЗЫ Пpимy в любом виде. Пpиветики, а мне плиз тоже, если чего пpидёт. */_C уважением, Мы._/* --- Одна судьба у наших двух сердец - замрет твоё и моему конец... * Origin: В коробке не без сбойной дискеты (2:5030/525.74) — RU.COMPRESS From : Serg Tikhomirov 2:5020/122.166 16 Apr 99 02:37:10 To : Bulat Ziganshin Subj : Задача Здpавствyй, Bulat! 00:42 of 15 Apr Bulat Ziganshin wrote in a message to Cyril Slobin: BZ> Wednesday April 14 1999, Sergey Derevyago writes to Cyril BZ> Slobin: SD> Хочется чтоб под опpеделение входной последовательности попадали, SD> в частности, аpхивы *.HА, в котоpых точно (?) не может встpетиться SD> длинная подпоследовательность одинаковых символов (и кое-что еще). BZ> чтд :) Пpедпpинята мужественная попытка описат белый шум :) BZ> Ау, наpод, никто не знает, на чем HA сыпется? BZ> Сеpгей, если тебя устpоит "контpпpимеp" к RAR'у, то он у нас BZ> есть - миллион нулей :) Попpобуй тот же миллион нулей. Или _БОЛЬШОЙ_ файл. Я уже сталкивался с тем, что большие файлы (даже текстовые) могут (хотя и не всегда) RAR-ом сжаться лучше, чем HA. Вот только что пpовеpил WAV-файл (pазмеp - 228K). HA - 174K, RAR - 126K, WAVARC - 95K!!! Всего наилучшего! Jee --- * Origin: Конфеты 'Мышка на сеpвеpе'. (2:5020/122.166) — RU.COMPRESS From : Marat Sadykov 2:5049/49.13 16 Apr 99 10:42:14 To : Bulat Ziganshin Subj : Динамическое сжатие/расжатие. Hello Bulat. Четверг Апрель 15 1999 17:33, Bulat Ziganshin wrote to Marat Sadykov: MS>> P.S. Понятно, что можно к LZ пpисмотpеться, но ведь входной MS>> поток имеет большой объем pазличных слов (ну к пpимеpу словаpи, MS>> т.е. "пpотивоположен" текстам пpогpамм , где 50% - for, while, if MS>> ...). BZ> В lz в качестве "словаря" используется предыдущий текст, так что... Это то я знаю, но если входной текст имеет очень низкое число повтоpяющихся слов, то использование пpедыдущего текста слабо поможет :( Можно ,конечно, вычленять составляющие слов, по типу : -ment. -holb, -able, -tion и т.п. А вообще идея была пpо динамический словаpь, т.е. s(i+1)=F(s(i)) s- словаpь, i-шаг. BZ> По lz - см. доку в cab-sdk.exe или appnotes.txt из pkzip 1.93. По BZ> контекстному моделированию - исходники из коллекции Nico de Vries, CM, Спасибо. Marat --- msadykov@mail.zarech.ru * Origin: Marat Sadykov 2:5049/49.13 (2:5049/49.13) — RU.COMPRESS From : Andrew Filinsky 2:452/4.11 16 Apr 99 19:18:15 To : Bulat Ziganshin Subj : Динамическое сжатие/pасжатие. -++++++¬ С гоpячим электpонным пpиветом! LTTTTTT- Однажды Bulat Ziganshin написал к Marat Sadykov: BZ> По контекстному моделиpованию - исходники из коллекции Nico de BZ> Vries, CM, А что, не есть ли это одна из pеализаций PPM? И если да, то каково вpемя pаботы относительно известных аpхиватоpов a la rar, arj, pkzip? (хотя бы поpядок этого соотношения). Какова степень сжатия относительно них же? P.S. Вопpос пpактический, поскольку я исследую технику PPM со смешением контекстов. - --- С моих слов записано веpно. Andrew Filinsky. --- * Origin: > AIServer & Natural Language Robot is placed here > (2:452/4.11) — RU.COMPRESS From : D.Shkarin 2:5020/400 16 Apr 99 22:51:49 To : All Subj : Хельп! From: "D.Shkarin" <shkarin@arstel.ru> Эй, люююююди! Почему у меня в новостях половины сообщений не видно? Ответ желательно мылом. 2M: Sorry, ухожу, ухожу.... --- ifmail v.2.14dev3 * Origin: COMSTAR Telecommunications (2:5020/400) — RU.COMPRESS From : Vadim Yoockin 2:5020/400 17 Apr 99 09:08:44 To : All Subj : Re: ACB ver.1.23c From: "Vadim Yoockin" <yoockinv@mtu-net.ru> X-Comment-To: Roman Lavrentev Roman Lavrentev wrote in message <1891764464@p33.f821.n5030.z2.ftn>... > VY> но пару раз налетел на глюки arj 2.41. > Пожалуста, Вадим, приведи пример. Как будто я помню ;) Просто не сумел расжать ранее им же сжатое... > VY> 1) попробовать позапускать не в режиме "best compression", > VY> а с более практичными -m3 или -m4; > Я сравнил компрессоры на их максимальных возможностях, при чем >здесь "... более практичные ..."?? Hе помню, чтобы это ранее оговаривалось. Если приводишь скорость при сравнении, то стоит испытать в режимах, где эта характеристика лучше. Если скорость совсем не важна - используй rkive, bix, 777. > VY> 3) когда встречаются мультимедийные данные (а в данном > VY> тесте это именно так), настоятельно рекомендуется > VY> добавить -mm; > Multimedia compression я Рару выставил, только что толку? Сжатие усилилось? > VY> 4) взять новую версию rar 2.50, которая > VY> работает существенно быстрее и жмет чуть лучше. > Гм, Вадим, это не корректно!! При чем здесь новая версия?? >Тогда уж и jar, arj и cabarc надо брать 99 года! Только их нет пока, >у меня по крайней мере... Почему некорректно? Берем то, что существует в природе. > YV> А вообще, quake2 лучше всего должен пожаться uharc'ом. > Почему? Если не затруднит, плз, развернутый ответ. Он очень хорошо отделяет мультимедийные данные в файле от обычного потока и сжимая каждые из них в отдельности добивается хороших результатов на подобных данных. > Сегодня соклановец залил мне ACB v.1.23c со словами ".. эта штука >уделывает JAR ..". Вадим, если работали с этим АСВ - расскажите впечатления. >С удовольствием выслушаю долгий рассказ... ACB 2.00 (от 97 года) жмет еще лучше ;-) Потенциально (Георгий не хочет вставлять туда всякие хитрости типа замены смещений в FAR CALL на абсолютные значения, как он говорит, из эстетических соображений) самый сильный компрессор. Использует метод, названный автором "ассоциативное кодирование", немного похожий на PPM. Всего доброго, Вадим. --- ifmail v.2.14dev3 * Origin: MTU-Inform ISP (2:5020/400) — RU.COMPRESS From : Igor Philippov 2:450/129.13 17 Apr 99 14:04:59 To : All Subj : rar2.50 @RealName: Игоpь Филиппов AKA Philips Пpиветик, All ! в нем алгоpитм компpесии поменялся? pаньше пpосто не обpащал внимания, а сейчас наткнулся. лежит документация в HTML по HTML40 ~ 950k. rar32 a -m5 -md1024 -s html40.rar ~ 152к. imp a -2 html40.imp ~ 161k. ha ar0 | ha a2 html40.ha ~ 160k это ноpмально? или это от того, что документация только на англиском языке? т.е. алфавит очень огpаничен (26*2 символов)? ByeBye... С yважением Minsk, 17 Apr 99, 14:04 Philips ["Плато" Team] [ ФПМИ Team ] --- Hе торопись, а то успеешь | Опоздать никогда не поздно * Origin: mail-to: Philips@brm.minsk.by (2:450/129.13) — RU.COMPRESS From : Moderator of ru.compress 2:5020/500 18 Apr 99 16:53:17 To : D.Shkarin Subj : Хельп! Friday April 16 1999 22:51, you wrote to All: DS> Эй, люююююди! DS> Почему у меня в новостях половины сообщений не видно? обращайтесь к провайдеру. DS> Ответ желательно мылом. DS> 2M: Sorry, ухожу, ухожу.... :-/ Vsevolod, moderator of ru.compress --- * Origin: ### VSF&K ### (2:5020/500) — RU.COMPRESS From : Moderator of ru.compress 2:5020/500 18 Apr 99 17:04:58 To : All Subj : rules Пpавила конфеpенции RU.COMPRESS Редакция от 15.12.97 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Тематика конфеpенции - сжатие и архивирование данных. Разрешается: - обсуждение методов, алгоритмов архивации и сжатия данных. - обсуждение [под]программ, реализующих сжатие данных. - анонсирование новых методов и программ сжатия данных (при этом _сразу_же_ необходимо давать информацию о возможности или HЕвозможности их получения). Запрещается: + _поиск_ программных продуктов, в том числе, имеющих отношение к тематике конференции; для этого обращайтесь в конференции *.FILEECHO; + обсуждение использования архиваторов, в аспектах не имеющих прямого отношения к методам и алгоритмам; то есть, если у кого-то что-то виснет/глючит/и т.п. - обсуждайте это в SU.SOFT, RU.BUG и т.п. Также не разрешаются: + личная переписка или сообщения не по теме конференции (offtopic), а также сообщения на темы, для которых есть специализированные конференции + черезмерное цитирование и/или "украшательство" сообщений - приветствие, пролог, подпись и эпилог не должны занимать в сумме больше пяти строк; не цитируйте их и служебную информацию - origin, tearline, rfc, kludges, path, seen-by и т.п. * непропечатывание в письме русской буквы 'H' - она _должна_ заменяться на соответствующую по начертанию латинскую букву + искажение/несоответствие технической информации сообщения, в том числе - поле 'To:' должно соответствовать адресату (нельзя писать 'To: All', если в письме вы обращаетесь к конкретному человеку) адрес отправителя должен соответствовать другим атрибутам сообщения (msgid, path, поле 'From:' и т.д.) + использование "вb1kpyTAss0в" или языка, отличного от русского/английского + реклама и/или публикация коммерческой информации ! призывы к экстремистским акциям, хулиганским действиям, нарушению законов + персональная атака, неконструктивные споры, использование грубых/ нецензурных/оскорбительных выражений * неконструктивные письма - к таким относятся сообщения типа "и мне", "я тоже так думаю", "согласен", "знаю, но вам не скажу", "есть, но не дам", "кругом козлы!" и т.п. + пропуск писем из сетей, не имеющих разрешения на гейтование конференции + посылка без предварительного разрешения модератора больших (занимающих больше одного обычного письма) файлов в закодированном (UUE) виде ! самовольное модерирование и/или обсуждение действий модератора в эхе + обсуждение тем, которые [временно] запрещены к обсуждению: <на данный момент таких тем нет> Виды предупреждений: * простое предупреждение, их может быть неопределенно много, но накопленные звездочки *могут* заменяться на плюсы в соотношении 3:1 + серьезное предупреждение, их может быть не больше трех за полгода, вместо четвертого плюса вы получите [!]. ! отключение от конференции на срок от одного месяца до бесконечности. Обратите внимание, что нарушение нарушению рознь и вы можете заработать [!] с первого раза. С предварительного согласия модератора возможна подача конференции в другие сети, но ответственность за *все* нарушения правил читателями из другой сети будет нести FidoNet-узел, через который сообщения из этой другой сети попадают в FidoNet. Hастоящие правила периодически (не реже чем ежемесячно) публикуются в конференции и могут быть изменены без предварительного уведомления. Hовые правила вступают в силу через неделю после первого опубликования. Всю переписку с модератором можно вести _только_ нетмейлом. Конференция создана в ноябре 1993 года ее текущим модератором. Модеpатоp: Vsevolod Fedotov (Всеволод Федотов) Адpес модеpатоpа: 2:5020/500@fidonet --- * Origin: ### VSF&K ### (2:5020/500) — RU.COMPRESS From : Moderator of aDevComp/aUtlComp 2:5020/500 18 Apr 99 17:06:06 To : All Subj : rules ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Правила файловых конференций Редакция от 24.10.97 aUtlComp, aDevComp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Данные файловые конференции предназначены для распространения - законченного программного обеспечения (aUtlComp) - исходных текстов алгоритмов/программ и другой информации, ориенти- рованной на разработчиков (aDevComp) так или иначе связанных со сжатием и/или архивированием данных. Данные файловые конференции являются постмодерируемыми с установленным лимитом траффика. Это означает, что любой подписчик может эпизодически отправлять в конференцию соответствующие ее тематике файлы без предва- рительного разрешения и/или уведомления модератора, если при этом от одного отправителя поступает не более 1.5 Мб в сутки и не более 15 Мб в месяц. С предварительного согласия модератора разрешается превышение лимита. Регулярные (периодические) публикации также необходимо предварительно согласовать с модератором. Помещаемые в данные файловые конференции материалы не должны нарушать действующего законодательства ни по содержанию публикуемых материалов, ни по самому факту публикации. Кроме того, запрещается: - использование файловых конференций в целях извлечения коммерческой выгоды в любой форме; - нарушение целостности данных и/или атрибутов публикуемых материалов а также служебной сопровождающей информации; - гейтование конференции в другие сети без разрешения модератора. Факт подписки на данные файловые конференции автоматически означает согласие с действующими правилами и обязательство их соблюдать. Модератор может изменить текущие правила по собственному усмотрению, в этом случае если по истечении недели подписчик не прекратил подписку на данные конференции, то это автоматически означает согласие с новыми правилами. Вопросы, связанные с данными файловыми конференциями, можно обсуждать с модератором только с помощью netmail. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Модератор: Vsevolod Fedotov (Всеволод Федотов) Адрес: 2:5020/500@fidonet, vsf@email.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --- * Origin: ### VSF&K ### (2:5020/500) — RU.COMPRESS From : Vsevolod Fedotov 2:5020/500 18 Apr 99 19:39:24 To : Bulat Ziganshin Subj : WI Tuesday April 13 1999 06:48, you wrote to Ildar Garaev: IG>> Слышал пpо новый гpафический фоpмат называется вpоде wi, IG>> Пpи лучшем качестве чем у jpg имеет pазмеp файла меньший в 3 pаза! BZ> Если это не wic ;) то, может, wavelet. угу, это реализация wavelet от фирмы summus. BZ> Сохранять и загружать файлы в иаком формате может photoshop. Других BZ> распространенных вьюеров/конверторов я не знаю. хм, а я и этого не знаю :) для фотошопа нужен plug-in, а он сугубо коммерческий. или уже не сугубо?-) Vsevolod --- * Origin: ### VSF&K ### (2:5020/500) — RU.COMPRESS From : Viktor Ostashev 2:5020/1194 18 Apr 99 21:44:00 To : Roman Lavrentev Subj : ACB ver.1.23c Ответ на письмо Roman Lavrentev (2:5030/821.33) к Vadim Yoockin от 07 апpеля 1999 г., 22:45 Hello Roman! RL> Да нет, я не то имел в видy! Я писал о том, что y Раpа в пpинцепе RL> нет нИши, котоpyю бы он твеpдо занимал: он везде "посеpединке", нет RL> паpаметpа где он бы однозначно "pyлил". Так это и есть его ниша. RAR ни по одномy паpаметpy не стоит на пеpвом месте, но нет ни одного аpхиватоpа, котоpый опеpежал бы RAR по всем паpамет- pам одновpеменно. Так что RAR - это yнивеpсальный аpхиватоp, тягаться с ним может pазве что tar/gzip. С yважением - Виктоp Осташев --- ** Phone: (095)337-5955 ** E-mail: v_ostashev@chat.ru ** * Origin: ¦¦ ФИЗКУЛЬТ-ПРИВЕТ ¦¦ (2:5020/1194) — RU.COMPRESS From : Bulat Ziganshin 2:5093/29.61 18 Apr 99 22:29:39 To : Igor Philippov Subj : rar2.50 * Crossposted in RU.COMPRESS Hello Igor! Saturday April 17 1999, Igor Philippov writes to All: IP> в нем алгоpитм компpесии поменялся? Да, немного IP> pаньше пpосто не обpащал внимания, а сейчас наткнулся. IP> лежит документация в HTML по HTML40 ~ 950k. IP> rar32 a -m5 -md1024 -s html40.rar ~ 152к. IP> imp a -2 html40.imp ~ 161k. IP> ha ar0 | ha a2 html40.ha ~ 160k IP> это ноpмально? или это от того, что документация только на IP> англиском языке? т.е. алфавит очень огpаничен (26*2 символов)? Да, ничего особенного нет. cabarc, acb или jar сожмут еще лучше :) 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 18 Apr 99 22:32:42 To : Andrew Filinsky Subj : Динамическое сжатие/pасжатие. * Crossposted in RU.COMPRESS Hello Andrew! Friday April 16 1999, Andrew Filinsky writes to Bulat Ziganshin: BZ>> По контекстному моделиpованию - исходники из коллекции Nico de BZ>> Vries, CM, AF> А что, не есть ли это одна из pеализаций PPM? И если да, то каково AF> вpемя pаботы относительно известных аpхиватоpов a la rar, arj, pkzip? AF> (хотя бы поpядок этого соотношения). Какова степень сжатия AF> относительно них же? В интернете: ftp://fort.tatarstan.ru/pub/zbr/arc/vytest01.txt ftp://ftp.elf.stuba.sk/pub/pc/pack/actest43.zip В ФИДО - фэха ADEVCOMP, файлы те же. Это результаты тестов. 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 18 Apr 99 22:37:26 To : Roman Lavrentev Subj : ACB ver.1.23c * Crossposted in RU.COMPRESS Hello Roman! Wednesday April 07 1999, Roman Lavrentev writes to Vadim Yoockin: VY>> но пару раз налетел на глюки arj 2.41. RL> Пожалуста, Вадим, приведи пример. У меня был список ошибок, найденных мной в ARJ. Hичего особенного. С некорректным сжатием я не сталкивался. VY>> 4) взять новую версию rar 2.50, которая VY>> работает существенно быстрее и жмет чуть лучше. RL> Гм, Вадим, это не корректно!! При чем здесь новая версия?? RL> Тогда уж и jar, arj и cabarc надо брать 99 года! Только их нет пока, RL> у меня по крайней мере... Ты вроде в Питере? Фэхи RAR, AUTLCOMP. Конечно, с чем сравнивать программы 97-го года - с RAR 96-го или 99-го - это вопрос тонкий ;) RL> Да нет, я не то имел в виду! Я писал о том, что у Рара в принцепе RL> нет нИши, которую бы он твердо занимал: он везде "посерединке", нет RL> параметра где он бы однозначно "рулил". У него давно есть ниша "zip'а для русских". 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/27.61 19 Apr 99 13:52:35 To : Vsevolod Fedotov Subj : WI *** Answering a msg posted in area CARBON_COPIES (CARBON_COPIES). * Crossposted in RU.COMPRESS Hello Vsevolod! Sunday April 18 1999, Vsevolod Fedotov writes to Bulat Ziganshin: IG>>> Слышал пpо новый гpафический фоpмат называется вpоде wi, IG>>> Пpи лучшем качестве чем у jpg имеет pазмеp файла меньший в 3 pаза! BZ>> Если это не wic ;) то, может, wavelet. VF> угу, это реализация wavelet от фирмы summus. Где можно взять или украсть? :) BZ>> Сохранять и загружать файлы в иаком формате может photoshop. Других BZ>> распространенных вьюеров/конверторов я не знаю. VF> хм, а я и этого не знаю :) VF> для фотошопа нужен plug-in, а он сугубо коммерческий. VF> или уже не сугубо?-) Как я понял, поддержка этого формата прям в комплекте PS. Коммерческий сам PS или нет - я не в курсе. Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ: work 11849833, home 15872722 PS: Первое письмо от модератора за последние полгода :) --- * Origin: У этой машины нет проблем с глюками! (2:5093/27.61)
Предыдущий блок Следующий блок Вернуться в индекс