mp3

Подскажите пожалуйста, почему записанные с компа файлы в формате mp3, dvd проигрыватель с такой функцией не видит, а заводские mp3 читает. Может что не так делаю?

скорее всего пишете слишком высокий битрейд.
аппарат на него не расчитан.

Некоторые ДВД могут не понимать мультисессионные диски. Писать выше 256 кБит/с не имеет смысла - выигрыш в компактности уже не тот, да и качество уже не улучшается так критически - лучше уж wav'ы в CDDA писать, а нормальному тракту и 192 кБит/с с головой хватит. А такие битрейты, я думаю, понимают все ДВД с функцией проигрывания mp3.

htkmcs писал(а):

Подскажите пожалуйста, почему записанные с компа файлы в формате mp3, dvd проигрыватель с такой функцией не видит, а заводские mp3 читает. Может что не так делаю?

Проблема в стандартах. Проверьте, записываются ли на диск ISO9660 и Joliet сессии. Попробуйте записать и то и то вместе и по раздельности. Так же не забывайте закрывать диск полностью. Используйте 2 разных ПО для прожига. Nero Burning ROM и WinON CD 5.2 (не выше). Должно что то из этих вариантов заработать точно.

Удачи.

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

Писать выше 256 кБит/с не имеет смысла - выигрыш в компактности уже не тот, да и качество уже не улучшается так критически - лучше уж wav'ы в CDDA писать, а нормальному тракту и 192 кБит/с с головой хватит.
Соласен с уточнением: либо 192 CBR, если качество не очень напрягает, либо если напрягает то 160-320 VBR. Это лучше по качеству, чем 256 CBR. И ни в коем случае не использовать дурацкую установку "-q 0", которую очень любят юные пионэры, толком не разобравшиеся в документации к LAME. Либо "-q 2", либо просто "-h" (собственно, это одно и то же...)

Любопытствующий писал(а):

Соласен с уточнением: либо 192 CBR, если качество не очень напрягает, либо если напрягает то 160-320 VBR. Это лучше по качеству, чем 256 CBR.

Все правильно, VBR из головы что-то выпало - самое главное, что у меня почти все самодельные mp3 в машине в 160-320 VBR.

Я стандартные пресеты не юзаю - люблю чтобы "все было под контролем" . Поэтому путем своих и чужих проб и ошибок вывел для себя такой вот оптимум: <-b 160 -B 320 -m j -q2 --vbr-new -V0> (это командная строка для LAME).

Для начала я бы убедился в том, что носитель соответствует заявленным характеристикам( например, мой двд плеер не понимает мр3, записанные на DVD диск - ему нужны мр3 только на CD). Как у Вас - не знаю, читаем инструкцию
Второе - проверить, что записанный диск финализирован - очень многие плееры не любят не финализированных дисков, а вот ПК это в общем-то всё равно...

То, что возможна несоместимость по битрейту или частоте выборки я тоже допускаю, но оглядываясь на современный рынок (в части всеядности плееров относительно частот и битрейтов файлов мр3) я эту причину поставил бы на последнее место. По крайней мере первые две мной указанные проверить просто необходимо.

Любопытствующий писал(а):

Я стандартные пресеты не юзаю - люблю чтобы "все было под контролем" . Поэтому путем своих и чужих проб и ошибок вывел для себя такой вот оптимум: <-b 160 -B 320 -m j -q2 --vbr-new -V0> (это командная строка для LAME).

Это конечно уже оффтопик, но все же. Почему при допустимости битрэйта 320 кБит Вы используете ключик "-m j" ? Если не секрет, по какой причине вы избрали режим VBR, а не ABR ? Ведь VBR по своей сути (даже с новой моделью поведения "new VBR") по качеству уступает режиму ABR. Я уж не говорю про соотношение качество/размер.

Кому интересно, попробуйте вот эту строчку: "-h -m s --abr 198 --lowpass 18000"
Субъективно на слух, благодаря отческе частот выше ~17,5кГц, звучание в ВЧ области становится менее дубовым, при этом я бы даже сказал что звучание преобретает естественность. Что касается ключика "--abr 198", то битрэйт выбирается в зависимости от стиля музыки. Если вдруг, нужно будет сжать классику в mp3, то цифру 198 лучше сменить на 206. Вроде бы, изменения в цифрах не большие, но кодер резко меняет политику сжатия.

Кому хочется продолжить беседу, можно в мыло dmitrii_22@mail.ru или в асю 286-459-996.

Это конечно уже оффтопик, но все же. Почему при допустимости битрэйта 320 кБит Вы используете ключик "-m j" ?
Потому что чудес на свете не бывает. Если мы делим битрейт пополам (<-m s> - Stereo) - то на каждый канал выделяется ровно половина битрейта, независимо ни от чего. Если же мы кодируем звук + разницу между каналами (<-m j> - Joint Stereo) - то "на звук" как правило выделяется больший битрейт (разница между каналами почти всегда занимает меньше места, чем полноценный канал). Я попытаюсь проиллюстрировать:

-m s (битрейт на 1 канал / битрейт на 2 канал)

|--------------------|--------------------|

-m j (битрейт на оба канала / битрейт на разницу между ними)

|------------------------------|----------|

Режим JS (кстати, о каком именно речь - об "MS", или "Intensity") хорош при необходимости сильной экономии пространства под файл. На 90% треков при кодировании в JS Intensity стереопанорама искажется (хорошо слышимые на слух фазовые искажения). Странная экономия, учитывая заведомо худший результат по сравнению с режимами stereo или вообще dual channel...

кстати, о каком именно речь - об "MS", или "Intensity"
Я же давал опцию: <-m j>. Т.е. mid/side по возможности, но если не имеет смысла - тогда обычное stereo.
хорош при необходимости сильной экономии пространства под файл
Ничего подобного. Вы сами-то пробовали кодировать и так, и этак, на современных версиях LAME (3.8 и старше)? Размер файла при кодировании в Stereo и Joint Stereo практически не отличается. См. рисунок в моем предыдущем постинге - оттуда видно, почему.
На 90% треков при кодировании в JS Intensity стереопанорама искажется (хорошо слышимые на слух фазовые искажения).
Заблуждение, достаточно характерное для тех, кто закончил эксперименты с Joint Stereo на версиях LAME младше 3.8. Там он действительно был ужасненький... Однако все течет, все изменяется - его уже довольно давно довели до ума.

Я же давал опцию: <-m j>. Т.е. mid/side

Ага, сорри, не доглядел. На память командную строку и её значения не помню.

Вы сами-то пробовали кодировать и так, и этак, на современных версиях LAME (3.8 и старше)? Размер файла при кодировании в Stereo и Joint Stereo практически не отличается.

Пробовал. На Lame 3.96. На самом деле экономия действительно не большая, и в случае с Lame VBR, результирующее качество в MS действительно неплохое и возможно спорно со stereo. А вот в кодерах Fraunhofer и в Lame CBR (хотя, на счёт свежих версий последнего не уверен) в JS применяется дополнительный механизм "Sparsing of side channel", понижающий качество в side канале (из-за меньшего кол-ва выделяемых бит на side-канал), но повышающего соответственно качество mid-канала...

Лично меня вполне устраивает stereo c VBR-ABR...

А вот в кодерах Fraunhofer
Каюсь - давно не юзал старичка... Какой-то он по нонешним стандартам до предела упрощенный. Да и каКчество ничуть не лучше, чем у LAME, IMHO. При весьма тормозной скорости (по сравнению опять-так с LAME).

Любопытствующий писал(а):

Потому что чудес на свете не бывает. Если мы делим битрейт пополам (<-m s> - Stereo) - то на каждый канал выделяется ровно половина битрейта, независимо ни от чего. Если же мы кодируем звук + разницу между каналами (<-m j> - Joint Stereo) - то "на звук" как правило выделяется больший битрейт (разница между каналами почти всегда занимает меньше места, чем полноценный канал). Я попытаюсь проиллюстрировать:

Ну почему же, чудеса бывают. Конечно, все это дело слуха и вкуса. Но мне на слух не нравится звучание joint стерео. У меня создается ощущение плоской панорамы. Поэтому и спросил. А про VBR вы мне так и не ответили...

Любопытствующий писал(а):

Цитата:

хорош при необходимости сильной экономии пространства под файл

Ничего подобного. Вы сами-то пробовали кодировать и так, и этак, на современных версиях LAME (3.8 и старше)? Размер файла при кодировании в Stereo и Joint Stereo практически не отличается. См. рисунок в моем предыдущем постинге - оттуда видно, почему.

Как не отличается? Как раз отличается. Lame v3.96.1 stable version. Только что сжал вашей строкой композицию от SUBTONAL "Centennial" 6.24 мин. В первом случае Joint Stereo, размер 10127640 байт, стерео режим 11512140 байт. Не отличаются? 1.4 мБайта это большие отличия. При хорошем раскладе, если бы алгоритм JS был бы прекрасно доработан, то различия в файлах между режимами JS и Stereo действительно были бы ничтожно малы. Но 1.4 мБайта это уже не ничтожно малые различия.


На 90% треков при кодировании в JS Intensity стереопанорама искажется (хорошо слышимые на слух фазовые искажения).
Заблуждение, достаточно характерное для тех, кто закончил эксперименты с Joint Stereo на версиях LAME младше 3.8. Там он действительно был ужасненький... Однако все течет, все изменяется - его уже довольно давно довели до ума.

Не соглашусь. Алгоритму JS еще очень далеко до идеала. Вот алгоритм работы VBR в Lame'е действительно хорошо доработан, по сравнению с другими mp3 кодеками. И в большинстве случаях, музыку портят именно алгоритмы режима JS (разумеется на битрэйтах выше 160 kbps), а не алгоритмы кодирования VBR/ABR.

ABR IMHO можно получить через VBR поэтому я в нем смысла особенного не вижу . ABR 192, например, будет примерно эквивалентно VBR 160-224 с опцией <-V 4>.

Насчет различий в размере между Joint Stereo и Stereo - не знаю, быть может, это связано с разными музыкальными исходниками, но у Вас разница получилась ~13%, мне же никогда не удавалось получить более 5%... В общем, не знаю, не знаю... Понятно что мое IMHO - это всего лишь обобщение моего личного опыта, не более.

Любопытствующий писал(а):

ABR IMHO можно получить через VBR поэтому я в нем смысла особенного не вижу . ABR 192, например, будет примерно эквивалентно VBR 160-224 с опцией <-V 4>.

Что значит получить "ABR через VBR"? Это не возможно. Вы сравнили не сравнимое. ABR и VBR диаметрально различаются по стилю и алгоритмам работы. ABR при кодировании фонограммы использует свободный резервуар битов, а VBR это заданный пользователем диапазон потоков + выбираемое виртуально-требуемое качество. То есть VBR выбирает качество в соответствии со своими внутренними алгоритмами анализа, которые еще далеки от совершенства. А ABR - доработанный CBR, который используя свободный резервуар битов будет максимально эффективно (качество/размер) сжимать фонограмму. На www.mp3dev.org или http://mitiok.cjb.net/ все про это изложено более детально и разборчиво, нежели это изложу я.

Любопытствующий писал(а):

Насчет различий в размере между Joint Stereo и Stereo - не знаю, быть может, это связано с разными музыкальными исходниками, но у Вас разница получилась ~13%, мне же никогда не удавалось получить более 5%... В общем, не знаю, не знаю... Понятно что мое IMHO - это всего лишь обобщение моего личного опыта, не более.

Как раз фонограмма была одна, а сжатый материал различался между JS и S на 1,5 мбайта. Что свидетельствует о достаточно большом различии в принципах алгоритмов JS и S. И как правило, не в пользу JS (при условии средних и высоких потоков).

ABR при кодировании фонограммы использует свободный резервуар битов, а VBR это заданный пользователем диапазон потоков + выбираемое виртуально-требуемое качество. То есть VBR выбирает качество в соответствии со своими внутренними алгоритмами анализа, которые еще далеки от совершенства.
На www.mp3dev.org или http://mitiok.cjb.net/ все про это изложено более детально и разборчиво, нежели это изложу я.
Мне всегда было интересно - вот почему, когда в рекламе по телевизору рассказывают про то что ACE с красной крышечкой отбеливает лучше чем ACE с синей - то большинство людей с мозгами этому все же не верит; а вот когда разработчики или программеры начинают рассказывать про свои сверхзамечательные "очень умные" решения - то эти же люди им верят? Ведь по сути врать могут (и успешно врут!) и в первом и во втором случае .

Никакими охренеть-не-встать-умными алгоритмами в VBR и не пахнет даже. Это очень хорошо доказало небольшое но в некоторых местах довольно дотошное исследование кодера LAME на iXBT: http://www.ixbt.com/cpu/lame-exam.shtml. Почитайте там раздел "Кодирование с переменным битрейтом", посмотрите на гисторгаммы кодирования в VBR, и обратите особенное внимание на все что касается опытным путем полученных сведений о влиянии параметра <-V ...>. Там все тупо и дубово донельзя. И в то, что "VBR тупой, а ABR умный" - я после этого не верю тоже, потому что опять-таки: чудес на свете не бывает, и то и то одни и те же люди делали.

А разработчикам себя хвалить сам бог велел, и рассказывать всем про то, какие они умные, и какие у них хитрые алгоритмы .

Любопытствующий писал(а):

...а вот когда разработчики или программеры начинают рассказывать про свои сверхзамечательные "очень умные" решения - то эти же люди им верят? Ведь по сути врать могут (и успешно врут!) и в первом и во втором случае .

Прежде чем такое утверждать, скачайте исходники Lame и внимательно изучите внутренние механизмы работы кодека. Я конечно надеюсь что вы человек не плохо знающий языки C++ и asm. Если это не так, очень жаль, но я спорить с Вами не буду. У Вас есть свое мнение, которое на чем то основано. Просто, сравнительно недавно, я перелопатил исходники v3.95sv и основательно проанализировал работу алгоритмов. От чего собственно и утверждаю то что пишу.

Любопытствующий писал(а):

Никакими охренеть-не-встать-умными алгоритмами в VBR и не пахнет даже. Это очень хорошо доказало небольшое но в некоторых местах довольно дотошное исследование кодера LAME на iXBT: http://www.ixbt.com/cpu/lame-exam.shtml. Почитайте там раздел "Кодирование с переменным битрейтом", посмотрите на гисторгаммы кодирования в VBR, и обратите особенное внимание на все что касается опытным путем полученных сведений о влиянии параметра <-V ...>. Там все тупо и дубово донельзя. И в то, что "VBR тупой, а ABR умный" - я после этого не верю тоже, потому что опять-таки: чудес на свете не бывает, и то и то одни и те же люди делали.

Прочитал я Вашу ссылку. И что там доказано? То, что -"Выводы: Они будут краткими. Скорость кодирования MP3 с помощью LAME зависит в рамках одной процессорной архитектуры практически исключительно от частоты работы ядра CPU..." Ну провели они зависимость скорости от CPU, но причем тут работа и качество алгоритмов VBR/ABR и JS/S? Да не о том там речь шла. Если сравнивать режимы VBR и ABR, то при относительно равных состовляющих (например, <-h -m j/s --abr 256> и <-h -m j/s -b 128 -B 320 --vbr-new -V0>) качество первого будет выше. Просто из-за того, что алгоритмы анализа и выбора качества в VBR отличны от ABR.

Любопытствующий писал(а):

А разработчикам себя хвалить сам бог велел, и рассказывать всем про то, какие они умные, и какие у них хитрые алгоритмы .

Да никто там себя не хвалит. Если бы так было, то уже давно людям все было бы известно. Но проект Lame открыт, каждый может взять исходники и досконально изучить их.

У Вас есть свое мнение, которое на чем то основано.
Ну, да - на результатах тестов.
Прочитал я Вашу ссылку. И что там доказано? То, что -"Выводы: Они будут краткими. Скорость кодирования MP3 с помощью LAME зависит в рамках одной процессорной архитектуры практически исключительно от частоты работы ядра CPU..."
При чем тут производительность? В данном случае нас выводы в этой статье совершенно не волнуют, я же писал Вам, на что следует обратить внимание. Там совершенно четко видно, что параметр <-V> при кодировании VBR работает как обычный "регулятор баланса между битрейтами". Никаких хитростей: чем меньше значение этого параметра - тем большее количество фреймов будет закодировано с максимальным (в рамках указанного диапазона) битрейтом. Чем выше <V> - тем большее количество фреймов будет закодировано с меньшим битрейтом. Среднее значение <V> (4) приводит к тому, что большинство фреймов кодируется со средним (в рамках указанного диапазона) битрейтом. Просто, как дубовая дверь.

Любопытствующий писал(а):

При чем тут производительность? В данном случае нас выводы в этой статье совершенно не волнуют, я же писал Вам, на что следует обратить внимание. Там совершенно четко видно, что параметр <-V> при кодировании VBR работает как обычный "регулятор баланса между битрейтами". Никаких хитростей: чем меньше

Так я Вам не про это, я не понимаю почему вы используете VBR? А не ABR?

Любопытствующий писал(а):

"... И в то, что "VBR тупой, а ABR умный" - я после этого не верю тоже, потому что опять-таки: чудес на свете не бывает, и то и то одни и те же люди делали."

Я не понимаю, почему вы не верите? Загляните в исходники, наступит ясность.
Люди то делали одни и те же, но повторяюсь, алгоритм работы ABR гараздо качественней алгоритмов VBR. ABR по сути работы не скован (при прочих равных) так как режим VBR, который скован ключиком "-V (0..9)", в общем и целом, это его самое слабое место. Я вам это пытаюсь сказать, и хочу узнать, так почему же все таки VBR?[/quote]

ABR по сути работы не скован (при прочих равных) так как режим VBR Я вам это пытаюсь сказать, и хочу узнать, так почему же все таки VBR?
Потому что я предпочитаю контролировать процесс самостоятельно . ABR так или иначе все равно скован - как я понимаю, он не может выделить на кусок, который требуется закодировать с лучшим качеством, больше битрейта, чем у него "есть в загашнике". VBR хотя бы позволяет указать этот самый баланс между низшим и высшим, а в ABR все "на автомате". В общем случае, это просто свойственное любому хорошо разбирающемуся в компьютерной технике неверие в то, что компьютер может оказаться "умнее" человека .

Любопытствующий писал(а):

Потому что я предпочитаю контролировать процесс самостоятельно . ABR так или иначе все равно скован - как я понимаю, он не может выделить на кусок, который требуется закодировать с лучшим качеством, больше битрейта, чем у него "есть в загашнике". VBR хотя бы позволяет указать этот самый баланс между низшим и высшим, а в ABR все "на автомате".

Как раз я Вам и пытаюсь сказать, о том, что в ABR механизм распределения битрэйта гараздо эффективнее и вернее, чем в VBR. Я уже писал, что ABR использует свободный резервуар битов и распределяет его в зависимости от сложности сигнала. ABR оперирует только ключиком "-q (0..9)", который подсказывает как распределить битрэйт по шкале качество/эффективность и даже если вы попробуете следующую строку <-h -m s --abr 200 --lowpass 19400>, то убедитесь в том, что кодек будет оперировать всем диапазоном потоков и если кодеку не хватит 256 kb для кодирования фрейма, то он смело выделит под него 320 kb. VBR же, оперирует, кроме ключа "-q", еще и ключиком "-V". Именно ошибки в алгоритмах распределения потоков есть очень слабое место VBR. Конечно, со времен v3.81, все изменилось и надо признать в лучшую сторону, НО ошибки тем не менее существуют и иногда вместо потока в 320 kb на фрейм кодек ошибочно может выделить 224 kb. VBR до сих пор под усиленной дороботкой (VBR is currently under heavy development...).

Любопытствующий писал(а):

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

Он по определению не может оказаться умнее человека. У ПК отсутсвует принципиальная деталь "система ИИ". А вот его скорость обработки данных конечно выше чем у любого человека. Но ПК - робот, а человек - творец.

ОК, я принял к сведению рассказанное Вами, буду экспериментировать и слушать ушами . Еще вопрос, раз уж Вы разбирались с исходниками (если честно - мне просто лениво...). Насчет ключа Q: это правда, что "качество" в его понятии очень тесно связано с выделением большего битрейта под высокие частоты? Т.е. чем меньше Q (чем выше качество) - тем больше битрейта выделяется под высокие? Дело в том, что лично мне вполне качественные записи (грабленые с фирменных CD) закодированные с Q=0 кажутся каким-то "слишком шипящими". Возникает впечатление, что пресловутое "наивысшее качество" достигается за счет выделения под кодирование высоких настолько большой части битрейта... что за счет этого начинает деградировать качество средних . Уже при Q=2 такого ощущения нет, хотя по логике опции "качество" должно получаться "ниже"...

Любопытствующий писал(а):

Еще вопрос, раз уж Вы разбирались с исходниками (если честно - мне просто лениво...). Насчет ключа Q: это правда, что "качество" в его понятии очень тесно связано с выделением большего битрейта под высокие частоты? Т.е. чем меньше Q (чем выше качество) - тем больше битрейта выделяется под высокие?

Связано, но косвенно. Параметр "-q" тесно связан с психоакустикой, scalefactor'ом и енкодером Хаффмана. Его интепретации (-q 0..9), как раз и влияют на качество обработки этими механизмами. При этом, алгоритмы q0 и q1, это просто чистой воды дополнительный анализ фреймов, в реальности он часто не дает должного качества и при этом требует максимум ресурсов ЦП. Вы можете в этом сами убедиться. Очень часто, разница между размерами файлов с параметром q0 и q2 оказывается не более 3%. А в звучании, определить различия оказывается задачей сверх сложности. То, что mp3 кодированые с ключиком -q0 звучат более остро, не является правдой.
Кстати, а вы знаете как можно узнать с помощью Scalefactor'а то, была ли фонограмма сконвертирована из mp3 в wav? Есть способ, на все 99,9% сказать точно, была ли фонограмма сжата по алгоритму mp3. Вы знаете такой способ?

Любопытствующий писал(а):

Дело в том, что лично мне вполне качественные записи (грабленые с фирменных CD) закодированные с Q=0 кажутся каким-то "слишком шипящими". Возникает впечатление, что пресловутое "наивысшее качество" достигается за счет выделения под кодирование высоких настолько большой части битрейта... что за счет этого начинает деградировать качество средних . Уже при Q=2 такого ощущения нет, хотя по логике опции "качество" должно получаться "ниже"...

Различи между q0 и q2, в более тщательном анализе (-q0) фреймов. Вы правильно делаете, что используете в своей строке для lame'а ключик -q2 (-h). Еще я рекомендую Вам пользоваться lowpass фильтром и делать срез на частоте 18000. Так как из-за scalefactor'а реальная постоянно кодируемая частота простирается лишь до ~16kГц. Далее действует жесткая обработка психоакустики.

Кстати, в инструкции к Pioneer 360 написано, что проигрываются MP3 файлы только с постоянным битрейтом.

Dimastty писал(а):

Кстати, в инструкции к Pioneer 360 написано, что проигрываются MP3 файлы только с постоянным битрейтом.

Ну и что? Это проблема фирмы Pioneer и их пользователей. Так как непонимание VBR является не полной поддержкой стандарта формата MPEG1 Layer-3. А CBR уже давно морально и физически устарел.

Скорее всего в Пио просто лоханулись с документацией и на самом деле все он понимает. AFAIK, сейчас просто нет аппаратных декодеров MP3, не понимающих VBR. Разве что Pioneer попросил кого-то сделать ему такую микруху в порядке эксклюзива .