Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[ThierryNK]

Hi

For several years, I have been asking the possibility to chose the sample rate of DSD to PCM conversion in DNLA, 44.1, 88.2 or 176.4.

Currently, JRiver proposes only 2 options:

- DoPE, OK for DSD compatible network player
- PCM conversion at 176.4 when choosing the output format to PCM 24 bits and same as source sample rate.

So 176.4 is hardcoded in JRiver for this conversion.

Please, please  it will not be a great work to add a line in the Audio DLNA menu and create a variable DLNA.DSD.2.PCM.Rate that is read in this menu and passed to the relevant routine in place of the hardcoded 176.4

I just bought MC22, even if do not need it and nothing special is announced about DLNA (I only use JRiver with Audio DLNA), just hoping that this DSD rate choice would be one day implemented as it is in Minimserver or other DNLA servers.

Kind regards

[AndrewFG]

^
See screenshot..

[ThierryNK]

?

What is your point? DSD is converted to 24/176 in you screenshot configuration. It is what I explained in my previous post.

Kind regards

[AndrewFG]

If you select another sample rate than "Same as Source" it will transcode to whatever you select. My screenshot shows 44100Hz selected (with a check mark next to it).

[ThierryNK]

I do not want to resample ALL my tracks, including PCM tracks, to a fixed sample rate, which is what you get in your screenshot.

My post is only about the sample rate chosen internally by JRiver for DSD 2 PCM conversion in DNLA mode.

[AndrewFG]

Actually I have myself been petitioning JRiver for years to include more flexibility in its UPnP media conversion options. The MC server should use the UPnP GetProtocolInfo command to query the renderer's playing capabilities, and then select which ever output format is the highest common denominator of the source media format and the renderer's playing capabilities. That is the exact reason why the UPnP specification included this GetProtocolInfo command in the first place. However JRiver does not see any need to do this. So don't hold your breath..

In your case, the work around is to set up two servers in MC. Use one for playing DOPE tracks, where you set a fixed down conversion sample rate. And use the other for playing other track formats, where you set Same as Source (or No Conversion).

( PS either way your initial complaint about "hard coded sample rate" is not true.. )

[ThierryNK]

If not hardcoded, how do you name a conversion rate that is systematically  176.4KHz for DSD tracks which have a 2822400 Hz sampling rate when you chose "same as source" as transcoding rate?

I could nearly bet that there is something coded in JRiver as:

if track_type=dsd
sample_rate=176.4
end if

as there is no "natural" or logical way to chose this 176.4 sample rate.

Minimserver offers the possibility to chose this sample rate, and I use Minimserver when I need 44.1 or 88.2 conversion.

Kind regards

[AndrewFG]

If not hardcoded, how do you name a conversion rate that is systematically  176.4KHz for DSD tracks which have a 2822400 Hz sampling rate when you chose "same as source" as transcoding rate?

Then you don't select "Same as Source". You select another value.

EDIT:  Are you perhaps confused why a 2'822'400 Hz file DSD "Same as Source" results in a 176'400 Hz PCM output? The reason is that 1-Bit @ 2'822'400 Hz is the same as 16-Bit @ 176'400 Hz. That is "Same as Source". So if want to output samples at a different rate, then select another output rate please.

[ThierryNK]

Then you don't select "Same as Source". You select another value.

EDIT:  Are you perhaps confused why a 2'822'400 Hz file DSD "Same as Source" results in a 176'400 Hz PCM output? The reason is that 1-Bit @ 2'822'400 Hz is the same as 16-Bit @ 176'400 Hz. That is "Same as Source". So if want to output samples at a different rate, then select another output rate please.

As already written above, selecting another value than "same as source" leads to converting ALL PCM tracks to this sample rate, and not only DSD tracks.

Setting up another dnla server only for DSD would be an archaic prehistorical approach.

DSD being the same as 16/176 is a non sense. DSD in an encoding fomat, not another PCM container as flac or Aif.

[mojave]

DSD being the same as 16/176 is a non sense. DSD in an encoding fomat, not another PCM container as flac or Aif.

Grimm Audio, who makes DSD DAC's, starts off their DSD faq with this comment, "DSD is another word for 1-bit PCM sampled at 2,822 mHz."

