» FreeArc (часть 4)

1noObman1

Цитата:

Интересует именно вшитый алгоритм, а не отдельные тулзы (с этим проблем и так нет).

Так и не надо комбайн устраивать... Который рухнет под своей тяжестью... и перегруженностью/запутанностью интерфейса.

Для аудиокодеров уж лучше отдельную GUI с прикрученными "отдельными тулзами".
Так дойти можно до "добавьте сжатие в mp3".
Слишком мало людей которые "лабают" lossless audio и репаки игр одновременно.

Булат, как насчёт включения в 0.70 тех быстрых пресетов из соседней темы, а также packarc для jpg/mp3 без precomp ?

Alex_Piggy
Афигеть!
Спасибо!
Второй вариант то что нужно!

Цитата:

Ещё раз: разница в сжатии максимум 4 Мб.
Или для Вас максимальное сжатие самоцель ?

По 4 мб на каждый файл и наберётся очень много.


Цитата:

1. вшивать другие алгоритмы для звука в fa я не буду потому что и он не резиновый, и моё время тоже. желающие могут использовать внешние exe, писать cls-фильтры и т.п.

В тот то и дело что ТАК и OptimFrog сжимают только непосредственный wav-файл, а не архив с ними и подключить их нормально к фа нельзя. Вот только непонятно зачем тогда они в павер-паке если их нельзя так использовать?

Добавлено:

Цитата:

Так и не надо комбайн устраивать... Который рухнет под своей тяжестью... и перегруженностью/запутанностью интерфейса.

Ну так речь не о перегруженности, а о большей функциональности фа.

Цитата:

Булат, как насчёт включения в 0.70 тех быстрых пресетов из соседней темы, а также packarc для jpg/mp3 без precomp ?

Не все сразу! дайте автору привести в порядок то что есть!

Всем привет!
Помогите модифицировать пресет -mx
Нужно чтобы он по умолчанию вместо стандартных настроек lzma использовал следующие lzma:192mb:bt4:273:mc10000:lc8 - т.е. нужно чтобы использовался словарь размером 192мб а не 177 как сейчас, или подскажите параметр с помощью которого можно сжимать со следующими параметрами lzma и всеми плюшками -mx

1noObman1

Цитата:

По 4 мб на каждый файл и наберётся очень много.

На 1 cd диск (iso/cue).


Цитата:

Ну так речь не о перегруженности, а о большей функциональности фа.

Это уже разница в терминологии.

Bulat_Ziganshin
Хотелось бы сделать примечание по sfx модулю.
Немного подглючивает прогрессбар.

Изображаю в лицах:[more]
Извлекаю sfx архив на "юсб-флешку".



















Прогресс-бар всегда на 99%.
"Remaining time" всегда 1 секунда.
На последнем скриншоте видно что процесс извлечения длится минуту.

На свежескачанной альфе происходит то же самое.
[/more]

Опишу словами:
Дефект: При извлечении неверно работает "прогноз оставшегося времени".
Запрос: Пожалуйста подкорректируйте алгоритм вычисления "предполагаемого оставшегося времени", чтобы "Remaining time" походило на реальное.
Причина: ожидание неизвестности очень дискомфортный процесс (психологический дискомфорт).


При этом скорость извлечения - верная.
Также в архиве присутствует "размер файлов в распакованом виде".
Со стороны, абстрактно, кажется что исправить не так уж и сложно.

Еще одно применение FreeArc - в качестве бенчмарка (на запись) юсб-флешек

Май, май, Первомай!
Скорей 0.70 нам давай!

Цитата:

Слишком мало людей которые "лабают" lossless audio и репаки игр одновременно.

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

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

Всем привет! скажите где можно скачать Srep 3.0 заранее благодарен

Цитата:

В тот то и дело что ТАК и OptimFrog сжимают только непосредственный wav-файл, а не архив с ними и подключить их нормально к фа нельзя. Вот только непонятно зачем тогда они в павер-паке если их нельзя так использовать?

ты пробовал? обрати внимание на последнюю строку:

[External compressor:ofr]
mem = 10
default = normal
packcmd = ofr --encode --mode {option} --optimize best --seek min $$arcdatafile$$.wav --output $$arcpackedfile$$.ofr
unpackcmd = ofr --decode $$arcpackedfile$$.ofr --output $$arcdatafile$$.wav
datafile = $$arcdatafile$$.wav
packedfile = $$arcpackedfile$$.ofr
solid = 0

