Ru-Board.club
← Вернуться в раздел «Программы»

» FreeArc (часть 4)

Автор: insorg
Дата сообщения: 28.07.2012 15:25

Цитата:
файл подкачки больше 1 гига не ставлю

Оно является тормозом по причине своего существования и не зависимо от размера.

Bulat_Ziganshin
Т.е., мне понадобится всё тот же 7z x64 в качестве внешнего упаковщика, верно?
Автор: slech
Дата сообщения: 23.11.2013 14:25
Andarin что вы лентяй, что Bulat_Ziganshin лентяй.
Он запостит ссылку, кому нужно прочитает такой перевод
Хоть какое-то временное решение вопроса.
Автор: Paramon111
Дата сообщения: 28.07.2012 15:36
insorg
200м файла подкачки в любом случае надо ставить на системном диске. остальное можно и убрать.
Автор: slech
Дата сообщения: 29.11.2013 18:58
Булат, вы как-то писали про Qt:

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


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


Не думали над этим вопросом подробнее ?
Автор: insorg
Дата сообщения: 28.07.2012 16:35
Paramon111
Я вот уже лет эдак 4-5 живу БЕЗ этой подкачки, и никаких проблем не имею.
Зато всё быстро и без убивания винта.
Автор: slech
Дата сообщения: 01.12.2013 16:33
Bulat_Ziganshin, ещё вопрос возник:
Можно ли приостановить на время задачу которая выполняется в фоне ?
Автор: Bulat_Ziganshin
Дата сообщения: 28.07.2012 16:41

Цитата:
Т.е., мне понадобится всё тот же 7z x64 в качестве внешнего упаковщика, верно?

нет


Цитата:
может что не так сделал?

да
Автор: RandRover
Дата сообщения: 08.12.2013 19:10

Цитата:
что Bulat_Ziganshin лентяй


Уважаемый, если бы вы хоть одну из собственноручно написаных фриварных программ с исходниками от 5000 тыс. строк мейнтейнили на протяжении более 1 года, вы бы не только обленились, у вас также начались бы периоды жуткой прокрастинации и устойчивое желание всех юзеров с просьбами о добавлении еще одной фичи в программу, сразу слать прямым текстом к "такой-то бабушке"...
И, судя по резковатым ответам автора в топике, он скоро вообще даже перестанет отвечать на вопросы по работе программы...
И писать здесь упреки типа, "октябрь уже давно прошел, а новой версии всё нету..." - бесполезно и глупо, так как у автора уже давно прошел тот период, когда с энтузиазмом бежишь кодить только из-за того, что в прошлом месяце твою программу уже скачало более 100 человек и несколько из них даже написали в комментах на странице скачки, что "прога - нормуль"...

И еще информация для размышления: а вы не задумывались хоть на минуточку, что FreeArc - это единственный БЕСПЛАТНЫЙ (в отличии от ВинРАРа) архиватор с собственным форматом, в котором реализован функционал добавления информации для восстановления к архивам? А это значит, что он является прямым конкурентом для платного аналога, и вполне возможно даже, что Женя Рошал "отстегивает" автору какую-то фиксированную суму для того, чтобы автор подольше "тянул резину" с написанием удобного ГУЯ, добавлением новых фич и выпуском новых стабильных версий архиватора. (да-да, понимаю, что такая версия бредовенькая, хотя... )

Короче, если хотите побыстрее узреть новый удобный ГУЙ и добавленые фичи в новой версии FreeArc, то ускорить появление оных можно только двумя способами - либо активно донатить разработку либо брать сорцы и добавлять фичи и ГУЙ самим.

Автор: insorg
Дата сообщения: 28.07.2012 16:49

Цитата:
Т.е., мне понадобится всё тот же 7z x64 в качестве внешнего упаковщика, верно?

Цитата:
нет
Можно тогда поподробнее, как его вызвать? Или, если описано было ранее, ссылку на описание...

Автор: Paramon111
Дата сообщения: 29.07.2012 16:43
insorg
Короче мы с тобой так и не поняли как lzma64 использовать. И никто по ходу нормально объяснять не собирается.

Добавлено:

Цитата:
64-битная реализация LZMA увеличивает скорость на 10-20% и позволяет LZMA использовать больше 4 ГБ памяти.

Для того, чтобы использовать внешний 64-битный LZMA (рас)паковщик, добавьте в arc.ini содержимое arc-lzma-x64[-filter].ini.


