Print

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

[SpeedD408]

In a coming build:
NEW: Added ASIO option 'Device uses only most significant 24-bits (Lynx, etc.)'.  This combined with dithering provides a theoretical S/N improvement for devices where this is true.

Hopefully you'll have time to test it.  I'd like to get the Bob Katz stamp of approval on our dithering

I see .126 is out with this added.  Did Mr. Katz have a chance to test and confirm??  I too would like to have MC get the Bob Katz stamp of approval.

[bobkatz]

I see .126 is out with this added.  Did Mr. Katz have a chance to test and confirm??  I too would like to have MC get the Bob Katz stamp of approval.

Wow, JRiver works fast! i was not aware of this option already being in the new beta, and I will test it thoroughly today. Speaking of this, how does the "show unread posts since your last visit" work?  After pressing "mark all read", and then I walk away from my computer for 20 hours without logging out, does the forum somehow time out and accumulate properly without having to log out/in?

Thanks, stand by for the fireworks,


Bob

[SpeedD408]

how does the "show unread posts since your last visit" work? 

Not sure how that works, but what works best for me is to click the "notify" button on the topics of interest.  Then the system will email me when a post is made to one of those threads.

[bobkatz]

Test 1 of dither using playback in JRiver:

OK, I tested the ASIO-related dither generator, in stereo, at 44.1k, 88.2k and 96 kHz, using some test tones I had generated, with ALL of the DSP studio turned off (checkboxes off).

tones included

1 kHz -10 dBFS 3244

1 kHz -10 dBFS already dithered 2444

1 kHz -60, -80 and -100 dBFS 3244 and 6444, as well as 6488 and 6496

I played the tones at unity gain, tested dither on versus off.  I also measured the tones at various attenuations with JRiver's volume control. Everything performed correctly, distortion was being correctly removed.

HOWEVER, I am sorry to say that the JRiver dither generator is uncorrelated. That is, a single dither generator is being used for all output channels. To guarantee good stereo imaging and ambience, separate, uncorrelated dither generators are needed. Otherwise as the sound fades to black and gets soft, it will "monofy" in the center for stereo. I'm not sure how well that will be noticed in surround if at all. Also, at 24-bits, this will be a very subtle effect. But technically and correctly, all professional-grade dither generators use uncorrelated dither for these reasons. But this is not going to stop me using the internal generator in JRiver if I can get line input to work correctly now. In my next post I'm going to retest line input because without needing Voxengo Elephant for dither I might have enough DSP stability to run Steinberg's ASIO multiclientserver/client.

I assume when a DSP element is unchecked the DSP is not in use and memory and DSP power is freed up, correct?

Stand by folks!

[bobkatz]

Next test was of live input using ASIO multiclient. With no DSP engaged in DSP studio, I got an audible glitch every 20 seconds to 2 minutes in the sound. This was not due to synchronization or clocking issues, I guarantee. I also don't think JRiver's ASIO dither generator is working in live input mode. I see garbage at low level in Spectrafoo, but it is not moving or fluctuating like random noise should, it's just staying there so I think it's distortion, though there are no distinct spikes related to the test tone I'm sending from Spectrafoo.

I tried to trace the glitches with DPC latency checker and it doesn't show anything. Neither does Task manager performance or CPU or resource manager but I am not an expert at interpreting those and maybe someone could guide me as to what to look for. CPU usage on all four cores is less than 1% and only the apps I'm testing are running. So, I'm sorry, I can't use Live input yet.

[Matt]

HOWEVER, I am sorry to say that the JRiver dither generator is uncorrelated. That is, a single dither generator is being used for all output channels. To guarantee good stereo imaging and ambience, separate, uncorrelated dither generators are needed.

The current dither generates a new dither value for each channel and each sample.  In other words, dithering CD format data would generate 88,200 dither values each second.

This matches my understanding of the definition of uncorrelated, and I believe it's the preferred approach (as opposed to generating 44,100 dither values each second for CD audio).

[bobkatz]

Hi, Matt. Are you using a random generator with a different seed for each channel?  My measurements in Spectrafoo show 100% correlation in amplitude and time between the left and right channels of your dither generator.


Bob

The current dither generates a new dither value for each channel and each sample.  In other words, dithering CD format data would generate 88,200 dither values each second.

This matches my understanding of the definition of uncorrelated, and I believe it's the preferred approach (as opposed to generating 44,100 dither values each second for CD audio).

[bobkatz]

