» FreeArc (часть 4)

Цитата:

Всё, разобрался. Оказывается, чтобы увидеть сообщение об ошибке, надо раскрыть комбобокс...

а вот это ошибка. при появлении ошибок он сам должен раскрываться

---

это жесть. сегодня получил письмо, причём с отметкой urgent:


Цитата:

Здравствуйте, Булат.
Спасибо вам за добротный архиватор FreeArc.
Для многих моих задач он подходит.

Однако у меня есть ещё вполне практическая задача, с которой ваш архиватор НЕ справился, даже со специальными опциями, в частности –tp3.
Для меня она очень важна.
Речь идёт о распаковке записей спортивных соревнований с телевизора Sony Bravia.

Файлы сохраняются на внешнем жёстком диске в сжатом виде, предположительно, с помощью алгоритма LZ77.
Об этом я сделал вывод, скачав в Интернете файлы обновления ПО для этого телевизора (см. папка “crypto”).

Поэтому я прошу вас как специалиста в данной сфере помощи – хотя бы направьте мои усилия в правильном направлении.

В Приложении к этому письму есть архив с папкой “crypto”, 2 короткими записями видео в MPEG-2 , 2 ENC-файла, возможно, нужные для распаковки (они также были на внешнем диске).

Надо было закончить пост вот так:
"P.S. Телевизор не мой, я просто разместил объяву")
Кстати, планировал брать Sony, но если сабж не распаковывает записи спорт.соревнований - я буду вынужден вернуть с дачи старый Фотон 51ТЦ-408Д.
А если по делу - хотел спросить. Не планируется ли интеграция последнего SREPа и детальная настройка SFX модулей?

я не знаю как фриарк включить в скрипт мож кто-нибудь поможет?

Цитата:

Однако у меня есть ещё вполне практическая задача, с которой ваш архиватор НЕ справился, даже со специальными опциями

Да, это жесть...

Bulat_Ziganshin

Цитата:

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

Идея понятна.
Но у меня, что на работе, что дома, ВСЕГДА без деления на группы получается лучше. И пока ни разу - наоборот! Что меня очень удивляет!
Вы не пробовали проверить и сравнить мой альтернативный вариант на своих данных?

А может быть, кто из пользователей сравнит и напишет, как получается?

Rep и быстрые tor (tor:3)
Предварительные результаты

В новой версии архиватора FreeArc от 6.02.2012 значительно изменился rep и появились новые настройки. Выкладываю предварительные результаты тестирования этих настроек.

1.    Показательно изменение параметра «l» при неизменных остальных.

Пример 1: –mrep:1g:…:c64+xtor:3:4m:h128k, где многоточием обозначен изменяемый параметр.
Rep:1g размер Время, с

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

Какой исходный объем и сжатый?

Цитата:

Не планируется ли интеграция последнего SREPа и детальная настройка SFX модулей?

интеграция на уровне включения srep.exe в дистрибутив freearc и опции для его использования - уже есть. на уровне включения распаковщика srep:f в код arc/unarc/afx - возможно сделаю, но это будет временное решение как нынешний dispack. в конечном счёте планируется сделать srep внутренним методов freearc, но даже в альфе это появится лишь через несколько месяцев

детальная настройка SFX модулей - считаю её низкоприоритетной, поскольку есть innosetup и даже генераторы программ под него

Добавлено:
Shuld
1. надеюсь, теперь проверка идёт полностью в озу
2. вместо сжатия папки лучше брать один файл (объединить свои файлы вместе, учитывая порядок сортировки при -m1 и при других методах)
3. fa использует rep:96m
4. помимо использованных тобой вариантов, интерес представляют 128:c128, 64:c64 и т.д.
5. что касается оптимальности - такое ощущение, что ты скорее искал точку перегиба точных данных ты не привёл (советую делать тиблицу хотя бы под тегом more), но на глаз это выглядит так - 128:c128 процентов на 5 быстрее и жмёт на 0.2-0.5% хуже чем 64:c32. при таких условиях я выберу 128:c128

вообще в новой альфе не только новый rep, но и новые настройки rep для m1-m4. в быстрых методах используется l==с потому, что я счёт это более выгодным

ситуация вообще такая - скорость rep определяется в основном параметром C - это куски, на которые разбивается входной файл и среди них ищутся совпадения. из найденных совпадений отбрасываются те, длина которых меньше L. поэтому скорость вырастает при большом C, а при равных C большой L её даже чуть снижает - мы проверяем всё те же совпадения, затем часть из них отбрасываем, и приходится обрабатывать эти данные снова. поэтому для быстрых режимов лучше l==с - тут нет смысла разбрасываться уже найденными матчами, поскольку снижение "проходного барьера" L только улучшает общий результат

разные L и С имеют смысл при использовании перед lzma:max, например - нам наплевать на время и мы хотим найти все или почти все совпадения длиной от 512 байт. тогда мы разбиваем файл на куски по 128 байт и через такой частый бредень почти ни один интересующий нас матч не проскользнёт

для более быстрых и менее аккуратных методов сжатия (начиная с 4x4:lzma) нас интересуют совпадения меньшей длины и можно ставить хоть l32. проблема в том, что это может оказаться довольно медленно, т.е. ограничением выступает уже скорость rep. поэтому в -m1 я использую 256:c256 и т.д. неагрессивность этих настроек исходит из принципа "не навреди"

ps: получился небольшой rep:faq

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

Цитата:

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

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


Цитата:

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

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

1. Где взять последний fazip?
2. Не умею
3. Да, знаю, что rep:96m.
4-5. Штука в том, что
метод –mrep:...:256:c256+xtor:3:4m:h256k уступит методу –mrep:...:64:c32+xtor:3:4m:h128k
и далее
–mrep:...:256:c256+xtor:3:4m:h128k уступит методу –mrep:...:64:c32+xtor:3:4m:h64k

Добавлено:
Поэтому параметры типа 256:c256, 128:c128, 64:c64 не имеет смысла использовать нигде, кроме самого первого, быстрого метода!!!

Добавлено:
Грубо говоря, параметры 256:c256, 128:c128, 64:c64 можно использовать только с tor:3:...:h64k и нигде больше!!!

Цитата:

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

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

Цитата:

freearc.exe при архивировании с удалением файлов, иногда не выдает ошибки (в логе пишет "архив успешно создан"), удаляет что может (могут остаться пустые папки), но не переименовывает freearc1.tmp в "имя_архива.arc".
Возможно ли сделать удаление после переименования и с каким-нибудь прогресс-баром?  

http://code.google.com/p/freearc/issues/detail?id=291

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

Добавлено:

Цитата:

–mrep:...:256:c256+xtor:3:4m:h128k уступит методу –mrep:...:64:c32+xtor:3:4m:h64k  

по сжатию - уступит на доли процента, по скорости - превзойдёт


Добавлено:
http://freearc.org/download/testing/fazip02.zip

Цитата:

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

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

Shuld

Цитата:

2. Не умею

Учитесь Все уже давно есть, нужно было поискать по форуму:
http://freearc.org/download/testdata/dll100.7z
http://freearc.org/download/testdata/dll700.7z

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

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

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

Добрый день, Bulat_Ziganshin

Цитата:

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

К сожалению, после архивации в GUI уже однажды удалил freearc1.tmp, не посмотрев, что он стер все кроме пустой папки. Посчитал, что из-за ошибки прервалась именно архивация и попробовал сжать еще раз.
Проблема в том, что в GUI при ошибке удаления он выводит сообщение только в логе полном (идентичном логу консольной версии). В кратком (который подстрочный в главном окне) указывается, что все в порядке. И окно архивации тоже закрывается без всяких предупреждений.
Пример: [more=лог полный (options>view logfile)].
C:\Program Files\freearc\bin>FreeArc a -tarc -m4 -rr -t -d -dpD:\Program -- D:\Program\screamer.arc screamer\
FreeArc 0.67 (February 5 2012) Using additional options: --logfile=C:\Program Files\freearc\freearc.log
Creating archive: D:\Program\screamer.arc using rep:96mb:96:c16:d4mb:s32+exe+delta+4x4:lzma:16mb:h4mb:normal:24:mc8, $obj => 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
Memory for compression 312mb, decompression 308mb, cache 16mb
Compressed 49 files, 5,791,784 => 2,063,831 bytes. Ratio 35.6%
Compression time: cpu 7.16 secs, real 5.94 secs. Speed 974 kB/s
Protecting archive with 9 recovery sectors (18 kbytes)...
9 recovery sectors (18 kbytes) present
Scanning archive for damages...
Archive integrity OK
Testing time: cpu 0.73 secs, real 1.01 secs. Speed 5,740 kB/s
Deleting successfully archived files
Keeping temporary archive D:\Program\freearc1.tmp

D:\Program\screamer\icons: rmdir: permission denied (Permission denied)[/more] [more=лог краткий]
17:49:03 Creating archive D:\Program\screamer.arc
17:49:11 SUCCESFULY TESTED D:\Program\freearc1.tmp
17:49:11 SUCCESFULY CREATED D:\Program\screamer.arc
[/more]

В консольной версии хоть "|| (echo ERROR && pause)" прицепить можно... но тогда лучше без удаления, с "&& rd /q /s".

byExit

Цитата:

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

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

Alex_Piggy
ясно. спасибо, буду разбираться

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

Вроде баг в unarc.dll: если указанный архив не найден или не является архивом, то бесконечно начинает вызываться event("error", -14, 0, "ERROR: this is not FreeArc archive or this archive is co
rrupt")

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

Если взять метод сжатия (лежит в основе метода -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 этого не знает)

не могу разобраться с командной строкой...
набрал код
Arc a -u Pak1.zip Pak.zip "media"
но в итоге у меня Pak.zip и папка media упаковываются в один Pak1.zip...

короче мне бы получить:
1. папку media запихнуть в уже существующий zip-архив, заменив совпадающие файлы
т.е. желательно без распаковки\запаковки архивов
2. и как в ISdone это же прописать без ком. строки?

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

1.
copy pak.zip pak1.zip
arc -tzip pak1.zip media
2. "isdone" в шапке

Здравствуйте.
Подскажите пожалуйста, почему когда я создаю архив через диалог, в графе сжатие прописываю например "precomp+delta+srep:a1+lzma:d260m:a1:mfbt4:fb273:lc8", то создание архива не завершается, время только увеличивается. Даже файлы в пару КБ стопарятся на определенном проценте (процент зависит от размера файла).
Дело явно в precomp...
Спасибо за разъяснения.

Проблема решена - оказалась битой одна плашка оперативки...

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