внешний распаковщик это "C:\Program Files (x86)\FreeArc\Addons\LZMA-x64\FreeArc-LZMA-x64.exe"?

Если нет то где его брать этот распаковщик и как заставить FreeArc его использовать???
Автор: slech
Дата сообщения: 08.12.2013 21:11
RandRover

Цитата:
Уважаемый, если бы вы хоть одну из собственноручно написаных фриварных программ с исходниками от 5000 тыс. строк мейнтейнили на протяжении более 1 года, вы бы не только обленились, у вас также начались бы периоды жуткой прокрастинации и устойчивое желание всех юзеров с просьбами о добавлении еще одной фичи в программу, сразу слать прямым текстом к "такой-то бабушке"...

Это ни в коем не упрёк Булату. Ну не хочет - не делает, а ленится он или времени нет или нехочет возможно не принципиально.


Цитата:
Короче, если хотите побыстрее узреть новый удобный ГУЙ и добавленые фичи в новой версии FreeArc, то ускорить появление оных можно только двумя способами - либо активно донатить разработку либо брать сорцы и добавлять фичи и ГУЙ самим.

У меня сложилось впечатление, что Булата больше интересуют технические вещи, чем реализация задач для пользователей. Каждому нравится своё и это здорово.

Значит нужно оформить Т.З. и определить стоимость проекта.
Собрать средства и найти разработчика.

Возможно как-то так.
Автор: insorg
Дата сообщения: 29.07.2012 18:04
Paramon111
Для х64 LZMA лучше простой 7z верти - тут тебе и проблем с совместимостью меньше будет, да и там уже всё готово к использованию, честное х64.

Bulat_Ziganshin
Требуется упаковать архив (в максимально возможное сжатие) с 20 файлами (по 202…212 мб каждый) ресурсов игры, которые по сути являются простыми zip-архивами с переименованым расширением и deflate сжатием, но после распаковки архивы должны получитсья бит-в-бит одинаковые и проходить md5 и sha проверку по изначальным суммам.
Поможет ли мне для этого precomp, не нарушив целостность результата?
Если да - какую конкретно строку следует ему задать?
Автор: Engaged Clown
Дата сообщения: 08.12.2013 22:26
slech

Цитата:
Значит нужно оформить Т.З. и определить стоимость проекта.
Собрать средства и найти разработчика.

KickStarter, но гуй на GTK всё убивает.
Автор: Bulat_Ziganshin
Дата сообщения: 29.07.2012 18:12

Цитата:
Короче мы с тобой так и не поняли как lzma64 использовать. И никто по ходу нормально объяснять не собирается.  

1. прочтите документацию
2. поищите в списке изменений связанное с lzma, external compressors и т.д.
3. читайте пару последних страниц здесь


Цитата:
Поможет ли мне для этого precomp, не нарушив целостность результата?
Если да - какую конкретно строку следует ему задать?

проще всего отметить в gui галочку precomp
Автор: Bulat_Ziganshin
Дата сообщения: 09.12.2013 13:10
http://encode.ru/threads/1838-Command-Line-Process-Profiling-Tool?p=35675#post35675 это типа timer.exe/consmeter но гораздо круче. пока он работает над прогой, можно попытаться передать через меня ему пожелания, если вы не можете там зарегиться и/или не знаете английского. для меня прога просто супер, вот пара примеров её работы (она выводит только выделенные жирным шрифтом строки):


C:\Base\Tools\Utils>ProcProfile64.exe -tb rar -inul a m:\aaa z:\1g

1,000,001,799 -> 296,995,091: 29.69%. Cpu 8 mb/s (116.860 sec), real 44 mb/s (21.670 sec) = 539%


C:\Base\Tools\Utils>ProcProfile64.exe -tb 7z a m:\aaa ProcProfile64.exe >nul

93,696 -> 37,706: 40.24%. Cpu 1475 kb/s (0.062 sec), real 1946 kb/s (0.047 sec) = 131%


C:\Base\Tools\Utils>ProcProfile64.exe -tb 7z a m:\aaa z:\1g

7-Zip [64] 9.32 alpha Copyright (c) 1999-2013 Igor Pavlov 2013-12-01
Scanning

Creating archive m:\aaa.7z

Compressing 1g

Everything is Ok

