» FreeArc (часть 4)

Новая альфа:-m5 на бинарных данных теперь работает значительно быстрее за счёт использования всех ядер CPU
-m2..-m4: сжатие на бинарных данных значительно улучшено (исправлена ошибка, появившаяся в версии от 22.08.2012)
-m1..-m5 и все -mex мгновенно обрабатывают уже сжатые данные (см. изменения в 4x4 ниже)
поддерживается выделение памяти Большими Страницами (4МБ), что увеличивает скорость на 10% (но к сожалению, БС обычно доступны только сразу после перезагрузки ОС)LZMA:HT4 теперь поддерживает словари размером до 2 ГБ
увеличена степень сжатия со словарём в 1 ГБ
предвыборка памяти и мульти-сканирование в BT4/HT4 -> увеличение скорости до 20%
для HT4 параметр MaxChain (:mc) по умолчанию теперь равен FastBytes/2 (:fb/2)Tornado:
новые методы сжатия с оптимальным парсингом tor:11..tor:16 и параметры :x :s :fb
поддержка значений :l, не являющихся степенью 2, в режимах tor:5..tor:16
см. сообщение о выходе Tornado 0.6 для доп. информации о новых возможностях4x4:быстрая обработка уже сжатых данных - они просто копируются в выходной файл со скоростью 1 ГБ/с
для этого каждый блок данных сначала проверяется на order-0 сжатие и если его коэффициент >99% - данные передаются без упаковки
настройка: параметр :r0 означает "не проверять и всегда пытаться сжать данные", :r99.5 означает "пропускать упаковку если коэффициент order-0 сжатия >99.5%"

---

New alpha version:-m5 binary compression made much faster by employing all CPU cores
-m2..-m4 binary compression ratio is significatly improved (fixed bug made in the Aug22/2012 version)
-m1..-m5 and -mex modes process incompressible data at 1 GB/sec speed (see 4x4 updates below)
Large Memory Pages (4MB) allocated if possible, improving speed by 10% (unfortunately, LP are usually available only immediately after OS restart)LZMA:HT4 now supports dictionaries up to 2 GB
improved compression ratio for 1 GB dictionary
prefetching and multi-scanning in BT4/HT4 matchfinders - up to 20% faster
default MaxChain (:mc) for HT4 now is FastBytes/2 (:fb/2)Tornado:new tor:11..tor:16 optimal compression modes and :x :s :fb parameters
support for :l values that is not power of 2 in the tor:5..tor:16 modes
see Tornado 0.6 release notes for details4x4:already compressed data now are quickly copied at the 1GB/s speed, because compression of the next block is automatically skipped if order-0 compression ratio of the block is >99%
tunable with :r parameter: :r0 means "always try to compress", :r99.5 means "compress if order-0 ratio is >99.5%"

Как новая альфа? Чего интересного?

egor23
опцию -slp пока не реализовал, поскольку надо её передавать в 7z.dll и facompress.dll. по большому счёту она интересна только бенчмаркерам. а описание - да, надо поправить

Bulat_Ziganshin

Здравствуйте
Как я понимаю Вы автор ?
Скажите пожалуйста почему при достаточном количестве изменения номер версии (пусть это даже альфа) - не меняется ?
Спасибо

Всем привет. Подскажите как через ком. строку распаковать файл *srep в нужной папке? Батник: srep ./DiscContentPC/ -d data.cab data.srep

NeoHunter
главным образом потому что там есть несколько серьёзных проблем которые я всё хочу исправить до выхода релиза

WiperX
srep -d inputDir/data.srep outputDir/data.cab

Булат, спасибо за помощь А есть дока для srep c параметрами ком. строки? И еще вопрос, можно ли при распаковке через unarc отобразить ход выполнения как в Arc (время и проценты)?

WiperX
http://freearc.org/research/SREP.aspx
http://freearc.org/research/SREP39.htm

если непонятно - спрашивай

Добавлено:

Цитата:

можно ли при распаковке через unarc отобразить ход выполнения как в Arc (время и проценты)?

имеется в виду unarc.exe или unarc.dll?

Цитата:

имеется в виду unarc.exe или unarc.dll?

unarc.exe

Цитата:

можно ли при распаковке через unarc отобразить ход выполнения как в Arc (время и проценты)?

есть графический sfx, переиеновываешь его в archive.exe, ложишь рядом с archive.arc и запускаешь archive.exe x -dpDIR (archive.exe -h для помощи)

1. Тут вот, что заметил. Если в arc.ini для внешнего компрессора указать необходимую память для упаковку/распаковки (mem=..., cmem=... dmem=...), то всё равно ОЗУ упаковки/распаковки: 4096 мб.
2. -m=ExternalCompressor1+4x4:ExternalCompressor2, то будет запущено: ExternalCompressor1 и несколько экземпляров ExternalCompressor2 (скорее всего равное количеству ядер), а это не есть хорошо. Предлагаю добавить команду для 4x4, которая бы уменьшала количество запусков ExternalCompressor2 на указанное число.
P.S. Для распаковки ExternalCompressor1 используется stdin/out, CLS.

Edison007007
1. это cls или external?
2. 4x4:t11:... создаёт 11 тредов. другое дело что 4x4:external у меня лично надёжно не работают. да, external compressor в моей терминологии - это именно exe, а не dll. в принципе что-то типа 4x4:t-2 для создания cpu-2 потоков могло бы быть полезным. хотя с жругой стороны - редко когда скорость разных алгоритмов одинакова, так что если у тебя есть ex1+4x4:ex2 - не факт что нужен именно N-1 поток

Цитата:

1. это cls или external?

Здесь походу мой косяк... т.к думал, что инфа об этом есть где-то в архиве

Добавлено:

Цитата:

2. 4x4:t11:... создаёт 11 тредов. другое дело что 4x4:external у меня лично надёжно не работают. да, external compressor в моей терминологии - это именно exe, а не dll. в принципе что-то типа 4x4:t-2 для создания cpu-2 потоков могло бы быть полезным. хотя с жругой стороны - редко когда скорость разных алгоритмов одинакова, так что если у тебя есть ex1+4x4:ex2 - не факт что нужен именно N-1 поток

Например precomp+какой-нибудь CM

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


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

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

все добавления новых пунктов меню делаются после текущего выделенного. описание пункта меню состоит из:

- наименования (выводимой в меню надписи), например "Add to archive {arcname}"
- выполняемой команды, соответственно "freearc a {arcname} {files}"
- галочек - условий включения этого пункта меню (для arc sfx, arc non-sfx, non-arc архивов, не-архивов)

в наименовании команды поддерживается возможность перевода, т.е. её можно написать в виде "0864 Add to archive..." и вместо английского текста будет подставлен соответствующий русский из файла перевода. в наименованиях и выполняемых командах поддерживается макроподстановка имени выделенного файла/создаваемого архива/...

Tornado 0.6a:поддержка FreeBSD, добавленная m^2
исправлены ошибки в режимах -11..16 и -10 -x2*
исправлена ошибка в индикаторе прогресса при распаковке
запрещено использовании опции -t1 с несовместимыми с ней -p4 и -x2*

---

Tornado 0.6a:FreeBSD support developed by m^2
fixed bugs in -11..16 and -10 -x2* modes
fixed bug in the decompression progress indicator code
prohibited use of -t1 with incompatible -p4 and -x2* switches

Bulat_Ziganshin

Про настраиваемый набор команд не подскажу.
А вот к прогресс-диалогу очень хочу вернуться!
Вот здесь это обсуждалось:
http://www.forum.ru-board.com:9000/topic.cgi?forum=5&topic=35164&start=1860#21
на этой и последующих страницах.

Прошло время, и пришло понимание,
что тот вариант, что сейчас (в версии 2013-11-11) мне ужасно не нравится!
Душа лежит к варианту вроде v5.
Но есть и свои соображения.
Я предлагаю вариант 17

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

Добавлено:
PS.
1. Просьба к цифрам не придираться - они не увязаны друг с другом.
2. В WinRAR мне раньше нравилось, но сейчас считаю, что сделано тоже неудачно.
3. Один из неплохих вариантов - winuha.

Возможно, Speed надо перенести в верхнюю часть диалога, поскольку относится к исходным данным.

Добавлено:
Возможно, самый лучший вариант,
разместить Ratio и Speed между прогресс-барами...

Добавлено:
v18



