Перейти из форума на сайт.

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в on-line?
Вход Забыли пароль? Первый раз на этом сайте? Регистрация
Компьютерный форум Ru.Board » Компьютеры » Программы » FreeArc: бесплатный open-source архиватор

Модерирует : gyra, Maz

Widok (30-01-2009 12:03): лимит страниц. продолжаем здесь  Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100

   

Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
FreeArc
бесплатный open-source архиватор для Windows и Linux,
сочетающий высокую степень сжатия и большой набор возможностей

Официальный сайт
Документация он-лайн на консольную версию
Скриншоты / Документация на GUI версию
Страница загрузки
Проект на SourceForge.net / SVN-репозиторий

Последний релиз - FreeArc 0.40 от 1 января 2008 г. Новая версия включает мультимедиа-сжатие, улучшение обычного сжатия, сверх-быструю упаковку в режимах -m1/m2, поддержку произвольных внешних упаковщиков, настраиваемых в arc.ini, 1.5-кратное увеличение скорости работы на 2-ядерных процессорах, навороченное шифрование, полностью работающие плагины для FAR/TC, прямой доступ к архивам в интернете, восстановление архивов через интернет и множество других изменений (полный список)
 
Текущая альфа версия 0.50 от 23 июня 2008 г. Включает GUI с русификацией (описание), автоматическое определение типов файлов, создание SFX, ускорены режимы -m3/m4 и linux-версия, решены проблемы на машинах с 2+ гб ОЗУ, исправлены ошибки в -m1 и -mx (полный список изменений)

MiniFAQ...

Подробное описание используемых алгоритмов
Почему он сжимает лучше и быстрее, чем 7-zip/rar...
Результаты тестов, подтверждающие его крутизну...
Планы дальнейшего развития... (обновлены 15 июня)
Почему для использования 2+ гб памяти желательно установить 64-битную версию Windows
Что подразумевается под "интеграцией с Explorer"  
FreeArc wiki (включая описание формата архива)
External compressors Power Pack
Логотип - объявляется конкурс на иконки для FreeArc

Сторонние оконные программы для работы с FreeArc
wArc - простая и понятная программа управления архивами (требует .NET Framework 2.0)
PeaZip – менеджер архивов с поддержкой большого количества форматов, для Windows и Linux

предыдущая версия шапки

Всего записей: 3408 | Зарегистр. 13-08-2007 | Отправлено: 12:55 13-08-2007 | Исправлено: juvaforza, 20:57 28-01-2009
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
а FreeArc с параметром /LARGEADDRESSAWARE откомпилировать возможно?  

 
откомпилировал - http://www.haskell.org/bz/arc.arc, тестируйте кто сможет  вот пример ком. строки:
Arc.exe a a -lc- -ld- -mppmd:2200m -di -di+$
 
- киньте сюда её вывод
 

Цитата:
Кстати, а почему именно TTA, а не FLAC или WavPack ?  

1. размер исходников. глупо для вспомогательного алгоритма сувать код в несколько раз больший, чем исходники ppmd/lzma
2. простота адаптации. все эти библиотеки нацелены на работу c wav-файлами, сжатие в них - только часть функциональности. я на адаптацияю tta  месяц потратил, с другими было бы ещё дольше
3. flac сжимает хуже, wavpack - вроде тоже чуть хуже
 
вообще, tta не пользуется популярностью из-за своей лицензии - gpl вместо bsd у flac/wavpack

Всего записей: 3408 | Зарегистр. 13-08-2007 | Отправлено: 17:19 02-12-2007
egor23



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Bulat_Ziganshin
про wav и то, что нужен анализ содержимого, хотя бы идущий по ходу упаковки.  
В плане на 0.42 стоит похожий пункт, что имеется ввиду?
 
на сжатие source sounds.gcf можно глянуть здесь
 
Winrar - взят из-за близких значий сжатие\время.
 
source sounds.gcf 975.5Мб
 
tta:m3+rep:1024mb:l16            - 908.9Мб - 128сек
tta:m3:c1:w16+rep:1024mb:l16 - 564.2Мб - 196сек
tta:m3:c2:w16+rep:1024mb:l16 - 617.1Мб - 202сек
 
tta:m3            - 975.5Мб - 80сек
tta:m3:c1:w16 - 572.8Мб - 138сек
tta:m3:c2:w16 - 622.7Мб - 156сек
 
Winrar(макс,4Мбсловарь)          - 618.1Мб - 407сек
Winrar(обычный,4Мбсловарь)    - 618.4Мб - 373сек
Winrar(скоростной,4Мбсловарь) - 810.7Мб - 234сек
 
распакованный source sounds.gcf 975.5Мб
root 949.2Мб (5510 файлов в 186-ти папках)
 
bcs                 - 21кб (8 файлов)
lst                  - 0.3кб (1 файл)
mp3               - 61.8Мб (53 файла)
wav 1ch 16bit - 792.1Мб (5240 файлов)
wav 2ch 16bit - 95.2Мб (208 файлов)
 
tta:m3 +rep:1024mb:l16           - 510.9Мб - 182сек
tta:m3:c1:w16+rep:1024mb:l16 - 539.4Мб - 184сек
tta:m3:c2:w16+rep:1024mb:l16 - 590.7Мб - 188сек
 
tta:m3             - 514.2Мб - 197сек
tta:m3:c1:w16 - 543.6Мб - 193сек
tta:m3:c2:w16 - 595.0Мб - 197сек
 
Winrar(макс,solid,4Мбсловарь)           - 592.3Мб - 425сек
Winrar(обычный,solid,4Мбсловарь)    - 592.5Мб - 395сек
Winrar(скоростной,solid,4Мбсловарь) - 786.4Мб - 274сек

Всего записей: 3832 | Зарегистр. 03-11-2003 | Отправлено: 17:39 02-12-2007
egor23



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Bulat_Ziganshin

Цитата:
откомпилировал - http://www.haskell.org/bz/arc.arc, тестируйте кто сможет   вот пример ком. строки:  
Arc.exe a a -lc- -ld- -mppmd:2200m -di -di+$  
 
- киньте сюда её вывод

 
WinXP Pro SP2 x64, 2.5Гб
чего-то не катит, потолок доступная память (1600 с чем-то)
Arc.exe a a -lc- -ld- -mppmd:2200m -di -di+$ wilsoft200.tar
ARC 0.40 (25.11) Creating archive: a.arc using ppmd:10:2200mb
Memory for compression 2gb, decompression 2gb, cache 1mb
Started: 0.00 secs
Found 1 files, 0 archives: 0.00 secs
Sorted 1 files: 0.00 secs
Joined filelists: 0.00 secs
Compressing 1 file of 215.283.200 bytes: 0.02 secs
  Using ppmd:10:2200mb: 0.02 secs
  Memory for compression 2gb, decompression 2gb: 0.0  0.0%
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

 
WinXP Pro SP2 (32bit), 2.5Гб
Максимум 1237m (при возможных 1562m, в 0.40-prerelease3)
Arc.exe a a -lc- -ld- -mppmd:1237m -di -di+$ wilsoft200.tar
 
Добавлено:

Цитата:
да, кто ещё не в курсе - fa занял три первых места в MFC efficiency rating, как собственно и ожидалось    если бы он протестировал ещё и -m2 - было бы четыре первых места  

То что FreeArc не плох, это мы в курсе.
Хочется, чтобы по "всем статьям" был не плох.

Всего записей: 3832 | Зарегистр. 03-11-2003 | Отправлено: 05:13 03-12-2007
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Егор, а у тебя вообще другие программы больше чем 2 гига могут использовать?
 
Добавлено:

