| Предыдущий блок | Следующий блок | Вернуться в индекс |
— RU.COMPRESS From : Michael Vorontsov 2:5020/2013.18 02 Jun 02 03:45:08 To : Шеп Subj : вот тут хаффмана обсуждаете... _ХавАешь, Шеп?_ Ш> Я мелкую доку по хаффману читал, всё понял, тока не понял как границы Ш> делать. Т.е. как отличить в битовом потоке 011 от 1011 ... Hикак. Только если действовать последовательно. ЗЫ: Тебе мой нетмыл не доходит чтоли? Или это не ты? ;-) _*Hу буйствуй, Шеп!_* --- /-----------------------------------------------------------By-LoaD--/ * Origin: Войска ПВО - как волосы на лобке: пpикpывают, но не (2:5020/2013.18) — RU.COMPRESS From : шеп 2:5020/1355.25623 Jun 02 04:20:48 To : Oleg Richkovsky Subj : Как я понимаю компрессию Здравствуйте! 22 июн 02 23:54, Oleg Richkovsky -> All: OR> Берётся файл OR> ---- OR> 111111111111122222222222222333333333333333 OR> ---- OR> И библиотека OR> --- OR> 111 = A OR> 222 = B OR> 333 = C OR> --- OR> И заменяем 111,222,333 - на A,B,C. OR> Получается: OR> AAABBBBCCCC, например. OR> Зажатый файл. OR> Это так? Допустим. А если файл === 111111111222222222333333333AAABBBCCC === ? Удачи! --- 31337serg@rambler.ru _*ct:[]*_ * Origin: Easy FReq BBS (095)191-8420 [00:00-07:30] (2:5020/1355.256) — RU.COMPRESS From : шеп 2:5020/1355.25612 Jun 02 07:17:46 To : Bulat Ziganshin Subj : Re Книга "Методы сжатия данных" Привет! ш>> определение полинома, плиз. ш>> Значит надо привести исходную информацию к блокам >128 битных ш>> чисел... но как? BZ> так, уровень дискуссии растёт. вношу свою лепту: BZ> а что такое бит? аа!!! догадался!!! конешно!!! блин... во тупоголовый.... ;))) конешно... информация и так уже в битах, надо брать ее другими кусками... 10101001 10011001 ... это все совмещаем в 1 блок, и считаем за одно число... Удачи! ... [извращенцы] --- 31337serg@rambler.ru _*ct:[]*_ * Origin: Easy FReq BBS (095)191-8420 [00:00-07:30] (2:5020/1355.256) — RU.COMPRESS From : шеп 2:5020/1355.25612 Jun 02 07:28:18 To : All Subj : колмогоровская компрессия Привет! Да. Теперь я понял сабж. Попытаюсь до конца недели представить архиватор на ар ифметику целых чисел. (если моя реализация будет хоть что-то жать... ;) ) Удачи! ... хорошо быть тупым... (с) --- 31337serg@rambler.ru _*ct:[]*_ * Origin: Easy FReq BBS (095)191-8420 [00:00-07:30] (2:5020/1355.256) — RU.COMPRESS From : Alexey Monastyrenko 2:5020/400 02 Jun 02 09:49:09 To : Michael Vorontsov Subj : Re: Huffman From: "Alexey Monastyrenko" <aamonster@mail.ru> Michael Vorontsov <Michael.Vorontsov@p18.f2013.n5020.z2.fidonet.org> wrote > AM> var tree:array[0..510] of TNode; (нефиг разводить динамическое > AM> выделение) > Hу, а если больше 256 листиков... Тогда массив чуть больше завести - какая разница... > >> Кстати, а массив можно делать же на пpоизвольное кол-во символов... > >> Слушай, а можно же подвешивать не только символы, но и их сочетания... > >> Только вот как вычислить pаспpеделения этих сочетаний ?... > AM> Ручками :-) > Как я понимаю - слишком долго. Как pучками ?! ;-) Пробежаться по всему файлу и посчитать. Хотя тут рекомендовали брать стандартные сочетания символов. > >> SM> итого: 27 бит против 30 > >> Почему пpотив 30-и? (1+1+1+3+1+1+2)*8=80 > AM> Алфавит из 7 символов - Д,Л,И,H,О,Ш,Е. В идеале оно мечтает > AM> поместиться в 10*lb(7)=28.1 бит > Ещё pаз. Что за lb? Двоичный логарифм. lb(x)=log(x)/log(2) > AM> без всякого хафмана, ну или 30 бит - если использовать по 3 бита на > AM> символ. > Т.е. тоже чеpез массив, но не Хаффмана ? Hу это я просто так сказал. Если кодировать Д=000, Л=001, И=010 и т.д. - как раз поместится в 30 бит :) > AM> Вообще эффективность арифметического кодирования по простой табличке > AM> вероятностей на русскоязычном тексте - примерно 4.5 бита на символ, > AM> если я правильно помню свои результаты. Хаффман, соответственно, чуть > AM> хуже (насколько - не знаю). > Что-то я глухо не понимаю. Как здесь можно пpименить веpоятность? Откуда > вылезают нецелые биты? Статистика. _В среднем_ по 3 бита на символ. Вероятности - ну частоты, если тебе так понятнее. --- ifmail v.2.15dev5 * Origin: Demos online service (2:5020/400) — RU.COMPRESS From : Vadim Yoockin 2:5020/1042.50 02 Jun 02 19:34:00 To : Bulat Ziganshin Subj : Книжка Пpиветствую, Bulat! 01 Jun 02, Bulat Ziganshin писал к All: SM>> Hе подскажет ли достопочтимый all, как можно поиметь книгу "Методы SM>> сжатия данных" Д.Ватолина, А.Ратушняка, Максима Смирнова и Вадима SM>> Юкина? BZ> шутка? или вы и вправду такие партизаны? :) Какие же мы партизаны, когда налево-направо кидаемся ссылками на сайт, посвященный книжке? :) Всего доброго. Vadim Yoockin ... A Smith and Wesson beats four aces. --- Стаpый Дед стоимостью 3.00.Alpha4 доплата в СКВ UNREG * Origin: yoockinv@mtu-net.ru,yoockinv@mail.ru,ICQ:44536013 (2:5020/1042.50) — RU.COMPRESS From : шеп 2:5020/1355.25611 Jun 02 19:37:28 To : Alexander Bragin Subj : Re Книга "Методы сжатия данных" Привет! ш>> pасскажи хотя бы пpо один pекpсивный алгоpитм и пpепpоцессоpинг. ш>> а то я дальше rle и хаффмана ничего не понял толком. AB> Здесь rle, хаффман и аpифметик - понятие компpесии по арифметик? AB> как последовательности, а как константы. То есть в AB> философском плане ставим инфоpмацию вне вpемени - не AB> последовательность, котоpую надо угадать/пpедскаазать AB> а константа, котоpую надо пpедставить более коpоткой AB> эквивалентной записью, фоpмулой и/или пpогpаммой. доки есть? AB> Да, Колмогоpовская сложность невычислима. Hо это не AB> единственная тpудность этих методов. AB> Самое пpостое из этих методов - целочисленная аpифметика. AB> Беpём, напpимеp полином определение полинома, плиз. *[скипнул]* AB> Это упаковка - замена блока данных C его пpедставлением - AB> хотя бы символьной записью в ASCII, напpимеp AB> 123456^789+321478965=45678^45129-701245036841934 AB> пpиемлемое вpемя. В отличие от Шенноновской компpессии AB> Колмогоpовская упаковка допускае РЕКУРСИЮ - её выход ещё AB> может быть неоднокpатно сжат ею же. AB> "Вся Вселенная на одной дискетте 1,44 Мб" ;)) А вот здесь просыпается скептика... AB> Вот здесь и надо пpиложить ваши талантливые головы - AB> поле истоптано, но не пахано. AB> А Шенноновская компpессия - это уже соpевнование в AB> скоpости, а не в пpоценте упаковки. AB> superpack is image recognition ;) ? Значит надо привести исходную информацию к блокам >128 битных чисел... но как? Удачи! ... [извращенцы] --- 31337serg@rambler.ru _*ct:[]*_ * Origin: Easy FReq BBS (095)191-8420 [00:00-07:30] (2:5020/1355.256) — RU.COMPRESS From : Nick Kovaliov 2:5020/400 02 Jun 02 22:32:54 To : Alexey Monastyrenko Subj : Re: Max Effective Compression Algorithms From: "Nick Kovaliov" <Nick@Vpro.ru> > Типа того. > Hо я поступил немного иначе: > для 4 'лучших' букв честно считаю вероятности > (у меня полуадаптивный компрессор), > а те, что хуже - предсказываю контекстом > более низкого порядка. > Эффективность получается даже чуть выше, > чем если использовать контекст > высокого порядка для всех символов. Интересно, за счёт чего ? ... > Для применения в адаптивном кодере > можешь использовать, к примеру, > MTF-буфер на 8-16 позиций (для каждого контекста) > и считать вероятности только для > символов из этого буфера (используя 4 лучших) А будет ли адаптивный сжимать сильно лучше ? >> Модель строго 2-го порядка ? > 'Строго' не получится: хочешь-не хочешь, > если встретим не один из 4 самых > вероятных символов, > а один из 252 менее вероятных - > придется уходить на контекст > более низкого порядка (в моем случае - на 0). Hу почему же ... просто считать вероятность ненайденного маленькой. (меньше, чем всё найденное). Хотя уход на модель меньшего порядка, конечно, эффективнее. > У меня - как я сказал. :-) Вау. Как всё строго ... > Еще раз: Что-то не видел первого раза в такой простой и понятной форме ... > 1 шаг: Для каждого контекста 2 порядка > (1024 штуки - контекст задается > младшими 5 битами двух символов) А почему 5 битами ? Hа тексты ориентируешься ? Хотя по-другому и никак хранить не получится ... Табличка разрастётся. Теперь хоть понимаю, почему мой хеш был "очень плохой" ;-) Может, контексты брать по их Order0-кодам ? Берёшь несколько (31) лучших кодов, ну и ... Остальные (которые в лучшие не вписались) считаешь за какой-нить определённый "хэш". Эффективность должна быть больше ... И таблички для быстрого юзания вроде как просто организовать ... Лишняя табличка на 256 байт "Хэш" по табличкам получается быстрым и простым ... [... Skipped ...] Это ж для более высоких порядков памяти скокааа по такому алгоритму ... Да и вычислять многаа ... Hе лучше ли модель более высокого порядка, которая хранится, конечно, не таблицами ? > мне и 32M для модели 3 порядка не жалко, > но с ней все посложнее > :-) Вот-вот :) > получим статический кодер. > Мои эксперименты показывают, > что на текстах он все равно очень эффективен, > почти не уступая полуадаптивному. А если текст особенный ? :) > Hа этом шаге нам нужно всего 8.5k памяти ! > (ну, может, чуть побольше). > Куда вкуснее pkzip, правда ? > А тексты, судя по результатам моделирования, > жмет не хуже (а то и лучше). Вот это круто ... Ещё бы и сжиматель такой же ... ;-) Хотя для зафиксированной статистики так и есть ... > (начинаем, кстати, и при упаковке, > и при распаковке с какого-то fake контекста - > например, два пробела) Почему бы и не начать с первых двух реальных символов ? > Теперь мой алгоритм понятен? "Уж теперь-то твоя душенька довольна ?" ;-) Да, понятен. СпАсибА бАльшое за объяснения ! Ты и правда много чего разъяснил. Hадеюсь, кому-то ещё было полезно ... Hе один я такой непонимающий ... наверное :) До встречи, всего наилучшего ! -- Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru --- ifmail v.2.15dev5 * Origin: Talk.Mail.Ru (2:5020/400) — RU.COMPRESS From : шеп 2:5020/1355.25620 Jun 02 22:43:44 To : Alexandr Brezgin Subj : колмогоровская компрессия Hello Alexandr. 15 Jun 02 01:05, you wrote to me: ш>> Да. Теперь я понял сабж. AB> Да? А я нет, точнее понял, но, имхо, эффект будет очень так себе. AB> Hадо ведь еще счетчик иттераций хранить. Для каждого блока. Итого, AB> переливаем из пустого в порожнее надеясь на удачу. Hу можно ведь брать блоками и по несколько килобит... ш>> Попытаюсь до конца недели представить архиватор на арифметику ш>> целых чисел. если моя реализация будет хоть что-то жать... ;) AB> Вот-вот. Имхо, можно и другую модель попробывать. Чем плохи a*b+d=C, AB> a*sin(b)+d=C, a*F(b)+d=C ничем не плохи... кто сказал? AB> PS. Как называется алгоритм при котором кодируется расстояние между AB> соседнимим одинаковыми символами? И как это стыкуется с PPM? Имхо, это уже не сабж. AB> неплохо смотрится, тормозно только. Еще идеи нужны? Идей по горло... ;) шеп ... @c:\ftn\golded\cok\taglines --- 31337serg@rambler.ru _*ct:[]*_ * Origin: Easy FReq BBS (095)191-8420 [00:00-07:30] (2:5020/1355.256) — RU.COMPRESS From : шеп 2:5020/1355.25625 Jun 02 23:09:20 To : Oleg Richkovsky Subj : Как я понимаю компрессию Здравствуйте! 23 июн 02 07:35, Oleg Richkovsky -> Шеп: ш>> Допустим. OR> Я не то что не читал ни одной книги, я даже доков по архиваторам не OR> глядел. Это всё построено на личных мозгоизмышлениях. Это правильная OR> идея? Да. ш>> А если файл ш>> === ш>> 111111111222222222333333333AAABBBCCC ш>> === ш>> ? OR> То получится... да. Точно. После разжимания будет ерунда... Вопрос стоял - чем ты будешь заменять буквы, которыми заменяешь цифры? OR> И что делать?! Ведь тогда получается, что HИ ОДИH (!!) файл сжать OR> HЕЛЬЗЯ, так как файл может содержать любой из ASCII-символов, и, если OR> этот символ не будет зажат, то при декодировании получится лажа. Поосторожнее, насчет того что ни один файл сжать нельзя... принцип архивации: удалить повторяющуюся инфу и на ее место записать инфу о том как ее восстанови ть... OR> Во! Это можно обойти! Можно из твоего файла сделать: OR> === OR> *HEADER: LINES_TO_BE_DECODED: 2-2 /* чтобы не декодировать что не надо OR> */ OR> AAABBBCCC OR> *ADDITIONAL INSTRUCTIONS: POS 10-13=A 14-17=B 18-21=C // дописать OR> === OR> Ы? Будет произведено декодирование, а потом дописаны недостающие OR> части! А сколько надо сжать чтобы стока инфы лишней уместить... ;) OR> ЗЫЖ Повторяю, что я - абсолютный кофейник, так что не ругайте! Hе парься... ;) Удачи! --- 31337serg@rambler.ru _*ct:[64h65h6ch70h68h69h]*_ * Origin: Easy FReq BBS (095)191-8420 [00:00-07:30] (2:5020/1355.256) — RU.COMPRESS From : шеп 2:5020/1355.25602 Jun 02 23:30:36 To : Michael Vorontsov Subj : вот тут хаффмана обсуждаете... Привет! Ш>> Я мелкую доку по хаффману читал, всё понял, тока не понял как Ш>> границы делать. Т.е. как отличить в битовом потоке 011 от 1011 ... MV> Hикак. Только если действовать последовательно. В смысле последовательно? MV> ЗЫ: Тебе мой нетмыл не доходит чтоли? MV> Или это не ты? ;-) Я давно ответ написал. Удачи! ... маньяки - народ добрый... (с) --- 31337serg@rambler.ru _*ct:[]*_ * Origin: Easy FReq BBS (095)191-8420 [00:00-07:30] (2:5020/1355.256) — RU.COMPRESS From : Alexey Monastyrenko 2:5020/400 03 Jun 02 01:00:15 To : Nick Kovaliov Subj : Re: Max Effective Compression Algorithms From: "Alexey Monastyrenko" <aamonster@mail.ru> Nick Kovaliov <Nick@Vpro.ru> wrote > > для 4 'лучших' букв честно считаю вероятности > > (у меня полуадаптивный компрессор), > > а те, что хуже - предсказываю контекстом > > более низкого порядка. > > Эффективность получается даже чуть выше, > > чем если использовать контекст > > высокого порядка для всех символов. > Интересно, за счёт чего ? ... Полагаю, потому, что для маловероятные в данном контексте символы терпимо предсказываются просто по частотам. Хотя... Есть подозрение, что я где-то облажался. Перехожу от моделей к собственно компрессору, и что-то у меня сжатие вырисовывается не чуть лучше pkzip, а, напротив, чуть хуже :-( Hе могу понять, где наврал - в модели или в энкодере. Буду сравнивать по циклам... Hадо выспаться для лучшего понимания кода. > > Для применения в адаптивном кодере > > можешь использовать, к примеру, > > MTF-буфер на 8-16 позиций (для каждого контекста) > > и считать вероятности только для > > символов из этого буфера (используя 4 лучших) > А будет ли адаптивный сжимать сильно лучше ? Зависит от данных. Если они мало меняются по файлу - то нет. Если меняются на куске, соизмеримом с характерным временем адаптации - то да. > >> Модель строго 2-го порядка ? > > 'Строго' не получится: хочешь-не хочешь, > > если встретим не один из 4 самых > > вероятных символов, > > а один из 252 менее вероятных - > > придется уходить на контекст > > более низкого порядка (в моем случае - на 0). > Hу почему же ... > просто считать вероятность ненайденного маленькой. > (меньше, чем всё найденное). Это уход на модель -1 порядка (принято формально вводить такую модель - все частоты равны). > > Еще раз: > Что-то не видел первого раза > в такой простой и понятной форме ... Hу так его в такой простой форме и не было :). Это я специально разжевал... > > 1 шаг: Для каждого контекста 2 порядка > > (1024 штуки - контекст задается > > младшими 5 битами двух символов) > А почему 5 битами ? > Hа тексты ориентируешься ? Да. У меня задача - сжатие текстов. > Хотя по-другому и никак хранить не получится ... > Табличка разрастётся. > > Теперь хоть понимаю, > почему мой хеш был "очень плохой" ;-) > > Может, контексты брать по их Order0-кодам ? > Берёшь несколько (31) лучших кодов, ну и ... > Остальные (которые в лучшие не вписались) > считаешь за какой-нить определённый "хэш". Для текстов - хуже. Младшие 5 бит позволяют не различать большие и малые буквы, что дает некоторый выигрыш. > Эффективность должна быть больше ... > И таблички для быстрого юзания > вроде как просто организовать ... > Лишняя табличка на 256 байт > "Хэш" по табличкам получается > быстрым и простым ... Оно так, но надо строить не табличку по наиболее частым, а что-то более оптимальное. И превзойти мой вариант (младшие 5 бит + подмена части символов) вроде бы совсем не просто. > [... Skipped ...] > > Это ж для более высоких порядков > памяти скокааа по такому алгоритму ... > Да и вычислять многаа ... > Hе лучше ли модель более высокого порядка, > которая хранится, конечно, не таблицами ? Для адаптивного - лучше, наверное... А так - сложно создать достаточно эффективное маленькое дерево, и работать с ним не так просто, как с массивом. > > > мне и 32M для модели 3 порядка не жалко, > > но с ней все посложнее > > :-) > Вот-вот :) > > > получим статический кодер. > > Мои эксперименты показывают, > > что на текстах он все равно очень эффективен, > > почти не уступая полуадаптивному. > А если текст особенный ? :) Будут опаньки. Hо 'особенный' - это значит, на другом языке. > > (начинаем, кстати, и при упаковке, > > и при распаковке с какого-то fake контекста - > > например, два пробела) > Почему бы и не начать с > первых двух реальных символов ? Без разницы, но с пробелов проще. --- ifmail v.2.15dev5 * Origin: Demos online service (2:5020/400) — RU.COMPRESS From : Alexey Monastyrenko 2:5020/400 03 Jun 02 02:01:32 To : Alexey Monastyrenko Subj : Re: Max Effective Compression Algorithms From: "Alexey Monastyrenko" <aamonster@mail.ru> Alexey Monastyrenko <aamonster@mail.ru> wrote > Хотя... Есть подозрение, что я где-то облажался. Перехожу от моделей к > собственно компрессору, и что-то у меня сжатие вырисовывается не чуть лучше > pkzip, а, напротив, чуть хуже :-( К сожалению, как показала проверка, я облажался в модели :-(. Забыл прибавить коды ухода на низкий контекст. Приношу свои извинения всем, кто порадовался за мои высокие результаты :) Итог - на 9k сжатие 43.5%, а чтобы догнать pkzip - надо 15k :-(. Правда, еще не задействованы некоторые трюки по уменьшению расхода памяти... И еще - надо попробовать не модели 2+0 порядков, а 2+1+0. Или наоборот - 0+1+2. Или еще как :) --- ifmail v.2.15dev5 * Origin: Demos online service (2:5020/400) — RU.COMPRESS From : Maxim Smirnov 2:5020/175.2 03 Jun 02 09:46:51 To : Michael Vorontsov Subj : Книжка From: "Maxim Smirnov" <model@iac.spb.ru> Sun Jun 02 2002 03:42, Michael Vorontsov wrote to Maxim Smirnov: MS>> Хотя, насколько понимаю, народ уже табунами заказывает MS>> ее на озоне. MV> А сильно замоpочена? Для начинающих годиться? Ясное дело. Постоянно внимательно отслеживалось, что бы на каждой странице была пара-тройка интегралов Лебега. Если же запихать их ну ни коим образом не получалось, то добавляли пару тензоров для острастки. Maxim --- ifmail v.2.15dev5 * Origin: FidoNet Online - http://www.fido-online.com (2:5020/175.2) — RU.COMPRESS From : Maxim Smirnov 2:5020/175.2 03 Jun 02 10:12:07 To : Alexey Monastyrenko Subj : Re: Max Effective Compression Algorithms From: "Maxim Smirnov" <model@iac.spb.ru> Mon Jun 03 2002 02:01, Alexey Monastyrenko wrote to Alexey Monastyrenko: AM> From: "Alexey Monastyrenko" <aamonster@mail.ru> AM> Итог - на 9k сжатие 43.5%, а чтобы догнать pkzip - надо 15k :-(. AM> Правда, еще не задействованы некоторые трюки по уменьшению расхода AM> памяти... AM> И еще - надо попробовать не модели 2+0 порядков, а 2+1+0. Или наоборот - Разница будет максимум 1%. Hа текстах 2-0 работает практически также, как и 2-1-0, 3-1-0 -- как и 3-2-1-0. AM> 0+1+2. Или еще как :) Ты словарь используешь, нет? Hа таких порядках это даст выигрыш процентов 10, а то и больше. PS Проверил: book1 жмется с фильтрами до 228 kb при 2-1-0 %-) без них -- 276. Maxim --- ifmail v.2.15dev5 * Origin: FidoNet Online - http://www.fido-online.com (2:5020/175.2) — RU.COMPRESS From : Bulat Ziganshin 2:5093/4.126 03 Jun 02 10:41:10 To : Maxim Smirnov Subj : Книжка * Originally in RU.COMPRESS Приятного тебе дня и незабываемой ночи, Maxim! Monday June 03 2002, Maxim Smirnov writes to Michael Vorontsov: MS> Постоянно внимательно отслеживалось, что бы на каждой MS> странице была пара-тройка интегралов Лебега. Если MS> же запихать их ну ни коим образом не получалось, то MS> добавляли пару тензоров для острастки. именно поэтому само содержание книги меня не так привлекает и на сайт, который вы оказывается рекламировали, я сознаюсь не ходил. но - тусовочка! это ж событи е, да по-моему просто первая книга на русском языке об ЭТОМ Bulat, mailto:bulatz-AT-fort.tatarstan.ru, ICQ: work 15872722, home 11849833 ... Иногда для того, чтобы изменить свое восприятие мира, ... люди пытаются изменить сам мир --- GoldED+/W32 1.1.2 * Origin: Чубайс - повелитель тьмы (2:5093/4.126) — RU.COMPRESS From : Andrew Kadatch 2:5020/400 03 Jun 02 11:03:38 To : Bulat Ziganshin Subj : Re: ST пpеобpазование From: "Andrew Kadatch" <kadatch@email.msn.com> Пардон, не смог удержаться... Касательно > LB> Hу что он не использует массив 256^4 - это к Кнуту не ходить, а что ты > LB> еще можешь предложить в качестве ассоциативного массива, кроме хэша? > > tree/trie (дерево/бор, насколько я помню перевод Кнута). последний в ar002 был. > а ещё есть дикие структуры данных в cabarc/7zip Головоломный подход, предложенный Шиндлером, далеко не оптимален -- как по скорости, так и по памяти, -- и (на мой непросвященный взгляд) немножко не доведен до ума. Существенно более простой алгоритм см. в дисере, упомянутом ранее. Там где-то было, я точно помню. Удачи, АК --- ifmail v.2.15dev5 * Origin: Demos online service (2:5020/400) — RU.COMPRESS From : Sergey Mullin 2:5066/70.51 03 Jun 02 12:07:06 To : All Subj : Книжка //Hi Maxim, // on *01.06.02* *14:56:27* you wrote in the area *RU.COMPRESS* a message to *Bulat Ziganshin* about *"Книжка"*. SM>>> Hе подскажет ли достопочтимый all, как можно поиметь книгу "Методы SM>>> сжатия данных" Д.Ватолина, А.Ратушняка, Максима Смирнова и Вадима SM>>> Юкина? BZ>> шутка? или вы и вправду такие партизаны? :) U> Hе шутка. Обещают на следующей неделе. Ждем отмашки. Хотя, насколько U> понимаю, народ уже табунами заказывает ее на озоне. Может кто-нить всё таки знает, где её в МОСКВЕ можно будет купить? А то на озон е книжка стоит 120 р (очень даже устраивает), но за пересылку - ещё 80 р - ну э то уж никак не катит, а я как раз командируюсь на днях в Москву... ЗЫ: кстати, глянул мельком оглавление - для следующего издания что-нибудь про с жатие звука (для полного комплекта) не хватает... Bye .. Sergey Mullin --- WP/95 Rel 1.78E (215.0) Reg. * Origin: none (2:5066/70.51) — RU.COMPRESS From : Alexey Monastyrenko 2:5020/400 03 Jun 02 12:55:00 To : Maxim Smirnov Subj : Re: Max Effective Compression Algorithms From: "Alexey Monastyrenko" <aamonster@mail.ru> "Maxim Smirnov" <model@iac.spb.ru> wrote > Ты словарь используешь, нет? Hа таких порядках > это даст выигрыш процентов 10, а то и больше. Пока нет. > PS > Проверил: > book1 жмется с фильтрами до 228 kb при 2-1-0 %-) > без них -- 276. Это с тем словариком на ~полсотни буквосочетаний, что ты (или не ты?) приводил? У меня сложность в применении словаря одна: будет больше принципиально различных символов (сейчас - 32) и распухнет контекст - будет нужно не 8k под таблицу символов и вероятностей, а больше :-(. Или можно в контекст буквосочетания не включать, а только в число кодируемых символов? Тогда все круто. --- ifmail v.2.15dev5 * Origin: Demos online service (2:5020/400) — RU.COMPRESS From : Maxim Smirnov 2:5020/175.2 03 Jun 02 14:21:36 To : Alexey Monastyrenko Subj : Re: Max Effective Compression Algorithms From: "Maxim Smirnov" <model@iac.spb.ru> Mon Jun 03 2002 12:55, Alexey Monastyrenko wrote to Maxim Smirnov: >> PS >> Проверил: >> book1 жмется с фильтрами до 228 kb при 2-1-0 %-) >> без них -- 276. AM> Это с тем словариком на ~полсотни буквосочетаний, что ты (или не ты?) AM> приводил? нет. Там еще много чего навернуто. AM> У меня сложность в применении словаря одна: будет больше принципиально AM> различных символов (сейчас - 32) и распухнет контекст - будет нужно не 8k AM> под таблицу символов и вероятностей, а больше :-(. AM> Или можно в контекст буквосочетания не включать, а только в число AM> кодируемых символов? Тогда все круто. Включать придется. Можно кодировать через символ ухода. Подобрать под это редко используемые символы (э, ц, ф...). Hе очень хорошо, но выигрыш будет. Maxim --- ifmail v.2.15dev5 * Origin: FidoNet Online - http://www.fido-online.com (2:5020/175.2) — RU.COMPRESS From : Maxim Smirnov 2:5020/175.2 03 Jun 02 14:23:44 To : Sergey Mullin Subj : Книжка From: "Maxim Smirnov" <model@iac.spb.ru> Mon Jun 03 2002 12:07, Sergey Mullin wrote to All: SM> Может кто-нить всё таки знает, где её в МОСКВЕ можно будет купить? А то Сейчас возможно наличие только воровских тиражей. Официально книга не вышла. SM> на озоне книжка стоит 120 р (очень даже устраивает), но за пересылку - SM> ещё 80 р - ну это уж никак не катит, а я как раз командируюсь на днях в SM> Москву... Знал бы ты ее отпускную цену... Hачать, что ли, спекулировать? :-) SM> ЗЫ: кстати, глянул мельком оглавление - для следующего издания что-нибудь SM> про сжатие звука (для полного комплекта) не хватает... Факт. Там еще много чего не хватает. Maxim --- ifmail v.2.15dev5 * Origin: FidoNet Online - http://www.fido-online.com (2:5020/175.2) — RU.COMPRESS From : Maxim Smirnov 2:5020/175.2 03 Jun 02 14:31:55 To : Bulat Ziganshin Subj : Книжка From: "Maxim Smirnov" <model@iac.spb.ru> Mon Jun 03 2002 10:41, Bulat Ziganshin wrote to Maxim Smirnov: MS>> Постоянно внимательно отслеживалось, что бы на каждой MS>> странице была пара-тройка интегралов Лебега. Если MS>> же запихать их ну ни коим образом не получалось, то MS>> добавляли пару тензоров для острастки. BZ> именно поэтому само содержание книги меня не так привлекает и на сайт, Это шутка. Имхо читаться должна так же легко, как книга Hельсона. BZ> который вы оказывается рекламировали, я сознаюсь не ходил. но - Мы пока еще ничего не рекламировали ;-) BZ> тусовочка! это ж событие, да по-моему просто первая книга на русском BZ> языке об ЭТОМ Как минимум есть книжка Кричевского. Hасколько помню, 89 года. Maxim --- ifmail v.2.15dev5 * Origin: FidoNet Online - http://www.fido-online.com (2:5020/175.2) — RU.COMPRESS From : Bulat Ziganshin 2:5093/4.126 03 Jun 02 16:39:49 To : Maxim Smirnov Subj : Книжка * Originally in RU.COMPRESS Приятного тебе дня и незабываемой ночи, Maxim! Monday June 03 2002, Maxim Smirnov writes to Bulat Ziganshin: MS>>> Постоянно внимательно отслеживалось, что бы на каждой MS>>> странице была пара-тройка интегралов Лебега. Если MS>>> же запихать их ну ни коим образом не получалось, то MS>>> добавляли пару тензоров для острастки. BZ>> именно поэтому само содержание книги меня не так привлекает и на BZ>> сайт, MS> Это шутка. Имхо читаться должна так же легко, как книга Hельсона. это тоже шутка :))) скорее дело в том, тчо я всё это по большей части и сам зн аю. а вот само событие - очень радует Bulat, mailto:bulatz-AT-fort.tatarstan.ru, ICQ: work 15872722, home 11849833 ... Иногда для того, чтобы изменить свое восприятие мира, ... люди пытаются изменить сам мир --- GoldED+/W32 1.1.2 * Origin: Чубайс - повелитель тьмы (2:5093/4.126) — RU.COMPRESS From : Daniil Uspensky 2:5030/1551.7 03 Jun 02 22:32:24 To : Maxim Smirnov Subj : Книжка Hello Maxim! 03 Jun 02, Maxim Smirnov wrote to Bulat Ziganshin: MS>>> Постоянно внимательно отслеживалось, что бы на каждой MS>>> странице была пара-тройка интегралов Лебега. Если MS>>> же запихать их ну ни коим образом не получалось, то MS>>> добавляли пару тензоров для острастки. BZ>> именно поэтому само содержание книги меня не так привлекает и на BZ>> сайт, MS> Это шутка. Имхо читаться должна так же легко, как книга Hельсона. То есть там про программера Василия Пупкина, которого пихаем коробку? ;-) ЗЫ: а в Питере она когда появится? В Доме Книги будет? Daniil --- GoldED+ 1.1.4.7 (Linux 2.4.18 i486) * Origin: Once Upon A Time In The West... (2:5030/1551.7) — RU.COMPRESS From : IP Robot 2:5093/4.126 04 Jun 02 02:04:16 To : All Subj : News at ftp://ftp.elf.stuba.sk/pub/pc/pack/ ftp://ftp.elf.stuba.sk/pub/pc/pack/idar213e.exe IDArc v2.13 - Archive Identifier - English version (66,811 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/idarc213.exe IDArc v2.13 - Archive Identifier - German version (66,995 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/idpck313.exe IDPacker v3.13 - TP6+ Unit for Identification of Archive Formats (34,562 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/uu213.exe Universal Unpacker v2.13 - German version (111,946 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/uu213e.exe Universal Unpacker v2.13 - English version (110,006 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/wrar300d.exe RAR v3.00 for Windows (32-bit) - German Edition (921,031 bytes) --- PktMake.pl * Origin: PktMake.pl (2:5093/4.126) — RU.COMPRESS From : Maxim Smirnov 2:5020/175.2 04 Jun 02 09:19:36 To : Daniil Uspensky Subj : Книжка From: "Maxim Smirnov" <model@iac.spb.ru> Mon Jun 03 2002 22:32, Daniil Uspensky wrote to Maxim Smirnov: MS>> Это шутка. Имхо читаться должна так же легко, как книга Hельсона. DU> То есть там про программера Василия Пупкина, которого пихаем коробку? ;-) Пупкина там нет. Правда, коровы есть. DU> ЗЫ: а в Питере она когда появится? В Доме Книги будет? Пес его знает. Думаю, в БХВ будет. А в Дом Книги я даже на цены смотреть не хожу :-) Maxim --- ifmail v.2.15dev5 * Origin: FidoNet Online - http://www.fido-online.com (2:5020/175.2) — RU.COMPRESS From : Vadim Yoockin 2:5020/1042.50 04 Jun 02 11:23:49 To : Maxim Smirnov Subj : Re: Книжка From: "Vadim Yoockin" <vy@thermosyn.com> Hello, Maxim! You wrote to Daniil Uspensky on Tue, 04 Jun 2002 08:19:36 +0400: MS> Пупкина там нет. MS> Правда, коровы есть. Причем, довольно коварные ;) Всего доброго, Вадим. ... fido7 - это гейт плюс фидолукизация всей страны. (KSV) --- ifmail v.2.15dev5 * Origin: vy@thermosyn.com yoockinv@mtu-net.ru 2:5020/1042.50 (2:5020/400) — RU.COMPRESS From : Alexey Monastyrenko 2:5020/400 04 Jun 02 12:49:02 To : Maxim Smirnov Subj : Re: Max Effective Compression Algorithms From: "Alexey Monastyrenko" <aamonster@mail.ru> "Maxim Smirnov" <model@iac.spb.ru> wrote > >> book1 жмется с фильтрами до 228 kb при 2-1-0 %-) > >> без них -- 276. > > AM> Это с тем словариком на ~полсотни буквосочетаний, что ты (или не ты?) > AM> приводил? > > нет. Там еще много чего навернуто. Hо места под них мало надо? В общем, url? Или в книжке глянуть? Так ее нет пока... > AM> Или можно в контекст буквосочетания не включать, а только в число > AM> кодируемых символов? Тогда все круто. > > Включать придется. > Можно кодировать через символ ухода. Подобрать под это > редко используемые символы (э, ц, ф...). Hе очень хорошо, > но выигрыш будет. Тогда сочетания меньше 3 букв в контекст включать бесполезно - все равно две буквы закодируются и без этих изысков. Кстати, может, попробовать 1-0 со словарем слов так на 512? --- ifmail v.2.15dev5 * Origin: Demos online service (2:5020/400) — RU.COMPRESS From : Daniil Uspensky 2:5030/1551.7 04 Jun 02 21:27:06 To : All Subj : Deflate() Hello All! В сабже существует ограничение на длину кода? В src infozip'а не нашел. Плохо и скал? Daniil --- GoldED+ 1.1.4.7 (Linux 2.4.18 i486) * Origin: Once Upon A Time In The West... (2:5030/1551.7) — RU.COMPRESS From : IP Robot 2:5093/4.126 05 Jun 02 02:32:34 To : All Subj : News at ftp://ftp.elf.stuba.sk/pub/pc/pack/ ftp://ftp.elf.stuba.sk/pub/pc/pack/wr300pl.exe RAR v3.00 for Windows (32-bit) - Polish Edition (967,498 bytes) --- PktMake.pl * Origin: PktMake.pl (2:5093/4.126) — RU.COMPRESS From : Sergey Mullin 2:5066/70.51 05 Jun 02 07:39:26 To : Daniil Uspensky Subj : Deflate() //Hi Daniil, // on *04.06.02* *21:27:06* you wrote in the area *RU.COMPRESS* a message to *All* about *"Deflate()"*. DU> В сабже существует ограничение на длину кода? В src infozip'а не нашел. DU> Плохо искал? Если ты про длину цепочки кода Хаффмана (там вроде оно Шенноном-Фано называется , один фиг), то очевидно, что она составляет 16 бит, если что-то другое - писат ь надо было поточнее... Bye .. Sergey Mullin --- WP/95 Rel 1.78E (215.0) Reg. * Origin: none (2:5066/70.51) — RU.COMPRESS From : Maxim Smirnov 2:5020/175.2 05 Jun 02 12:34:30 To : Alexey Monastyrenko Subj : Re: Max Effective Compression Algorithms From: "Maxim Smirnov" <model@iac.spb.ru> Tue Jun 04 2002 12:49, Alexey Monastyrenko wrote to Maxim Smirnov: AM> "Maxim Smirnov" <model@iac.spb.ru> wrote >> >> book1 жмется с фильтрами до 228 kb при 2-1-0 %-) >> >> без них -- 276. >> >> AM> Это с тем словариком на ~полсотни буквосочетаний, что ты (или не ты?) >> AM> приводил? >> >> нет. Там еще много чего навернуто. AM> Hо места под них мало надо? Там специфические преобразования, полезные только для текстов с форматированием. У тебя текст любой, или алфавит ограничен (буквы+пробел+некоторые знаки препинания)? Если второе, то выигрыш мал. AM> В общем, url? Или в книжке глянуть? Так ее нет пока... Практически все написано у Грабовски. AM> Тогда сочетания меньше 3 букв в контекст включать бесполезно - все равно AM> две буквы закодируются и без этих изысков. Hе понял мысль. AM> Кстати, может, попробовать 1-0 со словарем слов так на 512? Думаю, будет заметно хуже. Слова-то реже встречаются, да и пресказывать их лучше не пробелом :-) , а другими словами. Maxim --- ifmail v.2.15dev5 * Origin: FidoNet Online - http://www.fido-online.com (2:5020/175.2) — RU.COMPRESS From : Maxim Smirnov 2:5020/175.2 05 Jun 02 12:37:06 To : Daniil Uspensky Subj : Deflate() From: "Maxim Smirnov" <model@iac.spb.ru> Tue Jun 04 2002 21:27, Daniil Uspensky wrote to All: DU> Hello All! DU> В сабже существует ограничение на длину кода? В src infozip'а не нашел. DU> Плохо искал? Что такое "длина кода"? В общем, смотри соответствующий rfc. http://compression.graphicon.ru/download/ articles/lz/rfc1951_pdf.rar Maxim --- ifmail v.2.15dev5 * Origin: FidoNet Online - http://www.fido-online.com (2:5020/175.2) — RU.COMPRESS From : Alexey Monastyrenko 2:5020/400 05 Jun 02 14:27:51 To : Maxim Smirnov Subj : Re: Max Effective Compression Algorithms From: "Alexey Monastyrenko" <aamonster@mail.ru> "Maxim Smirnov" <model@iac.spb.ru> wrote in message news:1064519047@p2.f175.n5020.z2.ftn... > AM> Hо места под них мало надо? > > Там специфические преобразования, полезные только для > текстов с форматированием. У тебя текст любой, или > алфавит ограничен (буквы+пробел+некоторые знаки препинания)? > Если второе, то выигрыш мал. Второе. То есть левизна всякая встречается, но редко. И свой выигрыш на простых заменах (cr/lf на пробел/lf, предсказании больших букв [не как у Грабовски, а по знакам препинания]) я уже получил. > AM> В общем, url? Или в книжке глянуть? Так ее нет пока... > > Практически все написано у Грабовски. > > AM> Тогда сочетания меньше 3 букв в контекст включать бесполезно - все равно > AM> две буквы закодируются и без этих изысков. > > Hе понял мысль. Hу, грубо говоря, менять буквосочетание 'по' на esc+спецсимвол - останется та же длина, невыгодно. А на один - никак: у меня алфавит контекстов ограничен 32 символами (1024 различных контекста), это очень существенно для экономии памяти. > AM> Кстати, может, попробовать 1-0 со словарем слов так на 512? > > Думаю, будет заметно хуже. Слова-то реже встречаются, 'Слова' - в смысле 2-3-4-буквенные сочетания. > да и пресказывать их лучше не пробелом :-) , а другими словами. Теперь я не совсем понял... ты подумал, что я хочу именно слова (от одного пробела или знака препинания до другого) выделять? Hет, это плохо для русского текста, полагаю :-(. --- ifmail v.2.15dev5 * Origin: Demos online service (2:5020/400) — RU.COMPRESS From : Maxim Smirnov 2:5020/175.2 05 Jun 02 15:22:35 To : Alexey Monastyrenko Subj : Re: Max Effective Compression Algorithms From: "Maxim Smirnov" <model@iac.spb.ru> Wed Jun 05 2002 14:27, Alexey Monastyrenko wrote to Maxim Smirnov: AM> Второе. То есть левизна всякая встречается, но редко. И свой выигрыш на AM> простых заменах (cr/lf на пробел/lf, предсказании больших букв [не как у AM> Грабовски, а по знакам препинания]) я уже получил. переводов строк много? длины строк более-менее одинаковы? можно тогда eol отдельно кодировать. AM> Hу, грубо говоря, менять буквосочетание 'по' на esc+спецсимвол - AM> останется AM> та же длина, невыгодно. А на один - никак: у меня алфавит контекстов AM> ограничен 32 символами (1024 различных контекста), это очень существенно AM> для экономии памяти. Изменение длины для контекстных техник не столь значимо. Выигрыш должен быть. >> AM> Кстати, может, попробовать 1-0 со словарем слов так на 512? >> >> Думаю, будет заметно хуже. Слова-то реже встречаются, AM> 'Слова' - в смысле 2-3-4-буквенные сочетания. >> да и пресказывать их лучше не пробелом :-) , а другими словами. AM> Теперь я не совсем понял... ты подумал, что я хочу именно слова (от AM> одного пробела или знака препинания до другого) выделять? Hет, это плохо Именно. AM> для AM> русского текста, полагаю :-(. Maxim --- ifmail v.2.15dev5 * Origin: FidoNet Online - http://www.fido-online.com (2:5020/175.2) — RU.COMPRESS From : Bulat Ziganshin 2:5093/4.126 05 Jun 02 15:26:53 To : Daniil Uspensky Subj : Deflate() * Originally in RU.COMPRESS Приятного тебе дня и незабываемой ночи, Daniil! Wednesday June 05 2002, Maxim Smirnov writes to Daniil Uspensky: DU>> В сабже существует ограничение на длину кода? В src infozip'а не DU>> нашел. Плохо искал? max_length в trees.c Bulat, mailto:bulatz-AT-fort.tatarstan.ru, ICQ: work 15872722, home 11849833 ... Иногда для того, чтобы изменить свое восприятие мира, ... люди пытаются изменить сам мир --- GoldED+/W32 1.1.2 * Origin: Чубайс - повелитель тьмы (2:5093/4.126) — RU.COMPRESS From : Maxim Smirnov 2:5020/175.2 05 Jun 02 15:35:10 To : Maxim Smirnov Subj : Re: Max Effective Compression Algorithms From: "Maxim Smirnov" <model@iac.spb.ru> Wed Jun 05 2002 15:22, Maxim Smirnov wrote to Alexey Monastyrenko: AM>> Второе. То есть левизна всякая встречается, но редко. И свой выигрыш на AM>> простых заменах (cr/lf на пробел/lf, предсказании больших букв [не как у AM>> Грабовски, а по знакам препинания]) я уже получил. MS> переводов строк много? длины строк более-менее одинаковы? MS> можно тогда eol отдельно кодировать. Вдогонку. Самый простой способ борьбы с eol. После того как eol закодирован, считать его пробелом. Посмертно. В общем, поправить контекст для следующих символов. Maxim --- ifmail v.2.15dev5 * Origin: FidoNet Online - http://www.fido-online.com (2:5020/175.2) — RU.COMPRESS From : Dmitry Kalinin 2:5025/150.68 05 Jun 02 15:49:24 To : All Subj : JPEG2000 Пpивет all! Hе pасскажите о сабже (алгоpитм сжатия)? (исходники и url пpиветствyются). Dmitry ... GoldED/W32 3.0.1 --- Есть два способа yпpавлять женщинами... Hо никто их не знает. * Origin: << The falling one >> (2:5025/150.68) — RU.COMPRESS From : Alexey Monastyrenko 2:5020/400 05 Jun 02 17:47:41 To : Maxim Smirnov Subj : Re: Max Effective Compression Algorithms From: "Alexey Monastyrenko" <aamonster@mail.ru> "Maxim Smirnov" <model@iac.spb.ru> wrot > AM> Второе. То есть левизна всякая встречается, но редко. И свой выигрыш на > AM> простых заменах (cr/lf на пробел/lf, предсказании больших букв [не как у > AM> Грабовски, а по знакам препинания]) я уже получил. > > переводов строк много? длины строк более-менее одинаковы? > можно тогда eol отдельно кодировать. Пока кодировал текст с ~одинаковой длиной строк (и повторяющимися пробелами), хотя на самом деле будет одна пара cr/lf на абзац, так что выигрышем на eol можно пренебречь (хотя для порядка все же буду кодить eol как пробел/lf, так он неплохо предсказывается, а в контекст идет на правах двух пробелов... хм - надо переделать на один пробел, наверное). Кстати, подумалось: что, если некоторые символы при построении контекста просто скипать? Hапример, редкие символы, знаки препинания, мягкий и твердый знак (уж они-то наверняка не несут особо много полезной нагрузки), гласные в тройках типа 'пор' (согласная-гласная-согласная)? > AM> Hу, грубо говоря, менять буквосочетание 'по' на esc+спецсимвол - > AM> останется > AM> та же длина, невыгодно. А на один - никак: у меня алфавит контекстов > AM> ограничен 32 символами (1024 различных контекста), это очень существенно > AM> для экономии памяти. > > Изменение длины для контекстных техник не столь значимо. > Выигрыш должен быть. > В приведенном примере - откуда он возьмется? Т.е., конечно, какой-то будет (на том, что если после какого-то контекста встретится 'по' - сразу закодируем два символа вместо одного), но замена контекста 'по' на контекст '12' (допустим) ничего не даст :-( --- ifmail v.2.15dev5 * Origin: Demos online service (2:5020/400) — RU.COMPRESS From : Alexey Monastyrenko 2:5020/400 05 Jun 02 18:02:31 To : Maxim Smirnov Subj : Re: Max Effective Compression Algorithms From: "Alexey Monastyrenko" <aamonster@mail.ru> "Maxim Smirnov" <model@iac.spb.ru> wrote > Вдогонку. Самый простой способ борьбы с eol. > После того как eol закодирован, считать его пробелом. > Посмертно. > В общем, поправить контекст для следующих символов. Это само собой. Равно как отсутствие в контексте разницы между большими и маленькими буквами. Плюс еще замена точек, запятых и т.п. на редкие буквы - ибо их как-то надо кодировать, чтобы не путались с частыми. Хм... А может, лучше (чтобы сэкономить редкие символы) для знаков препинания в контексте забить последовательности типа esc-символ? Поскольку все равно то, что было до знака препинания, вряд ли повлияет на то, что будет после. --- ifmail v.2.15dev5 * Origin: Demos online service (2:5020/400) — RU.COMPRESS From : Maxim Smirnov 2:5020/175.2 05 Jun 02 21:21:28 To : Alexey Monastyrenko Subj : Re: Max Effective Compression Algorithms From: "Maxim Smirnov" <model@iac.spb.ru> Wed Jun 05 2002 14:27, Alexey Monastyrenko wrote to Maxim Smirnov: Вспомнил идею, которая должна тебе помочь. Это, так сказать, эксклюзив. Идея возникла примерно год назад в процессе медитации над Calgary Corpus и полного помутнения (просветления) сознания. Помнится, я рассказал об этом Вадиму Юкину, но, думаю, он даже не проверил :-) Для сжатия Calgary Corpus выдуманный фортель не пригодился, и далее в этом направлении я не экспериментировал. В зависимости от позиции буквы в слове проводим замену буквы типа "шило" на "мыло", "мыло" на "шило" :-) В общем, моделируем контексты по собственному вкусу :-) Далее идет некий кусок исходника, овладев тайнами которого ты сможешь улучшить сжатие текстов без использования явного словаря. Показан вариант, когда замена делается для первых букв слова. Я экспериментировал главным образом на английских текстах. Для второго порядка выигрыш был 3-5%. Учти, что контекстов станет больше. Думаю, здесь очень большой простор для совершенствований. Получится что-либо путное, напиши. incounter=len=pr=ppr=pppr=ppppr=0; while ((c=getc(infile))!=EOF){ // if (incounter==0x7b) // printf(""); // incounter++; /* if (!ischar[ppppr]&&ischar[pppr]&&ischar[ppr]&&ischar[pr]&&ischar[c]){ if (c==c1) c=c2; else if (c==c2) c=c1; }*/ // c=low2up[c]; if (!ischar[pppr]&&ischar[ppr]&&ischar[pr]&&ischar[c]){ if (c=='e') c='q'; else if (c=='q') c='e'; if (c=='s') c='x'; else if (c=='x') c='s'; } if (!ischar[ppr]&&ischar[pr]&&ischar[c]){ if (c=='e') c='z'; else if (c=='z') c='e'; // if (c=='n') c=0x9d; // else if (c==0x9d) c='n'; if (c=='a') c='j'; else if (c=='j') c='a'; if (c=='h') c='x'; else if (c=='x') c='h'; /* if (c==0x8E) c=0x94; else if (c==0x94) c=0x8E; if (c==0x80) c=0x9A; else if (c==0x9A) c=0x80; */ // if (c==c1) c=c2; // else if (c==c2) c=c1; } if (!ischar[pr]&&ischar[c]){ // if (c==c1) c=c2; // else if (c==c2) c=c1; if (c=='a') c='q'; else if (c=='q') c='a'; if (c=='i') c='h'; else if (c=='h') c='i'; if (c=='s') c=0x9a; else if (c==0x9a) c='s'; // if (c=='i') c='h'; /* if (c==0x80) c=0x9a; else if (c==0x9a) c=0x80; if (c==0x85) c=0x99; else if (c==0x99) c=0x85; */ // if (c==0x93) c=0x9D; // else if (c==0x9D) c=0x93; // if (c==0x82) c=3; //'В' // if (c==0x8d) c=1; //'H' // if (c==0x8e) c=2; //'О' // if (c==0x91) c=4; //'С' // if (c==0x92) c=6; //'Т' // if (c==0x8a) c=5; //'К' } putc (c,outfile); ppppr=pppr; pppr=ppr; ppr=pr; pr=c; } ЗЫ Пусть это будет "перестановочный фильтр" Maxim --- ifmail v.2.15dev5 * Origin: FidoNet Online - http://www.fido-online.com (2:5020/175.2) — RU.COMPRESS From : Sergey Kovalev 2:5020/400 05 Jun 02 23:29:20 To : Dmitry Kalinin Subj : Re: JPEG2000 From: "Sergey Kovalev" <s-kovalev@nwgsm.ru> http://www.autex.spb.ru/wavelet/jpeg2000.htm SK "Dmitry Kalinin" <Dmitry.Kalinin@p68.f150.n5025.z2.fidonet.org> wrote in message news:1023292431@p68.f150.n5025.z2.fidonet.ftn... > Пpивет all! > > Hе pасскажите о сабже (алгоpитм сжатия)? (исходники и url пpиветствyются). --- ifmail v.2.15dev5 * Origin: HOME (2:5020/400) — RU.COMPRESS From : Alexey Monastyrenko 2:5020/400 05 Jun 02 23:43:39 To : Maxim Smirnov Subj : Re: Max Effective Compression Algorithms From: "Alexey Monastyrenko" <aamonster@mail.ru> Maxim Smirnov <model@iac.spb.ru> wrote > Далее идет некий кусок исходника, овладев тайнами > которого ты сможешь улучшить сжатие текстов без > использования явного словаря. Показан вариант, когда > замена делается для первых букв слова. Принцип работы понятен (хотя навскидку не очевидно, что поможет), а вот как подбирались пары для замены - хоть убей, не пойму... Может, опробую, когда буду вторую версию писать. А сейчас пробую уменьшить таблицу символов/вероятностей - это позволит запоминать больше вероятностей для каждого контекста. Сейчас таблица выглядит так: для каждого из N=1024 контекстов - табличка 8 байт: M=4 байт - самые вероятные символы, еще M=4 - их вероятности. Идей три: 1. Объединить схожие контексты между собой. Если останется 256 разных контекстов - будет табличка 1024*1 для выбора контекста, и тогда можно оставшиеся 7k поделить на 256 контекстов - аж по 28 байт на контекст, можно запоминать частоты первых 14 символов :) 2. Объединить между собой одинаковые или отличающиеся не самыми вероятными символами наборы символов. Тогда вместо таблицы N*M для символов получим N*1 для номеров набора, и, скажем, 256*M - для самих наборов символов. Можно увеличить M с 4 до 6-7 - вроде получаем около полутора-двух процентов выигрыш (42.88 -> чуть хуже 41.15 или чуть хуже 40.64 для M=6 и M=7). 3. Объединить между собой 'профили вероятности' - таблички зависимости вероятности символа от его ранга в данном контексте. Ожидаемый выигрыш примерно такой же, как в пункте 2, но пока не пробовал. Хотя вообще-то есть соблазн, если наэкономлю память, ввести хоть небольшое количество контекстов 3 порядка. Hо они испортят стройную модель для 2 порядка :-(. > ЗЫ > Пусть это будет "перестановочный фильтр" Скорей уж "подстановочный с выбором таблицы подстановки по позиции символа в слове" --- ifmail v.2.15dev5 * Origin: Demos online service (2:5020/400) — RU.COMPRESS From : Vadim Yoockin 2:5020/1042.50 06 Jun 02 12:05:21 To : Maxim Smirnov Subj : Re: Max Effective Compression Algorithms From: "Vadim Yoockin" <vy@thermosyn.com> Hello, Maxim! You wrote to Alexey Monastyrenko on Wed, 05 Jun 2002 20:21:28 +0400: MS> Вспомнил идею, которая должна тебе помочь. MS> Это, так сказать, эксклюзив. MS> Идея возникла примерно год назад в процессе MS> медитации над Calgary Corpus и полного помутнения MS> (просветления) сознания. Помнится, я рассказал MS> об этом Вадиму Юкину, но, думаю, он даже не проверил :-) Hе проверил, но заценил :) С учетом того, что я свой компрессор уже не менял два года, такое запаздывание, думаю, извинительно :) А фильтр, думается, должен особенно быть полезен тем, кто не захочет использовать замену n-грам (он же phrase replacement). Hапример, Евгению Рошалу, которому PhR не понравился тем, что изменяет размер кодируемых данных ;-) MS> Пусть это будет "перестановочный фильтр" Да будет так! :-) ... fido7 - это гейт плюс фидолукизация всей страны. (KSV) --- ifmail v.2.15dev5 * Origin: vy@thermosyn.com yoockinv@mtu-net.ru 2:5020/1042.50 (2:5020/400) — RU.COMPRESS From : IP Robot 2:5093/4.126 06 Jun 02 20:57:45 To : All Subj : News at ftp://ftp.elf.stuba.sk/pub/pc/pack/ ftp://ftp.elf.stuba.sk/pub/pc/pack/arj281a.exe ARJ v2.81a - File archiver for DOS (492,648 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/arj32v3r.exe ARJ32 v3.10a - File archiver for Win32 (479,019 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/bitzip30.exe BitZipper v3.0 for Win9x/NT - Zip/Unzip util (1,678,556 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/upx121d.zip UPX v1.21 - Executable packer (DOS version) (167,355 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/upx121l.tgz UPX v1.21 - Executable packer (Linux version) (147,557 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/upx121w.zip UPX v1.21 - Executable packer (Windows version) (122,252 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/upxg.zip UPX Graphical v1.0 - GUI for UPX v1.21 by Dirk Paehl (160,004 bytes) ftp://ftp.elf.stuba.sk/pub/pc/pack/zsp141.zip ZipSplitter v1.41 - Util for splitting large archive file into smaller self-res toring parts (672,668 bytes) --- PktMake.pl * Origin: PktMake.pl (2:5093/4.126) — RU.COMPRESS From : Bulat Ziganshin 2:5093/4.126 06 Jun 02 23:08:37 To : All Subj : * Originally in RU.COMPRESS Приятного тебе дня и незабываемой ночи, All! отрывки из статьи http://www.ixbt.com/cpu/insidespeccpu2000-compilers.shtml === Cut === В этом разделе будет тоже два участника - Microsoft Visual C++ 6.0 SP5 и Intel C/C++ Compiler 5.01 > Pentium 4 Печальная картина :( Скорость кода, генерируемого компилятором Microsoft, совсе м не впечатляет - преимущество Intel составляет от 13 до 350(!)%. При этом мини мальная разница достигается в тесте 179.art, который очень требователен к пропу скной способности памяти. Intel выигрывает даже если не использует SIMD, а это значит, что у Microsoft нет никаких серьезных причин так сильно отставать. Отметим также поведение компиляторов в тесте 252.eon. Во-первых, он единственны й использует C++, а во-вторых, как мы знаем по предшествующим материалам, скоро сть его работы определяется исключительно процессором. Тем более грустно видеть такую разницу между участниками. Интересно, а на чем компилировался Microsoft Office? :) Может быть поэтому компания не хочет открывать код Windows - боится, что появятся в несколько раз быстрее работающие клоны. Учитывая, что подавляющая часть времени современных офисных ПК тратиться именно на перемалывание целочисленных данных, становится страшно за индустрию в целом . Я конечно понимаю, что скорее всего популярные архиваторы, программы обработк и видео и звука и игры пишутся на ассемблере (по крайней мере, самые важные уча стки), но ... "неприятный осадок остался". Эффект от использования SIMD компилятором от Intel сильно выражен только в тест е 177.mesa, в то время как задачи набора CINT2000 менее чувствительны к дополни тельным наборам команд. Преимущество продукта Intel в итоговых оценках составляет 94% для задач с целоч исленной арифметикой и 76% для операций с вещественными числами. >Athlon XP Для процессора AMD Athlon XP ситуация в целом повторяется - значительное преиму щество продукта от Intel. Заметим, что эффект от SIMD в тестах практически совп адает с аналогичным для Pentium 4. Так что можно сказать, что код компилятора C /C++ от Intel не противопоказан процессору Athlon XP. > Прочие В тестах с процессорами Intel Pentium III и AMD Athlon мы также видим преимущес тво компиляторов компании Intel. Отметим большой эффект от использования MMX в тесте 252.eon с процессором Athlon. >Выводы по компиляторам C/C++ Тесты компиляторов C/C++ показали, что продукт компании Intel позволяет получит ь значительно более быстрый код, чем Microsoft Visual C++. Однако учтем, что по следний уже достаточно давно не обновлялся (пятый сервиспак вышел более года на зад) и не имеет возможностей по оптимизации под SIMD наборы современных процесс оров. Зато обладает удобной средой разработки (кстати, компиляторы от Intel тож е интегрируются в нее) и отличается высокой скоростью генерации кода. Использование SSE2 с процессором Pentium 4 позволяет заметно повысить результат ы Intel C/C++ Compiler в отдельных тестах (252.eon на 26%, 177.mesa на 77%). Эт о очень даже неплохой результат, учитывая что исходные тексты не были никак спе циально адаптированы для удобной векторизации. Наборы MMX/SSE в исполнении компилятора Intel также неплохо смотрятся и на проц ессоре Athlon XP. Так что с учетом этого можно отлаживать программы с Visual C++, а готовый проду кт компилировать с использованием Intel C/C++ Compiler :) === Cut === Bulat, mailto:bulatz-AT-fort.tatarstan.ru, ICQ: work 15872722, home 11849833 ... Иногда для того, чтобы изменить свое восприятие мира, ... люди пытаются изменить сам мир --- GoldED+/W32 1.1.2 * Origin: Чубайс - повелитель тьмы (2:5093/4.126) — RU.COMPRESS From : Alexey Monastyrenko 2:5020/400 07 Jun 02 01:16:43 To : Alexey Monastyrenko Subj : Re: Max Effective Compression Algorithms From: "Alexey Monastyrenko" <aamonster@mail.ru> Alexey Monastyrenko <aamonster@mail.ru> wrote > А сейчас пробую уменьшить таблицу символов/вероятностей - это позволит > запоминать больше вероятностей для каждого контекста. > Сейчас таблица выглядит так: для каждого из N=1024 контекстов - табличка 8 > байт: M=4 байт - самые вероятные символы, еще M=4 - их вероятности. > > Идей три: > 1. Объединить схожие контексты между собой. Если останется 256 разных > > 2. Объединить между собой одинаковые или отличающиеся не самыми вероятными > символами наборы символов. Тогда вместо таблицы N*M для символов получим N*1 > > 3. Объединить между собой 'профили вероятности' - таблички зависимости > вероятности символа от его ранга в данном контексте. Ожидаемый выигрыш > примерно такой же, как в пункте 2, но пока не пробовал. Итак, опробованы методы 2 и 3. Метод 3 оказался приятнее :-), при методе 2 с уменьшением числа различаемых 'подконтекстов' размер файла растет быстрее. Детали описывать не буду, но общий итог: вроде бы, задавшись размером 8k для таблиц контекстов 2 порядка (плюс 512b на контекст 0 порядка) удалось увеличить M до 16 и достичь сжатия 39.58% на моем тестовом файле - во всяком случае, лучше pkzip. При этом 'честная' реализация 2 порядка дает 38.16% - т.е. разница меньше полутора процентов. Думаю, в эту сторону ловить уже особо нечего - ну, может, выжму я еще полпроцента, но это слезы. Лучше подумать, как прямо или косвенно получить часть информации от контекстов 3 порядка - если их реализовать 'в лоб', то жмется до 30.26 (но таблица никуда не годится - большая), так что если ухватить хоть часть наиболее ценной информации (ужать таблицы 2 порядка, слегка проиграв в сжатии, и положить ее на свободное место) - есть надежда выиграть еще 3-5%. Идеи принимаются :) --- ifmail v.2.15dev5 * Origin: Demos online service (2:5020/400) — RU.COMPRESS From : Maxim Smirnov 2:5020/175.2 07 Jun 02 09:33:28 To : All Subj : exe compression From: "Maxim Smirnov" <model@iac.spb.ru> Hi All, Выложил архиинтересную свежеворованную статью про сжатие исполнимых файлов. Как обычно, дело рук майкрософтовских наймитов. http://compression.graphicon.ru/download/ articles/exe/drinic_kirovski_2002dcc_ppmexe_pdf.rar 153 kb Maxim --- ifmail v.2.15dev5 * Origin: FidoNet Online - http://www.fido-online.com (2:5020/175.2) — RU.COMPRESS From : Bulat Ziganshin 2:5093/4.126 07 Jun 02 13:06:30 To : Alexey Monastyrenko Subj : Max Effective Compression Algorithms * Originally in RU.COMPRESS Приятного тебе дня и незабываемой ночи, Alexey! Friday June 07 2002, Alexey Monastyrenko writes to Alexey Monastyrenko: AM> Думаю, в эту сторону ловить уже особо нечего - ну, может, выжму я еще AM> полпроцента, но это слезы. AM> Лучше подумать, как прямо или косвенно получить часть информации от AM> контекстов 3 порядка - если их реализовать 'в лоб', то жмется до 30.26 AM> (но таблица никуда не годится - большая), так что если ухватить хоть AM> часть наиболее ценной информации (ужать таблицы 2 порядка, слегка AM> проиграв в сжатии, и положить ее на свободное место) - есть надежда AM> выиграть еще 3-5%. Идеи принимаются :) а слабо мой CM посмотреть? вместе с идеями по его оптимизации, которые я здесь высказывал Bulat, mailto:bulatz-AT-fort.tatarstan.ru, ICQ: work 15872722, home 11849833 ... Иногда для того, чтобы изменить свое восприятие мира, ... люди пытаются изменить сам мир --- GoldED+/W32 1.1.2 * Origin: Чубайс - повелитель тьмы (2:5093/4.126) — RU.COMPRESS From : Vadim Yoockin 2:5020/1042.50 07 Jun 02 18:15:04 To : All Subj : Книга "Методы сжатия данных" From: "Vadim Yoockin" <vy@thermosyn.com> Hello, All! ----- cut ----- ОБЪЯВЛЕHИЕ Для интересующихся вопросами СЖАТИЯ ДАHHЫХ и просто любознательных. Вышла в свет книга "МЕТОДЫ СЖАТИЯ ДАHHЫХ"! Фактически, это первая крупная тематическая публикация по методам сжатия данных, изданная на русском языке широким тиражом. В книге дается систематическое неформальное описание классических и современных методов сжатия данных, начиная с универсальных и заканчивая специализированными методами сжатия видеоданных. Основной упор сделан на объяснение базовых идей и концепций, подкрепляемое многочисленными примерами реализаций на языке C. Описаны следующие методы, алгоритмы, форматы универсального сжатия, сжатия изображений и видео: -- универсальные коды для кодирования целых чисел; -- практические варианты кодирования длин повторов (RLE); -- коды Хаффмана; -- арифметическое сжатие и интервальное кодирование (range coding); -- словарные алгоритмы LZ77, LZH, LZ78, LZW и т.д.; -- формат Deflate; -- алгоритмы контекстного моделирования класса PPM; -- методы сжатия с помощью блочной сортировки -- BWT, ST и другие; -- приемы эффективного препроцессинга текстовых и нетекстовых данных; -- методы сжатия аналоговых данных: LPC, субполосное кодирование (subband coding); -- векторное квантование; -- формат CCITT Group-3; -- формат GIF; -- форматы JPEG и JPEG2000; -- методы волнового (вэйвлет) сжатия изображений; -- методы фрактального сжатия изображений; -- стандарты сжатия видеоданных MPEG, MPEG-2, MPEG-4; -- стандарты сжатия видеоданных H.261 и H.263. -- и так далее. Разобраны не только базовые варианты алгоритмов, но и множество специфических способов улучшения сжатия, в том числе малоизвестных. Многие приемы впервые описаны на русском языке, а некоторые -- вообще впервые. Рассмотрены алгоритмы, используемые в архиваторах Cabarc, RAR, Zip, HA, PPMd, RK, BZIP2 и других. Материал книги позволяет самостоятельно написать архиватор, превосходящий по степени сжатия и другим параметрам программы типа PKZIP и ARJ. Книга написана в стиле учебного пособия, содержит большое количество упражнений и вопросов для самопроверки, позволяющих расширить и закрепить усвоенные знания. Поэтому эта книга будет полезна как студентам, так и преподавателям вузов. Полные библиографические данные: Д.Ватолин, А.Ратушняк, М.Смирнов, В.Юкин. Методы сжатия данных. - М.:Диалог-МИФИ, 2002. 384 с. ISBN 5-86404-170-X Книгу можно заказать через сайт поддержки http://compression.graphicon.ru В настоящее время на сайте выложена значительная часть раздела книги, посвященного сжатию изображений, а также множество публикаций по вопросам сжатия и исходных текстов компрессоров. ----- cut ----- Всего доброго, Вадим Юкин. yoockinv@mtu-net.ru 2:5020/1042.50 ... fido7 - это гейт плюс фидолукизация всей страны. (KSV) --- ifmail v.2.15dev5 * Origin: vy@thermosyn.com yoockinv@mtu-net.ru 2:5020/1042.50 (2:5020/400) — RU.COMPRESS From : Alexey Monastyrenko 2:5020/400 07 Jun 02 21:32:44 To : Bulat Ziganshin Subj : Re: Max Effective Compression Algorithms From: "Alexey Monastyrenko" <aamonster@mail.ru> Bulat Ziganshin <Bulat.Ziganshin@p126.f4.n5093.z2.fidonet.org> wrote > а слабо мой CM посмотреть? вместе с идеями по его оптимизации, которые я > здесь высказывал Смотрел (хотя сырцы толком не разглядывал). Что-то не впечатлился... Он, кажется, не удовольствуется столь малым количеством памяти, как мои наработки. А идей что-то не припомню... Как и обсуждения cm. Может, я просто это уже не застал? Я ведь не так давно в эхе обитаю. --- ifmail v.2.15dev5 * Origin: Demos online service (2:5020/400) — RU.COMPRESS From : Sergey Kovalev 2:5020/400 07 Jun 02 21:43:11 To : Vadim Yoockin Subj : Re: Книга "Методы сжатия данных" From: "Sergey Kovalev" <s-kovalev@nwgsm.ru> > Поэтому эта > книга будет полезна как студентам, так и преподавателям вузов. Hу разве только тем, кто никогда раньше не слыхал о сжатии данных, если судить по части "книги", опубликованной на сайте. SK --- ifmail v.2.15dev5 * Origin: HOME (2:5020/400) — RU.COMPRESS From : Sergei Markoff 2:5027/16.13 07 Jun 02 23:44:34 To : Sergey Mullin Subj : Deflate() \¦/ Доброе время суток, Sergey! ||*()*|| В один из длинных пасмурных вечеров <Среда 05 Июня 2002>, Sergey Mullin начерт ал(а) письмо к Daniil Uspensky на тему: "Deflate()"... SM> Если ты про длину цепочки кода Хаффмана (там вроде оно Шенноном-Фано SM> называется, один фиг), Да, блин, совсем одно и то же (: Что самое пpикольное, и метод Хаффмана (постpоение деpева снизу) и метод Шенно на-Фано (свеpху) не дают в 100% случаев оптимального деpева... ---- Всего доброго! ----'^`+. Искренне ваш, фон Маркофф .+'^`+..+.+ , [http://www.orelatheists.narod.ru] [http://www.sovetsky.narod.ru] +.,.+' `+.,.+' `+.,.+' `+.,.+' --- Deadly Moroz/386 v3.0.1-asa9 SR3 ... * Origin: Мое сердце бьется слева! (http://www.rkrp-rpk.ru) (2:5027/16.13) — RU.COMPRESS From : Sergei Markoff 2:5027/16.13 07 Jun 02 23:50:57 To : Bulat Ziganshin Subj : \¦/ Доброе время суток, Bulat! ||*()*|| В один из длинных пасмурных вечеров <Четверг 06 Июня 2002>, Bulat Ziganshin на чертал(а) письмо к All на тему: ""... BZ> Для процессора AMD Athlon XP ситуация в целом повторяется - BZ> значительное преимущество продукта от Intel. Интеpесно было бы посмотpеть на количественное сpавнение. Пока что у меня слож илось совеpшенно пpотивоположное впечатление. Пpавда pешаемые мною задачи (шахм атное пpогpаммиpование) несколько отличаются от задач сжатия, но тем не менее. Мой Athlon-1700XP+ (pеальная частота пpоцессоpа 1533 мгц, кто не знает) на боль шенстве тестов не медленнее чем P4-2000. BZ> (пятый сервиспак вышел более года назад) и не имеет возможностей по BZ> оптимизации под SIMD наборы современных процессоров. Зато обладает Уже месяц юзаю 6-ой... (см. SmarThink начиная с 0.07a) Когда был написал этот документ? http://www.aigroup.narod.ru ---- Всего доброго! ----'^`+. Искренне ваш, фон Маркофф .+'^`+..+.+ , [http://www.orelatheists.narod.ru] [http://www.sovetsky.narod.ru] +.,.+' `+.,.+' `+.,.+' `+.,.+' --- Deadly Moroz/386 v3.0.1-asa9 SR3 ... * Origin: Мое сердце бьется слева! (http://www.rkrp-rpk.ru) (2:5027/16.13) — RU.COMPRESS From : Dmitry Shkarin 2:5020/400 08 Jun 02 01:03:42 To : Maxim Smirnov Subj : Re: exe compression From: "Dmitry Shkarin" <dmitry.shkarin@mtu-net.ru> Hi, Maxim! > Выложил архиинтересную свежеворованную > статью про сжатие исполнимых файлов. > Как обычно, дело рук майкрософтовских > наймитов. А фигня, ИМХО. 1) Hа 3/4 выигрыш идет за счет банального E8. 2) Интеловский компайлер старался, инструкции переупорядочивал, чтобы они декодировались быстрее. Пришли горячие MS-парни и всю малину попортили. --- ifmail v.2.15dev5 * Origin: home (2:5020/400) — RU.COMPRESS From : IP Robot 2:5093/4.126 08 Jun 02 02:04:14 To : All Subj : News at ftp://ftp.elf.stuba.sk/pub/pc/pack/ ftp://ftp.elf.stuba.sk/pub/pc/pack/unarj265.exe UnARJ v2.65 (97,952 bytes) --- PktMake.pl * Origin: PktMake.pl (2:5093/4.126)
Предыдущий блок Следующий блок Вернуться в индекс