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


4. freearc.ini данный здесь не до конца совместим с последней версией freearc, в частности те же -m5p не работают (а в -m81 jpg preprocess вроде как нет).
ну вот приехали
srep295.exe -d s-so123_512.srep s-so123.tar
Ratio: 16735272960 -> 9873103080: 59.00%. Cpu 187.707 mb/sec, real 20.837 mb/sec
ERROR! Checksum of decompressed data is not the same as checksum of original data
s-so123_512.srep делался 01.12.2009 скорее всего версией 0.8
проще увеличить размер солид-блоков
через -m5p размер не уменьшается.
Дикий тормоз, на фоне того же x264 с теми же алгоритмами арифметического сжатия.
С точки зрения удобства людей наиболее лучшие по скорости/уровню сжатия режимы m81-m87 просто обязаны быть в GUI и более того, выбраны по умолчанию.
В GUI настройки при смене верхних пресетов вверху галочки внизу не меняются.
Кстати, попробовал packMP3 от создателя pacjJPG, действительно сжимает до 25%. Неплохо бы его тоже включить в FreeARC. mp3zip тоже хорош.
Цитата:
через -m5p размер не уменьшается.
блин, я уже забыл, а ты доки и не читаешь: "Обратите внимание: режим сжатия -max (-m9p) реализует максимальное сжатие с precomp+srep+dispack, а -m9j делает то же самое плюс пережатие jpeg"
может, ещё зафигачить по умолчанию методы, требующие 100 гб озу для распаковки?
новая альфа:
-mem100: Cpu 76.815 mb/sec, real 54.448 mb/sec. Matches 0 29368 4950862, I/Os 0, RAM 0/60, VM 0/2360, R/W 36760/36760
Всё равно не получается.
Кстати, packjpg консольный уже полгода как версии 2.5, в dll же 2.4.
Но если эти методы такие замечательные что на них проводятся тесты и рекомендуются в этой ветке именно они, то почему бы и нет
Идея пресетов позволит менять внутренние параметры от версии к версии, скрывая подробности от неопытных пользователей.
Хотел попробовать для этих целей навороченный StuffIt, так он не умеет режима синхронизации, то есть удалять файлы из архива.
множество изменений в колбеках FreeArcExtract->
это не даёт избавляться от дубликатов
дело в том, что использовать packjpg не очень удобно, поскольку он сжимает по одному файлу...и требует много времени на его запуски
множество изменений в вызовах FreeArcExtractВызов - это вызов. Колбек - это обратный вызов, типа события.
Цитата:
Всё равно не получается.
возьми portable версию, распакуй в отдельный каталог и прям в каталоге с arc.exe проверни это
Цитата:
Хотел попробовать для этих целей навороченный StuffIt, так он не умеет режима синхронизации, то есть удалять файлы из архива.
и навороченный fa не умеет. используй простенький 7-zip
что за packARC ?
так эти файлы затем по верху можно закатать lzma или rep-ом и все повторы исчезнут
фиг с тем временем упаковки, а розпаковну можно сделать параллельной, что ускорит ее немного
Compressed 1 file, 4,307,553 => 4,219,424 bytes. Ratio 97.9% против 78% у packjpg
ini ведь тот же.
Кстати, очень хотелось бы видеть в документации пример запуска для режима backup с синхронизацией, то есть новые или изменившиеся файлы добавлялись бы в архив, а исчезнувшие файлы соответственно удалялись.
а precomp оригинальном системные функции запускались напрямую с kernel32/msvcrt?напрямую с kernel/msvcrt. Когда загружается моя подставная дллка, она правит ссылки на системные функции в основном ехешнике, и перенаправляет на свои. По идее подобным образом можно сделать универсальный cls фильтр для любого пакера/анпакера, с единственным условием, что он не будет использовать fseek (или SetFilePointer). Или по крайней мере не перемещать указатель вне буфера cls фильтра (~несколько мегабайт). precomp отличается от обычных пакеров, т.к. он может патчить свое распакованное добро парой байт далеко за сотней мегабайт сзади.
или так же с packJPG.dll, если нет, то как ты их перенаправил в dll без модификации precomp.exe ?
я к чему все это, к тому что раз cls-precomp использует объекты синхронизации и packJPG подменный чтобы распаковывать "налету"можно, конечно, но это надо расбираться и с сжимающей частью программы. Для меня эффективность упаковки по времени не интересна.
может как то можно их и упаковывать,
а CLS_DONE точно вызывается?CLS_DONE вызывается в самом конце, перед завершением процесса (по крайней мере в unarc.dll так). Попробуй MessageBox поставить вместо printf, авось покажется.
у меня что то не пишет нечего
так дело именно в том, что проблемы возникают у одного из 10.000. если б проблемы были у большинства - всё было б ясно, а так они оказываются в дураках
srep295.exe -d s-so123_512.srep s-so123.tar
Ratio: 16735272960 -> 9873103080: 59.00%. Cpu 187.707 mb/sec, real 20.837 mb/sec
ERROR! Checksum of decompressed data is not the same as checksum of original data
можно для тестирования сделать билд, который не прерывает распаковку?
7. может иконку кнопки Add заменить на основную FA ? по аналогии с WinRar.
тогда не мешало бы и кнопку извлечь переделать, а то какой то плейер получается
Цитата:
разобрался. ты напоролся на известную багу в arc - если в архиве arc можно найти несжатый архив другого формата, то он откроет именно внутренний архив:
а что значит несжатый ?т.е. если я упакую cab - то потом данные свои распоковать не смогу ?
хм, а как же создание архива ARC без пробелов в имени и успешном листинге ?
Страницы: 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275
Предыдущая тема: Punto Switcher (часть 3)