» FreeArc (часть 4)
Около двух лет наблюдаю за развитием FreeArc.
За это время он не снискал особой популярности среди обычных людей, скорее больше среди репакеров игр. Да, статистика показыват неплохие цифры, но как насчёт реального использования, а не однократной установки?

Понятно, что поддержка разных форматов появилась не так давно, но в ближайшее время вряд ли кто-то перейдёт на Фриарк как основной архиватор.
Опрос здесь же подтверждает

Мне кажется в этой ситуации лучший выход был бы сменить вектор развития.
Как возможный вариант - развитие томов восстановления в виде кодов рид-соломона.
Если получится адекватная замена RAR+PAR(как по скорости, так и по сжатию), то он вполне сможет их вытеснить из usenet'а, а на данный момент не всех устраивает оригинальная пара, по скорости восстановления/создания томов для больших объемов не лучший вариант.
Просьба воспринимать критику в положительном ключе.

Цитата:
Подскажите, делаю распаковку так unarc.exe x files.arc -pPass -o+ -dpC:\path1
видна консоль, её можно скрыть?
да. спрашивай в теме по своему инструменту программирования
Цитата:
ERROR: general (de)compression error in srep:256m
я mem пропустил - сложно догадаться?
Цитата:
И осуществима ли здесь асинхронка вообще?
асимметрия != асинхронность. будь внимательней. думай сам вместо того чтобы задавать тривиальные вопросы
Цитата:
Зачем в новой альфе приписывать арку стандартные параметры для прекомпа? Пиши -mprecomp, а оно его в 042 переименовывает и само добавляет парамы. Теперь при распаковке через анарк длл пишет что метод не поддерживается.
можно конкретней, в чём проблема? у меня такой принцип - "precomp042" и т.п. означают конкретные версии precomp, а "precomp" заменяется на "precomp042" или другую свежую версию. это позволяет сжимать с -m=precomp и не думать, какая там сейчас версия последняя - например, не менять батники
единственное в чём возможно я неправ - это надо перенести определение precomp в стандартный arc.ini
Добавлено:
packMP3 v1.0c release
неужто так трудно запустить программу без параметров и почитать справку?
для удаление файлов после архивирования нужно указать параметр -d (или -df, если удалять надо только файлы, но не папки)
или же вместо команды a (add = добавить) использовать команду m (move = переместить)
а упаковка каждого файла отдельно, как я писал уже в теме 7-zip, делается командой FOR:
for %F in (*.*) do arc a -d "%F.arc" "%F"
(в батнике все проценты надо удвоить - %%F)
Цитата:
это потому что facompress.dll несовместим. скопируй его тоже
Получилось.
Вот результаты с папкой, с которой старый rep1g:h24 работал плохо. Компьютер двухядерный:
Метод время, с Размер
Цитата:
я mem пропустил - сложно догадаться?если досконально знать - то не сложно, а так - увы...
спасибо, поправлю и попробую упаковать
Цитата:
асимметрия != асинхронность. будь внимательнейда, точно.. это уже усталось сказывалась, пардон!
Цитата:
-m9xа как их тогда можно совместить для максимального ассиметричного сжатия?
не использует rep
(в доке искал, но, правда, в упор не вижу ответа на этот вопрос. по ходу, в 0.40, по которому она написана, этого срепа ещё не было что ль)
Добавлено:
Цитата:
я mem пропустил - сложно догадаться?
только что перепроверил, у меня (оказывается) там c указанием параметров всё нормально, "mem" - на месте:
-m9x -i2 -lc- -ld- -di -mc:rep/srep:mem256mb -ag
Цитата:
неужто так трудно запустить программу без параметров и почитать справку?
Не трудно, а может и трудно (без параметров?). Но не начинал я ни с DOS, ни со "Спектрума" ни с 3.1.
Моя первая система Win 98. Поэтому привык к GUI и командную строку недолюбливаю, если не сказать больше...
Да и неудобно это при частом применении
Цитата:
:c128 у меня всегда быстрее старого и сжимает лучше старого варианта (случайные совпадения?). Может быть лучше сделать его по умолчанию?
уже сделал
Добавлено:
кстати, оптимальные настройки rep-препроцессинга для различных режимов многопоточного сжатия:
-m1: rep:257
-m2: rep:65
-m3: rep:33
-m4: rep:96:d4m:s32
unarc.dll: changed meaning of returned value for "overwrite?" and "password?" callbacks; please update your code that makes use of unarc.dll
unarc.dll: full english and russian docs in Addons\Unarc-DLL\readme*.txt
unarc.dll: fixed bug encountered when callback==NULL
SFX/unarc/dll: fixed bugs sometimes preventing extraction of encrypted archives
External: fixed bug - hangup after attempt to execute non-existing external compressor
Новая альфа-версия:arc.ini: удалены устаревшие определения для exe2 и precomp
unarc.dll: изменена трактовка результата, возвращаемого из колбеков "overwrite?" и "password?"; пожалуйста обновите ваш код, использующий unarc.dll
unarc.dll: полная английская и русская документация в файлах Addons\Unarc-DLL\readme*.txt
unarc.dll: исправлена ошибка, возникавшая при callback==NULL
SFX/unarc/dll: исправлены ошибки, иногда препятствовавшие распаковке зашифрованных архивов
External: исправлена ошибка - зависание после попытки выполнить несуществующий внешний упаковщик
так а с графической версией программы проблем-то ещё меньше должно быть - все настройки ведь на виду
вот вам чекбокс для удаления файлов после архивирования (третий снизу):
http://freearc.org/ru/screenshots/freearc-add.png
как (и можно ли) отправить каждый файл в отдельный архив через GUI, я не знаю - никогда не пользовался графической версией
Цитата:
Выложил новый REP для тестов на http://freearc.org/download/testing/newrep.7z
обновил архив - ускорены I/O и сам REP
Цитата:
Выложил новый REP для тестов
Nero-9.2.6.0_trial.tar 1883МБ
arc a a -mrep:1g Nero-9.2.6.0_trial.tar
новый2 rep оказывае нагрузку на дискт сильнее, особенно заметно на фрагментированных файлах
1. фрагментирован 159 частей (забыл дефрагментировать, но оказалось полезно, для последней версии)
старый rep
Compressed 1 file, 1,974,371,328 => 510,572,988 bytes. Ratio 25.8%
Compression time: cpu 36.17 secs, real 60.53 secs. Speed 32,617 kB/s
новый rep
Compressed 1 file, 1,974,371,328 => 514,212,681 bytes. Ratio 26.0%
Compression time: cpu 34.38 secs, real 41.77 secs. Speed 47,273 kB/s
новый2 rep
Compressed 1 file, 1,974,371,328 => 512,900,101 bytes. Ratio 25.9%
Compression time: cpu 23.38 secs, real 61.28 secs. Speed 32,218 kB/s
2. дефрагментирован 1 часть
старый rep
Compressed 1 file, 1,974,371,328 => 510,572,988 bytes. Ratio 25.8%
Compression time: cpu 36.34 secs, real 57.05 secs. Speed 34,610 kB/s
новый rep
Compressed 1 file, 1,974,371,328 => 514,212,681 bytes. Ratio 26.0%
Compression time: cpu 33.70 secs, real 39.64 secs. Speed 49,807 kB/s
новый2 rep
Compressed 1 file, 1,974,371,328 => 512,900,101 bytes. Ratio 25.9%
Compression time: cpu 23.20 secs, real 46.63 secs. Speed 42,346 kB/s
Цитата:
так а с графической версией программы проблем-то ещё меньше должно быть - все настройки ведь на виду
И точно, просто я, открыв главное окно FreeArc, сразу пошёл в "Опции" -- "Редактировать настройки программы", а там ничего такого и в помине нет. Оказуется, доп. опции настроек появляются только при ПКМ на файле/лах и выборе подменю "Добавить в архив". Но вот сохранить эти настройки в профиль и выбирать его по ПКМ на файле/лах, как в WinRAR'е, нельзя.
А каждый файл в отдельный архив можно, отметив на второй закладке этих доп. настроек 1-й чекбокс:

во времена 0.40 у нас были два основных алгоритма - lzma требует 10*dictsize памяти для упаковки и 1x для распаковки, rep - 1x для того и другого
соответственно было две стратегии:
1) максимальное сжатие при заданной памяти для распаковки подразумевало использование только lzma, в целом алгоритм при этом получался асимметричным (скажем 2.5 гб для упаковки и всего 256 мб для распаковки)
2) максимальное сжатие при заданной памяти для упаковки достигалось применением rep+lzma, при этом те же 2.5 гб обеспечивали 1.5 гб словарь rep и 256 mb словарь lzma, а памяти и для упаковки, и для распаковки требовалось 2-2.5 гб
srep имеет совсем иной профиль памяти - порядка 10% от размера словаря и для упаковки, и для распаковки. соответственно, в твоём случае имея 2.5 гб памяти для упаковки и 500 мб для распаковки, мы можем использовать lzma:256mb плюс srep со словарём 25 гб
у тебя xp? диск имеет буфер какого размера? можешь протестировать на файле, целиком влезающем в дисковый кеш? словарь rep можно уменьшить. ещё лучше - с рамдиска на рамдиск
win 7 64bit sp1
i5 4670 + Turbo Boost
16 Gb ОП, файл подкачки 1-2 Гб
т.е., для "lzma:256mb плюс srep со словарём 25 гб" получаем нечто вида:
"-m9x -i2 -lc- -ld- -di -mc:rep/srep:mem2560mb -ag"
, верно?
старый rep
Compressed 1 file, 1,974,371,328 => 510,572,988 bytes. Ratio 25.8%
Compression time: cpu 36.28 secs, real 54.53 secs. Speed 36,206 kB/s
новый rep
Compressed 1 file, 1,974,371,328 => 514,212,681 bytes. Ratio 26.0%
Compression time: cpu 34.11 secs, real 39.69 secs. Speed 49,748 kB/s
новый2 rep
Compressed 1 file, 1,974,371,328 => 512,900,101 bytes. Ratio 25.9%
Compression time: cpu 23.03 secs, real 30.61 secs. Speed 64,502 kB/s
Добавлено:
Bulat_Ziganshin
Цитата:
у тебя xp? диск имеет буфер какого размера? можешь протестировать на файле, целиком влезающем в дисковый кеш? словарь rep можно уменьшить. ещё лучше - с рамдиска на рамдиск
машина старая
WinXP SP2rus
Sempron64 2500+(1868 МГц), RAM 2560Мб (415 МГц)
кэш у диск 16МБ
Nero-9.2.6.0_trial.001 700МБ
arc a W:\a.arc -mrep:700m Nero-9.2.6.0_trial.001
1. данные на HDD (закешированы) - запись на RAM-drive (RAM-drive 288МБ)
старый rep
Compressed 1 file, 734,003,200 => 263,593,371 bytes. Ratio 35.9%
Compression time: cpu 12.56 secs, real 12.80 secs. Speed 57,358 kB/s
новый rep
Compressed 1 file, 734,003,200 => 265,662,180 bytes. Ratio 36.1%
Compression time: cpu 12.36 secs, real 12.58 secs. Speed 58,356 kB/s
новый2 rep
Compressed 1 file, 734,003,200 => 264,563,450 bytes. Ratio 36.0%
Compression time: cpu 8.42 secs, real 8.80 secs. Speed 83,439 kB/s
2. данные на RAM-drive - запись на RAM-drive (RAM-drive 1024МБ)
завтра наверно переделаю с другим RAM-drive
старый rep
Compressed 1 file, 734,003,200 => 263,593,371 bytes. Ratio 35.9%
Compression time: cpu 13.02 secs, real 14.95 secs. Speed 49,087 kB/s
новый rep
Compressed 1 file, 734,003,200 => 265,662,180 bytes. Ratio 36.1%
Compression time: cpu 12.73 secs, real 14.34 secs. Speed 51,172 kB/s
новый2 rep
Compressed 1 file, 734,003,200 => 264,563,450 bytes. Ratio 36.0%
Compression time: cpu 8.88 secs, real 10.31 secs. Speed 71,176 kB/s
3. данные на HDD - запись на другой HDD (RAM-drive 1000МБ)
старый rep
Compressed 1 file, 734,003,200 => 263,593,371 bytes. Ratio 35.9%
Compression time: cpu 12.84 secs, real 17.94 secs. Speed 40,920 kB/s
новый rep
Compressed 1 file, 734,003,200 => 265,662,180 bytes. Ratio 36.1%
Compression time: cpu 11.86 secs, real 17.73 secs. Speed 41,389 kB/s
новый2 rep
Compressed 1 file, 734,003,200 => 264,563,450 bytes. Ratio 36.0%
Compression time: cpu 8.53 secs, real 14.67 secs. Speed 50,028 kB/s
Цитата:
Возникли проблемы с ФА! Апгрейдил систему и теперь ФА не хочет ни паковать ни открывать свои архивы
Во дела! А как апгрейдили? Это только FA начал глючить, всё остальное нормально?
Ты сам ясно дал понять, что во времена 0.40, по которой дока и написана, srep ещё не было (был просто rep, что является чем-то совсем другим). Соответственно, в этой самой "доке" нет даже слова "srep", не говоря уже про то, чтобы о нём что-то найти с ним связаное.
Все упоминания "-mc" сводятся к пункту "Мультимедиа-сжатие", в котором описывается как отключить (!) доп.алгоритмы сжатия, но не задействовать внешний.
Как я уже заметил, по сути arc опирается в основе на алгоритм lzma, а это многое проясняет. Следовательно, теперь я могу более-менее понятным языком для нас обоих сформулировать что мне нужно: максимальное сжатие lzma со словарём 512 Мб + использующий аналогичное количество памяти srep (он, как я пронимаю, обработает схожие данные на расстоянии до 5 гигов, чего мне полностью достаточно), особых ограничений к количеству памяти для упаковки не представляется, но для распаковки допускается выделить полгига, чего для lzma512mb вполне достаточно. Собственно, это и всё, что нужно. Напиши, пожалуйста, как конкретно будет выглядеть строка параметров для этого случая.
Только пожалуйста, не нужно посылать в очередной раз, ибо из-за этих посылательств мы торгуемся уже который день, а толку не появляется.
И ещё по этой же теме. Частенько попадаются репаки игр в этом самом ARC (только расширение хитрые люди на bin меняют) в паре с установщиком. Сначала распаковывается сам arc'овый архив, получаем некий архивчик .srep и потом распаковывается он. Каким способом реализуется подобное извращение?
Цитата:
А как апгрейдили?
Заменил мамку, проц и оперативку. + Переустановка windows
Кстати по моим тестам rep+exe+xtor пакует лучше без увеличения времени чем просто rep+xtor.
Цитата:
Заменил мамку, проц и оперативку. + Переустановка windows
Так это абсолютно новая система! И, теоретически, никакой её связи с FA Portable быть не может.
Та же версия FA Portable должна работать, так же, как и на старой системе. А может в дистрибутиве
FA Portable что-то "побилось"?
srep здесь: http://freearc.org/research/SREP.aspx
комстрока: -m9x -mc$default+srep:mem256m
1. доку читал?
2. но он может быть хуже на не-exe данных. в общем подумаю, может так и сделаю
Не планируете ли поддержать Евгения Рошала, в плане популяризации поддержки BLAKE2, в архивах FreeArc?
Для одиночных или текстовых файлов exe ухудшает сжатие. Есть смысл его добавлять на архив из множества разных файлов.
Это же совсем другое дело!
Спасбо!
Добавлено:
при упаковке с параметрами
a "f:\_HL1_-m9x-lc-ld-_defPsrep256m.arc" "HL1" -m9x -i2 -lc- -ld- -di -mc$default+srep:mem256m -ag"
на 14,3% архиватор споткнулся, ссылаясь на ошибку диска, хотя диск абсолютно исправен, свободно 20 гигов из 60, NTFS.
Последние строки консоли:
Цитата:
Compressing HL1\HLSourceHDC-M2\Half-Life Source HD Cinematic Pack\bin\TrackerU
I.dll
Compressing HL1\HLSourceHDC-M2\Half-Life Source\bin\TrackerUI.dll
Compressing HL1\HLSourceHDC-M2\Half-Life Source HD Cinematic Pack\bin\ServerBr
owser.dll 14.3%
ERROR: write error (disk full?) in compression algorithm srep:mem256m
Добавлено:
при параметрах
a "f:\_HL1_-m9x-defPsrep256m_.arc" HL1 -m9x -i2 -di -mc$default+srep:mem256m -ag"
аналогично:
Цитата:
Compressing HL1\HLSourceHDC-M2\HL2-HL1mod\hl1\bin.old\client.dll
Compressing HL1\HLSourceHDC-M2\Half-Life Source HD Cinematic Pack\hl1\bin\clie
nt.dll
Compressing HL1\HLSourceHDC-M2\Half-Life Source\hl1\bin\client.dll
Compressing HL1\HLSourceHDC-M2\HL2-HL1mod\hl1\bin\client.dll
Compressing HL1\HL1\HL-1111\cl\dlls\cl.dll
Compressing HL1\HL1\HL-1111\cstrike\dlls\mp.dll
Compressing HL1\HL1\HL-1111\decay\dlls\decay.dll
Compressing HL1\HL1\HL-1111\hunger3\dlls\einar.dll
Compressing HL1\HL1\HL-1111\platform\dbghelp.dll
Compressing HL1\HL1\HL-1111\platform\SteamUI.dll
Compressing HL1\HL1\HL-1111\platform\AddOns\checkers\Checkers.dll
Compressing HL1\HL1\HL-1111\platform\AddOns\chess\Chess.dll 14.3%
ERROR: write error (disk full?) in compression algorithm srep:mem256m
Страницы: 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275
Предыдущая тема: Punto Switcher (часть 3)
Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.