The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Выпуск мультимедиа-пакета FFmpeg 3.1, opennews (ok), 27-Июн-16, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


1. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +4 +/
Сообщение от Mihail Zenkov (ok), 27-Июн-16, 11:44 
> hdcd - декодирует со звукового CD 16-разрядные PCM-данные c hdcd флагами в 20 разрядный PCM-поток;

Декодировщик добавили спустя двадцать лет. Кодировщика, очевидно, не будет. Слава патентам! Еще одна интересная технология была благополучна ими похоронена ...

Ответить | Правка | Наверх | Cообщить модератору

7. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +5 +/
Сообщение от Аноним (-), 27-Июн-16, 12:18 
Зачем тратить время на кодировщик который уже не актуален по всем техническим параметрам? Сейчас более актуален декодировщик, чтобы хотя бы раскодировать то что накодировали.
Ответить | Правка | Наверх | Cообщить модератору

13. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +3 +/
Сообщение от Mihail Zenkov (ok), 27-Июн-16, 14:18 
Так я о том и говорю - нет смысла писать кодировщик, когда cd-audio фактически умер.

> Сейчас более актуален декодировщик, чтобы хотя бы раскодировать то что накодировали.

Даже он не особо актуален, так как сам формат не получил широкого распространения.

Ответить | Правка | Наверх | Cообщить модератору

18. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +5 +/
Сообщение от Stax (ok), 27-Июн-16, 14:59 
Это как сказать.
Иногда внезапно при проигрывании очередного диска можно увидеть, как загорается индикатор "hdcd". Даже когда на самом диске ничего не указано. Это я к тому, что их определенно больше, чем кажется, я совершенно случайно натыкался на hdcd диски, узнавая об этом уже при проигрывании.

А еще это важно, потому что без понимания, что это hdcd он воспроизводится не так хорошо (уровни громкости фрагментов друг относительно друга могут быть неправильные, возможен клиппинг и прочие неприятности). Формат "совместим" с не-HDCD проигрыванием только в том смысле, что звучать будет, но не совсем то, что записывали.

И т.к. все это переносится при любом loseless рипе и кодировании - flac, рипнутый с таких дисков тоже требует hdcd-aware декодера, чтобы звучать корректно. Без этого - звучит с огрехами. Так что либо надо во все проигрыватели поддержку hdcd при проигрывании, либо при рипе расшифровывать hdcd и превращать его в 24-х битный flac уже без этих странных технологий (там, конечно, 20 бит, но так не выйдет). В принципе, сейчас, когда есть декодер, можно пройтись по библиотеке и расшифровать найденные hdcd, перекодируя их в 24-х битные записи без hdcd.

Ответить | Правка | Наверх | Cообщить модератору

22. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +/
Сообщение от Mihail Zenkov (ok), 27-Июн-16, 19:23 
Хотел проверить сколько же реально hdcd у меня в коллекции.
Написал скрипт:
ffmpeg -v error -i "$1" -f wav - | md5sum
ffmpeg -v error -i "$1" -af hdcd -f wav - | md5sum

При декодировании с фильтром hdcd сумма всегда другая. Вероятно фильтр работает некорректно и вносит изменения даже там, где они не нужны :(

Ответить | Правка | Наверх | Cообщить модератору

25. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +2 +/
Сообщение от Stax (ok), 27-Июн-16, 21:03 
Эээ не совсем. Это фильтр, если его активировали, он всегда работает. Выходной формат фильтра заявлен как 24 бита (смысл фильтра же в распаковке 16 bit -> 20 bit). Ну а дальше.. просто ffmpeg так работает. Если HDCD-меток нет, получаем преобразование 16->24 бита без какого-либо преобразования. Но сумма, конечно, не сойдется.

В текущем виде это более пригодно для проигрывателя. Преобразование 16->24 будет всегда (ну и что такого), но если были HDCD-метки, будет преобразование.

Насчет выяснить. Надо понимать, что фильтр пригоден только для 44100 файлов, не надо через него гнать 48khz записи. По ссылке https://trac.ffmpeg.org/ticket/4441#comment:13 предлагают старый конвертер (на 64-х битной системе сделать замены типа, как описано в тикете). Он после конвертации пишет что-то типа "Total = 0  A = 0    B = 0     C= 0". Вот если Total отличен от нуля, было преобразование.

Ответить | Правка | Наверх | Cообщить модератору

27. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +/
Сообщение от Mihail Zenkov (ok), 27-Июн-16, 22:02 
В первом моем варианте оба выходных формата были s16le.

При варианте s24le сумма все равно разная.
ffmpeg  -i "$1" -f s24le - | md5sum
ffmpeg  -i "$1" -af hdcd -f s24le - | md5sum

Ответить | Правка | Наверх | Cообщить модератору

28. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +/
Сообщение от Stax (ok), 27-Июн-16, 22:18 
Ну ээ результат hdcd-декодирования в 16 бит положить невозможно :) Искажения будут.. лучше уж тогда вообще не трогать. Ну то есть даже пытаться не надо такое делать, смысл обработки же именно в представлении 20-битного сигнала.