I wonder if a bitdepth option should also be added to Parametric Equalizer? Bob has shown that a VST plugin (Voxengo Elephant) that is last in the signal chain can dither with the bitdepth staying intact since it is just being padded by JRiver for internal processing and the final ASIO output. This would also allow someone to send a certain bitdepth to another VST Plugin by using it before that plugin (although I'm not sure why someone would do this).

Mojave, I don't think there's good reason to do that unless someone has installed a cheap and dirty 3rd party plugin that isn't using the right in/out wordlength or is computing in (god forbid) fixed point. Even then, though, this fictional next plugin in the chain will use as much incoming data as it wants to and throw away the rest. So there's no point in truncating in front of it. Does this help?

[Matt]

Hi, Matt. Are you using a random generator with a different seed for each channel?  My measurements in Spectrafoo show 100% correlation in amplitude and time between the left and right channels of your dither generator.

Let me double-check the dither code tomorrow and follow up.

It's possible that it's not working the way I claimed above with ASIO due to ASIO buffers not being channel interleaved like other output modes.

If that's the case, it'll be an easy fix.

[Matt]

Let me double-check the dither code tomorrow and follow up.

There was an unintended (and unexpected) coherence in our random number generator when multiple were created within a millisecond or two (which happens in ASIO as it processes channel buffers).

This is because we were seeding off GetTickCount(...), and that didn't change in this case.

Good detective work catching this.  It will be fixed next build.

[bobkatz]

Dear Matt:

You're the one to be congratulated. You found the problem so quickly.

People, please keep in mind that I only performed a cursory analysis of the JRiver dither. A complete analysis and check could take a day or more. I did not check:

1) many different test frequencies, I only tested 1 kHz

2) The randomness and distribution of the dither. Ideally it should be TPDF (triangular probability density function). I don't even know how to do that!

3) Distortion at many different levels

4) The exact amplitude of the dither, though I did check it with other reference dither generators and it seemed to be in the ballpark for 24 bits.

Despite all that, my early tests show that JRiver's dither is eliminating distortion, helping the purity of tone and improving low level detail. Who could ask for more! Just remember: "Never turn your back on computers." When the programmer was asked if his program had any bugs, he replied, truthfully, "None that we've been able to find, yet".


Best wishes,


Bob

There was an unintended (and unexpected) coherence in our random number generator when multiple were created within a millisecond or two (which happens in ASIO as it processes channel buffers).

This is because we were seeding off GetTickCount(...), and that didn't change in this case.

Good detective work catching this.  It will be fixed next build.

[Matt]

Dither correlation issue fixed here:
http://yabb.jriver.com/interact/index.php?topic=77862.0

[hulkss]

Bob and Matt

Enjoying 24 bit random dither now. It's the Katz meow 

Feeling a bit incoherent.

Brad

[Mark Manner]

I have read with interest (and with some limited understanding, unfortunately) this thread on dithering. I am conversant with dithering in optical astronomy image processing, but not quite so sure I understand the audio version. Nevertheless,  I have the 18.0.128 version of JRiver MC installed, and am using it with my McIntosh C50 Preamp, which has an asynch usb input that requires ASIO, and I am using a McIntosh supplied ASIO driver.  The JRiver output I am using isn't making any changes to the stream (as far as I can tell--the icon is Blue, and indicates no changes made). On the McIntosh preamp, the display shows 32/44[88-96-176-192] as the input, depending on the source material on my PC. My question is whether I should check the box in the McIntosh ASIO driver to enable dither. See screenshot attached. Thanks for your advice,
Mark

[bobkatz]

Did the dither checkbox disappear?  This is on the window that has the option "open driver control panel" and also has the checkbox "devices uses only 24 bits".

I haven't needed it for a long time since I've been using Acourate ASIO (64 bit communication), but now I want to try JRiver's Convolution again and so JRiver is communicating direct with the Lynx. Matt, where did you hide the dither checkbox in this version?

Thanks,


Bob

[Matt]

Did the dither checkbox disappear?  This is on the window that has the option "open driver control panel" and also has the checkbox "devices uses only 24 bits".

I haven't needed it for a long time since I've been using Acourate ASIO (64 bit communication), but now I want to try JRiver's Convolution again and so JRiver is communicating direct with the Lynx. Matt, where did you hide the dither checkbox in this version?

A lot of your advice from this thread is now simply part of the audio engine.  Now all outputs (including ASIO) get dither on integer downsampling from a higher bitdepth (normally 64-bit floating point).

More here:
http://yabb.jriver.com/interact/index.php?topic=80522.msg548095#msg548095

Thanks for your help with this area.

[igorzep]

Our dither doesn't change how a 16-bit value looks at 24-bit.

From above: "It's important to remember that dithering, when done properly, does not change the bit-perfect nature of output.  A 16-bit or 24-bit value remains unchanged when dithering.  Dithering only changes values in between those whole values.  These in between values arise when performing any sort of processing, including volume."

I did real world testing of billions of random samples up to 32-bit integer output to test that our dither was obeying this rule.  It is.

Hello, Matt. Bumping up the dithering topic again. The quoted part is making me worry if TPDF dither is really implemented correctly in JRiver. The TPDF should be 2LSB dither and so, it MUST not be bit perfect even if there are no 'in between' values in the source. Otherwise (if 1LSB is used) the dither noise added would be modulated by the presence of signal.

Can you re-verify the dither is really implemented properly and has a Q of 2LSB, and so is not 'bit perfect'?

[Matt]

Sorry, but our dither is bit-perfect.  There are lots of ways to do a dither, and ours is chosen for strategic reasons.

[igorzep]

Sorry, but our dither is bit-perfect.  There are lots of ways to do a dither, and ours is chosen for strategic reasons.

There are a lots of ways to do dither, but not every way is a correct one. For TPDF dither there is only one correct amplitude - it is 2LSB. No other value is correct. What is the point of 64 bit processing if you destroy everything by not dithering it properly to the output resolution?

