During a silent time I have a question.
What happen if before R2R conversion oversampling is applied to the 16/44.1k source with intensive noise shaping, in the next step downsampled back with 16-bit dither. Would this operation result in decreasing a noise floor or other improvements in measurements?
What happen if before R2R conversion oversampling is applied to the 16/44.1k source with intensive noise shaping, in the next step downsampled back with 16-bit dither. Would this operation result in decreasing a noise floor or other improvements in measurements?
Last edited:
Not sure why you ask this specifically for R2R conversion.
But over- or up-sampling does not involve noise shaping.
Noise shaping has to do with reducing the number of bits, for instance from 48 during the calculation process to 24 bits at the quantizing stage and only distributes quantisation noise in such a way, that as much as possible of this quantisation noise is shifted out of the audio band.
Downsampling afterwards can be done by decimation when it's an integer of 44.1 or by SRC by using filters again.
As a last step quantization and dithering to 16 bits will have to be done, but at this point no noise shaping is possible because there is no out off band range anymore.
All this time the original dither from the 44.1/16 signal will be treated as signal an left untouched.
So after upsampling and quantizing plus noise shaping and going back to 44.1/16 with again quantizing and dithering, noise will always be increased compared to the original 44.1/16 file, how much depends on the roads that were followed.
Hans
Theoretically more predictable would be a more accurate description. With nonsubtractive dither, you can calculate some statistics and the spectrum of the total quantization error without needing to know anything about the music that's playing, but that's at the expense of a somewhat larger error.
... for you. Other might want the theoretically best version...
//
Well, I don't want to be misunderstood, I also care about theory despite I'm not an expert. It's that reality seems more obscure. For example, we hear that Foobar is processing everything at 32bit floating point yet bit perfect output is guaranteed. Will this happen only when a DSP is active or is the standard procedure? Same thing for the usb to I2S converter. A microprocessor is involved. It does process when the digital volume control is used. But are we sure it doesn't otherwise? Would it make sense to hope that bit perfect output is still possible? That is for 16, 24 and 32bit floating point, I understand it does not apply to 32bit fixed. And when the digital volume control is engaged, we forget 32bit immediately but when 24bit is lost? If I understand correctly, recorded dithering will be lost easily but we can hope for new dithering to apply. What makes one better than the other?
All these are indeed questions, I'm not stating anything...
32 bit float has 23 bits fraction+1 bit sign and 8 bits exponent. So indeed up to 24 bits can be stored 1:1. 64 float can store up to 53 bits 1:1 and has quite a similar performance (speed wise) on modern x86 CPUs. Little reason not to use it as an intermediate format.
Regarding clip avoidance, I would suggest to multiply with exactly factor 0.5. This would be the same as a shift of one bit. I think this would leave 16 bit material bitperfect. For 24 bit material used on 24 bit output, the lowest bit would be lost and therefore perhaps also the dithering. But this could be added back. For 32 bit output it would still be bit perfect.
Regarding ASIO vs KS vs WASAPI exclusive (forget about DirectSound & Wave APIs, they are obsolete for high end audio), once you start experimenting with and its subconfigurations (buffer size, bit width, some other settings and even the player used and general OS settings), a world opens up. To me and on my hardware it makes quite a difference, perhaps similar as in some of these upsampling experiments. To my ears, and on JL sounds USB to I2S/SPDIF v3, kernel streaming has better stereo placement and is much tighter while ASIO sounds more full & rounded. I really would like to have hardware that is more independent on whatever is done on CPU/player/interface side, but after reading quite some text on this this appears to be super hard to get fully solved. One of the reasons that some persons stopped using USB altogether and moved to ethernet solutions. I had similar perceptions on Amanero by the way, and indeed it has a direct ASIO driver, but still there is a difference in sound IMHO.
Regarding clip avoidance, I would suggest to multiply with exactly factor 0.5. This would be the same as a shift of one bit. I think this would leave 16 bit material bitperfect. For 24 bit material used on 24 bit output, the lowest bit would be lost and therefore perhaps also the dithering. But this could be added back. For 32 bit output it would still be bit perfect.
Regarding ASIO vs KS vs WASAPI exclusive (forget about DirectSound & Wave APIs, they are obsolete for high end audio), once you start experimenting with and its subconfigurations (buffer size, bit width, some other settings and even the player used and general OS settings), a world opens up. To me and on my hardware it makes quite a difference, perhaps similar as in some of these upsampling experiments. To my ears, and on JL sounds USB to I2S/SPDIF v3, kernel streaming has better stereo placement and is much tighter while ASIO sounds more full & rounded. I really would like to have hardware that is more independent on whatever is done on CPU/player/interface side, but after reading quite some text on this this appears to be super hard to get fully solved. One of the reasons that some persons stopped using USB altogether and moved to ethernet solutions. I had similar perceptions on Amanero by the way, and indeed it has a direct ASIO driver, but still there is a difference in sound IMHO.
Dither and bitperfect are mutually exclusive, so a program with software volume control that is bitperfect when the volume is at 100 % and that dithers and requantizes the signal when the volume is reduced, must have an if statement somewhere to switch off the dither when the volume is at 100 %.
Dither only works well when it has precisely the right probability density function. Reducing volume or (re)quantizing changes the probability density function, so you can't reuse dither from one quantization step for a later requantization step. Instead, you have to add new dither with the right probability density function whenever the signal gets quantized or requantized.
Dither only works well when it has precisely the right probability density function. Reducing volume or (re)quantizing changes the probability density function, so you can't reuse dither from one quantization step for a later requantization step. Instead, you have to add new dither with the right probability density function whenever the signal gets quantized or requantized.
Thanks! I need to grasp this.
On other news, I found something! Besides Foobar settings there is the WaveIO control panel, of course. There is required to set the output sampling rate and bit depth. It allows for max 192/24, no more. So this explains why I can play up to 384kHz with PCM1794. Obviously the conversion is done by the Xmos microprocessor.
On other news, I found something! Besides Foobar settings there is the WaveIO control panel, of course. There is required to set the output sampling rate and bit depth. It allows for max 192/24, no more. So this explains why I can play up to 384kHz with PCM1794. Obviously the conversion is done by the Xmos microprocessor.
Everyone, please proceed with the 88,2/176,4 test otherwise we are going off track.
Marcel, if I may please, I have a few more questions for you regarding the echo test you were in charge:
1. By using the digital volume control, did I miss the crucial info?
2. Is it difficult to generate this embedded ripple? Would it be possible to apply as
a post-DAC hardware implementation?
PS. I just saw it. Unfortunately, mathematics is my weak point.
EDIT: Conclusions written in spoken language is a torture I'm used to so lets see. Thanks!
Marcel, if I may please, I have a few more questions for you regarding the echo test you were in charge:
1. By using the digital volume control, did I miss the crucial info?
2. Is it difficult to generate this embedded ripple? Would it be possible to apply as
a post-DAC hardware implementation?
PS. I just saw it. Unfortunately, mathematics is my weak point.
EDIT: Conclusions written in spoken language is a torture I'm used to so lets see. Thanks!
Last edited:
Yes, there is a XMOS Control Panel, a separate application. It probably does query a DAC and report maximum capabilities. If I remember correctly, it is for ASIO interface. Whether resampling take place there, I think is not. Also in the properly configured Foobar for bit-perfect transfers there is no resampling in Foobar when it obtain access to the WASAPI Exclusive or ASIO outputs. It plays in a native format and reports error when start playing of unsupported sample rate. It will resample only on shared outputs to the value that is set in the system Sound Control Panel. Do you have enabled Exclusive mode in Windows?
Last edited:
Agree, though only mutually exclusive for added dither. What I meant is the following scenario:
16 bit audio from CD where dither was already applied during mastering. I would presume the dither is applied in the LSB. This is read by a player and extended to 24 or 32 bit (zero extension). Then a multiplication is done with factor 0.5. This would move the dither bit one position further down. But it would still be in proportion with the other data so I would think it is still correct. But please correct me if I am wrong.
I am definitely interested in that. I would like to get a better understanding of dithering methods. And in the long run, I would like to add better dithering in my audio test software.
You are perfectly correct, of course, actually independent of whether anyone applied any dither anywhere. In your example there is no need to round off anything because the result of the multiplication fits in the wordlength. When there is no need for rounding there is no need for dither. I could imagine that the average audio processing program doesn't know that, though, and applies dither anyway. Otherwise the programmers need to make exceptions for all gain factors 2-k with integer k from 0 to n, where n is the wordlength difference between the output and the input signal.
Last edited:
No.
It's very easy in digital, but difficult in analogue. It can be done with infinite tape loops or bucket brigade devices, but I wouldn't recommend that. Why would you want to create an unintended artefact post-DAC?
Isn't it just a simple matter to reduce by 6dB or 1/2. In other words this shifts everything one bit to the right? Sometimes I do this to reduce the amplitude. Can't really tell what is actually happening in the software though.