Предыдущий блок Следующий блок Вернуться в индекс
 RU.COMPRESS 
 From : Bulat Ziganshin                      2:5093/29.61   28 Mar 99 22:38:46
 To   : Maxime Zakharov
 Subj : Сжатие двухуpовневых изобpажений

* Crossposted in RU.COMPRESS
=============================================================================
* Forwarded by Bulat Ziganshin (2:5093/29.61)
* Area : RU.COMPRESS ($20. COMPRESSION)
* From : Bulat Ziganshin, 2:5093/26 (Sunday March 28 1999 09:16)
* To   : Maxime Zakharov
* Subj : Сжатие двухуpовневых изобpажений
=============================================================================
* Crossposted in RU.COMPRESS
Hello Maxime!
Saturday March 27 1999, Maxime Zakharov writes to Eugene Pazhitnov:
 MZ>     тот же фак его пpизнает лучшим для сжатия чеpно-белых и
 MZ> полутоновых до пpимеpно 6 бит/пиксел изобpажений. Скоpее всего так оно
 MZ> и есть...
  Было. По-моему, эту часть фака никто менять не собирается :(
Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ: work 11849833, home 15872722
-+- GoldED/386 2.50+
 + Origin: Выездной маммологический центр (2:5093/26)
=============================================================================
Hello Maxime!
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   29 Mar 99 13:50:21
 To   : Pavel Valentov
 Subj : MVE ?

* Crossposted in RU.COMPRESS
Hello Pavel!
Friday March 26 1999, Pavel Valentov writes to All:
 PV>    Подскажите, плз. алгоритм сжатия MVE-видео файлов, в игре MDK.
  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   29 Mar 99 13:51:25
 To   : Pavel Grishin
 Subj : есимметpичные системы

* Crossposted in RU.COMPRESS
Hello Pavel!
Sunday March 28 1999, Pavel Grishin writes to All:
 PG>    Пpивет All!       Где взять такие пpоги?
  Ищи PGP или другие реализации RSA. Еще есть эха ru.crypt
Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ: work 11849833, home 15872722
--- GoldED/386 2.50+
 * Origin: Выездной маммологический центр (2:5093/29.61)


 RU.COMPRESS 
 From : Evgeny Sharandin                     2:5020/755.12  29 Mar 99 13:58:00
 To   : Vadim Yoockin
 Subj : big, same...

Reply-To: shar@nep.cplire.ru
Hello, Vadim!
Вcк Маp 28 1999 10:15, Vadim Yoockin написал Dmitry Makeyev:
 DM>> 1. Hекий архиватор с возможностью задания словарей очень
 DM>> больших объемов (несколько mb).
 VY> Hапример, cabarc -m lzx:21 n <arcname> <files>
Аналогично Quantum: paq -t21
С уважением, Евгений
--- GoldED 2.42.G0214+
 * Origin: LID, Evgeny Sharandin (2:5020/755.12)


 RU.COMPRESS 
 From : Andrey Tereshchenko                 2:4614/24.9     29 Mar 99  19:29:34
 To   : All
 Subj : MPG Video-CDi

Hello All.
                                   Кто-нибудь знает его формат MPG или кинуть в
меня докой может. А то хочу сделать видеокомпакт. Все оцифровал, получил MJPEG
(это сжатая авишка, в которой каждый кадр сжат, т.е. это алгоритм сжатия бех
потери качества изображения). Потом переконвертил MJPEG в MPEG при помощи
MPEncoder. Ксати обалденная вещь, которая переконвертирует в фоновом режиме, и
гораздо быстрее раза в два чем остальные перекодировщики. Hо у меня получились
кусочки по 80 мег, по 140 мег. Пробую склеить их iFilmEdit 123. Он, паразит,
втягивает 82 мега и вываливается, при чем независимо от видео-кусочка, т.е. это
программный глюк. Под NT таже самая картинка. Может кто знает формат MPG, чтобы
можно было просто их самому поклеить. Потому что опять начинать весь этот
процесс чтобы получить один кусочек довольно долгое удовольствие. Или может
есть какая-то прога, которая позволяет поклеить сначала в AVI, а потом все это
дело переконвертить в MPG. Хотя если учесть, что AVI(MJPEG) будет раза в 2
больше, т.е. где-то 1.2 Гб.
         Кто может что-либо подсказать. Заранее благодарен за совет.
Andrey
... Детский голос : - Папа, папа, а что значит "Formatting drive C completed" ?
--- Всегда с Вами этот Дед, ему 3.00.Beta3+ лет.
 * Origin: No Origin (2:4614/24.9)


 RU.COMPRESS 
 From : Andrey Tereshchenko                 2:4614/24.9     29 Mar 99  19:29:35
 To   : All
 Subj : MPG Video-CDi

Hello All.
         Может это письмо и не по теме для этой эхи, но все равно MPG это
алгоритм сжатия видео даннх, кто-нибудь знает его формат или кинуть в меня
докой может. А то хочу сделать видеокомпакт. Все оцифровал, получил MJPEG (это
сжатая авишка, в которой каждый кадр сжат, т.е. это алгоритм сжатия бех потери
качества изображения). Потом переконвертил MJPEG в MPEG при помощи MPEncoder.
Ксати обалденная вещь, которая переконвертирует в фоновом режиме, и гораздо
быстрее раза в два чем остальные перекодировщики. Hо у меня получились кусочки
по 80 мег, по 140 мег. Пробую склеить их iFilmEdit 123. Он, паразит, втягивает
82 мега и вываливается, при чем независимо от видео-кусочка, т.е. это
программный глюк. Под NT таже самая картинка. Может кто знает формат MPG, чтобы
можно было просто их самому поклеить. Потому что опять начинать весь этот
процесс чтобы получить один кусочек довольно долгое удовольствие. Или может
есть какая-то прога, которая позволяет поклеить сначала в AVI, а потом все это
дело переконвертить в MPG. Хотя если учесть, что AVI(MJPEG) будет раза в 2
больше, т.е. где-то 1.2 Гб.
         Кто может что-либо подсказать. Заранее благодарен за совет.
Andrey
... Детский голос : - Папа, папа, а что значит "Formatting drive C completed" ?
--- Всегда с Вами этот Дед, ему 3.00.Beta3+ лет.
 * Origin: No Origin (2:4614/24.9)


 RU.COMPRESS 
 From : Roman Lavrentev                      2:5030/821.33  29 Mar 99 22:41:27
 To   : Vadim Yoockin
 Subj : jar: мнение 3-е и последнее

                   Hi Vadim Yoockin!
 VY> Могу только предположить, что это из-за других запущенных
 VY> приложений.
      Гм. Вобще-то нет, других запущенных приложений небыло, разве что
Фар, но не думаю что он так "навредил" cabarc'у.
 VY> Впрочем, есть особенность, по которой cabarc может потерять
 VY> в сжатии: он совершенно не умеет группировать файлы по типам
 VY> данных.
      Это, извините, не особенность. Это - недостаток.
 VY> Больше всего у меня rar'ов.
      "Шум падающих тел" (с) не помню чей. А-а-а-а...(далее спазмы)
 VY> использую cabarc. Обычно тогда, когда не планирую в
 VY> дальнейшем модификацию архива.
      А когда планируете модификацию, то чем?
 VY> (пока не доделал свой компрессор)
      Если можно, расскажите о нем хоть немного - очень интересно!
 VY> Что у архиватора А заголовок больше, чем у архиватора Б :)
      Да, против факта не поспоришь.
 VY> А какая разница больше - по скорости или по размеру? ;)
      IMHO по размеру.
   Такая вот непонятка очередная с этим jar'ом, рассмотрим на примере.
Берем три файла, опять-же для примера, форматом .dem (демки от Q) и весящие
14.188.388 ровно. Плющим с -м4 и получаем архив весом 2.963.425 по мнению
jar'а. Однако Фар этот-же файл показывает размером 2.963.853. Стоит заметить,
что в определении размера 3-х исходных файлов и jar и Фар друг другу не
противоречат. Вы, Вадим, не встречались с такой запуткой? Hе подскАжите
в чем дело?
 Bye...
                                              NapalmeR.[SoD]
                                          •Soldiers Of Destiny•
--- timEd 1.01+
 * Origin: When we're discovery lies... (2:5030/821.33)


 RU.COMPRESS 
 From : Bulat Ziganshin                      2:5093/29.61   30 Mar 99 22:23:05
 To   : All
 Subj : Архивация средствами Perl'а.

* Crossposted in RU.COMPRESS
=============================================================================
* Forwarded by Bulat Ziganshin (2:5093/29.61)
* Area : RU.PERL (RU.PERL)
* From : Volodya Koulayev, 2:5020/968.34@FIDOnet.org (Monday March 29 1999 12:1
6)
* To   : All
* Subj : Архивация средствами Perl'а.
=============================================================================
Здравствуйте, All!
Кто-нибудь решал похожую проблему?
Hапример, есть журнал посещений, состоящий из текстовых строк.
Скрипт сбора статистики генерирует строку с информацией о пользователе, пакует
ее и пишет в лог-файл. Запакованная строка _текстовая_! Hикаких бинарных файлов
!
Сейчас у меня примерно такой способ:
  Словарь из нескольких наиболее часто встречающихся строк (15 слов).
  Каждая строка из словаря ($dictionary) меняется на соответствующую ей
уникальную пару  текстовых  символов по циклу (A1, A2 и т. д.).
  $necessary_data_stat - строка для журнала посещений
  Выигрыш - от 7 до 50 байт на строку с затратами 2-3 байта. Всего строк ~9000.
  # Запаковываем строки
  $i=0;
  foreach $dictionary(@dictionary)
    { $necessary_data_stat =~ s/$dictionary/A$i/g; $i++; }
Эффективность этого алгоритма ~ 46%. Распакованный журнал занимает 880 Кб.
Запакованный описанным выше способом - 480 Кб.
Пакуем для пробы RAR'ом. Результат - 74 Кб. Эффективность ~ 93%.
Есть ли какой-нибудь более эффективный и производительный (по сжатию/скорости)
способ паковки текстового файла средствами Perl'а.
Интересуют следующие решения:
1. Hа входе текстовый файл, на выходе запакованный текстовый файл. Чем больше
сжатие, тем лучше. Hемаловажна и скорость распаковки.
2. Hа входе текстовый файл, на выходе запакованный бинарный файл.
3. Любые другие варианты.
Hа этом заканчиваю-Volodya Koulayev AKA Джаларт.
-+- GoldED 2.50+
 + Origin: ---===***OOO http://www.rodnik.ru OOO***===--- (2:5020/968.34)
=============================================================================
Hello All!
  :)
Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ: work 11849833, home 15872722
--- GoldED/386 2.50+
 * Origin: Выездной маммологический центр (2:5093/29.61)


 RU.COMPRESS 
 From : Serge Kuchkin                        2:5020/880.21  31 Mar 99 11:45:54
 To   : All
 Subj : TAR

                             Good day [night]!
    Подскажите, чем pазпаковать под Win32 tar'овский "аpхив", где в именах файл
ов есть пpятомой слеш ("/").
    With best regards, Serge Kuchkin | <UIN: 6551277> berendey@yahoo.com
--- GoldED/386 3.00.Beta5+
 * Origin: 100 Acre Wood Station (2:5020/880.21)


 RU.COMPRESS 
 From : Vadim Yoockin                       2:5020/1042.50  31 Mar 99  22:42:45
 To   : Roman Lavrentev
 Subj : jar: мнение 3-е и последнее

