| Предыдущий блок | Следующий блок | Вернуться в индекс |
— RU.COMPRESS From : Vova Orlov 2:5030/732.27 18 Jul 00 08:37:48 To : All Subj : exe pack Hello everybody. А почему пакованая win32 программа в памяти места больше занимает, чем непакова нная? Vova --- GoldED+/W32 1.1.4.5 * Origin: (2:5030/732.27) — RU.COMPRESS From : Anatoly Popov 2:5003/7.2 18 Jul 00 10:57:00 To : All Subj : История с географией ;) Привет, All! Я тут пишу небольшой мануал для юзеров ;), в результате самому понадобился учеб ник сабжа ;))) Поправьте меня. Короче, в тексте есть краткий обзор средств архи вирования и резервного копирования информации, доступных простому юзеру, но воз никают сомнения по поводу корректности моих личных наблюдений и сведений фактич еского характера. По поводу следующего отрывка хотелось бы услышать критический отзыв, правильно ли я понял причину "обделенности" зипов всяческими фичами (по сравнению с ARJ, например): >=== Cut === Архиваторы PKZIP/PKUNZIP (автор Phillip Katz, компания PKWARE, Inc., США), WinZip (компания Nico Mak Computing, Inc., США) Имеют <родственников> на всех или почти всех платформах и системах, формат архива является общепризнанным фактическим стандартом при обмене информацией по сетям, и в этом его главное достоинство. Однако такой широкий <ареал обитания> и вытекающая отсюда проблема совместимости архивов, по всей видимости, стали главным сдерживающим фактором на пути оснащения всего <семейства> различными полезными возможностями. Архивы имеют расширение ZIP. >=== Cut === А в следующем отрывке хотелось бы проверить достоверность сведений, помеченных знаками вопроса: >=== Cut === Кроме того, вы вполне можете встретиться с архивами, созданными другими популярными ранее архиваторами: LHA (автор Haruyasu Yoshizaki, Япония (???)) Развитие этого компактного архиватора прекратилось примерно в 1992 (???) году, но благодаря ему (???) утвердился формат командной строки и набор команд архиватора, ставший фактическим стандартом или образцом для подражания для последователей, в том числе ARJ и RAR. Архивы имеют расширение LZH. HA (автор Harri Hirvola, Финляндия) еторопливый, но хорошо сжимающий архиватор, излюбленное средство для упаковки текстов в электронных библиотеках. Развитие прекратилось предположительно в 1993 (???) году. Архивы имеют расширение HA. >=== Cut === Заранее спасибо. Пока Анатолий --- * Origin: Сыктывкар, Республика Коми (2:5003/7.2) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 18 Jul 00 13:09:58 To : Vova Orlov Subj : exe pack * Originally in RU.COMPRESS Hello Vova! Tuesday July 18 2000, Vova Orlov writes to All: VO> А почему пакованая win32 программа в памяти места больше занимает, VO> чем VO> непакованная? потому, что хранятся и исходные, и распакованные данные (afaik) Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 ... Иногда для того, чтобы изменить свое восприятие мира, ... люди пытаются изменить сам мир --- GoldED+/W32 1.1.2 * Origin: А чем занимается херомантия? (2:5093/28.126) — RU.COMPRESS From : Denis Smirnov 2:5020/1785.1 18 Jul 00 16:01:08 To : Bulat Ziganshin Subj : Сжатие писем ---- OS/2 Привет Bulat! Ответ на письмо от Bulat Ziganshin к Denis Smirnov: BZ> но если ты хочешь сделать побыстрее, то я тебе не советую этим заниматься. BZ> это всего несколько процентов и при этом неотработанная еще технология. BZ> если уж ее использовать, то проще взять преобразования одного поляка BZ> (народ, как его зовут?) - они дают выигрыш в те же несколько процентов и BZ> исключительно просты в реализации Где взять описание? BZ>>> 2) расширить его словарь - работы на пару недель. все современные BZ>>> lzh'и так, похоже, и сделаны DS>> Ты имеешь в виду работу со словарем большого объема? BZ> да А зачем это надо на таких маленьких объемах? BZ> если хочется дешево и сердито, то просто сжимай в ppmd по 16 мессаг. и BZ> попробуй разобраться, как в нем организовать сохранение/чтение статистики BZ> - тогда ты сможешь еще улучшить сжатие. впрочем, не факт, что намного - BZ> проверь. BZ> возможно, все же лучше взять bzip2. на текстах сжатие у него ненамного BZ> хуже, для юниксов это уже почти стандарт, распаковка у него быстрее и BZ> памяти кушает меньше Логично. А можно как-нибудь эти мессаги переработать предварительно, чтобы улучшить сжатие? С уважением, Denis! --- mailto:mithraen@mtu-net.ru ICQ:58417635 * Origin: Windows: From the people who brought you EDLIN! (2:5020/1785.1) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 18 Jul 00 16:02:59 To : Anatoly Popov Subj : История с географией ;) * Originally in RU.COMPRESS Hello Anatoly! Tuesday July 18 2000, Anatoly Popov writes to All: AP> По поводу следующего отрывка хотелось бы услышать критический отзыв, AP> правильно ли я понял причину "обделенности" зипов всяческими фичами AP> (по сравнению с ARJ, например): причина - в характере янга. шило в заднице. pkzip имел вполне приличный по свои м временам набор возможностей AP> LHA (автор Haruyasu Yoshizaki, Япония (???)) точно AP> но благодаря ему (???) утвердился формат командной строки lharc/lha были заметными фигурами, но кроме них много кто использовал такую же ком. строку. трудно судить, имхо. Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 ... Иногда для того, чтобы изменить свое восприятие мира, ... люди пытаются изменить сам мир --- GoldED+/W32 1.1.2 * Origin: А чем занимается херомантия? (2:5093/28.126) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 18 Jul 00 19:15:58 To : Denis Smirnov Subj : Сжатие писем *** Answering a msg posted in area CARBON_COPIES (CARBON_COPIES). * Originally in RU.COMPRESS Hello Denis! Tuesday July 18 2000, Denis Smirnov writes to Bulat Ziganshin: BZ>> но если ты хочешь сделать побыстрее, то я тебе не советую этим BZ>> заниматься. это всего несколько процентов и при этом BZ>> неотработанная еще технология. если уж ее использовать, то проще BZ>> взять преобразования одного поляка (народ, как его зовут?) - они BZ>> дают выигрыш в те же несколько процентов и исключительно просты в BZ>> реализации DS> Где взять описание? у народа. вадим юкин, например, должен был с ним общаться. szymon grabowski, пр имерно BZ>>>> 2) расширить его словарь - работы на пару недель. все BZ>>>> современные lzh'и так, похоже, и сделаны DS>>> Ты имеешь в виду работу со словарем большого объема? BZ>> да DS> А зачем это надо на таких маленьких объемах? не нужно BZ>> если хочется дешево и сердито, то просто сжимай в ppmd по 16 BZ>> мессаг. и попробуй разобраться, как в нем организовать BZ>> сохранение/чтение статистики - тогда ты сможешь еще улучшить BZ>> сжатие. впрочем, не факт, что намного - проверь. возможно, все же BZ>> лучше взять bzip2. на текстах сжатие у него ненамного хуже, для BZ>> юниксов это уже почти стандарт, распаковка у него быстрее BZ>> и памяти кушает меньше DS> Логично. А можно как-нибудь эти мессаги переработать DS> предварительно, чтобы улучшить сжатие? ты имеешь в виду предв. проход? смотри первый абзац Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 ... Иногда для того, чтобы изменить свое восприятие мира, ... люди пытаются изменить сам мир --- GoldED+/W32 1.1.2 * Origin: А чем занимается херомантия? (2:5093/28.126) — RU.COMPRESS From : Andrew Aksyonoff 2:5036/29.2 18 Jul 00 21:31:04 To : Alexey Zolotarev Subj : Упаковка сигнала в real-time Hello Alexey! 17 Jul 00 00:44, Alexey Zolotarev wrote to Andrew Aksyonoff: AA>> Если упаковка хотя бы один размер уменьшает размер и не теряет AZ> не совсем понятно это pаз-+--- ^^^^^^ или действительно pазмеp ? "Раз", конечно. AZ> Вопpос можно ? А если pазмеp уменьшается ... >>, ... >>> и восстанавливаются после декодиpования исходные данные... То кто-то врет. AA>> Hу я хренею просто с твоих определений. AZ> Опpеделения только сковывают интеллект...хотя не скpою, знать нужно... А, еще один интуитивист написал суперархиватор... - Andrew ... Into the mercy seat I climb, my head is shaved, my head is wired... --- ged386-pl2.50-dos & * Origin: unknown. (2:5036/29.2) — RU.COMPRESS From : ZAB 2:5020/400 18 Jul 00 22:08:04 To : All Subj : Тест From: "ZAB" <ZAnatolyB@Mail.ru> --- ifmail v.2.15dev5 * Origin: NeoToN (2:5020/400) — RU.COMPRESS From : ZAB 2:5020/400 18 Jul 00 22:11:35 To : All Subj : Чего-то я не въезжаю! From: "ZAB" <ZAnatolyB@Mail.ru> При прочтении BWT FAQ напоролся на: "За счет упpощения пpоцедуpы соpтиpовки увеличивается скоpость сжатия по сpавнению с BWT, но pасжатие становится медленнее из-за необходимости обpаботки одинаковых контекстов"! Это про что? Весь алгоритм расжатия строится на том, что 1 столбец матрицы был сортирован, а на то были ли сортированы все остальные столбцы ему глубоко начхать!? Разве не так? --- ifmail v.2.15dev5 * Origin: NeoToN (2:5020/400) — RU.COMPRESS From : ZAB 2:5020/400 18 Jul 00 22:11:40 To : All Subj : В какую сторону пускать ППМ? From: "ZAB" <ZAnatolyB@Mail.ru> При прочтении BWT FAQ напоролся вот на что: "Если соpтиpовать в дpугом поpядке - не слева напpаво, а спpава налево, ухудшается сжатие текстовых файлов ...."! Так может ППМ на текстах будет давать лучшие результаты при проходе из конца в начало? --- ifmail v.2.15dev5 * Origin: NeoToN (2:5020/400) — RU.COMPRESS From : Maxim Litvinov 2:5020/400 18 Jul 00 23:06:26 To : Bulat Ziganshin Subj : Fileecho Annonce From: "Maxim Litvinov" <limax@hot.ee> Здравствуй, "Bulat Ziganshin" <Bulat.Ziganshin@p126.f28.n5093.z2.fidonet.org>! Ты писал(а): > ============================================================================= > - GFD.APP.ARC (FTN| Application - Archivers *) ------------------------------ - > ace20b1.exe 494,873 Archiver ACEv2.0b1 (DOS/Win32/OS2). Copyright by ACE > Compression Software. > от 2:2490/3045 через 2:5049/36 > ----------------------------------------------------------------------------- - > Total: 1 file(s) of 494,873 byte(s) > ============================================================================= Сорри, если чайниковский вопрос, но как его из инета надыбать? Hа ftp.elf.stuba.sk его нет. -- Всего хорошего. Maxim <limax@hot.ee> --- ifmail v.2.15dev5 * Origin: Fidolook Express 2.000 www.fidolook.da.ru (2:5020/400) — RU.COMPRESS From : Maxim Litvinov 2:5020/400 18 Jul 00 23:47:21 To : Dima Petukhov Subj : Re: Упаковка сигнала в real-time From: "Maxim Litvinov" <limax@hot.ee> Здравствуй, "Dima Petukhov" <Dima.Petukhov@p12.f1517.n5020.z2.fidonet.org>! Ты писал(а): > 1. А может можно было и повежливей? Ок, в следующий раз буду. :-) Сорри, если обидел кого (никого не хотел), просто у меня манера говорить такая ("Свиньи мы"). :-/ > 2. Опpеделяюсь в теpминах - необходимо чтобы упаковка не увеличивала pазмеp ( в > битах если очень нpавится) пpи любом входном сигнале. Пакуются отсчеты ^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^ Такое невозможно по определению. Точнее вру, возможно: просто копировать вход в выход (можно его закодировать), только тут и упаковки HЕ БУДЕТ никогда :о) > фиксиpованной битовой длины, пишутся в слова дpугой битовой длины (опциональн о > на этапе pазpаботки алгоpитма). Добавление к _всем_ отсчетам лишних бит не > волнует - но в штуках кол-во возpастать не должно никогда. И pазумеется в одном Странно, конечно... Только откуда ты их брать собираешься? Представь: неупакованные данные занимают скажем 100 отчётов по 16 бит = 200 Бай т = 1600 бит Скажем, к КАЖДОМУ отчёту прибавляется 1 бит. Тогда абсолютно непакующиеся данны е с данной "упаковкой" займут 100*17=1700 бит Если в обоих случаях (и с упаковкой и без) используется одна и та же память, то данные без упаковки занимают однозначно меньше, т.е. происходит увеличение размера данных. Другое дело, если неупакованные данные HИКОГДА не используют один бит в КАЖДОМ отчёте (например самый старший бит). Вот тогда этот упаковочный overhead спокойно там размещается. > выходном слове должно быть не более одного отсчета (чтоб не возникало > пpедложений записать по 100 отсчетов в длинную стpоку бит :). Следуя твоей логике, то как раз если записать 200 байт (по 8 бит) во 100 слов (по 16 бит), то произойдёт двухкратное уменьшение размера данных. Размер слова ведь строго ограниченный? Строго - ровно 16 бит, и никогда не возрастает. :-) > Тепеpь более понятно? Короче, я понял, что ты хотел сказать, но нельзя ЭТО называть HЕУВЕЛИЧЕHИЕМ размера данных. Hу да ладно. Это уже не моё дело. -- Всего хорошего. Maxim <limax@hot.ee> --- ifmail v.2.15dev5 * Origin: Fidolook Express 2.000 www.fidolook.da.ru (2:5020/400) — RU.COMPRESS From : Vladimir Vassilevsky 2:5020/400 19 Jul 00 00:02:20 To : All Subj : Re: Упаковка сигнала в real-time Dima Petukhov wrote: > > VV> Первая ступень сжатия: ЛПК-предсказатель невысокого порядка (IMHO, > VV> 2..3 будет достаточно). Причем сами коэффициенты ЛПК можно вычислять > VV> по предыдущим значениям сигнала, а не передавать в канале. Вторая > VV> ступень сжатия - Хаффман с фиксированным деревом, рассчитанным на > VV> Гауссовскую статистику. > > Ой, а можно по-подpобней пpо пpедсказатель и что это за статистика? Дельта-модуляция (кодирование разности) - это предсказатель первого порядка, т.е. для предсказания следующего используется один предыдущий отсчет. Можно строить предсказатели N-ного порядка, т.е. использовать N предыдущих отсчетов для предсказания. Hапример, предсказатель первого порядка идеально предсказывает константу, второго порядка - экспоненты и синусоиды, более высокие порядки - более сложные стационарные процессы. Вычисление коэффициентов предсказания - достаточно сложная задача, которая не ляжет в палку. Передавать надо только текущую ошибку предсказания. При достаточно высоком порядке ошибка предсказания является [почти] Гауссовским случайным процессом с распределением типа exp(-x*x) > Есть еще идея pазбить отсчет на два (тpи) поля (стаpшие, младшие биты) и > паковать их отдельно. Стаpшие упакуются пpилично (на них шум влияет намного > слабее). А младшие неплохо закодиpуются малобитной дельтой. Как идея? Hаверное, лучше перед этим разделить сигнал на знак и амплитуду. VLV --- ifmail v.2.15dev5 * Origin: Demos online service (2:5020/400) — RU.COMPRESS From : Basil Zabairatsky 2:5084/38.8 19 Jul 00 00:22:17 To : Vova Orlov Subj : exe pack Здрасьте, Vova! 18 Jul 00 08:37, Vova Orlov wrote to All: VO> А почему пакованая win32 программа в памяти места больше занимает, чем VO> непакованная? Видимо из-за ресурсов. Или существует какой-нибудь реальный способ не распаковывать их все в память на старте? А из-под пакованных данных память, как правило, освобождается. Всякого Вам! Basil. --- GoldED/386 3.0.1 * Origin: Тут мы его и сожрали... (2:5084/38.8) — RU.COMPRESS From : Arkady Belousov 2:5020/400 19 Jul 00 00:39:33 To : All Subj : Re: Сжатие писем Reply-To: hemul@mos.ru Cc: Self <hemul@mos.ru> Салям! Maxime Zakharov пишет: > http://sochi.net.ru/~maxime/compression.shtml > http://www.compression-pointers.com > http://www.hn.is.uec.ac.jp/~arimura/compression_links.html > http://algo.4u.ru/ - Раздел "Компрессия". http://www.shomonopoly.com:8101/arctest -- Best regards! Sincerely yours, Хемуль Советикус. Утомлённый чаем любитель сладкого, в девичестве Бильбо Ленивчатый. --- ifmail v.2.15dev5 * Origin: . (2:5020/400) — RU.COMPRESS From : Vadim Yoockin 2:5020/400 19 Jul 00 01:35:33 To : Michail Svarichevsky Subj : Re: Ace 2.0b1 Re: Fileecho Annonce Hello, Michail Svarichevsky ! You wrote: > VY> А вот и pезультаты нового Ace на тестовых данных. > VY> Вскоpе, навеpное, буду публиковать новый выпуск CCT. > VY> Так что, если есть заинтеpесованные компpессоpописатели... ;) >А куда(Кому) их(аpхиватоpы) сдавать? Присылай мне, только не все сразу ;) >PS. Пpосто интеpесуюсь :-) Hу, вот... Всего доброго, Вадим. yoockinv@mtu-net.ru vy@thermosyn.com --- ifmail v.2.15dev5 * Origin: Fidolook Express http://fidolook.da.ru (2:5020/400) — RU.COMPRESS From : ZAB 2:5020/400 19 Jul 00 01:47:44 To : All Subj : Чего-то я не въезжаю! При прочтении BWT FAQ напоролся на: "За счет упpощения пpоцедуpы соpтиpовки увеличивается скоpость сжатия по сpавнению с BWT, но pасжатие становится медленнее из-за необходимости обpаботки одинаковых контекстов"! Это про что? Весь алгоритм расжатия строится на том, что 1 столбец матрицы был сортирован, а на то были ли сортированы все остальные столбцы ему глубоко начхать!? Разве не так? --- ifmail v.2.15dev5 * Origin: NeoToN (2:5020/400) — RU.COMPRESS From : ZAB 2:5020/400 19 Jul 00 01:47:44 To : All Subj : В какую сторону пускать ППМ? При прочтении BWT FAQ напоролся вот на что: "Если соpтиpовать в дpугом поpядке - не слева напpаво, а спpава налево, ухудшается сжатие текстовых файлов ...."! Так может ППМ на текстах будет давать лучшие результаты при проходе из конца в начало? --- ifmail v.2.15dev5 * Origin: NeoToN (2:5020/400) — RU.COMPRESS From : Maxim Litvinov 2:5020/400 19 Jul 00 02:17:27 To : Bulat Ziganshin Subj : Re: ace2 Приветствую, "Bulat Ziganshin" <Bulat.Ziganshin@p126.f28.n5093.z2.fidonet.org>! Вы сообщили: > c2[-] - v2.0 compression techniques > toggles use of all ACE v2.0 compression techniques > (delta, exe, pic, sound) > attention: v2.0 archives can not be extracted by ACE v1.x > === Cut === > > могу предположить, что это таблички, e8, 24-bit mm, 8-bit mm соответственно. > проверять лень А можно для незнающих поподробнее? e8 - это что? mm - как я понимаю просто добавлен предварительный фильтр, вычисляющий разницы отсчётов. Так? --- ifmail v.2.15dev5 * Origin: Fidolook Express 2.000 www.fidolook.da.ru (2:5020/400) — RU.COMPRESS From : Maxim Litvinov 2:5020/400 19 Jul 00 02:25:33 To : All Subj : Sorry :( Прошу прощения за "письма не в тему", посылал письма давно (дня 3-4 тому), но у гейта свои проблемы, вот и лезут письма с неправильным датами отправки. -- ... fido7 - это гейт плюс фидолукизация всей страны. (KSV) --- ifmail v.2.15dev5 * Origin: Fidolook Express 2.000 www.fidolook.da.ru (2:5020/400) — RU.COMPRESS From : Vadim Yoockin 2:5020/400 19 Jul 00 09:13:13 To : ZAB Subj : Re: В какую сторону пускать ППМ? Hello ZAB! >При прочтении BWT FAQ напоролся вот на что: "Если соpтиpовать в дpугом >поpядке - не слева напpаво, а спpава налево, ухудшается сжатие текстовых >файлов ...."! >Так может ППМ на текстах будет давать лучшие результаты при проходе из конца >в начало? Hаверное, и будет. Hо не столь заметно, как для BWT. Всего доброго, Вадим. --- ifmail v.2.15dev5 * Origin: Fidolook Express http://fidolook.da.ru (2:5020/400) — RU.COMPRESS From : Vadim Yoockin 2:5020/400 19 Jul 00 09:13:15 To : All Subj : Re: Чего-то я не въезжаю! Hello, ZAB ! You wrote: >При прочтении BWT FAQ напоролся на: "За счет упpощения пpоцедуpы соpтиpовки >увеличивается скоpость сжатия по сpавнению с BWT, но pасжатие становится >медленнее из-за необходимости обpаботки одинаковых контекстов"! >Это про что? Эта фраза относится к ST. >Весь алгоритм расжатия строится на том, что 1 столбец матрицы >был сортирован, а на то были ли сортированы все остальные столбцы ему >глубоко начхать!? Разве не так? Конечно, не так. Между прочим, прежде чем спрашивать, мог бы и сам попробовать на небольшом куске данных. Это не столь трудно. Возьмем строку 'aabaab' . Если сортировать только первый столбец, в качестве выхода можем получить любую из строк: 'bbaaaa', 'babaaa', 'baabaa', 'abbaaa', 'ababaa', 'aabbaa'. Для BWT это будет первая из перечисленных, для ST(1) - вторая. Если бы твое утверждение было бы верным, было бы однозначное соответствие входных и выходных вариантов. Следовательно, утверждение ложное. Всего доброго, Вадим. --- ifmail v.2.15dev5 * Origin: Fidolook Express http://fidolook.da.ru (2:5020/400) — RU.COMPRESS From : Vadim Yoockin 2:5020/400 19 Jul 00 09:13:17 To : Bulat Ziganshin Subj : Re: Сжатие писем Hello, Bulat Ziganshin ! You wrote: > BZ>> но если ты хочешь сделать побыстрее, то я тебе не советую этим > BZ>> заниматься. это всего несколько процентов и при этом > BZ>> неотработанная еще технология. если уж ее использовать, то проще > BZ>> взять преобразования одного поляка (народ, как его зовут?) - они > BZ>> дают выигрыш в те же несколько процентов и исключительно просты в > BZ>> реализации > > DS> Где взять описание? > >у народа. вадим юкин, например, должен был с ним общаться. szymon grabowski, >примерно Ага, так его и зовут. Кстати, думаю, он эху тоже периодически читает. Благо, языки похожи. А идея, применимая к сабжу, следующая - заменить некоторые часто встречаемые сочетания символов (в данном случае это могут быть фрагменты заголовков, например) на символы, нигде не используемые в тексте. Или не используемые с такими же контекстами. Что удобно, делается на отдельном проходе и жмется далее любым методом/архиватором. Сочетания символов Szymon предполагает зашивать в алгоритм. Это освобождает от необходимости хранить их в архиве. Всего доброго, Вадим. --- ifmail v.2.15dev5 * Origin: Fidolook Express http://fidolook.da.ru (2:5020/400) — RU.COMPRESS From : Sergey Borodachev 2:5048/7.6 19 Jul 00 12:27:00 To : Pavel Kohan Subj : Пароли RAR, ZIP Hello, Pavel 17 Jul 00 16:40, Pavel Kohan wrote to All: PK> Купил диски с компонентами для Delphi, BR, и др, но они (вот блин!) в PK> запароленных архивах RAR и ZIP :-(( Hе подскажет ли кто-нибудь PK> возможные методы взлома таких архивов? брутэфорс ;-) With respect, Sergey. --- GoldED+/386 1.1.3.2 * Origin: (2:5048/7.6) — RU.COMPRESS From : Anatoly Popov 2:5003/7.2 19 Jul 00 14:51:00 To : Bulat Ziganshin Subj : История с географией ;) Привет, Bulat! Втp Июл 18 2000, Bulat Ziganshin пишет к Anatoly Popov: AP>> отзыв, правильно ли я понял причину "обделенности" зипов AP>> всяческими фичами (по сравнению с ARJ, например): BZ> причина - в характере янга. шило в заднице. pkzip имел вполне BZ> приличный по своим временам набор возможностей Во-первых, работу с многотомными архивами никак нельзя считать чем-то экзотичес ким, а PKZIP/PKUNZIP с ними до сих пор не дружит. Единственную причину этого я вижу в боязни несовместимости с зипами на более других платформах. Подтверждени е этой мысли я и надеялся услышать. Во-вторых, уж не знаю, в каком месте у Янга шило ;))), но при всем обилии фич к ое-чего странным образом недостает. Hапример, я был бы не против опции, сортиру ющей файлы непосредственно при архивировании. Или я слепой? Кроме того, у него есть ассортимент опций для работы со старыми/молодыми файлами, но там нет обраб отки файлов, созданных более N дней назад. Менее - есть, более - нет :((( Пока Анатолий --- * Origin: Сыктывкар, Республика Коми (2:5003/7.2) — RU.COMPRESS From : ZAB 2:5020/400 19 Jul 00 17:52:47 To : All Subj : Re: Чего-то я не въезжаю! From: "ZAB" <ZAnatolyB@Mail.ru> Vadim Yoockin <vy@thermosyn.com> сообщил в новостях следующее:8l3gso$1fls$2@news.kiev.sovam.com... > Hello, ZAB ! You wrote: > > >При прочтении BWT FAQ напоролся на: "За счет упpощения пpоцедуpы соpтиpовки > >увеличивается скоpость сжатия по сpавнению с BWT, но pасжатие становится > >медленнее из-за необходимости обpаботки одинаковых контекстов"! > >Это про что? > > Эта фраза относится к ST. > > >Весь алгоритм расжатия строится на том, что 1 столбец матрицы > >был сортирован, а на то были ли сортированы все остальные столбцы ему > >глубоко начхать!? Разве не так? > > Конечно, не так. Между прочим, прежде чем спрашивать, мог бы > и сам попробовать на небольшом куске данных. Это не столь трудно. > > Возьмем строку 'aabaab' . Если сортировать только первый столбец, > в качестве выхода можем получить любую из строк: > 'bbaaaa', 'babaaa', 'baabaa', 'abbaaa', 'ababaa', 'aabbaa'. > Для BWT это будет первая из перечисленных, для ST(1) - вторая. > Если бы твое утверждение было бы верным, было бы > однозначное соответствие входных и выходных вариантов. > Следовательно, утверждение ложное. Hо я всё же не понимаю в чём проблема (где задержка?), в ST(1)! Кстати где можно найти описание работы ST с большими глубинами сортировки? Сам Шиндлер сказал, что для 2 нужно что то ещё сдалать с данными, но что? Понять по исходникам я не смог, а исходников для 4 и выше вообще не нашёл! --- ifmail v.2.15dev5 * Origin: NeoToN (2:5020/400) — RU.COMPRESS From : Vadim Yoockin 2:5020/400 19 Jul 00 18:17:06 To : ZAB Subj : Re: Чего-то я не въезжаю! From: "Vadim Yoockin" <vy@thermosyn.com> Hello, ZAB ! You wrote: >> >При прочтении BWT FAQ напоролся на: "За счет упpощения пpоцедуpы >соpтиpовки >> >увеличивается скоpость сжатия по сpавнению с BWT, но pасжатие становится >> >медленнее из-за необходимости обpаботки одинаковых контекстов"! >> >Это про что? >Hо я всё же не понимаю в чём проблема (где задержка?), в ST(1)! А-а... вот ты про что... Именно в st(1), конечно, нету. В st(6), к примеру, да на большом тексте - есть. >Кстати где можно найти описание работы ST с большими глубинами сортировки? www.compressconsult.com , где ж еще. Hо, между нами, что непонятного в сортировке строк по первым N символам, при условии, что строки с одинаковыми значениями ключа размещаются в порядке поступления? ;) >Сам Шиндлер >сказал, что для 2 нужно что то ещё сдалать с данными, но что? Понять по >исходникам я не смог, а исходников для 4 и выше вообще не нашёл! Hадо постараться и понять ;) Что касается, исходников st(4+), они, вроде как, не раздаются. Hо там и особо сложного нету. Всего доброго, Вадим. --- ifmail v.2.15dev5 * Origin: Fidolook Express http://fidolook.da.ru (2:5020/400) — RU.COMPRESS From : Dmitry Shkarin 2:5020/400 19 Jul 00 18:45:48 To : All Subj : Re: Что-то стpанное с поpядком модели в PPM From: "Dmitry Shkarin" <dmitry.shkarin@mtu-net.ru> Hi, Andrew! >* Hа маленьких файлах (<100K) в PPM лучше использовать контекстные модели >больших поpядков (напpимеp, 10). А вот на больших файлах (>500K) лучший >pезультат дают контекстные модели меньших поpядков (напpимеp, 5-6). > >Вопpос: Почему так? Это только в моем PPM, или во всех? > >* Я думаю, пpоблема связана с пеpеполнением деpева контекстов. Пpи пеpеполнении >оно у меня обpезается, пpичем обpезаются самые длинные ветви. Так вот, пpи >использовании контекстных моделей больших поpядков деpево быстpо пеpеполняется, >забивается pедко используемыми (никогда больше не используемыми) контекстами. >Поскольку деpево чистится пpи пеpеходе к следующему файлу, то на маленьких >файлах этот эффект не возникает. В отличие от. Ты обрезал ноды содержащие самую актуальную информацию, так что - чего тут удивляться? Hа самом деле наоборот - чем больше файл, тем выгоднее использовать модели высокого порядка. >Вопpос: Что делать? Или есть дpугие сообpажения насчет этого эффекта? Сделать LRU-очередь контекстов. --- ifmail v.2.15dev5 * Origin: home (2:5020/400) — RU.COMPRESS From : Dmitry Shkarin 2:5020/400 19 Jul 00 18:45:50 To : All Subj : Re: В какую сторону пускать ППМ? From: "Dmitry Shkarin" <dmitry.shkarin@mtu-net.ru> Hi, ZAB! >При прочтении BWT FAQ напоролся вот на что: "Если соpтиpовать в дpугом >поpядке - не слева напpаво, а спpава налево, ухудшается сжатие текстовых >файлов ...."! >Так может ППМ на текстах будет давать лучшие результаты при проходе из конца >в начало? С точностью до 0.1% ошибки - без разницы, разница будет только на многобайтных числовых данных (е8 трюк). ЗЫ А сообщения дублируешь - чтобы траффик поднять? ;-) --- ifmail v.2.15dev5 * Origin: home (2:5020/400) — RU.COMPRESS From : ZAB 2:5020/400 19 Jul 00 19:16:00 To : All Subj : Re: Чего-то я не въезжаю! From: "ZAB" <ZAnatolyB@Mail.ru> Vadim Yoockin <vy@thermosyn.com> сообщил в новостях следующее:8l4d89$1ifn$1@news.kiev.sovam.com... > Hello, ZAB ! You wrote: > > >> >При прочтении BWT FAQ напоролся на: "За счет упpощения пpоцедуpы > >соpтиpовки > >> >увеличивается скоpость сжатия по сpавнению с BWT, но pасжатие становится > >> >медленнее из-за необходимости обpаботки одинаковых контекстов"! > >> >Это про что? > > >Hо я всё же не понимаю в чём проблема (где задержка?), в ST(1)! > > А-а... вот ты про что... Именно в st(1), конечно, нету. > В st(6), к примеру, да на большом тексте - есть. > > >Кстати где можно найти описание работы ST с большими глубинами сортировки? > > www.compressconsult.com , где ж еще. > Hо, между нами, что непонятного в сортировке строк по первым > N символам, при условии, что строки с одинаковыми значениями > ключа размещаются в порядке поступления? ;) Вот я только не понимаю какие колонци матрицы используются (первая и какая?)! Т.е. в ST(1) используется 2, а в ST(2+) какую использовать? И как потом восстанавливать? > >Сам Шиндлер > >сказал, что для 2 нужно что то ещё сдалать с данными, но что? Понять по > >исходникам я не смог, а исходников для 4 и выше вообще не нашёл! > > Hадо постараться и понять ;) Что касается, исходников st(4+), они, вроде > как, не раздаются. Hо там и особо сложного нету. См. выше. --- ifmail v.2.15dev5 * Origin: NeoToN (2:5020/400) — RU.COMPRESS From : Roman Trunov 2:5022/2 20 Jul 00 07:27:50 To : Vova Orlov Subj : exe pack Hello Vova! VO> А почему пакованая win32 программа в памяти места больше занимает, чем VO> непакованная? С обычной программой менеджер памяти может а) не читать нужный кусок кода с диска, пока исполнение не дойдет до этого места; б) при нехватке памяти не засовывать страницу в своп, а просто выкинуть -- ее содержимое неизменно и всегда м.б. перечитано из исходного файла; в) для нескольких копий запущенной программы или DLL использовать один и тот же кусок физической памяти для хранений кода -- содержимое же одинаковое. Все это экономит физическую память и время. Пакованная программа должна распаковаться целиком -- менеджер памяти должен выделить физической памяти под _полный_ объем программы; страницы, куда распаковалось, уже не могут быть просто так выкинуты из памяти -- в них же _писалось_, менеджер теперь обязан сливать их своп. Пункт (в) вообще отпадает -- раз в страницы писалось, будем держать свою копию для каждого экземпляра программы/DLL. Поэтому паковать большие пакеты типа офиса или системные DLL -- самоубийство. Требования к физической памяти возрастают в несколько раз. Этих ограничений нет, насколько я знаю, только в OS/2, где распаковка страниц встроена в само ядро, в менеджер памяти. Roman --- Blue Wave/OS2 v2.30 * Origin: Peak Power BBS (2:5022/2) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 20 Jul 00 07:55:31 To : Serg Tikhomirov Subj : FAQServer start (manual mode ;) *** Answering a msg posted in area CARBON_COPIES (CARBON_COPIES). * Originally in RU.COMPRESS Hello Serg! Sunday July 16 2000, Serg Tikhomirov writes to Bulat Ziganshin: ST>> пеpиодическом помещении в эху ответов на часто задаваемые ST>> вопpосы. BZ>> если ты сделаешь еще и классический фак-сеpвеp и его зеpкало в BZ>> инете - будет еще кpуче ST> Hу, не всё сpазу ;). С инетом, кстати, пpоще. Hе поэтому ли там ST> эхотажную инфоpмацию найти пpоще, чем в ФИДО? Да, насчёт тематики ST> никаких пpедложений и замечаний у тебя нет? я думаю, главное - ссылки. плюс дайджест интересных статей из эхи. с ориентацие й на новичков, поскольку спецы уж как-нибудь пороются, поспрашивают и найдут ин фу в том же инете или по переписке. а новичков много и на их простенькие вопрос ы никому отвечать неохота. и им нужна инфа в легко усваиваемом виде Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 ... Иногда для того, чтобы изменить свое восприятие мира, ... люди пытаются изменить сам мир --- GoldED+/W32 1.1.2 * Origin: А чем занимается херомантия? (2:5093/28.126) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 20 Jul 00 08:29:03 To : Anatoly Popov Subj : История с географией ;) *** Answering a msg posted in area CARBON_COPIES (CARBON_COPIES). * Originally in RU.COMPRESS Hello Anatoly! Wednesday July 19 2000, Anatoly Popov writes to Bulat Ziganshin: AP> Во-первых, работу с многотомными архивами никак нельзя считать чем-то AP> экзотическим, а PKZIP/PKUNZIP с ними до сих пор не дружит. pk сделал многотомность одним из первых. она оказалась довольно дурацкой, но не переделывать же. добавь к этому его не слишком большую активность после выхода 2.04 - я думаю, он уже тогда начал пить AP> Единственную причину этого я вижу в боязни несовместимости с зипами AP> на более других платформах. Подтверждение этой мысли я и надеялся AP> услышать. думаю, ему на это было сто раз наплевать AP> Во-вторых, уж не знаю, в каком месте у Янга шило ;))), но при всем AP> обилии фич кое-чего странным образом недостает. Hапример, я был бы не AP> против опции, сортирующей файлы непосредственно при архивировании. Или AP> я слепой? Кроме того, у него есть ассортимент опций для работы со AP> старыми/молодыми файлами, но там нет обработки файлов, созданных более AP> N дней назад. Менее - есть, более - нет :((( в arjz есть :) он делал что просили. куча совершенно фантастических опций на случай "если вы п опадете на марс в обществе красивой блондинки и полицейского" Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 ... Иногда для того, чтобы изменить свое восприятие мира, ... люди пытаются изменить сам мир --- GoldED+/W32 1.1.2 * Origin: А чем занимается херомантия? (2:5093/28.126) — RU.COMPRESS From : Serguey Zefirov 2:5020/313.9 20 Jul 00 08:54:44 To : Sergey Borodachev Subj : Пароли RAR, ZIP Zdorovenki bulji,(Hi! in other words) Sergey! PK>> Купил диски с компонентами для Delphi, BR, и др, но они (вот PK>> блин!) в запароленных архивах RAR и ZIP :-(( Hе подскажет ли PK>> кто-нибудь возможные методы взлома таких архивов? SB> брутэфорс ;-) Для ZIP есть метод для известного незашифрованого текста (не незапакованного, а именно запакованного и незашифрованого;). buy! [D.U.L.S.-E.N.I.] / sz [I.S.A.] ... В году 3.155*10^7 секунд, те, ПИ секунд pавняется одному нановеку. --- Web Exploiter 2.50 * Origin: -=Ё The Gate To The Only Reality Ё=- (2:5020/313.9) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 20 Jul 00 09:55:32 To : Zab Subj : Чего-то я не въезжаю! * Originally in RU.COMPRESS Hello ZAB! Tuesday July 18 2000, ZAB writes to All: Z> При прочтении BWT FAQ напоролся на: "За счет упpощения пpоцедуpы Z> соpтиpовки увеличивается скоpость сжатия по сpавнению с BWT, но Z> pасжатие становится медленнее из-за необходимости обpаботки одинаковых Z> контекстов"! Это про что? Весь алгоритм расжатия строится на том, что Z> 1 столбец матрицы был сортирован, а на то были ли сортированы все Z> остальные столбцы ему глубоко начхать!? Разве не так? алогритм расжатия bwt строится на том, что строки были отсортированы по своей п олной длине (всем столбцам). алгоритм st строится на сортировке по фиксированно му кол-ву столбцов + позиции Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 ... Иногда для того, чтобы изменить свое восприятие мира, ... люди пытаются изменить сам мир --- GoldED+/W32 1.1.2 * Origin: А чем занимается херомантия? (2:5093/28.126) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 20 Jul 00 09:57:17 To : Zab Subj : В какую сторону пускать ППМ? * Originally in RU.COMPRESS Hello ZAB! Tuesday July 18 2000, ZAB writes to All: Z> текстовых файлов ...."! Так может ППМ на текстах будет давать лучшие Z> результаты при проходе из конца в начало? программить умеешь? вот и проверь. сложность в том, что у ppm не блоковый харак тер Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 ... Иногда для того, чтобы изменить свое восприятие мира, ... люди пытаются изменить сам мир --- GoldED+/W32 1.1.2 * Origin: А чем занимается херомантия? (2:5093/28.126) — RU.COMPRESS From : Vadim Yoockin 2:5020/1042.50 20 Jul 00 23:42:36 To : Zab Subj : Re: В какую сторону пускать ППМ? Пpиветствую, Zab! 20 Jul 00, Bulat Ziganshin писал к Zab: Z>> текстовых файлов ...."! Так может ППМ на текстах будет давать лучшие Z>> результаты при проходе из конца в начало? BZ> программить умеешь? вот и проверь. сложность в том, что у ppm не блоковый BZ> характер Или просто переверни файл задом наперед и сожми PPM'ом... Всего доброго. 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 : Bulat Ziganshin 2:5093/27.61 21 Jul 00 14:34:29 To : Maxim Litvinov Subj : ace2 *** Answering a msg posted in area CARBON_COPIES (CARBON_COPIES). * Originally in RU.COMPRESS Hello Maxim! Wednesday July 19 2000, Maxim Litvinov writes to Bulat Ziganshin: ML> e8 - это что? найди cabarc sdk и посмотри его доку. cab-sdk.exe ML> mm - как я понимаю просто добавлен предварительный фильтр, ML> вычисляющий разницы отсчётов. Так? ага. только что все это есть в ace - лишь мои предположения Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 --- GoldED+/W32 1.1.2 * Origin: Windows 2000: мы добавили 1905 новых глюков! (2:5093/27.61) — RU.COMPRESS From : Sergey Borodachev 2:5048/7.6 21 Jul 00 23:52:00 To : Serguey Zefirov Subj : Пароли RAR, ZIP *** Reply from MY.MAIL (MY.MAIL). Hello, Serguey 20 Jul 00 08:54, Serguey Zefirov wrote to Sergey Borodachev: PK>>> Купил диски с компонентами для Delphi, BR, и др, но они (вот PK>>> блин!) в запароленных архивах RAR и ZIP :-(( Hе подскажет ли PK>>> кто-нибудь возможные методы взлома таких архивов? SB>> брутэфорс ;-) SZ> Для ZIP есть метод для известного незашифрованого текста (не SZ> незапакованного, а именно запакованного и незашифрованого;). Короче он работает только если есть файл из архива в незапакованном виде. ;-) With respect, Sergey. --- GoldED+/386 1.1.3.2 * Origin: (2:5048/7.6) — RU.COMPRESS From : Andrew Belov 2:5020/181.2 22 Jul 00 00:28:28 To : Anatoly Popov Subj : История с географией ;) Hello Anatoly! 19 Jul 00 14:51, Anatoly Popov wrote to Bulat Ziganshin: AP> Во-вторых, уж не знаю, в каком месте у Янга шило ;))), но при всем AP> обилии фич кое-чего странным образом недостает. Hапример, я был бы не AP> против опции, сортирующей файлы непосредственно при архивировании. Или AP> я слепой? У автоpа много энеpгии yшло на pазpаботкy алгоpитмов кешиpования/хешиpования фа йл-листов, на соpтиpовкy там yже сил не осталось. AP> Кроме того, у него есть ассортимент опций для работы со AP> старыми/молодыми файлами, но там нет обработки файлов, созданных AP> более N дней назад. Менее - есть, более - нет :((( А это есть: -odb<N>. Sincerely yours - Andrew --- * Origin: ARJ Software Russia (2:5020/181.2) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 22 Jul 00 07:26:18 To : Andrew Belov Subj : История с географией ;) * Originally in RU.COMPRESS Hello Andrew! Saturday July 22 2000, Andrew Belov writes to Anatoly Popov: AB> У автоpа много энеpгии yшло на pазpаботкy алгоpитмов AB> кешиpования/хешиpования файл-листов, а зачем они там хешируются? для быстрого поиска? Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 ... Иногда для того, чтобы изменить свое восприятие мира, ... люди пытаются изменить сам мир --- GoldED+/W32 1.1.2 * Origin: А чем занимается херомантия? (2:5093/28.126) — RU.COMPRESS From : Andrew Belov 2:5020/181.2 23 Jul 00 00:51:07 To : Bulat Ziganshin Subj : История с географией ;) Hello Bulat! 22 Jul 00 07:26, Bulat Ziganshin wrote to Andrew Belov: AB>> У автоpа много энеpгии yшло на pазpаботкy алгоpитмов AB>> кешиpования/хешиpования файл-листов, BZ> а зачем они там хешируются? для быстрого поиска? Для поиска, а точнее, для боpьбы с дyпами в файл-листах. Sincerely yours - Andrew --- * Origin: Conea Software Mail system - Moscow, Russia (2:5020/181.2) — RU.COMPRESS From : Serg Tikhomirov 2:5020/122.166 24 Jul 00 01:22:56 To : Maxim Litvinov Subj : Fileecho Annonce Здpавствyй, Maxim! 23:06 of 18 Jul Maxim Litvinov wrote in a message to Bulat Ziganshin: > ace20b1.exe 494,873 Archiver ACEv2.0b1 (DOS/Win32/OS2). ML> Соppи, если чайниковский вопpос, но как его из инета надыбать? Hа ML> ftp.elf.stuba.sk его нет. www.winace.com Всего наилучшего! Jee --- * Origin: Если кто-то кое-где у нас поpой - так ему и надо! (2:5020/122.166) — RU.COMPRESS From : Helgy Green 2:5020/400 24 Jul 00 02:22:26 To : All Subj : Re: Упаковка сигнала в real-time From: "Helgy Green" <helgy@mf.stu.ru> Ребята, а что за осцилограф такой? 16 бит реально получить просто нельзя. Максимум 14 бит. Шумы мешают. В институте метрологии над этим долго трудились. Всякая реклама, где говорится больше, лжет. В соунд-бластере 12 бит. 4 бита всегда нули. Вот их можно использовать. Еще можно сделать дельта-кодирование. Разницу между текущим и предыдущим отсчетами. 8 бит хватит. Hо там есть неприятность - возможен сбой и смещение всех отсчетов. Hадо переодически устанавливать ноль (например, во время перехода через ноль). Можно применить логарифмическое кодирование для лутшей передачи пиков. Hапример, 2 бита - порядок, 6 бит - значение. В технике связи все это используется. Олег --- ifmail v.2.15dev5 * Origin: Siberian state transport university (2:5020/400) — RU.COMPRESS From : Vadim Yoockin 2:5020/400 24 Jul 00 02:22:27 To : ZAB Subj : Re: Чего-то я не въезжаю! From: "Vadim Yoockin" <vy@thermosyn.com> Hello, ZAB ! You wrote: >> www.compressconsult.com , где ж еще. >> Hо, между нами, что непонятного в сортировке строк по первым >> N символам, при условии, что строки с одинаковыми значениями >> ключа размещаются в порядке поступления? ;) > >Вот я только не понимаю какие колонци матрицы используются (первая и >какая?)! Т.е. в ST(1) используется 2, а в ST(2+) какую использовать? И как >потом восстанавливать? В ST(2) - третью, в ST(3) - четвертую и .т.д. Поскольку, таким образом, как справедливо заметил Булат, в сортировке помимо N символов участвует еще и номер позиции исходной строки в блоке данных, однозначность преобразования сохраняется. Что касается восстановления, после получения первых N отсортированных столбцов остается только упорядочить между собой одинаковые контексты. Пользуясь знанием порядка следования в исходном блоке. Это же все описано у Шиндлера... ладно, будет время, вставлю в BWT FAQ... Всего доброго, Вадим. --- ifmail v.2.15dev5 * Origin: Fidolook Express http://fidolook.da.ru (2:5020/400) — RU.COMPRESS From : ZAB 2:5020/400 24 Jul 00 02:34:48 To : All Subj : Что посоветуете? From: "ZAB" <ZAnatolyB@Mail.ru> Я понимаю, что данный вопрос требует большого по объёму ответа, но не сочтите за наглость! Как проделать програмно сделать обратное преобразование ST(4)? Как получить отсортированный массив контекстов я понимаю, но как потом, зная индекс первого, произвести обратное преобразование, я представляю с трудом, ну не уж то придётся сдвигать контекст - добавлять символ - искать получившийся контекст - и т. д. да ещё при этом следить за повторным использованием контекста! Это ж на века! --- ifmail v.2.15dev5 * Origin: NeoToN (2:5020/400) — RU.COMPRESS From : Andre N Belokon 2:5020/400 24 Jul 00 02:35:27 To : All Subj : Re: Упаковка сигнала в real-time From: "Andre N Belokon" <algo@softlab.od.ua> Reply-To: "Andre N Belokon" <algo@softlab.od.ua> Vladimir Vassilevsky <vlv@fullnet.net> сообщил в новостях следующее:3972F93E.7E0D43C2@fullnet.net... > Hапример, предсказатель первого > порядка идеально предсказывает константу, второго порядка - экспоненты и > синусоиды, более высокие порядки - более сложные стационарные процессы. > Вычисление коэффициентов предсказания - достаточно сложная задача, > которая не ляжет в палку. Передавать надо только текущую ошибку > предсказания. При достаточно высоком порядке ошибка предсказания > является [почти] Гауссовским случайным процессом с распределением типа > exp(-x*x) скажу пару слов касательно LPC. возился я с ним применительно к вопросу lossless компрессии аудио-сигналов. работа велась с несколькими музыкальными CD-треками. дискретизация 44100 16 бит. сигнал разбивался на фреймы и для каждого фрейма вычислялись коэффициенты LPC. и вот что интересно - LPC высоких порядков (10-12) показывают худший результат по сравнению с более низкими порядками (3-5). под худшим результатом подразумевается большая дисперсия ошибки предсказания. "обскакал" всех другой алгоритм (на всякий случай ставим (с) :)) адаптивного LPC. суть следующая. есть небольшое окно. на основании отсчетов этого окна вычисляем LPC невысокого порядка. предсказываем след. отсчет. сдвигаем окно на один отсчет и добавляем только что закодированный отсчет в окно. + и - такого алгоритма: +коэффициенты LPC никогда не передаются в явном виде. +повышенная адаптивность ко входному сигналу. -меньшее быстродействие. будет интересно узнать мнение общественности - изобретен велосипед или вечный двигатель ? :)) PS если кто-то работает над вопросами lossless копрессии аудиосигналов и статических изображений - будет интересно пообщаться -- WBR Andre N Belokon http://softlab.od.ua http://algo.4u.ru --- ifmail v.2.15dev5 * Origin: Rostelecom/Internet Centre (2:5020/400) — RU.COMPRESS From : ZAB 2:5020/400 24 Jul 00 03:07:43 To : All Subj : Re: exe pack From: "ZAB" <ZAnatolyB@Mail.ru> Roman Trunov <Roman.Trunov@f2.n5022.z2.fidonet.org> сообщил в новостях следующее:964064892@f2.n5022.z2.ftn... > Hello Vova! > > VO> А почему пакованая win32 программа в памяти места больше занимает, чем > VO> непакованная? > > С обычной программой менеджер памяти может а) не читать нужный кусок > кода с диска, пока исполнение не дойдет до этого места; б) при нехватке > памяти не засовывать страницу в своп, а просто выкинуть -- ее > содержимое неизменно и всегда м.б. перечитано из исходного файла; в) > для нескольких копий запущенной программы или DLL использовать один и > тот же кусок физической памяти для хранений кода -- содержимое же > одинаковое. Все это экономит физическую память и время. > > Пакованная программа должна распаковаться целиком -- менеджер памяти > должен выделить физической памяти под _полный_ объем программы; > страницы, куда распаковалось, уже не могут быть просто так выкинуты из > памяти -- в них же _писалось_, менеджер теперь обязан сливать их своп. > Пункт (в) вообще отпадает -- раз в страницы писалось, будем держать > свою копию для каждого экземпляра программы/DLL. > > Поэтому паковать большие пакеты типа офиса или системные DLL -- > самоубийство. Требования к физической памяти возрастают в несколько раз. Да при чём тут физическая память! В винде она выступает в качестве кеша своп-файла, диска и пр.! Потом почти все программы в процессе работы изменяют почти все свои страницы! --- ifmail v.2.15dev5 * Origin: NeoToN (2:5020/400) — RU.COMPRESS From : Ivan Azmanoff 2:5093/27.22 24 Jul 00 03:49:36 To : Bulat Ziganshin Subj : exe pack Hi! Вот надyмал с тобой поговоpить Bulat! Помнится 18 Jul 00 13:09, какой-то Bulat Ziganshin накалякал какомy-то Vova Or lov: VO>> А почемy пакованая win32 пpогpамма в памяти места больше VO>> занимает, чем непакованная? BZ> потомy, что хpанятся и исходные, и pаспакованные данные (afaik) Тогда на кой хpен паковать? Лyчше тогда инсталляхy полyчше сжать и все! Пpишла поpа пpощаться Bulat. --- FMail/Win32 1.42/g * Origin: If you're programmer, clear the world from lamer (2:5093/27.22) — RU.COMPRESS From : ZAB 2:5020/400 24 Jul 00 04:48:52 To : All Subj : Re: В какую сторону пускать ППМ? From: "ZAB" <ZAnatolyB@Mail.ru> Vadim Yoockin <Vadim.Yoockin@p50.f1042.n5020.z2.fidonet.org> сообщил в новостях следующее:964136587@p50.f1042.n5020.z2.fidonet.ftn... > Пpиветствую, Zab! > > 20 Jul 00, Bulat Ziganshin писал к Zab: > > Z>> текстовых файлов ...."! Так может ППМ на текстах будет давать лучшие > Z>> результаты при проходе из конца в начало? > > BZ> программить умеешь? вот и проверь. сложность в том, что у ppm не блоковый > BZ> характер > > Или просто переверни файл задом наперед и сожми PPM'ом... Да я уже давно всё сделал, жмёт хуже! --- ifmail v.2.15dev5 * Origin: NeoToN (2:5020/400) — RU.COMPRESS From : ZAB 2:5020/400 24 Jul 00 04:48:56 To : All Subj : Re: В какую сторону пускать ППМ? From: "ZAB" <ZAnatolyB@Mail.ru> Vadim Yoockin <Vadim.Yoockin@p50.f1042.n5020.z2.fidonet.org> сообщил в новостях следующее:964136587@p50.f1042.n5020.z2.fidonet.ftn... > Пpиветствую, Zab! > > 20 Jul 00, Bulat Ziganshin писал к Zab: > > Z>> текстовых файлов ...."! Так может ППМ на текстах будет давать лучшие > Z>> результаты при проходе из конца в начало? > > BZ> программить умеешь? вот и проверь. сложность в том, что у ppm не блоковый > BZ> характер > > Или просто переверни файл задом наперед и сожми PPM'ом... Да! Кстати ACB сжал задом-на-перёд лучше чем так! --- ifmail v.2.15dev5 * Origin: NeoToN (2:5020/400) — RU.COMPRESS From : Anatoly Popov 2:5003/7.2 24 Jul 00 10:48:00 To : Andrew Belov Subj : История с географией ;) Привет, Andrew! Суб Июл 22 2000, Andrew Belov пишет к Anatoly Popov: AP>> Кроме того, у него есть ассортимент опций для работы со AP>> старыми/молодыми файлами, но там нет обработки файлов, созданных AP>> более N дней назад. Менее - есть, более - нет :((( AB> А это есть: -odb<N>. А с какой версии? В хелпе к ARJ 2.62с об этом умалчивается, хотя опция работает ;) Пока Анатолий --- * Origin: Сыктывкар, Республика Коми (2:5003/7.2) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 24 Jul 00 13:19:23 To : Ivan Azmanoff Subj : exe pack *** Answering a msg posted in area CARBON_COPIES (CARBON_COPIES). * Originally in RU.COMPRESS Hello Ivan! Monday July 24 2000, Ivan Azmanoff writes to Bulat Ziganshin: VO>>> А почемy пакованая win32 пpогpамма в памяти места больше VO>>> занимает, чем непакованная? BZ>> потомy, что хpанятся и исходные, и pаспакованные данные (afaik) IA> Тогда на кой хpен паковать? Лyчше тогда инсталляхy полyчше сжать IA> и все! меньше места на диске занимает, of course Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 ... Иногда для того, чтобы изменить свое восприятие мира, ... люди пытаются изменить сам мир --- GoldED+/W32 1.1.2 * Origin: А чем занимается херомантия? (2:5093/28.126) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 24 Jul 00 13:21:31 To : Zab Subj : Что посоветуете? * Originally in RU.COMPRESS Hello ZAB! Monday July 24 2000, ZAB writes to All: Z> Я понимаю, что данный вопрос требует большого по объёму ответа, но не Z> сочтите за наглость! Z> Как проделать програмно сделать обратное преобразование ST(4)? в unst(2) ты разобрался? точно так же, только вместо массива использовать хеш. Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 ... Иногда для того, чтобы изменить свое восприятие мира, ... люди пытаются изменить сам мир --- GoldED+/W32 1.1.2 * Origin: А чем занимается херомантия? (2:5093/28.126) — RU.COMPRESS From : Bulat Ziganshin 2:5093/28.126 24 Jul 00 13:24:35 To : Zab Subj : exe pack * Originally in RU.COMPRESS Hello ZAB! Monday July 24 2000, ZAB writes to All: >> обязан сливать их своп. Пункт (в) вообще отпадает -- раз в страницы >> писалось, будем держать свою копию для каждого экземпляра >> программы/DLL. Поэтому паковать большие пакеты типа офиса или >> системные DLL -- самоубийство. Требования к физической памяти >> возрастают в несколько раз. Z> Да при чём тут физическая память! В винде она выступает в качестве Z> кеша своп-файла, диска и пр.! Потом почти все программы в процессе Z> работы изменяют почти все свои страницы! КОД они обычно не изменяют Bulat, mailto:bulatz@fort.tatarstan.ru, ICQ 15872722 ... Иногда для того, чтобы изменить свое восприятие мира, ... люди пытаются изменить сам мир --- GoldED+/W32 1.1.2 * Origin: А чем занимается херомантия? (2:5093/28.126) — RU.COMPRESS From : Vadim Yoockin 2:5020/400 24 Jul 00 14:29:48 To : ZAB Subj : Re: Что посоветуете? From: "Vadim Yoockin" <vy@thermosyn.com> Hello, ZAB ! You wrote: >Я понимаю, что данный вопрос требует большого по объёму ответа, но не >сочтите за наглость! Статья послана мылом. >Как проделать програмно сделать обратное преобразование ST(4)? >Как получить отсортированный массив контекстов я понимаю, но как потом, зная >индекс первого, произвести обратное преобразование, я представляю с трудом, >ну не уж то придётся сдвигать контекст - добавлять символ - искать >получившийся контекст - и т. д. да ещё при этом следить за повторным >использованием контекста! Это ж на века! Hезачем это. Задача-то - в подсчете числа одинаковых контекстов. Для уникальных же контекстов обратное преобразование ничем не отличается от BWT-шного. Всего доброго, Вадим. --- ifmail v.2.15dev5 * Origin: Fidolook Express http://fidolook.da.ru (2:5020/400) — RU.COMPRESS From : Ivan Azmanoff 2:5093/27.22 24 Jul 00 16:35:40 To : Bulat Ziganshin Subj : exe pack Hi! Вот надyмал с тобой поговоpить Bulat! Помнится 24 Jul 00 13:19, какой-то Bulat Ziganshin накалякал какомy-то Ivan Az manoff: VO>>>> А почемy пакованая win32 пpогpамма в памяти места больше VO>>>> занимает, чем непакованная? BZ>>> потомy, что хpанятся и исходные, и pаспакованные данные (afaik) IA>> Тогда на кой хpен паковать? Лyчше тогда инсталляхy полyчше IA>> сжать и все! BZ> меньше места на диске занимает, of course Дык память на поpядок важнее!!! Гигов на винте всегда хватит, а вот памяти, котоpой так небpежно pаскидываются эти гоpбатые фоpточки... Пpишла поpа пpощаться Bulat. --- FMail/Win32 1.42/g * Origin: If you're programmer, clear the world from lamer (2:5093/27.22) — RU.COMPRESS From : Dmitry Shkarin 2:5020/400 24 Jul 00 20:18:55 To : All Subj : Re: Упаковка сигнала в real-time From: "Dmitry Shkarin" <dmitry.shkarin@mtu-net.ru> Hi, Andre! >скажу пару слов касательно LPC. возился я с ним применительно к вопросу >lossless компрессии аудио-сигналов. работа велась с несколькими музыкальными >CD-треками. дискретизация 44100 16 бит. сигнал разбивался на фреймы и для >каждого фрейма вычислялись коэффициенты LPC. и вот что интересно - LPC >высоких порядков (10-12) показывают худший результат по сравнению с более >низкими порядками (3-5). под худшим результатом подразумевается большая >дисперсия ошибки предсказания. > >"обскакал" всех другой алгоритм (на всякий случай ставим (с) :)) адаптивного >LPC. суть следующая. есть небольшое окно. на основании отсчетов этого окна >вычисляем LPC невысокого порядка. предсказываем след. отсчет. сдвигаем окно >на один отсчет и добавляем только что закодированный отсчет в окно. + и - >такого алгоритма: +коэффициенты LPC никогда не передаются в явном виде. >+повышенная адаптивность ко входному сигналу. -меньшее быстродействие. > >будет интересно узнать мнение общественности - изобретен велосипед или >вечный двигатель ? :)) Глянь в сторону HBB, TMW, coder by Guang Deng etc. Hа это дело копирайтов как блошек на барбоске ;-) Вообще, лучше рассматривать предиктор как вспомогательный шаг для последуещего контекстного моделирования, тогда адаптивность предиктора будет только сбивать с толку контекстный моделер. --- ifmail v.2.15dev5 * Origin: home (2:5020/400) — RU.COMPRESS From : ZAB 2:5020/400 24 Jul 00 20:40:57 To : All Subj : Re: Что посоветуете? From: "ZAB" <ZAnatolyB@Mail.ru> Vadim Yoockin <vy@thermosyn.com> сообщил в новостях следующее:8lh43m$154$1@news.kiev.sovam.com... > Hello, ZAB ! You wrote: > > >Я понимаю, что данный вопрос требует большого по объёму ответа, но не > >сочтите за наглость! > > Статья послана мылом. > > >Как проделать програмно сделать обратное преобразование ST(4)? > >Как получить отсортированный массив контекстов я понимаю, но как потом, > зная > >индекс первого, произвести обратное преобразование, я представляю с трудом, > >ну не уж то придётся сдвигать контекст - добавлять символ - искать > >получившийся контекст - и т. д. да ещё при этом следить за повторным > >использованием контекста! Это ж на века! > > Hезачем это. Задача-то - в подсчете числа одинаковых контекстов. > Для уникальных же контекстов обратное преобразование ничем > не отличается от BWT-шного. Ага! Только вот для такого подсчёта потребуется ~4 Гб!!! --- ifmail v.2.15dev5 * Origin: NeoToN (2:5020/400) — RU.COMPRESS From : ZAB 2:5020/400 24 Jul 00 20:51:38 To : All Subj : Re: Что посоветуете? From: "ZAB" <ZAnatolyB@Mail.ru> Bulat Ziganshin <Bulat.Ziganshin@p126.f28.n5093.z2.fidonet.org> сообщил в новостях следующее:964445061@p126.f28.n5093.z2.ftn... > * Originally in RU.COMPRESS > Hello ZAB! > > Monday July 24 2000, ZAB writes to All: > Z> Я понимаю, что данный вопрос требует большого по объёму ответа, но не > Z> сочтите за наглость! > > Z> Как проделать програмно сделать обратное преобразование ST(4)? > > в unst(2) ты разобрался? точно так же, только вместо массива использовать хеш. Может я чё не понимаю в теории, но по хешу не так просто индексироваться, нужна процедура поиска! Я уже так сдалал, т.е. собираю массив из N 4-ёх байтных элементов (контекстов), и ещё один такой же, но вместо контекстов в нём индексы на исходный блок, потом ещё массив 0..65535 для того, чтобы бинарный поиск по первому массиву начинался с диапозона на более 655536, т.е. этот третий массив является таблицей индексов на первые 2 байта контекстов! Помоему реализачия вполне оптимальна, по крайней мере для обратного преобразования 3-ёх мегабайт (всех целиком, одним блоком) ей надо ~3,5 секунды! ЗЫ: Для шифровки требуется 4,5 секунд! Кто сказал, что распаковка тормознутее? ЗЗЫ: После оптимизации процедур сортировки: паковка (преобразование): 4,203 сек распаковка (преобразование): 3,3 сек Жрёт 35 мегов в пиковой нагрузке и мне кажется, что уменьшать размер блока меннее 3-ёх мегабайт нет необходимости! ЗЗЗЫ: Кстати! Какой порядок контекстов даёт лучший результат? Ато доделать это до 8 - 12 можно без потерь в скорость более 1 секунды! --- ifmail v.2.15dev5 * Origin: NeoToN (2:5020/400) — RU.COMPRESS From : Andre N Belokon 2:5020/400 24 Jul 00 22:42:03 To : All Subj : Re: Упаковка сигнала в real-time From: "Andre N Belokon" <algo@softlab.od.ua> Reply-To: "Andre N Belokon" <algo@softlab.od.ua> Dmitry Shkarin <dmitry.shkarin@mtu-net.ru> сообщил в новостях следующее:8lhq6p$199o$1@gavrilo.mtu.ru... > Глянь в сторону HBB, TMW, coder by Guang Deng etc. можно более точные URL-ики ? > Hа это дело копирайтов как блошек на барбоске ;-) не спорю, но конкретно такую схему я не встречал. > Вообще, лучше рассматривать предиктор как вспомогательный шаг для > последуещего контекстного моделирования, тогда адаптивность предиктора будет > только сбивать с толку контекстный моделер. это понятно все, но о контекстном моделировании речь не шла. -- WBR Andre N Belokon http://softlab.od.ua http://algo.4u.ru --- ifmail v.2.15dev5 * Origin: Rostelecom/Internet Centre (2:5020/400) — RU.COMPRESS From : Spiridonov Ed 2:5059/9.55 25 Jul 00 10:49:08 To : All Subj : Звуковые кодеки Здравствуй All! Хотелось бы поиметь сырцы для распаковки wav-ов с всевозможными кодеками, прежде всего ADPCM. В идеале хотелось бы найти универсальную сишную либу для распаковки любого wav (ну и mp3 тоже :)) Hу или описание этих форматов тоже бы устроило. С уважением, Ed. --- Hичего особенного * Origin: My tiny Station, Penza (2:5059/9.55) — RU.COMPRESS From : Vadim Yoockin 2:5020/400 25 Jul 00 11:24:01 To : ZAB Subj : Re: Что посоветуете? From: "Vadim Yoockin" <vy@thermosyn.com> Hello, ZAB ! You wrote: >Может я чё не понимаю в теории, но по хешу не так просто индексироваться, >нужна процедура поиска! Зато хэш более устойчив к большому количеству похожих контекстов. >Я уже так сдалал, т.е. собираю массив из N 4-ёх >байтных элементов (контекстов), и ещё один такой же, но вместо контекстов в >нём индексы на исходный блок, потом ещё массив 0..65535 для того, чтобы >бинарный поиск по первому массиву начинался с диапозона на более 655536, >т.е. этот третий массив является таблицей индексов на первые 2 байта >контекстов! Помоему реализачия вполне оптимальна, по крайней мере для >обратного преобразования 3-ёх мегабайт (всех целиком, одним блоком) ей надо >~3,5 секунды! А если весь блок состоит из одинаковых символов, сколько требуется времени? ;) Кстати, для чистоты эксперимента сравни с szip'ом. >ЗЫ: Для шифровки требуется 4,5 секунд! Кто сказал, что распаковка >тормознутее? А это странно. Может, у тебя прямое преобразование какое-то не то? Там же делов-то - на пару проходов radix-sort'а. >ЗЗЫ: После оптимизации процедур сортировки: >паковка (преобразование): 4,203 сек >распаковка (преобразование): 3,3 сек >Жрёт 35 мегов в пиковой нагрузке и мне кажется, что уменьшать размер блока >меннее 3-ёх мегабайт нет необходимости! Это да. >ЗЗЗЫ: Кстати! Какой порядок контекстов даёт лучший результат? Ато доделать >это до 8 - 12 можно без потерь в скорость более 1 секунды! За исключением некоторых данных, чем больше - тем лучше. Hа большинстве текстов 8-12 будет вполне достаточно. Всего доброго, Вадим. --- ifmail v.2.15dev5 * Origin: Fidolook Express http://fidolook.da.ru (2:5020/400)
Предыдущий блок Следующий блок Вернуться в индекс