By the way, if you need a non-destructive dither for some reason (like passing AC-3 stream... but you should still detect it probably...) you should use RPDF of 1LSB, this can be an option if it causes failures somewhere. But for the sound quality (and especially when you know you don't output to external decoder) there is no excuse not to use the correct TPDF dither.

Here are some links where TPDF is discussed/explained
http://repforums.prosoundweb.com/index.php/topic,32821.msg486812.html#msg486812
http://bitperfectsound.com/?p=60

[andyc56]

There are a lots of ways to do dither, but not every way is a correct one. For TPDF dither there is only one correct amplitude - it is 2LSB. No other value is correct. What is the point of 64 bit processing if you destroy everything by not dithering it properly to the output resolution?

I agree completely.  Dither isn't a heuristic algorithm. The mathematics behind the 2LSB peak-to-peak triangular PDF dither were fleshed out by Wannamaker in his Ph.D dissertation on dither (PDF).

Edit: I should also mention that seeding a random number generator should be done only once, at initialization of the generator. Subsequent seeding is unnecessary and undesirable.

[mojave]

The TPDF should be 2LSB dither and so, it MUST not be bit perfect even if there are no 'in between' values in the source. Otherwise (if 1LSB is used) the dither noise added would be modulated by the presence of signal.

Can you re-verify the dither is really implemented properly and has a Q of 2LSB, and so is not 'bit perfect'?

Are you saying that a 24-bit signal expanded to 64-bit and then dropped back to 24-bit, with no processing in between, should no longer be the identical 24-bit signal? If so, do you think JRiver should modify all 16-bit and 24-bit sources even when JRiver does no processing. In other words, there should never be bit-perfect output?

[Hendrik]

Thats what it sounds like. I think there are different goals here

He wants to use dithering to improve the original signal (by smoothing out quant errors present in the source), while we view the goal of dithering to avoid introducing *new* quant errors due to a reduction in bitdepth after processing.

FWIW, if you use internal volume, or a volume reduction through volume leveling, you'll quite certainly already dither more than 1LSB, and achieve the wanted effect, since lowering the volume shifts the previous QE into the new dithering noise floor.

[igorzep]

Thats what it sounds like. I think there are different goals here

There is only one goal of TPDF dither - linearize the system (remove quantization distortion and replace it with noise).

He wants to use dithering to improve the original signal (by smoothing out quant errors present in the source)

Wrong again. Original signal cannot be improved. But any processing of the signal could be made linear. So, what I want is not distorted signal after the processing.

while we view the goal of dithering to avoid introducing *new* quant errors due to a reduction in bitdepth after processing.

You ARE introducing them in current design. If you do NO processing then yes, dithering could introduce something that is not originally present (the noise). And so - it is worth to turn if off when there is no processing. But if there ever slightest change to the original (be it volume, resampling, PEQ filter, convolution, tone control, loudness compensation, Bass Management, virtual surround, etc, etc...) - the correct 2LSB TPDF dither must be applied to avoid introducing of *new* quantization errors that is not an uncorrelated noise. The errors are there already - it is unavoidable fact, we just want to transform them to the form where they least harmful, we don't want both noise and distortion, we want just noise and nothing more.

FWIW, if you use internal volume, or a volume reduction through volume leveling, you'll quite certainly already dither more than 1LSB, and achieve the wanted effect, since lowering the volume shifts the previous QE into the new dithering noise floor.

You don't. The 1LSB is to the output bit-length, not to the source. It is not something that depend on the input, the amplitude is constant to the OUTPUT, and it must be 2LSB to the output.

[igorzep]

I should also mention that seeding a random number generator should be done only once, at initialization of the generator. Subsequent seeding is unnecessary and undesirable.

BTW, Bruno compiled a good 'checklist' of common mistakes done when implementing dither:
http://repforums.prosoundweb.com/index.php/topic,32821.msg486602.html#msg486602

Badly implemented dithers I've come across over the years:
*First truncating, then adding noise. (my edit: rounding is mathematically eq to truncating)
*A dither source with only one bit rattling (mathematically the same as above)
*TPDF dither with a user-controlled noise level setting (my edit: he means any other value than 2LSB)
*Gaussian dither or dither noise derived from analogue sources.
*Dither added before, not inside, a noise shaper
*Noise shaping with no dither.
*One noise source for more than one channel.

Any one of those can cause people to believe dither is unnecessary or counterproductive, and will cause them to damage the sound of many productions to come.

My concerns in relation to the JRiver (and so TPDF) are bolded. First probably is OK as Bob have been able to register at least some reduction of the distortion... Another one is definitely not.

I've some concerns about convolver also (but it is not necessary there are some problems, I just wonder why some people claim they hear some difference, there are things to broke there, and identity filter of [1, 0, 0, 0..] that Matt is using for testing would not detect them), but it is infinitely more complicated, so, let's start from solving simple things first. Then I'll ask some questions more.

[bobkatz]

I've been staying away from JRiver discussions for months while watching and cheering on Matt's health progress. I did not want to stress this wonderful gentleman! Likewise the same for these dither discussions. I have a bunch of technical measurements to submit, but for those with little patience let me summarize them in two sentences:

1) Whoever has been complaining about the theoretical performance has absolutely nothing to worry about. JRiver's dither on PC when set to 24 bits is absolutely perfect. Its performance is perfect, no artifacts at all. JRiver on PC performs better than many many professional pieces that I use day in and day out and whose distortion measures a bit but exhibit no audible artifacts. I do quarrel with Matt's insistence on "bit perfect dither" since this is a contradiction in terms. You can't add noise and remain bit perfect. But I'm perfectly happy to live with Matt's terminology as strictly speaking when no processing is applied the output is bit-perfectly identical to the input plus some noise. And when processing is applied, as this post will attest, no distortion is added to the output when it is truncated.