По поводу суммы - ну хз, может заголовки разные выходят? А cmp -l на оба полученных файлов много различий пишет?

Вообще там есть логирование в фильтре, если в verbose-режиме запускать.
        av_log(ctx, AV_LOG_VERBOSE, "Channel %d: counter A: %d, B: %d, C: %d\n", i, state->code_counterA,
                state->code_counterB, state->code_counterC);

Отличный от нуля счетчик и говорит о сработавшем фильтре. Лучше через это проверять. А то контрольные суммы.. что-то не то.

Ответить | Правка | Наверх | Cообщить модератору

30. "Выпуск мультимедиа-пакета FFmpeg 3.1"  –1 +/
Сообщение от Mihail Zenkov (ok), 28-Июн-16, 00:27 
> Ну ээ результат hdcd-декодирования в 16 бит положить невозможно :)

Очень даже возможно :)

> Искажения будут..

Не будет.

> лучше уж тогда вообще не трогать. Ну то есть даже пытаться
> не надо такое делать, смысл обработки же именно в представлении 20-битного
> сигнала.

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

24 бита (как и 88-192 kHz) нужны для студии дабы не накапливать ошибки округления при многократной обработке и не получать артефакты при возникновении ультразвука во время записи.  

Что же касается hdcd, то если я правильно понял идею hdcd причина его возникновения была в плохом качестве дешевых DAC того времени - вместо полноценных 16 бит они выдавали честных 14-12. Самый простой способ исправить ситуацию - динамическая регулировка громкости (примерно тоже что и динамическая контрастность в мониторах). Тихие фрагменты пишутся существенно громче дабы они были выше 14 бит и ослабляются дополнительным хаком в аналоговой части DAC. На самом деле вполне неплохое решение проблемы. Похожие приемы применяются в психоаккустической модели кодеков с потерями.

На сегодняшний день полноценные 15-16 бит можно сказать норма, даже для весьма дешевых решений. Смысл в подобных ухищрениях пропал. Тем более используя современный алгоритмы (нойз шейпинг) можно получить диапазон более 18 бит на 16 битной записи. При этом будет 100% совместимость с любым плеером/устройством.

> По поводу суммы - ну хз, может заголовки разные выходят?

У -f s24le нет заголовков, это чистый (raw) pcm поток.

> А cmp  -l на оба полученных файлов много различий пишет?

Много - весь файл.

> Вообще там есть логирование в фильтре, если в verbose-режиме запускать.
>         av_log(ctx, AV_LOG_VERBOSE, "Channel %d:
> counter A: %d, B: %d, C: %d\n", i, state->code_counterA,
>            
>     state->code_counterB, state->code_counterC);
> Отличный от нуля счетчик и говорит о сработавшем фильтре. Лучше через это
> проверять. А то контрольные суммы.. что-то не то.

Проверил - пишит 0. Открыл в аудиоредакторе - с фильтром он делает весь файл в два раза тише. Наверное оставляет место для расширения пиков. Но ИМХО это неправильно - сперва следовало бы убедиться, что поток hdcd и только тогда его преобразовывать.

Ответить | Правка | Наверх | Cообщить модератору

32. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +/
Сообщение от Stax (ok), 28-Июн-16, 15:01 
> Не будет.

Будут элементарно. Проще показать на примере, вместо вместо 24 бит - 8, вместо 16 бит - старшие 4.

Исходный 8-битный сигнал: 0011 0100
HDCD-кодирование в 4 бита: 1101 + пометка, что у блока сдвиг на 2 бита. Обычный CD играет "1101".
Декодировали HDCD: 0011 0100. При преобразовании в 16-ти битный формат записали старшие 4 бита: 0110.

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

<далее поскипано>

Но практически на дисках бывает клиппинг и прочие проблемы. Мастеринг CD шел в большей глубине (float/48 обычно), финальное преобразование было в 16/44. Это можно сделать по разному. По простому - нормализовать запись, выполнить компрессию, убедиться, что в итоге нет звуков громче, чем -3 dB, закодировать в 16 бит. Практически.. ну известно, что вышло из loudness war, звуки до 0 db и т.д.
А при нормализации может вылезти другая проблема, понизим громкость, слишком тихие звуки уйдут из диапазона. Как на одном диске записать и тихую, и громкую композицию без потерь, если выравнивать весь диск к одной громкости? Это нам сейчас хорошо, у нас есть replaygain. А тогда вот не было. И придумали HDCD, эдакий поблочный replaygain.,

