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

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

Цитата:

про зацикливание, если нет внешнего упаковщика, уже говорили.

я вроде исправил?

у меня тут есть такой очень интересный архивчег со звуками к игре (все файлы в формате *.wav). Архив имеет неизвестный формат/происхождение, весит 64 мб, распаковуется:
за 42 сек на сильно фрагментированном разделе, системe AMD64 X2 5000+(AM2/DDR2-800x4Gb/SATA2)
за 38 сек на не очень фрагментированном разделе, системе AMD64 X2 3000+(S939/DDR400x4Gb/SATA2)
в 397 Мб, 4201 файлов в 168 папках!!!
Жамканье в mp3 исключено - за такое короткое время нереально перекодить столько mp3 в wav. Я для интереса сжал все в mp3 с помощью lame, так потом распаковка заняла 15-20 минут, если не дольше...
Попробовал фарк:
arc a -r -mx -ld512 sound *
сжимает полученное в 244 Мб! я в шоке... #:-0

Что ж там за метод такой применен с ТАКОЙ скоростью распака?! Вот если и бы и фарк ТАК умел!!!

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

2Bulat_Ziganshin
вопрос по поводу ошибки необработки заданным алгоритмом группы файлов (в моем случае это файлы, сжатые zip, но имеющие расширение ff (*.ff в группе $mygrp)), связанный с исключительно приоритетным попаданием таких фалов во внутреннюю группу $compressed будет осветлен или будет далее игнорироваться? Я же максимально детализировал проблему, выложил кучу логов, все настройки. Хоть подтверди что да, есть такое, или нет, происходящее - твои проблемы.

Цитата:

фарк подсунул слепок из нескольких файлов lame-у

Мне нравится эта логика! -- специально заставить архиватор (т.е. "компрессор без потерь") использовать сжатие с потерями! Следующим шагом на этом пути нужно будет указать препроцессором nul -- коэф. сжатия сразу приблизится к бесконечности

Цитата:

архиватор (т.е. "компрессор без потерь")

архиватор - это программа, собирающая много файлов в один (архив). строго говоря, вся остальная функциональность в ней опциональна. примером чистого архиватора является tar (tape archiver), а gzip, к примеру - это не архиватор

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

Добавлено:

Цитата:

Следующим шагом на этом пути нужно будет указать препроцессором nul -- коэф. сжатия сразу приблизится к бесконечности

-mfake

CTACKo

Цитата:

весит 64 мб, распаковуется
...
[q]в 397 Мб, 4201 файлов в 168 папках!!!

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

Цитата:

выкладывайте архив и чем его распаковать

я проверил - у меня скорость распаковки однопоточным lame именно такая, 1.6 мб/с. с учётом меньшей частоты, но двух ядер распаковать 64 мб за 40 секунд вполне реально

Bulat_Ziganshin

Цитата:

в прицнипе, если отключить crc checking при распаковке

опять же можно сделать или как опцию внешего упаковщика (т.е. данные при распаковке прошедшие через lossy не проверялись на целосность).
или ещё как...

Добавлено:

Цитата:

я вроде исправил?

вроде нет \ или опять поломали
arc.exe a 1.arc 1.wav -s- -mwavpackc -di -di+$#
arc.exe t 1.arc -di -di+$#
[more=screen_log..]
FreeArc 0.50 alpha (Feb 15 2009) Testing archive: 1.arc
Decoding directory: 0.00 secs
Directory decoded: 0.00 secs
Directory built: 0.00 secs
Testing 1 file, 39.866.444 bytes. Processed 0%
Unpacking 31146620 bytes with wvunpack.exe $$arcpackedfile$$.wv -o $$arcdatafile$$.wav
"wvunpack.exe" не является внутренней или внешней
командой, исполняемой программой или пакетным файлом.
Solid block decompression results (0.121 seconds)
wavpackc: 31.146.620 bytes in 0.121 sec 78%
Unpacking 31146620 bytes with wvunpack.exe $$arcpackedfile$$.wv -o $$arcdatafile$$.wav
"wvunpack.exe" не является внутренней или внешней
командой, исполняемой программой или пакетным файлом.
124%
Solid block decompression results (0.141 seconds)
wavpackc: 31.146.620 bytes in 0.141 sec156%
Unpacking 31146620 bytes with wvunpack.exe $$arcpackedfile$$.wv -o $$arcdatafile$$.wav
"wvunpack.exe" не является внутренней или внешней
командой, исполняемой программой или пакетным файлом.
220%
Solid block decompression results (0.081 seconds)
wavpackc: 31.146.620 bytes in 0.081 seconds
Unpacking 31146620 bytes with wvunpack.exe $$arcpackedfile$$.wv -o $$arcdatafile$$.wav
"wvunpack.exe" не является внутренней или внешней
командой, исполняемой программой или пакетным файлом.
259%
Solid block decompression results (0.087 seconds)
wavpackc: 31.146.620 bytes in 0.087 seconds
Unpacking 31146620 bytes with wvunpack.exe $$arcpackedfile$$.wv -o $$arcdatafile$$.wav
312%"wvunpack.exe" не является внутренней или внешней
командой, исполняемой программой или пакетным файлом.

