» FreeArc (часть 4)

Bulat_Ziganshin

Цитата:

SREP 2.96 alpha:

что-то улучшений нет
http://forum.ru-board.com/topic.cgi?forum=5&topic=35164&start=360#18

slech
Спасибо, буду пробовать.

неужели действительно удобно воспринимать к примеру:
байт 54,011,044 из 134,827,705
чем:
байт 54,011,044 всего байт 134,827,705

Цитата:

Что еще планируете сделать до выхода версии 0.7final, и когда планируете эту версию выпустить?

в history.txt:
0.70
deflate mt
накапливаемая статистика с отсылкой отовсюду
не установлена галка "ассоциировать с другими архивами", он все равно ассоциирует (прс установке с нуля отключены оба ассоциирования!)
saving paths inside archives as "a.arc:" or so
deleting tempfiles only when no other fa.exe is running (each fa.exe creates its own directory that may be deleted only if "dir\alive" can be deleted)
"a a.zip" и "a a -tzip" должны работать как "a a.zip -tzip"
сделать Compression/Encryption диалогами вместо вкладок в Add dialog

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

---

у меня вопрос ко всем кто использует SREP в репаках - напишите в каких ситуациях он у ваших пользователей устойчиво работает, а какие репаки оказались ненадёжными. в частности меня интересует:
- успешно ли распаковывается упакованное с -m3 (которое по умолчанию в 1.91 и выше)?
- успешно ли распаковывается упакованное с -f?
- успешно ли упаковывается/распаковывается с stdin на stdout?

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

Извините за мою лень, но не могли бы подсказать как сжимать при помощи FreeArc данные, поступающие из stdin ?
Конкретно требуется:
flashnul 2 -S - | arc.exe "что еще не пойму"
т.е. хочется забекапить данные с физического диска 2, сжав их freearc-ом.

Цитата:

у меня вопрос ко всем кто использует SREP в репаках - напишите в каких ситуациях он у ваших пользователей устойчиво работает, а какие репаки оказались ненадёжными. в частности меня интересует:
- успешно ли распаковывается упакованное с -m3 (которое по умолчанию в 1.91 и выше)?
- успешно ли распаковывается упакованное с -f?
- успешно ли упаковывается/распаковывается с stdin на stdout?
 
конкретные репаки с воспроизводимыми ошибками были бы идеальным вариантом чтобы я мог исправить ошибки

С такими вопросами надо обращаться на игровые трекеры! Советую сюда http://bestrepack.net/forum/index.php

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

Добавлено:
вот ещё что мне насоветовали:



Цитата:

a new suggestions for decompression in freearc:
freearc in merged methods for both compression and decompression [precomp+srep+lzma] needs some free space drive, for example:

max payne 3 files [except audio and video files] : 17.2 GB
max payne 3 files ---> copying to temp folder ---> 17.2 GB
17.2 GB ---> precomp ---> 40 GB [need 57.2 GB space]
40 GB ---> copying to temp folder ---> 40 GB [need 80 GB space]
40 GB ---> srep+lzma ---> 5.96 GB
for decompression reverse...
so for decompression we need 80 GB space and need many times

you can use cls-precomp.dll and cls-srep.dll files that have function can decompress archive with precomp+srep+lzma in parallel mode by 3x faster than your default decompression and need very little disk space.

говоря кратко, есть предложение включить cls-precomp.dll и cls-srep.dll в комплект программы, и сделать в ней поддержку гибридных кодеков (например в данном случае CLS должен обеспечивать только распаковку, а упаковка - внешними прогами), что позволит ускорить распаковку стандартного набора precomp+srep+lzma и не создавать при этом монстроидальные временные файлы. короче, как это уже делается в инсталяторах. что скажете?

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

"Извините за мою лень, но не могли бы подсказать как сжимать при помощи FreeArc данные, поступающие из stdin ? "

flashnul 2 -S image ; arc.exe a image image...

Типа так?

Архиваторам обычно нужен блочный файл с именем, а не последовательный поток данных.

По пробуйте взять 1 мп3 файл (4982кб) сделать 10 копий этого файла. Сбросить в папку(48.6мб). И сжать(настройки макс). И что? размер и в итоге почти равен 1 файлу.
7zip сжатые 10 песен -4893кб. 1 песня 7zip-4886кб. Итого разница= 7кб.
FreeArc сжатые 10 песен -4885кб. Сожмем 1 песню. FreeArc-4885кб. Итого =0кб FreeArc вышел победителем. Умничка! А если внутри одной песни нарезать 10 копий?

