MSC (media streams compressor)

MSC (media streams compressor) 0.0.6.4

Нет прав для скачивания

vint56

Ветеран
Проверенный
Mickey1s
MSC [media streams compressor] v0.0.6.4 by ProFrager
[command] [-options] infile [outfile]

[commands]:
c : default command. It scans and compresses the data. Requires an
output file.
s : it simply scans input file and displays all that was found to
console. Don't require an output file.
e : extracts on the disk all the files that were found. Don't require
an output file.
ec : extracts on the disk only ready for compression files
(DDS [DXT/RAW], BMP, WAV [PCM], MPEG Layer III) Don't require an
output file.
i : insert files from the disk back into archive. Don't require an
output file.

[options]:
-h, -? : show this help
-log=xxx : MSC saves all output also to log file "xxx"


[options.search_options]:
-wav=N : [N=1] disable(0) or enable(1) RIFF WAVE detection
-raw=N : [N=0] disable(0),enable(1) or advanced(2) raw audio data detection
In the options -mp3 and -raw only one can be equal to 2
-bmp=N : [N=0] disable(0) or enable(1) BMP detection
-dds[DXT,RAW]=N : [DXT=1, RAW=0] disable(0) or enable(1) DXT or RAW DDS
detection
-mp3=N : [N=1] disable(0),enable(1) or nonstandart(2) mp3 detection
-minMP3Frames=N : [N=20] set a minimum number of frames to detect MP3
-maxMP3Block=N : [N=1m] If detected size of mp3 is more than specified, the
file is split into pieces. This is needed to "smooth" unpacking.
-lzma:x:y:... : sets lzma-weighting compression options (bt4/hc4, lc, lp, pb,
fb, mc). Used to determine the best result in DXT DDS (-dxt=2) and
RAW audio (-raw=2). Default values for options:
bt4:lc3:lp0:pb2:fb32:mc32

[options.compress_options]:
-bmf=N: [N=9] compression lvl of bmf packer (1-9). s - optional parameter
that specifies the enhanced compression level, but greatly reduces
the processing speed. This option applies only to
RAW DDS and BMP
-frog=N : [N=off] compression lvl of OptimFrog WAVE packer (1-9). Used only
for PCM WAV and RAW audio.
-tak=N : [N=9] compression lvl of TAK WAVE packer (1-9). Available only TAK
or OptimForg compression, so setting any value one of them results
to resetting the second. This option applies only to PCM WAV and
RAW audio
-dxt=N : [N=2] disable(0), enable(1) DDS DXT optimization, or
lzma-weighting(2) model for optimization results.

[options.size_filter_options]:
-maxDDS[RAW,DXT,MIP]=N : set a maximum size of the processed DDS for a
specific type of operation
-minDDS[RAW,DXT,MIP]=N : set a minimum size of the processed DDS for a
specific type of operation
-max[BMP,WAV,RAW]=N : set a maximum size of the processed BMP, WAVE or RAW
audio file
-min[BMP,WAV,MP3,RAW]=N : set a minimum size of the processed BMP, WAVE, MP3
or RAW audio file
-f :
 
Последнее редактирование:

Kent

Новичок
Может кто то дать батник для того чтобы сжимать файл по цепочке Precomp>MSC>Srep>FreeArc ?
 
Последнее редактирование:

Loner

Новичок
У кого нибудь были ошибки распаковки на НЕКОТОРЫХ системах где юзался MSC?

У некоторых пользователей возникает ошибка при установке..у некоторых зависает на определённом проценте.. Ошибка появляется если используется MSC

Может у кого нибудь тоже наблюдались такие дефекты?:cry:
 

ProFrager

Знаток
Проверенный
у некоторых bmf вешается на распаковке, поэтому не включайте его в настройках msc.
 

ReFLeXx

Новичок
Ne0N, да, есть такая проблема. Испытано на пользователях: архив msc:ddsdxt=0:ddsraw=1:bmf=9:dxt=0:raw=0+srep+lzma - вешается при распаковке у некоторых.
 

Loner

Новичок
Может кто то дать батник для того чтобы сжимать файл по цепочке Precomp>MSC>Srep>FreeArc ?
arc.exe a -ep1 -dses --dirs -s; -lc- -di -i2 -r "-hpПАРОЛЬ" -mprecomp+msc:raw=1:bmf=9:ddsraw=1:bmp=1+srep:a1:l512+lzma:255mb:normal:bt4:273:lc8 data-A.bin packeddata\*
@pause

