» FreeArc (часть 4)

Цитата:

А, это Skymmer делал.

Надо же, даже необходимую dll в инпуте exe поменял

Добавлено:
vasulpr
http://www.sqx-archiver.org/

ruduk
ну так потому как в 7z только lzma,ppmd эффективны да и нету там возможности подкл. внешние архиваторы.
а тут очень гибкий архиватор
ну наверное кроме ppmd для текста и lzma для остального хватит, правда тут еще есть препроцессоры разные так что все равно сложная задача

ИМХО: архиватор не получит широкого признания до тех пор пока не сделаете удобный GUI и поддержку многотомности. Для обычного пользователя важнее удобство чем "немного лучшее сжатие".

Bulat_Ziganshin

Цитата:

могу объяснить эффект только тем, что диск в этом месте "протёрся"

ну это проверить можно, виктория или т.п. Вам в помощь.
посмотрел s-so123_512.srep (повезло что ещё не заменил на новый), так там всё красиво с поверхностью.
так что если дело в HDD, то наверно не в поверхности дело.

kalpak
У меня была идея чтобы (перед сжатием) анализировать какие у сжимаемых файлов расширения и, на основе этого анализа, составлять "свой" arc.groups, в котором были бы только расширения файлов, которые сжимаются, и методом перекидывания определенных расширений файлов между группами $text, $binary, $default, ... каждый раз сжимать FreeArc'ом методом [-max] и с отключенной опцией "Авто-определение типов файлов".
Сжимать сразу файлы всех расширений не нужно, сжимать сначала только файлы какого-то одного расширения.
Наименьший архив даст "правильный" arc.group -файл, в котором можно будет увидеть в какой группе были те или иные расширения файлов, что поможет выбрать наиболее эфективные цепочки методов.
Потом переходить к другому расширению... вроде того как работает Ultra7z.
Конечно никакого анализатора я не писал (ибо незнаю как), я просто сжимал пару раз одни и те же файлы, но расширения сам вписывал в разные группы. Выигрыш в размере архива получался в лучшем случае от 2 до 3 % меньше по сравнению с сжатием, когда опция "Авто-определение типов файлов" была включена. А в остальных случаях даже 20% увеличение размера.
Т.е. то, как сжимать файл, пускай выбирает сам FreeArc.

Fossius
Сто раз писали "Предлагайте варианты для гуя". И так понятно, что над этим надо работать.
Булат посмотрите пожалуйста в сторону PeaZIP, в стиле обычного проводника винды - это удобно и привычно. А опционально можно сделать в духе винрара.

Bulat_Ziganshin
1. так ты отвечай своевременно сразу на мессаги, тогда и не будут они повторяться.
2. я что-то противоправное спрашиваю или правила какие-то нарушаются, чтобы игнорить мои мессаги?

3.
Цитата:

1. а зачем там спрашивать? идея именно в том, чтоб предоставить распакованные файлы для setup.exe, а он уж дальше как нужно разбросает. и вообще лучше использовать IS
2. rtfm нет поскольку в нём нечего описываать

да я в курсе как работает модуль этот, но нужно немного подредактировать, чтобы запускался setup.exe, а остальльные файлы просто распаковывал, думаю знающим программистом это не составит труда такое сделать. кто сможет подредактить?

Fossius
Вопрос привычки.
Мне GUI нравится больше, чем у многих конкурентов (например, 7z).
А Вы вывод сделали с первого раза?

Bulat_Ziganshin

Цитата:

могу объяснить эффект только тем, что диск в этом месте "протёрся"

решил проверить гипотезу, но на RAM-drive, все файлы "лежат" на RAM-drive:
RAM-drive 1200МБ
xcmd_split.TAR.pcf 933МБ
xcmd_split.TAR.pcf.srep295_l64_a4 110МБ
Методика:
делаем распаковку с -nomd5, после проверяется md5 полученного файла.
srep295.exe -d -nomd5 xcmd_split.TAR.pcf.srep295_l64_a4 xcmd_split.TAR.pcf

Что представляет из себя файлик - xcmd_split.TAR.pcf.srep295_l64_a4
srep295.exe -m3f -l64 -a4 xcmd_split.TAR.pcf xcmd_split.TAR.pcf.srep295_l64_a4
srep295.exe -d -nomd5 xcmd_split.TAR.pcf.srep295_l64_a4 nul
Ratio: 978388288 -> 114967199: 11.75%. Cpu 182.556 mb/sec, real 171.049 mb/sec. Matches 0 67098 3299595, I/Os 0, RAM 0/21, VM 0/0, R/W 0/0

Запустил тест примерно в 7:00, поставил на паузу в 13:30, т.е. прошло 6.5часов, 1300 проходов.
В итоге получилось два сбойных прохода:
772_xcmd_split.TAR.pcf в 10:56
804_xcmd_split.TAR.pcf в 11:06

fc /b w:\xcmd_split.TAR.pcf 772_xcmd_split.TAR.pcf
Сравнение файлов W:\xcmd_split.TAR.pcf и 772_XCMD_SPLIT.TAR.PCF
2D35B6E0: 00 CC
2D43A71B: 00 CC
2D4D0778: 00 CC
2DD8FAE9: 00 CC
2DD93038: 00 CC
2DD930E3: 00 CC
2DD9B49D: 00 CC
2DE50932: 00 CC

fc /b w:\xcmd_split.TAR.pcf 804_xcmd_split.TAR.pcf
Сравнение файлов W:\xcmd_split.TAR.pcf и 804_XCMD_SPLIT.TAR.PCF
2DD03C20: 00 80
2E00BA62: 00 80