2) I cannot speak to, nor have I measured the Mac performance and I've been waiting for Matt's health to come back before asking him what happened to the "device uses upper 24 bits" option that's available in JRiver for PC under DSP options. I see that this option is missing, and Matt mentions Core audio wanting to get 32 bit float, but that is not necessary... many processors, including Pure Music, give us a dithering option to 24 bits so as to properly feed DACs, which as we know will truncate any information greater than 24 bits. And this is audible as a loss of depth, as my ears tell me.

Now for my measurements. You can skip the rest if you're not technically inclined. Instead of arguing over "1 LSB, 2 LSB, 0.5 LSB" or whatever, it is essential to measure. Many manufacturers have a slightly different way of specifying and randomizing their dithers. Some better than others. I now use a multitone test signal invented by the great Jim Johnston which I have implemented in 2444 and in 3244 stereo. It consists of about 40 carefully selected sine wave tones all the way up to near Nyquist. The ways in which these tones interact makes the test extremely subtle and capable of identifying the slightest aberration in distortion. I've performed randomization tests, independent dither on independent channel tests as well. And JRiver on PC comes out squeaky clean.

Attached are measurements performed with JJ's multitone test signal (also known as the "buzz" signal) and measured in Spectrafoo through an SPDIF input. For convenience I limit the display to 4 kHz. Notice that there are purposeful gaps in the buzz signal so that intermodulation distortions among high frequencies can be seen below 240 Hz and in the gap between 250 and 750 Hz.

1) Buzz attenuated 60 dB in Sequoia and either truncated to 24 bits (green) or dithered to 24 bits using Izotope Ozone's flat TPDF 24 bit dither (red). As you can see, Izotope's dither is absolutely perfect, there are no artifacts to be seen.

2) Dither amplitude comparison. JRiver's "24" dither in red, Izotope's dither in blue, playing the 3244 buzz signal, attenuated  and measured via a 24 bit spdif/AES output into Foo. JRiver is attenuating 95 dB and Sequoia is attenuating 60 dB. Notice that on the average, the amplitude of JRiver's dither is even slightly higher than Izotope's. Certainly we can agree that the amplitudes are comparable, and I am completely confident that Izotope has implemented its dither as 100% correct TPDF in amplitude and randomness. I never see any artifact of the buzz signal with either the JRiver or the Iztope.  

3) This is an example of a professional device whose dither or internal resolution performs poorer than JRiver's. Not naming names here. This is a monitor controller with a simple -34 dB attenuation when fed the 2444 buzz signal. Notice the distortion products are clearly visible.

4) Here is the buzz signal running JRiver as a convolver using the filters created in Accourate. The amount of calculations required to derive this filter are very complex, the attenuations are strong, and if there is going to be any problem in JRiver, it would be revealed using the convolver test. JRiver is attenuating the buzz signal 95 dB with its master volume control. In Red, the "device uses 24 bits" checkbox is checked in DSP options. In Green, the box is unchecked. At no time while kicking the tires was I ever able to see any distortion artifacts when JRiver was properly dithered. Nuff said!

Not shown...  a demonstration of how sensitive this measurement is... the slightest distortion of a device can be detected using the buzz signal. If anyone is interested in obtaining the buzz signal, contact me off list at bobkatz(atsign)digido.com

[igorzep]

I've been staying away from JRiver discussions for months while watching and cheering on Matt's health progress. I did not want to stress this wonderful gentleman! Likewise the same for these dither discussions.

I didn't know... All my wishes to him to heal soon!

But the product keep living, so, why not to talk about technical issues, especially this one is about just ONE number.  
And I hope Matt isn't alone behind the project. Isn't he?

I have a bunch of technical measurements to submit, but for those with little patience let me summarize them in two sentences:

Measurements are the truth But if you measure one thing and distortion is somewhere else... well it is just incomplete measurement. Sure, no measurements can be absolutely 'complete', but when we know what is the goal and what we are trying to find...

1) Whoever has been complaining about the theoretical performance has absolutely nothing to worry about.

According to your previous posts/measurements and according to the Matt's formulation there are still reasons to worry. At least there are two contradictory statements that cannot be true at the same time. As we have that it should be clarified. Either bit-perfect claim is not true, or they are not using correct TPDF dither amplitude (or are using something that is not TPDF at all). Or deliberately detecting lossless cases of processing and then turning off dither (but I doubt it, and from Matt's response the dithered signal end's up with no added noise).

JRiver's dither on PC when set to 24 bits is absolutely perfect.

Absolute perfect is TPDF 2LSB (see above). Any kind of 1LSB dither is not perfect (although it is possible RPDF won't be noticeable on the FFT graphs also, as long as you don't compare different / very small signals). The problem of 1LSB dither is noise modulation - the total amount of noise energy is dependent on the input signal (or lack of it).

Its performance is perfect, no artifacts at all.

Is the second graph you posted here: http://yabb.jriver.com/interact/index.php?topic=76912.msg526976#msg526976 not valid anymore? It clearly shows the distortion. And... What about the people with 16 bit converters...

JRiver on PC performs better than many many professional pieces

This was never an argument for me. If someone did a mistake it is not an excuse for anyone else to do the same.

I do quarrel with Matt's insistence on "bit perfect dither" since this is a contradiction in terms. You can't add noise and remain bit perfect.

This is what catched my attention also... The round-trip actually can be bit-perfect with RPDF if you do, for example 16bit->32bit->1RPDF->16bit, but even the no otherwise processed round-trip won't be bit-perfect for 2RPDF, which is the correct TPDF. There is contradiction, and I am trying to find where the truth is... If he is continuing insisting on lossless round-trip then it simply cannot be correct TPDF. I would like to know where the truth is in the current state of affairs and if there are problems - have them fixed (this is again - just ONE number).

But I'm perfectly happy to live with Matt's terminology as strictly speaking when no processing is applied the output is bit-perfectly identical to the input plus some noise.

I agree with you, but I doubt it is what Matt meant...

I've performed randomization tests, independent dither on independent channel tests as well. And JRiver on PC comes out squeaky clean.

I've seen your findings on this. Good job!

4) Here is the buzz signal running JRiver as a convolver using the filters created in Accourate.

Good to see that, and great if it working perfectly. My concerns are about applying circular convolution to the continuous signal, and so the need for some kind of overlap strategy (overlap-save/overlap-add methods). Testing this is tricky, and I am not sure FFT can catch the problem under all conditions. A simple yes/no answer here (if such strategy is used) would also help to at least know if it is worth to test it. From the way how the feature was communicated (and also tested for 'bit-perfectness') - I cannot be sure if there is full understanding of the process.

Not shown...  a demonstration of how sensitive this measurement is... the slightest distortion of a device can be detected using the buzz signal. If anyone is interested in obtaining the buzz signal, contact me off list at bobkatz(atsign)digido.com

Something that is very good at analyzing analog distortion is not always the best for investigating 'digital' problems. I don't expect too much modulation to the low frequency part of the spectra from (all) the dither imperfections.

[Hendrik]

I suggest you measure MCs output yourself, before this ends up in more days of wild speculations.

[igorzep]

I suggest you measure MCs output yourself, before this ends up in more days of wild speculations.

Why bother measuring if incorrectness is confirmed by the author (although it seems he has misconceptions about the dither and doesn't understand the problem)? To check something is correct first the author should confirm it is done correctly on his side. When he is confirming the reverse - it is not a speculation.

Also.
1) I am waiting my HTPC to arrive and so I don't have a way to measure.
2) I am not yet bought JRiver but I am considering it.
3) It is not quite normal that I as a customer (or potential customer) should check/test something... Especially the basic math (pretty standardized) done in the device/software. It is researched, mathematically proven, empirically verified for years already. The correct implementation of such things should be a given. But... well the reality is that I have to check all that... And I will. If author will show the desire to fix the problem instead of avoiding to do it because of the 'strategy'. Until then I see no courage to verify something if there is no chance for it to be solved.

[mojave]

He wants to use dithering to improve the original signal (by smoothing out quant errors present in the source)

Wrong again. Original signal cannot be improved. But any processing of the signal could be made linear. So, what I want is not distorted signal after the processing.

Matt's comment regarding bit-perfect is only applicable to a signal that has no processing. When there is processing, there is proper dither and no distortion as Bob Katz's measurements have shown. You seem to be overlooking this part of Matt's comment, "Dithering only changes values in between those whole values.  These in between values arise when performing any sort of processing, including volume." Matt is confirming correctness, not incorrectness.

If you haven't already, you might consider reading Bob Katz's book Mastering Audio:  The Art and Science.

My concerns are about applying circular convolution to the continuous signal

If you alias the linear convolution, the integer multiples will show that there is no distortion. Proper dither obviously results in non-zero values. If you delay replicas of the linear convolution you will get an identical result to circular convolution. If not, then you don't have non-zero values and the dither is incorrect.

[igorzep]

Matt's comment regarding bit-perfect is only applicable to a signal that has no processing.

He was commenting about the dither applied to the signal that has no other processing and explained it as his test for 'correctness' (while in reality it proves incorrectness), quite a difference to turning off the dither when we know there is no processing. And this must not be the case for proper TPDF audio dither. If he miscommunicated it, I am waiting a confirmation from first hands.

When there is processing, there is proper dither and no distortion as Bob Katz's measurements have shown.

I have referenced his measurement
It clearly shows the distortion. Also, proper TPDF dither must remove also noise modulation - this is something not visible on FFT plots, but can still be audible under some conditions (definitely it will be a real issue with 16 bit output, for 24 bit - who knows, but it is still worth to have the amplitude correct, if you combine headroom, EQ, gain matching, you can get close to the 24 bit resolution).

You seem to be overlooking this part of Matt's comment, "Dithering only changes values in between those whole values.  These in between values arise when performing any sort of processing, including volume." Matt is confirming correctness, not incorrectness.

