» FreeArc (часть 4)

Извиняюсь, помогите решить проблему, надо распаковать архив bin 1.2 гигабайт. Но FreeArc его не распаковывает, жалуясь что то там can't allocate память и распаковку прекращает. Он требует вроде 1gb свободной памяти, но столько свободной нету. Я пробовал распаковывать с ключом -lc, но всё равно так же жалуется. А по одному файлу он всё таки распаковывает, файлов только много, так не удобно. help

Paramon111
Речь идет об юзабилити FA и о том, что если сознательно отмечать опцию, то привыкшие к 7-zip и WinRAR юзеры тоже заметят этот момент в FA.

Bulat_Ziganshin

Тема уже не раз поднималась, но нормальной альтернативы унылому TTA для сжатия аудио в фа так и не нашлось. Оптимальным конечно бы был TAK, но его исходников до сих пор нету. Но есть еще 1 хороший алгоритм - OptimFrog - который на максимальных настройках жмёт аудио чуть сильнее ТАК'а, но медленнее. Поскольку это больше касается сжатия, тк разжатие происходит быстрее, то я осмелился бы попросить вшить OptimFrog в фа как некую альтернативу ТТА, у которого сжатие сильно отстаёт от этих алгоритмов.

З.Ы.
Заметил еще в новых репаках некий msc с которым хорошо жмётся аудио, но пока понятия не имею что это такое, тк оно идёт с CLS-фильтром который профрагер еще не выложил (и хз выложит ли).

Цитата:

у меня, что на работе, что дома, ВСЕГДА без деления на группы получается лучше.

ну например возьми группу obj-файлов сожми. вообще, какие у тебя файлы в группу obj попадают?


Цитата:

надо распаковать архив bin 1.2 гигабайт. Но FreeArc его не распаковывает, жалуясь что то там can't allocate память и распаковку прекращает. Он требует вроде 1gb свободной памяти,

распакуй на другой машине, желательно с 64-битной ОС. какое значение на последней закладке в Settings? что даёт arc lt на этом файле?

Хочу обратить внимание Булата на такой недочёт в GUI: если ставишь галочку "precomp", а уровень сжатия выбран ниже Maximum, то precomp использован не будет, что мягко говоря не очевидно для пользователя. Нельзя ли сделать так, чтобы буква "p" добавлялась сама, если выбран хотя бы один внешний компрессор?

1noObman1
Кроме унылого TTA есть неунылый FLAC, с фичей проигрывания произвольного места аудиофайла (streaming).
Те кто "качают" по полгига музыки в состоянии "покачать" на 10 секунд дольше
(разница между TTA и FLAC 650мб*((58,70%-57,10%)/100)=4 Мб)
Но зато после этого слушать с возможностью "промотки".

http://wiki.hydrogenaudio.org/index.php?title=Lossless_comparison#TTA_pros

OptimFROG (OFR)
OFR cons
Closed source
No multichannel audio support
No hardware support
Quite slow decoding

vishyakov
Присоединяюсь. А еще хотелось бы напомнить сделать выгрузку выбранных параметров в .bat\.cmd файлы.
С уважением.

Цитата:

ну например возьми группу obj-файлов сожми. вообще, какие у тебя файлы в группу obj попадают?

Поясняю.
Те папки, которые я беру для тестирования - все мои реальные, для которых мне как раз и нужна резервная копия, и собственно архиватор.
Мне не интересно экспериментировать на фильмах, музыке и т.п. что мне не нужно.
А мои реальные папки, как ни странно (!) содержат файлы из Excel, Word, Компаса и Корела, PDF, rar, zip, и т.п.
И это не должно быть удивительно. (в группе obj наверное ничего нет)

Цитата:

понятно. а вот например в arc можно передавать еще такие типы:
xz/wim/gzip/bzip2/tar

fa поддерживает все типы архивов, поддерживаемые 7z.dll


Цитата:

Отмечаю опцию "Сделать ЕХЕ"  -->  "Выходной архив" так и остается price.arc
Это возможно исправить?

записал на будущее


Цитата:

Если, не начиная Упаковки (не нажать на Ок. диалога упаковки), снова зайти по кнопке "..." ) - видим что "Уровень сжатия" - Нормальное  и галочка "precomp" не отмечена    ------>  нажимаем Ок  - но Строка сжатия  так и осталась  Максимальное: -mx -mc$default,$obj:+precomp  

1. когда ты заходишь в этот диалог, все настройки сбрасываются на стандартные, но при этом строка наверху остаётся старая
2. когда ты меняешь в нём хоть одну опцию, строка наверху формируется заново на базе отмеченных опций
3. в диалог Add передаётся строка сверху


Цитата:

Ну да. Добавлено содержание arc-lzma-x64-filter.ini. На lzma x32 таких выкрутасов никогда не замечал. Такую ошибку выдает только lzma x64.

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

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



Цитата:

если ставишь галочку "precomp", а уровень сжатия выбран ниже Maximum, то precomp использован не будет

неправда. создаётся опция типа -m4 -mc$default,$obj:+precomp и как нетрудно проверить, она использует precomp: [more]C:\>arc a KEmulator -m4 -mc$default,$obj:+precomp -di
Creating archive: a.arc using precomp042:c-:t-j+rep:96mb:96:c16:d4mb:s32+exe+delta+4x4:lzma:16mb:h4mb:normal:24:mc8, $obj => precomp042:c-:t-j+rep:96mb:96:c16:d4mb:s32+delta+4x4:lzma:16mb:h4mb
:normal:24:mc8, $text => grzip:8mb:m1:l32:h15, $compressed => rep:96mb:96:c16:d4mb:s32+4x4:tor:16mb:c3, $wav => tta, $bmp => mm+grzip:8mb:m1:l2048:h15:a
....

C:\>arc lt KEmulator.arc
Pos Size Compressed Files Method
-----------------------------------------------------------------------------
31 0 0 42 storing
31 157,123 16,476 27 grzip:156kb:m1:l32:h15
16,507 39,491,164 8,895,549 115 precomp042:c-:t-j+rep:96mb:96:d4mb:s32+exe+delta+4x4:lzma:16mb:h4mb:normal:24:mc8
8,912,056 2,848,985 2,650,853 3 rep:2811kb:96:d4mb:s32+4x4:tor:2811kb:c3
-----------------------------------------------------------------------------
187 files, 42,497,272 bytes, 11,562,878 compressed
[/more]


Цитата:

Нельзя ли сделать так, чтобы буква "p" добавлялась сама

я здесь сделал по-другому - не через добавление буквы 'p', а через -mc. просто в качестве эксперимента


snkreg
ok

ndch

Ну меня интересует сжатие, а флак не настолько сильно жмёт как ТАК и OptimFrog. Да и насколько я знаю его тоже нету в фа. Интересует именно вшитый алгоритм, а не отдельные тулзы (с этим проблем и так нет).

Добавлено:

Цитата:

OptimFROG (OFR)
OFR cons
Closed source

На его странице есть сдк.

Цитата:

Bulat_Ziganshin распакуй на другой машине, желательно с 64-битной ОС. какое значение на последней закладке в Settings? что даёт arc lt на этом файле?

На другом компьютере можно было бы тоже попробовать, но пока надо на этом распаковать. На последней вкладке значится 1298mb. arc lt не знаю, попробую.

ndch
смысл отображения скорости сжатия в том, что когда подбираешь оптимальный алгоритм сжатия
то сразу видишь его скорость, когда как сейчас скорость пишется в конце упаковки/распаковки
(сейчас ориентируюсь на показатель оставшегося времени)
память не нужна, так как примерно максимально потребляемое уже покажется

1noObman1
TAK есть исходник на Pascal, по крайне мере исходник сжатия потока (takStream.pas)
идет вместе

FreeArc 67a всё тки распаковал с ключом -lc300m

Цитата:

а из-за таких пустопорожних багрепортов я трачу время и пропускаю реальные баги

Намек понят.

Цитата:

TAK есть исходник на Pascal, по крайне мере исходник сжатия потока (takStream.pas)
идет вместе

Уже радует, но не факт что булат станет переписывать его с паскаля...

Bulat_Ziganshin
Не знаю, но вроде баг:
Метод rep неправильно пакует cab архивы, если использовать его без дополнительных методов. На выходе получается архив с содержимым cab архива (первого обрабатываемого, если их несколько).
Как ни странно, такой архив даже открывается 7-zip'ом. В свойствах 7-zip и FA показывают, что это cab архив.

Тестировал на версии 0.67a (18.03.2011)

Цитата:

опция типа -m4 -mc$default,$obj:+precomp и как нетрудно проверить, она использует precomp

Ну так я проверил - precomp не используется. А если добавить букву "p", то используется. На последней альфе. Сделать видео?

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

Добавлено:
kalpak

Цитата:

когда подбираешь оптимальный алгоритм сжатия то сразу видишь его скорость

Тогда уж график просите с указанием сжимаемых файлов, чего мелочится то ?

byExit

Цитата:

Не знаю, но вроде баг:
Метод rep неправильно пакует cab архивы, если использовать его без дополнительных методов. На выходе получается архив с содержимым cab архива (первого обрабатываемого, если их несколько).

Распаковывается нормально? Значит это не баг, а фича.

