FreeArc (Win32)

FreeArc (Win32) 0.67

Нет прав для скачивания

toolame

Старожил
Проверенный
компрессия не работает через гуи 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 режим? чот я туплю
 
Последнее редактирование:

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

Developer
Модератор
Булат, привет. А можно ли сделать чтобы 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'овского
 
Последнее редактирование:

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

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

toolame

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

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

Developer
Модератор
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 и т.д.
 

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

Developer
Модератор
скорость диска ~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?
 

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

Developer
Модератор
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
 

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

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

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 обычно не определён)
 

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

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

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

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

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

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