FreeArc (Win32) 0.67

[toolame]

tempfile исправил, проверяй http://freearc.org/download/testing/arc2014-09-13.7z

компрессия не работает через гуи FreeArc.exe почему то...

ERROR: read error (bad media?) in compression algorithm srep

декомпрессия нормально

SREP 3.93 бета (30 сентября 2014 г.)

что то в новом srep32\64i (Intel C++ 2011) работают только режимы m1 и m2
в остальных вываливается на 100%-ах
CPU i7 (Sandy Bridge) x86, x86-64, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, AES
другие exe'шники работают нормально

так для чего -mNo режим? чот я туплю

 

[Булат Зиганшин]

Булат, привет. А можно ли сделать чтобы FAzip поддерживал методы из ini?

P.S. FAzip64 не работает с CLS (x32)?

1. можно
2. конечно нет. они ж как dll грузятся. надо делать 64-битные dll-ки

компрессия не работает через гуи FreeArc.exe почему то...

ERROR: read error (bad media?) in compression algorithm srep

декомпрессия нормально


что то в новом srep32\64i (Intel C++ 2011) работают только режимы m1 и m2
в остальных вываливается на 100%-ах
CPU i7 (Sandy Bridge) x86, x86-64, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, AES
другие exe'шники работают нормально

так для чего -mNo режим? чот я туплю

1. freearc.exe не использует arc.exe
2. подтверждаю. посмотрю
3. это старый режим который был до srep 3.0. смысла в нём нет, но не выкидывать же

 

[toolame]

1. freearc.exe не использует arc.exe

аплин...
так когда тогда новая альфа? :3

Теперь все операции выводят в заголовок окна сколько процентов данных уже обработано, оставшееся время и имя обрабатываемого файла

сомнительное нововведение...
теперь во фриарке, прогресс бар в Win7, скачет от общего хода выполнения до srep'овского

 

[Булат Зиганшин]

отключи srep'овский опцией -v или арковский -i0. и лучше пиши новые сообщения в тему, иначе я на почту их не получаю

 

[toolame]

почините уже баг у 4х4 связанный с внешними упаковщиками
сейчас если не указать размер блока, то все зависает (и порой даже трудно все это дело убить)
и вопрос собственно об 4х4, что будет если не указать размер блока? c lzma все работает, но я не пойму на сколько оно блоков делиться, не где же размер не отображается
а и еще, что будет если входящая дата меньше размера блока? Будет 4x4 в один поток? Я к чему спрашиваю, в пресетах (arc.ini) можно выставить 4х4 с каким то размером блока, но данный могут быть разные и выставленный размер будет не актуален, так собственно, может задать условие, что если входящие данные меньше размера блока, то пропустить 4x4 и перейти к заданному в нем упаковщику?
или быть может добавить опцию типа:
4x4:автоматически разделить на n частей:lzma
иногда же после того rep, не знаешь какой размер данных выходит на 4х4

 

[Булат Зиганшин]

1. что мешает указывать размер блока?
2. размер блока берётся из словаря внутреннего метода, например 4x4:lzma:64m. словарь lzma по умолчанию - 8мб
3. да, в один поток
4. 4x4 тоже не знает заранее какой будет размер данных после rep. а в тех случаях, когда после tempfile этот размер известен, нет механизма передачи этого размера следующему алгоритму. думаешь это так важно - чтобы сжатие быстро отрабатывало и на небольших объёмах даных, даже в ущерб степени сжатия?

 

[toolame]

это все с пресетами связано
конечно можно сделать несколько настроек с 4х4 и без него, но путаться в них...плюс менять что то потом муторно
первое то починить можно? ведь объем всех данных заранее известен, и разделить его относительно -mt параметра не сложно же?
4х4 в один поток не вызывает никаких потерь производительности\надежности? Просто не хотелось бы наблюдать потом каких-нибудь глюков от такого сжатия.
Пропуск можно же сделать? Если объем одного типа данных например 100 мб, а в пресете для этих данных стоит что то типа [ rep:2g+4x4:b200mb:lzma:max ] то соответственно можно же 4х4 автоматически пропустить т.к. у него задан блок минимум в 200mb, а архиватор знает что всего 100mb на входе

 

