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

» FreeArc (часть 4)

Автор: ruduk
Дата сообщения: 09.06.2012 00:02
Hell_Dog2011

Цитата:
что можете посоветовать по сжатию файлов после обработки прикомпом и срепом

1) для начала, все-таки читать доку (например, FreeArc040-rus.htm --> разделы "Выбор алгоритмов сжатия", "Параметры алгоритмов сжатия", чтобы узнать что и как можно подстроить в методах "под себя"),
2) скачать и установить себе последнюю версию FreeArc,
3) пробовать файлы на сжимаемость - попробовать сжать файлы разными методами, вместе или по-отдельности, попробовать сжать экспериментальными методами (которые как-раз написаны для использования прекомп и среп, читайте форум),
Автор: WildGoblin
Дата сообщения: 15.11.2012 12:56
Bulat_Ziganshin

Цитата:
Archive Manager в TC
Что за такой Archive Manager? Можно ссылку?
Автор: Bulat_Ziganshin
Дата сообщения: 09.06.2012 00:11
Hell_Dog2011
в опциях сжатия выбираешь макс. сжатие и отмечаешь снизу галочки srep и precomp
Автор: Fire_Dragon
Дата сообщения: 15.11.2012 16:35
Хорошо бы сделать нормальную информацию для восстановления по раньше чем в версии 0.90, как по плану, давно хочется чтобы появился архиватор способный конкурировать с RARом, но без инфы для восстановления лично для меня конкурентов на 100% способных заменить RAR быть не может. Есть, конечно, SQX, но там свои прибамбасы есть.
Желаю удачи автору FreeArc в его начинаниях! Спасибо за работу!
Автор: Hell_Dog2011
Дата сообщения: 09.06.2012 12:21
Bulat_Ziganshin
в моём такого нету может у меня не та версия(666) вот моя.
Автор: muzf
Дата сообщения: 15.11.2012 16:40
Что-то автор precomp не фиксит проблему несжатия jpeg и не отвечает на http://encode.ru/threads/1366-Precomp-0-4-2/page2
Автор: Bulat_Ziganshin
Дата сообщения: 09.06.2012 12:55
Hell_Dog2011
да, это только в 0.67
Автор: QSQ
Дата сообщения: 15.11.2012 17:10
Bulat_Ziganshin разбивка на тома в бетке уже есть?
Автор: Bulat_Ziganshin
Дата сообщения: 11.06.2012 22:08

Цитата:
Ерунда какая-то с последним FreeArc:
1. В GUI настройки при смене верхних пресетов вверху меняются.
2. Нигде не слова о том что надо packjpg.exe положить в папку freearc/bin (нужен подход как в megui с автообновлением компонентов)
3. Подаю на вход чистого packjpg 1.jpg, на выходе - получаю 80%. Запускаю с тем же файлом freearc с -m5p (или -m9p), packjpg пишет в консоле что вроде как работает, но на выходе архив 101%. WTF ?
4. freearc.ini данный здесь не до конца совместим с последней версией freearc, в частности те же -m5p не работают (а в -m81 jpg preprocess вроде как нет).
5. Почему бы не включить эти m81-m87 в официальную версию, в том числе сделать их доступными и через GUI ?

1. не понял
2. не нужно
3. вероятно ты используешь свой нестандартный ini-файл или ini-файл от предыдущих версий. в моём _майском_ arc.ini packjpg при -m5p не используется, вместо него джипеги сжимает precomp
4. это верно
5. первое - можно. второе - ты предлагаешь снова начать цикл смены gui? думаю достаточно того, что ты сам можешь их вставить в freearc.ini или просто набрать "81" в строке выбора метода сжатия
Автор: V2driver
Дата сообщения: 15.11.2012 20:02
muzf
Че там фиксить то?
Просто у Вас как бы 2 jpg файла в одном)
Он жмёт их по отдельности.
Где ошибка?
Автор: Andarin
Дата сообщения: 15.11.2012 20:15
WildGoblin

Цитата:
Что за такой Archive Manager?

Я так полагаю, имелся в виду MultiArc плагин - надо в multiarc.ini внести содержимое freearc.addon, ну и пару файлов поместить в нужное место. Может, конечно, имелось в виду другое, но установить FA в Total можно и таким способом.
Автор: muzf
Дата сообщения: 12.06.2012 12:24
Да, половину слов не скопировал
1. В GUI настройки при смене верхних пресетов вверху галочки внизу не меняются.
3. Стандартный ini из последней версии. Что из GUI, что через -m5p размер не уменьшается.
5. С точки зрения удобства людей наиболее лучшие по скорости/уровню сжатия режимы m81-m87 просто обязаны быть в GUI и более того, выбраны по умолчанию. Возможно даже заменить ими стандартные -m1.. Или сделать подход как в x264, есть пресеты вида superfast, medium, slow, и другие, и в разные моменты времени их внутренности меняются, но названия остаются. Так и здесь, ввести superfast, который плавно мигрирует с -m1 на -m81.

