» FreeArc (часть 4)

Изменяет
Диапазон был расширен до 273 в версии 7-zip 4.30 beta. А вот выписка из файла помощи версии 4.29

fb={N}
Sets number of fast bytes for LZMA. It can be in range from 5 to 255. Default value is 32 for normal mode and 64 for maximum mode. Usually big number gives a little bit better compression ratio and slower compression process.

Чтобы уже наверняка.

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

egor23

Цитата:

Результат получается битый, т.е. архив должен был получиться 74МБ, а получился 40Мб
причём в папке темр временный файл получается 74МБ, т.е. srep отрабатывает правильно, а вот в архив попадают не все 74МБ, а только 40МБ.

попробуй с этой версией:

http://www.freearc.org/download/research/srep296b.zip

напомню, что речь шла о работе в режиме stdin-to-stdout

Bulat_Ziganshin

Цитата:

;options = mem75%-400mb (for decompresssion with srep+exe+delta+lzma:256mb)
packcmd = srep {options} <stdin> <stdout>
unpackcmd = srep -d {options} <stdin> <stdout>

Упаковка работает

arc a a296b -msrep:m3f:s250m pdf.TAR11.pcf
FreeArc 0.67 (March 18 2011) creating archive: a296b.arc
Compressed 1 file, 249,562,113 => 77,720,120 bytes. Ratio 31.1%
Compression time: cpu 2.13 secs, real 37.56 secs. Speed 6,644 kB/s
All OK

Распаковка с {options} не работает

Цитата:

unpackcmd = srep -d {options} <stdin> <stdout>

arc x a296b
FreeArc 0.67 (March 18 2011) extracting archive: a296b.arc
Extracting 1 file, 249,562,113 bytes. Processed 0.0%
ERROR: write error (disk full?) in compression algorithm srep:m3f:s250m

Распаковка без {options} работает

Цитата:

unpackcmd = srep -d <stdin> <stdout>

arc x a296b
FreeArc 0.67 (March 18 2011) extracting archive: a296b.arc
Extracted 1 file, 77,720,120 => 249,562,113 bytes. Ratio 31.1%
Extraction time: cpu 1.94 secs, real 5.88 secs. Speed 42,479 kB/s
All OK

Я правильно понял, что FreeArc в zip не сжимает? и не конвертирует?

1ANP
версия 0.666 - нет. версия 0.67 - сжимает, но с ошибками. если очень нужно, надо поставить 0.67 и заменить в ней 7z.dll на стандартную от 7-zip

SREP 2.97 release candidate:

* show original/compressed size with commas: 1,234,567
* -mem75p made equivalent to -mem75%


bugfixes:

* fixed bug in compression from stdin
* fixed crashes when decompressing corrupted data
* fixed crashes when real filesize is larger than one specified with -s


Recommended sections for arc.ini:

This section is optimized for srep:f (future-lz) compression, therefore compressed data are sent immediately to stdout:

Код: [External compressor:srep]
packcmd = srep {options} $$arcdatafile$$.tmp - <stdout>
unpackcmd = srep -d {options} - - <stdin> <stdout>

Bulat_Ziganshin

Цитата:

SREP 2.97 release candidate

[more=Упаковка "не проходит"..]
Упаковка с новыми рекомендациями "не проходит"


Цитата:

packcmd = srep {options} $$arcdatafile$$.tmp - <stdout>

arc a a297 -msrep:m3f:s250m pdf.TAR11.pcf
FreeArc 0.67 (March 18 2011) creating archive: a297.arc
Compressing 1 file, 249,562,113 bytes. Processed 75.8%
Compressing 249.562.113 bytes with srep -m3f -s250m $$arcdatafile$$.tmp -
48 mb, -m3f -l512 -c256 -a4
Compression ratio: 234,881,024 -> 72,710,139: 30.96%. Cpu 25.653 mb/sec, real 20.798 mb/sec
ERROR! Input file is larger that filesize specified

Errorlevel=3

ERROR: general (de)compression error in srep:m3f:s250m


Цитата:

packcmd = srep {options} $$arcdatafile$$.tmp $$arcpackedfile$$.tmp

arc a a297 -msrep:m3f:s250m pdf.TAR11.pcf
FreeArc 0.67 (March 18 2011) creating archive: a297.arc
Compressing 1 file, 249,562,113 bytes. Processed 100.0%
Compressing 249.562.113 bytes with srep -m3f -s250m $$arcdatafile$$.tmp $$arcpackedfile$$.tmp
48 mb, -m3f -l512 -c256 -a4
Compression ratio: 234,881,024 -> 72,710,139: 30.96%. Cpu 25.222 mb/sec, real 20.708 mb/sec
ERROR! Input file is larger that filesize specified

Errorlevel=3
Compressed 1 file, 249,562,113 => 249,562,114 bytes. Ratio 100.0%
Compression time: cpu 2.73 secs, real 14.63 secs. Speed 17,064 kB/s
All OK
[/more]

Добавлено:
-msrep:m3f:s250m

Упаковка проходит при
packcmd = srep {options} <stdin> <stdout>
packcmd = srep {options} - - <stdin> <stdout>

Распаковка проходит
unpackcmd = srep -d {options} - - <stdin> <stdout>

Распаковка не проходит
unpackcmd = srep -d {options} <stdin> <stdout>

пищит динамик ПК, "данные в консоль идут"

egor23
блин, глупая ошибка, попробуй с s260m

Bulat_Ziganshin

Цитата:

блин, глупая ошибка, попробуй с s260m

пробывал и 350 и 550 тоже самое
и без -s, тоже выскакивает

Цитата:

пищит динамик ПК, "данные в консоль идут"

прошлым летом разбирался с пайпом и имел те же проблемы в своей проге, этим кстати так же грешат [ccmx, tak, rar], по крайней мере на тот момент. Думал, раз эти не могут нормально, то и рыпаться не стоит. Но когда заметил что в 7-zip отсутствует это бадяга, пришлось изучить вопрос детальней, на WinAPI есть функция GetFileType, которая позволяет мониторить такие ситуации. Мне по крайней мере помогло.
http://msdn.microsoft.com/en-us/library/aa364960%28v=vs.85%29.aspx

GetFileType - хорошо, только не портабельно. есть стандартная isatty

в 2.97 глупейшая ошибка, из-за которой она с файлами вообще не может работать а с stdin только если указать в -s больший размер файла. в общем, подождите 2.98

Bulat_Ziganshin
Планируете ли вы добавить в среп работу с папками?

vasulpr
нет, я планирую интегрировать алгоритм srep в fa, а пока советую использовать srep через arc.ini

SREP 2.98 release candidate:

* fixed the stupid bug
* improved calculation of output filesize in -m1f mode

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

vasulpr
Как ты думаешь, зачем внутри архива лежит файл readme.htm ?
Кстати тебе еще понадобится редактор текстовых файлов с поддержкой перевода строки 0x0A, ибо notepad понимает только 0x0D 0x0A

не могу поставить пароль на архив в FreeArc
метод как на картинке ниже не помогает, он распаковывает всё без запроса пароля....
http://www.pkgid.ru/imagesoft/freearc/freearc14.png

death7lord
gui там, прямо скажем, нелогичный. проще всего - после нажатия Add поставить галочку на Шифровании в первой закладке и затем нажать OK - он сам спросит пароль