Solid block decompression results (0.124 seconds)
wavpackc: 31.146.620 bytes in 0.124 sec390%
Unpacking 31146620 bytes with wvunpack.exe $$arcpackedfile$$.wv -o $$arcdatafile$$.wav
"wvunpack.exe" не является внутренней или внешней
командой, исполняемой программой или пакетным файлом.
456%
Solid block decompression results (0.098 seconds)
wavpackc: 31.146.620 bytes in 0.098 seconds
Unpacking 31146620 bytes with wvunpack.exe $$arcpackedfile$$.wv -o $$arcdatafile$$.wav
"wvunpack.exe" не является внутренней или внешней
командой, исполняемой программой или пакетным файлом.
505%
Solid block decompression results (0.085 seconds)
wavpackc: 31.146.620 bytes in 0.085 seconds
Unpacking 31146620 bytes with wvunpack.exe $$arcpackedfile$$.wv -o $$arcdatafile$$.wav
"wvunpack.exe" не является внутренней или внешней
командой, исполняемой программой или пакетным файлом.
549%
[/more]

Добавлено:

Цитата:

вроде нет \ или опять поломали

или локалько исправили
arc.exe a 1.arc freearc.ini -mpmm:100m -di -di+$#
arc.exe t 1.arc -di -di+$#
[more=screen_log2..]
FreeArc 0.50 alpha (Feb 15 2009) Testing archive: 1.arc
Decoding directory: 0.06 secs
Directory decoded: 0.06 secs
Directory built: 0.08 secs
Testing 1 file, 24 bytes. Processed 0%
Unpacking 63 bytes with ppmonstr d $$arcdatafile$$.pmm
"ppmonstr" не является внутренней или внешней
командой, исполняемой программой или пакетным файлом.
WARNING: CRC error in freearc.ini
Solid block decompression results (0.062 seconds)
pmm:16:100mb: 63 bytes in 0.062 sec
Tested 1 file, 64 => 24 bytes. Ratio 266.6%
Testing time: real 0.16 secs. Speed 0 kB/s
There were 1 warning(s)
[/more]

Добавлено:
arc.exe a 1.arc 1.wav -cfg="alternative arc.ini" -mmac5 -di -di+$#
arc.exe t -cfg="alternative arc.ini" 1.arc -di -di+$#
[more=screen_log3...]
FreeArc 0.50 alpha (Feb 15 2009) using additional options: -di+$
Testing archive: 1.arc
Decoding directory: 0.00 secs
Directory decoded: 0.02 secs
Directory built: 0.02 secs
Testing 1 file, 39.866.444 bytes. Processed 0%
Unpacking 30598444 bytes with mac $$arcpackedfile$$.ape $$arcdatafile$$.wav -d
0%"mac" не является внутренней или внешней
командой, исполняемой программой или пакетным файлом.
Solid block decompression results (0.293 seconds)
mac5: 30.598.444 bytes in 0.293 sec 76%
Unpacking 30598444 bytes with mac $$arcpackedfile$$.ape $$arcdatafile$$.wav -d
"mac" не является внутренней или внешней
командой, исполняемой программой или пакетным файлом.
128%
Solid block decompression results (0.079 seconds)
mac5: 30.598.444 bytes in 0.079 seconds
Unpacking 30598444 bytes with mac $$arcpackedfile$$.ape $$arcdatafile$$.wav -d
"mac" не является внутренней или внешней
командой, исполняемой программой или пакетным файлом.
169%
Solid block decompression results (0.039 seconds)
mac5: 30.598.444 bytes in 0.039 seconds
Unpacking 30598444 bytes with mac $$arcpackedfile$$.ape $$arcdatafile$$.wav -d
230%"mac" не является внутренней или внешней
командой, исполняемой программой или пакетным файлом.
[/more]

Добавлено:
FreeArc
если на любом файле нажать Enter (два клика мышкой), то "заходим внурь файла" и видим былый лист

Цитата:

arc.exe a 1.arc 1.wav -cfg="alternative arc.ini" -mmac5 -di -di+$#

FreeArc
В настрйоках (Опции-Настройки) нет ничего про альтенативные arc.ini
при тестировании \ распаковке - FreeArc виснит.

АркИнфо - надо чтобы не выводил липу:

egor23
А как у тебя получилось "Cancel"->"Отмена" перевести?

Цитата:

при тестировании \ распаковке - FreeArc виснит.

тоже самое и c arc.exe (но не грузит CPU хоть)

Цитата:

arc.exe a 1.arc 1.wav -cfg="alternative arc.ini" -mmac5 -di -di+$#

FreeArc 0.50 alpha (Feb 15 2009) Testing archive: 1.arc
Decoding directory: 0.00 secs
Directory decoded: 0.00 secs
Directory built: 0.00 secs
Testing 1 file, 39.866.444 bytes. Processed 0%

Добавлено:
juvaforza

Цитата:

А как у тебя получилось "Cancel"->"Отмена" перевести?

в инстале не все файлы нужные, т.к. не практично было из-за нескольких надписей утяжелять - инсталл \ portable.
Перевод кнопок планировался реализован быть по-другому.
lib_locale.7z - распаковать в папку FreeArc
http://gettyfile.ru/255818/

Цитата:

Цитата:
выкладывайте архив и чем его распаковать
я проверил - у меня скорость распаковки однопоточным lame именно такая, 1.6 мб/с. с учётом меньшей частоты, но двух ядер распаковать 64 мб за 40 секунд вполне реально

ну я же именно эти все файлы жамкал лэймом и потом распаковывал. скорость распаковки получается просто несравнимыя!!! Учтите факт, что архив давний, сделан был в эпоху PIII, т.е. моноядерности. Поэтому
Цитата:

" двух ядер распаковать 64 мб за 40 секунд вполне реально"

- врядли сие старье догадывалось о мультипоточности. ну разве что чудеса оптимизации ХР

Цитата:

скорее всего многие файлы повторяются

а что же тогда фарк протупил и сложил архив аж в 200Мб?

Цитата:

или используется быстрый упаковщик с потерями (lossy)

типа Xing-mp3 или ogg? мей би...

Добавлено:
Вопрос снят, посмотрел в свойства ехе-анпакёра:

Цитата:

OggPakDecoder MFC Application

DAMN! It's really fuckin' fast!

можно, пожалуйста, получить ответ или камент по вопросу о создании своих методов компрессии, который я несколько предидущих постов подряд тщетно прошу осветить?(*.ff/$mygrp/$compressed)

CTACKo

Цитата:

ну я же именно эти все файлы жамкал лэймом и потом распаковывал. скорость распаковки получается просто несравнимыя

Вы уверены, что это была скорость распаковки (чистая), а не потери при обработке 4201 файла (например при вызове консольного распаковщика для каждого файла).

да, обработка в команднике... я понимаю что он съел кучу времени но не думаю что хотя бы 30% от общего, но даже если и 50% то все равно ogg куда быстрее lame, правда и качество несравнимое, у ogg гораздо хуже.

ЗЫ. скоро свой вопрос про *.ff наверное придеццо в подпись залить, чтобы каждый раз не мучаццо Обидел я чемто Булата чтоли?

egor23
можешь проверить, а? нужно создать группу, например $mygroup и в нее кинуть маску *.ff, создать для группы метод упаковки и затем попробовать им обработать несколько файлов, втч. хотябы 1 с раширением ff, который был бы на деле zip-архивом. Цель теста убедиться что будет делать фарк - определит что ff - архив и обработает по правилам для группы $compressed (т.е. фтопку твои настройки) или по заданным тобою для файлов группы $mygroup? было бы совсем харашо если б правилом для $mygroup было что-то типа precomp+lzma:max или просто precomp - тогда сразу виден результат по размеру архива, ну и наличие precomp надо...

Bulat_Ziganshin

Цитата:

опять проблемы с arc.groups.

arc.groups вообще вещь неприкосаемая
если удалить все группы или оставить только свои, то будем иметь
Program terminated!

arc.exe a 3.arc 3\ -mx -di -di+$#
FreeArc 0.50 alpha (Feb 15 2009) Creating archive: 3.arc using exe+rep:1gb+delta+tempfile+lzma:96mb:max:bt4:128, $obj => rep:1gb+delta+tempfile+lzma:96mb:max:bt4:128, $text => dict:128mb:80%:l8192:m400:s100+lzp:384mb:92%:235:h26:d1mb+ppmd:22:1gb, $wav => tta, $bmp => mm+grzip:8mb:m1:l:a
Memory for compression 1288mb, decompression 1088mb, cache 1mb
Started: 0.00 secs
Found 3 files: 0.02 secs
Program terminated!

если удалить arc.groups, то Program terminated! не будет

CTACKo

Цитата:

хотя бы 30% от общего, но даже если и 50%

времени съелось очень много
Вот OggDec который попался под руку имеет вот такую ком.строку:
OggDec 1.0
Usage: oggdec [flags] file1.ogg [file2.ogg ... fileN.ogg]
кстати посмотрите ком.строку с какой распаковывает OggPakDecoder MFC Application
и кстати выложте его

А у lame
lame.exe [options] <infile> [outfile]


Цитата:

А теперь вопрос в студию: пачаму сначала автодетект, который не отключатся, и почему не сначала по расширению а потом автодетект и как изменить порядок ад-расширение/расширение-ад?

Автодетект отключаем:
То чего нет в документации есть в Новостях:
http://freearc.org/ru/News.aspx
8 февраля 2008: выпущена очередная альфа-версия FreeArc 0.50
Улучшено авто-определение типов файлов, плюс его можно отключить опцией -ma- и в GUI

также краткое описание в Arc.exe есть:
-maLEVEL set filetype detection LEVEL (+/-/1..9)

-mx -m$mygrp=precomp+9b -ma-
и не будет автодетекта

Bulat_Ziganshin
А с автодетектом действительно какая-то непонятка, нельзяли прояснить как он работает по-умолчанию?
а то пришёл к выводу что:
автодетект включается если в методе упаковки есть группа $text
по поводу опции -ma-
как у ней другии вариации работают -ma -ma+ ma1 и т.п.?

по поводу

Цитата:

precomp: препроцессор для сжатых файлов, распаковывающий их

сначала, как обычно бегло, не понял как он должен работать
сейчас дошли руки и опять не понимаю, сошёлся на том что ему нужны идеальные файлы
беру файл FreeArc.exe упаковыю в 7-zip в GZIP (нормальное), FreeArc.exe.gz - не понимает precomp
беру из кэша браузера страничку opr0EY8B.gz 273кБ (1.2МБ), precomp понимает и разжимает её
FreeArc.exe.gz - GZIP - Deflated (Нормальное), ОS - DOS
opr0EY8B.gz - GZIP - Deflated (Нормальное), ОS - Unix

Добавлено:

Цитата:

можешь проверить, а?

автодетект включается если в методе упаковки есть группа $text
c вытекающими
это если так делать
-mx -m$mygrp=precomp+9b
то будет автодетект

Если сделать метод без $text не будет автодетекта
9my1 = rep:1gb+delta+tempfile+lzma:512mb:max:bt4:128 / $wav=tta / $bmp=mm+grzip:8mb:m1:l:a / $1234=rep:512m / $5678=lzma:512m / $mygrp=precomp+9b

-m9my1
то не будет автодетекта

но возможно с $text это косяк, и его поправят, и автодетект по-умолчанию будет при любом методе, а так подождём что скажет Bulat_Ziganshin, насчёт детекта и как он должен работать, может так задумано.

Цитата:

с автодетектом действительно какая-то непонятка, нельзяли прояснить как он работает по-умолчанию?
а то пришёл к выводу что:
автодетект включается если в методе упаковки есть группа $text

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


Цитата:

по поводу опции -ma-
как у ней другии вариации работают -ma -ma+ ma1 и т.п.?

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


Цитата:

беру файл FreeArc.exe упаковыю в 7-zip в GZIP (нормальное), FreeArc.exe.gz - не понимает precomp

а ты думаешь как он работает? унутрях него исходники стандартных библиотек deflate сжатия - zlib, pkzip'овская в виде dll-ки и т.п. когда он вилит deflate поток, он его расжимает и потом ими всеми пытается по очереди сжать, перебирая все 100 вариантов возможных настроек. если один из этих вариантов до копейки совпал с оригиналом - замечательно, значит мы сможем восставноитьт данные. а 7-zip'овской реализации унутрях у него нет, как понимаешь

Цитата:

7-zip'овской реализации унутрях у него нет

очень грустно, понятно, что там вариантов настроек немеренно:
GZIP - 256 настроек \ ZIP - 256 настроек (deflate) + 255 настроек (deflate64) + 9 (bzip2)

ну по сути программно перебрать все варианты не так и сложно, асобинна в условиях текущего железа. Одно, что это вряд ли мы в прекомпе увидаем (т.е. расклады под 7зип), но другое дело что радоваццо надо что хотя бы такое есть. Что до 7зипа то после его зипанья прекомп не ловит потоков никогда, убеждался неоднократно. И встроенный зипарь в ТС тоже далеко не всегда прекомпается.

теперича по поводу *.ff/$mygrp - фишка в том, что мне нужен автодетект! т.е. я хочу чтобы он детектил и подбирал лучший алго для всех типов файлов, и для текстов и не жал архивы и тд и тп, и при всем при этом особенным образом обрабатывал бы файлы с расширением *.ff - в данный момент, как я понял сие невозможно. Т.е. я хочу внести поправку на сжатие только определенных файлов и все. Т.е. фарк должен сложить, отавтодетектить и пожать лучшим по его мнению алго, все, что не в группе $mygrp, а все что в оной группе пусь жмет как указано.
Можно ли отключить автодетект только для группы $mygrp? т.е. что-то типа:
arc a -mx/$mygrp=precomp+9b+ma- ...

Добавлено:
а почему нет автодетекта на РСМ-потоки, я имею в виду RAW PCM, то есть без RIFF/WAVE хедера? иль это нереально?
я, кстати, пробовал такой файл при -мх - получилось хуже чем если насильно tta...

Добавлено:
egor23
Цитата:

и кстати выложте его

sound.exe

Bulat_Ziganshin
Требуется поместить содержимое папки data1 в корень архива
arc.exe a 3.arc C:\temp\12\data1\ -ep1 -mrep:1g -di -di+$#
arc.exe a 3.arc data1\ -ep1 -mrep:1g -di -di+$#
в итоге так и происходит, но ещё добавляется пустая папка data1\

egor23
м.б. нада было
arc.exe a 3.arc C:\temp\12\data1\* -ep1 -mrep:1g -di -di+$#
arc.exe a 3.arc data1\* -ep1 -mrep:1g -di -di+$#

такая ашипго:
freearc(gui) - неверно выдает инфу об архиве, а именно выдает отдельно кол-во директорий, и кол-во файлов, но в кол-во файлов входит и кол-во директорий, а надо типа вычитать.
К примеру у меня в архиве
виндовая инфа по папке, которая жалась:
Файлов: 18335 папок: 1193
инфа от freearc(gui)
Directories: 1.194 Files: 19.529 (а нада 19.529 минус 1.194)
ну и кроме того имеет место 1 лишний объект, если сравнивать с виндовой инфой, по ходу это папко (директория)

Цитата:

arc.exe a 3.arc C:\temp\12\data1\* -ep1 -mrep:1g -di -di+$#
arc.exe a 3.arc data1\* -ep1 -mrep:1g -di -di+$#

будут в архиве только файлы из корня папки data1, не будет подпаппок.

Цитата:

Bulat_Ziganshin

Загляни в ящик личных сообщений))
Всех с праздником 23 !

egor23

Цитата:

Цитата:
arc.exe a 3.arc C:\temp\12\data1\* -ep1 -mrep:1g -di -di+$#
arc.exe a 3.arc data1\* -ep1 -mrep:1g -di -di+$#

будут в архиве только файлы из корня папки data1, не будет подпаппок.

а -r для чего? тогда
arc.exe a -r -ep1 -mrep:1g -di -di+$# 3.arc C:\temp\12\data1\*
arc.exe a -r -ep1 -mrep:1g -di -di+$# 3.arc data1\*

