» FreeArc (часть 4)

я не понял твоего вопроса

1noObman1

Цитата:

Интересует именно вшитый алгоритм, а не отдельные тулзы (с этим проблем и так нет).

Так и не надо комбайн устраивать... Который рухнет под своей тяжестью... и перегруженностью/запутанностью интерфейса.

Для аудиокодеров уж лучше отдельную GUI с прикрученными "отдельными тулзами".
Так дойти можно до "добавьте сжатие в mp3".
Слишком мало людей которые "лабают" lossless audio и репаки игр одновременно.

Цитата:

вообще в srep есть что улучшить. я например знаю как увеличить скорость сжатия в несколько раз, но кому и зачем это нужно?

ну в общем то не особо нужно, но полезно

Цитата:

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

Ну сейчас в основном пакуют rep(.arc)->srep->lzma, дабы снизить многократные рандомные обращения к винту в момент распаковки srep убрав излишки rep'ом.
Цитата:

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

тож думал об этом, только проблем таковых не видел) Да и не вижу сейчас 1)как бы не проблема вовсе - не думаю, что кому то понадобится из срепа распаковывать только часть данных, все равно времени это займет не меньше, чем все. 2) дак никто не мешает сначала все (или пофайлово) в прекомп сунуть, а потом srep+lzma пакануть. Я тут ничего проблемного не вижу.
Цитата:

сейчас precomp, как и положено LZ, записывает откуда из истории надо скопировать данные на текущее место

наверное ты имел ввиду srep.
Цитата:

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

тока пакер будет небось раз в 10 сложнее текущего)
Цитата:

архиватор при распаковке обычно считает crc распаковываемых файлов для проверки целостности, здесь это придётся делать отдельным проходом

нда, реально проверочный проход был бы лишним..
Цитата:

во-вторых, при кусках данных в 512 байт запись такого куска в выходной файл, я боюсь, может потребовать сначала чтения целого кластера (4кб, а на ssd и все 128 кб)

так и вижу анти-рекламу: srep - убийца ssd В текущей реализации lz винда будет кешировать запись, а там уже фигушки на таких расстояниях..)


Цитата:

я не понял твоего вопроса

фильтр=еще один алгоритм, типа delta, rep и т.д. Хочу алгоритм оптимизации dds'ок попробовать вделать.

Цитата:

Ещё раз: разница в сжатии максимум 4 Мб.
Или для Вас максимальное сжатие самоцель ?

По 4 мб на каждый файл и наберётся очень много.


Цитата:

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

В тот то и дело что ТАК и OptimFrog сжимают только непосредственный wav-файл, а не архив с ними и подключить их нормально к фа нельзя. Вот только непонятно зачем тогда они в павер-паке если их нельзя так использовать?

Добавлено:

Цитата:

Так и не надо комбайн устраивать... Который рухнет под своей тяжестью... и перегруженностью/запутанностью интерфейса.

Ну так речь не о перегруженности, а о большей функциональности фа.

1noObman1

Цитата:

По 4 мб на каждый файл и наберётся очень много.

На 1 cd диск (iso/cue).


Цитата:

Ну так речь не о перегруженности, а о большей функциональности фа.

Это уже разница в терминологии.

Цитата:

По теме топика.
Возможно ли реализовать фильтр в ФА с динамически меняющимся размером блока? Т.е. на входе надо детектить необходимый заголовок и соответственно подстраивать текущий блоксайз

да, конечно. на уровне API, предоставляемого FA, есть просто операции "прочитать N байт из входного потока" и "записать N байт в выходной поток". и вообще проще написать прогу, работающую с stdin/out, а затем уже думать о фильтре. может тебе и внешнего фильтра хватит


Цитата:

1)как бы не проблема вовсе - не думаю, что кому то понадобится из срепа распаковывать только часть данных, все равно времени это займет не меньше, чем все

ну а как инсталяции, где можно установить то или это?


Цитата:

2) дак никто не мешает сначала все (или пофайлово) в прекомп сунуть, а потом srep+lzma пакануть. Я тут ничего проблемного не вижу.

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

Добавлено:

Цитата:

тока пакер будет небось раз в 10 сложнее текущего)

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

а распаковку сделать так - в памяти выделяется блок заданного пользователем размера (порядка 500 мб), при распаковке LZ-строк они в него записываются и ссылки на них хранятся в отсортированном по destination offset виде. ну и соответственно используются и удаляются из буфера по мере распаковки файла