Kernel Time = 1.107 = 1%
User Time = 378.458 = 657%
Process Time = 379.566 = 659% Virtual Memory = 1178 MB
Global Time = 57.534 = 100% Physical Memory = 1008 MB

1,000,000,000 -> 261,801,487: 26.18%. Cpu 2572 kb/s (379.565 sec), real 16 mb/s (57.539 sec) = 659%
Автор: insorg
Дата сообщения: 29.07.2012 18:15

Цитата:
проще всего отметить в gui галочку precomp

Я использую консольную версию в связке с TotalCommander.
Сейчас я использую уже полюбившиеся параметры -m9x -i2 -lc- -ld- -di , и хочу узнать, что следует добавить.
Интуитивно я догадваюсь, что в конец ещё бы нужно добавить -mc$precomp+default или -mc$default,$obj:+precomp , но хотелось бы уточнить.
Автор: Bulat_Ziganshin
Дата сообщения: 29.07.2012 18:35
insorg
почитай whatsnew, там описано как эти галочки действуют
Автор: Edison007007
Дата сообщения: 09.12.2013 18:57
Булат, если использовать внешний компрессор внутри FA, то различаются показания у ProcProfile_x86_1.3.1 и arc.exe (12.12.12)

ProcProfile32 -k -tb arc.exe a -r -ep1 -ds=ens -s=; -lc- -di=ecwftsm -i1 --logfile=freearc.log --append -wE:\FreeArcTempDir -m=precomp "1.arc" "TestDATA\*"

Compressed 1 file, 201,152,043 => 239,227,035 bytes. Ratio 118.9%
Compression time: cpu 1.42 secs, real 384.19 secs. Speed 524 kB/s

468,427,026 -> 440,379,740: 94.01%. Cpu 156821 kb/s (2.917 sec), real 1190 kb/s (384.284 sec) = 0%
Автор: Paramon111
Дата сообщения: 30.07.2012 07:30
Bulat_Ziganshin
У меня есть 3 файла в папке, FreeArc отказывается их паковать вместе. По одному файлу без проблем. Отказ в том что упаковка останавливается и все. Даже такой быстрый метод как -m=rep стопорится. Вот эти файлы : http://file.karelia.ru/fvv53r/

Добавлено:
В чем же дело? другой набор таких же файлов жмется нормально.
Автор: Shegorat
Дата сообщения: 09.12.2013 20:08
Edison007007 20:57 09-12-2013
Цитата:
Булат, если использовать внешний компрессор внутри FA, то различаются показания у ProcProfile_x86_1.3.1 и arc.exe (12.12.12)

Думаю, ProcProfile учитывает все операция чтения-записи. Так что нужно учитывать, что FA сначала копирует данные в темп-файл, потом этот темп-файл обрабатывает прекомпом в другой темп-файл и уже его копирует в архив.
Автор: Bulat_Ziganshin
Дата сообщения: 30.07.2012 11:43
Paramon111
I:\77>arc a a -mrep -i2
FreeArc 0.67 (May 22 2012) compressing 4 files, 419,582,502 bytes
Compressing Atlantis 9.7.ctb
Compressing Atlantis 9.7.ctg
Compressing Atlantis 9.7.cto
Compressing Options.bmp
Compressed 4 files, 419,582,502 => 343,709,340 bytes. Ratio 81.9%
Compression time: cpu 1.87 secs, real 0.76 secs. Speed 555,707 kB/s

установи программу с нуля
Автор: Bulat_Ziganshin
Дата сообщения: 11.12.2013 19:33
FAZip 0.3 это пофайловый упаковщик (аналогично gzip/bzip2), поддерживающий все алгоритмы сжатия FreeArc, включая CLS dll-ки, 4x4 и цепочки методов (например rep:512m+delta+4x4:lzma). Однако, у него нет развитого набора опций и сохранения контрольных сумм в сжатом файле, так что пока я не могу рекомендовать использовать его как замену вышеупомянутым программам.

FAZip может быть интересен для бенчмаркинга и поиска ошибок в алгоритмах сжатия FreeArc, и как внешний упаковщик, заменяющий встроенные в FreeArc алгоритмы. Включенный в поставку файл arc-fazip.ini показывает как использовать FAZip чтобы полностью заменить встроенные алгоритмы LZMA и REP, сохраняя полную совместимость по данным (т.е. данные, сжатые FAZip, будут распаковываться встроенными алгоритмами, и наоборот).

