» FreeArc (часть 4)

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

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

Не удивлён.Как и многие здесь,давно слежу за этим замечательным продуктом.Жмёт хорошо и быстро - просто очень долго автор его готовит. Понимаю, продукт бесплатный,держится на голом энтузиазме автора - за что ему , конечно, респект. Просто, может, не нужно ему заморачиваться слишком сложными итерациями...научно и долго всё очень.А вот бы...попроще...без Линукса....сугубо имхо.... С Новым Годом всех!

В первом случае случае (без rep) разница 5%, во втором - вдвое меньше. Вот об этом я говорю.
А если взять rep +xtor:6:4m:h8m?

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

во-первых, я считаю разницу от размера сжатых данных. далее - сравни:

D:\Testing>C:\Testing\rep\017\fazip rep:64+4x4:tor:6:8m dll100.dll nul
100%: 100,000,000 -> 31,352,957: 31.35% Cpu 18 mb/s (5.288 sec), real 94 mb/s (1.014 sec) = 522%

D:\Testing>C:\Testing\rep\017\fazip rep:64+4x4:lzma:8m:fast dll100.dll nul
100%: 100,000,000 -> 29,434,451: 29.43% Cpu 7 mb/s (14.492 sec), real 43 mb/s (2.236 sec) = 648%

D:\Testing>C:\Testing\rep\017\fazip rep:64+4x4:lzma:normal:8m dll100.dll nul
100%: 100,000,000 -> 27,779,433: 27.78% Cpu 3 mb/s (31.871 sec), real 22 mb/s (4.293 sec) = 742%


как видишь, lzma:fast находится посредине между lzma:normal и tor:6 и по сжатию, и по времени работы, т.е. обеспечивает формирование равномерной линейки методов. в третьих, в tor встроен упрощённый аналог delta, lzma же надо использовать вместе с ним, и тогда разница становится ещё больше:

D:\Testing>C:\Testing\rep\017\fazip rep:64+delta+4x4:tor:6:8m dll100.dll nul
100%: 100,000,000 -> 31,144,107: 31.14% Cpu 18 mb/s (5.179 sec), real 72 mb/s (1.325 sec) = 391%

D:\Testing>C:\Testing\rep\017\fazip rep:64+delta+4x4:lzma:8m:fast dll100.dll nul
100%: 100,000,000 -> 28,523,697: 28.52% Cpu 7 mb/s (13.634 sec), real 40 mb/s (2.357 sec) = 578%

D:\Testing>C:\Testing\rep\017\fazip rep:64+delta+4x4:lzma:normal:8m dll100.dll nul
100%: 100,000,000 -> 26,980,494: 26.98% Cpu 3 mb/s (31.637 sec), real 22 mb/s (4.435 sec) = 713%

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

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

Цитата:

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

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

Bulat_Ziganshin
Цитата:

тебя не устраивают исходники, которые я публикую с альфа-версиями?

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

QSQ
По большому счету кроме многотомности и возможности создавать recovery-volume FreeARC имеет все базовые, необходимые для повседневного использования фичи.

Да, он по сей день экспериментальный, каким и был с момента публикации первой паблик-версии почти 6 лет назад на форуме compression.ru. И, вероятно, так и останется экспериментальным навсегда.

Плюс не стоит забывать, что на дворе не 1993-й, а 2013-й год, всё актуальнее смарты и планшеты, на которых классический PC-шный архиватор, да ещё не совместимый ни с чем, банально никому не нужен.

Что касается "да кому это интересно" - ответ простой: автору И ещё сотне-другой энтузиастов компрессии, которые готовы им регулярно пользоваться (а не по принципу скачал - запустил разок-другой и забыл).

Когда над программистом не стоит менеджер и не "пинает" его, что к такому-то сроку надо реализовать и отладить вот такой-то функционал, программист будет делать не то, что нужно кому-то, а то, что интересно в первую очередь лично ему. FreeARC - как раз такой случай.

Так что твои возмущения непонятны.

там банальная опечатка, я её уже поправил

Добавлено:
кстати, мы переехали на новый сервер, можно протестировать его скорость по http://freearc.org/download/refal.rar

Bulat_Ziganshin


Цитата:

как видишь, lzma:fast находится посредине между lzma:normal и tor:6 и по сжатию, и по времени работы, т.е. обеспечивает формирование равномерной линейки методов

Согласен.
Это и есть примерно мой вариант.

Добавлено:
Только шаг в 2 раза слишком большой

Bulat_Ziganshin

Цитата:

кстати, мы переехали на новый сервер, можно протестировать его скорость по http://freearc.org/download/refal.rar

В один поток - 950кБ\с, а для несколько потоков файлик очень маленький.

Цитата:

на которых классический PC-шный архиватор, да ещё не совместимый ни с чем, банально никому не нужен.

На PC Freearc может быть превосходным бесплатным мультимедийным архиватором, в отличие от всяких там 7zip, когда автор сделает сжатие jpeg без precomp (там сейчас баг, jpeg через precomp сжимается сильно хуже чем без), и добавит сжатие mp3 из коробки (хоть packarc, хоть mpz через открытую dll). Бесплатных конкурентов в этой области нет, а даже и среди платных никого толком нет, кто умеет делать сжатые бэкапы через опцию --sync. Вот она, эта ниша, бери, не хочу.
Но автор уже полгода игнорирует эти пожелания.

Profrager
согласен. собственно, вопрос был в том, нужно ли это кому-нибудь. раз желающий нашёлся, постараюсь сделать фильтрованный репозиторий hg. можно и svn, но там в любом случае будет более бедное, линейное дерево коммитов


Цитата:

Это и есть примерно мой вариант.

ну да? ты вроде предлагал заменить lzma:fast на tor:6

ну, могу с тобой поделиться http://freearc.org/download/testdata/MsOfficeBCJ.7z

хотя мне и рефала хватило - 2 мбайт/с в одном потоке и 10 в 5 потоков

В основном проблема между методами tor:6 и lzma:fast. Здесь зазор заполнять нечем.

Добавлено:
У меня
84 = rep:1gb+4x4:tor:6:4mb:h8mb
85 = rep:1g+xlzma:4mb:h512k:fast:128:mc8

Где я пытался сколько можно ускорить Lzma:fast

Добавлено:
Здесь перечислял:
http://forum.ru-board.com/topic.cgi?forum=5&topic=35164&start=1260#19

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

это способ я думаю не будет лишним

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

Ваше мнение?
http://sourceforge.net/projects/sevenzip/forums/forum/45797/topic/3327567

The unarchiver project has an implementation of WinZip JPEG compression.
http://code.google.com/p/theunarchiver/source/browse/#hg%2FXADMaster%2FWinZipJPEG

kalpak,
FreeArc - это архиватор, а не искусственный разум да и думаю что бы это реализовать надо не хило времени.

Цитата:

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

что именно доделать и кому отдать? если речь о многотомности, то это недолго, а 7-zip имхо имеет GUI не лучше моего (т.е. в чём-то лучше, в чём-то хуже)

kalpak
подобная идея была немного в другом варианте - чтобы при перепаковке (команда ch) не перепаковывать неизменившиеся методы в начале цепочки. скажем, при перепаковке из rep:96m+lzma:64m в rep:96m+lzma:32m он распаковывал lzma:64m и затем направлял данные сразу на lzma:32m

Bulat_Ziganshin

Цитата:

если речь о многотомности, то это недолго

Дык уже не первый год ждем. Даже странно, что в FA такой стандартной, но часто используемой фичи до сих пор нет.

UriF
записал в планы на 0.75, заодно и wavpack делать придётся. кстати, имей в виду - там только распаковка

Цитата:

Дык уже не первый год ждем

автор просто очень часто отвлекается на всякую фигню: то ему захотелось precomp и srep прикрутить (хотя до сих пор ни то ни другое не работает нормально), то ему стал неожиданно интерфейс не нравиться, то с какой-то радости дельта стала медленно работать и ее сверхважно нужно было обновлять... А в планах написано, что в 0,7 версии должна быть реализована полная поддержка zip, rar, 7z и других архивных форматов и все! Так это уже фиг знает сколько времени как реализовано! неужели нельзя тупо исправить баги в этом направлении и выпустить финалку?

А тем временем 95.33% пользователей сидят на последней стабильной версии и ждут 0,7 версию! Вам не кажется что это как-то неправильно, делать столько времени beta версии для 5% пользователей и полностью не обращать внимание на другие 95%?


Цитата:

если речь о многотомности, то это недолго

Извините меня, но недолго в измерении ФА это годы! Через такое время эта функция нафиг никому не будет нужна. Тай мне лично за годы пользованием ФА эта функция ни разу и не понадобилась, хотя ее обязательно нужно сделать.

Не отвлекайтесь на добавление дополнительного функционала, сделайте уже основное! Выпустите 0,7 с тем функционалом что есть и беритесь за многотомность.

Bulat_Ziganshin

Цитата:

и 10 в 5 потоков

поймал себя на мысли, что предел скорости у себя не увижу, нужен кто-нить у кого канал 1Гбит\с или более.

vasulpr
QSQ
ребята, Вы немного веткой ошиблись
Большая просьба, думаю не только от меня, плз, перенесите сие "флеймовое" обсуждение в отдельную ветку!

У меня архив проходит тестирование, но при распаковке происходит ошибка. Это ведь не нормально? (FA 0.67a)

Да! Да и ещё раз таки да! Вот они, нужные слова,которые я не мог подобрать автору фа. Коротко и ясно!

vasulpr
Полностью поддерживаю!!!!