» FreeArc (часть 4)

Bulat_Ziganshin
Заметил, что в файлах i18n (во всех) пересекаются новые строки "0535 Processed" и "0536 Total" с уже существующими "lzma:1gb" и "ехе2"

Bulat_Ziganshin
Не так написал. Хотел сказать что 22m это минимальное ОЗУ распаковки.

kalpak
дело в том что сам по себе lzma может загрузить максимум 2 ядра. поэтому lzma/xlzma просто делит входные данные на блоки скажем по 16 мб и сжимает по несколько блоков одновременно

Shuld
1. уже сделано
2. http://freearc.org/history/changelog_full.htm - ищи --pause-before-exit

ruduk
второй раз уже про них забываю

Цитата:

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

чем качаешь-то? вообще-то fa умеет сам распаковывать через http, и скачивает при этом необходимый минимум данных


Цитата:

Хотел сказать что 22m это минимальное ОЗУ распаковки.

ясно. хоть для xtor должно и 4 мб хватать, но это ещё не доделано. только неясно, а зачем тебе такое? меньше чем 128 мб озу ты всё равно сейчас не найдёшь, а если найдёшь - будет ли там fa/unarc работать?

Кто нибудь подскажет мне, какой самый сильный параметр сжатия в FreeArc , чтоб диски трещали

Прошу протестировать.
Я создал Яндекс.Диск,
в котором открыл (надеюсь, только для чтения) папку FreeArc.
http://yadi.sk/d/gytcnNw85PaCA
В ней лежат файлы arc.ini.
(с разными датами)
Открывается эта папка? Читаются файлы?

Bulat_Ziganshin
это я знал
просто почему память больше
с hc4/a0 чем с bt4 например:

Цитата:

4 потока hc4/a0 dictsize 16mb - 904
4 потока bt4/a1 dictsize 16mb - 621

4 потока hc4/a0 dictsize 32mb - 1800
4 потока bt4/a1 dictsize 32mb - 1168

это данные с диалогового окна 7zg
я проверял на практике
поэтому заметил, мне почему то кажется что a0/hc4
в 7z просит больше памяти потому
что он (a0) быстро выделяет память и не успевает ее освобождать
(я говорю именно о lzma2 в 7z)

Shuld
да. да

kalpak
потому что каждый процесс сжатия в hc4/a0 занимает один поток, а в bt4/a1 - два потока. поэтому в первом случае таких процессов создаётся 4, а во втором 2

R76LW90
-mx

[more] опции d: s: rep
по сравнению с srep позволяют найти повторения меньшей длины на дистанции больше словаря lzma

по умолчанию:
dispack070: 779,902,969 bytes in 5.554 seconds
srep:m3f:mem75p-200mb:s:v2: 620,286,651 bytes in 353.974 seconds
delta: 621,104,395 bytes in 5.288 seconds
lzma:254m:max: 341,086,498 bytes in 340.848 seconds

только rep:
dispack070: 779,902,969 bytes in 5.741 seconds
rep:761mb:d268mb:s16: 626,250,060 bytes in 32.136 seconds
delta: 627,085,212 bytes in 5.273 seconds
lzma:254m:max: 341,090,467 bytes in 1949.573 seconds
(тут свапинг)

rep+srep:
dispack070: 779,902,969 bytes in 5.616 seconds
rep:761mb:d300mb:s16: 626,309,620 bytes in 23.603 seconds
srep:m3f:mem75p-200mb:s:v2: 620,135,115 bytes in 349.172 seconds
delta: 620,953,939 bytes in 4.883 seconds
lzma:254m:max: 341,073,105 bytes in 339.529 seconds
(srep нашел еще ~6mb)

в данном случае, если уменьшить d:, получается лучший результат:
dispack070: 779,902,969 bytes in 5.210 seconds
rep:761mb:d238mb:s16: 626,017,293 bytes in 24.804 seconds
srep:m3f:mem75p-200mb:s:v2: 619,855,435 bytes in 348.437 seconds
delta: 620,674,703 bytes in 5.070 seconds
lzma:254m:max: 341,067,209 bytes in 338.716 seconds
(то есть за счет того, что он ищет повторения от 16 байт, которые lzma кодировала бы разными записями в словаре) [/more]

Bulat_Ziganshin

2. http://freearc.org/history/changelog_full.htm - ищи --pause-before-exit

Нашел только один раз в версии 0,52 вот что
on – for "test" command in GUI mode
on-warnings – for other commands in GUI mode

И как это применять для GUI mode?

tsmv0k
эти изменения в пределах 0.01% я бы отнёс на случайные флуктуации. единстенное что тут могло бы иметь смысл - уменьшение времени работы, и то неясно почему свопинг был только в одном случае, может -lc- поставили?

а вообще можно попробовать сделать сначала srep, потом rep чтобы добить остатки

Bulat_Ziganshin
понятно, спасибо
а многопоточный lzma2 в FreeArc будет реализован
через 4x4
и/или как в 7z?

Bulat_Ziganshin

День добрый. Возникла ошибка с потреблением памяти при распаковке архивов со словарем lzma в 1гб. Судя по тому, что пишут юзеры, процессу не выделяется больше 20мб и в итоге выдает ошибку "Not an SREP compressed file". Для сжатия кроме srep+lzma ничего более не использовалось. Для распаковки используется unarc.dll (12 декабря 2012) + cls-srep.dll. Так же проблема происходит не у всех, у большинства всё спокойно ставится. При более маленьком словаре такой проблемы нету (либо бывает лишь у единиц). Более подробно тут. Есть какие либо соображения на этот счет?

Shuld
FreeArc 0.52 alpha (July 27, 2009)
---------------------
Changes:
* 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

kalpak
никак не будет реализован. lzma2 я сделаю для улучшения обработки несжимаемых данных, а многопоточные возможности, аналогичные lzma2, прекрасно реализуются и в 4x4

spider919191
1. паковать lzma с 1 гб ловарём категорически нельзя - cv. в заголовке статью "Почему для использования 2+ гб памяти желательно установить 64-битную версию Windows "
2. вы хотя бы параметры упаковки привели...

Булат, а предупреждение о превышении размера архива 4 ГиБ и, в результате, отмену вставки SFX-модуля в процессе архивации планируешь добавить, так как винда не поддерживает exe-шники такого размера? Или ещё лучше: создание отдельно SFX-модуля и отдельно data-файла? Также, будет ли многотомность в будущих версиях поддерживать SFX-архивы?

Bulat_Ziganshin

1. Ошибка возникает и у пользователей с х64, так же как и у многих на х32 системах ставится на ура, тч дело не в этом. Да и памяти при распаковке используется максимум 1.2гб, а не 2+.

2. srep:mem256m:m2f+lzma:1024mb:a1:bt4:... (остальное светить бы не хотелось).

З.Ы.
Паковать с таким словарем я вряд ли снова стану, но всё-таки хотелось бы узнать в чем конкретно проблема.

coolerru
1. проблемы возникают не с размера ровно 4 гб, и зависят от фрагментации памяти
2. уже. freearc-sfx.exe+freearc-sfx.arc
3. да

Цитата:

памяти при распаковке используется максимум 1.2гб, а не 2+.

может прочтёшь статью, а не только её название? )))

Добавлено:

Цитата:

процессу не выделяется больше 20мб и в итоге выдает ошибку "Not an SREP compressed file"

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

Добавлено:
вообще у меня проклёвывается мысль вшить srep в unarc.dll, на всякий случай. может это решить проблемы, или хотя бы избавит от сомнений кто в них виноват

Добавлено:

Цитата:

srep:mem256m:m2f+lzma:1024mb:a1:bt4:... (остальное светить бы не хотелось).

кинь lt от архива, можегшь с затёртыми параметрами lzma

Цитата:

freearc-sfx.exe+freearc-sfx.arc

Прекрасно! Как я понял, нужно просто взять нужный модуль из bin, переименовать его в имя архива (c расширением exe) и держать вместе?


Цитата:

проблемы возникают не с размера ровно 4 гб

Просто WinRAR так пишет. То есть, если в памяти найдётся непрерывный участок нужного размера всё заведётся?

1. да
2. а ты проверь. я лично о деталях особо не в курсе

Цитата:

2. srep:mem256m:m2f+lzma:1024mb:a1:bt4:... (остальное светить бы не хотелось).

Спидр такой олень...

Новая альфа-версия:Интеграция с Explorer: настройка расширений архивов, ассоциируемых с FreeArc
Сжатие: более быстрые методы для несжимаемых данных (группа $compressed), copy=storing (7z-совместимое имя метода)
GUI: завершён редизайн диалога прогресса, область сообщений скрыта до появления ошибок/предупреждений
UI: показывает xx.x% вместо xx% в индикаторе прогресса только при обработке > 1ГБ (было: >100МБ)
Исправлена ошибка: показывалось "выполнено 0%" по завершении операции над архивом, содержащим 0 байт данных

New alpha version:Explorer integration: configuration of archive extensions to associate with FreeArc
Compression: faster methods for already compressed data ($compressed group), copy=storing (7z-like method name)
GUI: finished redesign of Progress Dialog, message area is hidden while there are no errors/warnings
UI: show xx.x% instead of xx% in progress indicator only for datasets > 1gb (was: >100mb)
Fixed bug: showing "0% done" after operation on archive containing 0 bytes

Цитата:

2. srep:mem256m:m2f+lzma:1024mb:a1:bt4:... (остальное светить бы не хотелось).

Какие могут быть секреты в обычном lzma ? Там зашифрован пароль от кредитной карты ?

[more]
Цитата:

может прочтёшь статью, а не только её название? )))

Да, извиняюсь, прочитал уже. Но всё равно не пойму почему тогда подобное вылетает на некоторых х64 системах и ставится на некоторых х32 (причем у одного из тестеров всего 2гб оперативы на пк и игра поставилась нормально). Кстати, какой-то пользователь писал что после обнов винды происходит подобное, так ли оно на самом деле хз.


Цитата:

кинь lt от архива, можегшь с затёртыми параметрами lzma

FreeArc 0.67 (December 12 2012) listing archive: data.bin

Archive type: FreeArc
Total bytes: 6,339,269,769
Compressed bytes: 4,938,474,622
Ratio: 77.9%

Directory blocks: 1
Directory, bytes: 586
Directory, compressed: 401
Solid blocks: 1
Avg. blocksize: 6 gb

Compression memory: 4096 mb
Decompression memory: 4096 mb
Dictionary: lzma:1gb

Archive locked: -
Archive comment: -
Recovery info: -
SFX size: -
Headers encrypted: Yes

Encryption algorithms: aes-256/ctr

Pos Size Compressed Files Method
-----------------------------------------------------------------------------
* 31 6,339,269,769 4,938,474,622 14 srep+lzma:1024mb:a1:bt4:хххххх+aes-256/ctr:n1000:r0:ie0fc8e11546fec32cc068e045e54b093:s90b5f0686a41bf0948aeadf57f0b73006ffc9f12a065a2d7629fee51ab9950d9:c298b
-----------------------------------------------------------------------------
14 files, 6,339,269,769 bytes, 4,938,474,622 compressed
All OK
[/more]

Добавлено:
V2driver

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

muzf

Просто не всем нубам их знать надо, пусть сами читают доку, а не лезут в чужие раздачи.

Цитата:

Интеграция с Explorer: настройка расширений архивов, ассоциируемых с FreeArc

Можно ли чекбоксы приделать, как-то ручками писать не совсем привычно. А вот дописать чего нет - это очень интересная идея.

slech
а зачем тебе чекбоксы, ты хочешь отключить только часть расширений??

spider919191
ты меня извини, но здесь я srep:mem256m ну никак не вижу. а этот параметр нужен как раз распаковщику чтобы ограничить использование ОЗУ

хез, может стоить его вшивать в сам архив, как защиту от дурака

Цитата:

slech
а зачем тебе чекбоксы, ты хочешь отключить только часть расширений??

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