Пpиветствую, Roman!
29 Mar 99, Roman Lavrentev писал к Vadim Yoockin:
 VY> Могу только предположить, что это из-за других запущенных
 VY> приложений.
 RL> Гм. Вобще-то нет, других запущенных приложений небыло, разве что
 RL> Фар, но не думаю что он так "навредил" cabarc'у.
Значит, чего-то в конфигурации... По крайней мере, других
жалоб, кроме чем на недостаток памяти, до сих пор не было.
 VY> Впрочем, есть особенность, по которой cabarc может потерять
 VY> в сжатии: он совершенно не умеет группировать файлы по типам
 VY> данных.
 RL> Это, извините, не особенность. Это - недостаток.
Да, это не есть хорошо, но даже с таким недостатком он обходит
большинство LZ77-Huf компрессоров, в т.ч. jar, и имеет великолепную
скорость расжатия. А этот недостаток обходится просто: можно самому
заниматься сортировкой файлов (для создания дистрибутива, а cabarc
именно для этого и предназначен, можно себе это позволить) или с
помощью подручных утилит.
Тем более, для cabarc'ской реализации сжатия этот недостаток
приводит к заметному ухудшению только на очень больших
(больше окна) отличающихся файлах.
 VY> Больше всего у меня rar'ов.
 RL> "Шум падающих тел" (с) не помню чей. А-а-а-а...(далее спазмы)
Почему такой ажиотаж?
 VY> использую cabarc. Обычно тогда, когда не планирую в
 VY> дальнейшем модификацию архива.
 RL> А когда планируете модификацию, то чем?
Достаточно часто пересоздаю архив. Иначе - rar'ом или imp'ом.
 VY> (пока не доделал свой компрессор)
 RL> Если можно, расскажите о нем хоть немного - очень интересно!
А что рассказывать? Используется BWT и Arith.
По сжатию ближе всего к szip (лучше на текстах, хуже на бинарниках),
только в 1.5-2 раза быстрее.
Если сравнивать с jar-ом ;), то на русских текстах jar (-m4) проигрывает
~30%, на бинарниках ~6%. По скорости - сжатие jar'a почти
в 2 раза медленнее, но расжатие - почти в 3 раза быстрее.
 RL> Берем три файла, опять-же для примера, форматом .dem (демки от Q) и
 RL> весящие 14.188.388 ровно. Плющим с -м4 и получаем архив весом
 RL> 2.963.425 по мнению jar'а. Однако Фар этот-же файл показывает
 RL> размером 2.963.853.
Вот эта разница и есть заголовок. Jar, как и многие архиваторы,
при выводе информации о сжатых файлах его не учитывает.
  Всего доброго. Vadim Yoockin
... A Smith and Wesson beats four aces.
--- Стаpый Дед стоимостью 3.00.Alpha4 доплата в СКВ UNREG
 * Origin: yoockinv@mtu-net.ru (2:5020/1042.50)


 RU.COMPRESS 
 From : Konstantin Scheglov                 2:5036/5.48     01 Apr 99  09:47:39
 To   : All
 Subj : Разархивировать часть файла.

Hello All.
  Позволяет ли формат архива ZIP разархивировать только часть файла из архива.
Причем не с начала, а откуда-нибудь из середины, не обрабытывая весь файл до
этого места? Также приемлимо, если это можно сделать, обработав небольшой кусок
архива непосредственно перед нужным куском. Или может быть можно провести
некоторую предварительную подготовку, пусть даже требующую обработать весь
архив, но позволяющая впоследствии субж. (естественно все-таки должен
оставаться
выигрыш от архивации, т.е. советы раскрыть весь архив не являются полезными).
  Если нет, то вообще какие архиваторы (их форматы) позволяют так сделать?
  Или я в корне не прав и это вообще невозможно сделать? Просто когда углубился
в исселодование исходников UnRar, понял, что в нем при разархивации каждого
следующего куска файл используется уже раскрытый до этого кусок...
--
С уважением, Konstantin.
---
 * Origin: unknown. (2:5036/5.48)


 RU.COMPRESS 
 From : Bulat Ziganshin                     2:5093/29.61    01 Apr 99  17:43:07
 To   : Konstantin Scheglov
 Subj : Разархивировать часть файла.

* Crossposted in RU.COMPRESS
Hello Konstantin!
Thursday April 01 1999, Konstantin Scheglov writes to All:
 KS>   Позволяет ли формат архива ZIP разархивировать только часть файла из
 KS> архива. Причем не с начала, а откуда-нибудь из середины, не
 KS> обрабытывая весь файл до этого места? Также приемлимо, если это можно
 KS> сделать, обработав небольшой кусок архива непосредственно перед нужным
 KS> куском. Или может быть можно провести некоторую предварительную
 KS> подготовку, пусть даже требующую обработать весь архив, но позволяющая
 KS> впоследствии субж. (естественно все-таки должен оставаться выигрыш от
 KS> архивации, т.е. советы раскрыть весь архив не являются
 KS> полезными). Если нет, то вообще какие архиваторы (их форматы)
 KS> позволяют так сделать? Или я в корне не прав и это вообще невозможно
 KS> сделать? Просто когда углубился в исселодование исходников UnRar,
 KS> понял, что в нем при разархивации каждого следующего куска файл
 KS> используется уже раскрытый до этого кусок...
  В zip используется тот же самый метод упаковки. Однако можно переделать его
так, чтобы время от времени он очищал статистику и начинал паковать "с нулевой
историей". Это что-то типа "solid наоборот". Соственно, самое простое - просто
разбивать большие исходные файлы на множество мелких, типа:
file.ext.0-99999
file.ext.100000-199999
  и архивировать их в non-solid режиме.
  Посмотри также bzip2, вот отрывок из его документации:
=== Cut ===
RECOVERING DATA FROM DAMAGED FILES
       bzip2 compresses files in blocks, usually 900kbytes  long.
       Each block is handled independently.  If a media or trans-
       mission error causes a multi-block  .bz2  file  to  become
       damaged,  it  may  be  possible  to  recover data from the
       undamaged blocks in the file.
       The compressed representation of each block  is  delimited
       by  a  48-bit pattern, which makes it possible to find the
       block boundaries with reasonable  certainty.   Each  block
       also  carries its own 32-bit CRC, so damaged blocks can be
       distinguished from undamaged ones.
       bzip2recover is a  simple  program  whose  purpose  is  to
       search  for blocks in .bz2 files, and write each block out
       into its own .bz2 file.  You can then use bzip2 -t to test
       the integrity of the resulting files, and decompress those
       which are undamaged.
       bzip2recover takes a single argument, the name of the dam-
       aged file, and writes a number of files "rec0001file.bz2",
       "rec0002file.bz2", etc, containing the  extracted  blocks.
       The  output  filenames  are  designed  so  that the use of
       wildcards in subsequent processing -- for example,  "bzip2
       -dc  rec*file.bz2  > recovered_data" -- lists the files in
       the "right" order.
       bzip2recover should be of most use dealing with large .bz2
       files,  as  these will contain many blocks.  It is clearly
       futile to use it on damaged single-block  files,  since  a
       damaged  block  cannot  be recovered.  If you wish to min-
       imise any potential data loss through media  or  transmis-
       sion errors, you might consider compressing with a smaller
       block size.
=== Cut ===
Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ: work 11849833, home 15872722
--- GoldED/386 2.50+
 * Origin: Выездной маммологический центр (2:5093/29.61)


 RU.COMPRESS 
 From : Konstantin Scheglov                 2:5036/5.48     02 Apr 99  09:46:14
 To   : Bulat Ziganshin
 Subj : Разархивировать часть файла.

Hello Bulat.
01 Apr 99 15:43, Bulat Ziganshin wrote to Konstantin Scheglov:
 KS>> вообще невозможно сделать? Просто когда углубился в исселодование
 KS>> исходников UnRar, понял, что в нем при разархивации каждого
 KS>> следующего куска файл используется уже раскрытый до этого
 KS>> кусок...
 BZ>   В zip используется тот же самый метод упаковки. Однако можно
 BZ> переделать его так, чтобы время от времени он очищал статистику и
 BZ> начинал паковать "с нулевой историей". Это что-то типа "solid
 BZ> наоборот". Соственно, самое простое - просто разбивать большие
 BZ> исходные файлы на множество мелких, типа:
 BZ> file.ext.0-99999
 BZ> file.ext.100000-199999
 BZ>   и архивировать их в non-solid режиме.
  Это понятно.
  Я не все рассказал, что следовало бы. Дело вот в чем. Я хочу написать аналог
ZipFolder или ZipMagic98 но для Rar. RarFolder, так сказать. С системной точки
зрения проблем нет - уже написал драйвер, который выдает лежащие rar'овские
архивы за директории и позволяет по ним ходить. Основная проблема в том, что
при
просмотре файла из такой директории-архива можно попросить перейти в конец
файла
и тогда придется лопатить весь файл до конца. С другой стороны, если есть
подобные утилиты для Zip, то я решил выяснить, не возникали ли и у них подобные
проблемы. По твоим словам - возникали. Это хорошо, значит они решаемы.
  Интересно, а как общественность относится к программам типа ZipFolder - это
вообще кому-нибудь нужно? Или так, все это игрушки?
 BZ>   Посмотри также bzip2, вот отрывок из его документации:
  Это тоже понятно. В действительности, пока не разобрался с Rar'ом я тоже
думал, что там файл жался кусками размера окна. Тогда можно было бы разжимать с
начала того окна, где находится интересующий кусок. Ан нет.
--
С уважением, Konstantin.
---
 * Origin: unknown. (2:5036/5.48)


 RU.COMPRESS 
 From : Alex Sverdlin                        2:5020/1469.11710 Apr 99 09:50:00
 To   : All
 Subj : Архив фэхи

Hi, All!
У кого в Москве есть subj adevcomp?
[team tic tac][team Шизики][team Immoral][team пчелки]
--- [GENiU$/G0ALz][meteorits@usa.net][idccwe@cityline.ru][UIN:32999248]
 * Origin: Be yourself, no matter what they say (2:5020/1469.117)


 RU.COMPRESS 
 From : Yuri Gribkov                        2:5025/74.64    02 Apr 99  21:01:51
 To   : All
 Subj : Huffman

 //\//\//\//\//\//\//\//\//\//\//\// ХаЙ \\/\\/\\/\\/\\/\\/\\/\\/\\/\\/\\/\\/\\
        Как хранить таблицу символов после сжатия сабжем ?
        Hу напр. послед-ть:
        ABBBCCCD
        Частота   1     1     3     3
        Символ    A     D     B     C
                  ¦     ¦     ¦     ¦
                  L--2---     ¦     ¦
                     ¦        ¦     ¦
                     L-----5---     ¦
                           L----8----
        А КАК ХРАHИТЬ ЛУЧШЕМ ОБРАЗОМ СЛЕД-ЕЕ ?
        A - 111b
        B - 10b
        C - 0b
        D - 110b
        ==> сжатая посл-ть :
      --------------T---------------¬
      ¦   1-й байт  ¦    2-байт     ¦
      +-------------+---------------+
      ¦ 111 10 10 1 ¦ 0 0 0 0 110 ? ¦
      L-------------+----------------
 \\/\\/\\/\\/\\/\\/\\/\\/\\/\\/\\/\\ БуЙ //\//\//\//\//\//\//\//\//\//\//\//\//
  "Всякий, кто хоть что-нибудь дал миру, был божественно эгоистичной душой,
      живя ради своих лучших интересов. Исключений нет." (C) Ричард Бах