Что хочу сказать по поводу packjpg. Дикий тормоз, на фоне того же x264 с теми же алгоритмами арифметического сжатия. Если x264 на i7-860 выдаёт на 2Mpx FullHD -medium в районе 12fps, то та же 16Mpx jpg имеет в 8 раз больший объём, и должна сжиматься как минимум за полсекунды, но 4.5секунды это перебор, тем более там нет никакого motion compensation, как в x264, и просто расжимаются DCT коэффициенты из VLC и пережимаются в AC. Так что поле для оптимизация вижу как минимум раз в 10, неплохо бы автору packjpg взять некоторые готовые процедуры из кода x264.

Лог -m9p

Код:
C:\Program Files (x86)\FreeArc\bin>arc a 1jpg.arc 1.jpg -m9p
FreeArc 0.67 (May 22 2012) creating archive: 1jpg.arc
Compressing 1 file, 4,307,553 bytes. Processed 0%
Compressing 4,307,553 bytes with precomp042 -c- -t-j -intense -o$$arcpackedfile
$$.tmp $$arcdatafile$$.tmp

Precomp v0.4.2 - ALPHA version - USE FOR TESTING ONLY
Free for non-commercial use - Copyright 2006-2011 by Christian Schneider

Input file: $$arcdatafile$$.tmp
Output file: $$arcpackedfile$$.tmp

Using PACKJPG.DLL for JPG recompression.

--> packJPG DLL v2.4WIP4 (11/06/2008) by Matthias Stirner <--
More about PackJPG here: http://www.elektronik.htw-aalen.de/packjpg

100.00% - New size: 4307589 instead of 4307553

Done.
Time: 4 seconds, 477 milliseconds

Recompressed streams: 0/16
zLib streams (intense mode): 0/16

None of the given compression and memory levels could be used.
There will be no gain compressing the output file.

Errorlevel=2
10%
Compressing 4,307,566 bytes with srep -m3f -mem256mb $$arcdatafile$$.tmp -

SREP 3.0 (January 30, 2012): input size 4 mb, memory used 33 mb, -m3f -l512 -c256 -a4
100%: 4,307,566 -> 4,301,537: 99.86%. Cpu 88 mb/s, real 59 mb/s
Second pass: 100%

Errorlevel=0
Compressed 1 file, 4,307,553 => 4,321,369 bytes. Ratio 100.3%
Compression time: cpu 1.01 secs, real 6.88 secs. Speed 626 kB/s
All OK
Автор: muzf
Дата сообщения: 15.11.2012 21:47
V2driver
Обычный jpeg с фотоаппарата. Конечно же с маленькой превьюшкой в EXIF. Что тут необычного ? У любого человека 90% именно таких Jpeg, которые надо архивировать/бэкапить/пересылать.
PackArc/PackJpg справляется отлично, Precomp (который по умолчанию в FreeArc, без него из коробки jpeg не сжать) - не справляется.
Поэтому в www.squeezechart.com Freearc в секции сравнения сжатия Jpeg плетётся в самом конце, потому что там тестируются именно такие же похожие Jpeg с обычных фотоаппаратов. А должен - на одной из верхних строчек рядом с PackArc. Такая же ситуация и с mp3, поддержки которого ещё нет в Freearc из коробки.
Автор: Ivanov Ivan
Дата сообщения: 16.11.2012 02:28
В Википедии для FreeArc указана поддержка различных алгоритмов шифрования (AES, Blowfish, Twofish, Serpent). Их можно самому выбрать или как?

То есть какой из них указать, чтобы пароль был самый надёжный, то есть с большим количеством бит в ключе?
Автор: Shuld
Дата сообщения: 12.06.2012 21:47
Bulat_Ziganshin

Цитата:
4. freearc.ini данный здесь не до конца совместим с последней версией freearc, в частности те же -m5p не работают (а в -m81 jpg preprocess вроде как нет).

