Например, если перейти от целочисленного представления к плавающей запятой, хотя количество возможных уровней у 24 int и 32 float одинаково и равно 2^23=8388608 (значение 1048536 соответствует 20 int), то дополнительные 8 бит задают масштабирующий коэффициент, поэтому в этом формате возможно уменьшить уровень, но сохранить при этом исходную детализацию, т.е. количество “ступенек” остается неизменным. Последующая конвертация полученного результата в 1бит/11.2896МГц позволяет избежать обратного преобразования в 16 int или 24 int, необходимого для PCM ЦАП. Разумеется, практические ограничения аппаратной реализации могут нивелировать разницу.
Точно, перепутал, не на ту строчку посмотрел.
Почему 2в 23-ей? 2в24 =16777216.
Вообще “плавающая точка” всплыла (сорри за каламбур 
) в цифровом звуке исключительно из-за особенностей компьютерных систем в обработке таких файлов. Менее ресурсоёмкие операции чем с целочисленными форматами. Сегодня, когда рабочие станции проф. уровня имеют топовые многоядерные ЦП, а софт легко оперирует с промежуточными форматами 64-х битной разрядности это не так актуально, но иногда на устаревшем оборудовании организация сессии в 32float вместо 24int может слегка помочь - и latency снизить, и общую скорость работы с “тяжёлыми” плагинами повысить.
Вопросы же конвертации PCM->DSD, это скорее отдельный узкоспециальный вопрос, не относящийся прямо к ЦРГ.
Сорри, не указал, что рассматриваются только положительные отсчеты относительно нуля (отрицательные по сути просто дубль).[quote=“Dmitry, post:200, topic:5040”]
Вообще “плавающая точка” всплыла (сорри за каламбур ) в цифровом звуке исключительно из-за особенностей компьютерных систем в обработке таких файлов. Менее ресурсоёмкие операции чем с целочисленными форматами. Сегодня, когда рабочие станции проф. уровня имеют топовые многоядерные ЦП, а софт легко оперирует с промежуточными форматами 64-х битной разрядности это не так актуально, но иногда на устаревшем оборудовании организация сессии в 32float вместо 24int может слегка помочь - и latency снизить, и общую скорость работы с “тяжёлыми” плагинами повысить.
Вопросы же конвертации PCM->DSD, это скорее отдельный узкоспециальный вопрос, не относящийся прямо к ЦРГ.
[/quote]
Мы говорим несколько о разном: я рассматриваю формат PCM исключительно в качестве промежуточного контейнера, для которого существует удобный аппарат мат. обработки, не более. Внутреннее 64-битное представление в софте, разумеется, снижает накопление погрешностей, но вопрос “поток какой разрядности должен подаваться на вход?” это не отменяет.
На мой взгляд, конвертация PCM-DSD применительно к ЦРГ имеет прямое отношение, т.к. непосредственно 64-битный поток PCM на ЦАП не поступает, предварительное снижение разрядности обязательно. Преобразование в DSD256 позволяет это обойти.
Это не совсем так, точнее совсем не так Когда рассматривается синус - да, при реальном сигнале - нет. Достаочно взглянуть на waveform в любом редакторе.
На вход ЦАПа? Очевидно что предпочтительно (но не обязательно) той, которая поддерживается непосредственно ЦАПом.
Ну, не обязательно, но желательно, причём лучше с дитерингом.
Не понимаю - как?
Для PCM ЦАП, как правило, это 24 бита. Эквивалентная битность потока DSD зависит от частоты сигнала, битрейта и порядка модулятора. Для DSD256 и выше при восьмом порядке ограничивающим фактором будет не пересчет PCM-DSD, а реализация SDM ЦАП.
2^0 2^1 2^2… 2^22 2^23 Итого 24 разряда.
1 лайк
Например, даже в минимальном варианте (DSD64) при пятом порядке модулятора уже получаем эквивалентную разрядность 24 бита:
Да, ноль был забыт
Эквивалент получаем, а громкость как регулируем? Опять через DXD(PCM) или DSD-Wide (тот-же PCM по сути).
Изначально речь шла об изменении цифрового уровня исходного материала в формате PCM, пришли к необходимости избыточно высокой битности в софте, но донести полученный результат до PCM ЦАП без вынужденного снижения разрядности невозможно. В таком случае, что мешает сконвертировать его (результат ЦРГ) в DSD256 и отправить на SDM ЦАП?
Донести до PCM-ЦАПа можно всё что угодно (например в 48-битном представлении снизить громкость 24-х битного исходного сигнала можно без потерь аж на 144дБ). Проблемы возникают как раз в ЦАПе - в процессе DA конверсии. И вот тут уже не помогает ничего, даже расквантование в DSD.
Ограничения, возникающие из-за реализации контретного ЦАП (тепловые шумы и т.п.) - это одна сторона проблемы и тут не поможет ничего, ибо против законов физики. Но исходный сигнал в случае PCM еще до этапа преобразования в аналог должен быть приведен к соответствию внутреннему формату ЦАП (48-битных PCM, например, не наблюдается) - это вторая сторона. О ней и речь, применительно к расквантованию.
Кстати, автор HQplayer еще в 2012 году реализовал регулировку громкости в DSD-домене:
Feb 7 2012 HQPlayer Desktop 2.8.0beta2
Non-decimating (performed at original rate) digital volume control for DSDIFF/DSF file playback to DSD-DACs.
Я бы перевёл эту фразу как “регулировка на оригинальной частоте” то есть в PCM поток всё-таки переводится (ну, если автор не Копперфильд конечно), но обрабатывается на частоте 2.8, 5.6 и тп. Это вполне возможно как в варианте “чистого” PCM, так и в версии DSD-Wide при соответствующих ресурсах компьютера.
Например, из проф.софта только Sonoma и Sadie не выполняют промежуточную конвертацию в “чистый” PCM (DSD-Wide не нарушает правила?), тогда как Pyramix иначе “не обучен”.
link
Posted June 3, 2015 · _
_ tranz said:
How is it possible that HQP can do DSP without going back to PCM, when recording studios cannot even do this? Perhaps I am missing some understanding.
_ _
Yes, Jussi is doing things (DSP in DSD, channel level trims in DSD, distance delays in DSD) that older Pyramix, etc can’t do. That is a huge part of the beauty in HQP! I do convolution in DSD (oops, sorry, SDM, need to be politically correct), explained the reasons earlier and in my exaSound review, and not looking back.
Увы, нарушает - DSD Wide это PCM 8bit 2,8 MHz.
так что никаких чудес - обработка, монтаж и тп в DSD невозможна в принципе. Так или иначе - или через DXD или DSD-Wide - всё равно это PCM.
Собственно, главное в том, что любая обработка требует битность больше единицы. Как это обозначается - DSD-Wide или PCM-Narrow - не суть важно. Зайдем с другой стороны: если при снижении разрядности промежуточного 64-битного результата ЦРГ до 24-бит применить не только обязательный дизеринг, но и нойз-шейпинг - позволит ли это сохранить эквивалентную битность?
DSD-like coding inside PCM digital audio
И n.s. и dith. помогают только замаскировать шум квантования, не более. “Битность” они никак не повысят и не сохранят.
А что такое “эквивалентная битность”?
В литературе 20-летней давности результат одно- и многобитной дельта-сигма модуляции обозначается одинаково: noise-shaped PCM или NS-PCM. Позднее первый переименовали в DSD, а второй - в DSD-Wide, что внесло путаницу.
K(equivalent) = (Signal-to-Quantization-Noise Ratio - 1.76) / 6.02
SQNR = 3.01 + 6.02M (dB/doubling fs)
M - noise-shaping order
Какую путаницу? Всё достаточно понятно и давно используется на практике.
И для чего это нужно (в свете темы топика)?
Результат однобитной модуляции просто частный случай многобитной, принципиальной разницы нет.
Как иначе сопоставить K-bit PCM и 1-bit NS-PCM?
Ну в общем - да, с этим соглашусь.