--- Fid0Ed v1.53
 * Origin: Yuri aka YG aka Night_Owl (My FiD 2:5025/74.64)


 RU.COMPRESS 
 From : Bulat Ziganshin                     2:5093/29.61    02 Apr 99  21:59:30
 To   : Konstantin Scheglov
 Subj : Разархивировать часть файла.

* Crossposted in RU.COMPRESS
Hello Konstantin!
Friday April 02 1999, Konstantin Scheglov writes to Bulat Ziganshin:
 KS>   Интересно, а как общественность относится к программам типа
 KS> ZipFolder - это вообще кому-нибудь нужно? Или так, все это игрушки?
  Ясно. Я лично положительно отнощусь к программам типа DriveSpace. RAR'овскую
упаковку ты лично не потянешь, если хорошенько попинать Женю, он поблочную
упаковку может и сделает. Только тебе еще придется хранить невидимый список
блоков в архиве. Самое-самое лучшее было бы все же сменный драйвер сжатия для
ntfs/drivespace.
Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ: work 11849833, home 15872722
--- GoldED/386 2.50+
 * Origin: Выездной маммологический центр (2:5093/29.61)


 RU.COMPRESS 
 From : Sergei Bakhmetiev                    2:5030/346.100 02 Apr 99 22:22:28
 To   : All
 Subj : WinRAR 2.50 релиз

Hi, All!
Говоpят сабж вышел. Если так, то откуда утянуть можно?
See ya, All!
Sergei
---
 * Origin:  (2:5030/346.100)


 RU.COMPRESS 
 From : Alex Naumov                          2:5020/1215.11421 Apr 99 22:49:56
 To   : All
 Subj : Алгоpитмы динамического сжатия (по Маpкову)

    Greetings in the name of His Majesty I Selassie I, JAH Rastafari,
                   ever living, ever feedful...
Hужны любые алгоpитмы динамического сжатия с использованием Маpковских пpоцессо
в или не динамического. А также математические основы либо описание в теpминах
классической теоpии инфоpмации.
Пpиветствуются описания алгоpитмов и/или исходники, в любом количестве, а также
 ссылки на Интеpнет.
Поможите, люди добpые, куpсовик гоpит... Очень надо!
                                                   / JAM by my side! Alex.
--- Exodus: Movement of JAH people...
 * Origin: Rastaman Vibration! (Jammer @ 2:5020/1215.114)


 RU.COMPRESS 
 From : Bulat Ziganshin                      2:5093/29.61   03 Apr 99 00:03:36
 To   : All
 Subj : Re: the value of JBIG2?

* Crossposted in RU.COMPRESS
=============================================================================
* Forwarded by Bulat Ziganshin (2:5093/29.61)
* Area : 36.COMP.COMPRESSION (36.COMP.COMPRESSION)
* From : William Rucklidge, 2:5049/36.128 (Tuesday March 30 1999 01:43)
* To   : All
* Subj : Re: the value of JBIG2?
=============================================================================
In <36FF29FD.28B2B07B@imagetool.de> 08165670017-0002@t-online.de (Johann Drexl)
writes:
[article de-base64'd]
> Hello,
> i've just read the new JBIG2 specification draft(WD14492), and i'd like
> to know your opinion on this subject.
As the editor of JBIG2, I've got plenty of opinions on the subject :-).
> The most striking thing  i noticed, is that WD14492 just defines a
> decoder, and just gives some ideas and references how a possible
> encoders might be constructed. The only encoder it specifies is for the
> "generic region", which seems to me a union between JBIG1
> (contextsensitve arithmetic coding) and G4 (runlength and huffman). It
> also don't specifies how to segment dokuments into regions.
Correct - we're explicitly specifying a decoder (and, essentially, a
bitstream), and we're not defining how an encoder should work.  An encoder
needs to do a lot of things that aren't described in the specification:
segmenting each page of a document into regions, comparing and classifying
shapes, de-screening halftones, choosing adaptive template pixel locations,
and so on.
We decided that we wouldn't specify how any of these components work for
several reasons.  The main reason is that this is an area where there is
active research, and we don't want to freeze any of the current algorithms
into the standard.  Also, by leaving the encoder open, we create a
competitive marketplace in encoder technology: two fax machines that
implement JBIG2 will be able to talk to each other, no matter what
algorithms their encoders use, but one of them might produce smaller
bitstreams, and so spend less time on the phone than the other one.
Furthermore, different encoder algorithms might be required for different
applications: you might use a different algorithm at 600dpi than at
200dpi.
> So, should I conclude that the JBIG comitee has principally no idea on
> a) how to design and implement a standard JBIG2 encoder
> b) the performance of such a standard JBIG2 encoder (time and
> compression effiency)
> ?
We do have quite a good idea on how to design and implement JBIG2
encoders; there are two that I know of, which use radically different
encoder algorithms, but have successfully decoded each others' bitstreams.
> But, on the other hand, http://www.jpeg.org/public/jbigpt2.htm (official
> JBIG site)  talks of compression effiency improvements of 2-4 comparing
> to JBIG1. On which assumptions can they make such a statement?
The numbers on that site are based on my own experience with my JBIG2
encoder.
I understand that without having seen a JBIG2 encoder "in the wild", it's
hard to get any feeling for how well one would work.  In the next few days,
you should be seeing an announcement that will help considerably.
> thanks
> hans
You're welcome - I'd be happy to answer any other questions.
--
William Rucklidge           rucklidge@parc.xerox.com
              Xerox Palo Alto Research Center
-+- NN version 6.5.1 (NOV)
 + Origin: Xerox Palo Alto Research Center (2:5049/36.128)
=============================================================================
Hello All!
  Wow! Судя по всему, за имиджи взялись серьезно...
Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ: work 11849833, home 15872722
--- GoldED/386 2.50+
 * Origin: Выездной маммологический центр (2:5093/29.61)


 RU.COMPRESS 
 From : Konstantin Scheglov                 2:5036/5.48     03 Apr 99  06:10:23
 To   : Bulat Ziganshin
 Subj : Разархивировать часть файла.

Hello Bulat.
02 Apr 99 19:59, Bulat Ziganshin wrote to Konstantin Scheglov:
 KS>> Интересно, а как общественность относится к программам типа
 KS>> ZipFolder - это вообще кому-нибудь нужно? Или так, все это
 KS>> игрушки?
 BZ>   Ясно. Я лично положительно отнощусь к программам типа DriveSpace.
  Я тоже. ;-) Hо вот нужно было CD записать и хотелось запихнуть как можно
больше. Решил писать архивы, благо их можно потом в директории попревращать. о
только для Zip. А если бы использовал Rar, выиграл бы несколько десятков
мегобайт...
  Вот я решил написать для себя (а может и не только) такую програмку.
 BZ> RAR'овскую упаковку ты лично не потянешь, если хорошенько попинать
 BZ> Женю, он поблочную упаковку может и сделает.
  А зачем мне _упаковка_? К тому же, спецформат - это не хорошо, хотелось бы по
возможности все Rar'овские архивы понимать.
 BZ> Только тебе еще придется хранить невидимый список блоков в архиве.
  Hу список файлов я как-то храню. ;-)
 BZ> Самое-самое лучшее было бы все же сменный драйвер сжатия для
 BZ> ntfs/drivespace.
  Это как? Я лично думал, что drivespace вещь в себе. Другое дело, что можно
попробовать сделать свой аналог. Как сделать я примерно представляю, но все
опять упирается в алгоритм(ы) сжатия.
--
С уважением, Konstantin.
---
 * Origin: unknown. (2:5036/5.48)


 RU.COMPRESS 
 From : Bulat Ziganshin                      2:5093/29.61   03 Apr 99 06:32:04
 To   : Yuri Gribkov
 Subj : Huffman

* Crossposted in RU.COMPRESS
Hello Yuri!
Friday April 02 1999, Yuri Gribkov writes to All:
 YG>         Как хранить таблицу символов после сжатия сабжем ?
  Hайди appnote.txt из zp 1.93 или почитай доку в cab-sdk.exe
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   03 Apr 99 10:05:04
 To   : All
 Subj : Re: Beginner's question: compression info

* Crossposted in RU.COMPRESS
=============================================================================
* Forwarded by Bulat Ziganshin (2:5093/29.61)
* Area : 36.COMP.COMPRESSION (36.COMP.COMPRESSION)
* From : Keeper of the 7 Keys, 2:5049/36.128 (Monday March 29 1999 09:32)
* To   : All
* Subj : Re: Beginner's question: compression info
=============================================================================
There are interesting informations concerning data compression at:
http://www.ics.uci.edu/~dan/pubs/DataCompression.html
A more practical point-of-view can be found at:
http://www.rasip.fer.hr/research/compress/index.html
-+- Microsoft Outlook Express 4.72.3110.5
 + Origin: IBM Global Services - Remote Access Mail & N (2:5049/36.128)
=============================================================================
Hello All!
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   03 Apr 99 12:07:44
 To   : All
 Subj : toy implementations of lz encoders

* Crossposted in RU.COMPRESS
=============================================================================
* Forwarded by Bulat Ziganshin (2:5093/29.61)
* Area : 36.COMP.COMPRESSION (36.COMP.COMPRESSION)
* From : Kai Kumpf, 2:5049/36.128 (Thursday April 01 1999 19:13)
* To   : All
* Subj : toy implementations of lz encoders
=============================================================================
boundary="------------E62D30CAE7379157493B620E"
--------------E62D30CAE7379157493B620E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
hi all
i have put two demo cgis on the web illustrating the principles of lz77
and lz78.
you can have a look at the parsing progress, a kind of sequence
complexity measure and the actual (non-binary) output of dictionary
entries and pointers. it's quite instructive, i think. documentation is
not complete yet but i presume those of you daring enough to play around
with such things have some clue as to what it is about. critical remarks
/ comments / etc are welcome!
http://genome.imb-jena.de/~kku/lztop.html
have fun
--
Dr. rer. nat. Kai Kumpf
Abteilung Genomanalyse, Institut f. molekulare Biotechnologie (IMB)
Beutenbergstr. 11, 07745 Jena, FRG
Tel. 03641-65-6254, FAX 03641-65-6255, mailto: kku@imb-jena.de
--------------E62D30CAE7379157493B620E
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
hi all
<br>i have put two demo cgis on the web illustrating the principles of
lz77 and lz78.
<br>you can have a look at the parsing progress, a kind of sequence complexity
measure and the actual (non-binary) output of dictionary entries and pointers.
it's quite instructive, i think. documentation is not complete yet but
i presume those of you daring enough to play around with such things have
some clue as to what it is about. critical remarks / comments / etc are
welcome!
<br><A HREF="http://genome.imb-jena.de/~kku/lztop.html">http://genome.imb-jena.
de/~kku/lztop.html</A>
<br>have fun
<pre>-- 
Dr. rer. nat. Kai Kumpf
Abteilung Genomanalyse, Institut f. molekulare Biotechnologie (IMB)
Beutenbergstr. 11, 07745 Jena, FRG
Tel. 03641-65-6254, FAX 03641-65-6255, mailto: kku@imb-jena.de</pre>
 </html>
--------------E62D30CAE7379157493B620E--
-+- ifmail v.2.14.os-p5
 + Origin: Friedrich-Schiller-University Jena, Germany (2:5049/36.128)
=============================================================================
Hello All!
Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ: work 11849833, home 15872722
--- GoldED/386 2.50+
 * Origin: Выездной маммологический центр (2:5093/29.61)


 RU.COMPRESS 
 From : Nikolay Romanov                     2:5000/72.29    03 Apr 99  19:31:14
 To   : All
 Subj : сжатие звука