Добавлено:
Почему я предлагаю такие варианты?
Потому, что в прогресс-баре заполненная левая часть обозначает обработанную часть,
а весь прогресс-бар - все целиком.
Поэтому и цифры должны по расположению соответствовать прогресс-бару, а не так как сейчас! (соответствия по расположению нет! Все время надо напрягаться.)

Добавлено:
Если кому понравился мой последний вариант,
прошу - выскажитесь здесь.
И мне будет ясно насколько я одинок или нет, и Булат, может быть, прислушается.
(к одному моему мнению - вряд ли).

Добавлено:
А еще, если как следует подумать, надо убрать в v18 прогноз размера архива.
1. Не соответствует "всей шкале" прогресс-бара - это не размер архива, а размер данных
2. Все архиваторы сначала группируют файлы (по расширениям), и потом сжимают. В результате, при сжатии одной группы файлов, например, rar-файлов, они "прогнозируют" один размер архива, потом, когда дело доходит до .txt, архиваторы "резко" меняют свой прогноз - в общем смысла мало.
Достаточно текущего размера архива и процента сжатия.

Булат, в одной из последних версий ты сделал вот это:
* После выполнения команды "freearc a -t" окно программы не закрывается автоматически

Существует ли дополнительный ключик, чтобы вернуть старое поведение?

coolerru
C:\!FreeArc> arc | grep pause
--pause-before-exit=PAUSE make a PAUSE just before closing program window

ищем в http://freearc.org/history/changelog_full.htm pause-before-exit:

* Added option --pause-before-exit with the following settings:
on – always make a pause
off – never make a pause
on-warnings – make pause if there were any warnings due operation
on-error – if program exits due to error

* Default settings for the option:
off – for console mode
on – for "test" command in GUI mode
on-warnings – for other commands in GUI mode

* In FileManager mode this option is ignored

Добавлено:

Цитата:

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

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

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

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

Прекрасно! Благодарю за подсказку!

Bulat_Ziganshin
А нельзя, раз вы взялись за команды в меню эксплорер, добавить туда команду типа "умной" распаковки? Чтоб, если внутри архива находятся только файлы, они распаковывались бы в каталог с названием архива. А если они уже лежат в каталоге, внутри архива, то распаковывались бы так как есть.

b1745923
постараюсь сделать , но только в следующей версии. можешь здесь подписаться: https://code.google.com/p/freearc/issues/detail?id=116

Добавлено:

Цитата:

от меня давно требовали сделать настраиваемым набор команд в меню Explorer

добавил как https://code.google.com/p/freearc/issues/detail?id=383 , можете подписываться

Добавлено:

Цитата:

Здесь походу мой косяк... т.к думал, что инфа об этом есть где-то в архиве

из информации, выводимой по команде lt, в архиве сохраняется записанное между строчками с "---", а выводимое наверху - высчитывается. и для external алгоритмов берётся информация, считанная из arc.ini, которая может отличаться от имевшейся в момент упаковки:


Код: Archive type: FreeArc
Total bytes: 30,180,534
Compressed bytes: 6,697,778
Ratio: 22.19%

Directory blocks: 1
Directory, bytes: 5,047
Directory, compressed: 2,411
Solid blocks: 3
Avg. blocksize: 10 mb

Compression memory: 261 mb
Decompression memory: 198 mb
Dictionary: rep:96mb+xlzma:96mb grzip:2519kb

Archive locked: -
Archive comment: -
Recovery info: -
SFX size: -
Headers encrypted: -
Encryption algorithms: -

Pos Size Compressed Files Method
-----------------------------------------------------------------------------
31 0 0 4 storing
31 2,553,035 251,544 94 grzip:2519kb:m1:l32:h15
251,575 27,627,499 6,446,234 64 precomp043:cn:t-j+rep:96mb+exe+delta+4x4:lzma:96mb:normal:16:mc8
-----------------------------------------------------------------------------
162 files, 30,180,534 bytes, 6,697,778 compressed

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

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

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

Всем привет. Я к вам обращаюсь с вопросом, касается сжатию. Я делаю репак на 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
вы серьёзно полагаете что механики опубликовали нерабочий комплект?

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.
В чем может быть дело?

Цитата:

Unsupported compression methop or error in parameters: precomp

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

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

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

Цитата:

сейчас переделываю 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% быстрее