Ru-Board.club
← Вернуться в раздел «Программы»

» FreeArc (часть 4)

Автор: ndch
Дата сообщения: 12.04.2011 11:09
Bulat_Ziganshin

Цитата:
arc a a.zip -tzip

arc a a.zip -tzip
FreeArc 0.67 (March 18 2011) creating archive: a.zip
Compressing 2 files, 47,675 bytes. Processed 0%
c_szCompress: unsupported archive type
arc.EXE: szCheckedTABI: error
Автор: Bulat_Ziganshin
Дата сообщения: 12.04.2011 12:52
ndch
положи 7z.dll в каталог с arc.exe
Автор: Shuld
Дата сообщения: 26.01.2012 20:50
Я не знаю, что такое fazip.


Добавлено:
Он же не пишет на винт, а отправляет в nul?
Какое это отношение имеет к сжатию данных в реальных условиях?

Добавлено:
Загрузка CPU - это только часть процесса. И для быстрых методов не самая большая часть.

Добавлено:

Цитата:
ты даже не сообразил, что форумскую табличку можно оставить пустой, а затем редактировать как обычный текст

Так я делаю.
Но не получается взять целиком Excel-евскую или Word-овскую табличку и вставить. Только по одной ячейке. Застрелиться можно.
Автор: ndch
Дата сообщения: 12.04.2011 15:46
Bulat_Ziganshin

Цитата:
положи 7z.dll в каталог с arc.exe
положил
>arc a a.zip -tzip
FreeArc 0.67 (March 18 2011) creating archive: a.zip
Compressing 4 files, 183,314,706 bytes. Processed 0.0%
c_szCompress: unsupported archive type
arc.EXE: szCheckedTABI: error

Зачем 7z.dll отсутствует в дистрибутиве ?


Добавлено:
более того запускаю гуёвую версию:
libgdk-win32-2.0-0.dll not found

Это самое... хочется скачать дистрибутив, установить и пользоваться, а не бегать "из интернетов скачивать".
Кстати, что надо GLib,gdk-pixbuf или GTK+ ?

Будте любезны, сделайте "полный" дистрибутив.
Автор: slech
Дата сообщения: 26.01.2012 23:10

Цитата:
Но не получается взять целиком Excel-евскую или Word-овскую табличку и вставить. Только по одной ячейке. Застрелиться можно.

Может пригодится http://theenemy.dk/table/
Автор: namchik
Дата сообщения: 12.04.2011 17:01
если в установщике http://freearc.org/download/testing/FreeArc-0.67-alpha-win32.exe
Файл: FreeArc-0.67-alpha-win32.exe
CRC-32: 378ce0f1
MD4: 6bfccfbc0943884100e948d324f86bcb
MD5: ef3a17bd7eb683ead7117686d8335ee6
SHA-1: 47eb1271e7c6431c22a6ab0b03c13a3dac6e42f3

не установлена галка "ассоциировать с другими архивами", он все равно ассоциирует
Автор: Bulat_Ziganshin
Дата сообщения: 27.01.2012 01:02

Цитата:
Он же не пишет на винт, а отправляет в nul?
Какое это отношение имеет к сжатию данных в реальных условиях?  

а ты не думаешь, что на других машинах соотношение скорости диска и процессора может на порядок отличаться от твоего?
Автор: byExit
Дата сообщения: 12.04.2011 22:02
Bulat_Ziganshin
Скачал я precomp 0.4.1 и решил его совместить с FreeArc. Поскольку он не совместим с предыдущими версиями, я сделал следующее:
1. Создал в каталоге "bin" папку "precomp041" и поместил в неё прекомп (ексешка + дллки)
2. В arc.ini добавил:

Цитата:
[External compressor:precomp4]
mem = 2
packcmd = precomp041\precomp {options} -o$$arcpackedfile$$.tmp $$arcdatafile$$.tmp
unpackcmd = precomp041\precomp -o$$arcdatafile$$.tmp -r $$arcpackedfile$$.tmp