FAZip заменяет FreeArc-LZMA-x64.exe, Delta.exe и другие упаковщики, откомпилированные из библиотеки сжатия FreeArc.

Что новенького:Windows: 32-битный exe и facompress*.dll откомпилированы ICL 2011
Windows: 64-битный exe откомпилирован MSVC 2013
Linux: 32/64-битные динамически/статически-слинкованные программы откомпилированы GCC 4.6.3 под Ubuntu 12.04 (отсутствует поддержка CLS)
работает с чистым потоком сжатых данных при использовании синтаксиса "compress:метод" и "decompress:метод" (используется в arc-fazip.ini)
автоматически использует все ядра ЦПУ, но не уменьшает отывчивость системы
отображает зелёненький индикатор прогресса в таскбаре Win7
по умолчанию: использует большие страницы памяти (2МБ/4МБ) если они доступны; -slp-: никогда их не использовать; -slp+: использовать только их, при недоступности/нехватке выходить с ошибкой (ага, для бенчмарков)
опция -i0 отключает вывод программы (хотя сообщения об ошибках и ^Break всё же печатаются)
обновляет индикатор прогресса не чаще раза в 0.2 секунды (иначе на это может уходить слишком много времени)
печатает "\n" перед выходом и выдаёт расшифровки сообщений об ошибке вместо их цифровых кодов
удаляет частично созданный выходной файл при выходе по Ctrl-Break или ошибке

LZMA:словарь до 2 ГБ в BT4, до 4000 МБ в HT4/HC4
улучшено сжатие со словарём в 1 ГБ
предвыборка памяти в BT4/HT4 - до 20% быстрее
по умолчанию MaxChain (:mc) в HT4 теперь равен FastBytes/2 (:fb/2)

Другие алгоритмы:FAZip поддерживает все алгоритмы FreeArc, включая "tempfile" и cls-*.dll, за исключением только внешних алгоритмов, определяемых в arc.ini
64-битные версии алгоритмов ppmd/grzip/tta на самом деле пока не работают
REP: стал до 2 раз быстрее при больших :l/:c (потому что для хеширования теперь используются все ядра ЦПУ)
Delta: стало в 1.7 раз быстрее


Планы на будущие версии FAZip, в порядке приоритета:32/64-битные версии, откомпилированные MSVC 2010/2012/2013, ICL 2011/2013/2014 и GCC 4.8
подробное описание использования и параметров каждого алгоритма сжатия
полноценный формат сжатых файлов - с идентификатором формата и контрольной суммой
64-битные версии ppmd/grzip/tta
значительное ускорение HT4/BT4 (хотя при этом мы упрёмся в другую часть LZMA - Оптимальный Парсер)
упереть драйвер командной строки из bzip2 или tornado - где хуже лежит
64-битный MemSize (lzma:h4g)
не выводить сообщений об ошибках при -i0?





FAZip 0.3 is a single-file compression utility (like gzip/bzip2), that supports all
the FreeArc compression algorithms, including CLS dlls, 4x4, and method chaining
(like rep:512m+delta+4x4:lzma). It lacks feature-rich command line and data checksums,
though, so i can't yet recommend to use it as general-purpose compressor.

FAZip may be useful for benchmarking and bug-hunting FreeArc compression algorithms,
and as external compressor replacing built-in FreeArc methods. The provided arc-fazip.ini
demonstrates how to use FAZip to completely replace built-in LZMA and REP algorithms
while retaining full data format compatiblity (i.e data compressed by FAZip may be extracted
by built-in methods and vice versa).

FAZip replaces FreeArc-LZMA-x64.exe, Delta.exe and other standalone compression tools
compiled from the FreeArc library.

What's new:Windows: 32-bit executable and facompress*.dll compiled by ICL 2011
Windows: 64-bit executable compiled by MSVC 2013
Linux: 32/64-bit dynamic/static-linked executables produced by GCC 4.6.3 on Ubuntu 12.04 (no CLS support)
raw compressed stream produced by "compress:method" and extracted by "decompress:method" syntax (employed by arc-fazip.ini)
automatically employs all cpu cores, while keeping the computer responsive
Win7 taskbar progress indicator (the green bar)
default: use Large Memory Pages (2MB/4MB) if possible; -slp-: never use LP; -slp+: use only LP, abort if there aren't enough LP available (just for benchmarking)
-i0 option disables program output (although error/^Break messages are still displayed)
updates progress indicator only once per 0.2 seconds (otherwise it may need too much time)
prints "\n" before exiting and shows error descriptions instead of numeric codes
removes unfinished outfile on Ctrl-Break or error