KurshakovIS
К чему лить воду?

Вопрос БЫЛ вполне конкретно озвучен:
может ли FreeArc сжимать данные поступающие из stdin ?


Код: arc a x -si
arc: Cmdline.hs:(829,23)-(832,59): Non-exhaustive patterns in case

Bulat_Ziganshin
Копался в arc.groups и не нашел несколько распространенных типов файлов:
*.iss (Inno Setup)
*.config
*.nb (Mathematica)
*.nfo
*.diz
*.dic
все текстовые! Добавьте их в arc.groups при следующем обновлении программы.

Bulat_Ziganshin

Цитата:

...упрощает восприятие

согласен

Цитата:

...оно просто начинает мозолить глаза.

согласен

Цитата:

ну да, это пустая писанина.

и тут согласен

Цитата:

если ты пользуешься программой часто, оно просто начинает мозолить глаза

и опять согласен

Цитата:

...что действительно нужно увидеть

единственное что хочется видеть при процессе упаковки - это сколько осталось времени до завершения процесса и на сколько уменьшился объем первоначальной информации. И мне совершенно все равно что и как будет выглядеть на самом деле, но если есть вариант, то конечно хочется воспринимать информацию так чтобы не отвлекаться от основной задачи и просто контролировать (не задумываясь) процесс. Ведь согласитесь, по большому счету задача архивирования - второстепенная задача.
И все-таки оставьте старый (v0).

p.s. проведите опрос среди англоязычной публики ...

p.s.s. а почему бы не подумать на счет коммерческой составляющей, а !? если правильно построить маркетинговую политику по сравнению с конкурентами существующими на рынке, я думаю что успех может быть (англоязычные страны). отвечать по поводу коммерции не надо дабы избежать не нужный флуд.

Всем привет! У меня такой вопрос сжимаю большие файлы. Сжатие начинается со скоростью 3 500 и резко падает до 2 000 и на протяжении всей распаковки скорость медленно падает. Так только у меня?
Возможно ли сделать чтобы скорость оставалась около 3 000 на протяжение всего процесса сжатия? Спасибо

Я обещал помоч с документированием unarc.dll и смылся :( Прошу прощения.
Еще актуально?

Bulat_Ziganshin
и всё-таки, мне кажется, Ratio и Speed как-то "некстати" среди остальных значений
по сути, они не столько к "прогрессу" относятся, сколько к "вспомогательной информации"
и если насчёт Ratio это несколько спорно, то уж Speed однозначно - кандидат в status bar

вот расчехлил paint и сварганил пару вариантов:

(v5) - Ratio и Speed задвинуты в самый низ, в "воображаемый status bar"

(тут несколько напрягает непонятное соседство Ratio и [+])

(v6) - Ratio и Speed в правом углу над progress bar
с одной стороны, не так "заброшены", как в предыдущем варианте, с другой - достаточно отделены от остальных значений

Цитата:

у меня вопрос ко всем кто использует SREP в репаках - напишите в каких ситуациях он у ваших пользователей устойчиво работает, а какие репаки оказались ненадёжными. в частности меня интересует:
- успешно ли распаковывается упакованное с -m3 (которое по умолчанию в 1.91 и выше)?
- успешно ли распаковывается упакованное с -f?
- успешно ли упаковывается/распаковывается с stdin на stdout?

Устойчиво работает с вышеуказанными опциями, жалоб и нареканий нет. Правда, статистика пока слабовата - пару репаков всего лишь (FA 0.67 + SREP 2.96 + ISDone 0.6), но тем не менее...

Встроенный во FreeArc SREP работает хуже чем отдельный?
Уже много сжимал различные данные сначала цепочкой SREP 2.95 (с параметром -m3 -l512), а затем FreeArc 0.666 (с параметром delta+exe+lzma:512mb:normal:bt4:273:lc8), а затем просто в FreeArc 0.666 со строчкой -m=srep:512mb+exe+delta+lzma:512mb:normal:bt4:273:lc8 и всегда результат с отдельным использованием SREP у меня выходит лучше.
Если встроенный в FreeArc SREP дожлен работать с такой же эффективностью что и отдельный, помогите мне пожалуйста отредактировав строку -m=srep:512mb+exe+delta+lzma:512mb:normal:bt4:273:lc8 на правильное использование SREP с параметром -m3 -l512

cdman67

Цитата:

Устойчиво работает с вышеуказанными опциями, жалоб и нареканий нет. Правда, статистика пока слабовата - пару репаков всего лишь (FA 0.67 + SREP 2.96 + ISDone 0.6), но тем не менее...

странно, а у другого репакера вот наоборот юзеры через один писали об ошибке crc.

Цитата:

странно, а у другого репакера вот наоборот юзеры через один писали об ошибке crc.

367 скачавших на данный момент - и ни одного нарекания - это о чём-то говорит ? Согласен, что один репак - это не показатель, но что имеем, то и имеем. Бум нарабатывать статистику дальше )))

Aerogiz


Цитата:

Встроенный во FreeArc SREP работает хуже чем отдельный?

В FreeARC нет встроенного SREP. Там есть REP. Поэтому когда ты пишешь -msrep и в arc.ini отсутствует секция srep, то srep просто игнорируется и ты получаешь просто
exe+delta+lzma:512mb:normal:bt4:273:lc8


Цитата:

Уже много сжимал различные данные сначала цепочкой SREP 2.95 (с параметром -m3 -l512)

-m3 -l512 используются по умолчанию, так что можешь их не указывать и сэкономить время.


Цитата:

а затем FreeArc 0.666 (с параметром delta+exe+lzma:512mb:normal:bt4:273:lc8)

У тебя неправильная строка. Ты хочешь использовать match finder BT4 со словарем в 512 mb, что невозможно. При BT4 и словаре больше 64 mb используется примерно 10.5 x d памяти, где d - это размер словаря. А так как FreeARC является 32-битным приложением, то выделить 5375 мегов памяти не выйдет по определению. Поэтому FreeARC просто понизит размер словаря и ты получишь
delta+exe+lzma:177mb:normal:bt4:273:lc8, а ведь можно задрать и побольше.

Highpass спс за очень подробный ответ

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


Цитата:

пару репаков всего лишь (FA 0.67 + SREP 2.96 + ISDone 0.6), но тем не менее...

интересна статистика - сравнивал srep с rep на них? распаковка идёт без временных файлов? какая скорость процесса распаковки в общем достигается?

кстати, натолкнулся при перепаковке LostPlanet2 на интересный приём. там после SREP данные уже почти не ужимаются, процентов на 10 с lzma:max:256m всего. из-за этого распаковка в lzma идёт довольно медленно - если обычно на моей тачке можно получить 40-50 мб/с, то там порядка 20, что гораздо медленней скорости чтения/записи дисков. пробовал tornado - он быстро распаковывает, но теряет в сжатии. зато если заменить lzma на xlzma:max, то получается самое то - распаковка становится в 2-4 раза быстрее за счёт многопоточности, а степень сжатия почти не падает

Добавлено:

Цитата:

у другого репакера вот наоборот юзеры через один писали об ошибке cr

skymmer на английском форуме тоже сообщил что в stdin-to-stdout mode данные считываются не до конца. как минимум в этом проблема. плюс ещё неясности по порче памяти

Добавлено:
добавил в шапку Форум Krinkels Inc

Bulat_Ziganshin

Цитата:

skymmer
So. -m1 processing

ды с -m1 (-msrep:m1f:s250m) упаковка проходит корректно
но с распаковкой проблемы и у FreeArc и у Arc

Цитата:

ОШИБКА: ошибка записи (диск полон?) в алгоритме (рас)паковки srep:m1f:s250m

4 репака - полёт нормальный
упаковка - arc a -r -di+$ --display -mt2 -s -w. -m=srep:mem75%%-150mb:f:a1:l128:c128+lzma:128mb:max:1024:bt4 -dpE:\WORK\SOLYANKA ns2011.arc

2 Bulat_Ziganshin:

Не знаю поднимался ли вопрос, но я в него уткнулся - EXE-архив НЕ распаковывается под NT4 (Service Pack6 ENG)

Понятно, что эта операционка уже почти раритет, но как всегда, в самый неожиданный момент...

cdman67

Цитата:

-m=srep:mem75%%-150mb:f:a1:l128:c128+lzma:128mb:max:1024:bt4

А что это за параметр 1024 ты задаешь? Уж не fb ли ?

Highpass, ну да, и что ?

cdman67
Да ничего. Просто ты заблуждаешься, считая что такое значение параметра FB допустимо.
FB имеет диапазон от 5 до 273 (ранее до 255) включительно.

Цитата:

FB имеет диапазон от 5 до 273 (ранее до 255) включительно.

ранее было 256, если не изменяет память.