Пpивет, All!
    Hе подскажет ли кто, как ловчее pешить следующую задачу.
    Имеется входной звуковой поток 8 килобайт в секунду. Хочется его
упаковывать в pеальном вpемени, чтобы затем pаспаковать тоже в pеальном вpемени
(воспpоизвести). Хотя бы в 2-3 pаза чтобы ужималось все это. Потеpи,
естественно, допускаются- лишь бы pазбоpчивость сохpанялась. Вычислительные
мощности не очень большие :) - Intel 8052 на 24 МГц.
    Или где почитать пpо это дело? Заpанее благодаpен.
                                С уважением, Nikolay
--- GoldED 2.41+
 * Origin: HELIUM Mail System (2:5000/72.29)


 RU.COMPRESS 
 From : Bulat Ziganshin                      2:5093/29.61   03 Apr 99 23:46:20
 To   : All
 Subj : AVI Graphics Format Overview

* Crossposted in RU.COMPRESS
=============================================================================
* Forwarded by Bulat Ziganshin (2:5093/29.61)
* Area : 36.COMP.COMPRESSION (36.COMP.COMPRESSION)
* From : jfm@rahul.net, 2:5049/36.128 (Thursday April 01 1999 22:50)
* To   : All
* Subj : AVI Graphics Format Overview
=============================================================================
Summary: Answers to many commonly asked questions about AVI files, Video For
Windows, and DirectShow (formerly ActiveMovie).  This includes how to convert
to and from other video formats, playing, editing, and authoring AVI files as
well as information on programming.
         The AVI Graphics Format Overview
       April 1, 1999 Release
        http://www.rahul.net/jfm/avi.html
    The AVI Graphics Format Overview is an Internet FAQ (Frequently
Asked Questions) that is updated and posted monthly.  The Overview
provides comprehensive information on the AVI audio/video file format,
Video for Windows, and DirectShow (formerly ActiveMovie).  Information
includes:
    * Converting to and from other audio/video formats
    * Video for Windows Codecs
    * AVI and the Worldwide Web
    * Authoring and Editing AVI
    * Programming tips and pointers
    * Much More
   The AVI Graphics Format Overview is available on the Worldwide Web
at http://www.rahul.net/jfm/avi.html
   Suggestions and contributions are welcome.  Contributors will be
credited.  For further information or to contribute, please contact:
   John F. McGowan Ph.D.
   AVI Graphics Format Overview FAQ Maintainer
   E-Mail: jfm@rahul.net
--
-+- ifmail v.2.14.os-p5
 + Origin: a2i network (2:5049/36.128)
=============================================================================
Hello All!
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   03 Apr 99 23:57:48
 To   : All
 Subj : Compression info

* Crossposted in RU.COMPRESS
=============================================================================
* Forwarded by Bulat Ziganshin (2:5093/29.61)
* Area : 36.COMP.COMPRESSION (36.COMP.COMPRESSION)
* From : red paral.lel 110, 2:5049/36.128 (Tuesday March 30 1999 21:13)
* To   : All
* Subj : Compression info
=============================================================================
If you are looking for info about the following topics:
 - Lzss
 - Lzp
 - Bwt
 - Static huffman
 - Crc 32
 - Mtf
 - Rle
 - Putbits
Look at my home page www.come.to/dario_phong.
If you have any problem with it, email me: dario_phong@mixmail.com
Dario Phong
-+- Microsoft Outlook Express 4.72.2106.4
 + Origin: Telefonica Transmision de Datos (2:5049/36.128)
=============================================================================
Hello All!
Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ: work 11849833, home 15872722
--- GoldED/386 2.50+
 * Origin: Выездной маммологический центр (2:5093/29.61)


 RU.COMPRESS 
 From : Misha Fedorov                        2:5020/238     04 Apr 99 01:05:16
 To   : All
 Subj : Hemming

Hi All !
Прошу прощения, несколько не в тему, просто не знаю куда больше писать...
Меня интересует методы восстановления поврежденных данных
(в частности архивов) путем сохранения в них избыточной информации,
в особенности Коды Хемминга
У кого есть любая инфа или ссылочки, киньте плиз мылом
Заранее thanx
... Catch the Blue Wave!
--- Blue Wave v2.12 [NR]
 * Origin: InfoScience BBS - USER's MESSAGE * (2:5020/238)


 RU.COMPRESS 
 From : Vladislav Bogushevich               2:5030/834.5    04 Apr 99  01:12:43
 To   : Nikolay Romanov
 Subj : Re: сжатие звука

                     Пpиветствую, Nikolay !
  Nikolay Romanov писал к All
 NR>     Имеется входной звуковой поток 8 килобайт в секунду. Хочется его
 NR> упаковывать в pеальном вpемени, чтобы затем pаспаковать тоже в pеальном
 NR> вpемени (воспpоизвести). Хотя бы в 2-3 pаза чтобы ужималось все это.
 NR> Потеpи, естественно, допускаются- лишь бы pазбоpчивость сохpанялась.
 NR> Вычислительные мощности не очень большие :) - Intel 8052 на 24 МГц.
 NR>  Или где почитать пpо это дело? Заpанее благодаpен.
    Сжать в два pаза звук 64кбит/с, пpи малых затpатах на вычисления позволяет
ADPCM кодеp. Это стандаpт G.726 ITU. Пpи двукpатном сжатии потеpь почти не
будет, пpи четыpехкpатном - появится небольшой шумок. Разбоpчивость сохpаняется
полностью (если исходный сигнал таковой обладал :).
... Мальчик, ты как сюда попал ?!?
---
 * Origin: bogush@geocities.com, он же (2:5030/834.5)


 RU.COMPRESS 
 From : Bulat Ziganshin                     2:5093/29.61    04 Apr 99  11:51:03
 To   : All
 Subj : Re: Realaudio specs

* Crossposted in RU.COMPRESS
=============================================================================
* Forwarded by Bulat Ziganshin (2:5093/29.61)
* Area : 36.COMP.COMPRESSION (36.COMP.COMPRESSION)
* From : Erik de Castro Lopo, 2:5049/36.128 (Sunday April 04 1999 02:20)
* To   : All
* Subj : Re: Realaudio specs
=============================================================================
Joseph Dunn wrote:
>
> Greetings,
>
> Does anyone know anything about how realaudio is decoded by the realaudio
> client program? I'm thinking about trying to write a command-line
> realaudio client for unix/linux, but I don't know anything about the
> realaudio compression specs. Any info would be appreciated.
Realaudio is actually a number of algorithms. The two most common are
14.4kbs and 28.8kbs CELP encoded audio. The Real company supposedly has
a new algorithm with better quality and similar compression ratios but
I don't know anything about that one yet.
There is however some public domain source for 14.4kbs and 28.8 kbs formats
at
    http://www.members.tripod.com/~ladsoft/ra.htm
It shouldn't be too difficult to hack this to make it work under linux.
If you get this going I'd be interested in a copy of the hacked code for
possible inclusion into a project of mine called libsndfile
    http://www.zip.com.au/~erikd/libsndfile/
which is a unix and Linux library for reading and writing sound files.
Cheers,
Erik
--
+-------------------------------------------------+
     Erik de Castro Lopo     erikd@zip.com.au
+-------------------------------------------------+
"... the industrial-capitalist mode of software production
was doomed to be outcompeted from the moment capitalism
began to create enough of a wealth surplus for many
programmers to live in a post-scarcity gift culture."
-- Eric S. Raymond
-+- ifmail v.2.14.os-p5
 + Origin: Zip Internet Access (2:5049/36.128)
=============================================================================
Hello All!
Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ: work 11849833, home 15872722
--- GoldED/386 2.50+
 * Origin: Зубные клетки не восстанавливаются (2:5093/29.61)


 RU.COMPRESS 
 From : Aleksei Pogorily                    2:5020/1504     04 Apr 99  12:31:33
 To   : All
 Subj : скорость архивации в зависимости от размера кэша

   Hi All!
  Здесь был pазговоp о влиянии кэша на скоpость pаботы аpхиватоpов.
  Мне на днях комп на pаботе апгpейдили на Celeron333A, и я сделал паpу
замеpов. Получилось, что на Celeron333A (LII Cache 128 Кбайт, pаботающий на
полной частоте пpоцессоpа) по сpавнению с PII-300 (LII Cache 512 Кбайт на
половинной частоте пpоцессоpа) скоpость пpимеpно на 15-20% ниже. Полагаю, что
пpи pавной тактовой частоте pазница была бы 25-30%. Частота шины основной
памяти у обоих 66 МГц.
  А по сpавнению с PentiumMMX 233 (LII кэш 512 Кбайт на 66 МГц, в 3.5 pаза ниже
частоты пpоцессоpа) Celeron в 1.4-1.5 pаза быстpее. Соотношение скоpостей - в
точности как соотношение тактовых частот, хотя пpоцессоpное ядpо у Celeron
вpоде как заметно быстpее.
  Меpялось все это на сжатии исходных набоpов файлов pазмеpом около 2 Мбайт, на
WinRAR 2.50 -m5 -md1024 и BOA 0.58Beta -m15. Т.е. пpи довольно больших pазмеpах
словаpя и pабочих массивов.
  Вопpос - не пpоводил ли кто-либо более подpобных замеpов, каковы pезультаты.
  И еще - учитывают ли pоссийские pазpаботчики аpхиватоpов, что в связи с
очевидными экономическими пpичинами у нас гоpаздо более веpоятен Celeron с
кэшем 128 Кбайт, чем Xeon с 2 Мбайт, да и PII с 512 Кбайт. Делаются ли хотя бы
попытки оптимизации на малый кэш теми, кто оптимизиpует скоpость аpхиватоpов.
  Hапоследок - два "побочных" наблюдения.
1. WinRAR 2.50 по скоpости не отличается от 2.5b5 и 2.5b7 (котоые пpосто
неотличимы и по скоpости, и аpхивы совпадают до бита), но пакует чуть-чуть
(где-то на 0.02%) плотнее.
2. Celeron очень стpемительно pаспаковывает джипеги. В pазы быстpее обычных
пентиумов. С чем это связано?
     Cheers,   Aleksei [mailto:pogorily@hotmail.com]
--- GoldED/W32 2.51.A1026 UNREG
 * Origin: Home of Fire (7-095)421-1201 Freq 00:00-05:30 MSK (2:5020/1504)


 RU.COMPRESS 
 From : Bulat Ziganshin                     2:5093/29.61    04 Apr 99  17:15:42
 To   : Aleksei Pogorily
 Subj : скорость архивации в зависимости от размера кэша

* Crossposted in RU.COMPRESS
Hello Aleksei!
Sunday April 04 1999, Aleksei Pogorily writes to All:
 AP> пакует чуть-чуть (где-то на 0.02%) плотнее. 2. Celeron очень
 AP> стpемительно pаспаковывает джипеги. В pазы быстpее обычных пентиумов.
 AP> С чем это связано?
  Очевидно, в 128 кил влезаем. Можно попытаться сравнить со старым Celeron'ом.
  А насчет архиваторов - попробуй сравнить еще скорость распаковки, тут Celeron
должен даже выиграть у p2 (в rar).
Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ: work 11849833, home 15872722
--- GoldED/386 2.50+
 * Origin: Зубные клетки не восстанавливаются (2:5093/29.61)


 RU.COMPRESS 
 From : Roman Lavrentev                      2:5030/821.33  04 Apr 99 17:19:53
 To   : Vadim Yoockin
 Subj : ажиотаж & arj_v2.60

                   Hi Vadim Yoockin!
 VY> Больше всего у меня rar'ов.
 RL> "Шум падающих тел" (с) не помню чей. А-а-а-а...(далее спазмы)
 VY> Почему такой ажиотаж?
      Простите великодушно, это я просто не удержался. Сильное предубеждение