LZMA:dictionary up to 2 gb in BT4, up to 4000 mb in HT4/HC4
improved compression with 1 GB dictionary
prefetching in BT4/HT4 matchfinders - up to 20% faster
default MaxChain (:mc) for HT4 now is FastBytes/2 (:fb/2)

Other compressors:FAZip supports all FreeArc algorithms, including "tempfile" and cls-*.dll, except only of external compressors defined in arc*.ini
64-bit versions of ppmd/grzip/tta don't really work yet
REP: made up to 2x faster with large :l/:c (since now it uses all CPU cores for hashing)
Delta: made 1.7x faster


Plans for future FAZip versions, in order of priority:32/64-bit executables compiled by MSVC 2010/2012/2013, ICL 2011/2013/2014 and GCC 4.8
document usage and parameters for all compression algorithms
compressed file format with fileid and checksum
64-bit versions of ppmd/grzip/tta
much faster HT4/BT4 matchfinders (so that LZMA speed will be limited only by the Optimal Parser)
steal cmdline processing from bzip2 or tornado
64-bit MemSize (lzma:h4g)
no error messages on -i0?

Автор: Bulat_Ziganshin
Дата сообщения: 06.02.2012 17:10
i've set up Mercurial repository: http://source.freearc.org:8002/freearc/, although URL may be changed later
Автор: Paramon111
Дата сообщения: 30.07.2012 12:01
Bulat_Ziganshin
переустановил. Ничего не изменилось. так же отказывается. Я в обычной версии делаю. Консольной не умею.

Добавлено:
сейчас попробую на видео записать

Добавлено:
вот и видео: http://rghost.ru/39476904
Автор: 0Vovan0
Дата сообщения: 23.12.2013 01:17
Когда-то давно здесь http://forum.ru-board.com/topic.cgi?forum=5&topic=35164&start=780#2 обсуждалась распаковка архивов, которые воспринимаются арком как запароленные, хотя на самом деле распаковываются unarc.dll без пароля. Я попробовал с помощью UnarcDllExample.exe распаковать такой архив, но он все равно требует пароль. Как определить точно архив ли запаролен или распаковка почему-то происходит неправильно? Пример архива - например тут http://rutor.org/torrent/276813/arx-fatalis-zolotoe-izdanie_arx-fatalis-gold-edition-2002-2007-pc-repack-ot-r.g-mehaniki
Автор: Alex_Piggy
Дата сообщения: 06.02.2012 18:51
Добрый день, Bulat_Ziganshin
freearc.exe при архивировании с удалением файлов, иногда не выдает ошибки (в логе пишет "архив успешно создан"), удаляет что может (могут остаться пустые папки), но не переименовывает freearc1.tmp в "имя_архива.arc".
Возможно ли сделать удаление после переименования и с каким-нибудь прогресс-баром?
Прошу прощения за сумбурное изложение. Версия альфа от 23 ноября и от 5 февраля.
Автор: Bulat_Ziganshin
Дата сообщения: 30.07.2012 13:19
могу предположить что ты поломал lzma и не стёр после этого arc.ini
Автор: Shuld
Дата сообщения: 06.01.2014 08:13
Bulat_Ziganshin

Прошу комментарий.
Проводил тесты и столкнулся с таким моментом.

При архивировании командой (-m89)
rep:734mb+4x4:lzma:128mb:h128mb:normal:bt4:128
получается архив размером 338 695 222 байта (4 м 48 с)
http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=820#9

Но в одном случае я ошибся, у меня была запущена программа, и памяти не хватило.
Архиватор заменил метод на строку:
rep:734mb+4x4:b350mb:lzma:69mb:normal:bt4:128
и получился архив размером 337 769 101 байт, заметно меньше. Время архивирования было не намного больше (5 м 13 с).

Вопрос:
Размер словаря lzma стал меньше, в чем возможная причина уменьшения архива?
Какой стандартный параметр "b" у 4x4? Или он меняется?
Автор: Shuld
Дата сообщения: 07.02.2012 21:15
Bulat_Ziganshin

Экспериментирую с новой версией.

