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

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

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

Widok (23-11-2010 11:37): Лимит страниц. Продолжаем здесь  Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 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 101 102 103 104 105 106

   

Widok



Moderator-Следопыт
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

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


Официальный сайт | Скриншоты | Лента новостей
Документация на консольную версию | Документация на GUI версию
Сообщество пользователей FreeArc | Вики | Трекер (рассылка по ошибкам)
Проект на SourceForge.net | SVN-репозиторий | Поддержка InnoSetup
Обсуждение на encode.ru (англоязычное)

Скачать последний релиз - FreeArc 0.666 от 20 мая 2010 г. Что нового: ускорение работы в 1.5-2 раза благодаря новой технологии многопоточного сжатия, распаковка архивов многих форматов используя технологии 7-zip, запуск файлов из архива, исправлены все проблемы интеграции с Explorer (подробнее)
 
Текущая альфа версия: 0.67 - загрузка | список исправлений | блог

FAQ по FreeArc

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

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

    Родственные темы:
  • Inno Setup плюс внешние упаковщики - использование архивов FreeArc в инсталяторах
  • Пережатиe/Pекомпрессия/Oптимизация файлов для лучшего сжатия - "а как сжать ещё лучше?"
  • FreeArc и Unix - для альтернативно одарённых
     
    Другие архиваторы:
  • WinRAR
  • 7-zip

  • Всего записей: 24190 | Зарегистр. 07-04-2002 | Отправлено: 19:15 07-09-2009 | Исправлено: Bulat_Ziganshin, 18:34 26-07-2010
    Bulat_Ziganshin

    Silver Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Ghost2004
    помести сегодняшние arc.exe и facompress.dll в один каталог и дай в нём команду arc a a -mex5t. у меня: Подробнее...

    Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 13:40 30-11-2009
    egor23



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

    Цитата:
    у меня

    хм
    запустил на Win7 работает
    а WinXP не работает
     
    Добавлено:

    Цитата:
    а WinXP не работает

    также не работает и на WinXP x64

    Всего записей: 3832 | Зарегистр. 03-11-2003 | Отправлено: 16:00 30-11-2009
    Bulat_Ziganshin

    Silver Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    new version:
     
        * fixed problem with registering ArcShellExt-64.dll

    Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 17:33 30-11-2009
    Bulat_Ziganshin

    Silver Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    http://freearc.org/download/research/srep08.zip updated: added Linux executable

    Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 20:31 30-11-2009
    Bulat_Ziganshin

    Silver Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    насчёт -mex5t: выяснилось что facompress.dll не грузится в xp-32, хотя прекрасно работает в vista64 и win7-32. думаю, в чём может быть дело... может и не в самих ОС, а каких-то конкретных настройках моих экземпляров..
     
    отпишите ваши ос и работает или нет -mex5t

    Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 23:03 30-11-2009
    Ghost2004

    Junior Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Bulat_Ziganshin
    Насчёт srep08 - я правильно понимаю, существует вероятность около 10^-40 (т.е. ~2^-128) для 2x512 mb хеша (+1 gb), что в файле обнаружится некорректное совпадение, и ещё 10^-73 - (2^-256), что и md5 его не заметит, и не сообщит об некорректном блоке в процессе декомпрессии?  
     
    Тогда стоит добавить в arc.ini метод не как srep, а srep08 (и вписать на данный момент srep=srep08) - всё таки даже такие бесконечно малые вероятности могут взять и случиться вопреки всему ... Так что в следующих версиях с этим надо что-то сделать.
     
    Проще всего, в качестве быстрой заплатки, сделать проверку на такую ошибку на стадии компрессии - добавив декомпрессию после каждого сжимаемого блока на 8 mb, и сравнив исходного сжимаемый блок, с блоком после компрессии-редекомпрессиии (как оно делается в видео-кодеках, хотя там считается разница).
     
    В таком режиме даже md5 считать не надо. Просто по скорости декомпресии у меня выходило 15-25 Мб/c, а вот скорость компрессии была Cpu 5.332 mb/sec, real 3.800 mb/sec - на тех 23 Гб, с l512 (а декомпрессия давала 15 Мб/с). Впрочем, на прошлых 7.5 Гб данных с с l16kb она могла достигать до Cpu 19.196 mb/sec, real 14.998 mb/sec - при декомпрессии в 20.236 mb/sec. На меньших длинах было вот что:  
     
    l128 - Cpu 7.160 mb/sec, real 6.477 mb/sec - компрессия, 21.505 mb/sec - декомпрессия.
    l256 - Cpu 7.915 mb/sec, real 6.465 mb/sec - компрессия, 24.134 mb/sec - декомпрессия.
    l256 для уже сжатых srep -l256 данных - Cpu 5.335 mb/sec, real 4.661 mb/sec против 27.547 mb/sec
    l512 - Cpu 9.948 mb/sec, real 8.859 mb/sec при 23.844 mb/sec декомпрессии.
     
    Так что такой подход уменьшил бы (в теории) скорость сжатия с 9 до 6 Мб/с, а с 3.8 лишь до 3.1 - зато при декомпрессии md5 считать бы не требовалось (и скорость cpu возросла бы со 150 до 400-500 Мб/c - хотя она не особо там важна, разве что для очень быстрых SSD). Но главное, тот бесконечно малый шанс на ошибку пропал бы совсем. Хотя то - временная мера, возможно и правда лучше нечто подобное проделывать не с проверкой md5 8 Мб-ного блока, а на более ранней стадии компрессии, при поиске совпадений... Но это, должно быть, куда труднее сделать. А режим замедленной компрессии (с проверкой не по md5, а побайтовым сравнением) можно вообще включать особым ключом.
     
    С другой стороны, нечто подобное может иметь смысл лишь при интеграции srep в сам freearc в качестве препроцессора - а к тому времени и в srep может появится возможность проверять совпадения точнее. А так srep сейчас только для тестирования - так что хватило бы ключа -t в freearc'е .
     
    Добавлено:
    У меня WinXP 32-bit SP2. Пока пробовал со включённым /3G (mex5t не работает), завтра попробую с выключенным. А что ещё нужно описать?

    Всего записей: 51 | Зарегистр. 02-01-2008 | Отправлено: 23:10 30-11-2009 | Исправлено: Ghost2004, 23:14 30-11-2009
    CTACKo

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

    Цитата:
    архив. но подожди сегодняшнего обновления проги, попробуешь с новой dll, я там исправил выделение памяти в tta
    дык чето не вижу оного обновления... куда смотреть?
    как была 3.4 последней так и осталась...

    Всего записей: 180 | Зарегистр. 05-09-2008 | Отправлено: 00:24 01-12-2009 | Исправлено: CTACKo, 00:25 01-12-2009
    Bulat_Ziganshin

    Silver Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    CTACKo
    http://forum.ru-board.com/topic.cgi?forum=5&topic=31386&start=0&limit=1&m=1#1
     

    Цитата:
    насчёт -mex5t: выяснилось что facompress.dll не грузится в xp-32

    я разобрался в чём проблема, хотя пока не нашёл решения
     

    Цитата:
    я правильно понимаю, существует вероятность около 10^-40 (т.е. ~2^-128)

    sha1: 160 бит, md5: 128 бит. вероятность сбоя в памяти гораздо больше. а то что ты не доверяешь md5, но при этом доверяешь crc-32, вообще наводит на грустные размышления
     
    вообще, я с примерно теми же рассуждениями (только с упором на потребление памяти, а не сбои в sha1) собрался делать следующую версию. если скорость распаковки нас устраивает, то почему бы не делать то же самое при сжатии?
     
    т.е. коротко говоря, я выкидывааю sha1, заменяю crc-32 на crc-64 и тем самым требования к памяти сократятся ещё вдвое. упаковка может стать медленней для больших L, но только в тех случаях, когда и распаковка - не сахар. поэтому нынешний вариант имеет смысл только при упаковке на машине с куда меньшй памятью, чем распаковывающая
     
    Добавлено:
    new version:
     
        * fixed attempt to run 64-bit ArcShellExt dll on 32-bit OSes

    Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 00:51 01-12-2009 | Исправлено: Bulat_Ziganshin, 00:51 01-12-2009
    egor23



    Silver Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Bulat_Ziganshin
    Star Ocean: The Last Hope [PAL/ENG] [3-DVD9] xbox 360
    изначально iso пожаты были rar Скоростной размер в скобочках
    s-so1.iso 7475.5МБ - (rar 6826.3МБ)
    s-so2.iso 7475.5МБ - (rar 6797.2МБ)
    s-so3.iso 7475.5МБ - (rar 6854.9МБ)
    итого 22426.5МБ(21.9ГБ) - (rar 20478.4МБ(~20ГБ))
     
    по одиночке
    rep:1024m
    s-so1.iso - 5716.5МБ
    s-so2.iso - 5146.2МБ
    s-so3.iso - 5569.2МБ
    в сумме = 16431.9МБ
     
    srep
    s-so1.iso - 5478.1МБ
    s-so2.iso - 4950.5МБ
    s-so3.iso - 5415.0МБ
    в сумме = 15843.7МБ
     
    вместе
    rep:1024m
    заtarенные 1+2+3 - 16432.0МБ
     
    srep
    заtarенные 1+2+3 - 12528.4МБ
     
    Во время распаковки srep, система упала в BSOD (WinXP SP2)
    0x0..0D3
    rdbss.sys
     
    тестирование проходило
    1. Перезагрузка
    2. Запуск bat
    3. прошло две упаковки (rep, srep), при распаковке srep получил BSOD, распаковаться успело 2.9ГБ
    повторный запуск распакоки srep прошёл нормально
     
    лог заtarенные..
     

    Цитата:
    вообще, я с примерно теми же рассуждениями (только с упором на потребление памяти, а не сбои в sha1) собрался делать следующую версию. если скорость распаковки нас устраивает, то почему бы не делать то же самое при сжатии?

    что Вы имеете ввиду?
    сейчас при упаковке данные по содержимому сравниваются?
     
    Добавлено:
    Ghost2004

    Цитата:
    23516091904 -> 13137095188
    22426.693 Мб -> 12518.974 Мб

    опечатка
    22426.693 Мб -> 12528.51 Мб

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

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

    Цитата:
    сейчас при упаковке данные по содержимому сравниваются?  

    нет, по sha1
     

    Цитата:
    Во время распаковки srep, система упала в BSOD (WinXP SP2)
    повторный запуск распакоки srep прошёл нормально  

    думаю, перегрузка i/o системы, пиши репорт в ms
     
    Добавлено:

    Цитата:
    заtarенные 1+2+3 - 12528.4МБ

    да, опять же интересует скорость распаковки и объём озу, использовуемый под кеш
    update: сорри, нашёл

    Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 10:03 01-12-2009 | Исправлено: Bulat_Ziganshin, 11:01 01-12-2009
    Ghost2004

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

    Цитата:
    но при этом доверяешь crc-32, вообще наводит на грустные размышления  

    А где я такое говорил, crc32 я eщё больше не доверяю . После тестов декомпрессии я обычно устраивал побайтовое сравнение исходного и распакованного файлов в Total Commander'е с разных физических дисков;). Хотя, конечно, в контрольных суммах я особо не разбираюсь (знаю, что md5 крепче crc32 - но по чистой случайности..) .
     

    Цитата:
    вообще, я с примерно теми же рассуждениями (только с упором на потребление памяти, а не сбои в sha1) собрался делать следующую версию. если скорость распаковки нас устраивает, то почему бы не делать то же самое при сжатии?

    Да, я заметил подобные планы в todo-list srep08.cpp - хотя уже в процессе написания прошлого сообщения. (Читать-то .cpp я умею, а вот с написанием - проблема, мои знания застряли на том, чему успели научить в продвинутой математической школе - т.е. о c/c++ под дос (т.к. оно было лет 10-15 назад) я кое-что знаю (и даже программы писать умел), хотя и не полностью и не системно...).
     

    Цитата:
    sha1: 160 бит, md5: 128 бит. вероятность сбоя в памяти гораздо больше.  

    Да, точно - о втором (сбое в памяти) я как-то не подумал . Короче с этим я конечно лоханулся по полной программе ...
     
    egor23

    Цитата:
    что Вы имеете ввиду?
    сейчас при упаковке данные по содержимому сравниваются?  

    Нет, по контрольным суммам - если я правильно понял, то по sha1. Плюс проверка md5 для каждого исходного блока на 8 Мб - так что если при распаковке выйдут другие данные, то srep08 выдаст соответствующую ошибку... но шансы на это порядка 2^-160*filesize/L (скорее действительно файл побьётся при чтении или записи, или сбой в RAM случится).
     
    И спасибо что поймал опечатку - я тогда усталый был, и наверное что-то напутал...
     
    Тогда переставлю сюда и результаты в сравнимом виде
    1+3+2 -> rep:1gb:h27:a99 - 16429.324 Мб
    1+3+2 -> srep - 12528.510 Мб
     
    Так что с 1+2+3 разница маленькая в обоих случаях - 0.1 Мб для srep и 2.5-3 Мб для rep (тут наверное a99 их выиграли).

    Всего записей: 51 | Зарегистр. 02-01-2008 | Отправлено: 10:54 01-12-2009
    Bulat_Ziganshin

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

    Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 10:55 01-12-2009
    Ghost2004

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

    Цитата:
    да, опять же интересует скорость распаковки  

    Она есть в логе того сообщения - порядка 27 Мб/с .

    Всего записей: 51 | Зарегистр. 02-01-2008 | Отправлено: 10:57 01-12-2009
    Bulat_Ziganshin

    Silver Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    кстати, при тестировании подобного начинается остро ощущаться потребность в поддержке в srep обработки нескольких файлов одновременно

    Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 11:19 01-12-2009
    egor23



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

    Цитата:
    думаю, перегрузка i/o системы, пиши репорт в ms

    крэш дампа нету... (файл подкачки отключен)

    Цитата:
    объём озу

    2.5ГБ-160МБ RAM-drive (свободно около 2ГБ)

    Цитата:
    скорость распаковки

    скорость распаковки зависит:
    от скорости Диска;
    кол-ва свободной памяти

    Цитата:
    нет, по sha1

    ну как изначально и понял.

    Цитата:
    Плюс проверка md5 для каждого исходного блока на 8 Мб

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

    Цитата:
    т.е. коротко говоря, я выкидывааю sha1, заменяю crc-32 на crc-64 и тем самым требования к памяти сократятся ещё вдвое.

    а надёжность как уменьшится?
     
    PS: моё мнение - мнение обычного пользователя, далёкого от тонкостей...
     
    Добавлено:
    Bulat_Ziganshin

    Цитата:
    т.е. коротко говоря, я выкидывааю sha1, заменяю crc-32 на crc-64 и тем самым требования к памяти сократятся ещё вдвое.

    хм
    тоже возможно имеет смысл сделать опциональной выбор метода (или режима работы)
    crc32(и т.п.) как минимум можно использовать для оценки избыточности
    ведь файл на диск не обязательно скидывать?
    кстати для проверки md5(и т.п.) файл нужно обязательно физически распаковывать?

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

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

    Цитата:
    тоже возможно имеет смысл сделать опциональной выбор метода (или режима работы) crc32(и т.п.)  

    ты забываешь о том, что моё время ограничено
     

    Цитата:
    кстати для проверки md5(и т.п.) файл нужно обязательно физически распаковывать?  

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

    Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 12:24 01-12-2009
    egor23



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

    Цитата:
    ты забываешь о том, что моё время ограничено

    это всегда помнится

    Цитата:
    crc32(и т.п.) как минимум можно использовать для оценки избыточности

    или мне показалось...
    какая скорость crc32? а то тут нету
    http://forum.ru-board.com/topic.cgi?forum=5&topic=31386&start=621&limit=1&m=1#1

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

    так ведь считаются куски по 8МБ или я не так понял?

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

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

    Цитата:
    какая скорость crc32?

    в моей реализации - как у md5, в 7-zip - втрое быстрее
     

    Цитата:
    так ведь считаются куски по 8МБ или я не так понял?

    так их ещё распаковать надо ж
     
    Добавлено:
    http://freearc.org/HFCB.aspx
     
    i plan to add tests on huge games (prototype, COD) later

    Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 14:20 01-12-2009
    CTACKo

    Junior Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    arc.exe от 1го Декабря падает при сжатии wav-ок методом tta:m3
     
    --------------------------------------------------------------------------------------------
    arc.exe - Ошибко приложения
    Инструкция по адресу ... обратилась к памяти... Память не может быть read
    --------------------------------------------------------------------------------------------
     
     
    Добавлено:
    та же картина, но возникает позже при просто -mtta
     
    Добавлено:
    wav-ки давать? я их упаковал более ранней версией арка.

    Всего записей: 180 | Зарегистр. 05-09-2008 | Отправлено: 15:42 01-12-2009
    Bulat_Ziganshin

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

    Цитата:
    wav-ки давать? я их упаковал более ранней версией арка.

    ага. и что с новой dll?

    Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 17:07 01-12-2009
       

    Страницы: 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 101 102 103 104 105 106

    Компьютерный форум Ru.Board » Компьютеры » Программы » FreeArc: бесплатный open-source архиватор - Часть 3
    Widok (23-11-2010 11:37): Лимит страниц. Продолжаем здесь


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

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

    BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

    Рейтинг.ru