Print

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

[mojave]

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.

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 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.

An RME technician confirmed 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).

[mojave]

Certainly. 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.

[6233638]

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 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.
Or perhaps the default is 32-bit if the device doesn't request anything specific?

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.
In later tests using 24-bit and the Parametric EQ rather than the volume slider, I was more specific with the adjustments.
 
It really doesn't affect these results though, as it's Media Center's dithering which is causing the problem.

[6233638]

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.

[mojave]

it would appear that there is only one way to do correct TPDF dither

From iZotope's Dithering With Ozone:

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.

Per the same article, you also can't make any volume increases or it invalidates the test:

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.

[6233638]

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)
 
I don't know why you seem to think these tests don't prove anything now that we have confirmation from Hendrik that the same dither method is used for all outputs.
 
The only thing which was in doubt was Bob suggesting that the ASIO output may be handled differently since it passes one of his tests. He specifically mentioned that he has not checked for noise modulation.
 

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.
Why don't you try hydrogenaud.io for this?  It's the kind of thing they love.

Of course that is your right.
I wasn't looking for a debate though, I was simply asking whether you use a 2LSB TPDF implementation or not, because that would avoid any debate.
 
Confirming one way or the other avoids debate over whether it's the dither implementation or something else that could be causing this.
 
It's an objective fact that Media Center is distorting playback, what's subjective here is people arguing over whether or not it's audible to them, or whether it only affects non-ASIO outputs, and frankly I think that discussion has been a waste of time, detracting from the main issue.

From iZotope's Dithering With Ozone:

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 was under the impression that TPDF was "standard" dither that should have the same basic implementation everywhere.
However, according to the information posted earlier, it seems that many implementations deviate from using 2LSB (±1 LSB) dither, which can reduce the noise at the cost of introducing distortion and noise modulation.
 
What usually differs between implementations is when companies use something other than "standard" TPDF to try and increase the perceptual quality of the dither, such as iZotope's own MBIT+ dithering.
And I agree with them that noise-shaped dither could be subjective, and one person might prefer one type of perceptually-weighted dither to another.
 
This is why I used iZotope's TPDF implementation without any noise shaping for the comparisons, rather than include their MBIT+ dither, as that would be an unfair comparison against Media Center, and I'm not asking for anything like that - only that the distortion and noise modulation be fixed in the current TPDF implementation.
 

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)
 
iZotope is designed for production rather than playback, so dither must be the last thing you do to the audio, or else you are potentially introducing noise (dither) into the track and then amplifying it.
 
Here, we are specifically trying to listen to the lower bits of the signal to see whether or not it is being dithered correctly, or if it's introducing distortion/noise modulation, so it is perfectly valid.
 
You could do this with analog amplification instead—and with 16-bit audio it's not even that difficult—but it's simply easier and going to produce more consistent results to do it in the digital domain.

[bobkatz]

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.

This morning I'm going to do comprehensive tests and try to put this thing to bed. Also, please, 62xxxx, please stop leaping to conclusions. You are making a hypothesis and presenting evidence, but some of us question the way in which you gathered your evidence. A scientist never says that something is "confirmed" when he's the only guy reporting it. Remember "cold fusion". So please watch your language. When two people report very different conclusions, we need to see some confirmations from several other users on this forum and to reconcile the methods before leaping to conclusions. I'll check your results and conclusions over here and see if I can duplicate them.

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.

Bruno said,


"Hi Bob,

A great test or demo is a 0.5 lsb peak sinewave of 1Hz.

I'm confused about the slightly higher dither amplitude you report. Once you have two statistically independent 1 lsb rpdf added together (thus making a 2lsb tpdf) that's all you ever need. If the amplitude is different there are several possibilities. Maybe someone's decided to deviate from the 1 lsb amplitude for the rpdf and the dither is therefore plainly invalid. Maybe they've added a third noise source to an otherwise fine tpdf which changes nothing (for better or for worse) other than increase the noise floor. 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.

Cheers,

Bruno"

Maybe JRiver set the amplitude of the dither a bit higher....   which is benign at 24 bit level. So I am not saying that the higher amplitude I measured is a problem, just observing it at this time.

cheers back,

BK

[bobkatz]

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.

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.

[6233638]

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 really don't think this should be the focus of the discussion though, and it's why I preferred to use Media Center's conversion function rather than anything else.
 

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.
And again, what I'm calling "distortion" may not be in the sense that you are using it. I simply mean that it sounds distorted. Perhaps it's entirely noise modulation causing that.
 
I don't believe that my headphones are sensitive enough, or the headphone amplifier's output loud enough that I could confirm whether or not the 24-bit ASIO output differs from all my other testing. According to Hendrik, it should not.
 
I also see no reason why the converter should produce different results from playback, and I don't hear a difference between a 16-bit conversion or 16-bit WASAPI Exclusive output. (clearly audible noise modulation with an attenuation >24dB)
 

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.
I used the highly scientific method of using my ears, since the noise level really was not really my concern here.
It just sounded quieter in my tests, and I wondered if that might indicate that it's using <2LSB TPDF is all.
 