[External compressor:pprec4]
mem = 2
packcmd = precomp041\precomp {options} -o$$arcpackedfile$$.tmp -pdfbmp+ -progonly+ $$arcdatafile$$.tmp
unpackcmd = precomp041\precomp -o$$arcdatafile$$.tmp -r $$arcpackedfile$$.tmp

Всё работает, НО остаётся вопрос - как его описать правильнее?
У меня, как видно, precomp 0.4.1 назван precomp4.

-------------------------------------------------------------------
И ещё по поводу FreeArc.
Заметил небольшой баг в работе GTK Theme Selector. Темы не пред просматриваются, если текущая виндосовская учётка содержит символы кириллицы (тестил на XP SP3)

Автор: snkreg
Дата сообщения: 27.01.2012 01:31
Bulat_Ziganshin
Булат, добрый день. А Вы не планируете добавить Оценку Сжатия, как в HaoZIP и поддержку ASCII-комментов, как в WinRAR?

Добавлено:
Отлично я написал.."Добрый день" в 03:31))
Автор: Shuld
Дата сообщения: 27.01.2012 15:38
Bulat_Ziganshin

Цитата:
а ты не думаешь, что на других машинах соотношение скорости диска и процессора может на порядок отличаться от твоего?

Гипотетически - конечно, да!
То есть это для таких случаев, если они есть?
(для этого нужен какой-нибудь райд, но ведь и проц будет не моего уровня).


Добавлено:
А почему вообще такое происходит - на небольшом объеме данных tor:3 в разы превосходит по скорости, а на больших объемах чуть-чуть (на одном и том же компьютере)?
Что в принципе творится?

Добавлено:
slech

Спасибо, попробую.
Автор: Bulat_Ziganshin
Дата сообщения: 12.04.2011 23:27

Цитата:
Зачем 7z.dll отсутствует в дистрибутиве ?


Цитата:
более того запускаю гуёвую версию:
libgdk-win32-2.0-0.dll not found

сейчас переустановил с нуля - всё есть. что у тебя за дистрибут?


Цитата:
не установлена галка "ассоциировать с другими архивами", он все равно ассоциирует

спасибо, посмотрю


Цитата:
Скачал я precomp 0.4.1 и решил его совместить с FreeArc.

надеюсь, кто-нибудь другой ответит
Автор: Eagle1726
Дата сообщения: 29.01.2012 21:35
Приветствую.
Подскажите пожалуйта,какой алгоритм сжатия лучше подойдет для сжатия файлов мультимедиа?
Автор: ndch
Дата сообщения: 13.04.2011 07:37

Цитата:
сейчас переустановил с нуля - всё есть. что у тебя за дистрибут?

http://forum.ru-board.com/topic.cgi?forum=5&topic=35164&start=0&limit=1&m=1#1
http://freearc.org/download/testing/FreeArc-0.67-alpha-win32.exe
Да-да. Был невниманелен.
распаковал дистрибутив при помощи 7zip, получилось:
директория bin
и директория $_OUTDIR\bin
потому и не запустилось.
Я понимаю что "и так нормально устанавливается", но "внутренней красоты, единообразия" нет.
Это конечно один случай на 100500 пользователей и Ваше дело, как устроен инсталлятор, но всё же ...

Если пожелания к инсталлятору принимаются, то есть еще такое:
При установке анализировать установлены ли библиотеки gtk. Соотвтственно не устанавливать если они есть.
Сделать установку библиотек gtk "опциональными".
Я понимаю что есть ньюансы, но всё же. Хотелось бы немного более "гибкого" инсталлятора.


а другой листрибутив:
http://freearc.org/download/testing/FreeArc-console-0.67-alpha-win32.exe
так не получается создать zip.
Из вышеуказанного дистрибутива достал 7z.dll положил к директорию с Arc.exe. всё это счастье находится в %Path%.

запускаю

arc a a.zip -tzip

получаю