This is basically what AndrewFG is saying. 16-bit 176kHz PCM is the same as 1-bit 2,822 mHz DSD. You multiply the bit-depth times the sampling frequency.

Nuforce explains, "The differences between the two processes are relatively minimal and somewhat akin to comparing 10 dimes with a 1-dollar bill and trying to determine which is better. In one case where you have a coin purse, 10 dimes is better. In the case where you have a wallet though, the dollar bill is preferable. In either case, you still have the exact same amount of currency. Likewise in the case of PCM vs. DSD, you still have the same amount of data being processed. It's simply a matter of how the decoding hardware (DAC) was constructed as to which format is preferable."

You can certainly disagree and call it nonsense, but AndrewFG's statement is consistent with some DSD DAC manufacturers.

[ThierryNK]

Grimm Audio, who makes DSD DAC's, starts off their DSD faq with this comment, "DSD is another word for 1-bit PCM sampled at 2,822 mHz."

This is basically what AndrewFG is saying. 16-bit 176kHz PCM is the same as 1-bit 2,822 mHz DSD. You multiply the bit-depth times the sampling frequency.

Nuforce explains, "The differences between the two processes are relatively minimal and somewhat akin to comparing 10 dimes with a 1-dollar bill and trying to determine which is better. In one case where you have a coin purse, 10 dimes is better. In the case where you have a wallet though, the dollar bill is preferable. In either case, you still have the exact same amount of currency. Likewise in the case of PCM vs. DSD, you still have the same amount of data being processed. It's simply a matter of how the decoding hardware (DAC) was constructed as to which format is preferable."

You can certainly disagree and call it nonsense, but AndrewFG's statement is consistent with some DSD DAC manufacturers.

Hi Mojave

If you look at the global number of bits in a 16/176 and a DSD, OK, they contains the same number.

Would you say that a pdf file with the same number of bits is equivalent to 16/176 or DSD?

Algorithms to convert a DSD file to PCM are fully different from those to change the sampling rate of a PCM file and there is nothing "natural" or "logical" to impose 176 for conversions.

By the way, from your Nuforce link:

44.1kHz CD standard. Hence, the PCM equivalent of a 2.8Mhz DSD file would be manifest as an 88.2kHz file at 20-bit resolution.

And error in the Nuforce link, not all DAC use Sigma Delta. MSB or Totaldac for example do not. They are NOS DAC (Non Over Sampling) with no Delta Sigma involved.

The point of AndrewFG was that 176 was the "same as source" rate for DSD to PCM conversion. So what computation JRiver makes JRiver to find thks 176, as it is not in the headers of the file ?

I maintain that 176 is just a harcoded choice by JRiver. If JRiver explains how they get this 176 and 176 is not hardcoded, I will send a case of Champagne to AndrewFG.

Kind regards

[Matt]

By default, a 1x DSD file is converted to PCM at 352.8 kHz.

[ThierryNK]

By default, a 1x DSD file is converted to PCM at 352.8 kHz.

In DLNA, which is the subject of this thread?

I always saw 176

[dtc]

By default, a 1x DSD file is converted to PCM at 352.8 kHz.

Why? As others have pointed out, it seems like 1xDSD should, by default, convert to 176KHz and 2xDSD should convert to 352KHz, otherwise you are, in essence, upsampling. The current default produces twice as many data points as you started with.

It would be nice if you could put the final sample rate in the conversion column. For example, if you want to convert 1XDSD to, e.g., 88KHz, you should be able to put 88 KHz in directly. I believe that option is no longer available. You need to put 88 KHz as the conversion for 352 KHz or 704 KHz.This refers to Output Format conversions, not necessarily DLNA.

[Hendrik]

Why? As others have pointed out, it seems like 1xDSD should, by default, convert to 176KHz and 2xDSD should convert to 352KHz, otherwise you are, in essence, upsampling. The current default produces twice as many data points as you started with.

The DSD->PCM process is not as simple as taking 16 DSD bits and making it 16 PCM bits at 1/16 of the sample rate, because each sample is from a different point in time.
Perfect reproduction would even keep the same sample rate as the DSD source so all temporal details can be preserved, but thats just ludicrously high so we use 1/8th. There is no upsampling taking place.