если же буфер переполнился, то из него выкидывается *содержимое* наиболее далёких и длинных LZ строк (в надежде что на практике будут выкидываться только строки с длиной >>4кб), при этом:

- если у нас есть физический выходной файл (не stdout) и строка достаточно велика (N*128kb), то мы её сразу на нужное местои записываем
- если у нас есть физический входной файл, то строку просто выкидываем - потом скопируем из него
- иначе - скидываем строку в temp file

ну и вместо самой строки делаем отметочку как мы с ней поступили. когда дело дойдёт до декодирования этого места - поступаем соответственно этой отметке

что тут действительно имеет нехилую логику - так это декодер. зато реализуется вековая мечта человечества - распаковка с 10 гб словарём с буфером в 500 мб


хотя может всё это и не TRUЪ, а правильно - разбить данные на 128 кб куски, посчитать между ними корреляции (тем же самым srep в частности), и затем разложить эти куски в правильном порядке чтобы их дальше уже по человечески ужал обычный lzma

Цитата:

Слишком мало людей которые "лабают" lossless audio и репаки игр одновременно.

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

Цитата:

ну а как инсталяции, где можно установить то или это?

Обычно где есть выбор либо то, либо это устанавливать, архив(ы) с этими файлами на выбор не на столько велики, чтобы для них использовать srep, rep'а хватает. Не знаю, мне пока такое не требовалось на больших объемах данных
Цитата:

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

в любом случае и в цепочке srep->precomp->lzma будут временные файлы...если ты, конечно, прекомп не хочешь в ФА встраивать
Цитата:

без них - только так, как уже сейчас работает, только exe-шник внешний вызываться не будет

и то хорошо
Цитата:

и ссылки на них хранятся в отсортированном по destination offset виде.

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

а распаковку сделать так - в памяти выделяется блок заданного пользователем размера (порядка 500 мб), при распаковке LZ-строк они в него записываются и ссылки на них хранятся в отсортированном по destination offset виде. ну и соответственно используются и удаляются из буфера по мере распаковки файла

подобная идея у меня родилась давно, но даж боюсь браться за такое
Цитата:

а правильно - разбить данные на 1228 кб куски

а почему именно эта цифра?
Цитата:

посчитать между ними корреляции (тем же самым srep в частности), и затем разложить эти куски в правильном порядке чтобы их дальше уже по человечески ужал обычный lzma

это типа xdelta будет с автоматической разбивкой файла на нужные куски и сравнением их друг с другом?

Добавлено:

Цитата:

и вообще проще написать прогу, работающую сstdin/out, а затем уже думать о фильтре. может тебе и внешнего фильтра хватит

кстати заметил такую штуку: lzma_x64 (или как его там) в виде внешнего фильтра один раз из 10 вешает упаковку на 0%. При чем он как бы чего то ждет, не отъедая % от проца. Закрываешь, запускаешь заново - норм отрабатывает.

Цитата:

В тот то и дело что ТАК и OptimFrog сжимают только непосредственный wav-файл, а не архив с ними и подключить их нормально к фа нельзя. Вот только непонятно зачем тогда они в павер-паке если их нельзя так использовать?

ты пробовал? обрати внимание на последнюю строку:

[External compressor:ofr]
mem = 10
default = normal
packcmd = ofr --encode --mode {option} --optimize best --seek min $$arcdatafile$$.wav --output $$arcpackedfile$$.ofr
unpackcmd = ofr --decode $$arcpackedfile$$.ofr --output $$arcdatafile$$.wav
datafile = $$arcdatafile$$.wav
packedfile = $$arcpackedfile$$.ofr
solid = 0

Цитата:

в любом случае и в цепочке srep->precomp->lzma будут временные файлы...если ты, конечно, прекомп не хочешь в ФА встраивать

precomp вполне может распаковывать stdin->stdout, просто его автор не чешется


Цитата:

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

почитай какую-нибудь книгу про алгоритмы и структуры данных. вставка в упорядоченное дерево/B-дерево/пирамиду - log N


Цитата:

а почему именно эта цифра?

имел в виду 128 кб - размер страницы SSD. записывать выходные данные кусками меньшего размера в произвольном порядке чревато. а с точки зрения максимизации степени сжатия куски 128 кб вполне подходят


Цитата:

это типа xdelta будет с автоматической разбивкой файла на нужные куски и сравнением их друг с другом?

наверно да

Не обращаем внимания