в arc.ini добавить
[External compressor:msc]
header = 0
packcmd = msc c -v {options} $$arcdatafile$$.tmp $$arcpackedfile$$.tmp
 
Последнее редактирование модератором:

andrey

Мимокрокодил
Precomp+MSC+Srep+FreeArc выдаёт вот такую ошибку
 
Последнее редактирование:

urban

Старожил
andrey, вроде прекомп не нашел что разжать,вот и ошибка
 

toolame

Старожил
Проверенный
-minRAW и -maxRAW опции более не ответственны для RAW аудио? Что то не пойму, чем тогда задается мин\макс размер, плюс в логе вообще не видно какой он (RAWSize отвечает же за DDS), или быть может описание устарело и -minWAV\maxWAV отвечает и за WAV и за RAW WAV?
я это к чему, иногда не получается обойти баг при кодировании "плохого" wav файла, из-за чего весь архив ломается, т.е. он спокойно создается фриарком (при этом, размером явно не дотягивает), но при распаковке просто зацикливается на msc
в логе msc пишется: не могу открыть tmp~000.wav и в папке с прогой, этот самый wav и лежит...
алсо, непонятно почему и зачем, все операции происходят в корневой папке программы, а не в самой рабочей папке
и почему для распаковки требуется сторонний exe'шник (MSC_Unpack), а не тот которым все сжималось, тоже не понятно

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

Mailchik

Старожил
Проверенный
алсо, непонятно почему и зачем, все операции происходят в корневой папке программы, а не в самой рабочей папке
Временные файлы создаются рядом с MSC_Unpack, либо рядом с unarc если вы используете его.
и почему для распаковки требуется сторонний exe'шник (MSC_Unpack), а не тот которым все сжималось, тоже не понятно
Используйте CLS фильтр.
 

Edison007

Ветеран
Модератор
я это к чему, иногда не получается обойти баг при кодировании "плохого" wav файла, из-за чего весь архив ломается, т.е. он спокойно создается фриарком (при этом, размером явно не дотягивает), но при распаковке просто зацикливается на msc
Можете поделиться таким файлом?
почему для распаковки требуется сторонний exe'шник (MSC_Unpack), а не тот которым все сжималось, тоже не понятно
А почему должно одним?
 

toolame

Старожил
Проверенный
Временные файлы создаются рядом с MSC_Unpack, либо рядом с unarc если вы используете его.
в том то и дело, что не в рабочей папке
т.е. если фриарк создает временный архив в %TEMP%, и msc запускается с рабочей папкой в %TEMP%, но оперирует в своей директории
для-чего-почему этот вопрос? Ну например у меня %TEMP% в RAM или на скоростном SSD, а msc на обычном HDD, что в итоге приводит к очень сильной нагрузке на этот самый HDD (из-за кучи мелких I\O операций)
конечно я решил проблему переносом msc папки в RAM...
Используйте CLS фильтр.
насколько я понимаю, это требует замены оригинальных фалов фриарка
для создания например, инсталлеров -- это выход
но для stand-alone системы...
алсо, если последние версии фриарка поддерживают <stdin> <stdout>, то зачем этот CLS велосипед, почему бы не добавить поддержку в msc?

