FFMPEG plugin needs settings controls for proper DSD decoding

[dikonov]

While the current versions of deadbeef are able to play DSD files via ffmpeg, it cannot do it properly.

1) FFMPEG chooses 16bit output mode for DSD by default and there is no place to tell it to switch to 24-32 bit.
2) DSD gets decoded with very high bitrate, but plays at 192khz, which results in 2x sllooooowwww plaaaayyyyiiiing. There is no way to configure ffmpeg's bitrate for dsd decoding output.

Please, add controls in the ffmpeg plugin setup gui to set the preferred

• bitrate,
• sample format and
• channels (stereo/4.0/5.1...)

for the ffmpeg backend. It is mandatory for DSD->pcm conversion and might be useful for other formats. Foobar also has DSD interpolation method, but I am unsure if ffmpeg supports alternative ways of decoding dsd.

Steps to reproduce the problem

Add a dsd/dsf file to the playlist and try to listen. You will be unable to hear it play normally (list of supported output bitrates depends on your DAC, alsa driver, connection).

Information about the software:

Deadbeef version: 1.8.4 FFMPEG: 4.4 OS: linux-5.10.29

[Oleksiy-Yakovenko]

1. I'm not sure whether it's possible to configure FFMPEG to decode DSD into 32 bit PCM, but it's ok to have this open, and perhaps eventually someone will look into it. In some way, this problem is similar to #1254, where ffmpeg is decoding TAK into 32 bit instead of 24.
2. From what you are writing, it appears that you have the resampler disabled or misconfigured. There's no way to fix your problem without resampler. Your DSD file is decoded at 384KHz (but can be a different rate), and it needs to play at the 192KHz output rate. This is what resampler is solving.

[dikonov]

1. I'm not sure whether it's possible to configure FFMPEG to decode DSD into 32 bit PCM. ... In some way, this problem is similar to #1254, where ffmpeg is decoding TAK into 32 bit instead of 24.

Ffmpeg has command line options for that, but we cannot set them from the deadbeef GUI, when deadbeef plugin calls ffmpeg as a backend. Here is a quote from a similar question

_By default, the FFmpeg FLAC encoder takes the bit depth of the original. The bit depth can be changed with the sample_fmt option, e.g.
ffmpeg -i … -c:a flac -sample_fmt s16 output.flac_

Our problem is that DSD's original bit depth is 1 bit, but it is not a valid choice in PCM. Ffmpeg chooses 16bit as a fallback, which is not acceptable for HD audio! 24bit is OK, but 24bit audio streams are usually played using S32_LE sample format in alsa.

2. From what you are writing, it appears that you have the resampler disabled or misconfigured. There's no way to fix your problem without resampler. Your DSD file is decoded at 384KHz (but can be a different rate), and it needs to play at the 192KHz output rate. This is what resampler is solving.

Wrong. I intentionally disable resampler, because I want to hear all regular PCM recordings as-is. Any resampler degrades the sound. My DAC can handle all formats natively. However, my stupid HDMI connection / linux video driver / sets a cap at 192 khz, and does not allow direct DSD streaming. So, DSD file should be decoded at 176, 88 (or 192, 96) khz by ffmpeg. FFmpeg should not produce a useless 384khz stream, which cannot be played and has to be downsampled later. An additional resampler in the chain would turn our hi-end audiophile records into usual CD-level crap, pointlessly consume CPU cycles and burn electricity.

man ffmpeg lists the following options, that should help to produce a compatible PCM stream directly

-ar freq
Set the audio sampling frequency (default = 44100 Hz).
-ab bitrate
Set the audio bitrate in kbit/s (default = 64).
-ac channels
Set the number of audio channels (default = 1).

All software SACD and DSD converters, including foobar components, have a GUI to set the target PCM parameters. Deadbeef should follow suit.

[Oleksiy-Yakovenko]

Ffmpeg has command line options for that By default, the FFmpeg FLAC encoder takes the bit depth of the original. The bit depth can be changed with the sample_fmt option, e.g.

deadbeef is not using the ffmpeg "app", it's using the libavformat/libavcodec. They don't have the command line interface, and the command line options you're posting are not really helpful. They're for a different application.