fc /b 772_xcmd_split.TAR.pcf 804_xcmd_split.TAR.pcf
Сравнение файлов 772_xcmd_split.TAR.pcf и 804_XCMD_SPLIT.TAR.PCF
2D35B6E0: CC 00
2D43A71B: CC 00
2D4D0778: CC 00
2DD03C20: 00 80
2DD8FAE9: CC 00
2DD93038: CC 00
2DD930E3: CC 00
2DD9B49D: CC 00
2DE50932: CC 00
2E00BA62: 00 80

Bulat_Ziganshin
Насколько я понял ФА определяет тип файлов по их расширению, но часто расширение файла не совпадает с его содержанием.
Но есть такая утилитка которая независимо от расширения правильно определяет тип файла, если ее интегрировать в ФА то можно просто получить халявный прирост сжатия.

Очень хотелось бы увидеть ее в ФА, хотя бы опционально. Что скажите?

Bulat_Ziganshin
c i/o можно будет ли в будущем работать? а то на последней FreeArc-LZMA.exe жуткие лаги

Fossius,
консоль рулит.

egor23
логично для сравнения запустить так же распаковку rar -kb. и ещё распаковку 32-битным srep, ok?

vasulpr
ФА использует файле групп
а то что с расширением xxx имеет тип не подходящий для группы - это разве проблема архиватора
это хитрость и проблема пользователя, хотя я не знаю когда бы это расширение не совпадало с его содержимым
даже если .dat файл это фильм или не фильм то для него используется lzma
откуда такой пессимизм ?можно примеры, которые часто встречаются, потому как для редких случаев это не реентабельно

тем более можно самому предложить свой файл групп или изменить существующий
а ФА делает анализ но только кажется на проверку мультимедия

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

Bulat_Ziganshin

Цитата:

и ещё распаковку 32-битным srep

и так 32-битный, точнее 32i

Цитата:

ак же распаковку rar -kb

добавил, но тесты завтра утром планирую запустить
а на ночь поставить memtest гонять

Snoopak96
какое i/o, какие лаги???

vasulpr
Булат знает что такое TrID - http://forum.compression.ru/viewtopic.php?p=3799#p3799

Bulat_Ziganshin
ты ПМ читаешь ?

Bulat_Ziganshin
Если допустим в arc.ini lzma прицеплен так:

Код:
[External compressor:lzma]
header = 0
packcmd = FreeArc-LZMA-x64 e lzma{:option} <stdin> <stdout>
unpackcmd = FreeArc-LZMA-x64 d lzma{:option} <stdin> <stdout>

Цитата:

Но есть такая утилитка которая независимо от расширения правильно определяет тип файла

К сожалению она не может идентифицировать даже FA SFX архивы, ибо нет сигнатур для них в базе.

Кто-нибудь сравнивал степень сжатия и скорость распаковки больших файлов (скорость упаковки не важна) с архиватором 7-zip?

Цитата:

Fossius
Сто раз писали "Предлагайте варианты для гуя". И так понятно, что над этим надо работать.
Булат посмотрите пожалуйста в сторону PeaZIP, в стиле обычного проводника винды - это удобно и привычно. А опционально можно сделать в духе винрара.

Я бы взглянул в сторону HaoZip, и думаю что его создатель может поделиться исходниками т.к. FreeArc и HaoZip нисколько не конкуренты...

Mercedes_Benz
Да.

а нельзя сделать так чтобы при использовании внешних упаковщиков
можно было указывать уже готовый файл с данными
т.е. например precomp создает файл file.pcf
а мы его просто используем в цепочке методов типа такого:
arc a -mprecomp:slow+lzma:fast:128:64mb:mc100 -pfl1:file.pcf
где 1 - это порядковый номер метода сжатия в цепочке алгоритмов
и тогда можно будет ен ждать каждый раз пока например прекомп или среп сделают свою работу
а просто хранить эти файлы
чтобы например потом проверить на них другой метод сжатия (после внешних упаковщиков)

тем более совместно с PrecompInside и SrepInside будет выигрыш в распаковке таких архивов

Fossius
Хао в духе винрара и сделан.
Можно сделать "профи" - показывается в духе проводника, а "лайт" - стиль привычного винрара.

КТО НИБУДЬ ПОМОЖЕТ СДЕЛАТЬ ТАКУЮ ФИЧУ, ЗА ОТДЕЛЬНУЮ ПЛАТУ?

а ты БУЛАТ не пойму че так игноришься, я че не так спращиваю?

оставьте плиз контакты тут или ПМ для связи!

сделал сервер для загрузки файлов напрямую на мой комп: http://freearc.no-ip.org:8080/

andhunt

Цитата:

оставьте плиз контакты тут или ПМ для связи!

контакты написаны в "О программе", пишите письма.

Цитата:

Баг замечен давно был, приходится юзать с промежуточными/временными файлами, багрепорт на такое хз как сделать, если только видео записывать =)  

очень просто - убираешь лишние опции, лишние файлы пока ошибка не перестанет проявляться

http://freearc.no-ip.org:8080/ --> http://localhost:8080/!HFS/~upload

Цитата:

Firefox can't establish a connection to the server at localhost:8080.

или же там что-нибудь с логином и паролем ?

я сделал вариант unarc.dll/sfx, который корректно работает с stdin-to-stdout фильтрами. у меня с srep работает. проверяйте:

http://freearc.org/download/unarc.arc

там два вариант - hide_console вообще не создаёт консольного окна из gui-программы, думаю это именно то что многие давно хотели и для unarc.dll, и для gui sfx, и для самого freearc.exe