Можете поделиться таким файлом?
неа(
он ~3гига весит (с моим инетом -- это не реально)
хотя, если сильно надо, могу попробовать вырезать HEX-ом нужный кусочек
А почему должно одним?
ну как бы логично что программа должна, как сжимать данные, так и разжимать их

а, я еще не могу понять что значит lzma-weighting для -raw=2, т.е при -raw=1 используется TAK\FROG сжатие, а при -raw=2 найденные равки просто перетасовываются для оптимального сжатия lzma? Если так, то не лучше ли их в SBC жать (вроде у него самая лучшая WAV компрессия)
 

ProFrager

Знаток
Проверенный
но при распаковке просто зацикливается на msc
в логе msc пишется: не могу открыть tmp~000.wav и в папке с прогой, этот самый wav и лежит...
вини винду (скорее всего система индексирования). Да и еще я помню специально добавлял множественные попытки открыть файлы, но и этого, видимо, мало. На некоторых компах такое постоянно при большом числе временных файлов. На некоторых, в том числе моем, такого ни разу не видел.

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

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

Используйте CLS фильтр.
насколько я понимаю, это требует замены оригинальных фалов фриарка
не требуется никаких файлов заменять, ничего исправлять и т.д., в отличие от внешних exe файлов, для которых надо прописывать в arc.ini отдельную секцию.

алсо, если последние версии фриарка поддерживают <stdin> <stdout>, то зачем этот CLS велосипед, почему бы не добавить поддержку в msc?
stdin/stdout - крайне косячная штука. Часто вся эта система виснет на пустом месте, потому я напрочь отказался от ее использования. CLS фильтры для фриарка же крайне удобны и нет проблем в стабильности передачи данных.

я еще не могу понять что значит lzma-weighting для -raw=2
это необходимо только для непосредственного детекта raw аудио. Да и как показала практика -raw=1 быстрее и все же лучше детектит чем со 2м режимом. Сжатие проходит все тем же TAK или Optimfrog'ом при любом режиме детекта.
 

toolame

Старожил
Проверенный
вини винду (скорее всего система индексирования).
неа, отключил индексирование, все равно тоже самое...
вот собственно этот кусочек (в arc архиве)
я компрессил с такой опцией
raw=1:mp3=0:ddsdxt=0:ddsraw=0:bmp=0
но он похоже ломается на чистом WAV
вот такой файл выходит чисто в msc
Да и еще я помню специально добавлял множественные попытки открыть файлы, но и этого, видимо, мало. На некоторых компах такое постоянно при большом числе временных файлов. На некоторых, в том числе моем, такого ни разу не видел.
так может кодировать аудио в <stdin> <stdout> режиме? Вроде и TAK и FROG его поддерживают, или настолько не любовь к нему? Теоретически, это должно увеличить скорость в разы.
не требуется никаких файлов заменять, ничего исправлять и т.д., в отличие от внешних exe файлов, для которых надо прописывать в arc.ini отдельную секцию.
...поместил в директорию фриарка cls-msc.dll
при упаковке: ошибка в msc
приходится переименовывать cls-msc.dll при создании архива...
конфликт имен получается, вместо msc.exe он использует cls-msc.dll
при распаковке: ошибка в msc если не был указан header = 0
придется перепаковывать прежние архивы...

а если ли возможность добавить детект DDS без заголовков? или не реально?
и jpg почему нет? типа из-за precomp'а? а что если он не требуется, тогда jpg'и в пролете остаются
а еще в этом precomp'е, плохой детект png, тоже было бы здорово его добавить
 

Edison007

Ветеран
Модератор
вот собственно этот кусочек (в arc архиве)
я компрессил с такой опцией
raw=1:mp3=0:ddsdxt=0:ddsraw=0:bmp=0
но он похоже ломается на чистом WAV
вот такой файл выходит чисто в msc
У меня нормально упаковывается/распаковывается файл кусок (-wav=0 -raw=1 -ddsDXT=0 -ddsRAW=0 -bmp=0 -mp3=0)
а размер .msc - 7,33 МБ (7*696*945 байт)
 

ProFrager

Знаток
Проверенный
так может кодировать аудио в <stdin> <stdout> режиме? Вроде и TAK и FROG его поддерживают, или настолько не любовь к нему? Теоретически, это должно увеличить скорость в разы.
как-то давно пробовал делать. При передаче данных блоками, у которых размер меньше, чем передаваемый файл, вся это система виснет. Если же размер блока больше - то все нормально. А размер файлов может быть любой, так что нахрен этот stdin/out.

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

а если ли возможность добавить детект DDS без заголовков? или не реально?
теоретически можно. Размер скользящего окна сбора статистики должен быть: несколько раз по размеру алфавита умножить на шаг в структуре данных. Итого 4*256*16 = ~16кб. Точность детекта границ будет размером примерно в половину этого окна, хотя все зависит от самих границ. Но опять же точность детекта будет желать лучшего. Наличие RAW медиа данных гораздо легче зафиксировать нежели dxt dds. Да и с данной системой препроцессинга для dds все это не имеет смысла, от нее толку мало. А вот в паре с более эффективным компрессором можно попробовать)

и jpg почему нет? типа из-за precomp'а? а что если он не требуется, тогда jpg'и в пролете остаются
а еще в этом precomp'е, плохой детект png, тоже было бы здорово его добавить
все есть в прекомпе, зачем еще раз изобретать велосипед? png - тот же zlib, если его создавать нестандартными средствами, то обратно без сохранения дополнительной инфы беспотерьно не вернуть.
Время распаковки при использовании cls-precomp.dll не будет отличаться от времени без его использования. Потому что во-первых он выполняется в параллели с основным процессом, во-вторых при отсутствии всяких там zlib для передачи данных от прекомпа требуется лишь пара memcpy.

неа, отключил индексирование, все равно тоже самое...
вот собственно этот кусочек (в arc архиве)
пока нет возможности протестировать.
 
Последнее редактирование:
Сверху