» FreeArc: бесплатный open-source архиватор

Цитата:

а 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

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сек

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 не плох, это мы в курсе.
Хочется, чтобы по "всем статьям" был не плох.

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

Добавлено:

Цитата:

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

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

Bulat_Ziganshin

Цитата:

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

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

Цитата:

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

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

Цитата:

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

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


Цитата:

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

сделал

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

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

Цитата:

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

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

Bulat_Ziganshin

Цитата:

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

Пожалуй. Только вот par лицензиуется под GPL. Значит его можно встроить в FreeArc.
А для ICE ECC нужен отдельный, хоть и бесплатный, экзешник.

Надеюсь только, если вы будете использовать именно par для реализации recovery record, все эти *.par2 файлы будут "красиво спрятаны внутри" архива.

Добавлено:
Кроме того, ICE ECC есть только под Windows платформу.

sabio

Цитата:

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

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

Цитата:

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

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


Цитата:

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

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

Bulat_Ziganshin

Цитата:

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

Ой, как-то я пропустил этот момент. Звиняйте.
Почему-то был уверен, что возможность восстановления в FreeArc еще только планируется добавить - вот и решил предложить вариант. (хотя, ведь точно помню, что обратил внимание на команду/ключ rr )

Кстати, а как сравнима эта "xor-схема" с кодами Рида-Соломона? Наверное, быстрее и проще. А что в плане возможностей восстановления? Просто любопытство.

Правильно я понимаю, что если размер записи восстановления, например, 256 байт, то две ошибки по 128 байт смогут быть исправлены только если они находятся на непересекающихся частях "блоков"?
Т.е. получается, FreeArc может исправить ошибку только в одном из каждых n-ых битов блоков размером с recovery record? Два неверных 13-х бита - и архив потерян независимо от размера recovery record?

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

sabio
советую тебе вообще прочесть доку - наверняка узнаешь много интересного


Цитата:

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

да, при нынешней организации дело обстоит именно так. у меня есть планы по организации другой схемв, где можно удет восстанавливать повреждения в размере до 2/3 от размера recovery record, но при этом не будет такой жёсткой зависимости

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


Цитата:

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

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

Цитата:

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

Речь об этом?
curl -r 0-99 http://...

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

и
Цитата:

Речь об этом?
curl -r 0-99 http://...

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

ну и в сам fa такое неплохо было бы вставить, баго что выкачивать по ftp/http он уже умеет


Цитата:

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

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


Цитата:

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

а чем же xor здесь хуже?

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

Цитата:

а чем же xor здесь хуже?

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


Цитата:

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

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


Цитата:

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

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

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

Цитата:

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

да, вроде так


Цитата:

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

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


Цитата:

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

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


Цитата:

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

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

Bulat_Ziganshin

Цитата:

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

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

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

Цитата:

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

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

Цитата:

хотя к примеру: есть идея по сохранению и восстановлению дисковых образов

лучше всего найти программы, которые могут читать/писать образ через stdin/stdout, и реализовать -si/-so в моей программе. adaik, в виндах и юнихе просто открывается псевдо-файл со спец. именем (так что это может работать даже без спецподдержки в архиваторе!); не знаю только как организован прожиг cd/dvd

Цитата:

Все просто.

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

Bulat_Ziganshin

Цитата:

учше всего найти программы, которые могут читать/писать образ через stdin/stdout, и реализовать -si/-so в моей программе.

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

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

всё сделал - как обычно, можете взять новую версию в http://www.haskell.org/bz/arc.arc

итак, выкачиваем http://www.haskell.org/bz/bad.arc, пытаемся распаковать:

arc t bad

получаем сообщение об ошибке

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

arc r bad --save-bad-ranges=bad.ranges

и наконец, используем сам arc чтобы выкачать запорченные сектора с исправной копии и восстановить архив:

arc r bad --download=http://www.haskell.org/bz/good.arc

и проверяем результат:

arc t fixed.bad.arc


альтернативно, вы можете загрузить good.arc, попортить его самостоятельно и восстановить через интернет

заодно я добавил поддержку опций -rr0%/-rr0, которые добавляют к архиву только crc его секторов, что увеличивает архив всего на 0.1%. это бесполезно для самовосстановления, но очень удобно для восстановления через инет - наличие CRC позволяет определить сбойные сектора и перекачать только их при сбоях. именно таким образом создан good.arc



Цитата:

и сохраняю это содержимое обычно не менее одного раза в день

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

Bulat_Ziganshin

Цитата:

всё сделал

Работает.

Т.е. по сути лишь важно, чтобы сервер поддерживал докачку и на нем лежал гарантированно правильный архив. Суперская опция !

Чувствую, по достижении версии 0.42 FreeArc останется без конкурентов

Цитата:

Чувствую, по достижении версии 0.42 FreeArc останется без конкурентов

но выйдет она лет через 100


Цитата:

Т.е. по сути лишь важно, чтобы сервер поддерживал докачку и на нем лежал гарантированно правильный архив. Суперская опция !

причём заметь - designed by community. всей реализации было на пару часов работы

Bulat_Ziganshin

Цитата:

но выйдет она лет через 100

*озадаченно*

А в шапке написано, что на 0.41 и 0.42 уйдет примерно по месяцу работы


Цитата:

причём заметь - designed by community

И это здорово ! Зато какая фича получилась - больше ни в одном архиваторе такой не видел.

Bulat_Ziganshin

Цитата:

заодно я добавил поддержку опций -rr0%/-rr0

поумолчанию !

Цитата:

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

даже притом, что диск заполнен меньше чем на половину сохраненение образа занимае гораздо меньше времени , чем архивирование/копирование его содержимого
плохо что об этом мало кто знает

Цитата:

поумолчанию !

в смысле?


Цитата:

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

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

Bulat_Ziganshin
А нельзя ли выложить архиватор в другом типе архива - у меня не получается распаковать (всё-таки выкладывать архиватор в том же типе архива, который он и должен распаковывать - лёгкий изврат )?

кстати, вопрос ко всем - я хочу ещё сделать --download без параметра, при котором fa будет сам находить, с какого url ему выкачивать оригинал. такую опцию можно будет, в частности, ставить прямиком в arc.ini

мой download master умеет писать URL выкачанного файла в files.bbs/descript.ion и *.txt. у вас есть какие-то ещё варианты?

Добавлено:

Цитата:

А нельзя ли выложить архиватор в другом типе архива - у меня не получается распаковать (всё-таки выкладывать архиватор в том же типе архива, который он и должен распаковывать - лёгкий изврат )?

выложил arc.7z. но вообще-то это странно - у меня arc.arc распаковывается первой prerelease версией

кстати, эти тест-версии не предназначены для реальной работы - они работают существенно медленней из-за улучшенного индикатора поргресса. как только я этот процесс оптимизирую - выпущу следующий prerelease