» Форматы|кодеки|снятие и обработка звука|lossless&lossy|codec

TCPIP
Wenzel
А можно и кого-нть КРОМЕ ЕАС поюзать - он конешна лучший в своем роде - но не единственный, если диск читается без проблем, так вообще ИМХО без разницы чем конкретно сейвить треки, можно той же нерой например.

Darth_Vader

Цитата:

ИМХО без разницы чем конкретно сейвить треки, можно той же нерой например...

Я то же думаю что свет клином на еас не сошелся. Все равно чем снимать треки, если они снимаются правильно и без искажений. Раньше когда юзал w98 я все время использовал cdfs драйвер и копировал треки windows commander-ом. Иногда использовал Audiocatalyst и Audiograber, но всегда в логах проверял выскакивали ошибки или нет. А обрабатывал звук Lame-ом тоже всегда отдельно, предварительно проверив качество снятых треков.

help777

Цитата:

Раньше когда юзал w98 я все время использовал cdfs драйвер и копировал треки windows commander-ом.

Тоже ничего вариант дешево и сердито, особенно когда постоянно с коммандером работаешь. У меня так на него вообще тусова плугинов стоит, включая таск менеджер, регедит, унинсталлер, унеразер, поддержку MSI, ISO, etc.

;)Darth_Vader

Цитата:

У меня так на него вообще тусова плугинов стоит...

Я тоже думаю что с командером было удобнее;), особенно когда
Цитата:

вообще тусова плугинов стоит

;). Надо бы плагин для командера сделать чтобы он нормально треки сдирал.

Купил Трубу SonyEricsson P910i.
Поддерживает формат "Video/X-RN-MP4" никак не могу найти этот формат или кодек.
Помогите с траблом.

Intakto
Это формат MPEG-4.


Вышел FLAC 1.1.2 , чейнджлог здесь.

Darth_Vader
07:31 01-02-2005
Цитата:

так вообще ИМХО без разницы чем конкретно сейвить треки, можно той же нерой например.

Увы. Нера передерает треки. А как заставить ее передрать диск целиком в один wav?

TCPIP
И оно таки уже тебе туда надо? Понятия не имею... есть масса другой тулзы, которая умеет то же самое...

ALL
Лазая на хомяке FLAC, набрел на сравнение безпотерьных кодеров, и невзначай обнаружил абсолютного лидера по степени сжатия и при этом еще гораздо более толерантного к ресурсам чем OFR, как при кодировании так и при декодировании - LA (Lossless Audio, www.lossless-audio.com ). Стянул кодер версии 0.4b и проверил сам - действительно, даже мартышка версии 3.99 отстает на 5-6 Мб на CD, что впечатляет.
Плугины для фубара и винампа (последние, кто не в курсе - могут быть подложены в \Plugins к Apollo и использоваться им как "родные") прилагаются к самому кодеру, DShow-фильтр пока отсутствует, однако есть API к la-core.dll (в отличие от большинства других кодеров, ядро этого представляет собой dll, размещаемый в %SystemDir% e.g. \System32 и его наличие необходимо как для кодирования, так и для декодирования), позволяющий внедрить декодирование файлов LA практически в любой фронтенд, плеер, etc.
Исходники, *естесственно*, закрыты. Тем не менее, автор *пока* не намерен наживаться на патентах и лицензировании, поэтому бинарные модули раздаются безплатно. Поддерживаются теги, поиск работает шустрее чем в OptimFROG (на мой глаз), кодирование также - в разы быстрее чем с OFR. Гибридного режима, конечно, нет, что вполне естесственно: основной задачей при создании кодека было безкомпромиссное кодирование с наибольшей возможной степенью сжатия.
Из платформ, помимо win32, сущестует также набор бинарных модулей для UNIX.
Версия 0.3 не поддерживала стриминг, но и обезьяна тоже не поддерживает, да и вообще, ИМХО - для безпотерьных кодеков сие есть весьма сомнительное по необходимости усовершенствование...
Бинарные файлы текущей версии для win32: _hxxp://www.lossless-audio.com/La04b.exe