Again, a confirmation of what Media Center is currently using would clear things up rather than have us speculate.
I'm not sure why Matt/Jim/Hendrik haven't cleared things up yet. Of course they are under no obligation to, but it'd be a lot simpler if they did.

[bobkatz]

Can you suggest a tool which will let me directly capture Media Center's ASIO output then?

Try this. I've used it on Mac and it passes the grade. Somewhat unstable. There is a PC version:  jackaudio.org/faq/jack_on_windows.html

If you get it to work, test the bit-integrity of the interconnection by sending a known 16-bit signal from JRiver at unity gain, no dsp, into the receiving device. Put a bit-meter on the receiving device. Then drop the gain. It should grow to 24-bits, perhaps to 32-float or 64-float. If you don't have a bit-meter on the receiving device, then record a short file and put it up here and I'll measure its actual bits.

I've never used JRiver's converter and I've never used JRiver at 16 bits... See my next post with a thorough set of tests I performed today.

[bobkatz]

JRiver MC19 on PC Dithering Measurements. Bob Katz 9/27/14

I performed a series of exhaustive tests today. Here's a report. Warning: Long post with attachments!!!!!

Today is the first day I've ever tested JRiver at 16 bits and also the first time I've tested it with a definitive test signal for noise modulation.

All tests with JRiver on a PC, using ASIO, all DSP options turned off except as noted below. All tests at 44.1 kHz. FFT measurements made with Spectrafoo on a MacIntosh. Using AES/EBU output of JRiver PC or Sequoia PC. Each PC has a Lynx brand interface. Stereo audio tested. The source(s) feed the AES/EBU input of Motu interface. Foo is set to analyze the Motu interface.

Initial setup. Let's test the tester using signals from a Sequoia workstation. Sequoia DAW with various types and amounts of dither and plugins. In all cases, when properly dithered, Sequoia measured impeccably. When not dithered properly I was able to see any distortion or noise modulation using various test signals. So we're ready to test JRiver.

JRiver tests:

I. Distortion test. Multitone Buzz signal attenuated various amounts. At 0 dBeach sine wave tone in the multitone signal is at equal level, -32 dBFS. 3244 buzz attenuated 82 dB with JRiver's volume control. At these attenuations JRiver's steps are not exactly 1 dB per step, which explains the odd attenuation.

24 bit:

A)  24 checkbox on. Some barely perceptible distortion spikes occasionally drifting up to -180 dBFS. These are completely inaudible and way below the threshold of hearing. Measured performance is excellent. The buzz signal itself remains intact but attenuated 82 dB. All buzz tones measure -114 dBFS as they should be. (-32 - 82 = -114)

B) 24 checkbox off. Voxengo Elephant set to TPDF 24 bit. All buzz tones at -114 dBFS as they should be.

An FFT picture of IA and IB is attached. The main amplitudes are identical so you only see the color which is on top (blue). If you look VERY closely you can see a couple of barely visible (insignificant) distortion spikes in red, barely visible above the grass. I can see that JRiver's dither is a little lower in level than Elephant's. But both performances are excellent. For clarity, the FFT is limited to 2 kHz, but in reality the buzz signal extends to over 20 kHz, which intermodulate and reveal system nonlinearities. 

C) 24 Checkbox off. Significant distortion spikes. All this is expected because AES/EBU truncates to 24 bits, so the dither switch (24 checkbox) is working. No doubt the truncation is audible, the cumulation of the different distortion spikes. In general I find this level and kind of distortion manifests as a loss of stereo depth and space. However, when truncation occurs at 16 bits, then the sound develops coldness and harshness.

FFT picture attached, just for fun

16 bit tests:

D) 24 checkbox on or off. Parametric equalizer with 16 bit simulation, dither off. Since its' truncated, we get serious distortion, it doesn't resemble the buzz signal at all. To be expected. Not shown.
   
E) 24 checkbox on or off. Parametric eq with 16 bit simulation, dither on. I see the buzz signal, but its signals are not at equal levels. For example, 250 Hz is at -120, 750 at -117, 1250 at -117, 2250 at -117, but they should all be at -114. There are some measurable distortion spikes, but my main concern is that the dithering or some coding errors are not reproducing the tones at proper and equal levels. Something must be wrong with the code.

F) Change to Voxengo Elephant, set to 16 bits TPDF dither instead of the Parametric EQ.  All buzz tones are equal at -114 dBFS and there are no visible distortion spikes.

Attached is an FFT measurement comparing IE and IF above.


---------

II. Noise modulation test:

The Gonger signal was developed by the BBC's Chris Travis. http://www.aes.org/e-lib/browse.cfm?elib=6283

It was designed to audibly detect noise modulation issues with ADCs and DACs. But if you look at the Gonger on a live (real time) FFT analyzer you can watch the noise floor and see if it modulates or stays constant. It is a 16 bit dithered 399 Hz sine wave modulating from negative infinity up to -10 dBFS. When JRiver is at unity gain, Foo's bitscope shows 16 bits indicating JRiver's bit integrity and that there is no additional DSP engaged in the JRiver processing chain. At unity gain the noise floor is constant. Not shown.

Attenuating the 399 Hz gonger: I can see the noise floor go up and down when the gonger goes through its cycle and/or distortion IF DITHER IS IMPROPER OR NONEXISTENT. The Quicktime movies are between 2 and 4 MB each so I had to put them on my FTP. Here is the address. Open in a browser:

client.digido.com/?u=jriver_dither&p=jriver_dither

Gonger through Lynx, all DSP options turned off, ASIO, 24 bit box checked.

A) Initial test, bit-integrity

JRiver @ Unity gain

Checkbox 24 bit. Result: 16 bits showing in Foo. Bit-transparent copy of the 16-bit gonger source signal showing that at unity gain, JRiver is bit-perfect, or at least it passes only the wordlength of the fixed-point source. Not shown.

JRiver volume control attenuated 82 dB

24 bit

B) Checkbox 24 bit. Result: Foo's bitscope grows to 24 bits. I can see JRiver's dither. I can also see some very low level distortion as the gonger signal goes through its cycle, very low level. I do not see ANY noise modulation. The distortion is way below the threshold of hearing and probably masked by the DAC noise. This is excellent performance and I would say it's academic to ask JRiver to "improve" this nearly text-book quality dither.

Quicktime Movie. Play each movie a few times. The first time watch the signal. The next time watch the noise. The next time watch the bit meter. You could hear any noise modulation if you had sufficient analog gain. I cannot distribute the gonger signal because it is copyrighted. But it's no longer for sale to my knowledge so that's a bummer.

C) Turn off the 24 bit checkbox. Significant distortion. Many spikes, as would be expected, truncating the 32 float signal to 24 bits through AES/EBU. Watch the spikes explode when the signal attenuates all the way.

Quicktime Movie.

D) Voxengo Elephant. Elephant Set to unity gain. TPDF 24 bit dither. JRiver set to -82 dB attenuation. Results: Perfect performance. No noise modulation, no indication at all of distortion.

Quicktime movie.

16 bit

E) Plugin disabled in JRiver. Parametric with no filtering and unity gain, with the bitdepth simulator, set to 16 bits dither. I do see strong noise modulation and some distortion. The noise modulation is the main issue.


Quicktime Movie. Notice how the bit meter actually turns off at points, indicating the signal is completely cut off at times. That's serious noise modulation.


F) I turn off the dither in the parametric bit simulator and strong distortion is added along with the noise modulation.  Not shown. To be expected.

G) Voxengo set to unity gain. TPDF 16 bit dither. JRiver set to -82 dB attenuation. Results: Perfect performance. No noise modulation, no indication of distortion.

Quicktime movie.

6) Just for fun. 16 bit parametric set to bit simulation with dither turned off. Results are as expected. Not shown.


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.

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.

Listening: I am an audiophile and an engineer. Listening always comes first for me, but in this case I do not feel it necessary to listen to the music files provided by 62x because my measurements confirm what he hears AT 16 bit. And his methods of testing 24 bit with WDM as part of the chain do not pass muster. If he wishes to refute my conclusions at 24 bit he's going to have to emulate exactly what happens when the signal is sent to his DAC. Perhaps there is another way to reliably cross patch the signal from JRiver to a DAW on a single computer. If he finds one, one way to prove it is to send a 16-bit unprocessed signal from JRiver, and watch a bit meter on the receiving end. If it is 16 bit, and grows to 24-bit when any attenuation is made, that's a good indication he's got a good measurement and recording instrument.

I did not do any listening tests because the 24 bit tests above confirm my previous listening that 24 bit is for all intents and purposes very clean, undistorted, and does not exhibit any noise modulation. I also confirmed 62xxxx's 16 bit determinations with my own measurements so we're in agreement on that. I use JRiver as a high-fidelity player in my mastering room, which is one of the best-sounding rooms and playback systems in the country and I'm thrilled with the purity of tone and sound quality of JRiver when set to 24 bits.

[Sheriff1972]

Hi Bob,

Thank you for putting your time into looking at this.

This is a most satisfactory outcome to this thread. Vindication all round IMO.

I hope that your conclusions encourage Matt & Co, to do a little digging into their code, and make JRiver truly blameless (yes even at 16 Bit).

Thanks to 6XXX for not giving up on this topic. I remember when i had a tagging issue on JRiver 19 trial edition, i had some difficulty in getting my issue taken seriously. I was made to feel like i was doing it wrong'. Suffice to say i was not the only one with the problem and eventually and a fix was found.

It all helps to make a better product, and everyone is the winner.

Mike

[6233638]

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.
 
With 16-bit it can be clearly audible if there's even a relatively small attenuation and while we would have ideally moved beyond 16-bit by now, it's not always an option.
 
If it is what Bruno has suggested and Media Center is using 2LSB RPDF rather than TPDF for example, then it seems that it would greatly improve 16-bit performance to make this change, and do no harm with 24-bit, eliminating the circumstances where this may be audible.
 

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.

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.
 
If it fixes one problem and potentially improves playback quality at 24-bit, it seems worthwhile to me.

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.
 
That's not to say it's a problem for 24-bit output, since those lower bits are significantly quieter than 16-bit, but demonstrates that it still exists with it.



And I still believe that there is some merit to the idea that while it should be inaudible, we can actually pick up on noise-floor modulation at very low levels even though it should be masked by the signal. There was an ESS presentation at RMAF 2011 which mentioned their internal testing of this, but I can't seem to find it on YouTube any more. They're the company that designs the Sabre DAC chips found in almost every high-end DAC these days, if you are not aware.
 
One of the examples in the presentation by their CTO was that when comparing two DACs, one with 100dB SNR, -80dB distortion specs, and another with 120dB SNR -106dB distortion, noise floor modulation in the DAC below the noise floor of the music track actually made the second DAC sound worse, even though measurements indicated otherwise.
 
Here are a couple of slides from the presentation (I have a local copy of it) which may be of interest:

 
A lot of it was focused on explaining how ΣΔ DACs work and how they compare to conventional DACs, but one of the points which was repeated a lot was that the main reason people could identify the two, despite the ΣΔ DACs offering measurably better performance was due to noise modulation. (something which their HyperStream modulator fixes)
 
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.

[bobkatz]

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.

62xxx. Your language incorrectly states the situation. This time you misstated my words and revealed that you did not read my post thoroughly and absorb it thoroughly. Here's what you missed:

1) You have misstated an important fact demonstrated by my measurements. It is not just a case that "it is hard to hear an issue at 24 bit" as you say. In fact, it is the case that MC's performance at 24 bits is exemplary, one tiny step below perfect. All indications are that JRiver's dither at 24 bits is either equal to or close enough to the proper dither for all practical purposes.
2) You seem to ignore that I posted and demonstrated an FFT with absolutely no detectable noise modulation, with distortion products so insignificant as not to warrant any further development at 24 bit. Did you play the mov's and digest their conclusions? This is in mov # IIB. You will see a non-moving noise floor and barely perceptible distortion products. I repeat, the case for 24 bit is closed as far as I'm concerned. If JRiver decides to reinvestigate the dither for the sake of 16 bit ---- any improvements, if they migrate to 24 bit, will only be for Brownie points; any difference will be completely academic according to the most sensitive measurement methods on earth. As far as I can determine, MC's audible performance at 24 bit is not at all limited by its slightest measurable defects.
3) You have ignored the incredible sensitivity of the test mechanism. That I tested the test mechanism with Sequoia using as little as 0.1 bits, 0.2 bits, etc., to see that the measurement reveals the slightest amount of noise modulation when improperly dithered. Take a look at mov #IIC, trucation at 24 bits, which reveals strong noise modulation and somewhat important distortion products, which are audible as a reduction in depth and space in my own personal listening tests.
4) If you wish to refute my claims about the quality of the 24 bit performance and contribute something to the quality of this product, then I challenge you to perform a blind test between Voxengo Elephant TPDF dither at 24 bits versus JRiver's dither at 24 bits. If you can pass a blind listening test on that, I will try to see if I can pass it, because so far I have not heard a difference, using the most sensitive audiophile-quality musical material. Then and only then would I get on my high horse and ask JRiver to please improve the 24 bit dither. Just for you I'll do that listening test myself this morning and report here on the forum.
5) You are incorrect about your conclusions of using a power amp and Media Center with a volume control. These measurements show that even with a power amp with 20 dB or even more of excess analog gain and Media Center as a volume control, that there would be no audible problems at 24 bit. You would hear the noise of the DAC before you even heard the noise modulation or problems of JRiver as it currently stands at 24 bit. The noise of the DAC would completely mask the residual distortions that I measured and remember, there was absolutely no noise modulation!
6) OK, let's please stay truthful, accurate and thorough in our language. It's something that I try to do. It's not easy, and I urge you,  62xxx, to please step up to the plate.

[Sheriff1972]

62XXX, i suspect that this debate will have Matt digging into his code, as he too is interested in making the best product he can.

Having Bob comment on the 16 Bit performance as it is and the 24 Bit being a 'tiny step below perfect, will no doubt grate with him until he finds a fix.

We shall see no doubt.

P.S. Thanks Bob for the heads up on the Elephant Plugin

Mike

[bobkatz]

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.

By the way, I never claimed that distortion products 100 dB down are not a problem. In many cases they are, not just in cases with high analog gain and large amounts of digital attenuation. Truncations at the 24 bit level produce products which obscure depth, in the -100 and below region. The only thing I am disputing is whether you can hear distortion products which are 173 dB down, if you get my drift. I draw the line at tones that I cannot hear, and in my room, I can hear a 1 kHz -140 dBFS tone, and hear whether it is dithered or not!  I have to raise my analog gain 12 dB above my maximum calibration point in order to hear that, with my ear quite close to the loudspeaker, but it's audible, so the DAC has excellent resolution.

OK, let's see what that tells us. It tells us that a superior DAC with an RMS noise of about -120 dBFS can resolve individual tones which are at -140 dBFS, barely, and these tones can be heard in a calibrated quiet room with an extra 12 dB of gain. Somewhere around -141, -142, or so, in my room the tone disappears into the DAC noise. I think it is completely safe to say that the distortion products in MC which I measured at -173 dBFS, which are 33 dB below the 24 bit noise floor, and 53 dB below the DAC noise floor, are inaudible. At the highest NORMAL analog gain in my room, the DAC noise of -120 dBFS falls at MINUS 17
dB SPL. So let's be fair. In order of perception:

There are things you can hear which no one doubts
There are things which we may be able to hear which reasonable people accept could be audible
There are things which we can measure which we barely can hear under extreme circumstances with amplified gain
There are things which we can measure which we cannot hear
There are things which we can measure which are another 33 dB below that!

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  :-).

[6233638]

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.
If the dither algorithm is changed to correct this, I am pointing out that it should also have a positive impact on 24-bit performance.
 
While it is not my main concern, this improvement to 24-bit quality would offer objectively better performance, whether it is subjectively considered to be an issue or not.
If the dither is changed to address these problems with 16-bit playback, I see no reason why it should only be applied to 16-bit and not all conversions.
If you are concerned that a change may negatively impact the quality of a 24-bit output, perhaps there could be an advanced option to let people use the old dither instead, but I'd hope that would not be necessary.
 
 
I don't know if you want to call it distortion, noise modulation, or something else, but something sounds wrong with Media Center's dither.
I have now done some further testing using the trial of Voxengo Elephant after your recommendation, and it confirms that iZotope's TPDF implementation is good, since Voxengo and iZotope's TPDF implementations sound almost identical.
 
This is why I think there is some merit to performing conversions and amplifying the output, rather than trying to amplify it in the analog domain, or using FFT analysis, since this method produces clearly audible results which are easy to compare, and avoids any potential problems caused by the ASIO/WASAPI/Other outputs/drivers.
 
 
I was careful in the preparation of these files. The gain was reduced so that the peak sample in the track was exactly -120dB (a reduction of 105.6dB if I recall correctly) as this puts the audible signal in the lower 4-bits, quite far above -173dB.
 
The files were exported from their source application in a 24-bit format after this reduction was performed.
I then loaded these 24-bit files into Audacity and amplified them by 100dB.
Why 100dB? Because dither/noise shaping adds extra noise, so I wanted to leave adequate headroom to avoid clipping any of them.
They were exported as 16-bit files, because the lower 4-bits in the 24-bit signal have now been moved into the upper bits of a 16-bit one after amplification, so exporting as a 24-bit file would make no difference to these tests.
 

• This file contains examples of Voxengo Elephant's dither and an undithered example
  
• This file contains examples of Media Center and iZotope's dither
  
• Here is the source track again, if you want to perform these tests yourself using other software
  

 
2&3 have been posted before, but I'm reposting them just so that you have the right files for the comparison.
The Voxengo samples mute every 45s or so because I am running the trial.
 
I found that the easiest way to compare them all was to load them all into the same Audacity project, mute all but the iZotope TPDF track (since I consider it the reference) start playback, and then toggle the solo button on another track to quickly A-B them.
That way you don't have to listen to the full track and can quickly switch back and forth between the results.
 
 
Since I am pushing the audio into the lower 4 bits, the results should be exactly the same as a 16-bit output with a -72dB peak level, rather than 24-bit with a -120dB peak.
That's obviously a lot—even with 16-bit—but Matt & Jim seemed to have difficulty hearing the problem when I was only using a -60dB peak in 16-bit, and you have suggested that there is no problem with a 24-bit output. I designed this test to address both these concerns.
In my own listening tests I can quite clearly identify the problem with a 24dB reduction at 16-bit (12-bits for playback) so the attenuation does not have to be nearly as large for it to be audible.
I'm only using this much attenuation because it makes the problem more obvious, not because I normally have playback at these levels.
 
If it's not distortion, and it's not noise modulation, can you tell me what is happening with Media Center's dither?
 
 
At this point it seems that Media Center is not using TPDF, or that there is something wrong with the implementation if they are.
It is being dithered though, if you compare it with the undithered file that I included.
Bruno's suggestion of 2LSB RPDF sounded plausible, but I don't have any software which has this as an option, so I can't do a comparison.
Perhaps Matt/Jim could comment on it, but I'm really not as concerned about what is in use, as I am about what can be done to fix it.

[bobkatz]

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.

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. It avoids any questions whether you did or did not dither your subsequent digital gain after you attenuated. And if you did attenuate and then boost in the digital gain and are counting on the difference between the distortion you generated by the truncation after the gain shift to be "so far down as to be insignificant" then your methods immediately bring up so many questions. You mentioned this "avoids issues of ASIO/WASAPI" etc. 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 doubt. 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.

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.