[Булат Зиганшин]

я же ответил

 

[Edison007]

ведь объем всех данных заранее известен, и разделить его относительно -mt параметра не сложно же?

Ага, только если ты пакуешь на 2 ядрах таким образом, то на бОльшем количестве ядер распаковка будет в 2 потока

4х4 в один поток не вызывает никаких потерь производительности\надежности?

Пофиг ему, всё будет паковаться/распаковываться нормально

 

[toolame]

Ага, только если ты пакуешь на 2 ядрах таким образом, то на бОльшем количестве ядер распаковка будет в 2 потока

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

 

[toolame]

Еще одна неприятная ситуация...
у внешних упаковщиков, работу с темп файлами нужно как то оптимизировать
сейчас выходящий файл с одного упаковщика, тупо копируется в другой темп файл, при этом все это дело происходит на одном устройстве, соответственно это очень долго если файл большой, ведь можно же переместить+переименовать или перенаправить следующий упаковщик этот файл?
например такая цепочка
precomp+msc+srep+lzma
после прекомпа, файл $$arcpackedfile$$ будет копироваться в $$arcdatafile$$ для msc и т.д.

 

[Булат Зиганшин]

скорость диска ~100 МБ/с, т.е. копироваться будет со скоростью 50 МБ/с. само сжатие обычно идёт гораздо медленней, так что это последнее что я буду исправлять. учти, что внешние архиваторы вообще рассматриваются как вещь, которая используется в основном репакерами, поэтому тут важна скорость распаковки и степень сжатия, а уж скорость - как получится

 

[Edison007]

Булат Зиганшин, А если диск один? Скорость копирования резко падает. Так что идея с перемещением/переименование очень даже хороша.

 

[toolame]

скорость диска ~100 МБ/с, т.е. копироваться будет со скоростью 50 МБ/с. само сжатие обычно идёт гораздо медленней

ну HDD разные бывают, на сата 7200rpm, да ~50мб где то, а вот на ноутбучном 5400rpm уже ~30мб
скорость сжатия гораздо меньше? ну так оно же не сжимается, а копируется и потом только будет сжиматься, т.е. это дополнительное потраченное время, а если нужно сделать кучу тестов? Это же вообще ужас для любого HDD...
да тут дело даже не в скорости, а именно в излишней нагрузки на HDD (а в случаи с SSD еще уменьшением срока службы)

а, еще баг мелкий нашел
при сжатии папки с помощью GUI и выставлении опции: Relative to compressed folder, в архиве остается изначальная папка (пустая)

и есчо
можно ли как то разделить архив на части по блокам сжатия?
соединить то можно...
знаю можно через Modify исключить\включить файлы по маске, но опять же, останется только один архив
и такой способ не годится если надо например выделить файлы из блока $compressed так как, как я понял фриарк дополнительно определяет какие файлы жмутся, а какие плохо и помещает последние в эту группу. Пользователю не известно что это за файлы вообще и соответственно даже список не сделать...
Было бы здорово иметь опцию на распиливание архива

 

[toolame]

иииисчо
Почему сжатие ломается при использовании 4х4:b200mb с явно указанным размером солид блока, например -s800m ?
Логика? Набрать файлов на 800мб, разделить их по 200мб и пустить на упаковку
В итоге, спустя кое-какое время, ошибка...
С ограниченным количеством файлов (например -s400) такого не происходит

 

[toolame]

выловил очень странный баг
суть
есть набор файлов: jpg\bmp\текстовые файлы с описанием
метод сжатия:

rep:2g+lzma:128mb:max/$jpg=4x4:200mb:r0:precomp+rep:800mb:16:a99/$bitmap=packPNM/$text=5tn

в arc.groups

$jpg
*.jpg
*.jpeg
*.jp2
*.jpe
$bitmap
*.bmp

так вот, часть jpg файлов сжимается дефольным алгоритмом (rep:2g+lzma:128mb:max), а другая часть специальным, текстовые и bmp файлы сжимаются нормально, специальными
причем если этот дефольный алгоритм не указать, то юзается (rep:96mb+4x4:tor:16mb:c3)
выяснил что все это из-за $text=5tn
без указания текст-группы - все нормально
wtf is going on?

 

[Булат Зиганшин]

http://encode.ru/threads/43-FreeArc?p=41165&viewfull=1#post41165 выглядит очень похоже

в первую очередь на ум приходит что filetype auto-detection ошибочно определяет некоторые файлы как текстовые. проверить это можно опцией -di+!#

соответственно, бороться можно, отключив его опцией -ma-

Булат Зиганшин, А если диск один? Скорость копирования резко падает. Так что идея с перемещением/переименование очень даже хороша.

какая получается скоростьб и какая у вас (у кого есть проблема) версия винды? по логике, если у диска скорость 100 мб/с, то копия файла на том же диске создаётся со скоростью всего вдвое меньше

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

ну как, очень просто - сделать листинг архива в режимах l и lt, определить какие файлы попадают в каждый солид-блок, сделать N копий архива и из каждой из них стереть все лишние файлы )

согласен что это было бы интересной командой, но приоритеты у меня пока другие - я пилю новую реализацию fa

Почему сжатие ломается при использовании 4х4:b200mb с явно указанным размером солид блока, например -s800m ?

попробовал - не сломалось:

>arc a m:\a -s50m -m4x4:b10m:tor -r
Compressed 1,153 files, 288,156,614 => 81,769,782 bytes. Ratio 28.38% ocessed
Compression time: cpu 7.97 sec/real 3.48 sec = 229%. Speed 82.92 mB/s

>arc t m:\a
Tested 1,153 files, 81,769,782 => 288,156,614 bytes. Ratio 28.38% sed
Testing time: cpu 1.83 sec/real 1.39 sec = 131%. Speed 207.00 mB/s

>arc lt m:\a
FreeArc 0.67 (March 15 2014) listing archive: m:\a.arc
Pos Size Compressed Files Method
-----------------------------------------------------------------------------
31 0 0 134 storing
31 59,461,739 14,100,227 108 4x4:b10mb:tor:16mb
14,100,258 64,260,066 11,155,451 1 4x4:b10mb:tor:16mb
25,255,709 53,083,525 32,564,684 809 4x4:b10mb:tor:16mb
57,820,393 52,975,799 11,970,952 29 4x4:b10mb:tor:16mb
69,791,345 52,484,262 8,977,913 64 4x4:b10mb:tor:16mb
78,769,258 5,891,223 3,000,555 8 4x4:b10mb:tor:6mb
-----------------------------------------------------------------------------
1,153 files, 288,156,614 bytes, 81,769,782 compressed

 

[toolame]

filetype auto-detection ошибочно определяет некоторые файлы как текстовые

да да, что то с авто-детектом
только похоже что не как текстовые, а как $precomp $compressed

  ["v2_l8_03.jpg","v2_l8_18.jpg","v2_l8_34.jpg","v2_l8_38.jpg","v2_l8_51.jpg"] ["$precomp $compressed","$precomp $compressed","$precomp $compressed","$precomp $compressed","$precomp $compressed"]
  ? ["v2_l8_57.jpg","v2_l8_67.jpg","03.jpg","11.jpg","24.jpg"] ["$precomp $compressed","$precomp $compressed","default","default","default"]
  ["v2_l8_53.jpg","v2_l8_56.jpg","v2_l8_57.jpg","v2_l8_60.jpg"] ["$precomp $compressed","$precomp $compressed","$precomp $compressed","$precomp $compressed"]
  ["v2_l8_61.jpg","v2_l8_63.jpg","v2_l8_65.jpg","v2_l8_67.jpg"] ["$precomp $compressed","$precomp $compressed","$precomp $compressed","$precomp $compressed"]
  $jpg ["02.jpg","03.jpg","07.jpg","08.jpg"] ["default","default","default","default"]
  $jpg ["11.jpg","12.jpg","14.jpg","16.jpg"] ["default","default","default","default"]
  $jpg ["19.jpg","21.jpg","23.jpg","24.jpg"] ["default","default","default","defau

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

со скоростью всего вдвое меньше

при этом если диск вообще один (читай система\все на нем) то пользоваться компом очень проблематично
я лично вылечился уменьшением I\O приоритета, его можно указать в реестре, так:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\FreeArc.exe\PerfOptions]
"IoPriority"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\Arc.exe\PerfOptions]
"IoPriority"=dword:00000000

но рядовому пользователю придется смирится, ведь никакиx опций задания приоритетов в программе нету...

попробовал - не сломалось

угу, я не уточнил
с внешним ломается, точнее как повезёт, но в основном - ломается
если и повезёт запаковать, то распаковать тоже - как повезёт


и вопрос\реквест в чем заключается сложность реализации мульти запуска внешних упаковщиков?
было бы намного быстрее, особенно для тех что работают непосредственно с оригинальным фалом, а не с .tmp
можно было бы сделать это опционально, типа дописывать multi=1 в arc.ini

 

[Булат Зиганшин]

как работает определение типа файлов.

1. определение по arc.groups - строка, начинающаяся с "$" (помимо "$default"), определяет группу для последующиъ файлов. при этом в ней может быть описано несколько групп, скажем "$precomp $compressed" - тогда эти файлы попадут в первую из этих групп, которая есть в выбранном методе сжатия (т.е. у $precomp в данном случае - приоритет), или в группу по умолчанию. в начале arc.groups действует строка "$binary"

пример:

$precomp $compressed
*.mp3

-m=tor/$compressed=rep/$precomp=lzma/$text=ppmd -- файлы *.mp3 сжимаются lzma
-m=tor/$compressed=rep/$text=ppmd -- файлы *.mp3 сжимаются rep
-m=tor/$text=ppmd -- файлы *.mp3 сжимаются tor


2. при -ma проверяется реальное содержимое файлов. эта процедура может обнаружить всего два типа данных - $text и сжатые ($precomp $compressed). если ни одной из этих групп в текущем методе сжатия нет, то автодетект не используется (даже при наличии групп $wav/$bmp - пожалуй, это баг)

для автодетекта все файлы разбиваются на группы по 2 МБ с одинаковым расширением. файлы больше 2 МБ анализируются индивидуально, меньшие - целыми наборами.

2.1 если группа, определённая по arc.groups, является "мультимедийной" (жёстко зашито - это группы $wav и $bmp), то проверяется по заголовку и содержимому файла, похож ли он на мультимедийный несжатый. если похож - ему назначается группа по arc.groups, иначе идём дальше. остальные группы файлов этот этап проверки пропускают

2.2 из больших файлов (>2МБ) берётся несколько проб по 64 КБ, из наборов маленьких файлов берётся несколько файлов в качестве отдельных проб. данные каждой такой пробы считываются и анализируются - если они похожи на текст, то возвращается "$text", если они малосжимаемы - то "$precomp $compressed", иначе - "default". если в наборе файлов разные пробы дают разные результаты, то он разбивается на меньшие наборы, на которых тест повторяется

2.3 для одиночного файла если >~90% тестов дают одинаковый результат отличный от "default", то он и считается описанием типа данного файла - т.е. либо $text, либо первый из "$precomp $compressed", который есть в текущем алгоритме сжатия

2.4 в противном случае типом файла считается тип, полученный из arc.groups (см. алгоритм выше), но если он входит в число автодетектируемых (т.е. $text, $precomp или $compressed), то он заменяется на $binary, т.е. по факту он попадёт в группу по умолчанию (поскольку $binary обычно не определён)

 

[Булат Зиганшин]

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

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

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

UPDATE: выдвигаю такую идею - в arc.groups писать в заголовках таких групп например "$jpg $precomp $compressed". и при определении данных в файле как $compressed - freearc должен смотреть на заголовок такой группы целиком и делать вывод - раз в ней $compressed упоминается, значит эти данные могут выглядеть как несжимаемые и это не мешает поместить их в группу $jpg или $precomp, если такая есть в выбранном методе сжатия

а для html-файлов заголовок группы может быть к примеру "$xml $text". и определив данные в файле как текстовые, freearc тем не менее должен помещать такой файл в группу $xml, если она есть в выбранном методе сжатия