Bulat_Ziganshin
Понимаю что возможно на это нет времени, просто напоминаю, на случай если Вы забыли:
http://forum.ru-board.com/topic.cgi?forum=5&topic=35164&start=560#5

Суть предложения в том, чтобы была возможность
драг-н-дропнуть на sfx любой *.arc и этот *.arc извлёкся.
Т.е. при запуске sfx.exe анализировал аргумент и "извлекал из него содержимое архива", если это *.arc (или *.exe, но )
(по сути при драг-н дропе запускается sfx.exe тот_файл_который_кинули_на_пиктограмму)

Для чего ? "В среднем по палате" sfx-ы встречаются гораздо чаще чем "полнофункциональный архиватор".

Добавлено:
Bulat_Ziganshin

Цитата:

сложно сделать алгоритм который будет работать корректно во всех случаях, в том числе и этом

Делать поправку раз в 15 секунд (общий размер "распакованных" файлов/скорость) не вариант ?
Нет, Вам виднее, но мне просто интересно.

Fenixx3000
http://freearc.org/research/SREP.aspx

Цитата:

ты пробовал?

ТАК - да. После того, как оно прогоняет его в архив без сжатия так выдаёт ошибку что файл не является .WAV. С офр же еще не пробовал.

Добавлено:

Цитата:

solid = 0

То есть нельзя делать солид-архивы? Ну и даже если так, то это сжатие непосредственно для .вав-файлов. Или же оно пожмёт аудио и в игровом архиве?

Цитата:

драг-н-дропнуть на sfx любой *.arc и этот *.arc извлёкся.

я анализировал и нашёл небольшую техническую проблему - синтаксис "sfx.exe filename" сейчас обозначает "извлечь один файл filename из sfx". понятно, что можно его поменять, но может это вызовет какие-либо проблемы? в частности, мне хотелось бы быть совместимым по синтаксису вызова sfx с rar/7zip

а так мне импонирует идея сделать синтаксис вызова sfx точно таким же как у unarc. это и код упростит, и число компилируемых модулей поможет сократить. сейчас посмотрел - rar и 7-zip используют разный синтаксис, но можно поддерживать оба. так что вполне возможно переделаю до выхода 0.70


Цитата:

Делать поправку раз в 15 секунд (общий размер "распакованных" файлов/скорость) не вариант ?

сам freearc работает нормально? freearc делает два прохода по архиву - сначала просто считает сколько файлов/байт будет извлечено, и затем на основании этого рисует верный индикатор. у unarc предварительного прохода нет и он просто рисует текущую позицию в распаковываемом архиве. я в todo это всё записал, но добавление кода в unarc, замедление его работы из-за второго прохода - не факт что всё это стоит исправления проблем в достаточно частном случае


Цитата:

вот ещё бы 64-битную версию под Лин

главное препятствие здесь - часть моих алгоритмов сжатия не поддерживает компиляцию в 64 бита. поскольку число linux-пользователей крайне мало (меньше 100 штук), само по себе мне это неинтересно. когда буду делать win64 версию - в качестве первого шага именно этим и займусь


Цитата:

необязательно использующую все преимущества 64 бит,  
хотя бы просто кросс-сборку, которая запускается

это как? я так понимаю, что без компиляции в 64 бита тут ничего не поделаешь

Булат, Вы не пробовали свое творение в конкурсе?
http://prize.hutter1.net/
Конкурс старый, но все-же.
Предлагают приз в 50k€ тому кто побьет рекорд и сожмет 100mb архив википедии меньше чем в 16mb.
Там в основном PAQ сжимает.

1noObman1
вроде эти обе утилиты только и работают с PCM RAW данными
а в игровых бывает по разному и mp3 и wav
возможно тем более не любой wav сожмется этими утилитами

такой вот общий вопрос (не только о FreeArc мб):
степень сжатия\компрессии уже достигла своего предела или можно что-то улучшить? на данный момент все архиваторы застопорились в этом плане и вся работа ведется над балансировкой процесса: "скорость компрессии\декомпрессии - размер архива"
и по FreeArc конкретно (может уже было но все же спрошу): при распаковке в установщике % распаковки отображается скачками\шагами, а не плавно, это проблема фриарк или скрипта InnoSetup? если сживать LZMA2 или rar в Inno то распаковка идет плавно