Под последние версии архиватора, arc.ini я модифицировал, но не довел до конца (нужно много времени на проверки). Поэтому не выкладывал.
Первые методы из серии -m8. выглядят так:
81 = rep:1gb:64:c32+xtor:3:4m:h64k
82 = rep:1gb:64:c16:d4m:s32+xtor:4:4m:h512k:l4
83 = rep:1gb:64:c16:d4m:s32+xtor:4:4m:h1m:l8
84 = rep:1gb:64:c16:d4m:s32+xtor:4:4m:h8m:l8
и пока все.
Автор: egor23
Дата сообщения: 16.11.2012 03:10
Ivanov Ivan

Цитата:
В Википедии для FreeArc указана поддержка различных алгоритмов шифрования (AES, Blowfish, Twofish, Serpent). Их можно самому выбрать или как?

можно, но "руками"
http://freearc.sourceforge.net/rus/FreeArc040-rus.htm#_Toc185594998
Автор: Bulat_Ziganshin
Дата сообщения: 12.06.2012 22:05

Цитата:
через -m5p размер не уменьшается.

блин, я уже забыл, а ты доки и не читаешь: "Обратите внимание: режим сжатия -max (-m9p) реализует максимальное сжатие с precomp+srep+dispack, а -m9j делает то же самое плюс пережатие jpeg"


Цитата:
Дикий тормоз, на фоне того же x264 с теми же алгоритмами арифметического сжатия.

запорожец - дикий тормоз на фоне бугатти, несмотря на те же 4 колеса


Цитата:
С точки зрения удобства людей наиболее лучшие по скорости/уровню сжатия режимы m81-m87 просто обязаны быть в GUI и более того, выбраны по умолчанию.

может, ещё зафигачить по умолчанию методы, требующие 100 гб озу для распаковки?


Цитата:
В GUI настройки при смене верхних пресетов вверху галочки внизу не меняются.  

при выборе пресета в верхней строке? ага, и это не так просто реализовать. как-нибудь в будущем


Цитата:
Кстати, попробовал packMP3 от создателя pacjJPG, действительно сжимает до 25%. Неплохо бы его тоже включить в FreeARC. mp3zip тоже хорош.

или как вариант - packARC. с precomp проблема в том, что jpeg-поддержка в нём иногда виснет, не знаю как с этим будет в packARC. mp3zip - коммерчески

Shuld
в общем тот, кому хочется это видеть в fa, должен будет взять arc.ini от июньской версии, добавить туда аккуратно твои методы и кинуть мне
Автор: V2driver
Дата сообщения: 16.11.2012 07:16
muzf PackArc/PackJpg сжимают пофайлово, а precomp-у приходится работать с бинарниками, откуда ему знать что этоти 2 jpg нужно жать солидом?
Как Вы себе это представляете?
Автор: muzf
Дата сообщения: 12.06.2012 23:06

Цитата:
Цитата:
через -m5p размер не уменьшается.  

блин, я уже забыл, а ты доки и не читаешь: "Обратите внимание: режим сжатия -max (-m9p) реализует максимальное сжатие с precomp+srep+dispack, а -m9j делает то же самое плюс пережатие jpeg"

Всё равно не получается. Compressed 1 file, 4,307,553 => 4,219,424 bytes. Ratio 97.9%
У packjpg выше приводил 79%.
И самое главное, до того как пробовать через консоль включал галочки на precomp jpeg в gui с тем же нулевым результатом (то есть на выходе были те же 98%, которые я считаю ошибкой на фоне packjpg).
Кстати, packjpg консольный уже полгода как версии 2.5, в dll же 2.4.


Цитата:
может, ещё зафигачить по умолчанию методы, требующие 100 гб озу для распаковки?

Зачем же. Но если эти методы такие замечательные что на них проводятся тесты и рекомендуются в этой ветке именно они, то почему бы и нет. Идея пресетов позволит менять внутренние параметры от версии к версии, скрывая подробности от неопытных пользователей.

Кстати, очень хотелось бы видеть в документации пример запуска для режима backup с синхронизацией, то есть новые или изменившиеся файлы добавлялись бы в архив, а исчезнувшие файлы соответственно удалялись. Хотел попробовать для этих целей навороченный StuffIt, так он не умеет режима синхронизации, то есть удалять файлы из архива.
Автор: WildGoblin
Дата сообщения: 16.11.2012 10:14
Andarin

Цитата:
Может, конечно, имелось в виду другое...
Мне вот это и интересно!
Автор: Bulat_Ziganshin
Дата сообщения: 16.11.2012 11:19
Новая альфа-версия:AES-NI: 1ГБ/сек - скорость шифрования (методом по умолчанию и в целом для -ae=aes-*/ctr/r:0) на современных процессорах
REP: исправлена ошибка, приводившая к зависанию на файлах размером BLOCKSIZE*N+k где 0<=k<L
GUI: показывает английский тултип/перевод если текущая локализация не имеет своего варианта
7z.dll: расширение архива по умолчанию теперь определяется опцией -t (например, команда "a a -tbzip2" эквивалентна "a a.bz2 -tbzip2")
LZ4: переименован метод "lz4a"->"lz4b" (формат сжатых данных несовместим со старой версией)
Из лицензии программы убрано упоминание GPL

Интеграция с Explorer - исправлены ошибки в новой реализации:больше не показывает каскадное меню, если оно пусто
корректное меню, если выбраны каталоги
если выбран ровно один архив - показывает команды для сжатия его в другие форматы
для архивных файлов меню всегда выводится (так что галочка включает только ассоциирование с FreeArc и иконку)
обновлён список расширений архивов/контейнеров (взят из 7z.dll плюс apk/zipx и кое-что по мелочи)

Глобальная очередь операций - закончена реализация: теперь эта настройка из freearc.ini также используется для команд FreeArc.exe исполняемых из комстроки (включая запускаемые из меню Explorer)
изменения этой настройки в диалогах Добавить/Извлечь больше не запоминаются в freearc.ini (в отличии от изменений, сделанных в диалоге Настройки)
ГИП: выводит "Ждём пока другая копия FreeArc завершит операцию..." и не начинает отсчёт времени пока идёт ожидание в очереди

Улучшения в вычислении/ограничении потребления памяти:Более точное вычислении/ограничении потребления памяти при использовании внешних компрессоров-фильтров (с stdin на stdout)
Unarc: ограничивает потребление памяти в grzip/4x4 по такому же алгоритму как Arc.exe
Unarc: теперь опция -ld по умолчанию трактует свой параметр как мегабайты

Исправлены ошибки в использовании временного каталога:GUI: больше не предлагает удалить временные файлы при открытии вложенного архива (распакованного во временный каталог) - в частности это исправляет проблему при открытии архивов .tar.gz
GUI: временный каталог, установленный в arc.ini (опцией -w), отныне может быть использован для распаковки содержимого архива в операции "Открыть из архива"
GUI: логфайл/врем.каталог, установленные в freearc.ini, отныне имеет больший приоритет, чем аналогичные настройки из arc.ini





New alpha version:AES-NI: 1GB/sec speed for default encryption method (and in general for -ae=aes-*/ctr/r:0) on modern cpus
REP: fixed bug causing hangup on files with size=BLOCKSIZE*N+k where 0<=k<L
GUI: show english tooltip/translation if the current locale doesn't have one
7z.dll: "a a -tbzip2" now works as "a a.bz2 -tbzip2" (i.e. default archive extension depends on the -t option)
LZ4: renamed method "lz4a"->"lz4b" (data format is incompatible with previous version)
Removed GPL from the program license

Explorer integration - fixed bugs in the new implementation:don't show empty cascaded menu
proper handling if directories are selected
if only one archive is selected - show options to compress it to other formats
always show context menu for archive files (so checkbox only toggles association with FreeArc and icon)
updated list of extensions to associate with (taken directly from 7z.dll plus apk/zipx and a few other)

Global command queue - finished implementation: now this freearc.ini setting also used for FreeArc.exe commands executed from cmdline (including those executed from the Explorer menu)
changes made to "Global queueing" setting in Add/Extract dialogs are no more saved in freearc.ini (as opposed to changes made in the Setting dialog)
GUI: show "Waiting for other FreeArc copy to finish operation..." and don't start counting operation time until global lock is grabbed

Improved calculation/limiting of memory usage:Improved calculation/limiting of memory usage when using stdin-to-stdout external compressors
Unarc: limit memory usage for grzip/4x4 in the same way as Arc.exe
Unarc: now -ld option accepts limit in megabytes by default

Fixed bugs in tempdir usage:GUI: no more propose to delete temporary files on open of subarchive (stored in the tempdir) - in particular it fixes .tar.gz handling
GUI: temporary directory set in arc.ini (-w) now can be used for extracting archive contents in the "Open file from archive" operation
GUI: logfile/tempdir configured in freearc.ini now has higher priority than those set in arc.ini
Автор: QSQ
Дата сообщения: 12.06.2012 23:15
о чём здесь дискуссия? я выбрал в раскрывающихся списках нужные мне настройки: этого недостаточно?
Автор: Bulat_Ziganshin
Дата сообщения: 12.06.2012 23:25