I am not overlooking this part of the comment. This part is exactly the one, that confirms his misunderstanding. The correct TPDF dither CHANGE values that are NOT ONLY IN BETWEEN. If it doesn't then the noise amplitude depends on the input signal, and it is one of the artifacts that proper dither is supposed to suppress. It is supposed to make the error a white noise that is not audibly dependent on the input signal. If you (digitally) subtract the input signal from the output and reproduce it, it should sound as just noise that is not dependent on the input, so, it should be the same if there is digital silence (only exact zeroes in input) or if the full-amplitude signal is fed to the input, or anything in-between. This is impossible to accomplish with 1LSB ('bit-perfect') dither and TPDF dither of 2LSB is the one that accomplish this while adding least possible amount of (white) noise. This is formally proven as was referenced here in the thread.

If you haven't already, you might consider reading Bob Katz's book Mastering Audio:  The Art and Science.

If you haven't already, you might consider to re-read the links already posted in this thread by me and others:
Ph.D dissertation on dither (PDF)
Bruno Putzeys's (the designer of best in the world ADC/DAC converters, and class D amps) explanation of dither
BitPerfect Sound explanation of TPDF dither with some convincing graphical explanation of correct and incorrect amplitudes

If you alias the linear convolution

It is a different issue (or probably non-issue, just a concern about convolver feature). Should be discussed separately, it has nothing to do with dither.

[6233638]

BitPerfect Sound explanation of TPDF dither with some convincing graphical explanation of correct and incorrect amplitudes

 
For the ~3dB it seems to cost, it seems like a switch from 1LSB to 2LSB would be worthwhile, if that's what Media Center is currently using.

[bobkatz]

Igor, please don't quote one of my measurements that's so old it's starting to grow hairs without qualifying it and telling us what it is a measurement of. That's an old post I made from early 2013. I don't even know what it's measuring without studying in context. The new post I made just yesterday with the buzz signal clearly shows perfect performance from JRiver on the PC. Do you understand the meaning of "perfect"? As was previously posted today, if you have doubts, take some measurements of your own and stop speculating. If you spot any smoking guns, let us know.

As for amplitude of the dither, it's too complicated math to convert the measured amplitude of a random multi-bin FFT measurement of dither amplitude into number of LSBs, but certainly it is possible to compare the FFT measurement of the amplitude of the JRiver dither to that of the Izotope. We observe that it is AT LEAST as high in amplitude as Izotope's dither. And since Izotope's dither is properly done, we can assert that since JRiver's is even slightly higher amplitude (less than 0.25 dB I estimate) in terms of amplitude it must be enough to prevent distortion.

If you want to be helpful, see if you can devise a measurement to determine if JRiver's dither is random enough to prevent noise modulation. I wager it is. Everything looks (and sounds) very kosher from here.

Please stop worrying about it and just use it.... JRiver's dither measures perfect. The test signal which I'm using is designed to test digital systems... I don't know where you got the idea it was made for analog measurements. I rarely see distortion measurements of digital systems as perfect as what I got from the JRiver.

As for the "bit perfect" argument, it's purely a semantic quibble I may have with Matt's terminology. I don't care if Matt is on Venus and I'm on Mars as long as his dither performs correctly from the point of view of distortion removal. And it does. From the bit-perfect point of view, only on a statistical basis can a signal plus added noise be bit-perfect. And statistically, JRiver is 100% bit perfect. I've also done some tests (long ago) by subtracting the original signal and all that remains is the noise of the dither. Which = bit-perfect in my book. This can only be done with gain at unity and no processing (no multiplications), of course.

[Matt]

Please stop worrying about it and just use it.... JRiver's dither measures perfect. The test signal which I'm using is designed to test digital systems... I don't know where you got the idea it was made for analog measurements. I rarely see distortion measurements of digital systems as perfect as what I got from the JRiver.

As for the "bit perfect" argument, it's purely a semantic quibble I may have with Matt's terminology. I don't care if Matt is on Venus and I'm on Mars as long as his dither performs correctly from the point of view of distortion removal. And it does. From the bit-perfect point of view, only on a statistical basis can a signal plus added noise be bit-perfect. And statistically, JRiver is 100% bit perfect. I've also done some tests (long ago) by subtracting the original signal and all that remains is the noise of the dither. Which = bit-perfect in my book. This can only be done with gain at unity and no processing (no multiplications), of course.

Thanks Bob.

[bobkatz]

Matt, would you mind starting a discussion about the implementation of dither in the Mac side? Should we switch to JRiver Mac? Are you involved in the Mac development?

[Hendrik]

Dithering is a central function, its implemented the same on any OS. If you output a lower bitdepth than the internal format (and noone outputs 64-bit float), then it'll dither to that.

[bobkatz]

Dithering is a central function, its implemented the same on any OS. If you output a lower bitdepth than the internal format (and noone outputs 64-bit float), then it'll dither to that.

Where do I set the output bit depth on the Mac Side? On the PC side 24 bit is available in the DSP options. In a similar place on the Mac I can set "integer mode" but where do I set the bit depth (word length)?

[Matt]

Where do I set the output bit depth on the Mac Side? On the PC side 24 bit is available in the DSP options. In a similar place on the Mac I can set "integer mode" but where do I set the bit depth (word length)?

