Dithering is a Mathematical Process - NOT a psychoacoustic process.

[solderdude]

Maybe someone here knows this.

Thought experiment:

Suppose we have a RB signal and process this using digital volume control.
44.1/16 which we attenuate, then we need 1 LSB dither in amplitude regardless whether or not the steps are in 24 bit, 32 bit or 64bit at least when a DAC capable of 16 bit only.
Dither would need to be 1 LSB of 24 bit when a 24 bit capable bit is connected.
After all it is the DAC itself that determines how high (in level) dither is needed (1LSB max).

Do digital volume controls take this in consideration (when it uses dither ?) do they know what bit depth a connected DAC has and takes it into account ?

What part of the operating system/driver takes this in consideration or am I looking at this from the wrong angle.

When upsampling a RB to 88.1/24 or 176.4/24 things are different again because 'inbetween' sample values for the RB are calculated.
Does such program only look at the output format and adjusts dithering level (when possible/activated) to the new format even when calculated in 32 bit or 64bit stepsizes ?

 

[xr100]

Maybe someone here knows this.

Thought experiment:

Suppose we have a RB signal and process this using digital volume control.

What is an RB signal?

Do digital volume controls take this in consideration (when it uses dither ?) do they know what bit depth a connected DAC has and takes it into account ?

Depends on the software, question would need to be more specific.

What part of the operating system/driver takes this in consideration or am I looking at this from the wrong angle.