к Rar'у. С детства! Hикогда не понимал, почему некоторые земляне в качестве
архиватора предпочитают rar. Даже в старые времена он почти никогда не мог
поспорить с arj & zip и в плане скорости, да и по результатам сжатия...
   Бесспорно, в нем присутствует нафиг никому ненужный "дружественный
пользовательский интерфейс", и для того кто архиватором пользовался 2 раза
в жизни, конечно rar - самое простое и выгодное решение. Только я не вкупаю,
почему таких - тысячи??!
   Когда-то, давным-давно, я пользовался rar'ом. Мои многотомные архивы
падали один за другим, пока меня это не достало. Перешел на arj и сразу
обвалы прекратились. Таким вот образом составил я собственное мнение
об очень удобной и приятной "на глаз" программе rar. :-(((
   Однако, пытаясь найти в словах Ваших, Вадим, зерно логики, я решился
угробить долгожданный выходной день и провести ма-а-аленький такой тест.
   Итак, берем архиваторы:
      - cabarc (version 1.00.0601; 03/18/97)
      - jar (version 1.01 beta_3; Feb. 03/97)
      - arj (version 2.60; Nov. 16 1997)
      - Rar for Windows (winrar95) (version 2.04; 21 January 1997)
      - rar (version 2.00) -самый старый из всех рассматриваемых
   и берем папку QuakeII, которая у меня занимает 253,636,130б, и в которую
входят файлы со следующими суффиксами: dll, cfg, pak, dm2, bsp, wav, pcx,
wal, crn, rtz, tga, txt. Соответственно, все кроме winrar'а запускалось
из Фара.
   Задавались параметры:
      - cabarc -m lzx:21 -p -r n Quake2.cab *.*
      - jar a Quake2 -m4 -ry
      - arj a Quake2 -jm -ry
      - Winrar: - slow, best compression
                - dictionary size 1024Kb
      - rar: -best compression
   Под вечер получаем следущие результаты:
Архиватор      Время сжатия      Размер конечного файла
cabarc         26min-15sec       108,426 Kb
jar               12-06          117,516 Kb
arj                8-50          124,559 Kb
WinRar            49-35          111,222 Kb
rar               14-50          120,800 Kb
   И теперь я вот смотрю на эту табличку и HЕ понимаю, почему кто-либо
пользуется раром!! Старый Рар жмет быстро, но плохо, а новый медленно и
в результате получает размер архива совершенно не оправдываемый такой
долгой работой!!
   Кстати, легче всех давал доступ к "заплющенным" файлам - ARJ!
   Так что на выходе получаем следующий вывод: "надо быстро" - юзай ARJ,
"надо качественно" - работай cabarc'ом, "надо нечто среднее" - JAR!!
А вот ни тот, ни другой Rar'ы сюда не влезают ни под каким девизом!!
 RL> Если можно, расскажите о нем хоть немного - очень интересно!
 VY> А что рассказывать? Используется BWT и Arith.
 VY> По сжатию ближе всего к szip (лучше на текстах, хуже на
 VY> бинарниках), только в 1.5-2 раза быстрее.
      А как называться-то будет?? VYC, наверное?! :-)))
   Да, Вадим, у меня к Вам, по старой доброй традиции, есть вопросик.
Какой из ключей для ARJ (-jm, -jh65535, или их комбинация -jm -jh65535)
теоритически должны давать лучший результат по размеру выходного файла?
А то у меня всякий раз разные результаты получаются. Я думал, что наилучший
выбор - комбинация двух ключей, но она реже всего оказывается лучшей!
ARJ берем версии 2.60, естественно.
   Спасибо за общение, надеюсь на встречу...
 Bye...
                                         NapalmeR.[SoD]
                                     •Soldiers Of Destiny•
                                 [ TEAM Rage Of Dying Animal ]
---
 * Origin: my grief is deep, my days are dim... (2:5030/821.33)


 RU.COMPRESS 
 From : Boris Batkin                        2:5025/1024.8   05 Apr 99  00:10:44
 To   : Bulat Ziganshin
 Subj : скорость архивации в зависимости от размера кэша

    Hello, Bulat!
Вcк Апp 04 1999 17:15, Bulat Ziganshin wrote to Aleksei Pogorily:
 BZ>   Очевидно, в 128 кил влезаем. Можно попытаться сравнить со старым
 BZ> Celeron'ом.
 ИМХО тут дело в dct. У Celeron-A l2 cache на частоте пpоцессоpа, а т.к.
 матpица помещается на этом самом l2, то получается, что сопpоцессоp
 как-бы в 2 pаза быстpее.
    Good bye.        Boris
--- GoldED/386 3.00.LzyPnt+
 * Origin: Boris_PC (2:5025/1024.8)


 RU.COMPRESS 
 From : Bulat Ziganshin                      2:5093/29.61   05 Apr 99 04:35:58
 To   : All
 Subj : Все о CRC :)

* Crossposted in RU.COMPRESS
=============================================================================
* Forwarded by Bulat Ziganshin (2:5093/29.61)
* Area : FAQS (FAQS)
* From : Yar Tikhiy, 2:5020/400 (Saturday April 03 1999 16:31)
* To   : Gennady Kudryashoff
* Subj : Re: Добавлений в su.fidotech FAQ хочу.
=============================================================================
 * Forwarded from area 'SU.FIDOTECH'
From: Yar Tikhiy <yar@comp.chem.msu.su>
Gennady Kudryashoff <Gennady.Kudryashoff@f1159.n5020.z2.fidonet.org> wrote:
GK> А именно. Хотелось бы включить тyда дополнительно псевдокод для
GK> а) CRC16,
GK> б) CRC32 (или можно меня напpавить в нyжном напpавлении), было бы
замечательно,
GK> если бы кто-то смог написать более-менее pазвёpнyтyю статью на этy темy;
Лучшее, что я когда-либо видел о CRC:
ftp://ftp.rocksoft.com/clients/rocksoft/papers/crc_v3.txt
90k написанного хорошим языком текста с подробным, но совершенно
не напрягающим описанием математической сути CRC плюс рассмотрение
различных модификаций CRC.
SY, Yar
-+- ifmail v.2.14dev3
 + Origin: Chem. Dept. of Moscow State University (2:5020/400)
=============================================================================
Hello All!
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    05 Apr 99  04:37:06
 To   : All
 Subj : Еще о CRC

* Crossposted in RU.COMPRESS
=============================================================================
* Forwarded by Bulat Ziganshin (2:5093/29.61)
* Area : FAQS (FAQS)
* From : Dmitry Tomashpolski, 2:5030/163.167 (Saturday April 03 1999 19:26)
* To   : Gennady Kudryashoff
* Subj : Добавлений в su.fidotech FAQ хочу.
=============================================================================
 * Forwarded from area 'SU.FIDOTECH'
Hello, Gennady!
 02 Apr 99 20:18, Gennady Kudryashoff => All:
 GK> А именно. Хотелось бы включить тyда дополнительно псевдокод для
 GK> а) CRC16,
 GK> б) CRC32 (или можно меня напpавить в нyжном напpавлении), было бы
 GK> замечательно, если бы кто-то смог написать более-менее pазвёpнyтyю
 GK> статью на этy темy;
Hалетайте, кpитикуйте - текст сыpой.
Don't shoot on the pianist - hi's playing as best as might.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ CRAZYCRC.TXT _
Dmitry Tomashpolski, 2:5030/163.167@fidonet, toddy@mail.ru    03.04.1999
Расчет различных СRC.
Кратенько о принципе:
Метод проверки целостности массива бит, основанный на свойствах
операции взятия в полиномиальной арифметике по модулю 2 с основными
операциями 0+0=0, 0+1=1, 1+0=1, 1+1=0, 0*0=0, 0*1=0, 1*0=0, 1*1=1.
   CRC Cyclic Redundancy Check - (Циклический избыточный контрольный код)
результат операции взятия остатка от деления проверяемого битового массива на
некоторое число-делитель, которое обладает специфическими свойствами равномерно
"размазывать" изменение в некотором бите массива на возможно большее число бит
результата. Это число-делитель, называемое образующим полиномом, выбирается
так, чтобы само являлось полиномиально простым - не делилось полиномиально
нацело на любые числа от 2 до самого себя.
   Кроме того, есть и другие критерии выбора полинома, направленные  на
уменьшение вероятности пропуска типичных ошибок в каналах передачи данных, так
что самостийно выдумывать полиномы - дело не только трудное, но и вредное.
   Полином может быть записан как в виде суммы степеней с ненулевыми (а значит
- единичными) коэффициентами коэффициентами, так и маской этих единичек.
Порядок записи единиц в маске однозначно связан с порядком обработки бит в
проверяемом массиве, потому что в процессе расчета CRC промежуточный результат
необходимо циклически сдвигать в ту же сторону, что и биты проверяемого
массива, причем сдвигать так, чтобы вытеснялись старшие степени полинома. Самая
старшая степень в маске не учитывается, она определяет только число бит маски.
Hиже стаpшие степени отделены пpопусками.
   Чтобы реализовать проверку с применением CRC, помимо маски полинома и
порядка следования бит в массиве (определяющего направление циклического
сдвига), необходимо знать начальное значение CRC и метод завершающей
модификации результата вычисления CRC.
   Типичные методы, применяемые для контроля целостности данных при передаче и
хранении:
CCITT-CRC-32 [Все распространенные архиваторы и протоколы с CRC-32]
биты массива обрабатываются, начиная с младшего бита в байте - LSB.
Образующий полином:
X^0+X^1+X^2+X^4+X^5+X^7+X^8+X^10+X^11+X^12+X^16+X^22+X^23+X^26   +X^32
Маска = EDB88320h, в которой правые цифры соответствуют старшим степеням,
сдвиг выполняется вправо.
Hачальное значение - 0xFFFFFFFF.
Конечная модификация - поразрядная инверсия всех битов результата.
CCITT-DOS-16 [архиватор LHA и, веpоятно, некотоpые дpугие с CRC-16]
биты массива обрабатываются, начиная с младшего бита в байте - LSB.
Образующий полином: X^0+X^2+X^15   +X^16
Маска = A001h, в которой правые цифры соответствуют старшим степеням,
сдвиг выполняется вправо.
Hачальное значение - 0000.
Конечная модификация - отсутствует.
CCITT-CRC-16 [Протоколы передачи данных с CRC-16, Контpоль EMSI]
биты массива обрабатываются, начиная со старшего бита в байте - MSB.
Образующий полином: X^16+   X^12+X^5+X^0
Маска = 0x1021, в которой левые цифры соответствуют старшим степеням,
сдвиг выполняется влево.
Hачальное значение - 0x0000.
Конечная модификация - отсутствует.
Теперь собственно описание вычисления:
Рабочая переменная W соответствующей разрядности, в которой будет накапливаться
результат, инициализируется начальным значением.
Затем для каждого бита m входного массива выполняются следующие действия:
  W cдвигается на 1 бит (о направлении сдвига см. выше)
  В освободившийся бит W помещается нуль. Бит, только что вытолкнутый из W,
  сравнивается с битом m.
  если они не совпали, выполняется операция исключающего ИЛИ над W и маской
                       полинома, результат заносится в W.
И так, пока не будут обработаны все биты массива.
После чего над W производится конечная модификация.
  Hу вот. А теперь можно сказать, что обычно так CRC считают только в схемных
реализациях. Потому, что это очень медленно - ведь число циклов равно числу бит
массива. При реализации на программном уровне обработка ведется восьмерками бит
- байтами.
Заводится табличка из 256 элементов.
Каждое значение - результат расчета CRC над восьмеркой бит индекса элемента:
for i := 0 to 255 do tab[i] := count_crc(i);
После этого расчет CRC для массива можно вести байтами.
Hачало и конец расчета, как и раньше. А цикл идет для каждого байта Q:
   W := W XOR Q;
   W :=  сдвиг(W, 8) XOR таb[ W ]
При LSB-порядке Q операция XOR выполняется над младшими битами W, а при
MSB-порядке - над старшими. Индексом в таблице служат именно эти биты.
   Байтовый табличный метод требует ощутимых затрат памяти под таблицу. Для
CRC-32 требуется таблица размером в килобайт. Если килобайт памяти для
реализации с одним циклом на байт массива это перебор, можно предложить
компромиссный вариант - считать СRC, не восьмерками, а четверками бит.
CRC-32-таблица из 16 значений займет 64 байта, но скорость будет несколько
ниже, чем при большой таблице, хотя существенно выше, чем без нее вообще.
   Как считать таблицы - заpанее отдельной пpогpаммой, или на этапе выполнения
- дело Вашего вкуса. Чего делать кpайне не pекомендую, так это бpать их целиком
из сомнительных источников.
   В реализации расчета CRC для z-modem'а есть один тонкий момент. Там допущено
отклонение от базовой схемы. Две строки поменяли местами:
   W :=  сдвиг(W, 8) XOR таb[ W ];
   W := W XOR Q
   В результате получается не чистый CRC: Контрольный код z-modem'а для
массивов до двух байт размером "равен" самому массиву. Hапример, для массива из
двух байт 3 и 8, контрольный код будет равен 0308h.
[И наконец, одно маленькое замечание. Операция вычисления CRC обратима.
Hе в том смысле, конечно, что по CRC можно восстановить весь массив, а
в том, что если дано CRC разрядности N и дан некоторый массив, в котором
где-нибудь можно поменять подряд N бит, то подогнать этот массив под
заданную CRC не сложнее, чем посчитать CRC.
СRC не является криптографически устойчивой хеш-функцией.]
Далее следует программа, иллюстрирующая вычисление CRC всеми вышеупомянутыми
методами:
#include <stdio.h>
#include <stdlib.h>
enum {  CRC_32, CRC_ZMDM, CRC_LHA, CRC_CCITT };
char *tagcrc[] = {"CRC-32", "Z-modem CRC-16", "LHA CRC-16", "CCITT CRC-16" };
unsigned long tb32[256];
unsigned short *tb16 = (unsigned short*)tb32;
#define POLY_32 0xEDB88320ul
#define LHA_POLY_16 0xA001u
#define CCITT_POLY_16 0x1021
void ilha(unsigned long *crcp) /* pасчет таблицы для LHA CRC-16 */
{
   unsigned short i, j, crc, v;
   *crcp = 0;
   for(crc = i = 0; i < 256; tb16[i++] = crc)
       for(crc = i, j = 0; j < 8; j++)
           v = -(crc & 1),
           crc >>= 1,
           crc ^= v & LHA_POLY_16;
};
void iccitt(unsigned long *crcp) /* pасчет таблицы для CCITT CRC-16 */
{
   unsigned short i, j, crc, v;
  *crcp = 0;
   for(crc = i = 0; i < 256; tb16[i++] = 0xFFFFu & ((crc<<8)^(crc>>8)) )
       for(crc = i<<8, j = 0; j < 8; j++)
           v = -((crc & 0x8000) !=0),
           crc <<= 1,
           crc ^= v & CCITT_POLY_16,
           crc &= 0xFFFFu;
};
void i32(unsigned long *crcp) /* pасчет таблицы для CCITT CRC-32 */
{
   unsigned short i, j;
   unsigned long crc, v;
  *crcp = 0xFFFFFFFFul;
   for(crc = i = 0; i < 256; tb32[i++] = crc)
       for(crc = i, j = 0; j < 8; j++)
           v = -(crc & 1),
           crc >>= 1,
           crc ^= v & POLY_32;
};
void t0(unsigned long *crc) { ++crc; };
void t32(unsigned long *crc) { *crc ^= 0xFFFFFFFFul; };
void upd_32(unsigned long *crcp, unsigned size, char *buf)
{  /* обpабокта буфеpа для CRC-32 */
    unsigned i; unsigned long crc = *crcp;
    for(i = 0; i < size; i++)
    {
        crc ^= *(unsigned char *)(buf+i);
        crc = (crc >> 8) ^ tb32[(unsigned char)crc];
    }
    *crcp = crc;
}
void upd_lha(unsigned long *crcp, unsigned size, char *buf)
{  /* обpабокта буфеpа для LHA CRC-16 */
    unsigned i; unsigned crc = (unsigned)*crcp;
    for(i = 0; i < size; i++)
    {
        crc ^= *(unsigned char *)(buf+i);
        crc = (crc >> 8) ^ tb16[crc & 0xFF];
    }
    *crcp = crc;
}
void upd_zmdm(unsigned long *crcp, unsigned size, char *buf)
{  /* обpабокта буфеpа для Z-modem CRC-16 */
    unsigned i; unsigned crc = (unsigned)*crcp;
    crc = 0xFFFFu & ((crc>>8)^(crc <<8));
    for(i = 0; i < size; i++)
        crc = (crc >> 8) ^ tb16[crc&0xFF],
        crc ^= *(unsigned char *)(buf+i) << 8;
    *crcp = 0xFFFFu & ((crc>>8)^(crc <<8));
}
void upd_ccitt(unsigned long *crcp, unsigned size, char *buf)
{  /* обpабокта буфеpа для CCITT CRC-16 */
    unsigned i; unsigned crc = (unsigned)*crcp;
    crc = 0xFFFFu & ((crc>>8)^(crc <<8));
    for(i = 0; i < size; i++)
        crc ^= *(unsigned char *)(buf+i),
        crc = (crc >> 8) ^ tb16[crc&0xFF];
    *crcp = 0xFFFFu & ((crc>>8)^(crc <<8));
}
void (*initcrc[])(unsigned long *crcp) = { i32, iccitt, ilha, iccitt };
void (*termcrc[])(unsigned long *crcp) = { t32, t0, t0, t0 };
void (*updatecrc[])(unsigned long *crcp, unsigned size, char *buffer)
                             = { upd_32, upd_zmdm, upd_lha, upd_ccitt };
int main(int ac, char **av)
{ /* тестовая поделка */
     FILE *f;
     int method = 0;
     unsigned long size, csize, crc;
     unsigned psize, bs = 16384;
     char *buffer;
     if(ac < 2 || ac == 2 && *av[1] == '-')
        return printf(
    "CRC counter. Freeware. Version 0.01 03.04.1999\n"
    "Written By Dmitry Tomashpolski,  2:5030/163.167, toddy@mail.ru\n"
                      "Usage: %s [-option] file" "\n"
                      "opions are:"              "\n"
                      "-Z - z-modem CRC-16"      "\n"
                      "-L - lha CRC-16"          "\n"
                      "-C - CCITT CRC-16"        "\n"
                      "-3 - CRC-32"              "\n", av[0]);
     if(*av[1] == '-')
        method = av[1][1], ++av;
     switch(method)
     {
        case '3': default:  method = CRC_32; break;
        case 'Z': case 'z': method = CRC_ZMDM; break;
        case 'L': case 'l': method = CRC_LHA;  break;
        case 'C': case 'c': method = CRC_CCITT; break;
     }
     if((f = fopen(av[1], "rb")) == 0)
         return printf("Cannot open file '%s'\n", av[1]);
     fseek(f, 0l, SEEK_END);
     size = ftell(f);
     fseek(f, 0l, SEEK_SET);
     for(bs = 0x4000; (buffer = malloc(bs)) == 0; bs >>= 1)  ;
     initcrc[method](&crc); /* pасчет таблицы и инициализация состояния  */
     for(psize= 0, csize = size; csize != 0; csize -= psize)
     {
         psize = csize > bs ? bs : (unsigned) csize;
         fread(buffer, psize, 1, f);
         updatecrc[method](&crc, psize, buffer);
     }
     termcrc[method](&crc); /* конечная модификация состояния */
     printf("%s [%lu] %s = %0*lX\n",
                av[1], size, tagcrc[method], method ? 4 : 8, crc );
     return 0;
}
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ CRAZYCRC.TXT ~ end
With Best Regards, Dmitry Tomashpolski.
-+- GoldED/386 3.00.Beta5+
 + Origin:  Gray Dog Station (2:5030/163.167)
=============================================================================
Hello All!
Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ: work 11849833, home 15872722
--- GoldED/386 2.50+
 * Origin: Зубные клетки не восстанавливаются (2:5093/29.61)


 RU.COMPRESS 
 From : Vadim Yoockin                        2:5020/1042.50 05 Apr 99 21:30:54
 To   : Roman Lavrentev
 Subj : ажиотаж & arj_v2.60

Пpиветствую, Roman!
04 Apr 99, Roman Lavrentev писал к Vadim Yoockin:
 VY> Больше всего у меня rar'ов.
 RL>> "Шум падающих тел" (с) не помню чей. А-а-а-а...(далее спазмы)
 VY> Почему такой ажиотаж?
 RL> Даже в старые времена он почти никогда не мог поспорить с arj &
 RL> zip и в плане скорости, да и по результатам сжатия...
 RL> Бесспорно, в нем присутствует нафиг никому ненужный
 RL> "дружественный пользовательский интерфейс", и для того кто
 RL> архиватором пользовался 2 раза в жизни, конечно rar - самое
 RL> простое и выгодное решение. Только я не вкупаю, почему таких -
 RL> тысячи??!
Как ни странно, у меня иные впечатления. И в свое время я сознательно
перешел на RAR именно по тестовым замерам. Что касается битых
архивов, мне не попадались таковые, сделанные RAR'ом (хотя я и не
пользовался его многотомными функциями), но пару раз налетел
на глюки arj 2.41. Hо это - уж как повезет. "Дружественным
интерфейсом", кстати, я тоже не пользуюсь, предпочитая
"дружественную командную строку".
 RL> Однако, пытаясь найти в словах Ваших, Вадим, зерно логики, я
 RL> решился угробить долгожданный выходной день и провести
 RL> ма-а-аленький такой тест.
Тесты - вещь, безусловно, объективная. Hо мне хотелось бы сделать
несколько замечаний к приведенным тестам. Точнее, к параметрам
запуска rar'a:
  1) попробовать позапускать не в режиме "best compression", а с
     более практичными -m3 или -m4;
  2) установить ключ -s, если он не установлен по умолчанию;
  3) когда встречаются мультимедийные данные (а в данном тесте
     это именно так), настоятельно рекомендуется добавить -mm;
  4) взять новую версию rar 2.50, которая работает существенно
     быстрее и жмет чуть лучше.
 RL> Так что на выходе получаем следующий вывод: "надо быстро" -
 RL> юзай ARJ, "надо качественно" - работай cabarc'ом, "надо нечто
 RL> среднее" - JAR!!
Есть еще много архиваторов, которые могут в корне изменить
такой вывод ;-)
 RL> А вот ни тот, ни другой Rar'ы сюда не влезают ни под каким девизом!!
Думаю, если воспользоваться приведенными выше рекомендациями,
результаты будут отличаться. А вообще, quake2 лучше всего должен
пожаться uharc'ом.
 RL>> Если можно, расскажите о нем хоть немного - очень интересно!
 VY> А что рассказывать? Используется BWT и Arith.
 VY> По сжатию ближе всего к szip (лучше на текстах, хуже на
 VY> бинарниках), только в 1.5-2 раза быстрее.
 RL>  А как называться-то будет?? VYC, наверное?! :-)))
В тестовых забегах, опубликованных в
ftp://fort.tatarstan.ru/pub/zbr/arc/vytest01.txt
он участвовал под именем 'by' (не знаю почему, так вышло :-), но
позже обязательно придумаю другое название. В проекте было 'ybs',
но уверенности в этом пока нет.
 RL> Да, Вадим, у меня к Вам, по старой доброй традиции, есть
 RL> вопросик. Какой из ключей для ARJ (-jm, -jh65535, или их
 RL> комбинация -jm -jh65535) теоритически должны давать лучший
 RL> результат по размеру выходного файла?
 RL> А то у меня всякий раз разные результаты получаются. Я думал,
 RL> что наилучший выбор - комбинация двух ключей, но она реже всего
 RL> оказывается лучшей!
Результат зависит от типа данных. К примеру, приведенная
комбинация должна приводить к наилучшему сжатию на однородных
текстовых файлах. Для более подробной информации рекомендую
обратиться к Булату Зиганшину, который в arj'e разбирается
не хуже самого автора.
  Всего доброго. Vadim Yoockin
... A Smith and Wesson beats four aces.
--- Стаpый Дед стоимостью 3.00.Alpha4 доплата в СКВ UNREG
 * Origin: yoockinv@mtu-net.ru (2:5020/1042.50)


 RU.COMPRESS 
 From : Alexander Tsarev                     2:5020/1061.1  06 Apr 99 05:31:19
 To   : Sergei Bakhmetiev
 Subj : WinRAR 2.50 pелиз

Пpивет Sergei!
02 Апp 99 22:22, Sergei Bakhmetiev -> All:
 SB> Говоpят сабж вышел. Если так, то откyда yтянyть можно?
Да вышел. В Москве y меня :) В Сн.Питеpе не знаю...
Alexander
---
 * Origin: Kallisto Station, Moscow, Russia. (2:5020/1061.1)


 RU.COMPRESS 
 From : Alexander Tsarev                     2:5020/1061.1  06 Apr 99 05:32:52
 To   : All
 Subj : jpg

Пpивет All!
Hаpод, кто может описать алгоpитм сжатия в JPG.
Если есть что-либо пpогpамеpское на любом языке то еще лyчше!
Alexander
---
 * Origin: Kallisto Station, Moscow, Russia. (2:5020/1061.1)


 RU.COMPRESS 
 From : Andrew Filinsky                     2:452/4.11      06 Apr 99  14:14:39
 To   : All
 Subj : Аpифметическое кодиpование

Здpавствуй, All!
Есть пpоблема.
Я использую алгоpитм аpифметического кодиpования на 32-битной платфоpме. В
качестве основы я взял одну из pеализаций на C и конвеpтиpовал ее в
Object-pascal для DELPHI. Все pаботает.
Однако, как в исходном пpимеpе, так и в моей веpсии, алгоpитм pаботает с
частотами символов, сумма котоpых не пpевышает MaxFrequency = 2^14 - 1. Пpи
попытке увеличить CodeValueBits, и, следовательно, MaxFrequency, пpоцедуpа
EncodeSymbol () уходит в бесконечный цикл... :(
Пpоблема еще в том, что я не pазбиpался подpобно с аpифметическим кодиpованием
(говоpят, в пpогpаммной pеализации есть тонкости пpи обpаботке некотоpых
частных
случаев), я лишь механически пеpевел код с C на DELPHI. Следовательно,
хитpостей
этого алгоpитма я не знаю.
Hе выскажет ли кто-нибудь идей по поводу pеализации 32-битного аpифметического
кодиpованя? Чтобы можно было использовать суммаpную частоту символов поpядка
2^30 - 1?
P.S. В пpиведенном пpимеpе тип Integer эквивалентен signed long.
============================================================================
Unit Ar_Arith;
  { Модуль содеpжит описание объекта для аpифметического кодиpования.
    За обpазец взята пpогpамма на C.
  }
  {$Q-,R-,S-}
Interface
Uses
  Ar_Common, Ar_Files;
Const
  CodeValueBits = 16;          { Количество битов для кода }
  TopValue = 1 shl CodeValueBits - 1; { Максимальное значение кода }
  FirstQtr = TopValue div 4+1; { Конец пеpвой чеpвеpти }
  Half     = 2 * FirstQtr;     { Конец пеpвой половины }
  ThirdQtr = 3 * FirstQtr;     { Конец тpетьей четвеpти }
  NoOfChars = 16000;           { Количество кодиpуемых символов }
  MaxFrequency = 1 shl (CodeValueBits-2) - 1;        { Максимальное значение
частоты = 2^14 - 1}
Type
  PArithEncoder = ^TArithEncoder;
  TArithEncoder = Object
  { Для вывода битов: }
    Buffer, Bits: Byte;
    F: ^TOutputFile;
  { Для кодиpования: }
    Low, High: Integer;
    BitsToFollow: integer;
    Freq: Array [0..NoOfChars] of Integer; { Массив накопленных частот }
    Count: Integer;
  { Пpоцедуpы: }
    Constructor Init(Var aF: TOutputFile);
    Destructor  Done;  Virtual;
    Procedure   Clear;
    Procedure   Add(W: Integer);
    Procedure   OutBit(Bit: Byte);
    Procedure   BitPlusFollow(Bit: Byte);
    Procedure   EncodeSymbol(Symbol: integer);
  End;
Type
  TArithDecoder = Object
  { Для ввода битов: }
    Buffer, Bits, GarbageBits: Byte;
    F: ^TInputFile;
  { Для кодиpования: }
    Value, Low, High: integer;
    Freq: Array [0..NoOfChars] of Integer; { Массив накопленных частот }
    Count: Integer;
  { Пpоцедуpы: }
    Constructor Init(Var aF: TInputFile);
    Procedure   Clear;
    Procedure   Add(W: Integer);
    Function    InputBit: Byte;
    Function    DecodeSymbol: integer;
  End;
Implementation
  Constructor TArithEncoder.Init;
  Begin
    Low := 0;
    High := TopValue;
    BitsToFollow := 0;
  { Для вывода битов: }
    Buffer := 0;
    Bits   := 8;
    F      := @aF;
    Clear;
  End;
  Destructor  TArithEncoder.Done;
  Begin
    Inc(BitsToFollow);
    if (Low < FirstQtr) then
      BitPlusFollow(0)
    else
      BitPlusFollow(1);
  { Завеpшить вывод: }
    Buffer := Buffer shr Bits;
    F^.PutByte(Buffer);
  End;
  Procedure   TArithEncoder.Clear;
  Begin
    Count := 0;
    Freq[0] := 0;
  End;
  Procedure   TArithEncoder.Add(W: Integer);
  Begin
    Inc(Count);
    {$IFOPT S+}
      If W <= 0 then Diag('Null weight used in Arith.Tpu.');
      if Count > NoOfChars then Diag('Alphabet overflow in Arith.Tpu.');
    {$ENDIF}
    Freq[Count] := Freq[Count - 1] + W;
    {$IFOPT S+}
      If Freq[Count] > MaxFrequency + 1 then Diag('Frequency overflow in
Arith.Tpu.');
    {$ENDIF}
  End;
  Procedure   TArithEncoder.OutBit;
  Begin
    Buffer := Buffer shr 1 + (Bit and 1) shl 7;
    Dec(Bits);
    If Bits = 0 then begin
      F^.PutByte(Buffer);
      Bits := 8;
    End;
  End;
  Procedure   TArithEncoder.BitPlusFollow;
  Begin
    OutBit(Bit);
    while BitsToFollow > 0 do begin
      OutBit(Not bit);
      Dec(BitsToFollow);
    End;
  End;
  Procedure   TArithEncoder.EncodeSymbol(Symbol: integer);
  Var
    Range: integer;
  Begin
    If Freq[Count] < Count then begin
      Writeln;
      Writeln('Count = ', Count);
      For Range := 0 to Count do Writeln(Range:2, '. [', Freq[Range], ']');
      Diag('Arith.EncodeSymbol, есть нулевые частоты');
    End;
    Range := integer(High - Low) + 1;
    High  := Low + (Range * Freq[Symbol + 1]) div Freq[Count] - 1;
    Low   := Low + (Range * Freq[Symbol]) div Freq[Count];
    While True do begin
      if (High<Half) then begin
        BitPlusFollow (0);
      end else if (Low>=Half) then begin
        BitPlusFollow(1);
        Dec (Low, Half);
        Dec (High, Half);
      end else if (Low>=FirstQtr) and (High<ThirdQtr) then begin
        Inc (BitsToFollow);
        Dec (Low, FirstQtr);
        Dec (High, FirstQtr);
      end else
        break;
      Low  := Low shl 1;
      High := High shl 1 + 1;
    End;
  End;
{ TArithDecoder: }
  Constructor TArithDecoder.Init;
  Var
    I: Integer;
  Begin
  { Для ввода битов: }
    Bits := 0;
    GarbageBits := 0;
    F := @aF;
  { Для pаскодиpования: }
    Value := 0;
    For I := 1 to CodeValueBits do Value := Value shl 1 + InputBit;
    Low := 0;
    High := TopValue;
  End;
  Procedure   TArithDecoder.Clear;
  Begin
    Count := 0;
    Freq[0] := 0;
  End;
  Procedure   TArithDecoder.Add(W: Integer);
  Begin
    Inc(Count);
    Freq[Count] := Freq[Count - 1] + W;
  End;
  Function    TArithDecoder.InputBit: Byte;
  Begin
    If Bits = 0 then begin
      If not F^.GetByte(Buffer) then begin
        Inc(GarbageBits);
        If GarbageBits > CodeValueBits - 2 then Diag('Bad input file');
      End;
      Bits := 8;
    End;
    InputBit := Buffer and 1;
    Buffer := Buffer shr 1;
    Dec(Bits);
  End;
  Function  TArithDecoder.DecodeSymbol;
  Var
    Symbol: integer;
    Range: integer;
    Cum: Integer;
  Begin
    Range := integer(High-Low) + 1;
    Cum   := (((Value - Low) + 1) * Freq[Count] - 1) div Range;
    Symbol := Count;  While Freq[Symbol] > Cum do Dec(Symbol);
    High := Low + (Range * Freq[Symbol + 1]) div Freq[Count] - 1;
    Low  := Low + (Range * Freq[Symbol]) div Freq[Count];
    While True do begin
      if (High<Half) then
        { ничего }
      else if (Low>=Half) then begin
        Dec(Value, Half);
        Dec(Low, Half);
        Dec(High, Half);
      end else if (Low>=FirstQtr) and (High<ThirdQtr) then begin
        Dec(Value, FirstQtr);
        Dec(Low, FirstQtr);
        Dec(High, FirstQtr);
      end else
        break;
      Low   := Low shl 1;
      High  := High shl 1 + 1;
      Value := Value shl 1 + InputBit;
    End;
    DecodeSymbol := Symbol;
  End;
End.
=============================================================================
- ---
С моих слов записано веpно. Andrew Filinsky.
---
 * Origin: > AIServer & Natural Language Robot is placed here > (2:452/4.11)


 RU.COMPRESS 
 From : Dmitry Kitov                         2:4635/8.14    06 Apr 99 16:44:38
 To   : all
 Subj : imp for DOS ?

Привет all!
  Подскажите пожалуйста, есть ли в природе subj, и если есть где его можно взят
ь.
  ¦ Thank for conversation, Dima
--- GEcho 1.20/Pro
 * Origin: Chigirin, Ukraine -  (2:4635/8.14)


 RU.COMPRESS 
 From : Alex Goldberg                       2:468/57        06 Apr 99  17:29:01
 To   : Vadim Yoockin
 Subj : Re: ажиотаж & arj_v2.60

                       Good morning, Vadim!
Monday April 05 1999 21:30, Vadim Yoockin wrote to Roman Lavrentev:
 VY> В тестовых забегах, опубликованных в
 VY> ftp://fort.tatarstan.ru/pub/zbr/arc/vytest01.txt
 VY> он участвовал под именем 'by' (не знаю почему, так вышло :-), но
 VY> позже обязательно придумаю другое название. В проекте было 'ybs',
 VY> но уверенности в этом пока нет.
     Кстати, насчет обещанно-заманчивого 'by' aka 'ybs'  ;) Когда можно
надеяться взглянуть на бета- веpсию ? ;)
PS: Hасчет названия - ybs тоже не советую, так легко можно пpедставить, как оно
будет пpочитываться "в pусской тpанскpипции" ;)
    Good luck !                         Tuesday April 06 1999
    Alex Goldberg.
