While I'm tempted to say I agree, taking one step back it depends on your DNR target. This is a subjective area.
Let's say you target 96 dB CD-quality. And let's say you do so because that coincides with 120 dB DNR of human hearing minus 30 dB background noise.
Now when you have 24-bit playback, that's 144 dB range but let's also assume you want to have volume control. You have 48 dB available before you exceed your target.
Subjective again is a generally appreciated opinion that a volume control should have 60 dB range, which equates to about a healthy (?) 90 dB SPL minus 30 dB background noise. With 48 dB available, you're short of your target.
Some may say it's academic, because at that level of attenuation you wouldn't discern the details hidden in that DNR anyway.
This is of course irrelevant if you have invested in a good and probably costly analog attenuator.
Sounds appropriately MilSpec.
Never.
I think I've mentioned before, anyhow, that I feel these sorts of related digressions are healthy to a thread, as they help keep everyone engaged. Particularly, while thread action naturally slows as it has now while we conduct the 176 experiment.
So, no worries, Kostas.
We owe this very nice thread to an excellent host!
I just received a message from ZB, who is supplying us generously with files upsampled with his excellent PGGB software, who is reading this thread but not contributing.
But I thought it to be informative to share his message to all of you.
Thank you ZB for giving this additional information.
Hans
I see there is much mention of Foobar on the thread, Foobar does all processing as float, 24 bit files will play bit perfect but 32bit files will be converted to 32bit float and then back to 32bit ints if the DAC accepts 32bits, this can be a problem especially with noise shaped 32bit files because 32bit float cannot fully represent 32bit int and there will be rounding
Also any processing done by Foobar such as volume control, will alter the original file, it will be converted to 32bit floats and then possibly truncated back to 24 bits or 32bits.
This is les of an issue with players that support 64bit processing such as Jriver or HQplayer
Regards,
-ZB
But I thought it to be informative to share his message to all of you.
Thank you ZB for giving this additional information.
Hans
I see there is much mention of Foobar on the thread, Foobar does all processing as float, 24 bit files will play bit perfect but 32bit files will be converted to 32bit float and then back to 32bit ints if the DAC accepts 32bits, this can be a problem especially with noise shaped 32bit files because 32bit float cannot fully represent 32bit int and there will be rounding
Also any processing done by Foobar such as volume control, will alter the original file, it will be converted to 32bit floats and then possibly truncated back to 24 bits or 32bits.
This is les of an issue with players that support 64bit processing such as Jriver or HQplayer
Regards,
-ZB
I once had an interesting anecdotal experience in comparing dithered with truncated audio samples on both music and speech. That was quite a number of years ago, so I don't have a link (if one even still exists) to that test.
The test files utilized increasingly lower resolution samples, down to around 8-bits per sample, IICR. What I perceived was, as the quantization-noise consequently increased, dither kept speech more intelligible than did truncation. However, with music, the overall sound was less enjoyable with dither, than from truncation. I was surprised by this perception. The dither was audible as a separate noise source, and was distracting. I was less distracted from the music without the dither-noise. With dither, I enjoyed music much less than without. There was no question, however, that dither increased the intelligibility of speech, even with the dither noise being audible. Perhaps, the audible increase in noise was easier for the brain to ignore while decoding spoken words, an intellectual process, than while hearing music, an emotional process.
I don't know whether any of that subjective experience applies to hearing higher resolution audio (16-bits or more), but it was none the less interesting.
The test files utilized increasingly lower resolution samples, down to around 8-bits per sample, IICR. What I perceived was, as the quantization-noise consequently increased, dither kept speech more intelligible than did truncation. However, with music, the overall sound was less enjoyable with dither, than from truncation. I was surprised by this perception. The dither was audible as a separate noise source, and was distracting. I was less distracted from the music without the dither-noise. With dither, I enjoyed music much less than without. There was no question, however, that dither increased the intelligibility of speech, even with the dither noise being audible. Perhaps, the audible increase in noise was easier for the brain to ignore while decoding spoken words, an intellectual process, than while hearing music, an emotional process.
I don't know whether any of that subjective experience applies to hearing higher resolution audio (16-bits or more), but it was none the less interesting.
Hi Hans,
I think the point was already made that 32-bits is probably right for native DSD. However, for PCM we know that no physical dacs have ENOB of 24, maybe 21 or 22 at best.
Also, IIUC dither isn't considered important when truncating from 32-bits to 24 since there should already be enough inherent noise at that low level to effectively self-dither.
I think the point was already made that 32-bits is probably right for native DSD. However, for PCM we know that no physical dacs have ENOB of 24, maybe 21 or 22 at best.
Also, IIUC dither isn't considered important when truncating from 32-bits to 24 since there should already be enough inherent noise at that low level to effectively self-dither.
That is a very interesting experience, thanks for sharing.
If people would find this an interesting experiment, let me know because I can accommodate relatively easily. I am one of the maintainers of the librespot project which is an open source Spotify client, used by several audio distributions. I have authored the dithering and sample format code. You can already switch dithering on/off and between different algorithms. It would be quick work to patch in 4/8/11/12-bit audio formats and enjoy distorted music
To be clear I'd be happy to patch it in if there's sufficient demand. If it's only a select few then in all honesty I have more community affairs to tend to.
With reference to ZB's post, the entire librespot chain is in 64-bit floating point.
If people would find this an interesting experiment, let me know because I can accommodate relatively easily. I am one of the maintainers of the librespot project which is an open source Spotify client, used by several audio distributions. I have authored the dithering and sample format code. You can already switch dithering on/off and between different algorithms. It would be quick work to patch in 4/8/11/12-bit audio formats and enjoy distorted music
To be clear I'd be happy to patch it in if there's sufficient demand. If it's only a select few then in all honesty I have more community affairs to tend to.
With reference to ZB's post, the entire librespot chain is in 64-bit floating point.
Thanks, Kostas. My focus on hosting has been made so much easier by the technical support of Hans.
ZB wrote:
It means that Foobar can still be used for this testing if a volume slider is kept at 100% and other bit perfect precautions are observed.
@MagicBus. I was blindfolded, thanks.
Valid comment. However Foobar will convert to 32-bit float only when internal processing is required (internal active DSP, replay gain or volume control). I am sure about in the case of 16-bit and 24-bit source, why it should be different for 32-bit data sources?
It means that Foobar can still be used for this testing if a volume slider is kept at 100% and other bit perfect precautions are observed.
@MagicBus. I was blindfolded, thanks.
Last edited:
According to the producer of Foobar, this is how data is handled.
wav 32bit fixed-point to FLAC
Hans
Recently the Holo May (which is a NOS DAC, by the way) was measured at 140 dB DNR, a good 23 ENOB. Granted that's in dual mono, but still, spectacular and far from 32 bit. But man, I wish I owned one of those. Link: KTE May technical measurements | Super Best Audio Friends
The thermal noise floor in the audible range is -131 dB, if I recall correctly. The Holo May supposedly beats that figure by actively sensing noise levels and negating that in a feedback loop. Given the random nature of that noise I don't really understand how, but that seems to be the secret sauce.
Anyway, such mechanisms are not normal practice and so that -131 dB is a pretty good threshold below which, to keep it short, none of it really matters.
I maintain that discussions on this topic should state whether or not to take digital attenuation into account. At 0 dBFS it won't matter beyond 22 bit, below 0 dBFS you'll want the headroom to maintain your DNR target.
Nonsubtractive triangular PDF dither makes the average and standard deviation of the total quantization error independent of the signal at the expense of increased noise, usually by about 4.77 dB.
Depending on the characteristics of the music, the quantization error may already be similar to noise without any dither. Dithering then only makes the noise 4.77 dB worse.
When the signal has a simple rational relation to the sample rate and/or is only a few quantization steps large, then you get an undithered quantization error that has a line spectrum with all sorts of distortion and aliasing products. Then it definitely sounds better with dither. Simple music with just one instrument or voice, particularly when it is soft, is more likely to suffer from this than more complex music.
In fact I notice that with I load a new sound into my doorbell. When I was 17, I built a circuit meant to be used as a doorbell that records a few seconds of sound in DRAM memory using an undithered single-bit first-order delta modulator (about the worst kind of ADC you can imagine, but simple and good enough for a doorbell). When I load a part from the middle of Paul McCartney's Let 'm in, it sounds far better than when I load the sound of a bird singing with little or no background noise.
In my and quite many others opinion, kernel streaming should not be obsolete yet. Though it is very old, it is still a very direct and quick way to transfer audio. Some ASIO driver implementations actually go through kernel streaming. I had quite some back and forth between ASIO and kernel streaming, but in the end preferred kernel streaming. They can both be bit perfect, the difference is in USB timing affecting jitter and perhaps also noise patterns. Very audible, surprising really.
Sorry for the slight off topic though...
Thanks, very interesting. I forgotten that 24-bit integer is self-contained in 32-bit float (it can be converted forth and back losseless).
@fedde, I think Amanero ASIO do not use KS and for me there is no sq difference between WASAPI and ASIO. The same was with early XMOS driver for Topping D30. Perhaps it depends whether implementation use asynchronous packet delivery or not, then jitter matters..
Last edited:
So, I did the intersample overshoots test again. Only OS suffers from this. In NOS mode I can leave the digital volume control full open without problem. But in OS I have to take it down. Just a bit is enough however. And here comes the question: Lowering the level only as necessary to avoid overshooting, what would do to the least significant bits and the dithering applied during recording?
The digital volume control will consist of a multiplication and presumably some rounding/requantizing stage. If that rounding stage has its own dither, then the rounding error will sound similar to additive noise (with an extremely low level). If not, then it's hard to tell whether it will be noise-like or not. It probably will if the noise in the recording is much stronger than the rounding error or the music is complex enough.