Print

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

[richard-ec2]

I want to play back a DSD file in JRiver but my DAC does not support DSD. So I let JRiver convert it to PCM and in the Output Format I tell it to convert anything above 192 kHz to 44.1 kHz.

When playing back, this is what I get in the Audio Path:

Input: 352.8 kHz 64 bit 2ch from source format DSF
Output: 44.1 kHz 24 bit 2ch using ASIO (not using enough bits to output the input directly)

Obviously my DAC can only support a maximum of 24 bits and that’s why the bit depth is dropping from 64 bits on the input to 24 bits on the output. But that "not using enough bits to output the input directly" is worrying me. My question is, does this degrade the sound? I really understand very little about bits but I thought you were supposed to use dither when you were reducing bit depth.

[RD James]

It's a status message, not an error message.
Nothing to worry about so long as the output is appropriate for your hardware.

I wonder if the message should be removed in v22 because it only seems to bring people here concerned that something is wrong.

[richard-ec2]

OK, many thanks for the reassurance and I will stop worrying about it! It's probably quite a complex business and I would need to read up on it but if anyone has time to explain why nothing is lost in going from 64 bits to 24 bits, I'd be very interested to hear it.

[RD James]

OK, many thanks for the reassurance and I will stop worrying about it! It's probably quite a complex business and I would need to read up on it but if anyone has time to explain why nothing is lost in going from 64 bits to 24 bits, I'd be very interested to hear it.

It's not that "nothing is lost" but what is lost is down below -144dB (24-bit) which is inaudible when music is playing.
 
Additionally, it's not "really" 64-bit. It's a 1-bit audio file (DSD) decoded using a 64-bit decoder.
So the output is 64-bit from that conversion, but DSD is more like 20-bits SNR across the whole audio range.

[Matt]

I wonder if the message should be removed in v22 because it only seems to bring people here concerned that something is wrong.

Yeah, I wonder if we should just not show it if the output is 24-bit or higher?  It makes people worry, and there's just no reason if you're doing 24bit (or higher) output.

I think it would just be switching this:
else if (afOutput.GetValidBitsPerSample() < nInputBitDepthValuable)

To:
else if ((afOutput.GetValidBitsPerSample() < 24) && (afOutput.GetValidBitsPerSample() < nInputBitDepthValuable))

[RD James]

I would just remove the message entirely, since the audio path is displaying both the input and output bit-depth.
If you're using a 16-bit output it's probably intentional and not done in error.
Even a 16-bit output is not going to have any audible problems thanks to the TPDF option that was added in v21. (which I think should be promoted to the default setting in v22)
 
I did notice that ASIO reports a 32-bit output even if the "device uses 24 bits" option is selected though, while WASAPI correctly reports "24-bits (padded)".
 
Perhaps reformatting the dialog might be a good option?
If you list:
Input: [Channels] [Sample Rate] [Bit Depth] from [codec]
Output: [Channels] [Sample Rate] [Bit Depth] using [connection type]
Changes:
Then it makes the comparison easier.

[Hendrik]

I did notice that ASIO reports a 32-bit output even if the "device uses 24 bits" option is selected though, while WASAPI correctly reports "24-bits (padded)".

Technically that happens because ASIO has no such concept, it just gets 32-bit, thats why you have to manually set this flag as well, which changes the audio representation only, but not the metadata as shown to ASIO, while with WASAPI this is automatically detected and used when appropriate (and WASAPI is also told of this). The output format comes straight from the output plugin, and the ASIO plugin doesn't know any better.

[blgentry]

OK, many thanks for the reassurance and I will stop worrying about it! It's probably quite a complex business and I would need to read up on it but if anyone has time to explain why nothing is lost in going from 64 bits to 24 bits, I'd be very interested to hear it.

RDJames has pretty much covered it, but I wanted to say a little something:

A.  The conversion, internally from DSD to 64 bit is just because MC does everything in a 64 bit domain.  If you change the volume level (with internal volume), or use volume leveling, or add equalization, or anything else in MC's DSP, it gets converted to 64 bit to do those audio manipulations.  When MC is done with it and wants to send it to your DAC, it converts to the DAC's native bit depth.  So this really applies to everything you play in MC.

B.  If your DAC can't play any greater bit depth than 24 bits, then you have no way of hearing anything above 24 bits.  The idea of greater resolution than 24 bits, for playback, is kind of silly, as the number of levels represented in 24 bits of audio data is really enormous.  I don't think I've seen any arguments that human beings can discern above 24 bits of resolution.  But that's a WHOLE other discussion that we probably shouldn't have here.

Brian.

[RD James]

Technically that happens because ASIO has no such concept, it just gets 32-bit, thats why you have to manually set this flag as well, which changes the audio representation only, but not the metadata as shown to ASIO, while with WASAPI this is automatically detected and used when appropriate (and WASAPI is also told of this). The output format comes straight from the output plugin, and the ASIO plugin doesn't know any better.

Yes it's technically correct, but you are just padding out a 24-bit signal to 32-bits for the ASIO output, which I think is the important thing.
I wonder if reformatting the dialog might be a good option?

If you list:

Code: [Select]

Input:   [Channels] [Sample Rate] [Bit Depth] from <codec>
Output:  [Channels] [Sample Rate] [Bit Depth] using <connection type>
Changes:
  <dsp>
  <dsp>
  <dsp>
  <dsp>
  <dsp>

It makes the comparison easier than:

Code: [Select]

Input:   [Sample Rate] [Bit Depth] [Channels] from <codec>
Changes:
  <dsp>
  <dsp>
  <dsp>
  <dsp>
  <dsp>
Output:   [Sample Rate] [Bit Depth] [Channels] using <connection type>

Channels was moved because bit-depth can have a variable width, and sample rate would ideally be padded to align correctly.
Edit: This may be ugly unless the width of the audio path is increased. I forgot that some combinations result in it wrapping to multiple lines.

[richard-ec2]

Just to offer a user's perspective, the reason I became confused was because the Output Format function allows you to select a sample rate to suit your DAC but it does not enable you to select the bit depth you desire. My DAC offers a range of sample rates and also two bit depths, 16 bits and 24 bits, so having set the sample rate at the correct level, I then spent a long time searching unsuccessfully for some function that would allow me to select 24 bits. It was while doing this that I discovered that the DSD was actually being converted at 64 bits and the Audio Path message just added to my confusion. Personally, I think it's good that the Audio Path tells you what's happening but maybe it just needs rewording slightly to make it clearer what's happening - eg, instead of saying "not using enough bits to output the input directly," saying something like "bit depth set to maximum available on output device" or some such.

RDJames has pretty much covered it, but I wanted to say a little something:

A.  The conversion, internally from DSD to 64 bit is just because MC does everything in a 64 bit domain.  If you change the volume level (with internal volume), or use volume leveling, or add equalization, or anything else in MC's DSP, it gets converted to 64 bit to do those audio manipulations.  When MC is done with it and wants to send it to your DAC, it converts to the DAC's native bit depth.  So this really applies to everything you play in MC.

B.  If your DAC can't play any greater bit depth than 24 bits, then you have no way of hearing anything above 24 bits.  The idea of greater resolution than 24 bits, for playback, is kind of silly, as the number of levels represented in 24 bits of audio data is really enormous.  I don't think I've seen any arguments that human beings can discern above 24 bits of resolution.  But that's a WHOLE other discussion that we probably shouldn't have here.

Brian.

Thank you - I found this very helpful. On my PC I have Adobe Audition, which operates at 32 bit floating point internally but when you save a file, you'd normally do it at 24 bits or 16 bits. So it's the same sort of thing, I suppose. As you say, we can't hear more than 24 bits anyway so I certainly wouldn't be wanting a 64-bit output, even if there were a consumer DAC capable of  handling it.