В методе -m1 при замене:
-m1 -mc:rep/rep:96m:64:c64 -mc:4x4/4x4:tor:3:2m:h128k
у меня обычно уменьшается время и улучшается сжатие, например:

FreeArc 0.67 (February 5 2012) Creating archive: proba5.arc using rep:96mb:256:c256+4x4:tor:3:2mb:h256kb, $wav => mm:d1+4x4:tor:3:2mb:h256kb:t0, $bmp => mm:d1+4x4:tor:3:2mb:h256kb:t0, $compressed => storing
Memory for compression 142mb, decompression 140mb, cache 16mb
Compressing 1,026 files, 758,272,286 bytes.
Compressed 1,026 files, 758,272,286 => 614,504,948 bytes. Ratio 81.0%
Compression time: cpu 30.90 secs, real 8.75 secs. Speed 86,655 kB/s

FreeArc 0.67 (February 5 2012) Creating archive: proba5.arc using rep:96mb:64:c64+4x4:tor:3:2mb, $wav => mm:d1+4x4:tor:3:2mb, $bmp => mm:d1+4x4:tor:3:2mb, $compressed => storing
Memory for compression 154mb, decompression 140mb, cache 16mb
Compressing 1,026 files, 758,272,286 bytes.
Compressed 1,026 files, 758,272,286 => 613,661,514 bytes. Ratio 80.9%
Compression time: cpu 28.27 secs, real 8.41 secs. Speed 90,147 kB/s

Проверьте на своих данных.

Добавлено:
Вот результат для вашего же файла
http://freearc.org/HFCB.aspx
(мой компьютер примерно в 1,5 раза медленнее)

FreeArc 0.67 (February 5 2012) Creating archive: proba5.arc using rep:96mb:256:c256+4x4:tor:3:2mb:h256kb, $wav => mm:d1+4x4:tor:3:2mb:h256kb:t0, $bmp => mm:d1+4x4:tor:3:2mb:h256kb:t0, $compressed => storing
Memory for compression 142mb, decompression 140mb, cache 16mb
Compressing 1 file, 4,244,176,896 bytes.
Compressed 1 file, 4,244,176,896 => 1,295,281,921 bytes. Ratio 30.5%
Compression time: cpu 104.02 secs, real 79.33 secs. Speed 53,500 kB/s

FreeArc 0.67 (February 5 2012) Creating archive: proba5.arc using rep:96mb:128:c64+4x4:tor:3:2mb, $wav => mm:d1+4x4:tor:3:2mb, $bmp => mm:d1+4x4:tor:3:2mb, $compressed => storing
Memory for compression 154mb, decompression 140mb, cache 16mb
Compressing 1 file, 4,244,176,896 bytes.
Compressed 1 file, 4,244,176,896 => 1,281,669,520 bytes. Ratio 30.1%
Compression time: cpu 100.78 secs, real 79.89 secs. Speed 53,126 kB/s

Здесь время примерно одинаковое.

Добавлено:
Извиняюсь, по ошибке rep:...128:с64.
Привожу для 64:с64

FreeArc 0.67 (February 5 2012) Creating archive: proba5.arc using rep:96mb:64:c64+4x4:tor:3:2mb, $wav => mm:d1+4x4:tor:3:2mb, $bmp => mm:d1+4x4:tor:3:2mb, $compressed => storing
Memory for compression 154mb, decompression 140mb, cache 16mb
Compressing 1 file, 4,244,176,896 bytes.
Compressed 1 file, 4,244,176,896 => 1,278,343,363 bytes. Ratio 30.1%
Compression time: cpu 101.21 secs, real 79.17 secs. Speed 53,605 kB/s
Автор: Paramon111
Дата сообщения: 30.07.2012 14:25
Bulat_Ziganshin
Каким образом я мог поломать? Я же полностью переустановил, arc.ini и lzma установились заново. И у меня есть другое дерево .ctg так же из трех файлов, оно жмется без проблем.

Добавлено:
Предлагаю кому-нибудь на форуме попробовать упаковать эти файлы. Может не у меня одного так будет.

Добавлено:
Уточнение: -m=lzma сжатие идет! -m=srep сжатие идет! -m=rep сжатие останавливается как на видео. Из-за rep`а не работают -m1...-m9,mx,m9x.

Страницы: 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275

Предыдущая тема: Punto Switcher (часть 3)


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.