As a 64-bit engine, JRiver should not simply trucate to 24-bit on its way to a 24-bit DAC, for example. So, let's ask, does JRiver perform any dithering?
Hi Bob, welcome to Interact. I received the Master Handbook of Acoustics for Christmas and your Mastering Audio book is next on my list. I see that in your book you have measurements that show the difference between dither and truncation. Perhaps these would help the discussion.
If you want to measure these kind of effects with your computer, see my post here:But if you can't choose between dither or truncate with JRiver, then you can't measure the difference.
http://yabb.jriver.com/interact/index.php?topic=76525.0 (http://yabb.jriver.com/interact/index.php?topic=76525.0)
Bob,
Thanks for your contribution. Matt needed a hobby.
BTW, we prefer our name to be written as JRiver since it's friendlier to search.
Jim
Hey, wait a minute? Did you know that all current Lame and Fraunhofer and Apple AAC and MP3 decoders run internally at 32-bit floating point?
Can we hear truncation at 24 bits (versus dithering)? I can --- on a good day I can pass a blind test on it, with the right musical material. Is it a hard test to pass? YES IT IS! It is the hardest and probably one of the most subtle differences that you will ever be asked to hear or judge. Does this mean that it's insignificant? I like to think that any sonic difference which some small percentage of the population can hear is significant. At least it should be important to an audio engine as critical and designed for critical listeners as JRiver is. It's not a big deal to take an engine which already properly dithers to 16-bit and extend it to 24-bit, so I think it should be done, and then give the users the opportunity to choose truncation or dithering and decide for themselves. Or, better yet, leave dithering on and just enjoy. You won't hear the noise (24-bit dither is at -141 dBFS RMS!) but you will hear a reduction of artifacts, if your system is good enough to reproduce them.
By the way, is the JRiver dither uncorrelated between channels?
i like the topic.... and how quickly it got added in mc.. gottotest :)
It's good to be named Bob Katz. :o ;D;D i did not get this the first time. but now i realize that i have a book of him here at home. and i even red it. :) interesting stuff.
This is now public in 18.0.106:
http://yabb.jriver.com/interact/index.php?topic=76981.0
Next build:
NEW: Added the output bitdepth '24-bit (with dithering)' to DSP Studio > Output Format.
NEW: Dithering of bitdepth conversion is optional with ASIO in Options > Audio Output mode settings. (dithering has no effect / is bit-perfect until you make signal changes like volume or other DSP).
Changed: The 'Bitdepth simulator' in parametric equalizer exposes optional dithering.
It's possible we could always dither bitdepth down-conversion and not bother to make it optional. We may end up there someday, but I feel more comfortable with a judicious approach that allows users to opt in for the time being.
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.
2. If you are passing the bits from the music file unchanged ('bit perfect'), then you don't want dither to change any bits. Even if you are extending 16 bit content to 24 bits with zero insertion, you don't want dither.
If you are running ASIO, does it ignore the 24 bit dithering setting in DSP Studio > Output Format? ?
The Steinberg (MR816x and UR824) and Echo (AudioFire 8 ) pro devices I have tried only allow up to 5.1 output with WASAPI or WASAPI Event Style. ASIO is required to get 7.1 output.
What does "dither bitdepth conversions" do in the ASIO Output Mode Settings? Is it dithering at 32 bits? My output in JRiver with the MR816x shows "44.1kHz 32bit 8ch using ASIO."
3) Do NOT use ASIO. It doesn't dither, because at this time, JRiver always talks to ASIO at 32-bit, and so apparently there is no way to tell JRiver to dither to 24 bits.
Running an ASIO application and bit-depth says 32-bit in Lynx Mixer despite project bit-depth.
All OS
This is normal. ASIO requires a 32-bit “highway” to be open for the audio device, despite the project resolution. This does not mean that files recorded with a project bit-depth of less than 32 bits will consume the disk space or resources of a 32-bit recording.
Does anyone have information about the ASIO call that sets the buffer format the driver will use?
Or does there need to be an ASIO option like "Assume hardware only uses 24-bits"?
Is there a double conversion with ASIO output -to 32 bit int from JRiver to ASIO, 32 to 24 bit in driver (dithering driver/vendor dependent)? In RME link, they mention they strip off the lower 8 bits to make 24 bits - is this the standard for other ASIO implementations?
Does anyone have information about the ASIO call that sets the buffer format the driver will use?
Or does there need to be an ASIO option like "Assume hardware only uses 24-bits"?
Bob, Voxengo's Elephant (http://www.voxengo.com/product/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.
So yes, an ASIO option like "Assume hardware only uses 24-bits" would be GREAT! It would allow JRiver to dither down the 64bit fp data to 24bit int in a proper way and "put that into an 32bit fp container" to comply with the ASIO driver. In my understanding this 32bit fp data is converted to 24bit int.
So please consider an ASIO option like "Assume hardware only uses 24-bits" - it would allow proper dithering AND using ASIO. Thank you!
Our driver requests 32-bit since that is the most efficient to transfer over
the bus. If you look at the ASIO documentation for ASIOSTInt32LSB, you will
find:
"This format should also be used for 24 bit data, if the sample data is left
aligned. Lowest 8 bit should be reset or dithered whatever the
hardware/software provides."
ASIO never defined an active number of bits for 32-bit left-aligned data.
It does have ASIOSTInt32LSB24 but that is for right-aligned data and not
appropriate for our device.
The data is left aligned, so the LSB should be zero since it will be ignored
and the least significant bit(s) should be dithered by the software. We are
not going to dither anything in the ASIO case since no bit reduction is
being applied to either recording or playback in our hardware (the driver
never touches the audio data).
So from our side it might be reasonable to add an ASIO option like 'DAC
uses only most significant 24-bits'.
When that's enabled, we would zero out the least significant 8 bits and
dither the 24th bit.
When that's disabled, we would dither the 32nd bit.
I got a really nice response on this topic from David A. Hoatson, the co-founder of Lynx.
Here's what he had to say:
I replied:
Thoughts? Bob Katz, would you be willing to test the option if we were to add it?
The Lynx people (and the RME people) are very together. The one interesting thing is that David mentioned Integer rather than floating point communication, but I think if (hopefully) JRiver is going to be able to "assume DAC (or driver) wants 24 bits" and dither accordingly, then I will be pleased as punch to test it thoroughly! I "wasted" about $150 on Voxengo Elephant, but it's not a waste, I can use it in my other work. :-).
I wonder if a bitdepth option should also be added to Parametric Equalizer?
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 :)
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.
how does the "show unread posts since your last visit" work?
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).
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).
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.
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(...) (http://msdn.microsoft.com/en-us/library/windows/desktop/ms724408(v=vs.85).aspx), and that didn't change in this case.
Good detective work catching this. It will be fixed next build.
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?
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.
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?
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.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?
Can you re-verify the dither is really implemented properly and has a Q of 2LSB, and so is not 'bit perfect'?
Thats what it sounds like. I think there are different goals hereThere 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.
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.
Badly implemented dithers I've come across over the years: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.
*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.
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!
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 (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 piecesThis 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.comSomething 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.
I suggest you measure MCs output yourself, before this ends up in more days of wild speculations. :)
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.
My concerns are about applying circular convolution to the continuous signalIf 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.
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 (http://yabb.jriver.com/interact/index.php?action=dlattach;topic=76912.0;attach=7361;image)
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:
If you alias the linear convolutionIt 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.
BitPerfect Sound explanation of TPDF dither with some convincing graphical explanation of correct and incorrect amplitudes (http://bitperfectsound.com/?p=60)(http://bitperfectsound.com/wp-content/uploads/2013/09/Zoom-Combo.png)
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.
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)?
Bob, Voxengo's Elephant (http://www.voxengo.com/product/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.Bob, you are quoting me from January 25, 2013. I believe you started using Elephant because I recommended it back then. ;)
Thanks for that, Mojave. I'll check Elephant right away.
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 (https://www.sendspace.com/file/3mdbe9)
Thanks for that! Sample 2 has obvious noise modulation. Which is JRiver?Sample 1 is iZotope’s TPDF dither.
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.
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.
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.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.
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.I applied a -50dB volume adjustment via the Parametric EQ DSP.
With that said, sample 2 sounded better to me.Listen to the full samples. There is obvious distortion and noise modulation in Sample 2.
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.
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.
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.
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.If you are using WASAPI you can specify the output bit-depth in the device properties. It's not an option for ASIO.
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.60dB is not a "false test" since I have a 16-bit device which uses volume close to that level of reduction, as I have been using MC for volume control rather than the device.
I listened with Matt to the samples and both had some audible hiss. Neither seemed better or worse.OK, here is around 1 second of audio taken from the same point in both tracks, each repeated for about 10s:
We don't think the test is valid.
Our threshold of hearing is said to be about 20 bits, so dither in the lower 6-bits of a 16-bit device should be audible. Quiet, but audible.
60dB is not a "false test" since I have a 16-bit device which uses volume close to that level of reduction, as I have been using MC for volume control rather than the device.
The default level with Volume Protection enabled is -40dB which is approaching this.
I just wanted to say that the responses here are disappointing.
Please let's first make sure you were testing the exact same thing I was testing! My test was confined to using the "device uses 24 bit" checkbox, which is definitely dithered, and I believe also properly dithered. I cannot speak for any other options in JRiver, and frankly I wouldn't even bother with any other options since JRiver is a media player designed to feed a high quality DAC which accepts 24 bit words.24-bit comparison (https://www.sendspace.com/file/qbu0dz) - sorry for the size, I uploaded the full tracks by mistake.
Please check that option out and then report back here. Thanks,
BK
We have gone from "our dither is perfect" to "we can't hear a difference, and don't think it's a valid test"
While you don't work for JRiver mwillems, I'm saddened that your response is "here are the reasons why you couldn't possibly hear this"
It's possible that the converter processes files differently from playback, but that seems unlikely?
That's a possible explanation. Have you tried reducing the volume drastically in JRiver (i.e. -60dB) in real time with a 16-bit output, and then turning up the gain on your amp? Maybe use a spare pair of earbuds if you have a high-powered headphone amp around? If you can hear the same dither noise/modulation under those circumstances, we can rule out conversion as the issue. I may try the test myself next time I'm next to my O2; I'm pretty sure it can provide enough volume into a set of earbuds to test the hypothesis.I could probably get around to this at the weekend, but my DAC has to be opened up to change the gain on the headphone output, so it's kind of a pain. (it's currently at -20dB)
I could probably get around to this at the weekend, but my DAC has to be opened up to change the gain on the headphone output, so it's kind of a pain. (it's currently at -20dB)
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!
I'll be next to an amp tomorrow that should (in theory anyway) be able to push the bottom of a 96dB dither up high enough to hear in headphones. It should at least do the trick for an unscientific test. If I can steal a half hour, I'll give it a try and report back. Bob had mentioned above he had tried something similar with the 24-bit ditherI won't deny that it will be difficult to hear - and I expect that it would be very difficult to hear anything that Media Center is doing when sending 24-bit to the DAC, as the DAC's own noise floor is probably higher.
I won't deny that it will be difficult to hear - and I expect that it would be very difficult to hear anything that Media Center is doing when sending 24-bit to the DAC, as the DAC's own noise floor is probably higher.
But most people (Bob included) seem to agree that dithering the signal correctly is important, and I think it's important enough that doing it correctly should matter, whether you believe it will be audible or not.
And while most hardware is 24-bit now, not all hardware is, and in some situations you will have a lot of amplification and digital attenuation.
I will also add that I tried the same comparison using iZotope's MBIT+ dither rather than TPDF and it makes quite a difference. Perceptually, it sounds a lot nicer than TPDF.
Now I'm not asking JRiver to license it as some people have, because I think that properly implemented TPDF is sufficient when you consider how low the noise floor should be with a 24-bit DAC, but I do at least understand why it's a big deal to some people now.
Simulating lower bitdepths (14 in particular) I did hear noticeable distortion as the dither became louder than some of the softer parts of the music, but the tone of the dither definitely sounded just like white noise to me (unlike the MC clips above), although it did vary in volume as the program material peaked and troughed (suggesting some modulation). Trying lower bitdepths (like 12 or 13) more or less obliterated the music such that it was hard to assess whether I was hearing modulation or just that half the music was missing, although there did seem to be some modulation going on.I had avoided the bit-depth simulator because it was suggested that it may be different from playback, but both the simulator and conversion show similar results.
However, an interesting result was what the 14 bit simulation sounded like with dither turned off. To my ear, it sounded particularly similar to the MC dither clips included above. That makes me suspect that Media Center may not be dithering on conversion, and what we're hearing may just be the distortion produced by simple truncation.It's definitely performing dither on conversion - things would be far worse without any - it's just not dithering correctly.
Thanks for taking the time to test it.
Since my DAC2 has a lot more gain than the ODAC, and I have some very sensitive (and isolating) headphones, after reading your results I ended up opening it and changed the gain on the headphone outputs.
With the 20dB attenuation removed from the headphone outputs, this distortion is clearly audible on playback when outputting a 16-bit signal at low volume levels in Media Center.
So it confirms that this is not just an issue with the converter or bit-depth simulator, but Media Center's dithering in general.
There is no reason to believe that it would be any different when outputting a 24-bit signal, it just buries the problem lower down and makes it more difficult to hear.
I had avoided the bit-depth simulator because it was suggested that it may be different from playback, but both the simulator and conversion show similar results.
To be equivalent to -60dB at 16-bit, you would set the simulator to 6-bit (60dB = 10-bit) and listen at normal levels.
With properly implemented TPDF dither, as you decrease the bit-depth all you should hear is louder and louder white noise. It should not be introducing this type of distortion.
It's definitely performing dither on conversion - things would be far worse without any - it's just not dithering correctly.
Reducing the bit-depth without dither at all will introduce similar distortion much sooner.
Sample 1 is iZotope’s TPDF dither.
Sample 2 is Media Center. (ftp://Sample 2 is Media Center.)
This seems related to the 2LSB discussion recently (http://yabb.jriver.com/interact/index.php?topic=76912.msg631071#msg631071).
https://www.sendspace.com/file/3mdbe9 (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)
There is only one section of JRiver PC that produces a properly dithered output to my knowledge, and that is the DSP/options section where you can check the 24-bit checkbox when using ASIO.
You may have found a "defective" area of JRiver, but I would never use MC this way, I wouldn't recommend it to anyone. I would never trust a reduction in JRiver to produce a shorter wordlength file unless they make an explicit claim that method is properly dithered. Where does JRiver make that claim?To quote Matt:
There is only one section of JRiver PC that produces a properly dithered output to my knowledge, and that is the DSP/options section where you can check the 24-bit checkbox when using ASIO.If it's dithering correctly there, that should be applied to the rest of the program.
And as you already should know by now, I've tested, retested and listened.... and rest quite satisfied that this section of the program produces an adequate level of dither. I haven't tested for noise modulation, but I have never heard any, and the depth is excellent.If you are only using 24-bit then it does not surprise me if you haven't heard noise modulation - especially if you are using speakers, because your DAC or amplifier's noise floor is likely above that of the signal and masking it.
It sounds as good as sending a 64-bit float signal via Acourate ASIO to Acourate convolver doing Acourate dither, which I also tested and went over with Uli Brueggemann for months until I was satisfied! Please read my post Reply #74, Sept. 16, with the buzz measurements. With measurements that good, things can't be very broken! Please respond to that message. If you have a scientific measurement that refutes these, by all means show it. 24-bit dither checkbox in ASIO in the DSP options section.Consider that it may pass one test and fail another.
As to whether JRiver's 24-bit dither is sufficiently random (true TPDF) it's highly likely given the buzz test and other tests I have made.I don't believe that it's a "randomness" problem.
Who would need or desire to use River to produce a 16-bit output? Please tell me when you would need it.
With that in mind, is there a reason for JRiver to allow 16-bit output? If other methods or usage are invalid/erroneous, why not make JRiver error-proof?Well for one thing, a lot of hardware is 16-bit.
1) Define the real areas where actual users of Media Center would gain performance by Matt spending his valuable time improving the dithering to 16 bit. Personally, as a user of Media Center who plays music in one room over high quality DACs, I'm not interested in any other area of the program. But if you need to lobby for better performance for real users, then by all means go for it! However, I do think the methods and tools you had available to analyze performance were not completely adequate and personally I would have to make my own tests using better tools to be personally satisfied that your claims are valid. I'm not saying your claims are invalid, just that you have not supplied properly-gathered evidence of the problem, only a smoking gun as it were.Well the AirPlay receivers I have in use, and the DLNA speakers that I tried recently were all 16-bit devices.
2) Horses for courses. When it comes to preparing and outputting audio files, MC is a Shetland Pony in a field of Thoroughbreds. And rightly so, as a $40.00 application, it's amazingly full-featured and very high quality. But it is not a DAW, and it cannot compete with the several hundred-dollar to mult-thousand-dollar DAW applications which can edit, show waveforms, selectively dither only when necessary --- under the direction of the professional audio engineer, conveniently process, assemble, mix, etc.To be clear, I am not expecting MC to be a DAW.
I don't think that trying to turn MC into a DAW would be a useful, practical, or business-worthy endeavor for JRiver to do.
If you truly think that MC needs to properly apply dither in certain areas, then please define those areas and how real users of the application need this performance and we'll continue the discussion. If you can please give the menu items and choices which you have in question in my copious free time I'll try to do tests on them. Or maybe someone else who's equipped can do so because this is a very busy month for me! (Sorry)
Well the AirPlay receivers I have in use, and the DLNA speakers that I tried recently were all 16-bit devices.
Since I have now been able to compare Media Center's 16-bit output on playback, the files produced when converting to 16/24-bit, and the bit-depth simulator, I don't believe that there are different dither implementations used in each part of the program.
I'm used to seeing truncated routines that should never be used for judgments, and I suspect the bit-depth simulator is one of them.
So, please tell us exactly what method you are using to reduce the wordlength.Selecting 16-bit in the WASAPI Device Settings.
Doubting Thomas, eh? I suspect that whatever method you are using is not dithered at all, just truncated. We can lay the blame on MC if you wish, but you have not provided evidence to point to a defect in the ASIO-24 bit output. I spent a good deal of time and Matt as well, making sure that portion of the program is properly dithered.I have repeatedly stated that I have not tested the 24-bit ASIO output, nor do I have things set up in a way which would allow me to.
I believe the bit-depth simulator is truncated. Bad design, but I just ignored it and never use it. Don't recommend it. It's just a throw-in part of the program as far as I'm concerned. You're using bad tools to make your judgments. You need better tools. Again, you could put the blame on MC, but I'm used to seeing truncated routines that should never be used for judgments, and I suspect the bit-depth simulator is one of them.Well there's an option to enable/disable dither in the simulator. Still, I had been avoiding it in my initial testing specifically because it may not be doing things correctly.
When you Convert Audio, you can use either the bit-depth simulator with the dither box checked or you can use the Bitdepth option at the bottom of the Convert Audio options. I would assume the Bitdepth option applies dither similar to ASIO output, but I'm not sure.I used the bit-depth option for conversion, not the simulator when testing converted files.
To quote Matt:“[…] our dither is bit-perfect. There are lots of ways to do a dither, and ours is chosen for strategic reasons.”
Therefore, the concepts of "bit-perfect dither" and "dither that eliminates noise modulation" are mutually exclusive. If you have "bit-perfect dither", you will have noise modulation.I'd rather the dither be correct rather than "bit-perfect"
That's an interesting quote, and I was baffled by it at first. But then I thought about it some more, and came up with the following.
Rounding of a double "x" to an integer "y" is usually done with a simple routine something like this:
y = floor(x + 0.5)
Where "floor(u)" is "the greatest integer that's less than or equal to u (http://msdn.microsoft.com/en-us/library/x39715t6.aspx)".
Let's look at this operation for x = 7.49 and x = 7.50
floor(7.49 + 0.5) = floor(7.99) = 7
floor(7.50 + 0.5) = floor(8.00) = 8
So that's rounding in the usual way we think of it. With dither, we add a value "d" to x before doing the rounding operation. The d value comes from a random number generator and has an average value of 0. So now:
y = floor(x + d + 0.5)
Suppose x represents an integer that's been converted to a double directly with no processing at all (no attenuation). We'd like to find the range of allowable values for d such that y = x whenever x has an integer value. This would be "bit-perfect dither". We find that:
-0.5 <= d < 0.5
That is, in order to have "bit-perfect dither" by this definition, the dither values must be restricted to plus or minus one-half an LSB. But we know from Wannamaker's thesis that the simplest dither that prevents noise modulation is triangular PDF dither with a value of 2 LSB peak-to-peak, or
-1.0 <= d < 1.0
Therefore, the concepts of "bit-perfect dither" and "dither that eliminates noise modulation" are mutually exclusive. If you have "bit-perfect dither", you will have noise modulation.
However, from a statistical point of view, the source is matched, so MC IS bit-transparent, because the average will remain the same. If you subtract the dither noise from the result you will get exactly the original bits. So their language is a bit of marketing speak, because it's not entirely accurate strictly speaking.
Any dither with zero mean is bit-perfect in the average sense, so that's not saying much.
So I think part of what JRiver is trying to say is that MC employs accurate, high resolution calculations, which preserves the sonic integrity with the lowest distortion, and implements the dither correctly so as not to add any distortion or offset upon conversion to fixed point.
The first conditional moment, or mean error, in Fig. 4.4 is zero for all inputs, indicating that the quantizer has been linearized by the use of this dither thus eliminating distortion. The error variance, on the other hand, is clearly signal-dependent, so that the noise power in the signal varies with the system input. This is sometimes referred to as noise modulation, and is undesirable in many applications, such as in audio where audible time-dependent error signals are considered intolerable.
The first three derivatives of this function, and the corresponding moments as a function of the input, are plotted in Fig. 4.5. The first and second derivatives of this function go to zero at the required places, so this dither renders both the first and second moments of the total error independent of x. The second moment of the total error is a constant delta2/4 for all inputs, in agreement with Eq. (4.30). In this case the use of an appropriate dither has eliminated both distortion and noise modulation.
The actual concerns being expressed are much more specific than this though. Wannamaker's thesis compares the properties of rectangular PDF dither of 1 LSB peak-to-peak (which can be described as "bit-perfect dither" according to the criteria I posted earlier) with the optimum triangular PDF dither of 2 LSB peak-to-peak. Of the rectangular PDF dither, he states (emphasis mine):
There is only one section of JRiver PC that produces a properly dithered output to my knowledge, and that is the DSP/options section where you can check the 24-bit checkbox when using ASIO.
BK
And I hardly think that the solution to "there's a problem with dither which is noticeable with 16-bit" is to drop support for 16-bit signals.
OK, here is a recording from the 24-bit ASIO output: https://www.sendspace.com/file/sgthwz (https://www.sendspace.com/file/sgthwz)
I'd rather the dither be correct rather than "bit-perfect"
Guys I am a bit concerned by this statement and the rest of this thread and though I don't understand all the technicalities, I can see that there is real disagreement between competent people. Not everyone has a DAC that has an ASIO driver, with many the best you can do seems to be WASAPI.
In your opinion(s)..
Does this mean that if I have a DAC with which I use the WASAPI driver then JRiver will produce incorrectly dithered output when using the JRiver's volume control or DSP? What effect does setting the bit-depth in JRiver have?
Does it mean that if I have a DAC with a 32 bit ASIO driver then JRiver will produce incorrectly dithered output when using the volume control?
Oops... be careful what you click on from Sendspace. They intentionally confuse the reader so he can end up downloading their extensions and their ads instead of the actual file. I found the zip file...Sorry, I had not realized this was a problem with SendSpace.
Please tell us its provenance, 6233638Media Center into ASIO Link (http://midithru.net/Home/AsioLink), with Media Center's "Device users only most significant 24-bits" option enabled, and a large volume reduction via the Parametric EQ to push the signal into the lower bits.
Guys I am a bit concerned by this statement and the rest of this thread and though I don't understand all the technicalities, I can see that there is real disagreement between competent people. Not everyone has a DAC that has an ASIO driver, with many the best you can do seems to be WASAPI.
All Audio Outputs use the same dithering code. If WASAPI is told to output 24-bit (and there is even an option to tell it that, in addition to automatic), then it will end up sending the exact same audio signal as ASIO 24-bit would.Thanks for the confirmation - I did not expect it to be any different.
Sorry, I had not realized this was a problem with SendSpace.
Media Center into ASIO Link (http://midithru.net/Home/AsioLink), with Media Center's "Device users only most significant 24-bits" option enabled, and a large volume reduction via the Parametric EQ to push the signal into the lower bits.
Then ASIO Link sent Media Center's output to iZotope RX for recording and amplifying the signal back to its original level.
At this point it seems clear to me that Media Center's dither implementation is not the ideal 2LSB TPDF, no matter which output you are using.
It seems that whatever implementation they are using must at least be good enough that it avoids many of the obvious mistakes with dithering so that it'll pass your "buzz test" but it does not seem to avoid noise floor modulation and distortion in the lower bits, which 2LSB TPDF dither should eliminate.
At least iZotope's TPDF implementation avoids this, and I would assume that it's a "reference" 2LSB TPDF implementation, since they also offer their proprietary MBIT+ dither if you want something else.
All Audio Outputs use the same dithering code. If WASAPI is told to output 24-bit (and there is even an option to tell it that, in addition to automatic), then it will end up sending the exact same audio signal as ASIO 24-bit would.
Excellent, thanks for the info.
Would you say it's best to force an output bit-rate for WASAPI - say 24 bit if that's what your DAC likes - or is automatic clever enough to know? I suppose the question is how does automatic decide?
My understanding is that automatic chooses the highest bitrate your DAC will support. The reason that the 24-bit check box is present for ASIO is that many ASIO devices will request a 32-bit output from a program, but only actually use 24 bits for output; in that circumstance, you want the dither to be applied at 24-bits rather than 32-bits.
In the WASAPI context, I've never had any problem with the automatic; it always seems to correctly detect devices that support 24-bit output for me.
Cheers. Can I ask how do you know that automatic correctly detects devices that support 24 bit output?
Cheers. Can I ask how do you know that automatic correctly detects devices that support 24 bit output?
Thanks for giving the provenance, 62x. Can you please upload your original file so I can duplicate the test over here with my own interface and avoiding the complication of ASIO Link. We don't know the integrity of ASIO link, though of course it should be bit perfect :-)Certainly. https://www.sendspace.com/file/is4f96 (https://www.sendspace.com/file/is4f96)
How did Izotope record from ASIO link? Is this available as a direct driver input to Izotope?ASIO Link takes the input via ASIO and passes it to a WDM Recording device. ("ASIOVAD Driver")
Assuming you know which bitdepth is best for your DAC, you can just check the audio path if it is using this format for output.Yes, WASAPI generally gets it right - though I have had certain on-board audio devices which accept a 32-bit input for a 24-bit DAC.
In general, most DACs don't seem to accept a format higher then their favorite bitdepth though, so WASAPI should stick to 24 or 24-padded for a 24-bit DAC.
The override is necessary with ASIO because, as I understand it, ASIO natively works in 32-bit, so if you have a 24-bit DAC, it's necessary for the player to dither to 24-bit rather than hope that the driver will.
I checked my Steinberg UR824 and it shows 24-bit output in JRiver using ASIO. My Steinberg MR816x and Creative X-Fi Elite both show 32-bit output. The UR824 is the most recently produced device. It is interesting that Steinberg developed ASIO and my two Steinberg devices (both with 24-bit DACS) request different bit depths to the ASIO driver.
Certainly. https://www.sendspace.com/file/is4f96 (https://www.sendspace.com/file/is4f96)I was wondering why you were increasing the gain by 60 dB after reducing by 50. I analyzed the file and it has a Peak Level (R128) of -14.4 dBTP. I would recommend only increasing gain by the same amount you have reduced it. Adding 10 dB to a file's native level will bring up the noise floor, but maybe that is what you are trying to do.
As I mentioned earlier in this thread, I don't think ASIO "natively" works in 32-bit. In addition to my quote below, my ASUS Essence ST with ASIO also requests 24-bit data.I'm only repeating what I seem to remember Matt telling me when I asked why that option was there.
An RME technician confirmed (http://www.rme-audio.de/forum/viewtopic.php?id=10617) that with a 24-bit RME DAC, even though the ASIO request is for 32-bit data, the input driver and output driver truncate(?) to 24 bits. They recommend sending only 24-bit data to the RME (which is why I am assuming they truncate).I suppose it depends on the device then. Mine is requesting 32-bit from Media Center when using ASIO.
I was wondering why you were increasing the gain by 60 dB after reducing by 50. I analyzed the file and it has a Peak Level (R128) of -14.4 dBTP. I would recommend only increasing gain by the same amount you have reduced it. Adding 10 dB to a file's native level will bring up the noise floor, but maybe that is what you are trying to do.I suppose that's true. I was really just making the file as loud as possible while staying close to a factor of 6dB so that I knew that the signal had been pushed down into roughly the lowest 6-bits.
it would appear that there is only one way to do correct TPDF ditherFrom iZotope's Dithering With Ozone (http://downloads.izotope.com/guides/izotope-dithering-with-ozone.pdf):
We've probably evaluated 50 combinations of third party dither implementations. We won't tell you
ours is the best, because it's entirely subjective.
I suppose that's true. I was really just making the file as loud as possible while staying close to a factor of 6dB so that I knew that the signal had been pushed down into roughly the lowest 6-bits.
In later tests using 24-bit and the Parametric EQ rather than the volume slider, I was more specific with the adjustments.
With all the theoretical talk and spectrums, we didn't want to leave you without actually knowing how to apply dither. It's easy to make mistakes -- there was one time at iZotope when we thought we had broken our dither in an Ozone alpha version. We finally noticed that the problem was just that the level adjustment in the host app we were testing with had been turned up 1 dB (an inadvertent mouse click in the wrong spot most likely), which will completely mess up any dither. The point is, you can have done this a hundred times and still mess it up with one mouse click.
Then please stop the assertions that it is, or that your tests prove anything.You have a right to ask.With a 16-bit output in my setup, this is audible at normal listening levels when the volume control is below about -24dB or Volume Leveling is active. (since it targets -23dBFS)
We have a right to decline to answer, or to avoid a lengthy debate. This isn't an academic institution, or any other kind of institution.Of course that is your right.
Why don't you try hydrogenaud.io for this? It's the kind of thing they love.
From iZotope's Dithering With Ozone (http://downloads.izotope.com/guides/izotope-dithering-with-ozone.pdf):I was under the impression that TPDF was "standard" dither that should have the same basic implementation everywhere.Quote from: iZotopeWe've probably evaluated 50 combinations of third party dither implementations. We won't tell you
ours is the best, because it's entirely subjective.
Per the same article, you also can't make any volume increases or it invalidates the test:It will "mess up the dither" in the sense that it starts to make what should be inaudible, audible—which could be a problem when you are trying to use a perceptually-weighted dither rather than TPDF. (white noise)
OK, something Media Center does when reducing the playback volume is introducing distortion and noise floor modulation.
Based on the material that igorzep and andy_c have linked to, it would appear that there is only one way to do correct TPDF dither. (i.e. non-distorting, and non-modulating)
I can't say with 100% certainty whether this distortion is being introduced by the dither implementation in Media Center or not, but so far everything I've tested seems to point to it, since Media Center has a lower noise floor than programs with known-good implementations, indicating that it may be 1LSB dither rather than 2LSB.
Aha. WDM. There's a smoking gun. WDM's bit integrity has always been questionable. I've seen bits corrupted when trying to pass signals through WDM. As a professional I NEVER pass ANYTHING via WDM. So strike that solution for your tests. As far as I'm concerned, introducing WDM into your tests invalidates them.Can you suggest a tool which will let me directly capture Media Center's ASIO output then?
I had a discussion with Bruno Putzeys and Jim Johnston over this subject yesterday and here is a tidbit. Before I give you this quote from Bruno I wish to point out you that he presents three possible explanations for the dither amplitude which I measured being slightly high, and one of them is benign! Keep in mind that I personally am currently satisfied that JRiver's 24-bit output under ASIO with the 24 bit checkbox is letter perfect. When there are NO checkboxes in the DSP options. See, there are many permutations. Perhaps one of the checkboxes or methods (e.g. parametric equalizer) is the problem. My tests have been with complex convolution filters and simple volume control attenuation.The dither amplitude really is not a problem. The issue is the distortion and noise-floor modulation.
Or maybe they've just used 2 lsb rpdf which is as effective as 1 rpdf to eliminate distortion but which suffers from some amount of noise modulation. In all cases this suggests a certain amount of confusion regarding how dither works and should be looked at.That sounds plausible. Again, I am by no means an expert on this, I just know what I'm hearing.
By what means did you measure a lower noise floor? My reports show that by FFT an observed p-p amplitude about 0.1 to 0.2 dB higher than Izotope's reference dither.Perhaps it's the noise modulation making it sound quieter then. Media Center's dither also goes silent in quiet passages.
Can you suggest a tool which will let me directly capture Media Center's ASIO output then?
16-bit:Well I would hope that JRiver consider this to be a problem worth fixing rather than suggest spending $120 on another product to fix it.
However, whatever code MC is using appears to develop problems when extended to 16 bit. It exhibits significant noise modulation and some distortion when set to 16 bits. I recommend that any user who feels the need to feed 16-bit devices purchase Voxengo Elephant, which is very reasonably priced. There are no DACs currently available which are limited to 16-bit performance, and the only units which may limit performance to 16 bit are confined to things like Airplay, which should be improved. I would recommend the perfectionist user set up multiple zones, put Voxengo on the zones going to Airplay etc. And set the zone going to his high quality home theatre to 24 bit checkbox without any need for Voxengo. He could insert Voxengo if he thinks he can hear -172 dBFS distortion, but that would be truly anal-retentive behavior.
I would not draw inappropriate conclusions. One must not conclude or assume that just because the 16 bit performance is unnacceptable, that this error would extend to the 24 bit. Coding is a complex and tough job. A simple mathematical error or bug could arise that causes 16-bit problems but does not exhibit any issues at 24 bit. If there was a noise modulation issue at 24 bit, I would have seen it in Foo, whose resolution extends down to -180 dBFS. Even if there are slight errors in MC, they are barely measurable and certainly inaudible at 24 bit.Well again, this is why I preferred to use the conversion feature to produce a 24-bit file which can be amplified to hear what is actually happening in the lower bits of the audio signal, because when you do this it makes these issues obvious. (https://www.sendspace.com/file/3d0bs8)
Yes, thank you for taking the time to test this Bob.
I have always maintained that it is likely going to be very difficult to hear this with a 24-bit signal since it is the lower bits which are most affected, however I can think of some scenarios where it might become audible - e.g. with a power amp and Media Center being used for volume control.
Yes, thank you for taking the time to test this Bob.
snip
So while it might be easy to say that you can't possibly hear something >100dB's down (with 24-bit) there is at least some data which suggests otherwise, from the company producing arguably the best DAC chips available today.
Where would you draw the line in perfection? :-) That's why I think Matt has far more important things on his plate than to "fix" problems which are at -173 dBFS. Sometimes I wish that FFTs with resolution many dB below the threshold of hearing did not exist because people make much too much over what we can see on the display without having the perspective of understanding what these displays mean. Let me be some help. 20 dB is the difference between a shout and a whisper. 60 dB down is microphone level compared to line level. 80 dB down is below the vast majority of average analog system noise floors (not mine, but certainly that of typical consumer gear). Notice that we have jumped downward in level 3 times the difference between a shout and a whisper and we are still 93 dB above the point where I measured the errors in JRiver's FFT! How many more 20 dB jumps do you want to make for safety... before even irrational men would agree that we are talking about inaudible phenomena :-).My primary concern is not -173dB down, but in the audible 16-bit range - and you seemed to agree that there is an audible problem there.
I haven't listened yet and I did not fully understand what you did in your post but if you did not perform dithered conversions if your destination file is fixed point, or exact bit shift using a bit shifter, then you are ADDING distortion on top of the distortion you are trying to analyze. There are so many questions I would have to ask about your method that it has already exhausted my patience.I'm not trying to analyze (i.e. use FFT analysis) I'm trying to listen to what is happening in the lower bits.
There is absolutely nothing wrong with using analog gain to listen to the output of a DAC and evaluate if there is a problem with the sound, even if you have attenuated it in the digital domain.Of course there's nothing wrong with it.
It avoids any questions whether you did or did not dither your subsequent digital gain after you attenuated.Audacity does dither when exporting. It's not as clean as iZotope's TPDF dither, but it is sufficient because only the upper bits are in use when exporting the file after adding 100dB gain.
when instead you need to have sufficient tools to test your ASIO or WASAPI connection for bit integrity so you won't even bring up any doubtMy DAC has a bit-meter built in, and will report whether the signal being played is 16-bit, 24-bit, something in-between 16-24 bit, or below 16-bit.
Of course I have used digital gain for different types of analyses, but I've done my homework, done it completely properly and with proper dithering. But in your case, since you are avoiding testing your interfaces and cleaning that part of your connections up, I think it's a lot safer for you to do analog gain.I am specifically trying to avoid anything which could invalidate the results. If you're testing with analog amplification you could be hearing something else in your setup (the DAC or other connected equipment) that is causing a problem in the depths of the signal.
Furthermore, since I have found no problems hearing the difference between truncating or dithering at 24 bit at NORMAL listening levels, I think that you should be able to find a way to get 10 or 20 dB of reasonable listening analog gain to your analysis procedure and leave no room for doubt in your testing methods. Headphones with a good headphone amp and analog gain should do the job.I have confirmed this easily with 16-bit. I haven't tested 24-bit.
Are your examples of comparison of JRiver's 24 bit dither versus Elephant's 24 bit dither?Across the zip files I linked to in my previous post, I have included:
At normal gains I've no problems hearing the differences between 24 bit properly dithered and truncated, but I have never tried to identify a "defective" 24 bit dither versus a proper one.Which is exactly why I tested the dither algorithms this way.
I'm not trying to analyze (i.e. use FFT analysis) I'm trying to listen to what is happening in the lower bits.
Since both iZotope and Voxengo produce near-identical results when applying their TPDF dither, I am certain that the results from using this method are valid.I'm
The only variable which could affect this, is if Media Center's file conversion output is broken, but I don't believe that it is.Of course there's nothing wrong with it.
It's just a lot more difficult to hear the lower 4-bits in a 24-bit signal if you're using analog amplification than adding gain to a digital file. And as I previously explained, I'm using the lower 4 bits because Matt/Jim did not hear a difference in the file that I initially provided.
It's much easier to hear this with 16-bit playback, but as you insist that non-ASIO outputs are invalid, and there is no option to output 16-bit with ASIO, I am using file conversions instead. I also think that method should produce more accurate results.
I used 24-bit even though it makes virtually no difference in these tests (assuming -120dB for 24-bit, and -72dB for 16-bit) because you say that the 24-bit output does not suffer from the same issues that 16-bit does.
I will state once again that the differences between testing a 16-bit WASAPI output with analog amplification, and 16-bit file conversion were negligible, so I don't think it really matters.
You're too focused on the aspects of this which don't matter, and if they make any difference at all, it does not contribute to the results. The differences I'm demonstrating are big and obvious, not subtle changes.
Audacity does dither when exporting. It's not as clean as iZotope's TPDF dither, but it is sufficient because only the upper bits are in use when exporting the file after adding 100dB gain.
My DAC has a bit-meter built in, and will report whether the signal being played is 16-bit, 24-bit, something in-between 16-24 bit, or below 16-bit.
With a WASAPI signal and no DSP applied it is bit-perfect 16-bit until you adjust the volume in Media Center at which point it reports 24-bit.
I don't think there is anything to suggest that Media Center's WASAPI output is not bit-perfect.
I am specifically trying to avoid anything which could invalidate the results. If you're testing with analog amplification you could be hearing something else in your setup (the DAC or other connected equipment) that is causing a problem in the depths of the signal.
I provided the source file and described exactly what my methods were so that you could reproduce the results if you don't trust that I've done things correctly.
I have confirmed this easily with 16-bit. I haven't tested 24-bit.
I can get an extra 20dB out of my headphone amp but it's a pain to do since you have to open it up and move a couple of jumpers around.
Across the zip files I linked to in my previous post, I have included:
- Media Center 20's dithering
- iZotope's TPDF dither
- iZotope's "Ultra" noise-shaped MBIT+ dither
- Voxengo Elephant's TPDF dither
- Voxengo Elephant's "Gaussian Equal" noise-shaped dither
- An undithered file for reference
For all of these, the peak level of the source track was pushed down to -120dB (105.6dB attenuation, as the peak is -14.4dB) and a 24-bit file was exported using each dither method.
All 24-bit files were imported into Audacity (for the sake of neutrality) 100dB gain was applied, and a 16-bit file was exported.
Audacity's output is of sufficient quality that it has no bearing on these results.
- Both TPDF implementations sound near-identical.
- The undithered file sounds heavily distorted, as you would expect.
- Media Center's dither is clearly different from the two TPDF implementations, and lies somewhere in-between the two. It sounds distorted, but nothing like the undithered file.
The noise-shaped dithers were just used for comparison, and out of curiosity more than anything else.
I'm not asking for noise-shaped dithering in Media Center, only a good TPDF implementation.
Which is exactly why I tested the dither algorithms this way.
I'm not testing to see whether the output is dithered or not, I'm testing the quality of the dithering.
And I know that amplification can invalidate the results with noise-shaped dithering, but even if that were true, I don't believe that it applies to Media Center's output, and I'm not sure that it's true of the noise-shaped examples here - but that is subjective and not the point of discussion here.
I could respond to the rest of your comments, but I don't think there is much point if you have not downloaded the files in my previous post and compared them. Without having listened to them, I don't think you understand exactly what I'm trying to demonstrate here.
Please forgive the excess quoting below. I'm on my iPhone tonight. One thing which is not clear from your post is whether the dithers you were comparing were 16 or 24 bit.They were created as 24-bit files.
[…]
I would only bother to listen to your demo comparisons if they were 24 bit. Then my ears would perk up. I'm already convinced there are problems with 16. Please elaborate.
This is my second post. I re studied your post until it made sense. Im still on my iPhone traveling. Let me see if I understand. You attenuated a signal in JRiver (how was that done again?). You used various 24 bit dithers and exported them 24 bits to audacity. Then raised digital gain about 100 dB (dithered) in audacity and output a 16 bit file for convenience because (probably correct) 24 would be unnecessary. And you want us to listen to near the noise floors of the various 24 bit dithers to show (as you observed) that JRiver doesn't do the job as well as the others. Is that correct?Correct.
Seems like a fair method. Except in my mind a 100 dB (think about that. 100 dB) boost to decide if the distortions in one are actually significant at normal gains strikes me as a stretch. I don't think you'll prove anything about the performance of the dithers as long as JRiver produces a "passable" output. Because you've amplified a flea's wings to a lion's roar! I think you should concentrate on getting a similar 16 bit test to work, dropping gain something fair, like 40 dB and raising it 40.Bob, for you and I, 40dB should be more than enough, but my initial test was 60dB in 16-bit, and Matt & Jim had a difficult time discerning the difference.
I'm equipped to do that accurately at 16 bits without any technical obstacles that you may have introduced. I'll do it for you soon. I would attenuate 40 dB in JRiver, set the parametric to 16 bit simulation with dither,[…]Well Matt did say that the bit-depth simulator is less accurate than the output on playback, which is why I used the file convert format tool instead, as that lets you specify an output bit-depth without using the simulator.
[…] Sound fair?Sounds fair.
...
I’d still recommend that you try listening to the 100dB files though, since it makes the differences so apparent.
Hi 6233638, I can hear the differences you describe in the files you have provided, but I feel the context of your tests do not represent typical day to day usage of JRiver.Again, I understand this. It is audible to me at normal playback levels with a 16-bit output.
The context should be comparing dithers at typical program levels. In other words, typical program levels that 99.9% of JRiver users would listen to on a day to day basis better represents a typical listening scenario. Especially if one is looking to compare audibility in a typical listening scenario and not under a microscope with 1000X loudness magnification (i.e. 100dB gain) applied. http://www.sengpielaudio.com/calculator-levelchange.htm
I would find it hard to believe that the trained listeners at JRiver had trouble identifying the particular 16-bit problem that I measured. It's definitely a problem. I suggest a simple compromise: If trained ears can hear the artifact at normal monitor gains, then it's a problem, OR, if trained ears can detect the artifact at 20 dB attenuation followed by 20 dB boost, then it's a problem.Well I'm glad that we agree on this point.
If MC does not have a built-in way to reduce wordlength to 16 bit in normal reproduction except through a plugin, then why are you going through this exercise? Again, I ask, what real-world use are you asking JRiver to give you for 16-bit real-time reduction?WASAPI and Kernel Streaming output 16-bit. Both should be bit-perfect, and I know that WASAPI is for sure.
I would like to ask 62xxx realistically exactly what his goals are, how he would possibly be using JRiver to generate a 16-bit signal, and how he would be using the program day to day. Exactly what real-world goals are you trying to use JRiver Media Center for?To fix 16-bit playback. Maybe not daily, but I use it often enough that I have noticed this before, but assumed it was the hardware at fault rather than Media Center.
WASAPI and Kernel Streaming output 16-bit. Both should be bit-perfect, and I know that WASAPI is for sure.
Only ASIO/DirectSound do not offer a 16-bit output.
To fix 16-bit playback. Maybe not daily, but I use it often enough that I have noticed this before, but assumed it was the hardware at fault rather than Media Center.
Now that I know it's a software issue rather than hardware, I'd like to see it fixed.
You're not going to get anywhere trying to convince JRiver that a 100 dB boosted signal (or anything more than, say, 20 dB) means an urgent fix.I'm not trying to. I'm trying to provide something that Matt/Jim will actually hear the difference in, as they did not hear it in my original example, which I thought was already boosted too much in an attempt to make it obvious.
I'm not trying to. I'm trying to provide something that Matt/Jim will actually hear the difference in, as they did not hear it in my original example, which I thought was already boosted too much in an attempt to make it obvious.
At this stage I think we both agree that it's an audible problem with 16-bit, and I would hope that alone is enough to get this fixed.
The further examples are simply to give a better idea of what's happening in the lower bits, and show that it's not using standard TPDF.
Gotcha. Sounds fair enough. Don't expect a high priority response as I doubt that 16 bit is a high priority for them. Unless you can prove there is no workaround with a plugin.Well there's no option to output an undithered signal in Media Center any more, so wouldn't that mean it is being dithered twice when using Voxengo Elephant?
Well there's no option to output an undithered signal in Media Center any more, so wouldn't that mean it is being dithered twice when using Voxengo Elephant?
And I really don't want to buy a separate program to fix a problem in Media Center.
I think it is Kosher to set the output to 24 bits and apply a plugin doing 16 bit dither. I think that just adds insignificant 24 bit noise without disturbing the integrity of the 16 bit output, but I could be wrong, I would have to think about that and test to be sure.I had considered that,but I don't know what the driver will do when receiving a 24-bit signal rather than a 16-bit one.
I had considered that,but I don't know what the driver will do when receiving a 24-bit signal rather than a 16-bit one.
Hopefully now that it has been brought to their attention, some effort will be focused on rectifying this problem with their dither.
4. As mentioned previously, 6233638 testing methodology does not isolate the dither to only dither or distortion produced by JRiver. The test file is modified subsequent to JRiver's dither at least two more times and possibly by WASAPI.For all intents and purposes, it does. Dither has little-to-no effect on the upper bits in the signal.
16 bit: "Where would you draw the line in perfection? :-) That's why I think Matt has far more important things on his plate than to "fix" problems which are at -173 dBFS."-173 dBFS is for 24-bit, not 16-bit. And I don't agree that the problems only begin that low in the signal even with 24-bit.
-173 dBFS is for 24-bit, not 16-bit. And I don't agree that the problems only begin that low in the signal even with 24-bit
Conclusions:
My opinion has not changed regarding MC's performance on PC at 24 bits (measured with ASIO). I am thrilled with its sound and measured performance. I have measured insignificant distortion, many dB below the threshold of hearing, in fact likely masked by the DAC noise. There is no noise modulation whatsoever. MC's measured performance is exceeded only by Voxengo by the tiniest measurable but inaudible margin. It's an academic argument to ask JRiver to improve the 24-bit performance. I own some professional-quality, high integrity DSP products which show slightly more distortion on the FFT that is still well below threshold of hearing and whose sound is also excellent.
16-bit:
However, whatever code MC is using appears to develop problems when extended to 16 bit. It exhibits significant noise modulation and some distortion when set to 16 bits. I recommend that any user who feels the need to feed 16-bit devices purchase Voxengo Elephant, which is very reasonably priced. There are no DACs currently available which are limited to 16-bit performance, and the only units which may limit performance to 16 bit are confined to things like Airplay, which should be improved. I would recommend the perfectionist user set up multiple zones, put Voxengo on the zones going to Airplay etc. And set the zone going to his high quality home theatre to 24 bit checkbox without any need for Voxengo. He could insert Voxengo if he thinks he can hear -172 dBFS distortion, but that would be truly anal-retentive behavior.
16-bit gets you around 96dB of dynamic range undithered.Bob used tones encoded at -32dbFS. After the 82dB attenuation in JRiver the signal level is now at -114 dBFS. One would expect the distortion to be lower. The distortion is now at -172dBFS. This has nothing to do with the dynamic range of 16-bit audio being 96 dB.