» FreeArc (часть 4)

параметр 4x4:b определяет размер блоков, на которые разбиваются входные данные (каждый блок сжимается независимо адгоритмом описанным внутри 4x4). по умолчанию размер блока равен размеру словаря во внутреннем алгоритме, т.е. для 4x4:lzma:128mb этот блок будет 128 мб.

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

имеет смысл проверить на промежуточном 128:c128, по отдельности изменения в rep и tor, на большем числе файлов и исключить влияние I/O (в частности слить 1031 файл в один)

Короче, поганял я precomp по разному...

Абсолютно бесполезный алгоритм, который так и не смог хоть немного пережать существующие игровые ресурсы (напомню, по содержанию это zip-архивы), хотя их увидел, определил тип и deflate сжатие и что-то по-честному пытался-тужился на винт...

Целый день убил, а толку - ноль. Как было 3 гига, так 3 и осталось.

Хотя, если по-нормальному (как обещано) - должно ужаться до 2 гигов.

Да даже если просто вскрыть ресурсы (те самые zip-архивы), то изначальных данных будет на 8 гигов, но результат даже у WinRAR получится чуть меньше 2,2 гигов, а у 7z и того меньше...

Кто может разъяснить ситуацию?

Паковал два раза, с обоими из вариантов:
-m9x -lc- -ld- -di -mc$precomp+default - соответственно доступной инфе и мануалу
-m9x -lc- -ld- -di -mc$default,$obj:+precomp - как предложено gui версией
и с обоими толку ноль...

Есть смысл посмотреть и сравнить
4x4:b128mb:lzma:128mb
4x4:b256mb:lzma:128mb
4x4:b512mb:lzma:128mb
?

Цитата:

У меня архив проходит тестирование, но при распаковке происходит ошибка.

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

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

попробуй. в любом случае это костыли

Цитата:

имеет смысл проверить на промежуточном 128:c128

Вообще-то я проверяю все, начиная от 256:с256 и до 16:с16, включая 128:с64.
Проверять долго. (На вскидку, крайние варианты: 256:с256 и 16:с16 малоинтересны.
Вариант 128:с128 интересен, скорее всего для самых быстрых tor:3:...:h64k)


Цитата:

по отдельности изменения в rep и tor

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

Bulat_Ziganshin
У архиватора 7zip есть методы
LZMA с 1 или 2 потоками
LZMA2 с 1/2/.../8 потоками.

Какие из этих методов нам доступны в FreeArc-е,
и как их вызывать?

1. Качаю архив и выбираю открыть http://www.snort.org/downloads/1416
2. Захожу в FA во второй архив - новое окошко открывается.
3. Выбираю директорию doc - Extract.
4. Получаю ошибку что архива нет.

Добавлено:
Так же есть проблема если это действие выполнить несколько раз
Архив скачивается несколько раз Firefox
snort-2.9.2.1.tar.gz
snort-2.9.2.1.tar-1.gz
snort-2.9.2.1.tar-2.gz

Вложеный архив в первом открывается нормально. В последующих появляется проблема.
Похоже что проблема вызвана пересечением имён и как следствие созданием уникального имени с snort-2.9.2.1.tar-1 который FA незнает как открыть и появляется окошко Windows с предложение выбрать программу для открытия неизвестного типа файла.

Bulat_Ziganshin
"Чукча" перечитатель уже всего, что только есть, но вменяемого ответа так и не получил, ибо примеров - фиг найдёшь. Мануал - вообще за старую версию, про внешние упаковщики вообще пара строчек, возможность использования прекомпа упоминается бегло. Переискивать по форуму среди тысяч ответов в поисках того самого, нужного (не факт, что он вообще есть) - нереально.
Вместо тыканья и посылания в доки каждый раз лучше бы сразу сказал нормально. Время бы сэкономил и себе (не нужно каждый раз давать бессмысленные посылы) и мне - меньше мучений винта и пустого расхода процессорного времени, которое у меня крайне важно.
Если где-то в моих вариантах параметров есть ошибка - скажи конкретно где, если чего-то не хватает - дай полный вариант.


Цитата:

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

Если архивы несовместимы с прогой (что можно предположить с этой фразы) - лучше скажи, совместим ли он с архивами, которые делает WinRAR, 7zip и TotalCommander?


Цитата:

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

Именно, это самое поведение, когда для упаковки "распаковывает их", а потом "при восстановлении - сжимает назад" мне и нужно, дабы вручную каждый раз потом не пересобирать эти самые zip'ы.

При этом, как я понял, "восстановление" будет производиться сразу же при распаковке "на лету" и можно будет забрать из общего arc'а любой нужный их zip'ов в изначальном виде? Или будет такая же лажа, как в своё время с *.tar.* архивами (когда распакуй всё, потом зайди хз куда, снова распакуй... и только потом держи свой файл)?

Цитата:

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

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

---

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


Цитата:

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

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

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

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

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

Подскажите, пожалуйста, FreeArc PowerPack версии 0.666 подходит для 0.67 alpha ?

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

Цитата:

"Чукча" перечитатель уже всего, что только есть

дока самого precomp


Цитата:

Если архивы несовместимы с прогой (что можно предположить с этой фразы) - лучше скажи, совместим ли он с архивами, которые делает WinRAR, 7zip и TotalCommander?  

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


Цитата:

При этом, как я понял, "восстановление" будет производиться сразу же при распаковке "на лету" и можно будет забрать из общего arc'а любой нужный их zip'ов в изначальном виде?

и это проверяется

Цитата:

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

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

Shuld
только lzma. -mlzma -mt1/2

SELFY
да

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

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

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

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

Цитата:

дока самого precomp

И? Где смысл в твоём ответе?
Где она или (хотя бы) ссылка на неё?
Где это вообще искать?



Цитата:

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

1. Я не требую, а интересуюсь тем, что не описано в доступном мануале.
2. Как автор проги мог бы уже и сказать, с чем конкретно она работает, чем ломаться тут как школьница.
3. Времени у меня действительно мало, и абсолютно логично, что у других его вряд ли больше, но тот факт, что рациональнее было бы ответить сразу, чем разводить базар - налицо!
Тем более, что написать две-три строчки ответа - не такая уже и трудная задача, клава не отвалится и руки не отсохнут...


Цитата:

и это проверяется

Что проверяется? Автор даже не знает что он написал и это сейчас проверяется??? О_о
Эпик фэйл...

А вообще, я изначально задал серьёзный вопрос, который нигде не описан.
В ответ получаю ответы в духе "или нафиг".
Раньше тоже что-то хотел узнать по поводу srep'а, но получил аналогичный ответ.
Сейчас вижу, другой человек спрашивает по х64 упаковщику - его тоже завуалировано послал...
Так ты вообще всех пользователей и тестеров лишишься.

з.ы.
Не хочешь хотя бы подсказать - фиг с тобой, но если посылаешь (кстати, по причине своей же собственной лени) - то открытым тестом, а не как $%@%$^...

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

Цитата:

Не планируется ли интеграция последнего 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

Спасибо за ответ! Однако, инсталлятор PowerPack версии 0.666 был удалён наглухо Norton, как не имеющий доверия

Результат на Virus Total, тоже удручил

Чем это вызвано?

Цитата:

И? Где смысл в твоём ответе?
Где она или (хотя бы) ссылка на неё?  
Где это вообще искать?

в гугле забанили? рассказываю: заходишь на сайт https://www.google.ru/ там в строке поиска пишешь precomp, на первой странице найдешь тебе нужен сайт, а на нем мануал


Цитата:

Как автор проги мог бы уже и сказать, с чем конкретно она работает, чем ломаться тут как школьница.

Bulat_Ziganshin не является автором precompa! и ничем он тебе не обязан, все твои вопросы проверяются экспериментально за 10 мин. лучше чем писать здесь всякую пургу занялся бы этим и не выносил бы мозги

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 и нигде больше!!!

SELFY
поставь антивирус из зёлёного списка. если коротко - года 4 назад nod32 ошибочно внёс одну прогу в список вирусов, потом он исправился, но зомби-антивирусы до сих пор это помнят. если хочешь развлечься - напиши в ТП нортона и спроси что конкретно в этом файле нашла их "сеть из десятков миллионов экспертов, наблюдающих за интернетом" и не называется ли эта сеть - совершенно случайно - virustotal.com

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

Цитата:

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

Цитата:

-mlzma -mt1/2

Спасибо.
Поэкспериментирую.

Да вы что, сговорились что ли?
Precomp, как отдельная утилита, имеет свой синтаксис параметров, а freearc - свой.


Цитата:

Bulat_Ziganshin не является автором precompa

Кэп! Он - нет, но он точно знает, что он с параметрами напеределывал.


Цитата:

в гугле забанили? рассказываю: заходишь на сайт https://www.google.ru/ там в строке поиска пишешь precomp, на первой странице найдешь тебе нужен сайт, а на нем мануал

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


Цитата:

все твои вопросы проверяются экспериментально за 10 мин.

Да ну, неужели? И где ты такой комп мощный раздобудешь, ежели на 3ГГц 4-ядернике с 12 Гигами оперативки 3 несчастных гига пережимались целый день?

Shuld

Цитата:

2. Не умею

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

[more] [more=.][/more]
Проблема: не распаковываются репаки, сжатые с помощью FreeArc.
Я уже обращался в эту тему с той же неприятностью около года назад: ссылка.
В этот раз она проявилась на совершенно новом компьютере: чистая система, проверенная свежекупленная пара планок оперативки. Кажется, теперь исключены вообще все причины, которые могли вызвать неполадки: железо в порядке, софт в порядке, сам репак в порядке, скачивается без ошибок (сверял по SHA-1 хэшу). Я в растерянности и не знаю, что ещё можно сделать.

Тем временем в рунете эта проблема становится повальной. По запросу "не устанавливаются репаки крупных игр" в яндексе можно найти тысячу аналогичных случаев, и никто ещё не выработал рецепта для её решения. Чаще всего предлагают следующие способы (иногда пишут, что помогает): [more=Народные способы]
1) Заменить/вытащить планку оперативы
2) Переустановить WinRar
3) Запустить в режиме совместимости с WinXP и от имени администратора
4) Почистить реестр
5) Поставить лицензионный Windows
6) Снести антивирус
7) Качать на другой HDD/устанавливать с/на другой HDD
8) Качать с другого компьютера
9) Заменить BitTorrent на uTorrent
10) Принести религиозную жертву любимому IT-божеству
11) Перестать играть в компьютерные игры вообще[/more]
Как правило, ничего конструктивного. [/more]

Добрый день, 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".