Цитата:
про wav и то, что нужен анализ содержимого, хотя бы идущий по ходу упаковки.  
В плане на 0.42 стоит похожий пункт, что имеется ввиду?  

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

Всего записей: 3408 | Зарегистр. 13-08-2007 | Отправлено: 17:51 03-12-2007
egor23



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Bulat_Ziganshin

Цитата:
Егор, а у тебя вообще другие программы больше чем 2 гига могут использовать?

7-zip 64bit, но это 64bit-ное ПО.
Тут тестирование начнётся на днях..., а тут "малой кровью" ограничение в 2Гб можно обойти, по крайне мере больше ничего не указано что нужно.

Всего записей: 3832 | Зарегистр. 03-11-2003 | Отправлено: 01:16 04-12-2007 | Исправлено: egor23, 01:57 04-12-2007
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
а тут "малой кровью" ограничение в 2Гб можно обойти, по крайне мере больше ничего не указано что нужно.

 
обойти-то я его обошёл, теперь осталось результат протестировать

Всего записей: 3408 | Зарегистр. 13-08-2007 | Отправлено: 02:02 04-12-2007
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
на сжатие source sounds.gcf можно глянуть здесь  

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

Цитата:
Добавьте вывод размеров промежуточных данных в вывод отладочной информации.  
Для тестовых нужд.  

 
сделал
 
и главное - сделал более-менее оперативно обновляющийся индикатор прогресса упаковки. там ещё есть недоделки (в частности, неправильно выводится объём обработанных данных), но полюбоваться на него уже можно. пароль, как обычно - http://www.haskell.org/bz/arc.arc

Всего записей: 3408 | Зарегистр. 13-08-2007 | Отправлено: 01:29 09-12-2007
sabio

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Bulat_Ziganshin
Вы, наверное, уже знаете: http://parchive.sourceforge.net/
Лично для меня эта реализация добавления возможности восстановления для _любых_ файлов стала открытием.

Всего записей: 2898 | Зарегистр. 21-05-2004 | Отправлено: 03:24 10-12-2007
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Вы, наверное, уже знаете: http://parchive.sourceforge.net/  

насколько я понимаю, ICE ECC ещё лучше

Всего записей: 3408 | Зарегистр. 13-08-2007 | Отправлено: 11:45 10-12-2007
sabio

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Bulat_Ziganshin

Цитата:
насколько я понимаю, ICE ECC ещё лучше

Пожалуй. Только вот par лицензиуется под GPL. Значит его можно встроить в FreeArc.
А для ICE ECC нужен отдельный, хоть и бесплатный, экзешник.
 
Надеюсь только, если вы будете использовать именно par для реализации recovery record, все эти *.par2 файлы будут "красиво спрятаны внутри" архива.
 
Добавлено:
Кроме того, ICE ECC есть только под Windows платформу.

Всего записей: 2898 | Зарегистр. 21-05-2004 | Отправлено: 13:16 10-12-2007
Benchmark



Gold Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
sabio

Цитата:
А для ICE ECC нужен отдельный, хоть и бесплатный, экзешник

 
Алгоритм Reed-Solomon подробно описан и его реализация на любом языке программирования не представляет большой проблемы. Какой еще отдельный экзешник ? Зачем ???

Всего записей: 6924 | Зарегистр. 01-10-2002 | Отправлено: 13:37 10-12-2007
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Только вот par лицензиуется под GPL. Значит его можно встроить в FreeArc

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

Цитата:
если вы будете использовать именно par для реализации recovery record

а чем тебя не устраивает существующая xor-схема?

Всего записей: 3408 | Зарегистр. 13-08-2007 | Отправлено: 15:04 10-12-2007
sabio

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Bulat_Ziganshin

Цитата:
а чем тебя не устраивает существующая xor-схема?

Ой, как-то я пропустил этот момент. Звиняйте.
Почему-то был уверен, что возможность восстановления в FreeArc еще только планируется добавить - вот и решил предложить вариант. (хотя, ведь точно помню, что обратил внимание на команду/ключ rr )
 