Darth_Vader

Цитата:

Лазая на хомяке FLAC, набрел на сравнение безпотерьных кодеров, и невзначай обнаружил абсолютного лидера по степени сжатия и при этом еще гораздо более толерантного к ресурсам чем OFR

Ну абсолютным лидером он явно не является. Глянь хотя бы на эти тесты: .www.foobar2000.net/lossless/

Он "в разы быстрее чем OFR", только если в OFR ты используешь "экстремальный" режим вроде bestnew -seekslow, который сам по себе неудобен в использовании.

LA очень медленный. Кодирование и декодирование у него в 4 раза тормознее, чем OptimFrog в режиме default, и в 2 раза - чем MonkeyAudio в режиме insane. Т.е. о толерантности к ресурсам говорить вообще не приходится.


Цитата:

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

Трудно "наживаться" на кодеке, имеющем нулевую популярность

И всетаки что лучше : stereo или join stereo ?

Benchmark

Цитата:

Ну абсолютным лидером он явно не является. Глянь хотя бы на эти тесты: .www.foobar2000.net/lossless/

Я глядел на тесты. Сжимая CD у себя. Другие тесты меня после этого не интересуют - трудно не верить тому, в чем убедился сам.


Цитата:

Он "в разы быстрее чем OFR", только если в OFR ты используешь "экстремальный" режим вроде bestnew -seekslow, который сам по себе неудобен в использовании.

Он быстрее в 3-4 раза, чем OFR --mode best --optimize best, и при этом еще лягушка жмет слабее обезьяны, а обезьяна - слабее чем LA. При insane, естесственно. bestnew у меня кстати делает файлы такого же веса или толще чем вышеуказанный пресет.


Цитата:

LA очень медленный. Кодирование и декодирование у него в 4 раза тормознее, чем OptimFrog в режиме default, и в 2 раза - чем MonkeyAudio в режиме insane. Т.е. о толерантности к ресурсам говорить вообще не приходится.

Как я уже сказал, для безпотерьных кодеров не вижу никакого смысла в использовании иных режимов, чем максимальное возможное сжатие, но одно скажу опреденно: декодирование LA вряд ли может быть в два раза медленнее обезьяны, иб0 при декодировании плугинами и тот и другой потребляют 00% времени процессора, и только в WMP через DShow практически все форматы кушают около 20% (при выключенной визуализации).


Цитата:

Трудно "наживаться" на кодеке, имеющем нулевую популярность

Вряд ли она у него нулевая. По крайней мере, лично я 2 CD в нем уже пожал.


reanimator
Второе. Позволяет сохранить больше звучания, не тратя биты на кодирование одинаковой составляющей двух каналов в каждом фрейме, вместо чего кодируются "общая" и "разностная" составляющие.

Darth_Vader

Цитата:

вместо чего кодируются "общая" и "разностная" составляющие.

Но это разве не зависит от самой музыки ? Вроде джойн лучше если звук по каналам одинаков, если же он разный, то лучше использовать стерео. Или я не прав ?

reanimator
ЛоЛ... все равно, значительня часть там и там будет одинаковой (посмотри любой стереозвуковой файл в редакторе наподобие Adobe Audition). Так или иначе, не может быть такой ситуации, в которой выделение бит на кодирование одинаковых данных на обоих каналах даст результат лучше, чем кодирование этих данных в одном экземпляре, и выделение "лишних" бит на разностную составляющую.

Darth_Vader

Цитата:

Как я уже сказал, для безпотерьных кодеров не вижу никакого смысла в использовании иных режимов, чем максимальное возможное сжатие, но одно скажу опреденно: декодирование LA вряд ли может быть в два раза медленнее обезьяны, иб0 при декодировании плугинами и тот и другой потребляют 00% времени процессора