HDCD предлагает такое решение: для каждого блока данных найдем тот диапазон 16 бит, где максимум данных, запишем его, и ставим на блок тэг, что нужно так-то сдвинуть эти биты влево или вправо перед воспроизведением. Проблема решена - громкие композиции без клиппинга, тихие используют полный динамический диапазон, звук нормализован по всему CD. При этом с практической точки зрения оказалось, что чаще записывается тэг, усиливающий громкость. Тогда для чуть лучшей совместимости с CD решили писать на HDCD-диски +6 dB сигнал, так основной тэг блока стал "без изменений", а при прослушивании CD получили громкость чуть ближе к референсной (но все равно звук хуже, чем если бы мы писали честный CD).

Понятно, что грамотной обработкой и кодированием можно было это обойти. И что 16 бит при правильном мастеринге хватит. Просто практически, с тем, как это стали использовать - стало не хватать. HDCD предложил хак, как то, что намастерили максимально без потерь записать на диск.

> Проверил - пишит 0. Открыл в аудиоредакторе - с фильтром он делает весь файл в два раза тише. Наверное оставляет место для расширения пиков. Но ИМХО это неправильно - сперва следовало бы убедиться, что поток hdcd и только тогда его преобразовывать.

Это он делает обратное (-6 dB) преобразование, как положено по стандарту, потому что HDCD кодируют с +6 dB. Это как раз правильно для HDCD дисков (там на самом деле чуть хитрее, чем просто 6dB, тут хорошая иллюстрация и объяснение: http://www.audiomisc.co.uk/HFN/HDCD/Enigma.html). Аппаратный проигрыватель тоже это делает, если находит на диске тэги HDCD. А вот то, что он это делает безусловно даже там, где HDCD не пахнет, конечно, грустно...

Ответить | Правка | Наверх | Cообщить модератору

34. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +/
Сообщение от Mihail Zenkov (ok), 28-Июн-16, 16:49 
> При преобразовании в 16-ти битный формат записали старшие 4 бита: 0110.

Вы наверное отпечатались: в вашем примере будет 0011.

Вы не учитываете два факта:
1. Просто откинуть младшие биты нельзя - получим ошибку округления и существенные искажения. Те биты которые мы откидываем должны использоваться при формировании дитеринга. Как я уже говорил их частично можно сохранить использую нойз шейпинг и получить эквивалент 18 бит.
2. В каких условиях реальных условиях не хватает 16 бит? Вы вообще слышите последние 2 бита при прослушивании 16 битных записей при комфортной громкости? Вот тестовый файл на котором я проверяю цифровой аудиотракт на отсутствие ошибки округления: http://knk.square7.ch/dithering_test_2bit.flac Вы должны услышать музыку и равномерный/однородный шум на фоне. Если шум не однородный - где-то есть проблема с воспроизведением младших бит.

> По простому - нормализовать запись, выполнить компрессию, убедиться, что в итоге нет звуков громче, чем -3 dB, закодировать в 16 бит. Практически.. ну известно, что вышло из loudness war, звуки до 0 db и т.д.

Почему вы считаете, что нормализация по 0 dB это плохо?

> Как на одном диске записать и тихую, и громкую композицию без потерь, если выравнивать весь диск к одной громкости?

Никак. Это работа звукорежиссера. Если он не выронил - значит такова была его задумка. Если бы он хотел выровнять - то выровнял бы при мастеринге без всякого replaygain.

> Это нам сейчас хорошо, у нас есть replaygain.

Replaygain нужен для устранения клипинга после сжатия. Ранее подобной проблемы не было в принципе, так как поток (PCM) был не сжат.

Ответить | Правка | Наверх | Cообщить модератору

36. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +/
Сообщение от Stax (ok), 28-Июн-16, 18:20 
> В каких условиях реальных условиях не хватает 16 бит

Это просто был пример, почему после hdcd-декодирования в 16 бит без дальнейших преобразований без сильных потерь не положить.

Дело не в том, что 16 бит не хватает, а что после hdcd-декодирования нужно делать компрессию, чтобы положить это снова в 16 бит. Которую в данном примере никто не делает.

> Почему вы считаете, что нормализация по 0 dB это плохо?

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

> Replaygain нужен для устранения клипинга после сжатия

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

Ответить | Правка | Наверх | Cообщить модератору

37. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +/
Сообщение от Mihail Zenkov (ok), 28-Июн-16, 20:22 
> Дело не в том, что 16 бит не хватает, а что после hdcd-декодирования нужно делать компрессию, чтобы положить это снова в 16 бит.

При преобразовании HDCD в 16 бит мы по сути делаем тоже самое, что и звукорежиссер переводящий float в 16 бит - откидываем ту часть, которую все равно никто не слышит.

> Потому, что там в итоге выходит "полочка". Несколько сэмплов максимальной амплитуды подряд. Потому что обрезали..

У нас разное понимание термина нормализация: обычно в аудиоредакторах под этим понимают выставление самого большого пика на заданный уровень dB. То есть полочка в принципе не может образоваться от нормализации 0 dB. Она возможна только если попытаться дальше обрабатывать файл. Поэтому на промежуточных стадиях и используют нормализацию -3dB или -6dB, дабы не влезть в клипинг. Но для финальной стадии это не имеет смысла.

> Ну, вообще говоря клиппинг вообще невозможно устранить или обратить.

Верно для обычного (несжатого или сжатого без потерь) потока.
Проблема в том, что при кодировании с потерями, кодируется не просто сам сигнал, но его математическое описание. Поэтому возможна ситуация когда исходный сигнал был близок к 0dB, а декодируемый сигнал получится немного больше.

https://ru.wikipedia.org/wiki/ReplayGain

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

Да, так его тоже можно использовать - но при этом мы потеряем несколько бит диапазона.

Ответить | Правка | Наверх | Cообщить модератору

31. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +/
Сообщение от Mihail Zenkov (ok), 28-Июн-16, 12:04 
Проверил свою коллекцию (metal/rock/classic/jazz) flac - нашел семь альбомов. Это 2.5% от общего количества.

Было много ложных срабатываний с результатом "counter A: 0, B: 0, C: 1" на отдельных треках.

Как работает пока толком не проверил. Но уже ясно, что файл получается в итоге в два раза тише, даже если в нем нет расширения пиков. Соответственно теряем старший бит, что существенно снижает качество. Так что или алгоритм патчить или проводить нормализацию после этого фильтра.

Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

33. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +/
Сообщение от Stax (ok), 28-Июн-16, 15:09 
> Проверил свою коллекцию (metal/rock/classic/jazz) flac - нашел семь альбомов. Это 2.5%
> от общего количества.

Ну кое-что :)

> Было много ложных срабатываний с результатом "counter A: 0, B: 0, C:
> 1" на отдельных треках.

Ясненько. Вообще реальный проигрыватель по-моему смотрит на тэги только в начале трэка, если их нет с первых блоков, то HDCD не включается.

> Как работает пока толком не проверил. Но уже ясно, что файл получается
> в итоге в два раза тише, даже если в нем нет
> расширения пиков. Соответственно теряем старший бит, что существенно снижает качество.
> Так что или алгоритм патчить или проводить нормализацию после этого фильтра.

См. http://www.opennet.ru/openforum/vsluhforumID3/108380.html#32
Вообще в приличном HDCD-фильтре должна быть опция по отключению -6dB нормализации. Не говоря уж о том, что активироваться там, где тэгов нет он просто не должен. Но там, где HDCD есть, результат корректен. Эти диски и должны быть в два раза тише, чем сигнал, который на них реально записан; просто особенность мастеринга HDCD.

По итогам - фильтр написали явно рабочий, но он недоработан. Не хватает во-первых принудительного отключения -6 dB преобразования, во-вторых логики, которая отключает фильтр, если тэги hdcd не найдены... Без этого в плеере использовать проблематично (впрочем, есть ли удобные плееры, умеющие фильтры ffmpeg вообще? Обычно там только gstreamer-фильтры...) Но найти в коллекции файлы и перегнать их в 24 бит, пропустив через этот фильтр можно уже сейчас.

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

Ответить | Правка | Наверх | Cообщить модератору

35. "Выпуск мультимедиа-пакета FFmpeg 3.1"  +/
Сообщение от Mihail Zenkov (ok), 28-Июн-16, 16:55 
> По итогам - фильтр написали явно рабочий, но он недоработан. Не хватает
> во-первых принудительного отключения -6 dB преобразования, во-вторых логики, которая
> отключает фильтр, если тэги hdcd не найдены... Без этого в плеере
> использовать проблематично (впрочем, есть ли удобные плееры, умеющие фильтры ffmpeg вообще?

mpv? Но он больше для видео. Возможно есть удобный frontend.

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

Я пока не все проверил, но похоже расширение пиков мало кто включал. Наверное из тех же соображений - что бы на обычном cd нормально звучало.

Лично я больше склоняюсь к тому, что по возможности лучше поискать варианты мастеринга без hdcd - как-то оно надежнее :)

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

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру