» FreeArc (часть 4)

kalpak
CLS_DONE вызывается только из UnloadDLL(), выполняемой перед выгрузкой unarc.dll. можно сделать иначе, просто пока не надо было

какие у тебя задачи?

Цитата:

иконки такие потому, что это стандартные иконки из gtk - там есть набор для плеера, для редактора текстов, а вот для арзиватора как-то нету по идее вещей надо делать на платной основе

можешь сформулировать требования для иконок ?
сколько и каких - давай искать платный вариант - сколько такое может стоить ?

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

просто не нравится смотреть как выходной файл растет а ты должен сидеть и ждать окончания операции (а дома проц/хард медленные еще дольше ждать приходится)

а насчет CLS_DONE, dll не пользовался, только [un]arc.exe

а если всё же сначала попробовать поискать среди бесплатных?
http://habrahabr.ru/blogs/iconoskaz/114508/

а, это меня фраза про "стандартные иконки" с толку сбила
"фирменную" иконку FreeArc, конечно, ни в каком готовом наборе найти не получится..

протестировал сейчас сжатие в zip:

Z:\vhd>Arc.exe -tzip a a.zip -t
Compressed 1 file, 98,420,528,640 => 47,215,067,186 bytes. Ratio 47.9%
Compression time: real 495.72 secs. Speed 198,540 kB/s
Testing time: real 823.18 secs. Speed 119,561 kB/s

т.е. упаковка работает быстрее распаковки

Цитата:

rc.ini должен быть от майской версии, за чужие arc.ini я не отвечаю

Ну да, я его не трогал.
Вот этот файл http://narod.ru/disk/52697814001.0ab47b2f6b6f9e0e29fdc7f5c3b462a4/1.jpg.html

Цитата:

--sync

Спасибо! Действительно работает, удивительно что этого нете было в справке.
Но m9j пока работает действительно хреново, запускаю -m9j на трёх mp3, и вижу что почему-то запускается packjpg на 30 секунд хотя кроме mp3 там нет jpg.
Теперь я понимаю почему в SqueezeChart2012web.xlsx в разделе JPG FreeARC на последнем месте, автор теста видимо тоже не понял эту нарушенную логику работы пропускать всё без разбору через packjpg даже если там нет jpg.

Если ли сейчас возможность не дожидаясь новой версии изменив .ini запустить отдельно packjpg для каждого jpg (и только для jpg!) и packarc для каждой mp3 ?

Bulat_Ziganshin

Цитата:

-nomd5

так откуда я узнаю что сбой произошёл, если сбой связан с расчётом md5?
или всё таки установленно, что данные получаются на выходе битые?

Bulat_Ziganshin
Булат, а как на счет предварительного теста всех методов сжатия, который я описывал выше? Это совсем не актуально?

нужно что-то наподобие http://www.7-zip.org/logos.html

Цитата:

Вот этот файл http://narod.ru/disk/52697814001.0ab47b2f6b6f9e0e29fdc7f5c3b462a4/1.jpg.html

да, этот файл precomp 0.4.2 не тянет даже при включении jpg-сжатия. может, из-за старой dll или ещё чего


Цитата:

Спасибо! Действительно работает, удивительно что этого нете было в справке.

неправда. ты вообще её читал?


Цитата:

Но m9j пока работает действительно хреново, запускаю -m9j на трёх mp3, и вижу что почему-то запускается packjpg на 30 секунд хотя кроме mp3 там нет jpg.

ещё раз повторю - arc не запускает packjpg, jpg-файлы обрабатываются через precomp


Цитата:

Если ли сейчас возможность не дожидаясь новой версии изменив .ini запустить отдельно packjpg для каждого jpg (и только для jpg!) и packarc для каждой mp3 ?

доку прочти. и посмотри как это было сделано в старых версиях - там packjpg натравливался на группу $jpg, а она была определена как

$jpg
*.jpg
*.jpeg

Цитата:

kalpak
Слушай, а как думаешь, можно ли сделать тест всех вариантов? Ну прям к примеру сжимаешь 20Гб, ставишь на ночь - он у тебя проходится всеми возможными комбинациями, после каждой проходки архив удаляется, чтобы не засорять хард - потом выдается отчет - время, размер на выходе и выигрыш.
Bulat_Ziganshin
Булат, как ты на это смотришь?

а я тут причём? делай

slech
так есть же отдельная тема про логотип для FreeArc - вон её даже в шапку добавили
там и лежат все "нагенерированные пользователями" идеи