It's automatically selected based on your output hardware.  Most are 24-bit integer (in integer mode), but it varies.  There's no need to do anything.

You can check Audio Path while it's playing to see.

[gappie]

yesterday evening, mister igorzep, i tried to read your phd study ( i really did   ).. i did not get all the maths, but the introduction and the conclusions were clear... its a great theoretical thesis. what intrigues me, is how you went into a discussion in such a non-scientific way, more like some hardcore preacher.

but practically, speaking as someone with a Phd ( ) in theoretical biology, and a trying to survive musician, im happy with the measurements from mister bobkatz (and with matt, he really knows what he is doing   )... we are still good  

 
gab

[bobkatz]

Bob, Voxengo's Elephant allows you to process 8 channels and it will dither to 24 bit. You can download and test for free. I would be curious if, with ASIO output, what happens when it dithers in the DSP chain. The dithered signal should be the same even though JRiver converts to 64-bit and then 32-bit for output.

Hi, Mojave. I own Elephant. I actually bought it at a time before JRiver was capable of doing 24-bit dither and did use it in 8 channels in JRiver as my dithering engine. You could still use it to dither to 24 bits in JRiver by UNCHECKING the "device uses 24 bit" box in JRiver. I did test Elephant's place in the chain and it comes after all JRiver processing including volume which is where you would want it.

But I abandoned Elephant once Matt got the action going. At this point I need to do tests of JRiver Mac to see how it does in Integer mode. It's promising. A bit terrifying only because there is no explicit directive for the output wordlength in integer mode. Preliminary tests I just did reveal that integer mode does output 24 bits fixed... maybe that's all we have to worry about.

[mojave]

Hi, Mojave. I own Elephant. I actually bought it at a time before JRiver was capable of doing 24-bit dither and did use it in 8 channels in JRiver as my dithering engine.

Bob, you are quoting me from January 25, 2013. I believe you started using Elephant because I recommended it back then.  

You replied,

Thanks for that, Mojave. I'll check Elephant right away.

[bobkatz]

Well I'll be a monkey's uncle, Mojave. You deserve credit for turning me on to Elephant (however briefly).

Anyway, to go back to the subject of dither, for me the case is closed on the PC side but now I have to get into a discussion (perhaps with Matt) on the Mac side. I thought there was such a discussion on integer mode, on the Mac side, but I don't see it so I'm going to start a discussion over there. I do see some problems and I'm going to lobby for an explicit "24 bit" checkbox in JRiver on the Mac side as well. See you over there!!!!!!!!

[6233638]

I'm not sure that Media Center's TPDF implementation is correct.
It's amplified, but you can probably guess which of these is Media Center.
I recommend listening to the full samples, in order.
 
https://www.sendspace.com/file/3mdbe9

[andyc56]

I'm not sure that Media Center's TPDF implementation is correct.
It's amplified, but you can probably guess which of these is Media Center.
I recommend listening to the full samples, in order.
 
https://www.sendspace.com/file/3mdbe9

Thanks for that!  Sample 2 has obvious noise modulation.  Which is JRiver?

[6233638]

Thanks for that!  Sample 2 has obvious noise modulation.  Which is JRiver?

Sample 1 is iZotope’s TPDF dither.
Sample 2 is Media Center.

This seems related to the 2LSB discussion recently.

https://www.sendspace.com/file/3mdbe9
 
Sample 1 is iZotope's TPDF dither.
Sample 2 is Media Center's dither.
 
 
Samples were created by performing a large gain reduction (-50dB) and exporting a 16-bit file, which pushes the signal into the lower bits. The conversion tool was used for this in Media Center.
Both files were then amplified to the maximum volume possible without clipping in Audacity. (about +60dB)

[Matt]

I'm quoting Bob Katz again, because there's a little bit of FUD being spread.  Bob literally wrote the book on studio engineering.  He says we're "perfect."

Please stop worrying about it and just use it.... JRiver's dither measures perfect. The test signal which I'm using is designed to test digital systems... I don't know where you got the idea it was made for analog measurements. I rarely see distortion measurements of digital systems as perfect as what I got from the JRiver.

As for the "bit perfect" argument, it's purely a semantic quibble I may have with Matt's terminology. I don't care if Matt is on Venus and I'm on Mars as long as his dither performs correctly from the point of view of distortion removal. And it does. From the bit-perfect point of view, only on a statistical basis can a signal plus added noise be bit-perfect. And statistically, JRiver is 100% bit perfect. I've also done some tests (long ago) by subtracting the original signal and all that remains is the noise of the dither. Which = bit-perfect in my book. This can only be done with gain at unity and no processing (no multiplications), of course.

[6233638]

I'm quoting Bob again, because there's a little bit of FUD being spread.  Bob literally wrote the book on studio engineering.  He says we're "perfect."

Please listen to the samples.

[mojave]

Samples were created by performing a large gain reduction (-50dB) and exporting a 16-bit file, which pushes the signal into the lower bits. The conversion tool was used for this in Media Center.
Both files were then amplified to the maximum volume possible without clipping in Audacity. (about +60dB)

