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