Are your examples of comparison of JRiver's 24 bit dither versus Elephant's 24 bit dither? I think you should just do that at normal gains and let the listeners decide if they want to amplify it and how. 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. Given the measurements, I wager the differences here will be inaudible and that you cannot amplify enough to hear them if you have done your patching and routing correctly.

Are you saying that you clearly heard a meaningful difference between JRiver's 24 bit dither and Elephant? With music? Although listening to dither noise under highly amplified conditions is an excellent diagnostic tool it is not at all musical, nor does it reflect what the ears hear at normal gains, not at all. Because the ISO curves change the emphasis of low frequencies to high, so you can never say, "this sounds better" when listening under extreme magnification. All you can say is, "I hear distortion" or "I hear noise modulation", etc. That's why in the end you have to resort to measurably testing performance with an FFT analyzer and test signals, then limit your listening to normal or slightly higher gains in the analog domain.

Unfortunately I can't compare Elephant dither versus JRiver's dither using JRiver because for about a year or two I have been running a convolution/crossover within JRiver. When I tried it tonight, I discovered that you can't have your cake and eat it, too. It's ok to patch Elephant multichannel in FRONT of the convolution, but not after... I could not fix the routing within Elephant to route the low pass to my woofers no matter how hard I tried, if I left the plugin as the last item in the chain where it belongs for dithering.

When I get a chance, I'll compare JRiver's dither with a very good and known reliable dither by playing back a known music file from JRiver within Sequoia. But not tonight.

[6233638]

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.
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.
 
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.

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'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.
 

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 doubt

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.
 

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.
 
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.

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.
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.

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:
 

• 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.

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 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.

[bobkatz]

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.

Anyway, I don't think it necessary to prove any more points by listening to an exaggerated signal. My tests showed serious defects in MCs 16 bit output. The defects would be clear to anyone viewing the bitscope and the noise modulation and distortion in the mov. So JRiver will decide if this is something they want to tackle.

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.

Bob

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.

[bobkatz]

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?

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.

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,. Feed AES out to sequoia, observe a bitscope in sequoia to confirm the reduction to 16, and record that. Then do the same with elephant. Forget about noise shaped because they sound real sucky when amplified. Then boost 40 dB in Sequoia re dithered probably to 24 to avoid any question. Listen to the two and compare.

I might try the same with 24 bit just for curiosity but continue with the 40 dB pair of atten/boost because in my mind that's the fairest reasonable amount to exaggerate what anyone could ever hear and is probably 20 to 30 dB greater than real life already. I'm not trying to hide any defects at 24 but just being realistic. Let's say we're trying to prove if you can hear my pen scratching on the desk next to you, not whether you can hear me rub my fingers together while sitting in the next room from you! Sound fair?

Bob

 leave the 24 bit checkbox on

[6233638]

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.
[…]
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.

They were created as 24-bit files.
 
The Media Center example was created using the “convert format” option with the output bit-depth set to 24-bit (not the simulator) and the volume reduction applied via the Parametric EQ’s “adjust volume” option, as it lets you be more specific with the attenuation.
 
The other files were created in iZotope RX, since it lets me specify the dither being used when exporting a file.
 
The “no dither” file was created to confirm that iZotope’s “no dither” output is undithered, and confirming that ensured that the program was suitable for applying the Voxengo Elephant dither. (Since it would not be dithered twice)
 
 
Note: loading these files into Audacity to add 100dB of gain and exporting as a 16-bit file will have probably added some dither to the final "no dither" file. It only needed to be undithered at iZotope's export, which I was able to confirm. This dither after adding 100dB of gain to the file has no bearing on the results.
 

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.

As you perform greater attenuation and gain to the file, such as 100dB in 24-bit in these latest examples, it just makes things more obvious and means that you don't have to play things back so loud.

It’s not at all necessary for it to be this much, it just makes it easier to hear the difference.
Since all I'm trying to do is confirm that A) There is distortion being introduced and B) Media Center is not using TPDF dither, the more obvious these differences are, the better.
 
I’m not at my PC right now either, but I can create files using much less attenuation if you wish—but the results are the same, it just becomes more difficult to discern which dither is being used, rather than whether or not the dither is being performed correctly.

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 should be back at my PC soon and will create some 16-bit, -40dB files for you if it saves you some time.
I'm probably not going to have a chance to do this today now.
 
I’d still recommend that you try listening to the 100dB files though, since it makes the differences so apparent.

[bobkatz]

I've thought some more about the threshold of audibility issue and after discussing it with some psychoacoustic experts off list I've slightly revised my recommendations, but the theme is the same.

It is "ok" to exagerrate gain in order to train the ears to recognize certain artifacts. However, it is not ok to assume that this means that these artifacts are audible at normal gains. 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. I submit that 20 dB attenuation/boost is already at least 10 dB more than we would EVER expect a digital reproduction system to be adjusted. It is therefore a "safe extreme" threshold for audibility testing. It accounts for listeners who completely misuse the gain structure of their playback system (e.g. turning up their analog gain far too much and attenuating digitally far too much). It accounts for listeners with extreme hearing sensitivity. It accounts for listeners with very quiet rooms. It accounts for listeners with better DACs than you used for your own audibility tests. Etc. etc. etc. 20 dB is an excellent margin of error. And it avoids the question of suggesting anything more, and I was much too generous to suggest 40 dB attenuation/boost. 100 is completely stupid. Our digital tools give us the power to amplify things which are completely masked in normal circumstances, and so we must be fair to reality.

I propose a standard test for proper dithering where:

1) The user trains his ears to hear the artifacts under question

2) the user attenuates his source 20 dB using the normal tools in the application under test.

3) feeds it out through a DAC (which is a real world situation) testing with/without dither/with various flavors of dither, etc.

4) Re-records it through an ADC

5) Boosts it 20 dB with 24 bit dither

5) Auditions the result at normal monitor gains

If the artifacts are then inaudible, we deem them to be inaudible and completely acceptable.

Unfortunately, I am completely unfamiliar with the parts of MC which are used to export files and the only section of the program that does 16 bits that I am familiar with is the parametric bit simulator in the preferences. 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? Please Educate me. Until you convince me that there are really applications that a reasonable person would expect JRiver to do, I'm not convinced that 16-bit output is useful. And if you want to be a perfectionist feeding cheap Airplay to cheap speakers in your den, then go ahead and buy Elephant, or Izotope, or PSP's X dither and insert it as a plugin in DSP's signal chain.
-----------

For goodness sakes, let's be realistic! Expecting JRiver to be a DAW is unrealistic. It was not intended to be a DAW.  Although its bit-integrity and resolution for reproduction at 24 bits or feeding 64-bit float via ASIO to another application are impeccable. I use MC to play back music, feeding Acourate Convolver via Acourate at 64 bit float, convolve the audio with a room correction filter, and then dither within Acourate Convolver to 24 bits on the way to my monitor DACs. I also have Acourate filters built in a zone choice in MC to play back motion pictures with 5.1 sound.

However, JRiver is not a DAW, and for $39.95 or whatever the current price I would never expect its tools for wordlength reduction to 16 bits or export of sample rate converted or wordlength-reduced files to be of professional quality. I never heard such a claim and I would be skeptical of a $40 program that claimed to do this. With a bit of work, I bet JRiver could come up to that quality, and that would truly be a bargain. But do you really expect the developers to work on DAW features when that is not their target audience?

For DAWs:

Does Audacity have "automatic dither" that cannot be turned off by the user? If so, then I would not consider Audacity to be professional quality. Does it have the options of exporting floating point files without any dither? If not, then I would not consider Audacity to be professional quality.

The most reasonably-priced PC-based DAW application with these features and good bit-integrity that I would recommend is probably Samplitude. I say probably because I have never used regular samplitude and you would have to look in the preferences to see if regular Samplitude offers the dithering option. I say that because I know that Samplitude Pro and Sequoia do have the dithering options.

OK, back to the listening tests. 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? I've already demonstrated that the 24-bit is perfect. if it's feeding another zone that must be 16-bit, then buy a plugin for goodness sake.

[Mitchco]

...
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.
 
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 
 
Your test effectively takes an amplitude that is typically inaudible, relative to regular program levels, amplifies the loudness by a factor of 1000, which makes it audible and compares.  I feel the test should be the other way around, compare dithers at typical program levels.  Program levels that we all listen to on a day to day basis, not amplifying microscopic amplitudes by a loudness factor of 1000X.
 
I would argue this approach: http://www.computeraudiophile.com/content/520-fun-digital-audio-%96-bit-perfect-audibility-testing/ for testing audibility artifacts better represents the typical listening scenario most listeners would find themselves in on a daily basis.  In other words comparing changes at regular program levels.

[6233638]

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.
 
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 

Again, I understand this. It is audible to me at normal playback levels with a 16-bit output.
In most situations, I would expect that the error at 24-bit should be inaudible, though I do think there are some scenarios where it might become audible.
 
Magnifying things this much does two things:
 

• It confirms that there is something wrong with the current dither implementation by making the differences so large that it shouldn't be possible to miss them. (since both Matt and Jim did with my less-extreme examples)
• It confirms that Media Center is not using a standard TPDF implementation since it sounds nothing like the iZotope/Voxengo TPDF dither.

 
Not that Media Center must use a standard TPDF implementation, but the dither currently in use sounds worse than it.

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.
Only ASIO/DirectSound do not offer a 16-bit output.
 

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.
Now that I know it's a software issue rather than hardware, I'd like to see it fixed.

[bobkatz]

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.

I see. Well, I propose that when you need simple 16-bit playback with high quality you use a plugin which dithers to 16 bit. Assuming that you can turn off MC's own dither in that condition. Were you able to? I've forgotten, it's somewhere in your posts.

If you can do a workaround with a plugin, then I would say this request is not at all urgent. Send a request to fix 16-bit playback to JRiver, they will prioritize it and see if they can fix it. If there is a good workaround (Elephant, Izotope or PSP X-dither) I think you should send the request and move on. 16-bit playback is not that important to the vast majority of MC users. With a workaround this cannot be an urgent, high priority request in my point of view.

I'll create a +/- 20 dB listening test with Wasapi versus Elephant at 16 bit and report here as well do a listening test at normal levels. (In my copious free time  :-))

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.

Honestly, hope this helps,

BK

[6233638]

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.
 
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.

[bobkatz]

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.

[6233638]

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?
 
And I really don't want to buy a separate program to fix a problem in Media Center.

[bobkatz]

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.

In my opinion it is fair to buy a plugin if you are a minority user needing a particular feature that can be covered by a plugin. At least until JRiver gets its act. I purchased Elephant myself during the time when JRiver's 24 bit dither was not up to snuff, because I was a perfectionist. So I think you have to step up to the plate. However, as I suggested, if you can demonstrate there is an obstacle (such as not turning off the 16 bit dither) to doing it properly, then the urgency of the request should go up.

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.

BK

[6233638]

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.
 
Hopefully now that it has been brought to their attention, some effort will be focused on rectifying this problem with their dither.

[bobkatz]

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.

I can tell you one thing for sure. If it is a legitimate 16 bit signal in a 24 bit container, then it will survive truncation to 16 bit when you send it to Airplay or some other 16-bit destination you have in mind.

[mojave]

1.  People are overlooking that Matt said, "Yes, the bitdepth simulator is rough and dirty.  It definitely shouldn't be used in critical trials."
Bob Katz used JRiver's regular dither for 24 bit, but the bitdepth simulator for 16 bit.

2.  The 16 bit noise Bob did find, with the "rough and dirty" simulator is at -172dBFS to -173dBFS.
"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."

"The only thing I am disputing is whether you can hear distortion products which are 173 dB down, if you get my drift."

"I think it is completely safe to say that the distortion products in MC which I measured at -173 dBFS, which are 33 dB below the 24 bit noise floor, and 53 dB below the DAC noise floor, are inaudible."

3.  Nobody ever had an issue that I'm aware of before JRiver introduced dither in 18.0.106. They used to truncate which now looks "terrible." 

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.

5.  Conclusion from Bob Katz:
24 bit:  "I use JRiver as a high-fidelity player in my mastering room, which is one of the best-sounding rooms and playback systems in the country and I'm thrilled with the purity of tone and sound quality of JRiver when set to 24 bits."

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."

[6233638]

I got to do a little testing earlier today and I am quite confident that Media Center is using 1LSB RPDF for its dither - or something which sounds very similar to it.
 
Increasing this to 2LSB would be a big improvement, eliminating the obvious distortion, and greatly reducing the severity of noise modulation.

At 2LSB, switching from RPDF to TPDF seems to eliminate the noise floor modulation too.
 
Perceptual dithers are interesting, but I think that the best overall results may just be TPDF. Or at least, they are the most consistent.
 

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.
MC's conversion function was used as my primary means of testing, not capturing its output during playback.
 

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.

[mojave]

-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

JRiver is being attenuated by 82dB for the tests. Bob says in the 16-bit conclusion section that there is some distortion and one could use Voxengo to bypass the 16-bit distortion. He then says one would only use Voxengo if they think they can hear -172dBFS distortion. Why would he recommend Voxengo for 24 bit when he said it is an academic argument to ask to improve JRiver's 24-bit dither? What makes you think he is talking about 24-bit?  Here is the entire quote again:

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.

[mattkhan]

frankly I have no idea how dither should be implemented or whether I'd even hear the difference with normal listening material. However I do have one question; if 2LSB TPDF is the one true way then why wouldn't jriver just implement that? Is it computationally expensive? have some other undesirable downside? or is it just because dither is an unusually esoteric subject that few people really know how to implement?

[6233638]

When doing some further reading on the subject, there was a post from Bruno which, to paraphrase, said that the random noise generator was the computationally expensive part of dithering, and that the cost of using 1 or 2 LSB, RPDF or TPDF would be negligible.
 
There are potentially better ways than 2LSB TPDF, such as using noise shaping, but that is beyond the scope of what I would expect JRiver to change, and I'm not sure that it's important at all.
 
2LSB TPDF avoids both distortion and noise modulation, which is the main issue.
Anything else you do is a trade-off for where the noise is (trying to make it less audible by shifting it to higher frequencies) and other changes could potentially make things worse.

[mojave]

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.

To go the opposite direction, I can listen to my Blu-ray of Cream: Live at Royal Albert Hall that is 16-bit. Drum beats are in excess of 120 dB in my room. Does that mean they really aren't in excess of 120 dB since 16-bit has a dynamic range of 96 dB? No, they don't have anything to do with each other.