Bulat_Ziganshin
По GUI улучшения не придвидятся ?
Показ иконок, поддержка перетаскивания мышью и прочие радости.
Я пока немогу мотивировать всех в компании перейти на FA

Цитата:

ты пробовал?

ТАК - да. После того, как оно прогоняет его в архив без сжатия так выдаёт ошибку что файл не является .WAV. С офр же еще не пробовал.

Добавлено:

Цитата:

solid = 0

То есть нельзя делать солид-архивы? Ну и даже если так, то это сжатие непосредственно для .вав-файлов. Или же оно пожмёт аудио и в игровом архиве?

это как раз те две вещи, которые в gtk2hs очень сложно реализовать

1noObman1
вроде эти обе утилиты только и работают с PCM RAW данными
а в игровых бывает по разному и mp3 и wav
возможно тем более не любой wav сожмется этими утилитами

мдя, жаль ... будем ждать.
сдаётся мне неизбежать перехода на 7z, а затем на FA - как он подоспеет.

kalpak

Да с чем они работают я знаю. Вот в архиве, например, тот же PCM и с тта в фа сжатие архива улучшается, а эти алгоритмы применить к нему не получается.

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

1noObman1

Цитата:

не все архивы можно вскрыть и пожать аудио самому, то хотелось бы что-то, что брало бы архивы целиком и нормально сжимало аудиопотоки

Вам видимо далёки понятие энтропия и закономерности сжатия на пользовательском (эмпирическом) уровне.

Добрый вечер!
Хотел спросить, нельзя ли с делать следующее:
1. чтобы srep сам паковал все файлы в один целый файл, а то просто цепочка, например, 7z (не сжатый) => srep, не всегда удобна для ее распаковки. и можно сделать так, чтобы он был наточен на srep
2. объединить srep + delta, просто как бы цепочка srep => delta, опять таки не всегда удобна

И еще, если кто знает подскажите пожалуйста, здесь.

ndch

И к чему это? Закономерности сжатия мне вполне известны и такое вполне вероятно сделать, и уже сделано в фа - тта - но он жмёт аудио не особо хорошо. Именно поэтому я прошу осуществить такое в фа с более сильным алгоритмом. Фа это лучший архиватор по степени сжатия/скорости распаковки, но, увы, аудио он жмёт плохо.

slech

Цитата:

Я пока немогу мотивировать всех в компании перейти на FA

А оно надо ?
Зачем менеджеру по экологической обстановке комп ?
Прошло время архиваторов для масс.

Цитата:

То есть нельзя делать солид-архивы?

т.е. файлы, сжимаемые этим алгоритмом, пакуются по одному на солид-блок

ndch
надо, разработчики используют WinRar.

Bulat_Ziganshin

Ну вот о чём и речь. Я то говорил совсем о другом - о том что нужен алгоритм который жмёт аудиопотоки в игровых архивах как это делает тта, только сильнее. Пожать вав-файлы отдельно я и сам могу, а так... Но как я понял такого не будет.

ну и пусть используют, что за горе ?
Удобство интерфейса (gui, интеграция) и достаточное количество поддерживаемых архивов (zip rar 7z) - вот главное преимущество WinRAR.

это 5! http://otvet.mail.ru/question/21022296/

Прошу прощения, возможно вопрос уже поднимался, я не нашел. Мой пример: файл 12Гб (игра с установщиком на IS, дефолтная распаковка происходит при помощи IsDone). 2 .arc архива упакованы в 1 srep и снова в arc. При установке возникает ошибка в CRC и всё отменяется. Разархивировал .arc, попробовал напрямую srep -d, то же самое - ошибка, прекращение распаковки. Открыть файл упакованный srep в архиваторе нечем, FreeArc не берет (возможно есть способ подключить srep, чтобы брал?). Есть ли способ при распаковке не останавливаться при ошибке, а пропустить и продолжить разархивацию?

1noObman1

Цитата:

Фа это лучший архиватор по степени сжатия/скорости распаковки, но, увы, аудио он жмёт плохо.

Есть алгоритмы сжатия и есть программы.
Тёплое и мягкое.

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

Недавно мне один человек показывал как у него на ноутбуке игрушка ставится (распаковывается) 50 минут. FIFA. При этом сам репак скачивался от силы 20 минут.

Bulat_Ziganshin

Цитата:

это 5

Это современная реальность...
Страна советов...

Aroyl

Цитата:

возможно есть способ подключить srep

смотри "How to set up FreeArc to use new SREP in filter mode" на этой странице последний вариант подключения