Подскажите,как в командной строке запаковать ZIP windows стандартный,без установления rar,zip? на vbs есть,но я хочу что бы через cmd,Спасибо за помощь

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


Цитата:

(сейчас ориентируюсь на показатель оставшегося времени)

ты может не в курсе, но freearc.exe поддерживает комстроку точно так же как arc.exe. попробуй:

freearc.exe a a


Цитата:

кстати а можно для CUI сделать в заголовке или где то еще чтобы также как в GUI скорость сжатия отображалась

слишком специфичная вещью. можно было бы подумать о колбаке в lua или просто опции "шаблон заголовка окна", в которой это можно настроить

byExit
1. создаваемый архив содержит в себе куски исходных данных, скопированные без изменений - это особенность REP
2. 7-zip распознаёт такой архив как имеющий тип .cab, поскольку он видит cab-заголовок, и не способен распознать структуру .arc
3. старый freearc тоже распознавал это как cab-архив. эта оишбка была исправлена как раз в марте. если маротовсrbq fa неправильно распознаёт архив - пришли его мне. я посмотрю

new alpha version:lz4: new, fastest compression method (and xlz4 to utilize all cores)
xlzma: reduced memory usage for compression
xppmd: restored multi-threading support
4x4, grzip: fixed bugs in reporting memory usage, limiting memory usage and reporting (de)compression progress
Before releasing 0.70, i should fix plenty of bugs. This time, i worked around multithreading compression issues. Also i've added LZ4 method in order to explore freearc's inner limits to fastest compression


Новая альфа-версия:lz4: новый, самый быстрый метод сжатия (плюс многопоточный xlz4)
xlzma: уменьшено использование памяти при сжатии
xppmd: восстановлена многопоточная работа
4x4, grzip: исправлены ошибки в вычислении требуемой памяти, ограничении потребления памяти и отображении прогресса операции
До релиза 0.70 мне предстоит исправить кучу ошибок. В этот раз я сосредоточился на проблемах в многопоточной упаковке, а также добавил LZ4 чтобы исследовать внутренние ограничения freeac для сверхбыстрого сжатия

1noObman1

Цитата:

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

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

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

Вопрос про многопоточность

Если взять метод сжатия (лежит в основе метода -mex6):
1) -mrep:256mb+4x4:lzma:8mb:h16mb:max
и его варианты
2) -mrep:256mb+4x4:t3:lzma:8mb:h16mb:max
3) -mrep:256mb+4x4:t2:lzma:8mb:h16mb:max

то получается:
time memory
cpu real compression decompression
1) 1052s 266.5s 740mb 368mb
2) 1042s 265.7s 643mb 349mb
3) 976s 290.0s 546mb 330mb
Размер архива во всех случаях идентичен - 1 254 171 009 байт.

Вопрос:
Почему время сжатия в три потока :t3: примерно такое же, как в случае четыре потока?
У меня такое проявляется всегда, плюс/минус погрешность.
Процессор i3-530 (2 ядерный, 4 поточный), Win7 32-разрядная, ОЗУ 4 ГБ
Это особенность 2-ядерного процессора? И на настоящих 4-ядерных такого нет?
Кто ответит?

Загрузка процессора в 4 и 3 потока - 100%, в 2 потока - около 85%.
(Получается, что на таких процессорах, как мой, удобнее архивировать в три потока - меньше требуется памяти. Жаль, FreeArc этого не знает)

А что за зверь lz4?
http://fastcompression.blogspot.com/p/lz4.html
?

Попробуем, сравним.
Что-то не пишут, он что, быстрее tornado?

Цитата:

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

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


Цитата:

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

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

Добавлено:

Цитата:

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

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

Shuld
по сравнению с tor:1 он и быстрее, и жмёт лучше. вот здесь например можешь глянуть: http://encode.ru/threads/1591-zpaq-benchmarks

вообще за исключением quicklz, это лучший из максимально быстрых алгоритмов. другое дело, какой в них смысл - в freearc xlz4 упирается в скорость не самого lz4, а того треда архиватора, который читает данные и вычисляет их crc

У меня такой вопрос: я не дуб в программировании, но в этой программе вообще ничё понять не могу... У меня стоит win 7 x64... Упаковывая ёмкий (порядка 16 Гб изначальных файлов) инсталлятор стандартными средствами inoo setup, все архивы создавались с ошибками, думал, что в freearc их не будет, но нет,тоже выдаёт ошибку, что архив был повреждён при упаковке и там что-то в духе lzma написано и т.п. Я решил попробовать воспользоваться LZMA-x64 в папке Addons, но не понял, как его встроить и пользоваться им. Объясните, как его встроить, стандартный readme не помог и с чем всё-таки могут быть связаны ошибки при упаковке?...

1noObman1

Цитата:

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

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


Цитата:

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

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