[an error occurred while processing this directive][an error occurred while processing this directive][an error occurred while processing this directive]
— 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)
[an error occurred while processing this directive][an error occurred while processing this directive]