Кстати, а как сравнима эта "xor-схема" с кодами Рида-Соломона? Наверное, быстрее и проще. А что в плане возможностей восстановления? Просто любопытство.
 
Правильно я понимаю, что если размер записи восстановления, например, 256 байт, то две ошибки по 128 байт смогут быть исправлены только если они находятся на непересекающихся частях "блоков"?
Т.е. получается, FreeArc может исправить ошибку только в одном из каждых n-ых битов блоков размером с recovery record? Два неверных 13-х бита - и архив потерян независимо от размера recovery record?
 
И каковы характеристики обнаружения позиций этих самых сбоев? В свете, например, возможности частичной докачки архива для его восстановления, если recovery record не достаточно.

Всего записей: 2898 | Зарегистр. 21-05-2004 | Отправлено: 16:34 10-12-2007
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
sabio
советую тебе вообще прочесть доку - наверняка узнаешь много интересного
 

Цитата:
Два неверных 13-х бита - и архив потерян независимо от размера recovery record?  

да, при нынешней организации дело обстоит именно так. у меня есть планы по организации другой схемв, где можно удет восстанавливать повреждения в размере до 2/3 от размера recovery record, но при этом не будет такой жёсткой зависимости
 
т.е. сейчас к примеру если записывается 1000 recovery-секторов, то каждый сектор архива отображается на один из них и если повредились два сектора в архзиве, отображающиеся на один и тот же recovery сектор - то уже кранты. а в этой схеме эти 1000 секторов будут разделены на 666 секторов в одном наборе, 200 секторов во втором наборе, 66 секторов в третьем и т.д. так что повреждение станет невосстановимым только когда окажутся "скомпрометированы" все наборы
 

Цитата:
И каковы характеристики обнаружения позиций этих самых сбоев? В свете, например, возможности частичной докачки архива для его восстановления, если recovery record не достаточно.
вниз

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

Всего записей: 3408 | Зарегистр. 13-08-2007 | Отправлено: 21:42 10-12-2007
sabio

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
я не знаю таких утилит, которым можно было бы передать адреса сбойных участков и попросить их перекачать эти участки заново

Речь об этом?
curl -r 0-99 http://...
 
Судя по всему, для характера типичных повреждений файлов (редкие, но большие пачки ошибок) наиболее эффективны восстанавливающие коды Рида-Соломона: http://ru.wikipedia.org/wiki/Обнаружение_и_исправление_ошибок ("Часто применяемые на практике коды с большой корректирующей способностью (такие, как коды Рида-Соломона)...")
Правда, насколько я могу судить по тому, что успел прочитать про par и ICE ECC, вычисление этих кодов довольно ресурсоемкая операция. ICE ECC гордится 2.5 минутами на 600 мегабайт.

Всего записей: 2898 | Зарегистр. 21-05-2004 | Отправлено: 22:22 10-12-2007 | Исправлено: sabio, 22:48 10-12-2007
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
и
Цитата:
Речь об этом?  
curl -r 0-99 http://...  

ага. если fa будет возвращать информацию о сбойной части архива в таком виде (типа "0-1023,4096-8191"), то можно будет написать скрипт, который вызывает curl и затем патчит архив выкачанной информацией. это отличная идея!
 
ну и в сам fa такое неплохо было бы вставить, баго что выкачивать по ftp/http он уже умеет
 

Цитата:
ICE ECC гордится 2.5 минутами на 600 мегабайт.

по сравнению с временем архивации это немного.  5 мб/с - это скорость сжатия в -m2
 

Цитата:
Судя по всему, для характера типичных повреждений файлов (редкие, но большие пачки ошибок) наиболее эффективны восстанавливающие коды Рида-Соломона:  

а чем же xor здесь хуже?
 