FreeArc 0.67 (March 18 2011) creating archive: a.zip
Compressing 58 files, 23,213,441 bytes. Processed 0%
c_szCompress: compression error
arc.EXE: szCheckedTABI: error

Я что-то упустил из виду ?
Автор: WildGoblin
Дата сообщения: 30.01.2012 11:56
Bulat_Ziganshin
Потестировал я ещё раз свои файлики - к сожалению, при использовании -mx и при отключенных некоторые прекомпрессорах, ошибки всё равно иногда появляются - если же использовать -m9, то архивы создаются без проблем.
Автор: Shuld
Дата сообщения: 30.01.2012 16:57
Bulat_Ziganshin

1. Понял про разницу во времени маленьких объемов и больших.
При маленьких объемах, похоже, исходные данные хранятся в ОЗУ, и на диск идет только запись. (Я ведь несколько раз подяд прогоняю сжатие).
При больших объемах, данные реально считываются и записываются. Получается две дисковых операции, скоростные методы преимущество теряют.

2. При новом rep-е появляется еще интересный скоростной вариант: rep+xtor:3:4m:h64k
Один из примеров, везде rep от 11.01.2012:

Без rep-а
FreeArc 0.67 (December 25 2011) Creating archive: proba5.arc using 4x4:tor:3:4mb:h256kb
Memory for compression 83mb, decompression 88mb, cache 16mb
Compressed 1,731 files, 757,517,055 => 527,930,839 bytes. Ratio 69.6% Compression time: cpu 27.11 secs, real 7.44 secs. Speed 101,866 kB/s
FreeArc 0.67 (December 25 2011) Updating archive: proba5.arc using 4x4:tor:3:4mb
Memory for compression 83mb, decompression 88mb, cache 16mb
Compressed 1,731 files, 757,517,055 => 532,685,127 bytes. Ratio 70.3% Compression time: cpu 24.30 secs, real 7.59 secs. Speed 99,825 kB/s

С rep-ом
FreeArc 0.67 (December 25 2011) Creating archive: proba5.arc using rep:1gb+4x4:tor:3:4mb
Memory for compression 1171mb, decompression 1112mb, cache 16mb
Compressed 1,731 files, 757,517,055 => 435,592,914 bytes. Ratio 57.5% Compression time: cpu 24.15 secs, real 6.94 secs. Speed 109,162 kB/s
FreeArc 0.67 (December 25 2011) Creating archive: proba5.arc using rep:1gb+4x4:tor:3:4mb:h64kb
Memory for compression 1170mb, decompression 1112mb, cache 16mb
Compressed 1,731 files, 757,517,055 => 436,406,848 bytes. Ratio 57.6% Compression time: cpu 22.18 secs, real 6.40 secs. Speed 118,429 kB/s

Добавлено:
Внес исправления
Автор: juvaforza
Дата сообщения: 13.04.2011 10:23
ndch

Цитата:
При установке анализировать установлены ли библиотеки gtk. Соотвтственно не устанавливать если они есть.

Это практически невозможно, в силу этих нюансов, и бессмысленно, в силу этих же нюансов.

Цитата:
Сделать установку библиотек gtk "опциональными".

Это другой разговор.

Добавлено:
byExit

Цитата:
Заметил небольшой баг в работе GTK Theme Selector. Темы не пред просматриваются, если текущая виндосовская учётка содержит символы кириллицы (тестил на XP SP3)

Может учетные записи имеют разный тип? Но это уже не по поводу FA, а по поводу GTK+ Preference Tool.
Автор: Bulat_Ziganshin
Дата сообщения: 30.01.2012 18:22

Цитата:
Гипотетически - конечно, да!
То есть это для таких случаев, если они есть?
(для этого нужен какой-нибудь райд, но ведь и проц будет не моего уровня).

достаточно ssd и какого-нибудь ультрабучного процессора


Цитата:
Подскажите пожалуйта,какой алгоритм сжатия лучше подойдет для сжатия файлов мультимедиа?

стандартным, fa сам разберётся