1/8th also seems to be the standard for high-quality DSD to PCM conversions in software players, as far as I can tell.

@DLNA:
I'm not sure if DLNA allows such high rates, so maybe thats why its stepping down? Unfortunately DLNA PCM audio is not my expertise.

[blgentry]

Why? As others have pointed out, it seems like 1xDSD should, by default, convert to 176KHz and 2xDSD should convert to 352KHz, otherwise you are, in essence, upsampling. The current default produces twice as many data points as you started with.

What Hendrick said covers it, but I wanted to add:

DSD encoding is fundamentally different than PCM encoding. You can not losslessly convert between the two encoding types.  Neither is a lossy format.  But they are so fundamentally different that you can't go DSD > PCM > DSD and get the same bits back.  The encoding is that different.

So you can't really make a meaningful comparison simply by comparing the number of bits in each format when doing a conversion.  What I've read suggests that 1xDSD is closer to 20 bit 96kHz than anything else.  But that's just what I've read.  The various multiples of 44.1 kHz are said to be chosen most of the time to make conversion easier with DACs that are based on multiples of 44.1kHz.

Brian.

[dtc]

The DSD->PCM process is not as simple as taking 16 DSD bits and making it 16 PCM bits at 1/16 of the sample rate, because each sample is from a different point in time.
Perfect reproduction would even keep the same sample rate as the DSD source so all temporal details can be preserved, but thats just ludicrously high so we use 1/8th. There is no upsampling taking place.

1/8th also seems to be the standard for high-quality DSD to PCM conversions in software players, as far as I can tell.

@DLNA:
I'm not sure if DLNA allows such high rates, so maybe thats why its stepping down? Unfortunately DLNA PCM audio is not my expertise.

Hendrik - Thanks for the explanation. I understand that DSD to PCM is not just a point by point conversion. The question I have is what is the appropriate PCM sample rate to convert to. I have not done a thorough look at other converters, but converting 1X to 352Khz and 2X to 704 KHz seems very high.  The other program I use to do DSD to PCM conversions - AudioGate 4.0 - does not even support those high frequencies, at least as output. Likewise, Tascam's Hi-Res Editor only goes up to 352 KHz, again, at least for output. I also looked at Weiss Saracon and the maximum sample rate it supports for 2X DSD is 352 Khz

Unfortunately, few DACs have 704 KHz capability, so any time you  convert 2XDSD to PCM, you then have to do a conversion to a lower sample rate which, I presume,  uses the PCM converter. Wouldn't it be better to convert directly to the desired sample rate?

I will note that prior to 704 KHz support in MC, I am pretty sure than 1X conversion was to 176 KHz and 2x was to 352 KHz. I am pretty sure that changed when 704KHz was added.

Any comment on the other issue - that you cannot simply put the desired final sample sample in to do a conversion, as you could with prior versions. If converting a 2XDSD to 176 KHz, you now have to add a conversion from DSD to 704 KHz and then a conversion of 704 KHz to 176 KHz, using the PCM converter I presume. I am not sure, but I always thought that prior to the 704 KHz addition, the conversion was done directly from DSD to PCM without a PCM conversion. Was that not the case?


Just to be clear, my comment on upsampling was not that an actual upsampling is done, but that there were twice as many bits in the output as in the input.


EDIT: I just checked DSDMaster, a popular program to convert DSD to PCM on Apple systems. It's maximum PCM sample rate is 352.8/384. KHz.

[dtc]

What Hendrick said covers it, but I wanted to add:

What I've read suggests that 1xDSD is closer to 20 bit 96kHz than anything else.  But that's just what I've read. 

Brian.

That is part of the reason that converting 1x DSD to 352 KHz seems extreme.

[dtc]

I just wanted to clarify the math here a little bit, just for reference.  I am most of you know this.

176.4 KHz x 16 =  2.822 MHz  (1XDSD)

352.8KHz x 16 = 5.644 MHz    (2XDSD)

That is why DoP uses 176K for 1x DSD and 352 KHz for 2x DSD. DoP only uses 16 bits of the 24 bits for the audio signal.