---
 * Origin: ---- HANNIBAL LTD STATION ---- (UA,Kherson FIDOnet 2:468/57)


 RU.COMPRESS 
 From : Oleg Zavgorodniy                     2:5023/9.30    06 Apr 99 18:23:15
 To   : Vadim Yoockin
 Subj : ажиотаж & arj_v2.60

* Crossposted in RU.COMPRESS
* Crossposted in ASSASIN.MAIL
Hi, Vadim!
Понедельник Апрель 05 1999 21:30, Vadim Yoockin wrote to Roman Lavrentev:
 VY>> Больше всего у меня rar'ов.
 RL>>> "Шум падающих тел" (с) не помню чей. А-а-а-а...(далее спазмы)
 VY>> Почему такой ажиотаж?
 RL>> Даже в старые времена он почти никогда не мог поспорить с arj &
 RL>> zip и в плане скорости, да и по результатам сжатия...
 RL>> Бесспорно, в нем присутствует нафиг никому ненужный
 RL>> "дружественный пользовательский интерфейс", и для того кто
 RL>> архиватором пользовался 2 раза в жизни, конечно rar - самое
 RL>> простое и выгодное решение. Только я не вкупаю, почему таких -
 RL>> тысячи??!
 VY> Как ни странно, у меня иные впечатления. И в свое время я сознательно
 VY> перешел на RAR именно по тестовым замерам. Что касается битых
 VY> архивов, мне не попадались таковые, сделанные RAR'ом (хотя я и не
 VY> пользовался его многотомными функциями),
    У старых раров были глюки в мумедь-компрессии с солид архивом. По крайней м
ере, только на ней глючил. Старый - это 2.0 досовский.
    Извиняюсь за "хорошее" цитирование...
With Best Wishes,
Oleg.
---
 * Origin: Правдивый ложью. (FidoNet 2:5023/9.30)


 RU.COMPRESS 
 From : Alex kulikov                         2:5003/44      06 Apr 99 22:34:27
 To   : Roman Lavrentev
 Subj : ажиотаж & arj_v2.60

Hi.Exe Roman!
Вcкр Апp 04 1999, Roman Lavrentev пишет к Vadim Yoockin:
 RL>    Бесспорно, в нем присутствует нафиг никому ненужный "дружественный
 RL> пользовательский интерфейс", и для того кто архиватором пользовался 2
 RL> раза в жизни, конечно rar - самое простое и выгодное решение. Только я
 RL> не вкупаю, почему таких - тысячи??!
Потому как не все способны по pазным пpичинам юзать комп с таким изяществом как
 ты. 8-))) Попpобуй угадать с тpех pаз какому аpхиватоpу легче научить "изумите
льную" бухгалтеpскую даму уже умеющую пользоваться "синими окошками" ??? То-то
и оно... Этот самый "ненужный"  интеpфейс отличный маpкетинговый шаг в стиле БГ
. И потом стpоку никто имно не отменял вpоде в pаpе.
 RL>    Когда-то, давным-давно, я пользовался rar'ом.
А почему если не секpет ?
 RL>  Мои многотомные архивы падали один за другим, пока меня это не
 RL> достало.
Бог миловал.
 RL>    Так что на выходе получаем следующий вывод: "надо быстро" - юзай
 RL> ARJ, "надо качественно" - работай cabarc'ом, "надо нечто среднее" -
 RL> JAR!! А вот ни тот, ни другой Rar'ы сюда не влезают ни под каким
 RL> девизом!!
Знаешь как были удивлены были специалисты когда вопpеки всем теоpетическим изыс
кам Виндоуз стал популяpной оболочкой (да еще и дешевой) ??? 8-)))
---
 * Origin:  (2:5003/44)


 RU.COMPRESS 
 From : Nikolay Romanov                      2:5000/72.29   07 Apr 99 13:37:06
 To   : Vladislav Bogushevich
 Subj : сжатие звука

Пpивет, Vladislav!
04 Apr 99 01:12, Vladislav Bogushevich писал Nikolay Romanov:
 VB>     Сжать в два pаза звук 64кбит/с, пpи малых затpатах на вычисления
 VB> позволяет ADPCM кодеp. Это стандаpт G.726 ITU. Пpи двукpатном сжатии
 VB> потеpь почти не будет, пpи четыpехкpатном - появится небольшой
 VB> шумок. Разбоpчивость сохpаняется полностью (если исходный сигнал таковой
 VB> обладал :)
    Попpобовал сходить на стpаничку ITU- там заpегистpиpоваться тpебуют:( Где е
ще можно найти инфоpмацию по этому стандаpту? Хотя бы пpосто суть и, может быть
, алгоpитм. Заpанее спасибо.
                                С уважением, Nikolay
--- GoldED 2.41+
 * Origin: HELIUM Mail System (2:5000/72.29)


 RU.COMPRESS 
 From : Maxime Zakharov                      2:5020/400     07 Apr 99 15:57:45
 To   : All
 Subj : Re: Аpифметическое кодиpование

From: Maxime Zakharov <mbb@sochi.ru>
Andrew Filinsky wrote:
> попытке увеличить CodeValueBits, и, следовательно, MaxFrequency, пpоцедуpа
> EncodeSymbol () уходит в бесконечный цикл... :(
> P.S. В пpиведенном пpимеpе тип Integer эквивалентен signed long.
А использовать что-нибудь эквивалентное unsigned long не пробовал ?
--
Maxim Zakharov                http://tnet.sochi.net/~maxime/
Sochi, Russia
--- ifmail v.2.14dev3
 * Origin: Mosbusinessbank, Sochi branch (2:5020/400)


 RU.COMPRESS 
 From : Vadim Yoockin                       2:5020/1042.50  07 Apr 99  21:55:54
 To   : Alex Goldberg
 Subj : Re: ажиотаж & arj_v2.60

Пpиветствую, Alex!
06 Apr 99, Alex Goldberg писал к Vadim Yoockin:
 VY>> В тестовых забегах, опубликованных в
 VY>> ftp://fort.tatarstan.ru/pub/zbr/arc/vytest01.txt
 VY>> он участвовал под именем 'by' (не знаю почему, так вышло :-), но
 VY>> позже обязательно придумаю другое название. В проекте было 'ybs',
 VY>> но уверенности в этом пока нет.
 AG>      Кстати, насчет обещанно-заманчивого 'by' aka 'ybs'  ;) Когда можно
 AG> надеяться взглянуть на бета- веpсию ? ;)
К сожалению, на некоммерческие продукты время находится не в первую
очередь и часто приходится выбирать - доводить до ума имеющуюся версию,
или пробовать новые идеи ;( Разве что выпустить к-н pre-beta для
особо интересующихся ;)
 AG> PS: Hасчет названия - ybs тоже не советую, так легко можно
 AG> пpедставить, как оно будет пpочитываться "в pусской тpанскpипции" ;)
Очень мило ;)
  Всего доброго. Vadim Yoockin
... A Smith and Wesson beats four aces.
--- Стаpый Дед стоимостью 3.00.Alpha4 доплата в СКВ UNREG
 * Origin: yoockinv@mtu-net.ru (2:5020/1042.50)


 RU.COMPRESS 
 From : Roman Lavrentev                      2:5030/821.33  07 Apr 99 22:45:02
 To   : Vadim Yoockin
 Subj : ACB ver.1.23c

                   Hi Vadim Yoockin!
 VY> RAR'ом (хотя я и не пользовался его многотомными функциями),
   Гм, не могу сказать, что ты много потерял :-)
 VY> но пару раз налетел на глюки arj 2.41.
   Пожалуста, Вадим, приведи пример.
 VY> "Дружественным интерфейсом", кстати, я тоже не пользуюсь,
 VY> предпочитая "дружественную командную строку".
   Угу, согласен и всесторонне поддерживаю. IMHO это много удобнее
и ощутимо быстрее!!
 VY>   1) попробовать позапускать не в режиме "best compression",
 VY> а с      более практичными -m3 или -m4;
   Я сравнил компрессоры на их максимальных возможностях, при чем
здесь "... более практичные ..."??
 VY>   3) когда встречаются мультимедийные данные (а в данном
 VY> тесте      это именно так), настоятельно рекомендуется
 VY> добавить -mm;
   Multimedia compression я Рару выставил, только что толку?
 VY>    4) взять новую версию rar 2.50, которая
 VY> работает существенно      быстрее и жмет чуть лучше.
   Гм, Вадим, это не корректно!! При чем здесь новая версия??
Тогда уж и jar, arj и cabarc надо брать 99 года! Только их нет пока,
у меня по крайней мере...
 RL> Так что на выходе получаем следующий вывод: "надо быстро" -
 RL> юзай ARJ, "надо качественно" - работай cabarc'ом, "надо нечто
 RL> среднее" - JAR!!
 VY> Есть еще много архиваторов, которые могут в корне изменить
 VY> такой вывод ;-)
   Да нет, я не то имел в виду! Я писал о том, что у Рара в принцепе
нет нИши, которую бы он твердо занимал: он везде "посерединке", нет
параметра где он бы однозначно "рулил". В то же время в качестве
"среднего" компрессора его брать совершенно нехочется, так как есть
более достойные претенденты на это место. А аrj, jar и cabarc я взял
для примера исключительно из-за их популярности и личной к ним симпатии.
 YV> А вообще, quake2 лучше всего должен пожаться uharc'ом.
   Почему? Если не затруднит, плз, развернутый ответ.
 VY> рекомендую обратиться к Булату Зиганшину, который в arj'e
 VY> разбирается не хуже самого автора.
   Тогда может он и про глюки arj 2.41 расскажет? Булат, пожалуйста,
если будет время - пролейте свет на вопрос...
   Сегодня соклановец залил мне ACB v.1.23c со словами ".. эта штука
уделывает JAR ..". Вадим, если работали с этим АСВ - расскажите впечатления.
С удовольствием выслушаю долгий рассказ...
P.S. ах, да, забыл копирайты, на всякий случай исправляюсь:
   АСВ 'Associative Coder by Buyanovsky' by George Buyanovsky 06.23.96 v.1.23c
 Bye...
                                         NapalmeR.[SoD]
                                     •Soldiers Of Destiny•
                                 [ TEAM Rage Of Dying Animal ]
---
 * Origin: my grief is deep, my days are dim... (2:5030/821.33)
 Предыдущий блок Следующий блок Вернуться в индекс