Если бы они на самом деле потребляли 00% процессорного времени, ничего бы не декодировалось Task Manager тут не показатель, измерять надо по времени, уходящему на полное декодирование файла. Для LA оно явно больше, чем для .ape. Крайне медленное декодирование делает формат даже потенциально неприменимым в аппаратных плеерах.


Цитата:

Вряд ли она у него нулевая. По крайней мере, лично я 2 CD в нем уже пожал.

Десяток-другой юзеров погоды не делают. На фоне flac или monkey, распространенность LA близка к нулю.

Darth_Vader
13:46 08-02-2005
Цитата:

И оно таки уже тебе туда надо? Понятия не имею... есть масса другой тулзы, которая умеет то же самое...

Тьфу ты. Опять за рыбу деньги. Чуток кокретнееееее-е-е-е-е.

Есть ли способ проверить пережат ли мп3шник с меньшего битрейта в больший ? Если да, то как ?

Добавлено:
Понятно что 128 от 320 просто отличить по спектру, а вот вбр от 256.

reanimator
18:14 09-02-2005
Цитата:

Есть ли способ проверить пережат ли мп3шник с меньшего битрейта в больший ?

Ты имеешь в виду на лету?
Если можно, вопрос: зачем перекодировать лосси с меньшего битрейта в больший? Что это дает?

TCPIP

Цитата:

Ты имеешь в виду на лету?

Нет. Вот есть у меня мр3 файл, я сомневаюсь что его битрейт 256, мне кажется что он был пережыт с 160 например. Вот это можно как-то узнать ?

Benchmark


Цитата:

Если бы они на самом деле потребляли 00% процессорного времени, ничего бы не декодировалось

Это если бы 00.00...%, а так - вероятно, потребляется 00.xx%, но мне совершенно безразлично чему равно это хх, потому что это совершенно несерьезно.


Цитата:

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

А смысл? Если все равно файл декодируется плеером в реальном времени?


Цитата:

Крайне медленное декодирование делает формат даже потенциально неприменимым в аппаратных плеерах.

Во-первых, ИМХО очень много времени пройдет пока какой-нибудь серьезный безпотерьный формат будет реализован в аппаратных плеерах, FLAC и TTA я серьезными не считаю из-за их убожества в смысле сверхнизкой эффективности сжатия; во-вторых, я полагал что аппаратная поддержка декодирования реализуется путем создания аппаратной реализации того же самого алгоритма декодирования, который используется в программном декодере, т.е. изготовления соответствующего микрочипа или его части, способного декодировать соответствующий формат полностью в реальном времени. Нет, понятно что это должен быть бо-ме серьезный микропроцессор, способный кэшировать данные ввода/вывода и промежуточные, предсказывать то да се, но таки все аппаратно!


Цитата:

Десяток-другой юзеров погоды не делают. На фоне flac или monkey, распространенность LA близка к нулю.

Нащет FLAC не знаю, а обезьяна действительно очень популярна... но таким макаром наверное можно приравнять к нулю и WV и OFR...

reanimator
Узнать сие по сонограмме, я полагаю, было бы не так просто, и возможно более всего для опытного эксперта в части визуального анализа таковых. Отличить Audio CD, разжатый из мр3, еще худо-бедно можно: на websound.ru была статья на сей предмет, а вот различить мр3 с разными битрейтами...
Технически же сделать это (пережать) - проще пареной репы, поскольку после декодера звук в формате РСМ можно перенаправить на ввод любого енкодера мр3, в винампе например можно делать такую конверсию на лету, кроме того - любым редактором можно сделать эту операцию. Хотя это маразм, поскольку при пересчете сэмплов звук сильно смазывается и искажается... полагаю, что пережатый мр3 можно определить на слух - и даже проще, чем по сонограмме.

TCPIP

Цитата:

Тьфу ты. Опять за рыбу деньги. Чуток кокретнееееее-е-е-е-е.

Если ты не понял, я таким никогда не занимался, и не интересовался этим вопросом - только случайно встречал упоминание такой возможности с настройках ряда софтин, среди которых прежде всего ЕАС, CDEx, Easy CD-DA.

Darth_Vader

Цитата:

Во-первых, ИМХО очень много времени пройдет пока какой-нибудь серьезный безпотерьный формат будет реализован в аппаратных плеерах, FLAC и TTA я серьезными не считаю из-за их убожества в смысле сверхнизкой эффективности сжатия;

Поддержка FLAC есть точно в Rio Karma. Насчет TTA - не знаю. По-моему ни в одном мобильном плеере его поддержки нет, стационарные плееры не интересны. К тому же тут, похоже, вечная дилема - или высокая скорость декомпрессии и низкая ресурсоемкость, или хорошее сжатие.


Цитата:

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

Ну для mp3 так оно и есть. Для остальных форматов - не знаю. Тут ведь еще проблема. Допустим, кто-то сделает поддержку декодирования, к примеру, monkey. Но от одной и той же батарейки плеер сможет либо 8 часов играть mp3, либо (к примеру) 1-1,5 часа - мартышку. И кому такое будет нужно ?


Цитата:

Нащет FLAC не знаю, а обезьяна действительно очень популярна... но таким макаром наверное можно приравнять к нулю и WV и OFR...

Да так оно и есть.

Benchmark

Цитата:

Поддержка FLAC есть точно в Rio Karma. Насчет TTA - не знаю.

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


Цитата:

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

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


Цитата:

Тут ведь еще проблема. Допустим, кто-то сделает поддержку декодирования, к примеру, monkey. Но от одной и той же батарейки плеер сможет либо 8 часов играть mp3, либо (к примеру) 1-1,5 часа - мартышку. И кому такое будет нужно?

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

Darth_Vader

Цитата:

Гы... а вот лично я сильно сомневаюсь в том, что в мини-наушниках, в толпе или общественном транспорте, или вообще где-нибудь где обычно носишь с собой плеер, аудио без потерь можно будет отличить от мр3 или ogg, на крайний случай.

Согласен, для улицы mp3 192 - выше крыши. Но ведь не всегда слушаешь переносной плеер на улице, бывает ведь хочется и на работу, и в поездку в отпуск с собой взять. Т.е. когда слушаешь в тихой спокойной обстановке, а стационарного плеера по близости нет.


Цитата:

Я бы не был так уверен в том, что микрочип декодирующий более сложный формат, будет иметь настолько же линейно б0льшее энергопотребление, чем чип декодирующий мр3

Такой чип просто нецелесообразно разрабатывать. Как раз одна из причин -
Цитата:

сомневаюсь в целесообразности проигрывания безпотерьного аудио именно в мобильных плеерах

Darth_Vader
01:46 10-02-2005
Цитата:

Если ты не понял, я таким никогда не занимался

Понял. Действительно не понял. Continue...
Извини за беспокойство.
Я думал, ты свои 4 терабайта именно таким образом получал... Значит, ты их скачал. Вот это я понимаю!
reanimator
23:49 09-02-2005
Цитата:

мне кажется что он был пережыт с 160 например. Вот это можно как-то узнать ?

У True Audio есть программа, позволяющая по спектральному составу сделать заключение был ли файл транскодирован из lossy-файла... Что тупо приходит на ум --- сравнить декодированный поток от одного и того же файла с разным битрейтом.

TCPIP

Цитата:

Я думал, ты свои 4 терабайта именно таким образом получал... Значит, ты их скачал. Вот это я понимаю!

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

Darth_Vader
05:06 11-02-2005
Цитата:

Чего ерничать,

Дык я и не ерничаю...

Цитата:

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

А что ты делаешь с нулевыми паузами между композициями?

Darth_Vader
По поводу LA. Опять меня удивляет, что Athlon 3200+ дает настолько прочихаться P4 2400… Я думал, что может быть разница, но чтоб такая… да еще при том, что P4 вечно кичится своей скоростью обработки потоковой информации. Хотя, трешка была непотоковая, а четверка я что-то не понял, но, судя по всему, тоже осталась беспоточная и все отличие только в двукратном увеличении скорости кодирования в обычном режиме, так а для старой скорости кодирования оставлен режим High. Так что преимущества в обработке потоковой информации, видимо, ни при чем. У меня загрузка процессора не падает ниже 20%, а в среднем держится на уровне 40% (режим High), так что работать при прослушивании становится невозможно --- задержки при перемещении указателя мыши серьезно раздражают! Экономия в сжатии существенная --- 5%. Единственное, что не нравится железно: неправильная прокрутка. При работе с cue-файлами переход осуществляется не на то место… в моем случае на пару секунд раньше, так что вместо начала дорожки слышен сперва конец предыдущей. Это жаль. В нормале можно было бы даже слушать...

TCPIP

Цитата:

А что ты делаешь с нулевыми паузами между композициями?

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


Цитата:

Единственное, что не нравится железно: неправильная прокрутка. При работе с cue-файлами переход осуществляется не на то место… в моем случае на пару секунд раньше, так что вместо начала дорожки слышен сперва конец предыдущей.

Не знаю как нащет CUE - не юзал, а так - вроде по отдельным файлам поиск туды-сюды...

Нащет тормознутости пня - мну это тоже удивляет, и не слишком радовает, поскольку если LA так тормозит на интеле, это так или иначе ограничивает его применимость...

Darth_Vader
01:44 16-02-2005
Цитата:

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

Но это не решает проблемы, когда дорожка 2 начинается за несколько секунд до конца дорожки 1! Если я добавлю в конец дорожки 1 паузу, то, тем самым, я прерву воспроизведение мелодии!
Пример:

Цитата:

TRACK 10 AUDIO
TITLE "Everything's Alright"
PERFORMER "Tim Rice & Andrew Lloyd Webber"
INDEX 00 34:43:46
INDEX 01 34:45:46
TRACK 11 AUDIO
TITLE "I Don't Know How to Love Him"
PERFORMER "Tim Rice & Andrew Lloyd Webber"
INDEX 01 35:21:26
TRACK 12 AUDIO

TCPIP

Цитата:

Но это не решает проблемы, когда дорожка 2 начинается за несколько секунд до конца дорожки 1! Если я добавлю в конец дорожки 1 паузу, то, тем самым, я прерву воспроизведение мелодии!

Пардон, но как сие возможно? Вообще-то, на Audio CD ставится стандартная пауза - 2 секунды, и треки расположены в одной спиральной дорожке последовательно друг за другом с паузами, fadeout по идее можно сделать только средствами плеера, а на самом CD никакого "нахлеста" быть не может (да и зачем)?

Обновился энкодер Musepack до версии 1.15t.


Цитата:

mppenc 1.15t is out. It handles teh_sample properly now. The problem was a result of aggressive compiler settings in previous versions.

The new versions for both Windows and Linux are now compiled by ak using GCC. It allows for easier maintenance and ensures that we release compatible binaries that produce the exact same encoded files.

The new encoder should produce files with a bitrate similar to 1.15s, but in many cases slightly lower or higher (1-2 kbps at --standard). We've thoroughly tested it on a Pentium 3, Pentium 4, Athlon, Athlon XP, Athlon 64, G5 (Mac). Speed is mostly
the same as before but on some computers it is slightly lower. Frank Klemm advises to be very careful when compiling with certain flags and we've followed this advice.

Future plans:

We're currently testing yet another problematic sample which could be indicative of a problem with SV7 (SV8 can easily handle it). We're in direct contact with Frank and it's possible that the next version of the code will include minor changes to psy.c. It's time to tweak the encoder and slowly finalize SV7 before we tackle the more demanding challenge of a new stream version.

_http://files.musepack.net/windows/encoder/mppenc-windows-1.15t.zip