вообще, пока этот архиватор напишешь - поневоле станешь экспертом во всём - начиная от алгоритмов шифрования и кончая тонокостями win32 api

Всего записей: 3408 | Зарегистр. 13-08-2007 | Отправлено: 00:17 11-12-2007
sabio

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
а чем же xor здесь хуже?

Может быть (и наверняка), эти самые коды Рида-Соломона не накладывают таких ограничений на расположение сбойных участков, как xor-метод.
 

Цитата:
написать скрипт, который вызывает curl и затем патчит архив выкачанной информацией

Здесь, к сожалению, не все так просто
Например, некоторые серверы не поддерживают частичное скачивание. Тогда curl скачает весь кусок 0-8191, и скрипту придется самому отрезать от этого файла нужную часть.
Кстати, здесь проявляется еще один потенциальный плюс от реализации этого в самом fa: если сервер не поддерживает докачку, то выгоднее будет выполнить один запрос 0-<макс. позиция сбоя> и потом вырезать нужные куски, чем снова и снова качать все с самого начала для каждого сбойного участка.
 

Цитата:
по сравнению с временем архивации это немного

Но, как я понимаю, это будет добавочное время, т.е. сначала архивируем, а потом генерим коды.
Хотя, было бы здорово, наверное, если бы можно было считать их сразу по ходу сжатия - как минимум, на одном проходе по файлу можно было бы сэкономить.
 
Кстати, насчет "умеет выкачивать". Первая проблема, с которой обычно сталкиваются практически все программы, которые начинают что-то качать из инета - настройка прокси. Надеюсь, в fa это хотя бы запланировано (если еще не реализовано)?

Всего записей: 2898 | Зарегистр. 21-05-2004 | Отправлено: 00:34 11-12-2007
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Может быть (и наверняка), эти самые коды Рида-Соломона не накладывают таких ограничений на расположение сбойных участков, как xor-метод.  

да, вроде так
 

Цитата:
здесь проявляется еще один потенциальный плюс от реализации этого в самом fa: если сервер не поддерживает докачку

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

Цитата:
Но, как я понимаю, это будет добавочное время

да это непринципиально, всё равно это немного по сравнению со сжатием
 

Цитата:
Надеюсь, в fa это хотя бы запланировано (если еще не реализовано)?  

реализовано. я об этом тоже в первую очередь подумал

Всего записей: 3408 | Зарегистр. 13-08-2007 | Отправлено: 01:15 11-12-2007
euheny



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Bulat_Ziganshin

Цитата:
вообще, пока этот архиватор напишешь - поневоле станешь экспертом во всём - начиная от алгоритмов шифрования и кончая тонокостями win32 api

у меня вобще куча идей в этом направлении - для их реализации понадобятся ещё некоторые знания  
но я конечно всё понимаю (ничего предлагать не буду) - сам можно сказать топчусь на месте  
 
хотя к примеру: есть идея по сохранению и восстановлению дисковых образов  
имеются ли у тебя знания в этом воросе ?  
(я к примеру не припоминаю ни одного полноценного архиватора способного к этому)

Всего записей: 4181 | Зарегистр. 22-11-2006 | Отправлено: 08:21 11-12-2007
sabio

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
если найти какой-то способ определять, поддерживает ли сервер докачку

Все просто.
Качаем первый кусок и проверяем размер файла на превышение разности стоп - старт.
Правда, если этот кусок довольно далеко от начала, то имеет смысл скачать какой-нть пробный кусочек, типа 32-63.

Всего записей: 2898 | Зарегистр. 21-05-2004 | Отправлено: 10:24 11-12-2007
   

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100

Компьютерный форум Ru.Board » Компьютеры » Программы » FreeArc: бесплатный open-source архиватор
Widok (30-01-2009 12:03): лимит страниц. продолжаем здесь


Реклама на форуме Ru.Board.

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.B0ard
© Ru.B0ard 2000-2024

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru