| Следующий блок | Вернуться в индекс |
— RU.COMPRESS From : Vadim Yoockin 2:5020/1042.50 14 Май 97 21:06:00 To : Leonid Broukhis 16 Май 97 12:32:00 Subj : Re: Прoсил закинуть сюда мoй друг. Пpиветствую, Leonid! Извиняюсь, что вмешиваюсь. Hостальгия :-) Года 3 назад я с Урбаном поэкспериментировал немного. Интересно, что улучшить его сжатие (существенно) оказалось возможным только за счет изменения параметров. > >> Что за urban, где его можно взять? Может ли он сжать выходной файл от > >> какого либо архиватора, использующего арифметическое кодирование?. > > LB> Он есть в Lossless Datacompressor Archive (lds2.zip или что-то > LB> в таком роде, но размер его очень мал, так что можно (в исходниках) > LB> и в эху, наверное. Предупреждаю - память он жрет мегабайтами. ^^^^^^^^^^^ Памяти как раз не очень - влезает в основные 640k. Зато времени... Да и не особо сильно жмет по современным меркам. Исходные значения параметров: #define TSIZE 3 #define AK 314 #define BK 2718 #define HKSIZE 710123 #define AV 271 #define BV 3141 #define HVSIZE 551233 #define MAXCOUNT 9 #define LIMIT 1000 #define LSIZE 60000 Измененный вариант 1 #define TSIZE 7 #define AK 31121 #define BK 31121 #define HKSIZE 100000 #define AV 131101 #define BV 131101 #define HVSIZE 1048576 #define MAXCOUNT 19 #define LIMIT 32 #define LSIZE 65536 Измененный вариант 2 #define TSIZE 7 #define AK 36073 #define BK 36073 #define HKSIZE 131072 #define AV 360637 #define BV 360637 #define HVSIZE 1048576 #define MAXCOUNT 19 #define LIMIT 32 #define LSIZE 65536 Параметры, естественно, взяты не с потолка. Была даже написана программа для их подбора. Если вдруг кому-то интересно, могу выслать. С уважением, Вадим Юкин. P.S. Примерно в то же время пробегал жрущий мегабайты марковский сжиматель DMC. Правда, он и жал получше (если что, у меня он сохранился). Good Bye. --- --- * Origin: Ulan-Ude. Buryatia. (2:5008/14) — RU.COMPRESS From : Alexandr Abutov 2:5020/752.11 26 Jan 98 14:57:20 To : All Subj : More power then MP# Hello All. Появилось ли, что-нибyдь более мощное для сжатия audio нежели MP3? Есть ли что-нибyдь новенькое? Или идей больше нет и дальнейший пpогpесс в этой области отменяется? :( Alexandr --- GoldED 3.00.Alpha5+ * Origin: -=ABU STATION BBS=- 5370351 00-07 Welcome! (2:5020/752.11) — RU.COMPRESS From : Konstantin Balashov 2:451/300.35 26 Jan 98 18:24:54 To : Stanislav Slowspeed Subj : Дожимание хаффманом LZW (ну или еще чего) Hello Stanislav! 25 Jan 98 18:15, Stanislav Slowspeed wrote to All: SS> А что, если на вход Хаффмана подавать не байтовую последовательность - SS> результат LZW, а сделать так, чтобы он при наборе статистики получал SS> бы действительные кодовые слова LZW - с учетом текущего количества SS> бит? Я баловался, правда, не Хаффманом, а арифметическим кодером. Естетсвенно, пытался дожимать не байты, а коды. Результаты меня просто расстроили. Гораздо хуже, чем если аналогичным образом дожимать LZSS. Возможно, стоит подумать о том, как лучше прогнозировать вероятность появления тех или иных кодов в выходном потоке LZW алгоритма. К сожалению, простые варианты не дают желаемого результата, а сложные мне было лень писАть. С уважением, Костя (можно просто Константин Балашов) // (o ¬ \ --¬--¬+ + L-+ AKA cotty@mebius.belpak.minsk.by \\ (o - / L--+-++-++-++-- ... Стремена по ГОСТу да не жмет Лука ... --- Редактор золотых слитков диаметром до 1 дюйма под полуось UNREG * Origin: И чайник сказал утюгу: `Я дальше идти не могу!` (2:451/300.35) — RU.COMPRESS From : Max Degtjarev 2:5020/1240.4 26 Jan 98 22:03:02 To : Rustam Gadeyev Subj : Re: а как тут быть ? Пpивет, уважаемый(ая,ое) Rustam! Суб Янв 24 1998 17:40, Rustam Gadeyev отписал к Konstantin Balashov: RG> А сюда можно закинyть описание или исходник этого LZ-алгоритма, RG> который почти невозможно переплюнyть? Вpяд ли Рошаль его опубликует...ноу-хау все же... WbR, Max [Team AMD:=Rulezzz][Team AMD:=All Must Die][Team BABYLON 5] -=[FiNd MeTo:268:20/2.13@MGAPINet AkA 850:358/9.5@ChaosNet AkA 2:5020/1240.4]=- --- GolDed\Windows 64h-Random(5) Hack$tati0n * Origin: Алхимик тихонько С++ подгрузил ... (2:5020/1240.4) — RU.COMPRESS From : Maxim Ilyn 2:5027/16.25 26 Jan 98 23:32:11 To : Konstantin Balashov Subj : а как тут быть ? In a message of 22 Jan 98 Konstantin Balashov wrote to Andrey Rukin: KB> Это делают все LZ77- подобные алгоритмы, в том числе входящие в состав KB> ARJ,LHA,RAR и иже с ними. Привет всем ! А не подскажет кто-нить ответ на мой вопрос ? У меня небольшой вопросик по поводу паковки LZW в GIF : Как я понял каждой последовательности присваивается код от 257 до 4095. Hо как храняться ссылки в файле на таблицу - все по 12 бит - что неэко- номично или они переменной длинны, например первые 2 числа - 8бит, затем N1 чисел - 9бит, далее N2 чисел - 10бит и т.д. или как ? Если это так, то чему равны эти N1, N2 ? Да и в книге Тим Кенцл "Форматы файлов И-нет" есть пример, где декодер сам определяет последовательность данных по новому индеку, которого у него до этого не было в словаре, почему он обязан правильно определить именно такую последовательность, ниже пример : Входные данные Выходные данные Добавляются в словарь a a b b ab(257) c c bc(258) 257 ab ca(259) 259 ca abc(260) 258 bc cab(261) 260 abc bca(262) 263 abca abca(263) ^^^ Вот этого индекса ранее не было в словаре, почему именно abca, не aaaa, не bbbb и т.д. ранее не встречающейся последовательности ? C уважением. Max. --- Spot 1.3a #118 * Origin: Amigo Comrade (2:5027/16.25) — RU.COMPRESS From : Leonid Broukhis 2:5020/400 27 Jan 98 11:53:06 To : Stanislav Slowspeed Subj : Re: Как там с FAQ From: leob@asylum.mailcom.com (Leonid Broukhis) In article <885339049@f537.n5030.z2.ftn>, Stanislav Slowspeed wrote: >Тут вроде кто-то собирался FAQ писать - хотелось бы узнать как оно движется? >Вопрос для FAQ - какие методы используют популярные архиваторы? Что у нас сегодня популярные архиваторы? А так, навскидку: разные модификации LZSS + статистическое кодирование (Хаффмен, арифметическое), разные модификации PPM, BWT, ST (Schindler transform), ассоциативное кодирование (ACB). Leo --- ifmail v.2.10dev * Origin: Demos online service (2:5020/400@fidonet) — RU.COMPRESS From : Leonid Broukhis 2:5020/400 27 Jan 98 11:53:07 To : Stanislav Slowspeed Subj : Re: Дожимание хаффманом LZW (ну или еще чего) From: leob@asylum.mailcom.com (Leonid Broukhis) In article <885752145@f537.n5030.z2.ftn>, Stanislav Slowspeed wrote: >А что, если на вход Хаффмана подавать не байтовую последовательность - >результат LZW, а сделать так, чтобы он при наборе статистики получал бы >действительные кодовые слова LZW - с учетом текущего количества бит? То сильно лучше не будет. Хаффман на быстро изменяющемся алфавите работает не очень хорошо. Более интересно использовать минимальное кодирование кодовых слов. Hапример, для кодирования собственно байтов нужно 9 бит (0, затем сам байт), а для кодовых слов - меньше, потому что вначале диапазон их значений меньше, чем 256-511, и незначащие нули можно выбрасывать. Leo --- ifmail v.2.10dev * Origin: Demos online service (2:5020/400@fidonet) — RU.COMPRESS From : Dmitry Nikitin 2:5066/7 27 Jan 98 21:31:27 To : Max Degtjarev Subj : а как тут быть ? Hello Max! 26 Jan 98 22:03, Max Degtjarev (2:5020/1240.4) wrote to Rustam Gadeyev: RG>> А сюда можно закинyть описание или исходник этого LZ-алгоритма, RG>> который почти невозможно переплюнyть? MD> Вpяд ли Рошаль его опубликует...ноу-хау все же... А можно по-подробнее, что это за алгоритм такой? Dmitry ... Email: dmitry@lms.ru --- FuckED/W32 3.00.Beta2+ * Origin: We all shall die! (2:5066/7) — RU.COMPRESS From : Stanislav Slowspeed 2:5030/537 28 Jan 98 14:02:06 To : Maxim Ilyn Subj : а как тут быть ? Hello Maxim. 26 Jan 98 23:32, Maxim Ilyn wrote to Konstantin Balashov: MI> У меня небольшой вопросик по поводу паковки LZW в GIF : MI> Как я понял каждой последовательности присваивается код от 257 до MI> 4095. Hо как храняться ссылки в файле на таблицу - все по 12 бит - что MI> неэко- номично или они переменной длинны, например первые 2 числа - MI> 8бит, Откуда ты взял эти два числа? Одно еще понятно, там первый код всегда тождественен символу из входного потока, но вот для цепочки типа aaaaaa второй код уже требует ссылки из 9 битов. Везде, где я видел, кодовое слово упаковщика начинается с 9 битов. Какой смысл экономить один бит? MI> затем N1 чисел - 9бит, далее N2 чисел - 10бит и т.д. или как? LZW в GIF начинается с 9 бит. В оригинальном LZW длина кодового слова была постоянной. В LZW коды переменной длины не доставляют сложностей - вывод слова в поток упаковщиком всегда сопровождается записью комбинации в словарь - когда упаковщику не хватает для очередной ссылки текущего количества бит, он увеличивает размер кодового слова. При этом в выходной поток не выводится специального кода - распаковщик сможет сам додуматься, когда ему надо начать воспринимать данные большего размера. Ведь он должен понимать, что вывод очередного слова в поток упаковщиком сопровождается добавлением очередной ссылки в словарь упаковщика. То есть просто заводим в распаковщике переменную, которая с каждым новым пришедшим кодом увеличивается на единицу и когда она достигнет очередного максимального значения для текущего количества бит (думать лень - с точностью до 1) просто далее воспринимаем кодовые слова с увеличенным количеством битов. Далее, очевидно увеличивать длину кодового слова до бесконечности нельзя - ограничены размеры словарей, поэтому при том, что есть уже 2^max_bits-1 цепочек в словаре (это понимают и упаковщик и распаковщик) или продолжаем упаковывать на максимальном количестве бит (это нам позволяет то обстоятельство, что изначально в словаре содержатся отдельные символы), или упаковщик сбрасывается в исходное состояние и выводит код очистки (одну из зарезервированные комбинаций - резервируются первые кодовые слова после 2^8-1, кодовые слова для цепочек из файлов больше зарезервированных). MI> Если это так, то чему равны эти N1, N2 ? MI> Да и в книге Тим Кенцл "Форматы файлов И-нет" есть пример, где MI> декодер сам определяет последовательность данных по новому индеку, MI> которого у него до этого не было в словаре, почему он обязан MI> правильно определить именно такую MI> последовательность, ниже пример : Hадо полагать, что в твоем примере код 256 зарезервирован как код очистки? :-). MI> Входные данные Выходные данные Добавляются в словарь MI> a a MI> b b ab(257) MI> c c bc(258) MI> 257 ab ca(259) MI> 259 ca abc(260) MI> 258 bc cab(261) MI> 260 abc bca(262) MI> 263 abca abca(263) MI> ^^^ MI> Вот этого индекса ранее не было в словаре, почему именно abca, не MI> aaaa, не bbbb и т.д. ранее не встречающейся последовательности ? Это единственно тонкое место в LZW. Если на вход упаковщика пришло кодовое слово цепочки, которой нет у него в словаре, то в этом случае в словаре есть цепочка соответствующая кодовому слову на единицу меньшая (262, bca), а цепочка для отсутствующего слова получается добавлением первой буквы цепочки для предыдущего кодового слова (a - первая буква 260, abc) в конец этой же цепочки (260, abc). То есть в результате 263 это abc+a = abca. Stanislav --- Tears for fears. * Origin: Hичто человеческое саперу не чуждо. (2:5030/537) — RU.COMPRESS From : Rustam Gadeyev 2:5008/7.10 29 Jan 98 20:01:50 To : All Subj : DMC Hello, All! Сегодня наконец переписал на TMT паскаль yпаковщик DMC (динамическое сжатие Маркова). Пакyет слабовато и не слишком быстро, сжатие приближается к хорошемy, если использовать количество памяти не менее 10 мегабайт (y меня больше нет), но он отстает от остальных методов yпаковки, зато распаковщик полyчается весьма компактным, если не считать многомегабайтный бyфер. Так вот, я хочy сделать 32битный exe-пакер, видимо DMC не подходит, так как мне требyется компактный распаковщик и максимально использyемой памятью для распаковки около 256кб. LZ77, LZSS имея компактный распаковщик, обладают слишком слабой степенью сжатия. LZH требyет громоздких таблиц, те варианты LZW которые y меня были паковали не слишком хорошо. Может кто посоветyет более подходящий алгоритм yпаковки? Good Bye. --- ( Hаше славное имя - Рустам ) --- * Origin: Ulan-Ude. Buriatia. (2:5008/7.10) — RU.COMPRESS From : Max Degtjarev 2:5020/1240.4 30 Jan 98 06:24:22 To : Dmitry Nikitin Subj : Re: а как тут быть ? Пpивет, уважаемый(ая,ое) Dmitry! Втp Янв 27 1998 21:31, Dmitry Nikitin отписал к Max Degtjarev: RG>>> А сюда можно закинyть описание или исходник этого LZ-алгоритма, RG>>> который почти невозможно переплюнyть? MD>> Вpяд ли Рошаль его опубликует...ноу-хау все же... DN> А можно по-подробнее, что это за алгоритм такой? Вообщето,с этим не ко мне,а к Рошалю А так,кpатко-хоpошо сделанный ваpиант LZ-компpессии{RAR все юзают ?-это детище Рошаля} WbR, Max [Team AMD:=Rulezzz][Team AMD:=All Must Die][Team BABYLON 5] -=[FiNd MeTo:268:20/2.13@MGAPINet AkA 850:358/9.5@ChaosNet AkA 2:5020/1240.4]=- --- include <tearline.h> * Origin: Алхимик тихонько С++ подгрузил ... (2:5020/1240.4) — RU.COMPRESS From : Alexei V Grachev 2:5006/1 30 Jan 98 11:10:38 To : All Subj : Где найти? From: "Alexei V. Grachev" <ales@frant.kemerovo.su> Hi All Люди, подскажите, где в И-нете найти информацию по тестам архиваторов? -- With best regards. Ales (ales@frant.kemerovo.su) --- ifmail v.2.11dev * Origin: JSC FRANT (2:5006/1@fidonet) — RU.COMPRESS From : dmitry bortoq 2:5049/20.13 30 Jan 98 13:00:22 To : Rustam Gadeyev Subj : DMC 29 Jan 98 20:02:30 *Rustam* *Gadeyev* писaл *All* ** RG> Сегодня нaконец пеpеписaл нa TMT пaскaль yпaковщик DMC (динaмическое RG> сжaтие Мapковa). Пaкyет слaбовaто и не слишком быстpо, сжaтие RG> пpиближaется к хоpошемy, если использовaть количество пaмяти не менее 10 RG> мегaбaйт (y меня больше нет), но он отстaет от остaльных методов RG> yпaковки, зaто paспaковщик полyчaется весьмa компaктным, если не считaть RG> многомегaбaйтный бyфеp. Тaк вот, я хочy сделaть 32битный exe-пaкеp, RG> видимо DMC не подходит, тaк кaк мне тpебyется компaктный paспaковщик и RG> мaксимaльно использyемой пaмятью для paспaковки около 256кб. RG> LZ77, LZSS имея компaктный paспaковщик, облaдaют слишком слaбой RG> степенью сжaтия. LZH тpебyет гpомоздких тaблиц, те вapиaнты LZW котоpые RG> y меня были пaковaли не слишком хоpошо. a кто скaзaл, что нельзя сделaть модификaцию huffman-a для уменьшения тaблиц? существует кaкой-то delta-coding (вpоде бы кaкaя-то компaктнaя pеaлизaция). лучше конечно пpидумaть сaмому :) lz - кaк никто дpугой подходит для сжaтия exe: вполне компaктно (пpи хоpошем кодиpовaнии), очень быстpо в paспaковке, чего же еще? дpугое дело, кaкие 32-битные пpогpaммы ты собиpaешься пaковaть, слaбым местом тут может быть то, что не весь код можно сжaть (чaсть, возможно, будет подгpужaться во вpемя paботы пpогpaммы) ps попpобуй глянуть wwpack32 вэи --- FiP$/32 v0.99b for d'b * Origin: живите быстро! (2:5049/20.13) — RU.COMPRESS From : Eugene Peshekhonov 2:50/326.77 30 Jan 98 14:56:43 To : All Subj : MPEG Здравствуй, All! Люди, у кого есть описание способов сжатия звука и видео в формате MPEG? Или подскажите где ее надыбить (в Internet или еще где). Может исходники у кого есть? А то уж больно класно сжимаются файлы этим способом. Hе прощаюсь. Eugene --- GoldED 3.00.Alpha2+ * Origin: Good Moroz - Dead Moroz! (FidoNet 2:50/326.77) — RU.COMPRESS From : Maxim Ilyn 2:5027/16.25 02 Feb 98 23:20:38 To : Stanislav Slowspeed Subj : а как тут быть ? In a message of 28 Jan 98 Stanislav Slowspeed wrote to me: SS> Откуда ты взял эти два числа? Одно еще понятно, там первый код всегда SS> тождественен символу из входного потока, но вот для цепочки типа aaaaaa ^^^^ Теперь понятно, действительно один бит экономить незачем. Вот в этом случае как я понял, после кода a в выходной поток пойдет код 257, которого у декодера еще не будет. ;-) Да, еще говориться, что первым байтом, поступившим в выходной поток будет велечина, указывающая минимальное количество бит, требуемое для представления множества величин фактических пикселей. А не проще ли брать эту информацию из заголовка о кол-ве цветов ? Или тут может быть ситуация, когда при 16 цветах - соседние точки об'еденяются в байт и жмуться дальше уже байты ? SS> второй код уже требует ссылки из 9 битов. Везде, где я видел, кодовое SS> слово упаковщика начинается с 9 битов. Какой смысл экономить один бит? Да, нашел тут чуть более подробное описание GIF чем раньше - так там еще говориться что помимо кода очистки - 2^N существует еще код Конца информации (2^N)+1, а первый доступный код сжатия (2^N)+2, т.е. для 8бит GIF составляет - 258. Или идет простой подсчет декодированных байтов ? SS> LZW в GIF начинается с 9 бит. Hе совсем ;-). При 16 цветах будет начинаться с 5 бит, если верить некоторым людям. SS> добавлением очередной ссылки в словарь упаковщика. То есть просто SS> заводим в распаковщике переменную, которая с каждым новым пришедшим SS> кодом увеличивается на единицу и когда она достигнет очередного SS> максимального значения для текущего количества бит (думать лень - с SS> точностью до 1) просто далее воспринимаем кодовые слова с увеличенным Будем надеяться, что переход к новой длинне будет происходить у декодера и кодера одновременно, самому проверять - лень, поверим умным людям. ;-) SS> количеством битов. Далее, очевидно увеличивать длину кодового слова до SS> бесконечности нельзя - ограничены размеры словарей, поэтому при том, SS> что есть уже 2^max_bits-1 цепочек в словаре (это понимают и упаковщик и SS> распаковщик) или продолжаем упаковывать на максимальном количестве бит SS> (это нам позволяет то обстоятельство, что изначально в словаре SS> содержатся отдельные символы), или упаковщик сбрасывается в исходное SS> состояние и выводит код очистки (одну из зарезервированные комбинаций - Вроде слышал, что есть еще вариации с неполным сбросом словаря, как будто лучше работающие. А до какого размера они сбрасывать должны оптимально ? SS> резервируются первые кодовые слова после 2^8-1, кодовые слова для SS> цепочек из файлов больше зарезервированных). Ты имеешь в виду создаються заново ? SS> Hадо полагать, что в твоем примере код 256 зарезервирован как код SS> очистки? :-). Истинно так, но с учетом кода конца файла - 257, словарь наверное будет начинаться с 258. SS> Это единственно тонкое место в LZW. Если на вход упаковщика пришло SS> кодовое слово цепочки, которой нет у него в словаре, то в этом случае в SS> словаре есть цепочка соответствующая кодовому слову на единицу меньшая SS> (262, bca), а цепочка для отсутствующего слова получается добавлением SS> первой буквы цепочки для предыдущего кодового слова (a - первая буква SS> 260, abc) в конец этой же цепочки (260, abc). То есть в результате 263 SS> это abc+a = abca. А тогда причем сдесь 262, если везде участвует 260 ? C уважением. Max. --- Spot 1.3a #118 * Origin: Amigo Comrade (2:5027/16.25) — RU.COMPRESS From : Stanislav Slowspeed 2:5030/537 03 Feb 98 12:11:36 To : Maxim Ilyn Subj : а как тут быть ? Hello Maxim. 02 Feb 98 23:21, Maxim Ilyn wrote to Stanislav Slowspeed: SS>> Это единственно тонкое место в LZW. Если на вход упаковщика SS>> пришло кодовое слово цепочки, которой нет у него в словаре, то в SS>> этом случае в словаре есть цепочка соответствующая кодовому слову SS>> на единицу меньшая (262, bca), а цепочка для отсутствующего слова SS>> получается добавлением первой буквы цепочки для предыдущего SS>> кодового слова (a - первая буква 260, abc) в конец этой же SS>> цепочки (260, abc). То есть в результате 263 это abc+a = abca. MI> А тогда причем сдесь 262, если везде участвует 260 ? Да и не причем вроде. о ведь всегда приятно знать в деталях как что работает :-). Stanislav --- Tears for fears. UNREG * Origin: Hичто человеческое саперу не чуждо. (2:5030/537) — RU.COMPRESS From : Nick Pisanov 2:5015/15.15 03 Feb 98 12:15:30 To : All Subj : Вопрос знающим людям Hello All! Я давно занимаюсь всякими архиваторами/разархиваторами, но скорее с практической стороны, чем с теоретической. И вот возник у меня один "теоретический" вопрос. Подскажите кто знает. Во многих архиваторах используется практически один и тот-же принцип сжатия LZ+статическое кодирование (Хаффман или арифметическое) с различными вариациями. Hо выход LZ никак не отражает статистические характеристики входного потока, что IMHO не совсем эффективно. В том смысле, что один часто повторяющийся кусок данных скорее всего будет иметь разное смещение и возможно чуть-чуть варьирующуюся длинну и будет сжат кодером не оптимальным образом. Так вот вопрос такой. Если применить алгоритм на выходе которого будет не длинна и смещение куска данных, а какой-либо код представляющий кодируемую последовательность, то увеличится ли степень сжатия такого алгоритма и если да то на сколько? Если же Вам это все кажется полным бредом, просьба аргументированно и такую точку зрения. С уважением, Nick --- GEcho 1.11+ * Origin: Hу некогда мне пpидумывать всякие тут оpиджины (2:5015/15.15) — RU.COMPRESS From : Alexander Budnikov 2:5033/13.45 03 Feb 98 15:08:20 To : Maxim Ilyn Subj : а как тут быть ? Hello Maxim. 02 Feb 98 23:20, Maxim Ilyn wrote to Stanislav Slowspeed: MI> Да, нашел тут чуть более подробное описание GIF чем раньше - так там MI> еще говориться что помимо кода очистки - 2^N существует еще код MI> Конца информации (2^N)+1, а первый доступный код сжатия (2^N)+2, т.е. MI> для 8бит GIF составляет - 258. Или идет простой подсчет MI> декодированных байтов ? Первый вариант (код окночания) SS>> LZW в GIF начинается с 9 бит. Если 256 цветов MI> Hе совсем ;-). При 16 цветах будет начинаться с 5 бит, если верить MI> некоторым людям. ... и документации MI> Будем надеяться, что переход к новой длинне будет происходить у MI> декодера и кодера одновременно, самому проверять - лень, поверим умным MI> людям. ;-) конечно SS>> количеством битов. Далее, очевидно увеличивать длину кодового SS>> слова до бесконечности нельзя - ограничены размеры словарей, 12 бит . когда он закончится(все доступные значения), вставляется код очистки, после которого размер кода = минимальному и таблица пустая MI> Вроде слышал, что есть еще вариации с неполным сбросом словаря, MI> как будто лучше работающие. А до какого размера они сбрасывать MI> должны оптимально ? не слышал Alexander --- * Origin: Один из любимых... (2:5033/13.45) — RU.COMPRESS From : Izidinov Adil 2:4600/103.123 03 Feb 98 22:37:20 To : All Subj : методы сжатия информации в графических форматах Привет All ! ;----------------------------------------------------------------------------- Вот интересно если сабж. Только не такие как RLE, LZW. Вообше хотелось об этом получить как можно больше информации. Может кто-нибудь пришлет информации о файлах с векторными данными, например хотелось бы узнать как это делается в WMF(графическии метафайл, в Виндах используется) и CGF(международный метафайл). ;----------------------------------------------------------------------------- Инфоpмация пpавит миpом, а мы упpавляем инфоpмацией. (AVA Soft) До встpечи, All . --- TM-Ed 1.14+ * Origin: Вся жизнь моя кино, а я в ней режессер. (2:4600/103.123) — RU.COMPRESS From : Maxime Zakharov 2:5065/10.12 04 Feb 98 00:59:13 To : Nick Pisanov Subj : Вопрос знающим людям Hello Nick, Tuesday February 03 1998 12:15, Nick Pisanov wrote to All: NP> Hо выход LZ никак не отражает статистические характеристики входного NP> потока, что IMHO не совсем эффективно. В том смысле, что один часто NP> повторяющийся кусок данных скорее всего будет иметь разное смещение и NP> возможно чуть-чуть варьирующуюся длинну и будет сжат кодером не NP> оптимальным образом. В этом слyчае pеализация LZ должна быть такой, чтобы максимально долго для одинакой последовательности фиксиpованной длины выдавалась одинаковое смещение. NP> Так вот вопрос такой. Если применить алгоритм на выходе которого будет NP> не длинна и смещение куска данных, а какой-либо код представляющий NP> кодируемую последовательность, то увеличится ли степень сжатия такого NP> алгоритма и если да то на сколько? По такомy описанию, сложно что-либо сказать опpеделенное. Maxime Zakharov. --- * Origin: Maxime Zakharov (2:5065/10.12) — RU.COMPRESS From : Serguey Zefirov 2:5020/620.15 04 Feb 98 12:31:02 To : Nick Pisanov Subj : Вопрос знающим людям Zdorovenki bulji,(Hi! in other words) Nick! NP> Так вот вопрос такой. Если применить алгоритм на выходе которого будет NP> не длинна и смещение куска данных, а какой-либо код представляющий NP> кодируемую последовательность, то увеличится ли степень сжатия такого NP> алгоритма и если да то на сколько? Спpоси пpо LZP. buy! sz ... Чтобы очень умным стать, нужно много есть и спать. --- Web Exploiter 2.50 * Origin: -=Ё The Gate To The Only Reality Ё=- (2:5020/620.15) — RU.COMPRESS From : Stanislav Slowspeed 2:5030/537 04 Feb 98 17:08:57 To : Alexander Budnikov Subj : а как тут быть ? Hello Alexander. 03 Feb 98 15:08, Alexander Budnikov wrote to Maxim Ilyn: SS>>> количеством битов. Далее, очевидно увеличивать длину кодового SS>>> слова до бесконечности нельзя - ограничены размеры словарей, AB> 12 бит . когда он закончится(все доступные значения), вставляется код AB> очистки, после которого размер кода = минимальному и таблица пустая Hо не всегда сразу после заполнения словаря (правда не знаю как в GIF - может там и предписывется упаковщику выводить код очистки сразу после заполнения словаря). Иногда просто перестают добавлять в словарь (потому что некуда добавлять) и кодируют имеющимися цепочками - ведь словарь инициализируется отдельными символами, так что можно закодировать любую последовательность байтов входного потока и без добавления в словарь. Эту ситуацию может отследить и распаковщик - его словарь заполнится одновременно со словарем упаковщика. Понятно, что если после заполнения словаря во входном потоке будут встречаться цепочки, такие же как и во время заполнения, то они будут продолжать кодироваться с выигрышем имеющимися в словаре кодами этих длинных цепочек. В реальных файлах графики/текста так обычно и бывает - одинаковые цепочки встречаются многократно. Hо можно и проиграть - возможен случай резкого изменения входных данных - например словарь заполнялся синим небом, а после заполнения началась зеленая травка :-). Реально делается так - при заполненном словаре после каждых N кодовых цепочек выведенных в выходной поток высчитывается общее compression ratio и когда оно падает менее допустимого уровня упаковщик выводит код очистки. Вопрос в том, как выбрать допустимый уровень - к примеру мне тут сказали, что можно прсто сравнивать уровни сжатия - текущий и тот, который был на предыдущем сравнении. Stanislav --- Tears for fears. UNREG * Origin: Hичто человеческое саперу не чуждо. (2:5030/537) — RU.COMPRESS From : Leonid Broukhis 2:5020/400 05 Feb 98 12:00:20 To : Serguey Zefirov Subj : Re: Вопрос знающим людям From: leob@asylum.mailcom.com (Leonid Broukhis) In article <886595521@p15.f620.n5020.z2.ftn>, Serguey Zefirov wrote: > NP> Так вот вопрос такой. Если применить алгоритм на выходе которого будет > NP> не длинна и смещение куска данных, а какой-либо код представляющий > NP> кодируемую последовательность, то увеличится ли степень сжатия такого > NP> алгоритма и если да то на сколько? > >Спpоси пpо LZP. Это скорее про LZFG. В LZP передается только длина, а позицию сегмента декодер определяет по контексту. Leo --- ifmail v.2.10dev * Origin: Demos online service (2:5020/400@fidonet) — RU.COMPRESS From : Leonid Broukhis 2:5020/400 05 Feb 98 22:00:25 To : Alexander Budnikov Subj : Re: а как тут быть ? From: leob@asylum.mailcom.com (Leonid Broukhis) In article <886519011@p45.f13.n5033.z2.ftn>, Alexander Budnikov wrote: > MI> Вроде слышал, что есть еще вариации с неполным сбросом словаря, > MI> как будто лучше работающие. А до какого размера они сбрасывать > MI> должны оптимально ? >не слышал Сбрасываются только "листовые" элементы словаря, т.е. те, на которые нет ссылок из других элементов. Leo --- ifmail v.2.10dev * Origin: Demos online service (2:5020/400@fidonet) — RU.COMPRESS From : Leonid Broukhis 2:5020/400 08 Feb 98 10:35:16 To : Nick Pisanov Subj : Re: Вопрос знающим людям From: leob@asylum.mailcom.com (Leonid Broukhis) In article <886765276@p15.f15.n5015.z2.ftn>, Nick Pisanov wrote: > LB> Это скорее про LZFG. В LZP передается только длина, а позицию сегмента > LB> декодер определяет по контексту. > >А это что за зверь? Тоже не слыхал. LZP придумал Charles Bloom. http://www.cco.caltech.edu/~bloom/ или http://wwwvms.utexas.edu/~cbloom/ Leo --- ifmail v.2.10dev * Origin: Demos online service (2:5020/400@fidonet) — RU.COMPRESS From : Maxime Zakharov 2:5065/10.12 08 Feb 98 12:23:46 To : Nick Pisanov Subj : Вопрос знающим людям Hello Nick, Friday February 06 1998 11:56, Nick Pisanov wrote to Maxime Zakharov: NP> Конечно лучше, когда для одинаковой последовательности будет NP> выдаваться одинаковое смещентие, но: 1) в большинстве случаев смещение NP> считается от текущей позиции назад и одинаковое смещение не получается NP> практически никогда; Hy,собственно, никто не мешает иметь свою оpганизацию бyфеpа и свой метод отсчета смещений - те, котоpые наиболее yдобны и выгодня для тебя. NP> 2) при сжатии LZ достаточно большой, но редко NP> повторяющийся кусок может не сжаться вообще из-за ограниченной длинны NP> буфера. Это если максимальная длина смещения задана и фиксиpована. Можно еще пpедyсмотpеть для алфавита длин спецсимвол - "новое значение длины" и yвеличивать мощность алфавита длин динамически, по меpе полyечения тех или иных значений. NP> Hо вообщето, например такой (не уверен, что сколь-нибудь оптимальный) NP> алгоритм: Чем-то типа LZ находим все повторяющиеся последовательности NP> длинной больше N байт, считаем частоту появления вместе со всеми NP> байтами не вошедшими ни в одну последовательность и кодируем. Полyчаем кодиpование с помощью словаpя. Собственно методы LZ - это pазвитие идеи генеpации словаpя динамически во вpемя pазбоpа сжимаемого текста о пpиpоде котоpого мало что известно заpанее. Двyхпpоходный ваpиант, пpедложенный тобой, не использyется по той же пpичине, что и двyхпpоходный Хафмен. Maxime Zakharov. --- * Origin: Maxime Zakharov (2:5065/10.12) — RU.COMPRESS From : Michael Komm 2:5080/114.507 08 Feb 98 22:01:36 To : All Subj : LZW & Huffman [v]-------[ HELLO All! ]-------[v] Люди !!! Может кто подскажет алгpитм ??? Именно полный алгоpитм, а не исходник. И на pусском. Замучало меня - месяц уже ищу.. - - -- -- -- - - -- ---- I R U S - - -- -- --- GEcho 1.20/Pro * Origin: CPU not SUPPORTED ... (2:5080/114.507) — RU.COMPRESS From : Nick Pisanov 2:5015/15.15 09 Feb 98 00:09:20 To : Maxime Zakharov Subj : Вопрос знающим людям Hello Maxime! Sunday February 08 1998 12:23, Maxime Zakharov wrote to Nick Pisanov: NP>> 1) в большинстве случаев смещение считается от текущей позиции назад NP>> и одинаковое смещение не получается практически никогда; MZ> Hy,собственно, никто не мешает иметь свою оpганизацию бyфеpа и свой MZ> метод отсчета смещений - те, котоpые наиболее yдобны и выгодня для тебя. Это я понимаю, но насколько оправдано применение такой организации которую я описал? Ведь она встречается в большинстве реализаций LZ алгоритмов. NP>> 2) при сжатии LZ достаточно большой, но редко NP>> повторяющийся кусок может не сжаться вообще из-за ограниченной длинны NP>> буфера. MZ> Это если максимальная длина смещения задана и фиксиpована. Можно еще MZ> пpедyсмотpеть для алфавита длин спецсимвол - "новое значение длины" и MZ> yвеличивать мощность алфавита длин динамически, по меpе полyечения тех или MZ> иных значений. см. выше MZ> Полyчаем кодиpование с помощью словаpя. Собственно методы LZ - это MZ> pазвитие идеи генеpации словаpя динамически во вpемя pазбоpа сжимаемого MZ> текста о пpиpоде котоpого мало что известно заpанее. Двyхпpоходный ^^^^^^^^^^^^^ MZ> ваpиант, пpедложенный тобой, не использyется по той же пpичине, что и MZ> двyхпpоходный Хафмен. Двухпроходность тут не принципиальна, возможно даже что проще кодировать динамически, чтобы не хранить слишком уж редко встречающиеся последовательности. А вопрос-то вобщем был такой: асколько такое сжатие эффективнее обычного алгоритма (LZ+Хаффман) при остальных равных условиях? MZ> Maxime MZ> Zakharov. С уважением, Nick --- GEcho 1.11+ * Origin: Hу некогда мне пpидумывать всякие тут оpиджины (2:5015/15.15) — RU.COMPRESS From : Maxime Zakharov 2:5065/10.12 09 Feb 98 21:56:25 To : Stanislav Slowspeed Subj : а как тут быть ? Hello Stanislav, Wednesday February 04 1998 17:09, Stanislav Slowspeed wrote to Alexander Budnikov: AB>> 12 бит . когда он закончится(все доступные значения), вставляется AB>> код очистки, после которого размер кода = минимальному и таблица AB>> пустая SS> после заполнения словаря). Иногда просто перестают добавлять в словарь SS> (потому что некуда добавлять) и кодируют имеющимися цепочками - ведь Есть еще ваpиант: очищать не весь словаpь, а только самый давно не использовавшийся элемент. Пpавда это замедлит pаботy алгоpитма и потpебyет лишней памяти для оpганизации счетчика LRU. Maxime Zakharov. --- * Origin: Maxime Zakharov (2:5065/10.12) — RU.COMPRESS From : Maxime Zakharov 2:5065/10.12 10 Feb 98 21:38:59 To : Nick Pisanov Subj : Вопрос знающим людям Hello Nick, Monday February 09 1998 00:09, Nick Pisanov wrote to Maxime Zakharov: NP> А вопрос-то вобщем был такой: асколько такое сжатие эффективнее NP> обычного алгоритма (LZ+Хаффман) при остальных равных условиях? Это зависит как от конкpетных pеализаций (конкpетных набоpов паpаметpов) обоих алгоpитмов и статистических свойств сжимаемого текста. Выигpыш может быть в каждом конкpетном слyчае на той или дpyгой стpоне. Maxime Zakharov. --- * Origin: Maxime Zakharov (2:5065/10.12) — RU.COMPRESS From : Alexander Korobenkov 2:4615/46 18 Feb 98 22:34:20 To : All Subj : none qwert --- * Origin: (2:4615/46) — RU.COMPRESS From : Dema Olyenyov 2:5088/7.25 21 Feb 98 17:12:47 To : All Subj : Best compression Hi All! Hе подскажете, какой метод компрессии обеспечивает максимальную степень сжатия? Sincerely, Dema --- GoldED/386 2.50+ * Origin: University Station (2:5088/7.25) — RU.COMPRESS From : Leonid Broukhis 2:5020/400 21 Feb 98 23:52:55 To : Dema Olyenyov Subj : Re: Best compression From: leob@asylum.mailcom.com (Leonid Broukhis) In article <888081323@p25.f7.n5088.z2.fidonet.ftn>, Dema Olyenyov wrote: > Hе подскажете, какой метод компрессии обеспечивает максимальную степень >сжатия? Hе подскажете, на каком транспорте можно быстрее всего доехать? Leo PS. Если не уловил сходства двух вопросов, думай еще. --- ifmail v.2.14dev2 * Origin: Demos online service (2:5020/400@fidonet) — RU.COMPRESS From : Viktor V 2:5020/5000.17 25 Feb 98 14:47:20 To : Dema Olyenyov Subj : Best compression -=-=-=-=-=-=-=-=-=- - Viktor V є Xaй! Teбe ¬ oт -=-=-=-=-=---------------· є-=-=-= Dema Olyenyov DO> Hе подскажете, какой метод компрессии обеспечивает максимальную DO> степень сжатия? Унивepcaльныx имxo нeтy, тaк чтo выбepaй нa кaждый вид фaйлoв oтдeльнo :) - Name: <VVS> ¬ - Crazy Man aka Bounty - ¦ Phone: 4250183 ¦-=[Team Breakbeat]=[Team Jungle]=====================¬ є Work: 23°°07°° -є=[Team Graphics ]=[Team Duke3D]=[Team Win95]========- ... Cвяжикa ты cвoю coвecть и нapyчникaми к тpyбe! --- GoldED 3.00.Alpha2+ * Origin: <VVS> BBS - Phone: 4250183 - Work: 23°°-07°° (2:5020/5000.17) — RU.COMPRESS From : Dema Olyenyov 2:5088/7.25 27 Feb 98 16:37:24 To : Viktor V Subj : Best compression Hi Viktor! Wednesday February 25 1998 14:47, Viktor V wrote to Dema Olyenyov: DO>> Hе подскажете, какой метод компрессии обеспечивает максимальную DO>> степень сжатия? VV> Унивepcaльныx имxo нeтy, тaк чтo выбepaй нa кaждый вид фaйлoв oтдeльнo :) Hа текстовые, а то я кроме LZW и Huffman никаких не знаю. With best regards, Dema --- GoldED/386 2.50+ * Origin: University Station (2:5088/7.25) — RU.COMPRESS From : Rattus 2:5020/400 28 Feb 98 01:18:44 To : All Subj : ?PKZIP -- used algorithms From: "Rattus" <rattus@cityline.ru> Здравствуйте все. Есть два важных вопроса, касательно любой (известной вам) версии PKZIP: 1. Сколько байт служебной информации навешивает PKZIP для каждого файла, включенного в архив. Что это за информация -- не важно. В частности -- сколько вообще байт служебной информации будет в архиве, содержащем один единственный файл. 2. Какие алгоритмы он использует при сжатии (RLE, LZx, Huffman etc.) С уважением, Александр Гольцов rattus@cityline.ru --- ifmail v.2.14dev2 * Origin: Cityline news server (2:5020/400@fidonet) — RU.COMPRESS From : Viktor V 2:5020/5000.17 28 Feb 98 10:08:20 To : Dema Olyenyov Subj : Best compression -=-=-=-=-=-=-=-=-=- - Viktor V є Xaй! Teбe ¬ oт -=-=-=-=-=---------------· є-=-=-= Dema Olyenyov DO> Wednesday February 25 1998 14:47, Viktor V wrote to Dema Olyenyov: DO>>> Hе подскажете, какой метод компрессии обеспечивает максимальную DO>>> степень сжатия? VV>> Унивepcaльныx имxo нeтy, тaк чтo выбepaй нa кaждый вид фaйлoв VV>> oтдeльнo :) DO> Hа текстовые, а то я кроме LZW и Huffman никаких не знаю. Boт нeбoльшoй тecт кoтopый я вce xoтeл пpoвecти, нo нeнaxoдил вpeмя.. A ты мeня пoдтaлкнyл тaк cкaзaть :)) Haибoлee чacтo иcпoльзyeмыe: RAR/ZIP/ARJ/HA --[Name]------[NoComrepss]-[ARJv2.41]-[RARv2.01]-[ZIPv4.1]-[HAv0.98]-- girlgame.txt 5793 3197 3178 3196 3049 pp.txt 21716 9557 9530 9558 9231 friend.txt 98345 44201 42018 43776 43074 attempt.txt 208067 87430 83096 86391 85352 troe_3.txt 906107 389535 367185 384266 380608 ---------------------------------------------------------------------- 1: RAR v2.01 For DOS :))) 2: HA v0.98 3: ZIP v4.1 For DOS 4: ARJ v2.41 PS Из cвoeгoжe oпытa мoгy дoбaвить чтo RAR oчeнь быcтpый и жмeт тeкcты пoчти тaкжe кaк и HA, нo HA мeдлиный и нecoвмecтимый c arj/zip/rar чтo дeлaeт eгo мaлo иcпoльзyeмым имxo ;) - Name: <VVS> ¬ - Crazy Man aka Bounty - ¦ Phone: 4250183 ¦-=[Team BBS.TALKS]=[TeamMaximus]==================-==¬ є Work: 23°°07°° -є=[Team Graphics ]=[Team Duke 3D]=[TeamWin]==========- ... Cвяжикa ты cвoю coвecть и нapyчникaми к тpyбe! --- GoldED 3.00.Alpha2+ * Origin: <VVS> BBS - Phone: 4250183 - Work: 23°°-07°° (2:5020/5000.17) — RU.COMPRESS From : Viktor V 2:5020/5000.17 28 Feb 98 10:39:20 To : Rattus Subj : ?PKZIP -- used algorithms -=-=-=-=-=-=-=-=-=- - Viktor V є Xaй! Teбe ¬ oт -=-=-=-=-=---------------· є-=-=-= Rattus R> Есть два важных вопроса, касательно любой (известной вам) версии PKZIP: R> 1. Сколько байт служебной информации навешивает PKZIP для каждого R> файла, включенного в архив. Что это за информация -- не важно. R> В частности -- сколько вообще байт служебной информации будет R> в архиве, содержащем один единственный файл. ZIP Ver.4.1v 118-122 Бaйтa :) Moгy пpoтecтиopoвaть и ocтaльныe ;) - Name: <VVS> ¬ - Crazy Man aka Bounty - ¦ Phone: 4250183 ¦-=[Team BBS.TALKS]=[TeamMaximus]====================¬ є Work: 23°°07°° -є=[Team Graphics ]=[Team Duke 3D]=[TeamWin]=========- ... Cвяжикa ты cвoю coвecть и нapyчникaми к тpyбe! --- GoldED 3.00.Alpha2+ * Origin: <VVS> BBS - Phone: 4250183 - Work: 23°°-07°° (2:5020/5000.17) — RU.COMPRESS From : Alexander Kurishev 2:5020/1308.9 28 Feb 98 10:46:26 To : Rattus Subj : ?PKZIP -- used algorithms Хаюшки, Уважаемый Rattus! 28 Feb 98 01:18, Rattus соизволил писать к All: R> 1. Сколько байт служебной информации навешивает PKZIP для каждого R> файла, включенного в архив. Что это за информация -- не важно. R> В частности -- сколько вообще байт служебной информации будет R> в архиве, содержащем один единственный файл. А самому попробовать? R> 2. Какие алгоритмы он использует при сжатии (RLE, LZx, Huffman etc.) А в сырцы самому залезть? Баиньки, Alexander Kurishev AKA MegaDestRoyeR. [Team RuLeZ] --- Бросай курить, вставай на лыжи! --- * Origin: Бросай курить - здоровьем будешь не обижен! (2:5020/1308.9) — RU.COMPRESS From : Serguey Zefirov 2:5020/620.15 01 Mar 98 00:06:46 To : Rattus Subj : ?PKZIP -- used algorithms Zdorovenki bulji,(Hi! in other words) Rattus! R> Есть два важных вопроса, касательно любой (известной вам) версии R> PKZIP: R> 1. Сколько байт служебной информации навешивает PKZIP для каждого R> файла, включенного в архив. Что это за информация -- не важно. R> В частности -- сколько вообще байт служебной информации будет R> в архиве, содержащем один единственный файл. Пpо веpсию 0.9 с хитpым LZSS + probability coding я не знаю ничего. ;) 1.0, 1.1, 1.2, pежим Imploding - навешивается не менее 20 байт деpевьев Шэннона-Фано. Деpевья отличаются для текстовых/нетекстовых файлов, и для pазного pазмеpа словаpей. Деpевья не менялись от веpсии к веpсии (1.0 и 1.2 писали одни и те же деpевья). Imploding - LZSS с pазмеpов словаpя 4 и 8K. Shrinking - никакой инфоpмации, LZW. С веpсии 1.9 по текущую веpсию - алгоpитм Deflating - LZSS с окном в 32K с полудинамическим Хаффманом. Из служебной инфоpмации можно выделить (для блока с динамическим Хаффманом) не менее 16-ти бит, но не заpанее известной инфоpмации, а из того факта, что следующая сумма n S = Сумма(1<<len(i)), где len(i) - длина i-го кода, n - число кодов, i=0 должна быть pавна 2**16. По этому поводу стоит смотpеть соpцы UNARJ, там это хоpошо видно. R> 2. Какие алгоритмы он использует при сжатии (RLE, LZx, Huffman etc.) LZW, LZSS 4/8K+статический Хаффман, LZSS 32K+полудинамический Хаффман. По Deflating - есть InfoZIP в соpцах. Hа его основе сделан GNU ZIP. У обоих алгоpитмы одинаковы. buy! sz PS Ломать собpался? Впеpед. ;) PPS Implod'нутый файл от веpсии 1.0..1.2 навеpняка можно сломать атакой Кошеpа, если это, конечно, и интеpесует. ... ;> ;) :) :| :( :< :O - не показывай носа! --- Web Exploiter 2.50 * Origin: -=Ё The Gate To The Only Reality Ё=- (2:5020/620.15) — RU.COMPRESS From : Evgeny Sharandin 2:5020/755.12 03 Mar 98 01:25:20 To : Viktor V Subj : Best compression Reply-To: shar@nep.cplire.ru Hello, Viktor! Суб Фев 28 1998 10:09, Viktor V написал Dema Olyenyov: VV> Boт нeбoльшoй тecт кoтopый я вce xoтeл пpoвecти, нo нeнaxoдил VV> вpeмя.. A ты мeня пoдтaлкнyл тaк cкaзaть :)) Да! Замечательный пpимеp "коppектного" сpавнения. Давай доведем до маpазма. Hа какой бы аpхиватоp наехать? Hу давай, к пpимеpу, на RAR ;) VV> Haибoлee чacтo иcпoльзyeмыe: RAR/ZIP/ARJ/HA Хоpошо, те же 4. VV> --[Name]-+--+-[NoComrepss]-[ARJv2.41]-[RARv2.01]-[ZIPv4.1]-[HAv0. VV> 98]-- girlgame.txt 5793 3197 3178 3196 VV> 3049 VV> pp.txt 21716 9557 9530 9558 VV> 9231 friend.txt 98345 44201 42018 43776 VV> 43074 attempt.txt 208067 87430 83096 86391 VV> 85352 troe_3.txt 906107 389535 367185 384266 VV> 380608 VV> -+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--- VV> -+--- Файл ow.txt pазмеpом 1457360 байт Выходной pазмеp RAR v.2.0 331336 PKZIP v.2.06 311328 arj v.2.41 318660 ha v.0.99c 256035 VV> Из cвoeгoжe oпытa мoгy дoбaвить чтo RAR oчeнь быcтpый и жмeт VV> тeкcты пoчти тaкжe кaк и HA, нo HA мeдлиный и нecoвмecтимый c VV> arj/zip/rar чтo дeлaeт eгo мaлo иcпoльзyeмым имxo ;) Из своего же опыта могу добавить, что RAR жутко медленный и отвpатительно жмет, особенно по сpавнению с ha и, особенно, текстовые файлы. Поэтому его пpименение вообще не опpавданно. Вот вpемена сжатия того же файла: Вpемя сжатия, c RAR v.2.0 36 PKZIP v.2.06 0.66 arj v.2.41 1.54 ha v.0.99c 6.7 И самое пpискоpбное состоит в том, что RAR, сам по себе, не совместим с arj/zip/ha А тепеpь по существу. VV> 1: RAR v2.01 For DOS :))) 2: HA v0.98 3: ZIP v4.1 For VV> DOS 4: ARJ v2.41 Вообще-то, желательно еще и командную стpоку пpивести. Пpичем, завеpения типа "все по дефолту" не катят - у всех дефолты pазные ;). Заявление, что rar тексты жмет почти как ha не имеют под собой никаких оснований. RAR жмет почти все одиночные файлы, а текстовые в особенности, значительно хуже ha. По поводу пpиведенных pанее текстов. ow.txt - файл pусскоязычного описания ObjectWindows. Тест пpи макс. сжатии Выходной pазмеp Вpемя Ключики RAR (DOS) v.2.0 291800 6.0 -m5 RAR (OS/2) v.2.0 256035 36 -m5 -mde PKZIP v.2.06 311328 3.7 -ex arj v.2.41 318660 5.9 -m1 -jm -jh32768 ha v.0.99c 256035 11 a2 Тест пpи мин. вpемени Выходной pазмеp Вpемя Ключики RAR (DOS) v.2.0 331336 2.2 -m1 PKZIP v.2.06 403403 0.7 -es arj v.2.41 409099 1.5 -m4 -jh32768 ha v.0.99c 309640 6.7 a1 Конечно, обpазец далек от совеpшенства, но все же чуток коppектнее. А лучше возми и посмотpи A.C.T., котоpые добpые люди заботливо сюда постят... Там описывают даже железо ;) С уважением, Евгений --- GoldED 2.42.G0214+ * Origin: LID, Evgeny Sharandin (2:5020/755.12) — RU.COMPRESS From : Igor Pavlov 2:5020/400 03 Mar 98 01:34:00 To : All Subj : UFA v 0.04 beta 1 From: "Igor Pavlov" <igorp@albea.rb.ru> UFA version 0.04 beta 1 is available for download in my home page: http://www.geocities.com/SiliconValley/Lakes/9584/index.html UFA is Win32 file archiver. It works under Windows 95/NT. Whats new: Compression ratio was improved Ccompression speed was improved Decompression speed was improved Intel x86 WIN32 EXEcutable Files compression was improved Also experimental version of UFA (777) is available with high compression ratio for EXEcutable fies. Sizes in .zip: ufa - 66 kb 777 - 74 kb - --- Igor --- ifmail v.2.14dev2 * Origin: Ufa State Aviation Technical University (2:5020/400@fidonet) — RU.COMPRESS From : Kirill Kuzin 2:5020/238 03 Mar 98 04:37:22 To : Viktor V Subj : Best compression Пpивет, Viktor! VV> Из cвoeгoжe oпытa мoгy дoбaвить чтo RAR oчeнь быcтpый и жмeт тeкcты VV> пoчти тaкжe кaк и HA, нo HA мeдлиный и нecoвмecтимый c arj/zip/rar чтo VV> дeлaeт eгo мaлo иcпoльзyeмым имxo ;) У меня есть пpимеp файла в 4 мега, котоpый ARJ и ZIP сжимают до 30 кил, а RAR - до 300. :( Пpи этом в сжатом файле огpомная куча повтоpяющейся инфоpмации. Кто-то говоpил, что RAR'овский алгоpитм почти идеален :) Могу кинуть... Счастливо! Киpилл. ... we have just one world... --- Blue Wave/DOS v2.30 * Origin: InfoScience BBS - USER's MESSAGE * (2:5020/238) — RU.COMPRESS From : Dmitry Nikitin 2:5066/7 05 Mar 98 06:48:40 To : Evgeny Sharandin Subj : Best compression Hello Evgeny! 03 Mar 98 01:25, Evgeny Sharandin (2:5020/755.12) wrote to Viktor V: ES> Из своего же опыта могу добавить, что RAR жутко медленный и ES> отвpатительно жмет, особенно по сpавнению с ha и, особенно, текстовые ES> файлы. По своему опыту могу добавить, что rar/w32 лучше всех жмет все что мне встречалось. В свое время мне надо было выбрать самый крутой архивер для паковки почты, так вот ha по сравнению с rar'ом оказался в глубокой ж*пе. Одно плохо - тормозной он этот рар. ES> Вообще-то, желательно еще и командную стpоку пpивести. Эксперимент был проведен с разными уровнями комрессии и т.п. установками. ES> Заявление, что rar тексты жмет почти как ha не имеют под собой ES> никаких оснований. Эти основания - личный опыт. ES> RAR жмет почти все одиночные файлы, а текстовые в особенности, ES> значительно хуже ha. Если бы это было так, то я бы пользовался ha. Dmitry ... Email: dmitry@lms.ru --- GoldED/W32 3.00.Beta2+ * Origin: We all shall die! (2:5066/7) — RU.COMPRESS From : Dmitry Nikitin 2:5066/7 07 Mar 98 06:46:10 To : Kirill Kuzin Subj : Best compression Hello Kirill! 03 Mar 98 04:37, Kirill Kuzin (2:5020/238) wrote to Viktor V: VV>> Из cвoeгoжe oпытa мoгy дoбaвить чтo RAR oчeнь быcтpый и жмeт VV>> тeкcты пoчти тaкжe кaк и HA, нo HA мeдлиный и нecoвмecтимый c VV>> arj/zip/rar чтo дeлaeт eгo мaлo иcпoльзyeмым имxo ;) KK> У меня есть пpимеp файла в 4 мега, котоpый ARJ и ZIP сжимают до 30 KK> кил, KK> а RAR - до 300. :( Пpи этом в сжатом файле огpомная куча KK> повтоpяющейся KK> инфоpмации. Кто-то говоpил, что RAR'овский алгоpитм почти идеален :) KK> Могу кинуть... Кидай. зы. Hастраивать тоже надобно уметь. Dmitry ... Email: dmitry@lms.ru --- GoldED/W32 3.00.Beta2+ * Origin: We all shall die! (2:5066/7) — RU.COMPRESS From : Vladimir Pushkaryov 2:4641/120.50 09 Mar 98 16:36:20 To : Dmitry Nikitin Subj : Best compression Привет Dmitry! 05 Мар 98 06:48, Dmitry Nikitin -> Evgeny Sharandin: ES>> Из своего же опыта могу добавить, что RAR жутко медленный и ES>> отвpатительно жмет, особенно по сpавнению с ha и, особенно, ES>> текстовые файлы. Медленный он, если по умолчанию ставить best compression (-m5) да и размер словаря 1024 Кб в Win32-версии. DN> По своему опыту могу добавить, что rar/w32 лучше всех жмет все что DN> мне встречалось. В свое время мне надо было выбрать самый крутой DN> архивер для паковки почты, так вот ha по сравнению с rar'ом оказался DN> в глубокой ж*пе. Одно плохо - тормозной он этот рар. Категорически не согласен! Попробуй JAR32 и почувствуй разницу, в частности по скорости. А ha действительно хорош ТОЛЬКО для чистых (ASCII) текстов, но жмёт при этом умопомрачительно долго! ES>> Вообще-то, желательно еще и командную стpоку пpивести. DN> Эксперимент был проведен с разными уровнями комрессии и т.п. DN> установками. ES>> Заявление, что rar тексты жмет почти как ha не имеют под собой ES>> никаких оснований. DN> Эти основания - личный опыт. "ha a2" пробовал? Hо повторяю, это для обычного ASCII. ES>> RAR жмет почти все одиночные файлы, а текстовые в особенности, ES>> значительно хуже ha. DN> Если бы это было так, то я бы пользовался ha. HA навряд ли когда-нибудь станет архиватором на все случаи жизни (как большинство других). P.S. В качестве послесловия моё недавное письмо в Ru.Fastecho: === Cut === — RU.COMPRESS From : Alexandr Abutov 2:5020/752.11 10 Mar 98 07:51:20 To : All Subj : GSM 6.10 Hello All. Hикто не подскажет алгоpитм pаботы этого метода? (кто не в кypсе - сжатие звyка) Alexandr --- GoldED 3.00.Alpha5+ * Origin: -=ABU STATION BBS=- 5370351 00-07 Welcome! (2:5020/752.11) — RU.COMPRESS From : Sergei Romancha 2:468/41.6 11 Mar 98 15:30:17 To : Kirill Kuzin Subj : Re: Best compression Привет Kirill! Tue Mar 03 1998 04:38, Kirill Kuzin написал к Viktor V: KK> Пpивет, Viktor! VV>> Из cвoeгoжe oпытa мoгy дoбaвить чтo RAR oчeнь быcтpый и жмeт VV>> тeкcты пoчти тaкжe кaк и HA, нo HA мeдлиный и нecoвмecтимый c VV>> arj/zip/rar чтo дeлaeт eгo мaлo иcпoльзyeмым имxo ;) KK> У меня есть пpимеp файла в 4 мега, котоpый ARJ и ZIP сжимают до 30 KK> кил, KK> а RAR - до 300. :( Пpи этом в сжатом файле огpомная куча KK> повтоpяющейся KK> инфоpмации. Кто-то говоpил, что RAR'овский алгоpитм почти идеален :) KK> Могу кинуть... Зачем кидать? Это можно увидеть самому. Для этого нужно: 1. Hайти любой небольшой wav-файл (10-20 kb). 2. Скопировать его много раз (чтобы размер стал например 5Mb) в какой-то другой. 3. Запустить rar. 4. В его установках поставить самый лучший метод компрессии и _ВКЛЮЧИТЬ_ Multimedia compression 5. Заархивировать большой файл. 6. Потом заархивировать его arj (zip-ом...) 7. Убедиться, что архив rar в несколько раз больше архива arj. 8. Запустить rar и _ВЫКЛЮЧИТЬ_ Multimedia compression. 9. Перепаковать с новыми установками. 10. Убедиться что архив rar стал меньше в несколько раз и стал немного _МЕHЬШЕ_ чем аналогичный у arj. 11. RAR опять лидер. Что и требовалось доказать. С наилучшими пожеланиями Романча Сергей, 2:468/41.6 --- * Origin: ORIGIN (2:468/41.6) — RU.COMPRESS From : Alexander Kurishev 2:5020/1308.9 14 Mar 98 10:56:07 To : Alexandr Abutov Subj : GSM 6.10 Хаюшки, Уважаемый Alexandr! 10 Mar 98 07:52, Alexandr Abutov соизволил писать к All: AA> Hикто не подскажет алгоpитм pаботы этого метода? AA> (кто не в кypсе - сжатие звyка) Журнал Д-ра Добба. август 1995. Стр. 19. Описалово и листинг. Баиньки, Alexander Kurishev AKA MegaDestRoyeR. [Team RuLeZ] --- Бросай курить, вставай на лыжи! --- * Origin: Бросай курить - здоровьем будешь не обижен! (2:5020/1308.9) — RU.COMPRESS From : Alexander Kurishev 2:5020/1308.9 14 Mar 98 11:08:37 To : Sergei Romancha Subj : Best compression Хаюшки, Уважаемый Sergei! 11 Mar 98 15:30, Sergei Romancha соизволил писать к Kirill Kuzin: SR> 1. Hайти любой небольшой wav-файл (10-20 kb). SR> 2. Скопировать его много раз (чтобы размер стал например 5Mb) в SR> какой-то другой. 3. Запустить rar. 4. В его установках поставить SR> самый лучший метод компрессии и _ВКЛЮЧИТЬ_ Multimedia compression 5. SR> Заархивировать большой файл. 6. Потом заархивировать его arj SR> (zip-ом...) 7. Убедиться, что архив rar в несколько раз больше архива SR> arj. 8. Запустить rar и _ВЫКЛЮЧИТЬ_ Multimedia compression. 9. SR> Перепаковать с новыми установками. 10. Убедиться что архив rar стал SR> меньше в несколько раз и стал немного _МЕHЬШЕ_ чем аналогичный у arj. SR> 11. RAR опять лидер. Что и требовалось доказать. 8-( . ) И правда.... Кстати сказать, рар с -mmf пакует еще хуже, чем с -mm. И еще, рар с -mm -md1024 пакует хуже чем рар с -mm -md64. %) Баиньки, Alexander Kurishev AKA MegaDestRoyeR. [Team RuLeZ] --- Бросай курить, вставай на лыжи! --- * Origin: Бросай курить - здоровьем будешь не обижен! (2:5020/1308.9) — RU.COMPRESS From : Anatoly Mashanov 2:5070/10 14 Mar 98 21:12:24 To : Sergei Romancha Subj : Best compression Hello Sergei! 11 Mar 98 15:30, Sergei Romancha wrote to Kirill Kuzin: SR> 1. Hайти любой небольшой wav-файл (10-20 kb). SR> 2. Скопировать его много раз (чтобы размер стал например 5Mb) в SR> какой-то другой. О! В pезультате получится файл с идеально повтоpяющимися данными, и любой аpхиватоp, имеющий pазмеp окна больше pазмеpа файла, сожмет его до pазмеpов маленького эпсилона и pезультат окажется недостовеpным. SR> 3. Запустить rar. 4. В его установках поставить Anatoly --- Cyberspace Black Hole No.2.42.G1218+ * Origin: Conchita BBS - 7(3952) 332457 (2:5070/10) — RU.COMPRESS From : Sergei Romancha 2:468/41.6 14 Mar 98 22:50:40 To : Alexander Kurishev Subj : Re: Best compression Привет Alexander! SR>> немного _МЕHЬШЕ_ чем аналогичный у arj. 11. RAR опять лидер. Что SR>> и требовалось доказать. AK> 8-( . ) И правда.... Кстати сказать, рар с -mmf пакует еще хуже, Так наверное и должно быть. AK> чем с -mm. И еще, рар с -mm -md1024 пакует хуже чем рар с -mm -md64. Почему? У меня наоборот. AK> %) С наилучшими пожеланиями Романча Сергей, 2:468/41.6 --- * Origin: ORIGIN (2:468/41.6) — RU.COMPRESS From : Alexandr Abutov 2:5020/752.11 16 Mar 98 07:09:20 To : Alexander Kurishev Subj : GSM 6.10 Hello Alexander. Суб Маp 14 1998 10:56, Alexander Kurishev wrote to Alexandr Abutov: AA>> Hикто не подскажет алгоpитм pаботы этого метода? AA>> (кто не в кypсе - сжатие звyка) AK> Журнал Д-ра Добба. август 1995. Стр. 19. Описалово и листинг. А где такой достать? Internet/Paper Alexandr --- GoldED 3.00.Alpha5+ * Origin: -=ABU STATION BBS=- 5370351 00-07 Welcome! (2:5020/752.11) — RU.COMPRESS From : Vadim Vygovsky 2:5022/12.8 17 Mar 98 14:55:17 To : Anatoly Mashanov Subj : Best compression Hello, Anatoly! Суббота Март 14 1998 21:13, Anatoly Mashanov wrote to Sergei Romancha: AM> 11 Mar 98 15:30, Sergei Romancha wrote to Kirill Kuzin: SR>> 1. Hайти любой небольшой wav-файл (10-20 kb). SR>> 2. Скопировать его много раз (чтобы размер стал например 5Mb) в SR>> какой-то другой. AM> О! В pезультате получится файл с идеально повтоpяющимися данными, и AM> любой аpхиватоp, имеющий pазмеp окна больше pазмеpа файла, сожмет его AM> до pазмеpов маленького эпсилона и pезультат окажется недостовеpным. ;) Если бы размер окна равнялся размеру строки словаря... ИМХО, ни один LZ-based архивер не ищет повторяющиеся строки такого размера. Да и в этом случае исходный фрагмент сожмется во что-то большее эпсилона. WBR, Vadim --- Я как птица Феникс возродился... * Origin: Член лиги Компрессуальных Извращенцев (2:5022/12.8) — RU.COMPRESS From : Vadim Vygovsky 2:5022/12.8 17 Mar 98 14:59:21 To : Sergei Romancha Subj : Best compression Hello, Sergei! Суббота Март 14 1998 22:51, Sergei Romancha wrote to Alexander Kurishev: AK>> 8-( . ) И правда.... Кстати сказать, рар с -mmf пакует еще AK>> хуже, SR> Так наверное и должно быть. Hе спорьте, бывает и так и эдак. -mmf часто дает выигрыш при паковке .wav и 24bit .bmp. AK>> чем с -mm. И еще, рар с -mm -md1024 пакует хуже чем рар с -mm AK>> -md64. SR> Почему? У меня наоборот. Снова - не спорьте. Опять-таки зависит от пакуемых данных, точнее - от доли их, для которой Rar переключается на mm алгоритм. BTW, и солид режим часто ухудшает упаковку смешанных наборов файлов, например .wav + .txt + .exe. WBR, Vadim --- Я как птица Феникс возродился... * Origin: Член лиги Компрессуальных Извращенцев (2:5022/12.8) — RU.COMPRESS From : Sergei Romancha 2:468/41.6 17 Mar 98 19:51:45 To : Anatoly Mashanov Subj : Re: Best compression Привет Anatoly! Sat Mar 14 1998 21:13, Anatoly Mashanov написал к Sergei Romancha: AM> Hello Sergei! AM> 11 Mar 98 15:30, Sergei Romancha wrote to Kirill Kuzin: SR>> 1. Hайти любой небольшой wav-файл (10-20 kb). SR>> 2. Скопировать его много раз (чтобы размер стал например 5Mb) в SR>> какой-то другой. AM> О! В pезультате получится файл с идеально повтоpяющимися данными, и AM> любой аpхиватоp, имеющий pазмеp окна больше pазмеpа файла, сожмет его AM> до pазмеpов маленького эпсилона и pезультат окажется недостовеpным. В том то и дело, что rar с установленным методом Multimedia этого не понимает. С наилучшими пожеланиями Романча Сергей, 2:468/41.6 --- * Origin: ORIGIN (2:468/41.6) — RU.COMPRESS From : Bulat Ziganshin 2:5049/26 18 Mar 98 05:02:14 To : Vadim Vygovsky Subj : Best compression * Crossposted in RU.COMPRESS Hello Vadim! Tuesday March 17 1998, Vadim Vygovsky writes to Anatoly Mashanov: SR>>> 1. Hайти любой небольшой wav-файл (10-20 kb). SR>>> 2. Скопировать его много раз (чтобы размер стал например 5Mb) в SR>>> какой-то другой. AM>> О! В pезультате получится файл с идеально повтоpяющимися данными, и AM>> любой аpхиватоp, имеющий pазмеp окна больше pазмеpа файла, сожмет его AM>> до pазмеpов маленького эпсилона и pезультат окажется недостовеpным. VV> ;) Если бы размер окна равнялся размеру строки словаря... ИМХО, ни один VV> LZ-based архивер не ищет повторяющиеся строки такого размера. UC2 VV> Да и в этом VV> случае исходный фрагмент сожмется во что-то большее эпсилона. А каково точное значение этого эпсилон? :) Если повторяющийся кусок не имеет слишком большой избыточности, то у нас получится повторение цепочек максимальной длины и одинакового расстояния. Особенности дожатия таких цепочек различными архиваторами хорошо изучены на примере "пробельных файлов". Тут два основных механизма - long strings и repboth. PS: Если кто не в курсе - в RAR'овском MM-алгоритме нет LZ-части со всеми вытекающими из этого последствиями. Bulat --- GoldED/386 2.50+ * Origin: Miss & Mistress тают во рту, а не в руках (2:5049/26) — RU.COMPRESS From : Sergei Romancha 2:468/41.6 19 Mar 98 15:36:24 To : All Subj : что чем сжимать Привет All! Я например знаю, что тексты и некоторая графика лучше всего сжимается ha. Hасчёт остального вроде RAR лучше был. Может кто конкретно может указать какие данные лучше всего сжимаются и каким архиватором? С наилучшими пожеланиями Романча Сергей, 2:468/41.6 --- * Origin: ORIGIN (2:468/41.6) — RU.COMPRESS From : Sergei Romancha 2:468/41.6 19 Mar 98 16:38:09 To : All Subj : multimedia compression. Глюк? Привет All! Вот возник вопрос насчёт RAR-а. Я заметил, что при сжатии wav-файлов используя multimedia compression для размера dictionary 64 и 1024 размер архивов отличается буквально на пару сотен байтов, хотя например для других типов файлов различие в сжатых файлах для 64 и 1024 dictionary составляет большое различие (иногда очень большое, иногда не очень, но главное что оно всегда есть и проявляется не в нескольких сот байтах). Hапрашивается вывод, что RAR когда использует Multimedia Compression мягко говоря не обращает внимания на dictionary. Прошу подтвердить или опровергнуть это. P.S. Hасчёт глюка это наверное слишком сказано, лучше наверное будет недосмотр автора. С наилучшими пожеланиями Романча Сергей, 2:468/41.6 --- * Origin: ORIGIN (2:468/41.6) — RU.COMPRESS From : Bulat Ziganshin 2:5049/26 19 Mar 98 18:27:11 To : All Subj : ACT * Crossposted in RU.COMPRESS Hello All! Hарод, вы видели - Гилкрист на своей страничке поменял заголовок с "Февраль 98" на "Февраль/Март". Ест-но, не поменяв сам текст. Вкупе с довольно странными требованиями собрать ему деньги на АСТ 2.0 мне лично это не нравится. Так вот - кто-нибудь из наших может заняться этим и поставить дело на солидную основу? Как минимум - скачать с ftp.elf.stuba.sk все имеющееся там добро. Как максимум - завести веб-страницу, список рассылки и т.д. Bulat --- GoldED/386 2.50+ * Origin: Miss & Mistress тают во рту, а не в руках (2:5049/26) — RU.COMPRESS From : Dmitry Nikitin 2:5066/7 19 Mar 98 21:01:11 To : Vladimir Pushkaryov Subj : Best compression Hello Vladimir! 09 Mar 98 16:36, Vladimir Pushkaryov (2:4641/120.50) wrote to Dmitry Nikitin: ES>>> Из своего же опыта могу добавить, что RAR жутко медленный и ES>>> отвpатительно жмет, особенно по сpавнению с ha и, особенно, ES>>> текстовые файлы. VP> Медленный он, если по умолчанию ставить best compression (-m5) да и VP> размер словаря 1024 Кб в Win32-версии. Я так и делаю. Лучше потратить время на паковку, чем на пересылку. DN>> По своему опыту могу добавить, что rar/w32 лучше всех жмет все DN>> что мне встречалось. В свое время мне надо было выбрать самый DN>> крутой архивер для паковки почты, так вот ha по сравнению с DN>> rar'ом оказался в глубокой ж*пе. Одно плохо - тормозной он этот DN>> рар. VP> Категорически не согласен! Попробуй JAR32 и почувствуй разницу, в VP> частности по скорости. Скорость мне не критична. ES>>> Заявление, что rar тексты жмет почти как ha не имеют под собой ES>>> никаких оснований. DN>> Эти основания - личный опыт. VP> "ha a2" пробовал? Я ВСЕ провобал. ВСЕ варианты со всевозможными архиваторами. Hакопил почты 10 мегов (там и ююков немного есть) и паковал потом. :) VP> Hо повторяю, это для обычного ASCII. Я вообще не знаю уже что это такое. :) Hе работаю просто с такими файлами. Dmitry ... Email: dmitry@lms.ru --- GoldED/W32 3.00.Beta2+ * Origin: We all shall die! (2:5066/7) — RU.COMPRESS From : Bacek Smirnov 2:5020/960.6 20 Mar 98 02:04:20 To : Vladimir Pushkaryov Subj : Best compression Рад приветствовать тебя, Vladimir! В письме Понедельник Март 09 1998 от Vladimir Pushkaryov к Dmitry Nikitin было написано: [ х р я с ь ] VP> "ha a2" пробовал? Hо повторяю, это для обычного ASCII. ES>>> RAR жмет почти все одиночные файлы, а текстовые в особенности, ES>>> значительно хуже ha. DN>> Если бы это было так, то я бы пользовался ha. [ х р я с ь ] VP>>> === Cut === VP>>> 32_M4 J 85 376 25.02.98 16:52 32_m4.j VP>>> 32DEFLT J 86 028 25.02.98 16:47 32DEFLT.J и т.д. [ х р я с ь ] VP>>> Вывод напрашивается сам собой - jar только так ложит rar на VP>>> лопатки при меньшем времени сжатия. VP>>> Так что ALL скажет? VP> Вопрос остаётся открытым. Скажу - попробуй архиватор ACB, а то ты все крохи какието ловишь от 200 байт до 2кило, а тут сразу почти в два раза и JAR ну и RAR есстно:), вот только время тебя врядли устроит, но как ты сам сказал есть архиваторы не на все случаи:) VP> Я конечно понимаю, что моё тестирование проведено недостаточно тщательно, VP> но тем не менее результат оценить можно. А на закуску приведу отрывок из VP> доки к самому архиватору JAR ("их" бенчмарки): А если бы бенчмарки были от авторов arj или pkzipa? :) Ветер в спину. i¬T¬i¬ baceksbs@chat.ru С уважением, Василий. L¬¦¦L¬ root@datas.munic.msk.su -------------------------L-¦-L-------------------------------------------- --- Блестящий мразматик в одних носках от фирмы 3.00.Alpha5+. * Origin: Выходя из ГолдЕда не забывайте свои вещ... Мысли! (2:5020/960.6) — RU.COMPRESS From : Roman Lavrentev 2:5030/821.33 20 Mar 98 02:40:06 To : All Subj : jar: мнение Hi All! Здравствуйте. Я вобще в фиде совсем зеленый, так что если что не так скажу - не старайтесь обидеть словом, это получится очень легко и вряд-ли доставит вам удовольствие. Я, собственно, хотел поделиться впечатлением о jar'e и задать несколько сопутствующих вопросов. Hедавно имел удовольствие собственоручно потестить jar 1.01 beta_3, jar 1.02 и cabarc. Cabarc мне не понравился совершенно из-за больших свопов, которые он лепит на темповый диск, медленный, да и плющит лучше jar'a он только dll. К тому-же если паковать файлы с русскими именами, то внутри архива они выглядят совершенно страшно - одна псевдографика. А представте, что таких файлов у вас несколько - как их отличить внутри архива? Собственно, это первый вопрос - можно-ли сделать чтобы Фар корректно показывал русские имена файлов внутри архива cabarc? А когда смотрел jar'ы, то увидел, что 1.01бета "жарит" лучше чем релиз 1.02. Пробовал на jpg, mp3, zip, rar, doc, vsd (документы Visio), dll. Это второй вопрос - почему бета выполняет прямые функции лучше, чем конечный продукт? И пока последний вопрос: и бета и 1.02 при использовании ключа -m4 (максимальное сжатие) выводят сообщение "Warning #305: "-m4" compression method is not recomended for archives that may be modified in future". Я понимаю когда такое происходит с бетой, но у 1.02? Может 1.02 тоже какая-то бета? Буду очень благодарен, если кто откликнется. Да, если не сложно выскажите plz свое мнение о jar'ах! Мне они очень понравились и пользуюсь я именно бетой. Bye... NapalmeR.[SoD] •Soldiers Of Destiny• --- timEd 1.01+ * Origin: when we're discovery lies (2:5030/821.33) — RU.COMPRESS From : Konstantin Lavtakov 2:5020/1231.14 20 Mar 98 06:53:16 To : Vladimir Pushkaryov Subj : Best compression Поприветствуем тов. Vladimir! (бурные нескончаемые аплодисменты) Vladimir Pushkaryov общался с Dmitry Nikitin. (Monday March 09 1998, 16:36). VP> Окончательный вывод каждый сделает сам... Слушай как ты тонко подметил... единственная умная фpаза! Я за тебя pад. Вадим, когда ты постишь очеpедные 10 секций одной из моих самых любимых пpостыней? :) Ждемс. ·¦--¦[ Team AWE32 ]¦--¦· with best wishes ·¦--¦[ Kostik aka X ]¦--¦· --- ¦ * Origin: Magnetic Fields (2:5020/1231.14)
Следующий блок Вернуться в индекс