Normally 176.2 KHz and 352.8Khz samples are done at 24 bit.

176.4KHz x 24 = 4.23 KHz

352.8KHz x 24 = 8.46 Khz

So, purely from a number of bits perspective, 24/176 is more than adequate for a 1XDSD conversion and 24/352 is more than adequate for a 2XDSD conversion

[Hendrik]

I will note that prior to 704 KHz support in MC, I am pretty sure than 1X conversion was to 176 KHz and 2x was to 352 KHz. I am pretty sure that changed when 704KHz was added.

Any comment on the other issue - that you cannot simply put the desired final sample sample in to do a conversion, as you could with prior versions. If converting a 2XDSD to 176 KHz, you now have to add a conversion from DSD to 704 KHz and then a conversion of 704 KHz to 176 KHz, using the PCM converter I presume. I am not sure, but I always thought that prior to the 704 KHz addition, the conversion was done directly from DSD to PCM without a PCM conversion. Was that not the case

DSD to PCM conversion in MC has always converted into a 1/8th sample rate PCM signal, any further processing after that happens in PCM.
This is the exact behavior of the dsd2pcm library that the majority of software player that supports DSD conversion are based on. It does not give you a choice what to convert to.

Many software players have internal limits for the sample rate so its quite possibly they just lower it after the fact so their existing audio chain works, its not really an argument for the DSD to PCM behavior either way.
The majority of audio devices would also not allow such high PCM sample rates to be output (if there even are any), but we didn't see a reason to artificially downsample in the DSD decoder, instead you can do that yourself through DSP Studio.

I just wanted to clarify the math here a little bit, just for reference.  I am most of you know this.

176.4 KHz x 16 =  2.822 MHz  (1XDSD)

352.8KHz x 16 = 5.644 MHz    (2XDSD)

That is why DoP uses 176K for 1x DSD and 352 KHz for 2x DSD. DoP only uses 16 bits of the 24 bits for the audio signal.

DoP does not convert to PCM though, it only uses PCM as storage for the original DSD signal, so the 1/16th math makes perfect sense there. Its still 1-bit DSD, just 16 bits packed into one PCM "frame" each, which a DSD DAC then "unpacks" into 2.8MHz/1-bit DSD signals.

Note that these multiplications make no sense when you talk about PCM, as I've outliend in an earlier post. In DSD, every single bit is from a different point in time, in PCM all 16 or 24 bits are from the same point in time. The sample rate is an expression of the temporal resolution, DSD has higher temporal resolution (ie. you record 2.8 million times per second - 2.8MHz) but only 1-bit bitdepth, so it gets very noisy (hence the need for strong filters when converting to PCM to get rid of ultrasonic noise), while PCM has a lower temporal resolution but higher bitdepth.

[dtc]

Thanks for the clarification Hendrik.  In older versions, the PCM conversion of 2XDSD must have been hidden before 705KHz was available to the user. For example, in MC 17 playing a 2xDSD converted to 176 shows as a conversion from 352 to 176 in Audio Path. That is the source of my confusion.

As a separate issue, I still think it would be useful if you could specify the desired sample output rate directly when converting DSD to  PCM file. As I see it now, the conversion is automatically done at the 1/8 rate then you have to specify any other down conversion on the 1/8 sample rate line. For example, if you want to go from 2xDSD to 176, then you need to specify >768 converting to something (anything will do) and then 705 converting to 176. Even putting in 44 as the output rate for  >768  and then 705 to 176 will show in Audio Path as 705 being converted to 176. It really looks like anything you put into the output format for >768 does the same thing - converts to 1/8th of the original sample rate. This is often confusing to users trying it the first time. Putting 176 as the output conversion for > 768 causes a conversion error and a 0 bit file. The same thing happens on playback, but then you get the a "Playback Could Not Be Started at 705" error in Audio Path.  I am not sure, but the same thing may be happening with DLNA conversions.  I do know that in MC 17, I can put 176 or 88 on the >384 line and the conversion worked as expected. Someplace along the way that got changed, I think when 705/768 got added, but I am not sure.

Sorry to be such a pain about this, but new users often run into this conversion failure issue when trying to convert form DSD to PCM, either on playback or for file conversion.

