» FreeArc (часть 4)

Цитата:

И еще можно ли как-то сжимать файлы упакованный в *.zip контейнер с 0-вым сжатием, т.е. применять особые настройки для файлов находящихся внутри этого контейнера а не к самому контейнеру?

нет


Цитата:

файлы должны ужаться до примерно до 14мб, но создаваемый архив весит 42 мб !!!

arc lt что выдаёт?

[more] Середину вырезал, а то слишком длинное сообщение не отправляется

[spoiler]
arc lt snd.arc
FreeArc 0.666 listing archive: snd.arc
Listing archive: snd.arc

Archive type: FreeArc
Total bytes: 51,210,240
Compressed bytes: 42,802,456
Ratio: 83.5%

Directory blocks: 1
Directory, bytes: 163,561
Directory, compressed: 26,518
Solid blocks: 1,806
Avg. blocksize: 28 kb

Compression memory: 384 mb
Decompression memory: 384 mb
Dictionary: 185kb + 185kb

Archive locked: -
Archive comment: -
Recovery info: -
SFX size: -
Headers encrypted: -
Encryption algorithms: -

Pos Size Compressed Files Method
-----------------------------------------------------------------------------
31 0 0 55 storing
31 468,502 247,216 11 dict:463kb:80%:l8192:m400:s100+lzp:463kb:92%:145:h19:d1mb+ppmd:16:384mb
247,247 75,270 29,021 1 tta:s+rep:75kb:128:a99+lzma:75kb:normal:bt4:128:mc10000
276,268 19,374 15,776 1 tta:s+rep:20kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
292,044 62,956 26,161 1 tta:s+rep:63kb:128:a99+lzma:63kb:normal:bt4:128:mc10000
318,205 62,956 26,161 1 tta:s+rep:63kb:128:a99+lzma:63kb:normal:bt4:128:mc10000
344,366 64,624 54,474 1 tta:s+rep:65kb:128:a99+lzma:65kb:normal:bt4:128:mc10000
398,840 64,624 26,762 1 tta:s+rep:65kb:128:a99+lzma:65kb:normal:bt4:128:mc10000
425,602 49,884 28,643 1 tta:s+rep:50kb:128:a99+lzma:50kb:normal:bt4:128:mc10000
454,245 55,212 24,358 1 tta:s+rep:55kb:128:a99+lzma:55kb:normal:bt4:128:mc10000
478,603 55,212 24,358 1 tta:s+rep:55kb:128:a99+lzma:55kb:normal:bt4:128:mc10000
502,961 123,620 52,887 1 tta:s+rep:123kb:128:a99+lzma:123kb:normal:bt4:128:mc10000
555,848 123,620 52,887 1 tta:s+rep:123kb:128:a99+lzma:123kb:normal:bt4:128:mc10000
608,735 186,222 93,095 1 tta:s+rep:185kb:128:a99+lzma:185kb:normal:bt4:128:mc10000
701,830 17,896 15,687 1 tta:s+rep:19kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
717,517 17,896 15,451 1 tta:s+rep:19kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
732,968 17,896 15,678 1 tta:s+rep:19kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
748,646 17,896 15,768 1 tta:s+rep:19kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
764,414 17,896 15,843 1 tta:s+rep:19kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
780,257 17,896 15,831 1 tta:s+rep:19kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
796,088 17,896 15,362 1 tta:s+rep:19kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
811,450 21,036 19,109 1 tta:s+rep:22kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
830,559 21,052 18,792 1 tta:s+rep:22kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
849,351 21,052 18,084 1 tta:s+rep:22kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
867,435 21,052 19,119 1 tta:s+rep:22kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
886,554 21,052 17,064 1 tta:s+rep:22kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
903,618 21,052 17,064 1 tta:s+rep:22kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
920,682 21,052 18,230 1 tta:s+rep:22kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
938,912 21,052 18,401 1 tta:s+rep:22kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
957,313 21,052 17,087 1 tta:s+rep:22kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
974,400 21,052 17,087 1 tta:s+rep:22kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
991,487 32,420 28,294 1 tta:s+rep:33kb:128:a99+lzma:33kb:normal:bt4:128:mc10000
1,019,781 16,956 14,753 1 tta:s+rep:18kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
1,034,534 16,956 14,671 1 tta:s+rep:18kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
1,049,205 16,956 14,671 1 tta:s+rep:18kb:128:a99+lzma:32kb:normal:bt4:128:mc10000

***************************************************
***************************************************
***************************************************

tta:s+rep:15kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
42,671,497 14,908 12,810 1 tta:s+rep:16kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
42,684,307 14,908 12,810 1 tta:s+rep:16kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
42,697,117 13,884 10,600 1 tta:s+rep:15kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
42,707,717 13,884 10,600 1 tta:s+rep:15kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
42,718,317 13,884 10,868 1 tta:s+rep:15kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
42,729,185 13,884 10,868 1 tta:s+rep:15kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
42,740,053 12,860 9,852 1 tta:s+rep:14kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
42,749,905 12,860 9,852 1 tta:s+rep:14kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
42,759,757 12,860 10,342 1 tta:s+rep:14kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
42,770,099 12,860 10,342 1 tta:s+rep:14kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
42,780,441 13,884 11,023 1 tta:s+rep:15kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
42,791,464 13,884 11,023 1 tta:s+rep:15kb:128:a99+lzma:32kb:normal:bt4:128:mc10000
-----------------------------------------------------------------------------
1,870 files, 51,210,240 bytes, 42,802,456 compressed
All OK

[/spoiler]


Вообще у меня при использовании -tta или -mm результаты выходят отвратительные - 98%, тот же -m9 выдает 64%. Вот и попробавл скомбинировать с lzma - результат пишет потрясающий, но файл создает в 3 раза больше [/more]

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

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


Попробовал и не один час и разные варианты - от сжатия wav'ов -tta или -mm становиться только заметно хуже...

StaticZ
я же вам написал - попробуйте ещё раз и если будет неправильный вывод, пришлите мне архив для тестирования

Попробовал, сжатый архив: http://rghost.ru/48556675

Лог fa:

arc create snd.arc snd -m9 -m$wav=tta:s:m3+rep:512mb:128:a99+lzma:ultra:mc10000:5

FreeArc 0.666 creating archive: snd.arc
Compressed 338 files, 9,757,172 => 3,445,403 bytes. Ratio 35.3%
Compression time: cpu 3.81 secs, real 4.30 secs. Speed 2,267 kB/s
All OK



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

[more=мой лог]
Z:\4>arc create snd.arc snd -m9 -m$wav=tta:s:m3+rep:512mb:128:a99+lzma:ultra:mc10000:5
Compressed 338 files, 9,757,172 => 8,333,609 bytes. Ratio 85.4% cessed
Compression time: cpu 1.76 secs, real 2.45 secs. Speed 3,987 kB/s

Z:\4>C:\Testing\FreeArc666\bin\arc create snd.arc snd -m9 -m$wav=tta:s:m3+rep:512mb:128:a99+lzma:ultra:mc10000:5
FreeArc 0.666 creating archive: snd.arc
Compressed 338 files, 9,757,172 => 3,444,998 bytes. Ratio 35.3%
Compression time: cpu 1.97 secs, real 2.29 secs. Speed 4,253 kB/s
All OK

Z:\4>C:\Testing\FreeArc666\bin\arc create snd.arc snd -m9 -m$wav=tta:s:m3+rep:512mb:128:a99
FreeArc 0.666 creating archive: snd.arc
Compressed 338 files, 9,757,172 => 9,450,527 bytes. Ratio 96.8%
Compression time: cpu 0.67 secs, real 1.05 secs. Speed 9,336 kB/s
All OK
[/more]

в общем, в 0.67 эта ошибка исправлена. очень смутно припоминаю, что там запись из lzma неправильно считалась

Bulat_Ziganshin
0.67 зафиналить не собираетесь?

Понятно будем ждать следующего релиза, жалко конечно я уж так обрадовался сжатию до 30% .... А что с -mm и -tta не подскажите? Как написано на сайте они предназначены для сжатия мультимедии в особенности wav, так почему результат такой низкий? Обычный -m9 сжимает данные до 64% а с mm\tta удается достичь только 85%, может я что-то не так делаю?


PS И спасибо за чудесную программу

Bulat_Ziganshin

Цитата:

в 0.67 эта ошибка исправлена.

Имеет смысл обновиться или все-таки подождать финала?

Skif_off
Я с версией 0,666 не мог работать - там ошибки.
А в версии 0,67 те ошибки, что мы замечали, Булат исправил.
Я в последней версии 12-12-2012 пока с ошибками не сталкивался.

Цитата:

0.67 зафиналить не собираетесь?

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


Цитата:

Имеет смысл обновиться или все-таки подождать финала?

обновляйтесь. 0.67 сейчас горазло качественней чем 666


Цитата:

Обычный -m9 сжимает данные до 64% а с mm\tta удается достичь только 85%, может я что-то не так делаю?  

всё зависит от конкретных данных. у вас медкие wav-файлы, fa к этому не приспособлен. попробуйте nz,rar4,uharc

http://lenta.ru/news/2013/09/06/encryption/

это к вопросу о том, достаточно ли шифрования по american encryption standard, к тому же так удобно ускоренного в процессорах американской фирмы intel

Bulat_Ziganshin

Цитата:

это к вопросу о том, достаточно ли шифрования по american encryption standard, к тому же так удобно ускоренного в процессорах американской фирмы intel

Быстрее зашифрует - быстрее и расшифрует Думаю, их аппаратный RNG тоже не совсем random.

Булат, вопрос к тебе как к автору arjz. Есть arj-архив, в нем есть упакованный exe'шник, дающий при распаковке ошибку crc. Инфы для восстановления в архиве ессно никогда не было. Есть серьезные основания полагать, что ошибка не более, чем в 1 бит (к примеру правильный байт был 87, а "стал" C7). Вопрос: как локализовать место в сжатом файле, где возникает ошибка ? Чтобы на край хоть все 256 вариантов сбойного байта перебрать

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

если только один бит/байт сбойный, то можно просто перебрать все файлы отличающиеся одним битом/байтом и попробовать распаковать их в памяти

в любом случае это требует программирования

Цитата:

посмотреть в расжатом файле до какого места он выглядит правдоподобно и с какого места - неправдобподобно

Выглядит правдоподобно весь. И даже работает. Вопрос лишь в том, вылезет ли в какой-то момент непредвиденная ошибка, или повреждено не особо критичное место. С полным перебором ясно (~110kb * 256 вариантов каждого байта), просто надеялся, что можно проще.

Цитата:

~110kb * 256 вариантов каждого байта

=25 миллионов вариантов = 2.5 тб данных = час работы компьютера

А есть ли способ при упаковке\распаковке сохранять атрибуты файлов (только чтение, скрытый, системный и тд) ?

нет, атрибуты пока не сохраняются

Сжал файл в 7z выбрав шифрование Быстрое: twofish-256 -p? -hp Но Bandizip показывает, что шифрование применено AES 256. Чему верить?

winkot
формат .7z поддерживает только aes-шифрование, так что эта опция внаглую игнорируется

Bulat_Ziganshin
Тогда, наверное, надо бы сделатьт эту кнопку не активной. А то вводит в заблуждение. Кстати, сжать в zip с шифрованием не получилось вообще, ни с AES ни с twofish. На сайте пишется о возможности применения каскадного шифрования. К каким типам архивов это относится?

winkot
да, при работе с 7z/zip надо менять интерфейс, отключая неподдерждиваемые опции. просто это ещё не сделано. каскадное шифрование - фича только формата arc. zip поддерживает aes-шифрование, но похоже способа включить его вместо дефолтного нету. надо впрочем сделать его вообще по умолчанию, кому нужен этот zip-crypto..

Bulat_Ziganshin
ХВАТИТ СИСЬКИ МЯТЬ!!! Выпусти пожалуйста 0.70 которую ты обещаешь всему миру уже который год, а потом уж придумывай новые фичи, алгоритмы и т.д.

Помолчал бы ты ей богу. Хотя бы из-за уважения к автору FreeArc, который делает его совершенно бесплатно и наполнил его отличным функционалом.
И вообще, что ты хочешь увидеть в 0.70 в отличии от текущей версии?

Действительно, надо объективно признать - с такой скоростью разработки ко времени выхода релиза 1.0 просто отпадёт надобность что-то архивировать.Возьмут люди новый винтик терабайта так на 3-4 и всё.Многие просто постареют, забросят компьютер, и будут уже таки выращивать помидоры на даче.Или просто люди увлекутся чем-нибудь другим - дайвингом, или велопутешествиями, например.Автору необходимо уже прислушаться к голосу народа.
Говорю спокойно, взвешенно, разумно, имхо. И прошу так-же отнестись к моим словам.
Хотя, конечно-же, архиватор замечательный. Сам им пользуюсь.

7-zip теми же темпами развивается. И ничего. А FreeArc его по функционалу в разы превосходит даже на этой стадии.

Добавлено:
Главная проблема FreeArc - малая распространенность, а из-за нее плохая поддержка формата сторонним софтом. А оба этих показателя, ИМХО, все решают. Ниша уже занята 7-zip-ом.

WatsonRus

Цитата:

Главная проблема FreeArc - малая распространенность

Я напрмиер сотрудникам предпочитаю ставить 7zip, а не FA.
Если глянуть на интерфейс на данном этапе и учесть ошибки с пустыми каталогами или вложенными архивами, то мой выбор понятен.
Ждём ...

А что за ошибки?

Интерфейс пофиг, ибо отдельно никогда не будет использоваться, ни FA, ни 7Z. Только из файл-менеджера. Меня удерживает лишь малая распространенность.

Добавлено:
И еще удерживает то, что и в других малораспространенных архиваторах - возможность внезапной смерти проекта.

Цитата:

Меня удерживает лишь малая распространенность.

Лично меня удерживает не столько малая распространенность, сколько слабые возможности SFX-модуля этого архиватора. В том же WinRar или 7-Zip есть возможность использования сценариев - куда и как распаковывать данные, а так же что потом сними делать. Да и настойчивое желание GUI SFX-модуля распаковать архив в папку, где расположен самораспаковывающийся архив с созданием дополнительной папки по имени самого архива вместо распаковки по конкретному пути тоже напрягает.