Вы знакомы с этим?
http://www.elektronik.htw-aalen.de/packjpg/

kalpak

Да с чем они работают я знаю. Вот в архиве, например, тот же PCM и с тта в фа сжатие архива улучшается, а эти алгоритмы применить к нему не получается.

Цитата:

при распаковке в установщике % распаковки отображается скачками\шагами

если сам freearc отображает также - вопрос ко мне, чи ни - то ни

Цитата:

Вы знакомы с этим?
http://www.elektronik.htw-aalen.de/packjpg/

да. в курсе что сейчас он под gpl



Добавлено:

Цитата:

Предлагают приз в 50k€ тому кто побьет рекорд и сожмет 100mb архив википедии меньше чем в 16mb.

во-первых, не так. 50к можно получить только сжав файл до 0 байт


Цитата:

Там в основном PAQ сжимает.

ну да, а вдруг freearc раскроет скрытые возможности и опередит paq LOL


Цитата:

нужно чтобы использовался словарь размером 192мб а не 177 как сейчас

в описании метода прописан словарь 254 мб, afair. его уменьшают -lc/-ld, ты можешь отключить их с помощью -lc- -ld-. после этого изменить словарь lzma можно опцией -md

Добавлено:

Цитата:

при прерывании по crtl+c несовсем корректный вывод:

как раз над этим я работал в последнее время..


Цитата:

планируется ли подобие цифровой подписи?

пока нет, есть вещи важнее


Цитата:

А так же, когда ориентировочно планируется работа над юзабилити, поддержка скинов и тд?

скины от gtk держатся, меню Options/Change program skin. юзабилити, наряду с докой и томами, на первом месте в приоритетах

1noObman1

Цитата:

не все архивы можно вскрыть и пожать аудио самому, то хотелось бы что-то, что брало бы архивы целиком и нормально сжимало аудиопотоки

Вам видимо далёки понятие энтропия и закономерности сжатия на пользовательском (эмпирическом) уровне.

Цитата:

сам freearc работает нормально?

Да, gui-версия распаковывает понятно
[more] [/more]


Цитата:

но добавление кода в unarc, замедление его работы из-за второго прохода - не факт что всё это стоит исправления проблем в достаточно частном случае

Молчание на эту тему тоже не факт что людей данная особенность не раздражает. Многие ленивы или терпеливы.
Я честно говоря не увидел замедления при распаковке GUI-версией. Возможно просто не присматривался. Но sfx-ы встречаются чаще "полного архиватора".
Факт занесения Вами в todo данной особенности меня вполне устраивает :) Возможно присмотритесь и со временем сделаете выводы о нужности/ненужности, всё равно же я Вас уговаривать не буду (максимум - приведу доводы за или против).

cross125

Цитата:

степень сжатия\компрессии уже достигла своего предела или можно что-то улучшить?

Оцените соотношение степень сжатия/время упаковки. У FreeArc есть очень интересный алгоритм tornado. Лишь за одно это у меня живёт freearc. При записи на флешку "кучи мелочи" (да и вообще) упаковываю на флешку freearc-ом, получаю ощутимый выигрыш по времени и контроль целостности, критичное закрываю паролем.

Bulat_Ziganshin

Цитата:

во-первых, не так. 50к можно получить только сжав файл до 0 байт

Ого, это же маразм? Если это априори невозможно, почему тогда такой абсурд выкладывают?
Это же достаточно серьезный проект.

ndch

И к чему это? Закономерности сжатия мне вполне известны и такое вполне вероятно сделать, и уже сделано в фа - тта - но он жмёт аудио не особо хорошо. Именно поэтому я прошу осуществить такое в фа с более сильным алгоритмом. Фа это лучший архиватор по степени сжатия/скорости распаковки, но, увы, аудио он жмёт плохо.

Цитата:

число linux-пользователей крайне мало

дык потому и мало, что нет 64-битной версии!
кто ж систему ради архиватора на 32 бита менять захочет?

Цитата:

когда буду делать win64 версию

буду надеяться, что это время всё же настанет

Цитата:

Если это априори невозможно, почему тогда такой абсурд
выкладывают?

какбэ намекают. чем ближе к нулю спресуешь, тем ближе к цифре 50к отвалится академика Павлова и его труды никто не отменял)