Thanks for your insight and your help.

[Hendrik]

As a separate issue, I still think it would be useful if you could specify the desired sample output rate directly when converting DSD to  PCM file. As I see it now, the conversion is automatically done at the 1/8 rate then you have to specify any other down conversion on the 1/8 sample rate line. For example, if you want to go from 2xDSD to 176, then you need to specify >768 converting to something (anything will do) and then 705 converting to 176. Even putting in 44 as the output rate for  >768  and then 705 to 176 will show in Audio Path as 705 being converted to 176. It really looks like anything you put into the output format for >768 does the same thing - converts to 1/8th of the original sample rate. This is often confusing to users trying it the first time. Putting 176 as the output conversion for > 768 causes a conversion error and a 0 bit file. The same thing happens on playback, but then you get the a "Playback Could Not Be Started at 705" error in Audio Path.  

Thats because DSP is entirely in PCM, it doesn't know nor care what the original DSD sample rate was. DSD is for those purposes just another audio format that decodes to PCM, and the final PCM rate is what the DSP studio sees, cares about and acts on.
So 2xDSD is decoded to 705kHz, and thats what the DSP Studio sees, and which setting in the DSP studio is active. If you had 4xDSD, then the >736k option would apply.

Thats also why there are no special conversion options for DSD in the DSP Studio, since the DSP Studio just doesn't know or care what the original format was - and nor should it. It gets decoded PCM from a large variety of input plugins, DSD just being one of them.
The entire audio engine is quite modular, which allows using it in many different situations as-is without special logic everywhere, but one factor of something re-usable is that it just gets generic input - raw decoded PCM of a specified sample rate and bitdepth.

[dtc]

Thats because DSP is entirely in PCM, it doesn't know nor care what the original DSD sample rate was. DSD is for those purposes just another audio format that decodes to PCM, and the final PCM rate is what the DSP studio sees, cares about and acts on.
So 2xDSD is decoded to 705kHz, and thats what the DSP Studio sees, and which setting in the DSP studio is active. If you had 4xDSD, then the >736k option would apply.

Thats also why there are no special conversion options for DSD in the DSP Studio, since the DSP Studio just doesn't know or care what the original format was - and nor should it. It gets decoded PCM from a large variety of input plugins, DSD just being one of them.
The entire audio engine is quite modular, which allows using it in many different situations as-is without special logic everywhere, but one factor of something re-usable is that it just gets generic input - raw decoded PCM of a specified sample rate and bitdepth.

Thanks for the explanation. It really does help to understand what is going on.

As I said, at some point  the DSP Studio user interfaced changed, and, I think for the worse. How is a user to know that converting from 2XDSD requires an additional entry on the 705 line? And if you have both 1X and 2X DSD files, you need entries on both the 352 and the 705 line. That is just not very intuitive. It seems like the internal conversion engine is driving the user interface, which is causing confusion for users.

DSD to PCM conversion is already a special case in DSP studio. Why can't that special case pass the 352 or 705 output into the PCM conversion routine using the sample rate on the >768 line.  As I said,  MC 17 used to use that value.  As it is now, the actual value in that line is ignored and if there is no entry in the 352 or 705 line, the routine creates an error.

I have had to explain this two step conversion process to several new users and they just never understood it. That is why I pushing this discussion. I hope you understand.

[Hendrik]

As I said, at some point  the DSP Studio user interfaced changed, and, I think for the worse. How is a user to know that converting from 2XDSD requires an additional entry on the 705 line?

People wanted to configure those separately for reasons I don't understand, as I was not involved in adding those new lines, but more then one user asked for it.
There is practically no PCM content at such sample rates, although its not impossible, just impractical, so folding all DSD into the >736 line would defeat the purpose of having added them in the first place.

If I'm getting an error that 705k sample rate cannot be played, wouldn't going to that list and setting 705k to something lower be a logical first step to take? Its hard to think like some random user though.

Maybe for maximum out-of-the box playback compatibility we should default those to something reasonably lower, widely supported, 176/192 respectively?
We have one option that tries to automatically adjust output settings if playback fails, but I don't remember if its on by default and if it catches all problems. Definitely wouldn't help with conversion troubles.

Personally I don't think DSD is something worth worrying all this much about, rather get rid of it then spend so much time thinking about it, but thats just me.

DSD to PCM conversion is already a special case in DSP studio.

No its not, it acts just like you would decode a PCM file with such a high sample rate. DSP studio doesn't know its getting content that was originally DSD.

[dtc]

People wanted to configure those separately for reasons I don't understand, as I was not involved in adding those new lines, but more then one user asked for it.
There is practically no PCM content at such sample rates, although its not impossible, just impractical, so folding all DSD into the >736 line would defeat the purpose of having added them in the first place.

If I'm getting an error that 705k sample rate cannot be played, wouldn't going to that list and setting 705k to something lower be a logical first step to take? Its hard to think like some random user though.

Maybe for maximum out-of-the box playback compatibility we should default those to something reasonably lower, widely supported, 176/192 respectively?
We have one option that tries to automatically adjust output settings if playback fails, but I don't remember if its on by default and if it catches all problems. Definitely wouldn't help with conversion troubles.

Personally I don't think DSD is something worth worrying all this much about, rather get rid of it then spend so much time thinking about it, but thats just me.

No its not, it acts just like you would decode a PCM file with such a high sample rate. DSP studio doesn't know its getting content that was originally DSD.

The problem comes especially with conversions. The conversion simply errors with a 0 byte temp file as the output. No indication about the problem. Maybe some error handling would help.

To users, DSP Studio  is a set of windows with various options. The Output Format Option is, for a user point of view, part of DSP Studio. The header even says DSP Studio. So, from a user perspective, DSP Conversion is part of DSP Studio.

The point is the code that calls the DSD to PCM conversion routine could also call the PCM conversion routine. It doesn't seem like it would be a huge task to do that and it seems like it used to work that way.

A line for 705, one for 768, one for 1XDSD, one for 2XDSD would seem like the most straightforward from the user interface point of view. Behind that, the code can decide how to funnel those options to the internal routines.

I understand the DSD is only used by a small number of users. But it seems a shame to have what is a very fine implementation of it, with a few loose ends. Cleaning up those loose ends (including the low pass filters) would really make it superb. Unfortunately, I do not see that happening and DSD support will forever be incomplete. I would be happy to have you prove me wrong Maybe a few days work would get those of us who care out of your hair forever.

Thanks for your insight and your candor.

[Hendrik]

The point is the code that calls the DSD to PCM conversion routine could also call the PCM conversion routine. It doesn't seem like it would be a huge task to do that and it seems like it used to work that way.

A line for 705, one for 768, one for 1XDSD, one for 2XDSD would seem like the most straightforward from the user interface point of view. Behind that, the code can decide how to funnel those options to the internal routines.

I already tried to explain above why thats not something thats being done right now. DSP Studio and all conversions are distinctly separate components from the input plugins which handle decoding of the audio (and in this case dsd to pcm conversion, since its strictly speaking an act of decoding to PCM).
Because those are separate and individual components, once the audio reaches the DSP Studio, it does no longer know what it once was, and therefor having it act differently based on what the original format was is not currently possible - it just lacks this information.

And yes, we could somehow give it this information, however it would entail quite a bit of extra complexity to create a new interface to communicate new data like this just to make some UI changes.
We might as well just rename 705k into 705k/2xDSD to somehow illustrate thats what this entry is used for, and not need any complex behind-the-scenes logic to decide which one to use.

PS:
The way DSD processing works has not changed since I've been working on MC (ie. in the last 3 years or so). All that changed was the addition of some extra sample rate entries in the DSP Studio "Output Format", previously it was all bunched together into >192 or >384, or whichever it started out as. If you didn't change that setting from "untouched", it would've resulted in the same issues as today.

[dtc]

Obviously I do not know the internals, so I will leave that to you. I am still confused how this was done back in MC17 but is now not doable. I guess some internals must have changed.

How about in the Output Format section,  adding some comment below the >768 line  if that line is changed that says conversion is done to 352 or 705 and any other desired re-sampling should be specified in those lines. Or maybe in a popup.

Anyway,  I have beaten this to death. Thanks.