Цитата:
Потестировал я ещё раз свои файлики - к сожалению, при использовании -mx и при отключенных некоторые прекомпрессорах, ошибки всё равно иногда появляются - если же использовать -m9, то архивы создаются без проблем.

-mx определяется как -m9, так что вопрос просто в везении. а в чём проблема - в твоей машине иди моей программе, надо разбираться, тестировать сжатие присланных тобой файлов
Автор: Bulat_Ziganshin
Дата сообщения: 13.04.2011 11:41

Цитата:
Я понимаю что "и так нормально устанавливается", но "внутренней красоты, единообразия" нет.

это называется "вылизывать яйца" к тому же у меня это никак не регулируется, вероятно внутренняя кухня nsis


Цитата:
При установке анализировать установлены ли библиотеки gtk. Соотвтственно не устанавливать если они есть.
Сделать установку библиотек gtk "опциональными".


нафиг не нужно 99% юзеров (в отличие от уже имеющихся настроек инсталятора) и создаст ещё больше проблем поскольку есть проблемы совместимости с другими версиями gtk2hs. сейчас есть "update" версии - они как раз без файлов gtk2hs:

FreeArc-update-0.67-alpha-win32.exe
FreeArc-portable-update-0.67-alpha-win32.zip


Цитата:
Из вышеуказанного дистрибутива достал 7z.dll

либо бери 7z.dll из самого 7-zip, либо ещё добавь FreeArcCodecs.dll
Автор: Shuld
Дата сообщения: 30.01.2012 20:26

Цитата:
достаточно ssd


Да, я уже так подумал.

В ближайшее время (завтра?) выложу вчернове линейку равномерных методов (основных) для FreeArc. Вроде получилось.
Автор: ndch
Дата сообщения: 13.04.2011 13:23
Bulat_Ziganshin

Цитата:
ещё добавь FreeArcCodecs.dll

Тоже самое
класть надо в .\Codecs\FreeArcCodecs.dll
и с 7z.dll от 7zip заработало

Разница то вообще есть 7z.dll от 7zip и 7z.dll от FreeArc ?
Я имею ввиду для меня как для пользователя.

Неувязка какая-то с этим 7z.dll и FreeArcCodecs.dll: нет их в "консольном дистрибутиве".
Можно ли расчитывать что Вы рассмотрите вариант включения их в "консольный дистрибутив" ?

Добавлено:

Цитата:
создаст ещё больше проблем поскольку есть проблемы совместимости с другими версиями gtk2hs

тогда и не надо наверное.
Автор: Bulat_Ziganshin
Дата сообщения: 31.01.2012 00:32
SREP 3.0 released:-m1f..-m3f: Future-LZ compression; -m3f now is the default mode
-mem: limit amount of RAM used for Future-LZ decompression
-vmfile and -vmblock options fine-tune VM file used in -mem mode
-mBYTES: copy matches longer than BYTES directly from outfile
3x faster compression: I/O and MD5/SHA1 tasks were offloaded into separate thread
unrolled internal loop, unrolling factor controlled by -a option, -a1 is the slowest but requires least memory
-nomd5: don't store/check MD5 checksum of every block
-mmap: use memory-mapped file for match checking by I/O
when necessary, temporary file is created automatically
made stderr always unbuffered (useful for GUIs around srep.exe providing progress indicator)
"srep" and "srep -d" commands now work as a filter if stdin and stdout are redirected
64-bit version now can use >4 GB of RAM
fixed bug when compressing data from pipe (i.e. producer | srep)
Changes since the latest alpha:files compressed with -nomd5 tagged with special flag in the compressed file header, so that -nomd5 is automatically applied on their decompression with appropriate message to user
added date, version, copyright and other exe resources to windows executables
More info at http://freearc.org/research/SREP.aspx


Релиз SREP 3.0:-m1f..-m3f: Future-LZ сжатие; -m3f теперь - режим по умолчанию
-mem: ограничивает объём ОЗУ, используемый для Future-LZ распаковки
-vmfile и -vmblock: опции, настраивающие файл подкачки, используемый при ограничении ОЗУ опцией -mem
-mBYTES: копировать матчи длиннее BYTES байт напрямую из выходного файла
3-кратно ускорена упаковка: I/O и вычисление MD5/SHA1 вынесены в отдельный тред
развёрнут внутренний цикл упаковки, коэф. разворачивания настраивается опцией -a, -a1 - самый медленный режим, но использует чуть меньше памяти
-nomd5: не запоминать/проверять MD5 хеши блоков
-mmap: использовать отображение файлов в память для проверки матчей через I/O
при необходимости временный файл создаётся автоматически (если не указано -temp= без параметра)
stderr никогда не буферизуется (полезно для GUI-программ, выводящих индикатор прогресса для srep.exe)
"srep" и "srep -d": эти команды теперь работают как фильтр, если stdin и stdout перенаправлены
64-битная версия теперь может использовать >4ГБ ОЗУ
исправлена ошибка при сжатии данных, полученных по конвейеру (например, producer | srep)
Изменения с последней альфы:файлы, сжатые с -nomd5, помечаются спецфлагом в заголовке сжатого файла, так что -nomd5 автоматически используется и при их распаковке с выводом соответствующего сообщения пользователю
добавлены дата, версия, копирайт и прочие exe-ресурсы в виндовые exe-файлы
Хотите узнать больше? http://freearc.org/research/SREP.aspx
Автор: Bulat_Ziganshin
Дата сообщения: 13.04.2011 15:10

Цитата:
Тоже самое
класть надо в .\Codecs\FreeArcCodecs.dll


только хотел написать...


Цитата:
Разница то вообще есть 7z.dll от 7zip и 7z.dll от FreeArc ?

есть. моя быстрее, но глючит. пока советую оригинальную


Цитата:
Неувязка какая-то с этим 7z.dll и FreeArcCodecs.dll: нет их в "консольном дистрибутиве".
Можно ли расчитывать что Вы рассмотрите вариант включения их в "консольный дистрибутив" ?


как раз думаю. с одной стороны. он станет намного больше и это не основная функция программы, тем более консольной. с другой... в общем консольный дистрибут делался для тех кому тяжело загрузить основной
Автор: juvaforza
Дата сообщения: 13.04.2011 15:39

Цитата:
к тому же у меня это никак не регулируется, вероятно внутренняя кухня nsis

Скорее это [more=плюсы]
Цитата:
В настоящее время инсталляторы NSIS не могут быть полностью декомпилированы. Сам инсталлятор не содержит в себе никаких функций для того, чтобы извлечь сценарий и/или файлы без инсталляции. Это - выбор разработчика, доступны ли исходный текст и/или файлы для инсталлятора для публики или нет. Есть, однако, внешние инструментальные средства, которые позволяют это сделать. 7-zip поддерживает частичную распаковку NSIS инсталляторов с алгоритмом сжатия lzma или bzip. Так же существует мульти-архивный плагин для TotalCommander.
Небольшая заметка для разработчиков: используйте DCryptDll, если хотите скрыть некоторые файлы в вашей инсталляции.
[/more] 7-Zip, чем чей-то недостаток.
Автор: newbie2k6
Дата сообщения: 31.01.2012 06:52
Eagle1726
Подскажите пожалуйта,какой алгоритм сжатия лучше подойдет для сжатия файлов мультимедиа?
Если эти файлы уже упакованные, то, по идее, от дополнительной компрессии архиватором будет мало пользы. Другое дело — форматы вроде WAV, которые можно сжимать как с потерями данных (англ. "lossy"; например, в формат MP3), так и без потерь (англ. "lossless"; например, в формат FLAC). Без конкретики это, в общем-то, праздный разговор.
Автор: vasulpr
Дата сообщения: 15.04.2011 07:03
Было бы интересно увидеть этот алгоритм в FA
http://habrahabr.ru/blogs/algorithm/117319/
Автор: WildGoblin
Дата сообщения: 31.01.2012 07:29
Bulat_Ziganshin

Цитата:
-mx определяется как -m9, так что вопрос просто в везении.
Действительно, в везении - вчера упаковывал одну игрушку (я не "репакер" - просто файлики у себя в порядок привожу...) и вылетела ошибка уже с -m9.


Цитата:
а в чём проблема - в твоей машине иди моей программе, надо разбираться, тестировать сжатие присланных тобой файлов
7z и рар архивы создают без проблем.
P.S. Если надо что-то протестировать для решения проблемы, то я всегда готов!
Автор: PAQer
Дата сообщения: 15.04.2011 08:55

Цитата:
Было бы интересно увидеть этот алгоритм в FA

без реально работающего декодера это фигня, а не алгоритм. Комменты хотя бы почитайте.
Автор: Shuld
Дата сообщения: 01.02.2012 19:07
Bulat_Ziganshin
Как и обещал, выложил тест с новой линейкой методов –m81…-m89 здесь:
http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=760#6
Линейка методов имеет примерно равномерный шаг возрастания времени сжатия от метода к методу и составляет 1,4…1,5.
Расшифровка методов:


Добавлено:
Метод Расшифровка метода Примерное соответствие стандартному методу
Автор: Bulat_Ziganshin
Дата сообщения: 15.04.2011 10:42
очевидно, что алгоритм, сжимающий несжимаемые данные, некорректен
Автор: Bulat_Ziganshin
Дата сообщения: 02.02.2012 09:30
Shuld
1. твоим результатам по настройке параметров fb и т.п. я не очень доверяю - это может зависеть от типа данных. хотя с другой стороны, я сам это вообще не тестировал, скопировал готовые настройки из однопоточных режимов, оптимизацией которых я занимался ещё на старом cpu

2. предлагаемые тобой методы сжатия требуют много памяти для распаковки, что заставляет задуматься о том, как их можно использовать, не создавая проблем. я разные способы передумал, сейчас склонился к тому, чтобы всё же встроить srep в fa, но пока это дело будущего

3. на настоящий же момент я оптимизировал rep, добавил его в -m1 и оптимизировал настройки rep в -m2..m4 что повысило сжатие на 1-2% без потерь скорости


теперь что касается внедрения srep. произойдёт это в лучшем случае в 0.80. в январе я сделал очень важную вещь - реализовал поддержку методов с несколькими выходными потоками (как bcj2 в 7-zip). srep в fa будет сделан на основе нынешнего режима -m1f, но сжатые данные будут записываться в два потока - поток литералов и поток матчей. литералы будут писаться (и сжиматься дальнейшими exe+delta+lzma) сразу, а матчи копиться в памяти, и по окончании данных сортироваться по src и только затем сохраняться в архив. соответственно, при распаковке я смогу читать данные из обоих потоков параллельно и сохранять в памяти/vmfile содержимое будущих матчей

итого - и при сжатии, и при распаковке чтение и запись данных будет осуществляться чисто последовательно, при этом будет использоваться объём памяти, примерно равный 10% от объёма сжимаемых данных. при необходимости его можно дальше сократить - при упаковке за счёт увеличения -l, при распаковке - за счёт сохранения содержимого матчей во временном файле. помимо этого, можно ещё выцыганить несколько процентов сжатия, используя после srep обычный rep сч небольшим словарям и размером матча, к примеру rep:96m:32


кстати, пример распаковки 100 гб файла (со 100 гб словарём!!!) с использованием всего 100 мб памяти:

D:\>srep64i -d -mem100m m1f.srep nul
100%: 55,214,690,844 -> 98,420,528,640: 56.10%. Cpu 112 mb/s, real 84 mb/s
Matches 0 68925 39805211, I/Os 0, RAM 0/60, VM 0/8808, R/W 221352/221352

Добавлено:
Архиватор Размер словаря

Страницы: 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275

Предыдущая тема: Punto Switcher (часть 3)


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.