» FreeArc (часть 4)

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

1. уверен, что это текстовые файлы. для текстов -m5..9 однопоточный. два ядра + HT в i5 эквивалентны 2.5 ядрам по скорости

для бинарных файлов -m5..9 двухпоточный (точнее там три потока, загружающие 1.8 ядра)

-mx === -m9

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

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

SREP 2.96 alpha:

* -mem50% and -mem75%-600mb options support; -mem75% by default
* when necessary, temporary file is created automatically
* make stderr always unbuffered (useful for GUIs around srep.exe providing progress indicator)
* "srep" and "srep -d" commands now works as a filter if stdin and atdout are redirected

bugfixes:

* -mem option sometimes was ignored on -f decompression
* fixed bug when compressing data from pipe (i.e. producer | srep)
* 64-bit version now can use >4gb of RAM


This version helps to use SREP in FreeArc and repacks. First, you no more need to specify temporary file with -temp option - it's created automatically, but only when necessary. Second, by default up to 75% of RAM used for -f decompression - it's optimal value for standalone SREP decompression. If you use SREP in a pipe, second form (-memXX%-YYmb) may be used, for example:

arc a archive -m=srep:mem75%-600mb:f+lzma:512mb

This means that SREP on decompression should use 75% of RAM minus 600 mb (memory required for LZMA and unarc buffers)


Recommended {External compressor:srep} section in arc.ini:

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

nixx1

Цитата:

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

Справку читай, а не флуди во всех темах. Тем более здесь тема FreeArc'а а не inno.

Цитата:

Справку читай, а не флуди во всех темах. Тем более здесь тема FreeArc'а а не inno.

нашел бы, не писал. И где я флудил во всех темах, тему Инно + сторонние упаковщики я сразу не увидел, а ты тут сразу раздухарился, самый умный чтоль?

Цитата:

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

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


Цитата:

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

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


Цитата:

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

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


Цитата:

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

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


Цитата:

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

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

Bulat_Ziganshin

Цитата:

SREP 2.96 alpha:

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

Цитата:

Что еще планируете сделать до выхода версии 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?

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

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

Цитата:

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

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


Цитата:

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

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

Цитата:

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

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

ну тома - это архивы созданные им ))) неправильно выразился просто )))
и еще при попытке распаковать архив с помощью ISDone Unarc.dll возвращает мне код ошибки -2(Unsupported compression metod)

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

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

Цитата:

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

Спасибо.


Цитата:

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

Ошибка выдается в двух случаях:

1. добавление кода при сжатии (сразу выставляется 3 галки - сжать, код, sfx). При начале работы (уже после сжатия) он и вылетает, еще до добавления кода.
2. командой добавить код к архиву (там галки сжатия нет, есть только галка код)

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

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

Цитата:

1. уверен, что это текстовые файлы. для текстов -m5..9 однопоточный. два ядра + HT в i5 эквивалентны 2.5 ядрам по скорости

для бинарных файлов -m5..9 двухпоточный (точнее там три потока, загружающие 1.8 ядра)

-mx === -m9

1. Word'а нет совсем. В основном Html -странички, pdf.

2. У меня были случаи когда -mx сжимал плотнее, чем -m9.

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

1. судя по времени работы, оно распозналось и паковалось как текстовые данные
2. -mx определено в программе как -m9 тут может быть эффект того что -m9 использует всю доступную в данный момент память, так что он может давать чуть разные рез-ты при разных запусках

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

Вот окно добавить код.

http://s59.radikal.ru/i163/1203/e3/70a59663ade9.jpg

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

Sergey_Advisor
вот первая же строка - сжатие. другое дело что галка там не отмечена. а вот 100% RR при немаленьком размере архива - это жесть. советую вам par2 использовать для таких вещей

Цитата:

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

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

Цитата:

вот первая же строка - сжатие. другое дело что галка там не отмечена.

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

1. Сжал как обычно -mx -ld1600m
2. Командой добавил код для восстановления (галки сжатия нет и я ее не убирал! версия FreeArc 0.67 (March 18 2011))


Цитата:

а вот 100% RR при немаленьком размере архива - это жесть. советую вам par2 использовать для таких вещей

А в чем фишка? Тут все одним файлом, места у меня навалом, а современные диски время от времени любят сыпать плохими секторами. Если бы эта программа использовала новые коды коррекции, а не коды Рида-Соломона.

Добавлено:
Вот еще раз проверил:

1. Сжатие образа диска 9ГБ в 2ГБ.
2. Выбор пункта добавить восстановление.
3. Галочки сжатия нет.
4. Сортировка списка файлов.
5. Сообщение об ошибке.

Встроенный во 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

Sergey_Advisor
проблема в том, что вся информация для восстановления хранится в RAM, причём память выделяется одним блоком. поэтому её размер не может быть больше размера наибольшего непрерывного блока ОЗУ (диалог Settings/Information)

freearc использует xor - намного более примитивную схему коррекции ошибок, чем коды RS. вообще это совсем не моя область, но я думаю, что par2 и 20% инфы - вполне достаточно для любых сбоев. дальнейшее повышение надёжности хранения данных - за счёт хранения копий на разных носителях (внешние диски, интернет, dvd, usb-стик)

cdman67

Цитата:

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

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