да, это помогло, спасибо
но тогда возникает вопрос: а где в ISDone0.4.2.5 прописывать этот параметр??
if not ISArcExtract ( 0, OveralPct, 0, ExpandConstant('{src}\aa.bin'), ExpandConstant('{app}\'), false,CallBack, '', '', '') then break;

Mожет кто сталкивался с проблемой такой:
Качал торрент, вроде все нормально скачалось, перехешировал все совпадает на 100%, но при попытке открыть архив появляется
[more=Ошибка] [/more]

Попытался восстановить:
[more=Получаю]C:\Program Files (x86)\FreeArc\bin>arc r -tp- "W:\Half-Life 2 Anthology\games\Cinemat
ic Mod part1.arc"

FreeArc 0.67 (March 18 2011) recovering archive: W:\Half-Life 2 Anthology\games\
Cinematic Mod part1.arc

ERROR: W:\Half-Life 2 Anthology\games\Cinematic Mod part1.arc isn't archive or this archive is corrupt: block descriptor at pos 3059718000 is corrupted. Please recover it using 'r' command or use -tp- option to ignore Recovery Record[/more]
Длина файла в торренте "3059718154".

---

На всякий случай напишу железо и ОС, может из-за его:
Windows 7 SP1 x64. 6Gb ОЗУ, процессор q6600.


UPD.
Решил проблему следующим способом:
Отрезал в WinHex от конца файла все адреса до указанного в ошибке и докачал недостающие части.

death7lord
зашифрованные архивы может распаковать только arc.exe (да, это мой баг)

Народ, я тут новичок, кто-нибудь знает когда будет новая не-альфа версия FreeArc?

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

Методом тыка ранее выяснял, что вероятность успешной распаковки уменьшается не только в зависимости от сжимаемых файлов, но и от всяких объединений/перепаковок/добавлений в архив. В связи с этим у меня вопрос: есть ли какие-либо гарантии, что запакованные так-то и так-то файлы будут гарантированно распакованы?

Doctor_Freeman

Цитата:

Методом тыка ранее выяснял, что вероятность успешной распаковки уменьшается не только в зависимости от сжимаемых файлов, но и от всяких объединений/перепаковок/добавлений в архив. В связи с этим у меня вопрос: есть ли какие-либо гарантии, что запакованные так-то и так-то файлы будут гарантированно распакованы?

Вы бы по подробней писали, какие методы сжатия использовали, желательно брать их из архива, и какие сбои происходили.

Иначе, если есть ошибка в FreeArc, то её не локализовать общими словами.

Doctor_Freeman

Версия 0,666 работает с ошибками на методах -мех5...-мех9
Версия 0,67а этих ошибок не имеет. Но ошибается при записи в формат .zip
Если в версию 0,67а записать файл 7z.dll от 7zip v9.20, то этих ошибок тоже не будет.
А больше я не знаю про ошибки.

а нельзя сделать чтобы архиватор при распаковке архива с методом 4x4 (например lzma:128mb:fast:96:mc20) учитывал параметр t (кол-во потоков), для данного файла ставил t2
а то получается смешная ситуация, запаковать смог, а распаковать нет ))
(использовался архиватор 0.666 build)
можно даже не указывать кол-во потоков, он все равно сможет запаковать, получается опция lc75p по-умолчанию работает, а опция ld75p - нет

кстати unarc успешно его распаковывает
(067 alpha 2011-03-18, 0.666 зависала [ошибки не было, просто нечего не делала])


оказывается что по умолчанию в normal preset match finder - ht4 ?
кстати а у него требование к памяти какое, в докуметации по lzma только hc4 есть, а ht4 - это же детище автора FA ))
и какой эффект дает hashsize (параметр h)?


и еще для tor в исходниках вроде написано что он принимает параметры многие, например p(parser ), однако я ввожу p1 или p3, но пишет ошибку, хотя кроме lazy greezy есть еще 3 парсера (3,4,5), но все равно пишет ошибку о неверном параметре

Здравствуйте! У меня такой вопрос: можно ли сделать опциональную распаковку arc-архивов в зависимости от выбранных пунктов? Я пробовал так:

[more]
#define ArcLocation "{app}\*.bin"

[Files]
Source: "data-1.bin"; DestDir: "{app}"; Flags: deleteafterinstall ;
Source: "data-2.bin"; DestDir: "{app}"; Flags: deleteafterinstall ; Check: 1;
Source: "data-3.bin"; DestDir: "{app}"; Flags: deleteafterinstall ; Check: 2;
[/more]

Но инсталятор просто выплёвывает все три архива, не распаковывая их. Если же не включать файлы в архив и писать #define ArcLocation "{src}\*.bin", то распаковываются сразу все архивы.

Можно ли решить мою проблему? Может быть тут такое уже обсуждалось, но я искал и не нашёл; так что извиняюсь за возможный повтор вопроса. Заранее спасибо.

Posetitel33
пропиши в скрипте не распаковывать по маске а передавать список файлов (можно через запятую)
и все будет тип топ
он же у тебя по маске ищет все файлы бин и распаковывает
а ты вместо маски сделай чтобы скрипт использовал список файлов

какое преимущество дает использование future-lz
я понял что требование к памяти при распаковке ниже
но ведь память и так при распаковке очень малая (16мб)

kalpak

Цитата:

какое преимущество дает использование future-lz

скорость и щадащий режим для винта. А для памяти как раз наоборот