Цитата:
Всё равно не получается.

возьми portable версию, распакуй в отдельный каталог и прям в каталоге с arc.exe проверни это


Цитата:
Кстати, packjpg консольный уже полгода как версии 2.5, в dll же 2.4.  

дело в том, что использовать packjpg не очень удобно, поскольку он сжимает по одному файлу. это не даёт избавляться от дубликатов, и требует много времени на его запуски. с другой стороны, внутри precomp он иногда сбоит. так что по дефолту мы его не используем вовсе


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

это личное дело Shuld что он тестирует и советует - для 90% пользователей оно подходит, а для оставшихся 10% (которым иногда нужно распаковывать на меньшем озу) оно категорически неприемлемо


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

это в fa с самого начала - юзеры пишут -m1..-m9, а программа сама расшифровывает в силу текущего момента и параметров компа юзера


Цитата:
Хотел попробовать для этих целей навороченный StuffIt, так он не умеет режима синхронизации, то есть удалять файлы из архива.

и навороченный fa не умеет. используй простенький 7-zip

QSQ
??? дискуссия о многом
Автор: vasulpr
Дата сообщения: 13.06.2012 07:52
Bulat_Ziganshin
что за packARC ? это что ваша новая разработка?


Цитата:
это не даёт избавляться от дубликатов

так эти файлы затем по верху можно закатать lzma или rep-ом и все повторы исчезнут


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

фиг с тем временем упаковки, а розпаковну можно сделать параллельной, что ускорит ее немного
Автор: muzf
Дата сообщения: 16.11.2012 12:54

Цитата:
muzf PackArc/PackJpg сжимают пофайлово, а precomp-у приходится работать с бинарниками, откуда ему знать что этоти 2 jpg нужно жать солидом?  
Как Вы себе это представляете?

Как вариант - для мультимедиа файлов отключать precomp и сжимать пофайлово.
Но проблема вообще-то в самом precomp (в 043 проблема осталась). Судя по -v он определяет размер второго jpeg stream всего в 493390 байт, когда он должен быть раз в 9 больше.
Эта проблема проявляется и в таблице squeezechart у Precomp.
Автор: muzf
Дата сообщения: 13.06.2012 09:30

Цитата:
Цитата:
Всё равно не получается.  

возьми portable версию, распакуй в отдельный каталог и прям в каталоге с arc.exe проверни это

Один в один, ini ведь тот же.
Compressed 1 file, 4,307,553 => 4,219,424 bytes. Ratio 97.9% против 78% у packjpg

Цитата:
Цитата:
Хотел попробовать для этих целей навороченный StuffIt, так он не умеет режима синхронизации, то есть удалять файлы из архива.

и навороченный fa не умеет. используй простенький 7-zip

Неплохо бы добавить такой режим в freearc, первоначально он меня заинтересовал фразой Solid compression with smart updates (only changed solid blocks are recompressed) , подумал что такое там уже есть. Но вижу, что в roadmap это запланирован в 2.0
Автор: Paramon111
Дата сообщения: 16.11.2012 15:47
И никто не напишет что последняя альфа не работает? Приколисты вы народ ))
Автор: Andarin
Дата сообщения: 16.11.2012 16:41
Paramon111

Цитата:
И никто не напишет что последняя альфа не работает? Приколисты вы народ ))

Это только у приколистов, видимо, не работает.
У меня работает. Всё до мелочей не проверял, но стандартные операции без проблем.
Автор: slech
Дата сообщения: 16.11.2012 17:39
Файл.doc --> FreeArc --> Add to Archive --> Всё дефолтное --> Ok:
c_szDefaultExtension:unsupported archive type

Добавлено:
Ok --> Cancel --> Ok - вешает процесс FA

Добавлено:
Хотя не совсем,
thread blocked indefinetely

Потом всё исчезает.
Автор: egor23
Дата сообщения: 16.11.2012 17:42
Paramon111

Цитата:
И никто не напишет что последняя альфа не работает? Приколисты вы народ ))

глючный релиз


Добавлено:
Bulat_Ziganshin
FreeArc
1. например упаковываем Папку bin\, ничего не создаётся
Упаковать - ок - окно закрылось
ничего не происходит

2. например упаковываем Папку FreeArc-portable-0.67-alpha-win32\

Упаковать - ок

c_szDefaultExtension: unsupported archive type

Кстати
А окно так должно выглядеть?

Страницы: 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275

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


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