Предыдущий блок Следующий блок Вернуться в индекс
 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)
 Предыдущий блок Следующий блок Вернуться в индекс