или о чём ты?

Bulat_Ziganshin
Ахаха, я же не кодер. Был бы программистом - сделал бы для себя. Я имею в виду - опционально встроить это в архиватор.

Цитата:

неправда. ты вообще её читал?

Всю не читал, признаю. Дошлё до слов arc a backup (через поиск по слову backup) и не увидел там ничего про автоматическое удаление.

sabio
не совсем о логотипе, но может в той теме и продолжить.
речь о иконках интерфейса.

Цитата:

packARC

так это универсальный препроцессор, который затем интегрируете в ФА или самостоятельный архиватор?

в одном из репаков ФА показывает на одном из архивов следующие свойства


в архиве собраны Bink Video файлы, такой высокий уровень сжатия файлов этого типа я еще не видел. Хочется знать каким макаром их сжимали

snkreg
а для чего это встраивать в архиватор? как это будет использоваться?

Цитата:

Here, memory-mapped files degrade -m2 performance even more

а обратили внимание на счётчик, например в Диспетчере задач, Mem Use, что со временем памяти показывается вся доступная.
На что это оказывает влияние это уже другой вопрос, на который я не могу ответить.

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



Цитата:

для меня выходом будет stdin/stdout но там сейчас не доделки, и хотелось бы чтобы у FreeArc\Arc\unarc был полноценный stdin/stdout.

да, я сейчас как рза над этим раюботаю. в самом srep stdin+stdout тоже что-то разладился с 18 февраля, надо разобраться


Цитата:

srep295_x64.exe -d -mem1800m -vmfile=vmfile_temp

-vmfile можно не указывать, там по дефолту future-lz.tmp


Цитата:

для -m1 многопоточность сделать возможно?

при упаковке? уже естью у меня 4-ядерник до 40% нагружается

Bulat_Ziganshin
Смотри, к примеру мне нужно сделать репак - и просчитать какой метод сжатия в FreeArc выгоднее всего. Соответственно я выбираю файлы для упаковки, ставлю опцию "Тест сжатия" и ухожу. В это время он пробегается по файлам всеми возможными комбинациями и записывает это в таблицу сравнения, после чего я делаю вывод и выбираю для себя оптимальный вариант.

Цитата:

так это универсальный препроцессор, который затем интегрируете в ФА или самостоятельный архиватор?

это не моя прога


Цитата:

Хочется знать каким макаром их сжимали

написано же - с помощью bink_unp

Bulat_Ziganshin

Цитата:

имхо лучшая тема по srep - та, в которой никак не упоминается его название. иначе и в неё набегут пионеры

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

у мене така проблема

FA 0.666
win7 and winXP
уровень сжатия ультра с упорядочиванием файлов по расширению
3,25 Гб ОП
С свободно 4,82 Гб
D свободно 296Гб на этот проводится архивация

типа того есть в UPX ( в precomp вроде то же брут но на определенном потоке) кажется
но там то другая ситуация
там размер не большой файла

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

хотя, тогда надо будет знать какие методы комбинировать и как

vasulpr

Цитата:

в одном из репаков ФА показывает на одном из архивов следующие свойства

Ну так что за репак и где лежит он?

VasulNoz
чисти диск С: Не буду объяснять почему.

kalpak
Ну да, вот я и думаю, что было бы удобно в FreeArc реализовать подобное. Ну ничего, что долго, зато автоматизированно и в итоге оптимальный результат

А, это Skymmer делал. Ну эти файлы можно и посильнее пожать, но прибегнув к симметричному сжатию. У тут ассиметрик со словарем маленьким.

VasulNoz
в настройках программы установи tempdir на d:

Цитата:

хотя, тогда надо будет знать какие методы комбинировать и как

Когда-то на форуме видел сообщение автора Ultra7z и, по его словам, он хотел сначала написать пограмму типа UltraFA, но остановился на Ultra7z, т.к. ему было проще разобраться с опциями 7-zip, чем с FreeArc.

Цитата:

так откуда я узнаю что сбой произошёл, если сбой связан с расчётом md5?

fc /b с оригиналом

Цитата:

или всё таки установленно, что данные получаются на выходе битые?

да. в общем, рассказываю, что у меня было: невозможно было вообще проверить, правильно ли работает srep, из-за того что при распаковке сыпались ошибки. думал, что это из-за большого числа I/O операций при обычной распаковке, но потом оказалось, что и распаковка future-lz без ограничений памяти сбоит

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

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

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

для прикола - лог моих тестов (диск g - сбойный, напоминаю что srep создаёт врем. файл в тек. каталоге): [more=лог]F:\Temp>G:\f.cmd G:\lp2.pcf.srep-r

F:\Temp>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d G:\lp2.pcf.srep-r nul
Ratio: 2600468480 -> 1427841725: 54.91%. Cpu 315.115 mb/sec, real 148.644 mb/sec. Matches 16903 17275 101865, I/Os 0, RAM 470/632, VM 0/0, R/W 0/0
ERROR! Checksum of decompressed data is not the same as checksum of original data

F:\Temp>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem1g G:\lp2.pcf.srep-r nul
Ratio: 2600468480 -> 1427841725: 54.91%. Cpu 301.439 mb/sec, real 268.311 mb/sec. Matches 16903 17275 101865, I/Os 0, RAM 470/632, VM 0/0, R/W 0/0
ERROR! Checksum of decompressed data is not the same as checksum of original data

F:\Temp>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem500 G:\lp2.pcf.srep-r nul
Ratio: 2600468480 -> 1427841725: 54.91%. Cpu 296.611 mb/sec, real 259.126 mb/sec. Matches 13148 13520 101865, I/Os 0, RAM 291/459, VM 192/192, R/W 0/192
ERROR! Checksum of decompressed data is not the same as checksum of original data

F:\Temp>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem200 G:\lp2.pcf.srep-r nul
Ratio: 2600468480 -> 1427841725: 54.91%. Cpu 276.444 mb/sec, real 226.211 mb/sec. Matches 11208 11580 105105, I/Os 0, RAM 158/159, VM 368/576, R/W 384/752
ERROR! Checksum of decompressed data is not the same as checksum of original data

F:\Temp>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem100 G:\lp2.pcf.srep-r nul
Ratio: 335544320 -> 216895290: 64.64%. Cpu 294.645 mb/sec, real 224.164 mb/sec. Matches 2399 3548 6909, I/Os 0, RAM 32/59, VM 64/64, R/W 0/64^CЗавершить выполнение паке
тного файла [Y(да)/N(нет)]? y



G:\>G:\f.cmd F:\Temp\lp2.pcf.srep-r

G:\>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d F:\Temp\lp2.pcf.srep-r nul
Ratio: 22069494174 -> 7008860732: 31.76%. Cpu 287.307 mb/sec, real 185.588 mb/sec. Matches 0 174390 1449482, I/Os 0, RAM 0/1919, VM 0/0, R/W 0/0

G:\>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem1g F:\Temp\lp2.pcf.srep-r nul
Ratio: 22069494174 -> 7008860732: 31.76%. Cpu 274.860 mb/sec, real 163.288 mb/sec. Matches 0 174390 1482625, I/Os 0, RAM 0/983, VM 0/1000, R/W 1560/1560

G:\>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem500 F:\Temp\lp2.pcf.srep-r nul
Ratio: 7365197824 -> 4428665852: 60.13%. Cpu 292.157 mb/sec, real 104.050 mb/sec. Matches 4254 18705 190765, I/Os 0, RAM 156/459, VM 1440/1656, R/W 216/1656
ERROR! Checksum of decompressed data is not the same as checksum of original data

G:\>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem200 F:\Temp\lp2.pcf.srep-r nul
Ratio: 7365197824 -> 4428665852: 60.13%. Cpu 259.695 mb/sec, real 165.344 mb/sec. Matches 4893 12391 211440, I/Os 0, RAM 152/159, VM 1464/2136, R/W 1736/3200
ERROR! Checksum of decompressed data is not the same as checksum of original data

G:\>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem100 F:\Temp\lp2.pcf.srep-r nul
Ratio: 7365197824 -> 4428665852: 60.13%. Cpu 215.878 mb/sec, real 120.354 mb/sec. Matches 1026 8544 264278, I/Os 0, RAM 52/59, VM 1624/2360, R/W 4096/5720
ERROR! Checksum of decompressed data is not the same as checksum of original data



F:\Temp>G:\f.cmd F:\Temp\lp2.pcf.srep-r

F:\Temp>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d F:\Temp\lp2.pcf.srep-r nul
Ratio: 7365197824 -> 4428665852: 60.13%. Cpu 305.780 mb/sec, real 229.560 mb/sec. Matches 29409 31697 188028, I/Os 0, RAM 1382/1872, VM 0/0, R/W 0/0
ERROR! Checksum of decompressed data is not the same as checksum of original data

F:\Temp>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem1g F:\Temp\lp2.pcf.srep-r nul
Ratio: 7365197824 -> 4428665852: 60.13%. Cpu 295.632 mb/sec, real 248.457 mb/sec. Matches 7637 27310 188028, I/Os 0, RAM 492/983, VM 952/952, R/W 0/952
ERROR! Checksum of decompressed data is not the same as checksum of original data

F:\Temp>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem500 F:\Temp\lp2.pcf.srep-r nul
Ratio: 7365197824 -> 4428665852: 60.13%. Cpu 285.963 mb/sec, real 202.580 mb/sec. Matches 4254 18705 190765, I/Os 0, RAM 156/459, VM 1440/1656, R/W 216/1656
ERROR! Checksum of decompressed data is not the same as checksum of original data

F:\Temp>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem200 F:\Temp\lp2.pcf.srep-r nul
Ratio: 234881024 -> 146617058: 62.42%. Cpu 307.273 mb/sec, real 102.757 mb/sec. Matches 2939 3548 6594, I/Os 0, RAM 80/107, VM 0/0, R/W 0/0^CЗавершить выполнение пакетн
ого файла [Y(да)/N(нет)]? y



U:\>G:\f.cmd U:\lp2.pcf.srep-r

U:\>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d U:\lp2.pcf.srep-r nul
Ratio: 22069494174 -> 7008860732: 31.76%. Cpu 277.883 mb/sec, real 198.049 mb/sec. Matches 0 174390 1449482, I/Os 0, RAM 0/1919, VM 0/0, R/W 0/0

U:\>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem1g U:\lp2.pcf.srep-r nul
Ratio: 22069494174 -> 7008860732: 31.76%. Cpu 264.975 mb/sec, real 176.744 mb/sec. Matches 0 174390 1482625, I/Os 0, RAM 0/983, VM 0/1000, R/W 1560/1560

U:\>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem500 U:\lp2.pcf.srep-r nul
Ratio: 22069494174 -> 7008860732: 31.76%. Cpu 248.717 mb/sec, real 155.206 mb/sec. Matches 0 165382 1621776, I/Os 0, RAM 0/460, VM 0/1656, R/W 3768/3768

U:\>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem200 U:\lp2.pcf.srep-r nul
Ratio: 2181038080 -> 1159031584: 53.14%. Cpu 265.293 mb/sec, real 143.418 mb/sec. Matches 6845 9046 87945, I/Os 0, RAM 128/159, VM 496/576, R/W 224/720^CЗавершить выпол
нение пакетного файла [Y(да)/N(нет)]? y



F:\Temp>G:\f.cmd F:\Temp\lp2.pcf.srep-r

F:\Temp>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d F:\Temp\lp2.pcf.srep-r nul
Ratio: 22069494174 -> 7008860732: 31.76%. Cpu 275.395 mb/sec, real 168.174 mb/sec. Matches 0 174390 1449482, I/Os 0, RAM 0/1919, VM 0/0, R/W 0/0

F:\Temp>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem1g F:\Temp\lp2.pcf.srep-r nul
Ratio: 22069494174 -> 7008860732: 31.76%. Cpu 265.323 mb/sec, real 154.438 mb/sec. Matches 0 174390 1482625, I/Os 0, RAM 0/983, VM 0/1000, R/W 1560/1560

F:\Temp>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem500 F:\Temp\lp2.pcf.srep-r nul
Ratio: 22069494174 -> 7008860732: 31.76%. Cpu 249.243 mb/sec, real 137.346 mb/sec. Matches 0 165382 1621776, I/Os 0, RAM 0/460, VM 0/1656, R/W 3768/3768

F:\Temp>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem200 F:\Temp\lp2.pcf.srep-r nul
Ratio: 22069494174 -> 7008860732: 31.76%. Cpu 185.656 mb/sec, real 103.877 mb/sec. Matches 0 70888 2376056, I/Os 0, RAM 0/160, VM 0/2136, R/W 12120/12120

F:\Temp>"C:\!\FreeArchiver\Compression\SREP\srep64i.exe" -d -mem100 F:\Temp\lp2.pcf.srep-r nul
Ratio: 22069494174 -> 7008860732: 31.76%. Cpu 94.845 mb/sec, real 59.705 mb/sec. Matches 0 29368 4950862, I/Os 0, RAM 0/60, VM 0/2360, R/W 36760/36760
[/more]