Did you use the bitdepth DSP in JRiver when creating the files? Audacity uses 32 bit float when performing any changes to the audio. It will then apply its own dither to the final output when reducing back to the file's native bitdepth. Amplifying to maximum volume in Audacity invalidates the test, IMO.

Any listening to the files with volume correction will involve re-dithering. If someone listens to the files and isn't using JRiver's internal volume, then who knows how it is being dithered. With JRiver's internal volume control, it will still be dithered again. So, the final listening involves either dithering or truncation when file was reduced by 50 dB depending on settings used in Convert Format, dithering by Audacity when the file was increased by 60 dB, and then dithered a third time during playback when listening.

With that said, sample 2 sounded better to me. I then analyzed the file in JRiver. Sample 2 is .3 dB quieter for Volume Level R128. Also the Dynamic Range (R128) is .9 dB higher than Sample 1. I think this means the dither noise has been pushed lower in Sample 2.

When the dither noise is at around -190 dB per Bob Katz's measurements, I'm not sure the difference in how it might sound when amplified has any bearing on real life.

I took a file, reduced it by 50 dB and dithered to 16 bit using JRiver's DSP. I then played the file back with +50 dB in DSP Studio. There was no audible noise when played back at normal listening levels.

[6233638]

Did you use the bitdepth DSP in JRiver when creating the files? Audacity uses 32 bit float when performing any changes to the audio. It will then apply its own dither to the final output when reducing back to the file's native bitdepth. Amplifying to maximum volume in Audacity invalidates the test, IMO.

I applied a -50dB volume adjustment via the Parametric EQ DSP.
Bit-depth was set to 16-bit in the conversion options. (not the bit-depth simulator DSP)
 
In iZotope RX3 I simply applied a gain of -50dB, and exported as a 16-bit file using TPDF dither.
 
I chose a -50dB adjustment since it pushes the audio from this track into the lower ~6-bits of a 16-bit file. (the peaks were approximately -10dB)


Both files were then opened in Audacity and had ~60dB gain applied.
Audacity's dither is not relevant here, since dither only applies to the lower bits, and after amplification the audio is now using the highest bits.
I could do the amplification using iZotope instead, but chose Audacity to keep things impartial.

With that said, sample 2 sounded better to me.

Listen to the full samples. There is obvious distortion and noise modulation in Sample 2.
Headphones may help.

I then analyzed the file in JRiver. Sample 2 is .3 dB quieter for Volume Level R128. Also the Dynamic Range (R128) is .9 dB higher than Sample 1. I think this means the dither noise has been pushed lower in Sample 2.

Sample 1 should have ~3dB more noise than Sample 2 if Media Center is using 1LSB and iZotope is using 2LSB.
 
The volume differences are my fault for letting Audacity just maximize the gain without clipping.
It's really not relevant though, because we are not comparing noise levels. We are listening for distortion.
I could recreate the files using exactly +60dB for both, but it wouldn't make a difference.
 

When the dither noise is at around -190 dB per Bob Katz's measurements, I'm not sure the difference in how it might sound when amplified has any bearing on real life.

Well it must be 60dB down (rather than 190dB) since I amplified the signal by ~60dB.
 
For what it's worth, I did suspect that there was some noise modulation when listening to certain tracks, though I was concerned that something else might have been the cause, and this just confirms it.
 
And yes, 24-bit should be a lot better but I have some devices which only handle 16-bit audio and do use quite a large volume reduction via Media Center - not quite 60dB, but maybe 40dB or so. I know it's not ideal, but that's just how things have to be.

I took a file, reduced it by 50 dB and dithered to 16 bit using JRiver's DSP. I then played the file back with +50 dB in DSP Studio. There was no audible noise when played back at normal listening levels.

Again, be sure that you are converting to a 16-bit file. The track that you use may matter as well, it just happened to be rather obvious with solo piano like this.
It's unlikely to be an issue whatsoever with 24-bit playback, since a loss of ~10-bits (60dB) still leaves you with 14 rather than 6.
 
That said, DAC chip manufacturers like ESS have claimed that noise floor modulation is something that we can detect, even at levels which should be "inaudible" below the music.
The same argument is used with DSD vs PCM, since DSD has a variable noise floor and PCM should have a flat noise floor.

[bobkatz]

I can't speak for the file-making or exporting portion of JRiver. I've never used that facility as it's not always transparent what operations are being performed. I have a special test signal for judging noise modulation and I'll check out JRiver on PC at 24 bit and let you know. Keep in mind that 24 bit dither is so low in level that any noise modulation from moderately-incorrect dither might be inaudible below the noise of the DAC.

However, in my quiet room, with the monitor gain turned up about 12 dB, I am able to hear a 1 kHZ -140 dBFS test tone played back in JRiver with and without JRiver's dither. The distortion without dither is quite audible, and the pure tone with the dither is also detectable. But noise modulation...  at 24 bits that's asking for a lot more resolution than may be audible. But if the noise modulation is audible when the gain is turned up, I'll let you know!

As for 16-bit, I do not know if JRiver on PC is even equipped to do that properly when using the export facility the O.P. mentioned. I'd have to ask Matt.

[Matt]

The samples sound different, but one isn't clearly better.  However, it's a false test because it's inflating inaudible noise by a huge amount.  In real life, the noise is below the threshold of hearing.