Depends on which OS and which API is used, etc. Generally you want to bypass whatever the audio stack is up to. It should "know" what the settings are for the audio device. Off the top of my head... as of Vista, Windows does everything at a higher layer in the audio stack before hitting the driver--streams are resampled (if required), mixed, then dithered to the target format. There is a global limiter on the output also. (Try playing an audio file that's got a high RMS level and hits 0dBFS, then try playing a short impulsive "alert" type sound that also hits 0dBFS. The limiter will obviously kick in, I think the release time is pretty long, too.)

When upsampling a RB to 88.1/24 or 176.4/24 things are different again because 'inbetween' sample values for the RB are calculated.
Does such program only look at the output format and adjusts dithering level (when possible/activated) to the new format even when calculated in 32 bit or 64bit stepsizes ?

Again, it depends on the software. Ideally, resample (if required) in 64-bit float, rescale/adjust gain in 64-bit float, then dither to the target bit-depth, delivered to the sound device in "exclusive"/"bit-accurate" mode, e.g. WASPAI Exclusive mode, bypassing the "mixer" etc. in the audio stack.

 

[xr100]

Anyway, I digress. I expect Audacity is OK if your needs are trimming files or exporting to FLAC etc., but I wouldn't trust it for much more, e.g. using high pass filters or something I'd want to test before use!

Yikes. Not only is this a horrendous UI, but the max. filter length, depending on sample rate, whether the filter imposes delay or not, is hardly adequate, or is inadequate, at the LF end. No idea what windowing is used, either.

 

[solderdude]

What is an RB signal?

Red Book (16/44) should have said 'file' instead of signal.

Looked into this a bit (pun intended) and found what I wanted to know.
I don't use Windows, Apple nor Linux for serious listening and the question popped up in my head .

 

[bennetng]

Thank you. I could not find this option ("enabled") in CoolEdit Pro. I will try in Adobe Audition, which is installed on another PC, that I usually do not use.

I have Audition 1.5. Perhaps you can try this file:
https://www.audiosciencereview.com/forum/index.php?attachments/white-zip.43799/

Original wav file:

Encoding settings:

32-bit decoding disabled:

Enabled:

 

[xr100]

Red Book (16/44) should have said 'file' instead of signal..

D'oh! Of course.

 

[bennetng]

Red Book (16/44) should have said 'file' instead of signal.

Looked into this a bit (pun intended) and found what I wanted to know.
I don't use Windows, Apple nor Linux for serious listening and the question popped up in my head .

I used to use CDDA as it is the official name.

 

[xr100]

I used to use CDDA as it is the official name.

Well... strictly "Red Book" signal nor "CDDA" signal are correct. LPCM audio data per "Red Book" or "CDDA" specification, maybe.

Although I now feel compelled to post this image...

 

[bennetng]

Well... strictly "Red Book" signal nor "CDDA" signal are correct. LPCM audio data per "Red Book" or "CDDA" specification, maybe.

Although I now feel compelled to post this image...

View attachment 50161

OK, so the real name is PCDPPSF.
Philips Compact Disc Pure Perfect Sound Forever

 

[xr100]

OK, so the real name is PCDPPSF.
Philips Compact Disc Pure Perfect Sound Forever

LOL!

 

[Hayabusa]

What am I to say? He denies that ISP's are an issue, then equivocates around the whole issue, then tries to frame my position (incorrectly) while scolding me for malpractice, ...

I am glad I am still alive haha..

 

[mansr]

Suppose we have a RB signal and process this using digital volume control.
44.1/16 which we attenuate, then we need 1 LSB dither in amplitude regardless whether or not the steps are in 24 bit, 32 bit or 64bit at least when a DAC capable of 16 bit only.
Dither would need to be 1 LSB of 24 bit when a 24 bit capable bit is connected.
After all it is the DAC itself that determines how high (in level) dither is needed (1LSB max).

If a 16-bit signal is being sent to a 24-bit DAC, it can be shifted right by up to 8 bits without needing dither. You can, if you prefer, see it as varying the amount of zero padding at the bottom of each sample. Dither should be used whenever the input samples are altered in some way rather than simply placed in a larger bucket.

 

[JohnPM]

To stray somewhat towards the original thread topic, I have noticed an odd behaviour on more recent Windows versions that looks to be dither related. When Windows is asked for 16-bit data from a 24-bit source it seems to apply dither (good) but the dither is periodic with a period that looks to be 2047 samples, based on examining the behaviour of the LSBs of the raw data (rather bad). Consequently the noise floor of the data has features at 23.4 Hz (approx) intervals (48 kHz sample rate). Making dither periodic seems rather poor.

 

[bennetng]

To stray somewhat towards the original thread topic, I have noticed an odd behaviour on more recent Windows versions that looks to be dither related. When Windows is asked for 16-bit data from a 24-bit source it seems to apply dither (good) but the dither is periodic with a period that looks to be 2047 samples, based on examining the behaviour of the LSBs of the raw data (rather bad). Consequently the noise floor of the data has features at 23.4 Hz (approx) intervals (48 kHz sample rate). Making dither periodic seems rather poor.

View attachment 50168

Indeed. I have the same result as yours. Perhaps it is just a stored snippet of an audio file.

 

[pma]

To stray somewhat towards the original thread topic, I have noticed an odd behaviour on more recent Windows versions that looks to be dither related. When Windows is asked for 16-bit data from a 24-bit source it seems to apply dither (good) but the dither is periodic with a period that looks to be 2047 samples, based on examining the behaviour of the LSBs of the raw data (rather bad). Consequently the noise floor of the data has features at 23.4 Hz (approx) intervals (48 kHz sample rate). Making dither periodic seems rather poor.

I have found the same problem (one of the reasons I complained about REW for low distortion measurements) but only if REW works with JAVA card driving. It the ASIO driver is used, resolution is in conformance with 24-bits operation. This problem that you describe I have with Creative USB X-Fi HD, with JAVA selection in REW. The same card works flawlessly in Arta with WDM windows drivers in 24-bit resolution. Also in SpectraLab. So it seems to be REW implementation issue, not Windows issue.
The card that works well in ASIO mode in 24bits with REW is Roland Duo-Capture Ex.

P.S.: with WDM drivers it must be of course set in Control Panel the proper resolution (like 96/24) to prevent Windows from resampling to 16bits. I think this is basic and obvious to anyone.

 

[solderdude]

I use REW but only in ASIO mode which works fine for me.

 

[scott wurcer]

The time consuming part is getting the environment (VST etc) to work, not the (trivial) payload code. I for one am very thankful for this kind of simple stuff.

You might not remember that CoolEdit came with a MS Visual C SDK back in the day where you just edited a plug-in "skeleton" and did a one click recompile. I wrote a plug-in to do a third order spline click repair that still works today.

 

[JohnPM]

I have found the same problem (one of the reasons I complained about REW for low distortion measurements) but only if REW works with JAVA card driving. It the ASIO driver is used, resolution is in conformance with 24-bits operation. This problem that you describe I have with Creative USB X-Fi HD, with JAVA selection in REW. The same card works flawlessly in Arta with WDM windows drivers in 24-bit resolution. Also in SpectraLab. So it seems to be REW implementation issue, not Windows issue.

It is a Java on Windows issue, not an REW issue. JavaSound on Windows only offers 16-bit data and only mono or stereo, both legacies of the original implementation many years ago when DirectSound was the underlying problem. JavaSound has not been updated since. That might change one day, I have a couple of enhancement requests in to address it and others have expressed interest in adding WASAPI support to JavaSound.

 

[pkane]

It is a Java on Windows issue, not an REW issue. JavaSound on Windows only offers 16-bit data and only mono or stereo, both legacies of the original implementation many years ago when DirectSound was the underlying problem. JavaSound has not been updated since. That might change one day, I have a couple of enhancement requests in to address it and others have expressed interest in adding WASAPI support to JavaSound.

Any known issues or limitations with CoreAudio on macOS? That's where I'm using REW. So far I've not seen any problems with dither.

 

[DonH56]

Random responses:

Ah. Do you happen to recall over what period the standard calculates that?

Hmph. Sorry, I conflated two things. The ideal SFDR derivation is not in the Standard, at least I don't think it is (been a while, and ironically I helped write and revise them but didn't keep a copy when I left that company), but is in various other papers. The last time I waded through it was whilst reviewing a PhD dissertation some years back as an outside "expert" (as if!) I'll just say I think the student was better than I at math.

Again bearing in mind I do not have it in front of me, I don't think the Standard actually specifies record lengths, though includes methods for optimizing bit coverage for given record lengths. It also bases its performance metrics on ENOB, which is in turn based upon SINAD, not SFDR. It defines histogram and curve fitting routines in addition to using FFTs along with methods for calculating relatively prime signals to avoid windowing in testing (can't in the real world as you've said). I may have retained a copy; I'll have to see if I have it on a shelf in my office at home. If it is boxed up as I fear in the black hole masquerading as our basement storage room I am not digging for it.

I know I don't know this stuff as well as you, and my day job shifted away from data converter design, so I am not immersed in it daily as I was a few years ago. Apologies in advance for my mistakes and appreciate your catching and correcting them for me! - Don