я в последнее время изучаю один рейтинг архиваторов. он пока закрытый, но из него можно сделать кое-какие выводы. загрузите к примеру http://dl.sourceforge.net/sourceforge/mingw/gcc-4.3.0-20080502-mingw32-alpha-bin.7z

это 500 мб данных, которые fa в режиме -m2 упаковывает до 140 мб. если же добавить в arc.ini строчку

2b = tor:b96m:h128m

то они сожмутся в полтора раза лучше!

аналогично этому, "-m3 -md96m" сжимает их на 3% лучше, чем просто -m3

в связи с этим, я думаю увеличить словари в -m2..-m4 до 96 мб, что должно заметно сказаться на сжатии больших объёмов данных

что скажете?


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

Bulat_Ziganshin

Цитата:

в связи с этим, я думаю увеличить словари в -m2..-m4 до 96 мб, что должно заметно сказаться на сжатии больших объёмов данных

что скажете?

Если это не сильно сказывается на скорости сжатия, то "за".

Bulat_Ziganshin

Цитата:

в связи с этим, я думаю увеличить словари в -m2..-m4 до 96 мб, что должно заметно сказаться на сжатии больших объёмов данных

расход памяти\скорость - должны пострадать, а так смотреть надо.


Цитата:

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

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

Цитата:

Если это не сильно сказывается на скорости сжатия, то "за".

ну вы попробуйте сами, я объяснил как это проверить. результаты которые я вижу - от 20% замедления по сранвению с июньской версией там, где особого выигрыша не получилось (2%), до 20% ускорения в этом примере с полуторакратным выигрышем..

Добавлено:

Цитата:

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

ок, это не к спеху. главное, что идея принята. окно пока сделать не могу - не до того

Цитата:

FreeArc
В настрйоках (Опции-Настройки) нет ничего про альтенативные arc.ini

Имелось ввиду или указание конкретных *.ini
или указание папки где эти *.ini лежат
перед упаковкой\распаковкой, идёт поиск методов начиная с arc.ini по-умолчанию, и далее перебераются альтернативные *.ini, в том случае если конкретный arc.ini не указан, далее уже логика поведения:
или каждый метод ищется по отдельности, и используется из того *.ini в котором первым нашёлся;
или ищется *.ini, в котором все методы присутствуют.


Добавлено:
Bulat_Ziganshin
Выдалось немного времени \ место на диске, дошли руки до Dead Space Repack Skullptura
архив data4
размер данных 4349МБ 522файла (самый большой файл 32.5МБ)
файлы (в разных файлах) имеют повторы, за счёт этого упаковываются хорошо до 891МБ (~20%) rep+lzma (это скорее всего не предел).
отдельно файлы упаковываются всего лишь до ~80%

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

Например (обобщённая хотелка):
1. указываются данные для упаковки;
2. выставляется максимальные настройки, по словарю (это если правильно понимаю как работает rep);
3. указываются размеры словарей для которых делать анализ (сортировку);
указывается сколько будет проходов rep (rep+rep+...), но выводить информацию\файл-список для каждого этапа, т.е. сначала для rep (для случая когда один rep), потом для rep+rep и т.д.;
4. режим работы - "только вывод информации на экран" \ вывод на экран + сохранение файл-списков;
5. вывод в лог-файл.

Bulat_Ziganshin
FreeArc
Тестирование:
на битом архиве виснит

Нужен вывод окна: Тестирование прошло успешно (или типа того)
Нужен вывод окна: Тестирование выявило ошибки и ниже на каких файлах выявлены ошибки (как в WinRAR)

Потестировал FreeArc 0.5а на Windows 98 SE (64 МБ):

1. sfx архив вообще не запускается и ничего не выводит
2. FreeArc.exe вылетает с ошибкой "Файл libgdk-win32-2.0-0.dll связан с отсутствующим компонентом Сomdlg32.dll:PrintDLgExW"
3. Arc.exe вылетает с ошибкой "Файл Arc.exe связан с отсутствующим компонентом kernel32.dll: GlobalMemoryStatusEx."

Нужен вывод окна при не удачной распаковке : во время распаковки произошла ошибка
ниже список файлов на которых она произошла (как в WinRAR)

и в общем при ошибках нужен вывод окна в котором говорится что произошло

Добавлено:
greyserg

Цитата:

Windows 98 SE

Windows (x86)
Microsoft Windows 2000, XP and Vista