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

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в 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
    CTACKo

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

    Цитата:
    дык нет вопросов - давай по старой схеме: я выкладываю архив у себя на фтп, ты качай да изучай, вес - 3Гб.  
    вот ltПодробнее...  
     
    опиши проблему. без лирики.  
     
    а сколько у тебя там wav-файлов? есть подозрение, что память фрагментируется из-за того, что их слишком много. может, для пробы перепакуешь архив с -mc-tta ?

    wav-файлов действительно много: 18.712 в 397 папках.
     
    Описываю проблему еще раз:
     
    Если коротко - при распаковке архива с помощью unarc.dll весрии 3.3 или 3.4 - процесс молча исчезает не завершив работу и прихватив с собой инносетап, т.е. не сообщая ни ему ни системе какой-либо код ошибки. Происходит это во время распаковки wav-файлов. Кроме того скорость распаковки архивов с тта гораздо ниже в версии 3.4 по сравнению с 3.3
     
    Теперь подробнее:
    1) Берем, в данном случае, 6 архивов, пожатых разными способами. Максимальная требуемая ОЗУ для распаковки составляет 384Мб у 3х из них, у остальных - и того меньше. Один архив сжат методом тта+что-то (жал не я), для распаковки требует пару Мб.
    Вот их lt
    Подробнее...
    2) Объединяем эти архивы в один джойном, для чего используем последнию доступную версию фа или одну из более старых.
    3) Все офорляем в инносетап, лепим арк к сетапу и устанавливаем
    4) Во время установки/распаковки:
    если использовать unarc.dll весрии 3.3, визуально доходит до половины распаковки и молча отваливается, т.е. не выдввая никаких предупреждений или ошибок. За собой валит инносетап.
    если использовать unarc.dll весрии 3.4, визуально доходит дальше, но скорость распаковки очень и очень сильно падает, до 1мб/сек или меньше. В этом месте выглядит как зацикливание на распаковке одних и тех же файлов (меряю размер папки с помощью ТС - она колеблется, но цифры одни и те же, сначала рост, затем сброс до той же "начальной" цифры и снова рост) на протяжении где-то 20-30 мин, после чего точно также молча падает.  
     
    Далее, архив "пересобрал" так, чтобы архив с тташными вав-ками был последним. Это решило проблему, но все же с весрсией 3.3 распаковка на вав-ках заметно медленнее чем на других архивах, причем в разы. А версия 3.4 в том же месте вообще dramatically slow! Я просто не выдержал дожидаться полной распаковки. Т.е. выглядит так, что версия 3.4 хуже чем 3.3 в смысле скорости распаковки, по крайней мере тта, но обе версии содержат одну и ту же ошибку.
     
    В связи с вышесказанным есть ли все еще смысл в "для пробы перепакуешь архив с -mc-tta" ?

    Всего записей: 180 | Зарегистр. 05-09-2008 | Отправлено: 00:11 29-11-2009 | Исправлено: CTACKo, 01:19 29-11-2009
    Ghost2004

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

    Цитата:
    второй вопрос - насколько улучшится srep от добавляения точных матчей (сейчас он в отличие от rep матчит только блоками по L байт, выравненными на L-байтную границу)
     

    Не знаю насчёт других данных, но на этих 7.5 Гб результат вышел такой:
     
    srep-16kb+lzma:192mb:max 4.572.251.124 => 3.297.545.899 bytes. Ratio 72.1%        
    Compression time: cpu 8767.70 secs, real 7578.52 secs. Speed 603 kB/s
     
    rep:512+srep-512+lzma 4.002.779.320 => 3.294.577.644 bytes. Ratio 82.3%        
    Compression time: cpu 7674.43 secs, real 6768.63 secs. Speed 591 kB/s
     
    rep:256+srep-512+lzma 3.927.490.696 => 3.294.442.325 bytes. Ratio 83.8%        
    Compression time: cpu 7988.63 secs, real 6647.13 secs. Speed 591 kB/s
     
    rep:256+srep-256+lzma 3.926.065.808 => 3.294.808.056 bytes. Ratio 83.9%        
    Compression time: cpu 7974.75 secs, real 6673.66 secs. Speed 588 kB/s
     
    srep-512+lzma 4.101.289.228 => 3.293.144.163 bytes. Ratio 80.2%        
    Compression time: cpu 7210.52 secs, real 5147.89 secs. Speed 797 kB/s
     
     
    Разумеется, первым четырём разультатам могли мешать множество вкладок файрфокса или симонкей, так что время вышло большее. Но сжимаемость ну просто очень мало пострадала. Даже если матчить болками по 16Кб, выравненными под те же 16 Кб.
     
    При этом l128 - далеко не лучший вариант по любому:
    srep-128+lzma 3.916.538.436 => 3.294.102.320 bytes. Ratio 84.1%        
    Compression time: cpu 8419.50 secs, real 6596.33 secs. Speed 594 kB/s
     
    srep-128+rep:128+lzma 3.879.943.240 => 3.297.288.815 bytes. Ratio 84.9%        
    Compression time: cpu 7724.89 secs, real 6584.84 secs. Speed 589 kB/s
     
    rep:128+srep-128+rep:128+lzma 3.827.112.122 => 3.294.651.845 bytes. Ratio 86.0%        
    Compression time: cpu 9351.99 secs, real 8523.16 secs. Speed 449 kB/s
     
    Тут проход rep-ом даже ухудшил результат...
     
    srep-16kb+rep:512+lzma 4.014.605.104 => 3.297.558.308 bytes. Ratio 82.1%        
    Compression time: cpu 7664.74 secs, real 6389.70 secs. Speed 628 kB/s
    Толку в смысле степени сжатия от rep:512 - даже минус, хотя в смысле времени вроде стало лучше. Вот только результаты в смысле времени у такого rep'а - сводят выигрыш на нет (хотя это конечно из-за a99, которая наверно избыточна):
    srep-16kb->rep:512(:a99) выдаёт 4.572.251.124 => 4.014.604.842 bytes. Ratio 87.8%        
    Compression time: cpu 979.48 secs, real 1350.09 secs.  
     
    Т.е. lzma после srep-16kb даёт cpu 8767.70 secs, real 7578.52, lzma после srep-16kb+rep:512 - cpu 7664.74 secs, real 6389.70 secs. Разница - 1102.96 secs cpu, 1188.82 secs real - примерно столько же, сколько уходит на rep:512:a99:h27:1700mb . И сжимаемость даже ухудшается - хоть и всего на 12 кб...
     
    В результате выходит, что rep после srep'а смысла не имеет - на этих данных и с дожатием lzma:192mb:max:lc8... Хотя можно в принципе посмотреть варианты rep без a99 - да больно оно долго будет, повторять половину тестов... Что можно глянуть, так это srep+lzma:959mb:mc29:h896mb - ведь тут встроена хорошая замена rep. Ещё можно испробовать lc8 к этому - а может, уменьшить mc до 3-ех - для высокой скорости такого lzma. Помимо этого есть ещё вариант rep+srep - он-то как раз вроде выглядит полезнее. Но наверное в фриарк с srep-препроцессором его не встроишь - он должен идти первым при сжатии и последним при распаковке, иначе придётся разбираться с лишним tempfile'ом...
     
    Но в принципе, возможно стоит расчищать место да переходить к тестированию 24 Гб SO4... Ссылку на скачивание сейчас дать не могу - убрали её... Хотя может и можно как-нибудь исхитриться с тем торрентом - DHT ещё работает...
     
    Короче, есть три варианта дальнейших тестов - rep+srep, srep+lzma:959mb или уже переходить к 24 Гб... Что предпочтительнее - второе имеет смысл (ведь моё впечатление от ht4 - rep встроенный в lzma, только matchfinder чуть послабее)?
     
    Добавлено:
    Так, похоже моим результатам в смысле времени и скорости lzma особо доверять не стоит - в последнем сеансе у меня было открыто слишком много окон и вкладок Firefox'а да Seamonkey (а может ещё что в фоне мешало - тот же торрент кажется был всё таки запущен) - а когда их в сумме штук 20-30, то они у самой системы окусывают много ресурсов, и Freearc медленнее работает... Но совсем не использовать инет пока что-то сжимается по два часа на файл, а файлов этих с десяток - для меня уже слишком .  
     
    Вот ещё пара результатов, которые окончательно мне это подтвердили:
     
    srep256+lzma 4.011.245.268 => 3.293.358.015 bytes. Ratio 82.1%        
    Compression time: cpu 9240.61 secs, real 8069.13 secs. Speed 497 kB/s
     
    srep256+srep256+lzma 3.997.881.040 => 3.293.098.543 bytes. Ratio 82.3%        
    Compression time: cpu 9118.75 secs, real 7554.55 secs. Speed 529 kB/s
     
    Причём при сжатии второго файла активности было куда как меньше.

    Всего записей: 51 | Зарегистр. 02-01-2008 | Отправлено: 01:56 29-11-2009
    Ghost2004

    Junior Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Угу, и последнее подтверждение тому факту, что скоростью/врменем lzma я серёзно лоханулся - этот файл сжимался без торрента фа фоне (который у меня всё время в фоне раздаёт, хотя скорость там гуляет от 300 до 1200 Кб/c) и только с 3-мя открытыми окнами броузера (в которых только текст форумов, нету ничего грузящего систему):
     
    rep128+srep128+lzma 3.827.972.128 => 3.294.530.391 bytes. Ratio 86.0%        
    Compression time: cpu 7282.85 secs, real 5258.24 secs. Speed 728 kB/s
     
    Так что из всех моих тестов стоит смотреть только на объём... Который тут меняется в пределах 4 Мб, минимум был srep256x2+lzma - 3 293 098 543 bytes, и на 45 619 байт больший  srep512+lzma. А максимум (с куда более заметным отрывом от остальной группы) дали  
    srep16k+rep:512+lzma - 3 297 558 600
    srep16k+lzma - 3 297 546 174
    srep128+rep128+lzma - 3 297 289 110. Т.е. разница между самым большим и самым малым - 4 460 057 байт, всего лишь 0.14%.  
     
    Думаю, смысла в тестировании rep+srep+rep - вообще никакого, потому что разница там не превышает 4 Мб по сравнению с такими же настройками rep+srep - и она скорее всего станет ещё меньше после lmza.  
     
    Добавлено:
    Так, на ненагуженной системе lzma:959mb:h768mb:mc3 работает чуть ли не быстрее, чем rep:1700mb:a99:h27 . Я прав, что для скорости ht4 очень важно отношение размера хэша к значению mc - т.е. 768mb/3=256 mb тут сильно ускоряет это дело?
    Да, тут обозначение lzma:ht4:mc3=lzma:959mb:h768mb:normal:32:mc3
     
    rep:512+srep-512+lzma:ht4:mc3 - 4.002.779.320 => 3.320.549.950 bytes. Ratio 82.9%        
    Compression time: cpu 3275.88 secs, real 2193.39 secs. Speed 1.825 kB/s
     
    srep-256+srep-256+lzma:ht4:mc3 - 3.997.881.040 => 3.320.147.004 bytes. Ratio 83.0%        
    Compression time: cpu 3281.36 secs, real 2145.80 secs. Speed 1.863 kB/s
     
    srep-256+lzma:ht4:mc3 - 4.011.245.268 => 3.320.216.844 bytes. Ratio 82.7%        
    Compression time: cpu 3611.02 secs, real 2105.63 secs. Speed 1.905 kB/s
     
    srep-16kb+lzma:ht4:mc3 - 4.572.251.124 => 3.321.789.954 bytes. Ratio 72.6%        
    Compression time: cpu 3366.94 secs, real 2254.44 secs. Speed 2.028 kB/s
     
    В итоге - такой lzma в 2-3 раза быстрее lzma:max:192mb:lc8 . При этом сжимает всего лишь на 27-23 Мб слабее - т.е. где-то на 0.8% для srep256. И главное, опять разница сжатых данных между разными minlen srep и rep не выходит за пределы 2 Мб, даже если та - целые 16kb.

    Всего записей: 51 | Зарегистр. 02-01-2008 | Отправлено: 09:11 29-11-2009
    egor23



    Silver Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Bulat_Ziganshin
    Star Ocean: The Last Hope [PAL/ENG] [3-DVD9] xbox 360
    в наличии пока 2 диска
    немного статистики по ним
    изначально 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МБ
    в сумме = 10862.7МБ
     
    srep
    s-so1.iso - 5478.1МБ
    s-so2.iso - 4950.5МБ
    в сумме = 10428.7МБ
     
    вместе
    rep:1024m
    s-so1.iso + s-so2.iso - 10862.7МБ
     
    srep
    s-so1.iso + s-so2.iso - 8835.1МБ

    Всего записей: 3832 | Зарегистр. 03-11-2003 | Отправлено: 16:54 29-11-2009 | Исправлено: egor23, 17:15 29-11-2009
    Alex Zaguzin



    Silver Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Ghost2004
    egor23 - друзья, давайте под тег more прятать простыни, если не против.

    Всего записей: 3698 | Зарегистр. 21-07-2007 | Отправлено: 17:53 29-11-2009
    egor23



    Silver Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Alex Zaguzin
    всё что должно быть под more, прячиться под more
    или "переписку" тоже под more прятать советуете?
     
    PS: отвечать на вопрос не нужно.

    Всего записей: 3832 | Зарегистр. 03-11-2003 | Отправлено: 18:02 29-11-2009
    Ghost2004

    Junior Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Так,  
    srep-16kb+lzma:959mb:h928mb:normal:32:mc29:lc8 выдал вот что:  
    4.572.251.124 => 3.301.558.513 bytes - и проиграл по скорости да сжатию lzma:192mb:max:lc8, хотя и не сильно. (Хотя насчёт скорости не уверен - там система у меня чуть свовсем в процессе не поисла). Так что решил пока оставить этот тест.
     
    egor23
    Тоже начал разбираться со Star Ocean'ом. Все три диска srep сжимает так:
    Compression ratio: 23516091904 -> 13137095188: 55.86%. Cpu 5.332 mb/sec, real 3.800 mb/sec
    (правда, при сжатии работающий торрент мог чуть помешать+фрагментация того файла на 23 Гб составляла аж 1354 фрагмента)
     
    Т.е. с Мб которые 2^20 - вот что выходит.
    22426.693 Мб -> 12518.974 Мб
     
    Да, и ещё - специально затарил и в неудобном для кеширования виде "s-so1.iso+s-so3.iso+s-so2.iso". Тест распаковки вот что выдал:
    Cpu 162.776 mb/sec, real 15.323 mb/sec
     
    Kernel Time  =   165.875 = 00:02:45.875 =  10%
    User Time    =   144.484 = 00:02:24.484 =   9%
    Process Time =   310.359 = 00:05:10.359 =  20%
    Global Time  =  1535.297 = 00:25:35.297 = 100%
     
    Конечно, не так внушительно, как 25 Мб/с в прошлый раз, но всё равно очень впечатляет.
    Торрент я отключил по такому случаю, да и фрагментации сжатого файла почти не было - 3 фрагмента - и это на 13 Гб... Да, и ещё -  памяти свободной было много - 1.5-2 Гб, с системным кэшем проблем не было... Правда, система была загружена без /3G, чтобы DXVA работало и видео можно было смотреть не нагружая процессор. Да, и ещё - у распакованного файла стало всего 97 фрагметов - не так много для такого размера.
     
    Если надо - логи srep есть (в смысле информация -s), и для компрессии этих 23 Гб и для их декомпрессии. Можно ещё попробовать собрать 23 Гб как 1+2+3 (а не 1+3+2) - может, так srep ускорится... Обычный rep пока не тестил - но пока у меня только 2 Гб на один процесс, так что больше rep:1gb не выйдёт...

    Всего записей: 51 | Зарегистр. 02-01-2008 | Отправлено: 20:07 29-11-2009
    Alex Zaguzin



    Silver Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    А, ну да, я и забыл. У ват тут блог

    Всего записей: 3698 | Зарегистр. 21-07-2007 | Отправлено: 20:11 29-11-2009
    Bulat_Ziganshin

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

    Цитата:
    real 15.323 mb/sec  

    отлично! хотя я таки не понял, какое -l при этом было

    Всего записей: 3408 | Зарегистр. 13-08-2007 | Отправлено: 20:39 29-11-2009
    sabio

    Silver Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Alex Zaguzin
    egor23
    Bulat_Ziganshin
     
    вот и я хотел заметить, что, если забредёт сюда какой-нть _обычный_ пользователь в поиске ответов на свои _простые_ вопросы - все эти "простыни" с логами, тоннами настроек, и пр. его просто испугают
     
    может, стоит все эти технические обсуждения как-то отделить?
    создать специальный топик для "энтузиастов сжатия FreeArc"?
    а здесь оставить новости о выходе новых версий и прочее _обычное_ обсуждение программы (с резюмированием наиболее интересных и важных находок "энтузиастов" - как например, про 2+ ГБ в шапке)
     
    я понимаю, что "энтузиастам" и автору это мало интересно
    но первое впечатление в виде десятка последних страниц этой темы может отпугнуть многих потенциальных пользователей своей излишней сложностью

    Всего записей: 2898 | Зарегистр. 21-05-2004 | Отправлено: 20:44 29-11-2009 | Исправлено: sabio, 20:45 29-11-2009
    Redisych



    Advanced Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    А что вообще тут делать "обычному пользователю"? По-моему, пока здесь только бета-тестеры, или я неправ, и кто-то без затей использует архиватор в повседневной деятельности?

    Всего записей: 662 | Зарегистр. 15-04-2005 | Отправлено: 21:35 29-11-2009
    Ghost2004

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

    Цитата:
    отлично! хотя я таки не понял, какое -l при этом было

    Стандартный 512.

    Всего записей: 51 | Зарегистр. 02-01-2008 | Отправлено: 21:58 29-11-2009
    CTACKo

    Junior Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Да, действительно, так живо обговаривается тема про srep, а реальный глюк вызывает мало интереса.
    Сколько еще раз мне надо сказать о том, что есть проблема в unarc.dll, чтобы ею как-то заинтересовались, не на уровне отписок? Ну не впервые же! Или пусть оно так и будет... Как бы решение я нашел сам, а там кто еще с таким же глюком столкнется пусть пеняет на себя.  
    А проблема-то достаточно живая, особенно в свете того, что фа не умет бить на тома и что жмет сгруппированные данные одного типа по отдельности лучше, чем все в одном, смешанном...
    Как еще описать проблему, какие еще данные надо предоставить, учитывая что unarc.dll никак не логается, я не знаю. Короче я забиваю, когда заинтересуешся, Булат, у тя есть моя аська.

    Всего записей: 180 | Зарегистр. 05-09-2008 | Отправлено: 22:26 29-11-2009
    Bulat_Ziganshin

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

    Цитата:
    какие еще данные надо предоставить

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

    Всего записей: 3408 | Зарегистр. 13-08-2007 | Отправлено: 22:29 29-11-2009
    Ghost2004

    Junior Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Да, больше на USB-винчестер жать ничего не стану. Итак, результаты обычной rep:1gb:h27:a99 -  
    23.516.091.904 => 17.227.395.259 bytes. Ratio 73.2%      
    Compression time: cpu 3615.30 secs, real 6951.05 secs. Speed 3.383 kB/s
    Т.е. srep сжал в 1.3 раза лучше.

    Всего записей: 51 | Зарегистр. 02-01-2008 | Отправлено: 22:46 29-11-2009
    Bulat_Ziganshin

    Silver Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    new version:
     
        * UAC compatibility - when you change Explorer Integration in the Settings dialog, it asks your permission
        * allow to enable/disable Personal Settings and Explorer Integration due installation
        * SREP added to PowerPack and arc.ini
        * TTA: improved memory handling
        * -mex1..5: added fast compression for already compressed files
        * UI: use "1,234,567" instead of "1.234.567"
     
     
    Добавлено:
    Ghost2004
    для -mex5t необходима facompress.dll

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

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

    Цитата:
    для -mex5t необходима facompress.dll

    Скорее это у меня arc.ini был 9 ноября, и не хотел обновляться при запуске инсталляторов. Сейчас его убрал-переименовал, и встал новый - сразу заработали и -mex5t и -msrep (вручную я его в arc до этого так и не прописал, не успел).
     
    Добавлено:
    Не, ошибся - всё равно не работает - хоть facompress.dll сегодняшней версии лежит в каталоге freearc'а . Та же ошибка вылезает "invalid compression method or parameters in 4x4:b7mb:ppmd:8:96mb:c7mb" - как только dict+lzp обрабатывают первый блок. Нужна какая-то особая версия facompress.dll?

    Всего записей: 51 | Зарегистр. 02-01-2008 | Отправлено: 08:41 30-11-2009 | Исправлено: Ghost2004, 09:02 30-11-2009
    Bulat_Ziganshin

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

    Цитата:
    для -mex5t

    что=то ты напутал. помести сегодняшние arc.exe и facompress.dll в один каталог и дай в нём команду arc a a -mex5t

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

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

    Цитата:
    что=то ты напутал. помести сегодняшние arc.exe и facompress.dll в один каталог и дай в нём команду arc a a -mex5t

    Возможно, только не пойму что. Вот что по любому выдаёт:
     
    FreeArc 0.60 RC (November 30 2009) creating archive: a.arc
    Compressing 4 files, 3,154,944 bytes. Processed   0% 11%
    ERROR: invalid compression method or parameters in 4x4:b7mb:ppmd:8:96mb:c7mb
    .
    Хоть оставляй path (с каталогом инсталляции freearс'а), хоть его убирай...

    Всего записей: 51 | Зарегистр. 02-01-2008 | Отправлено: 11:09 30-11-2009
    egor23



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

    Цитата:
    arc a a -mex5t

    тоже самое
    ERROR: invalid compression method or parameters in 4x4:b7mb:ppmd:8:96mb:c7mb
    лог..

    Всего записей: 3832 | Зарегистр. 03-11-2003 | Отправлено: 12:55 30-11-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