I intentionally disable resampler, because I want to hear all regular PCM recordings as-is. Any resampler degrades the sound. My DAC can handle all formats natively. However, my stupid HDMI connection / linux video driver / sets a cap at 192 khz

Well, you have 2 options to solve this dillema :)

1. Keep listening to the music the way you do now, at wrong speed
2. Find another DAC that can play back the 384KHz natively without resampling

If you can't use these options -- you can use resampling, but you don't like that. What you described here also sounds like resampling to me:

So, DSD file should be decoded at 176, 88 (or 192, 96) khz by ffmpeg

[dikonov]

deadbeef is not using the ffmpeg "app", it's using the libavformat/libavcodec. They don't have the command line interface, and the command line options you're posting are not really helpful. They're for a different application.

There should be equivalent API calls. I am not an expert but, it seems very plausible that the ffmpeg app is a thin wrapper of the same libs and all its options are translated to library API functions. So, I believe that it is possible to instruct the backend to produce PCM stream with desired parameters, just like all other DSD capable palyers do.

I intentionally disable resampler, because [...] resampler degrades the sound.

you can use resampling, but you don't like that. What you described here also sounds like resampling to me:

You are right. DSD conversion has a lot in common with resampling and is unavoidable in most systems. But my point is that I do not like DOUBLE and triple resampling. 1) DSD-> 384PCM 2) 384 PCM -> 192|96 PCM. Evil MITM stuff like pulseaudio can add even third resamling stage 3) -> 44|48 PCM.

DSD file should be decoded at 176, 88 (or 192, 96) khz directly by libavformat/libavcodec controlled by API calls.

• The issue of the wrong 16bit depth of the decoded PCM stream has already been raised in #2012 and #2144. It all boils down to the user's ability to control, what the backend libs do at the DSD decoding stage.

[Oleksiy-Yakovenko]

1) DSD-> 384PCM 2) 384 PCM -> 192|96 PCM. Evil MITM stuff like pulseaudio can add even third resamling stage 3) -> 44|48 PCM.

DSD -> 384PCM

This is not resampling. It's supposed to be lossless decoding.

384 PCM -> 192|96 PCM

This is resampling. It's necessary, so that the 384KHz stream could play at the right speed on your output.

DSD file should be decoded at 176, 88 (or 192, 96) khz directly by libavformat/libavcodec controlled by API calls.

This would mean lossy decoding of a file that's supposed to be decoded as lossless. Would be weird, don't you think?

The issue of the wrong 16bit depth of the decoded PCM stream has already been raised in #2012 and #2144. It all boils down to the user's ability to control, what the backend libs do at the DSD decoding stage.

thanks! I knew it's a duplicate, but smh failed to find the previous reports. For some reason, no matter what search terms I write, the issue #2012 doesn't show up in the search results. Seems like github search is broken.

Closing as duplicate of #2012

[dikonov]

Извините, но я не уверен, что мы друг друга понимаем на английском. Этот баг не является настоящим дублем 2012!!!! Он всего лишь включает в себя #2012, как часть описываемого недостатка. #2593 -более общий запрос, решение которого одновременно закроет #2012.

Общая проблема состоит в невозможности для пользователя управлять декодированием DSD через передачу параметров ffmpeg-модулю (на самом деле libavcodec и ко.).

В #2012 речь идет о неверном умолчательном выборе типа семпла (bit depth) и только. Решение №2012 не снимает проблему #2593.

[dikonov]

Также добавлю, что включение конвертера частоты дискретизации в DSP разделе настройки deadbeef приведет к тому, что он будет активен не только для DSD, но и для PCM форматов. Для PCM этот модуль будет делать ненужную работу, ухудшающую звучание, что совершенно неприемлемо. Для DSD он будет делать второе и излишнее преобразование. Насколько мне известно, преобразование DSD в PCM принципиально не может быть беспотерьным ни при каких параметрах. Также как и преобразование частоты PCM, оно включает в себя интерполяцию и обязательное усиление или ослабление сигнала, чтобы не вылететь за пределы диапазона PCM или не терять этот диапазон впустую.

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

[Oleksiy-Yakovenko]

Я считаю вопрос про "декодирование dsd в другом samplarate" исчерпанным, т.к. я не вижу в исходниках ffmpeg никаких намеков на подобную функциональность.

да, в командной строке можно указать настройки resampling, но resampler в deadbeef и так есть, и я не вижу смысла тратить время чтобы добавить поддержку resampler'а встроенного в ffmpeg. он просто лишний.

если есть какие-то сомнения -- вот исходники декодера dsd, из них ясно видно, что никакого преобразования в различные samplerate там не предусмотрено

https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/dsd.c

но если я куда-то не туда смотрю -- обязательно сообщите.

Также добавлю, что включение конвертера частоты дискретизации в DSP разделе настройки deadbeef приведет к тому, что он будет активен не только для DSD, но и для PCM форматов

нет, не приведет. если преобразовывать частоту не нужно -- то она и не будет производиться.

[dikonov]

Вот для информации сравнение двух разных конвертеров DSD (включая модуль foobar2000), где видно, что разные конвертеры дают разный PCM из одинакового DSD.

https://archimago.blogspot.com/2015/04/analysis-dsd-to-pcm-2015-foobar-sacd.html

Вот еще цитата:

__The problem is the way in which data are contained by DSD and LPCM. The differences are in the way that information is mathematically distributed between the amplitude domain and the time domain. The effect is that there is no direct correspondence of one information pattern and the other. Whenever analogue data are subjected to the entropic process of digitising the data some data are inherently lost as a function of the entropy (e.g. the data in the ‘gaps’ between samples are not encoded in the digital signal for LPCM). This digitisation loss is different from the lossless storage of the data: As both formats are lossless, there’s no subsequent mathematical loss of data by compression (or other processing) of the data. However the data that are lost by the entropic process of digitising the data are different for LPCM and DSD. Since the lost data are different, then when convertin from one to the other the information lost in one format cannot be recreated in the new format, but the data that cannot be stored in the new format are also lost - hence the final result is less than the original before the conversion.

Each may be lossless in their own right, but as they can hold slightly different interpretations of the analogue data, the conversion can still be lossy…_

Итого, лучше иметь цепочку преобразований с потерями из одного шага (1 раз терять), чем из двух (два раза терять). Если же libavcodec действительно абсолютно неуправляем и не может делать 32bit 192гц вместо 16bit 384Гц, то это уже дефект libavcodec.

[Oleksiy-Yakovenko]

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

Наверняка, все так и должно быть, но вот в исходниках декодера dsd в ffmpeg я не вижу ничего подобного. там прямое преобразование из dsd в float32 pcm, и что там происходит с ним дальше -- уже дело дальнейших модулей. можно оставить как есть, а можно резать.

потери возможны разве что при этом самом преобразовании из int в float32, но что-то мне подсказывает, что даже так потерь не будет.

[Oleksiy-Yakovenko]

Вот для информации сравнение двух разных конвертеров DSD (включая модуль foobar2000), где видно, что разные конвертеры дают разный PCM из одинакового DSD.

там прямым текстом и написано, что в одном из конвертеров встроенные улучшайзеры -- т.е. это не имеет к dsd непосредственного отношения. те же фильтры можно и на pcm напускать, с аналогичным результатом.

[dikonov]

Без улучшайзеров получается мощный шум в районе 30 кгц. Его видно в анализаторе спектра. Крутые пищалки это играют и пугают котов, и даже могут выйти из строя при большой громкости. Меня спец по колонкам когда-то предупреждал о неслышимом УЗ свисте.

[greenvorbisfan]

Меня спец по колонкам когда-то предупреждал о неслышимом УЗ свисте.

Ну так расскажите этому спецу о δσ-модуляции — шум квантования специально перемещается в неслышимый диапазон, это основное отличие DSD от PCM. Любой DSD-DAC этот шум проигнорирует, а для DoP не грех и эквалайзер человечий заиметь, раз уж занимаетесь.

[c3kkos]

Please use english!

is there a way to bypass ffmpeg and send DSD data directly to a capable dac?

[Oleksiy-Yakovenko]

@c3kkos there is a way of course, but deadbeef doesn't have such feature. And this is not what this issue is about.