» FreeArc (часть 4)

сейчас переделываю FA чтобы данные паковались с precomp 0.4.3. вроде единственное изменение в нём по сранению с 0.4.2 - то что вместо опции -c- надо использовать -cn? как вообще эта версия - не стала менее надёжной чем прежняя?

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

Bulat_Ziganshin
Нужно будет держать рядом precomp042.exe и precomp043.exe или просто заменить первый вторым?

Sergey_Advisor

1. А без восстановления с опцией -mx на 9 ГБ у Вас что получается?
Это же уйма времени! (1 час?)

2. Не пробовали что-нибудь типа -m82...-m83
http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=760#6
Временные файлы в этих методах не создаются.

Skif_off
паковаться будет теперь версией 0.4.3. для распаковки архивов созданных прежде нужна будет версия 0.4.2. freearc будет включать обе версии precomp.exe; в архив записывается какая версия precomp использовалась для сжатия, так что нужная для распаковки версия будет выбираться автоматически

вот как будет выглядеть новый arc.ini:

precompj = precomp043:cn
...

[External compressor:precomp042,precomp043]
mem = 2
packcmd = {compressor} {options} -o$$arcpackedfile$$.tmp $$arcdatafile$$.tmp
unpackcmd = {compressor} -o$$arcdatafile$$.tmp -r $$arcpackedfile$$.tmp

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

Всем привет. Я к вам обращаюсь с вопросом, касается сжатию. Я делаю репак на Crysis, использую скрипт от Механиков, а во время установки вылезает ошибка.
Вот скриншот: http://www.pictureshack.ru/view_32821_Bezymyannyi.jpg
Дайте исправленный arc.ini или другой файл, чтобы этот алгоритм работал. Заранее спасибо. Жду ответа!
И еще сам скрипт на всякий случай: http://repacks.org.ua/inno-setup/skripty/75-dino-crisis-mexaniki-ot-shopack98.html

anton210896
вы серьёзно полагаете что механики опубликовали нерабочий комплект?

Цитата:

понятно. а вот например в 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

Bulat_Ziganshin
В файле по ссылке http://repacks.org.ua/inno-setup/skripty/75-dino-crisis-mexaniki-ot-shopack98.html есть архив Data.arc, при попытке распаковать получаю ошибку

Цитата:

user error (Unsupported compression methop or error in parameters: precomp)

FreeArc крайняя альфа.
В Mulitarc ошибка

Цитата:

Executed command ... returned errorlevel 1 бла-бла, проверьте конфигурацию

errorlevel 1, так понимаю - Some error when (de)compressing.
В чем может быть дело?

Время там 1,5 часа меня устраивает.
С временным файлом я разобрался - перекинул его на диск с NTFS, но все равно осадочек остался.
А вот почему добавление кода для восстановления упирается в память мне не понятно - ведь код добавляться по верх основного архива и по идее степень сжатия основного архива ни как влиять не должна. С -mx -ld800 код все таки добавился.

Цитата:

Unsupported compression methop or error in parameters: precomp

такого метода в fa действительно нет, обращайтесь к создателю архива

Булат, а как бы к вам в статистику попасть ?
Тут на днях побывал на сервере с 70 Гб памяти, хотел украсить вашу статистику

Дополнительная инфа:
скопировал все из \include в \bin - ошибка при запуске precomp.exe:

Код: Сигнатура проблемы:
Имя события проблемы:    APPCRASH
Имя приложения:    precomp.exe
Версия приложения:    0.0.0.0
Отметка времени приложения:    4d0fc462
Имя модуля с ошибкой:    packJPG_DLL.dll
Версия модуля с ошибкой:    0.2.1.0
Отметка времени модуля с ошибкой:    4e900bc9
Код исключения:    c0000005
Смещение исключения:    00001d55

скажите пожалуйста, каждый раз при включенном прекомпе в ФА когда начинаю жать файл то прогрессбар останавливается на 10%, это понятно, что ФА извлекает файлы во временную директорию, но можно ли с этим как-то бороться? И еще, когда пережимаю существующий архив, при включенном срепе прогрессбар постоянно доходя до 99% падает на ~ 95 и опять, и так пока не закончится процесс, возможно я жму реправильно, пользую пока встроенные методы в ФА ибо пока не силен в составлении собственных цепочек )))

Цитата:

сейчас переделываю FA чтобы данные паковались с precomp 0.4.3. вроде единственное изменение в нём по сранению с 0.4.2 - то что вместо опции -c- надо использовать -cn? как вообще эта версия - не стала менее надёжной чем прежняя?

Изменение синтаксиса - это лишь малая часть отличий версии 0.4.3 от 0.4.2.
Версия 043 скомпилена статически и представляет теперь один exe файл, так что меньше размер и нет проблем с возможными конфликтами из-за файлов packjpg_dll.dll и zlib1.dll (хотя для некоторых целей это не гуд).
Движок PackJPG обновлен с 2.4wip4 до 2.5a и как следствие меньше глюков при включеной обработке JPEG. Пофиксен баг с GIF файлами, когда например на vm.dll найденые GIF файлы раздувались в temp файлы размером под 4 Гб.
Разные фиксы и улучшения, типа возможности нескольким копиям Precomp работать на одном файле, сохранении корректного имени файла в заголовке (раньше всё хранилось в lower case) и др и пр.
Но самый вкусный момент это скорость.
Fallout - Textures.bsa + Fallout - Textures2.bsa (Fallout NV)
RAMDisk (ImDisk -awe)


Код: 0.4.2 -intense -c- 727 sec.
0.4.3 -intense -cn 581 sec. <- 20% быстрее

Цитата:

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

Намек понят.

Расшифруйте пожалуйста, сколько реальной памяти понадобится для распаковки при таких параметрах:
1.rep:256mb+4x4:t2:i0:lzma:64mb:h64m:normal:bt4:128
2.rep:256mb+lzma:64mb:h64m:normal:bt4:128

Цитата:

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

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

hammerxp1
256 мб. без tempfiles - 256+132 и 256+64 мб, соответственно

Highpass
спасибо!

Цитата:

srep:mem256mb это размер словаря? если да то в каких пределах его можно указывать?  

нет. это размер буфера озу используемый при распаковке, в истории srep довольно подробно описана его работа: http://freearc.org/history/changelog_full_ru.htm


Цитата:

не лучше было бы сделать этот процесс следующим образом:
1) прекомпом обрабатывается каждый нужный файл отдельно
2) далее идет упаковки lzma

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


Цитата:

предложение разбивать временный файл на меньше 4ГБ для FAT в силе.

согласен, не помешает, добавил с низким приоритетом


Цитата:

Булат, а как бы к вам в статистику попасть ?
Тут на днях побывал на сервере с 70 Гб памяти, хотел украсить вашу статистику

там и 128 гб было, просто эта статистика за последнюю неделю только. попасть просто - при проверке новой версии инфа о машине отсылается, а страница обновляется в 0:00 по гринвичу


Цитата:

скажите пожалуйста, каждый раз при включенном прекомпе в ФА когда начинаю жать файл то прогрессбар останавливается на 10%

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

Цитата:

256 мб. без tempfiles - 256+132 и 256+64 мб, соответственно

Тогда не понимаю почему в виртуальной машине с количеством процессоров > 1, имея физически 1gb памяти, свободной >512, unarc.dll вылетает с ошибкой по чтению записи памяти, а unarc.exe говорит о нехватке памяти?
Или 256+132 это сколько требуется памяти на поток? Потому что если выставить одноядерный процессор то всё работает.
Без параметра 4x4 всё отлично, но с моим количеством обрабатываемых данных (около 40гб) не хватает скорости, а 4x4 дает ускорение при распаковке минимум в 2 раза.
Пока что перешёл на эксперименты с rep:256+tor:15, разница в размере получаемого архива не такая значительная, зато скорость распаковки почти в 2 раза выше. Кстати tor:16 при упаковке тоже не хватает памяти.

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

спасибо, а можно узнать, я сделал репак и сделал не 3-4 тома а 8-10 томов с упакованными данными? Это как-нибудь влияет на распаковку или вообще на что-то влияет?

Shud поднял тему прогресс-бара, хочу высказаться.

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

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

Другие предложения:
1) Мне очень не нравятся пустые места между параметрами и значениями. (Time-много-пустого-места-0:12).
2) Больная часть исходных данных, по моему мнению не нужна. Количество файлов смело можно выкидывать, с этой информацией ничего не поделаешь (не остановится же пользователь посередине архива, достигнув магического числа). Текущий размер во время обработки выкидываем по той же причине. Также не вижу, зачем нужен размер информации (исходный и обработанный), роль заменяется процентом.
3) Размер лучше показывать во МБ с двумя знаками после запятой. Кстати, можно спросить, почему у мегабайта маленькая 'm'? Вики использует большую. А еще лучше использовать вместо десятичных бинарные приставки, даешь просвещение в массы!
4) Время: меняем формат на 1h 23m; не отображаем секунды, пока не остается меньше минуты; не отображем час, пока не прошёл час. Вместо 'of' можно использовать слэш. Идея из uTorrent.
5) Заголовок: я бы поменял вертикальныю черту на слэш. Но это на усмотрение, у меня какая-то нелюбовь к этому знаку. Еще можно поставить разделитель между процентом и временем.



Вместо жирности можно использовать различие размеров шрифта, сейчас это модно, и смотрится неплохо.


Добавлено:
По поводу набора команд в меню Explorer. Некоторы предложения для строк.

1) Выкиньте 'the selected files' -- файловое меню не показывается при отсутствии выделенных файлов
2) 'using Freearc' -> '(Freearc)', или 'with Freearc', 'via Freearc' (сэкономит целый симбол в меню); еще лучше совсем Freearc выкинуть, как в меню 7-Zip. Мы же все равно рассчитываем, что Freearc в скором будущем станет единственный архиватором на машинах пользователей
3) '... via dialog', 'Extract, Test with Freearc' -> Compress, Open, Extract, Test archive (tnx 7-Zip).
4) 'Extract to a folder', 'Extract here'.


Добавлено:
В голову пришла еще одна замечательнаяы идея. Вчера смотрел видео на ted.com, понравилось как у них время отображается по краям на прогресс-баре. Идею с легкостью можно перенести и сюда.

Прогресс = Обработано данных/ Всего данных
Всего времени = Прошло времени * (Всего данных/Обработано данных)
Прошло времени / Всего времени = Обработано данных / Всего данных

Превьюшка с метро-дизайном


Добавлено:
И в дробных числах лучше использовать точку, я не запятую.

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 для сверхбыстрого сжатия

UbiSergei
Первый бар (в моем предложении) - "процент" выполненой работы (в целом, а не по файлам!)
Второй бар - размер "архива", т.е. показатель "эффективности" работы!

Цитата:

Попытка добавить к архиву (2ГБ) информацию для восстановления приводит к сообщению: malloc: resource exhausted (out of memory).

спасибо за баг-репорт. при добавлении RR надо снять галочку с режима сжатия, иначе freearc ещё и перепаковывает архив. именно поэтому ему не хватает памяти - 1600 мб для распаковки старого алгоритма, ещё столько же для упаковки новым


Цитата:

спасибо, а можно узнать, я сделал репак и сделал не 3-4 тома а 8-10 томов

а что за тома? freearc многотомность не поддерживает

Shuld
Значит второй бар просто показывает коэфициент сжатия, понятно. Как обидно это было бы не говорить, но надобности в нем тоже не вижу: на протяжении процесса жизни ратио колеблется слабо. Бары для вещей у которых есть начало и конец, ратио же почти постоянен.

Это же идея из винрара? Похоже, что авторы изначально не продумали концепцию.

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

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