Print

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

[6233638]

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.
The default level with Volume Protection enabled is -40dB which is approaching this.
 
And if you are trying to determine whether dither is being performed correctly of course you would use the lower bits to determine this, since that is where dither is most necessary.
 
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.
 
 
Something must be wrong in your setup if you can't hear the significant distortion in Sample 2 compared to Sample 1.
Sample 1 just has a lot of background noise, Sample 2 has variable noise and distortion.
 
I would suggest listening with a pair of good headphones rather than speakers. It should not be a subtle difference between the two samples.
There should be very bad distortion around the halfway point and in the last 15s of Sample 2. (Media Center)

[JimH]

I listened with Matt to the samples and both had some audible hiss.  Neither seemed better or worse.

We don't think the test is valid.

[6233638]

I listened with Matt to the samples and both had some audible hiss.  Neither seemed better or worse.
We don't think the test is valid.

OK, here is around 1 second of audio taken from the same point in both tracks, each repeated for about 10s:
 
https://www.sendspace.com/file/42kywl
 
First half is iZotope, second half is Media center.
iZotope's TPDF is just random noise - as it should be, Media Center is heavily distorted.
 
Let the track loop a couple of times if necessary, but I don't think you can miss it.

[mwillems]

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.

The dynamic range of an average person's hearing is about 21.5 bits (130dB), which does not imply what you're suggesting; 130dB is the distance between the threshold of pain and the threshold of audibility.  That means that (on average) we can, in laboratory conditions, hear noises 130dB quieter than noises that are so loud they cause us physical pain.  And 0dB (or close to it) is the lower bound; if you routinely listen to music with peaks reproduced at 70dB SPL in your room, in that context you can, even theoretically, only perceive a dynamic range of about 11.5 bits (70dB).

And I say theoretically because the lower bound of our hearing is mostly theoretical in non-lab conditions as most non-lab rooms have noisefloors that are between 40 and 50 dB.  For reference, some anechoic chambers used for equipment testing have 20dB noisefloors (e.g. the one silentpcreview uses for their tests), and I've never personally measured a domestic space with a noisefloor below 30dB, even in well treated home theater spaces, even at night.  I'm sure some exist, but it usually takes a lot of money and effort to get ambient SPLs lower than 30dB.  Have a look at this chart for context: http://www.sengpielaudio.com/TableOfSoundPressureLevels.htm

So that means that if you're listening on speakers in a normal home to music with peaks that reach 80dB at your listening position you'd be lucky to get 50dB of effective dynamic range before the quiet bits are lost in the noisefloor of the room.  Realistically, it's probably more like 35dB in most homes.  If you turn it up to theater reference levels with peaks to 103, you might start to actually see 60dB+ of effective dynamic range on peaks in a quiet room.  But that's pretty loud to my ears, when I've tried it.

It's a slightly different story with headphones depending on how much isolation they provide, but I don't see many headphones that offer much more than 10 or 15 dB of isolation, and the open-backed ones provide far less. You get the idea.  It's not easy to create a real world scenario where your program material and your room conspire to give you 60dB+ of dynamic range without engaging either extremely loud music or professionally treated rooms/laboratory conditions.  

I don't mean to suggest by any of that that if there were a problem here, that it shouldn't be fixed; distortion sources can "gang up" and push into clearly audible territory, or you might have a room where you can hear down to 20dB.  That said, I'm not convinced there is a problem.  Bob's measurements look good, and I don't hear clear differences between the two samples you provided; but I don't have headphones handy, I'll give another listen when I get home.

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'm not sure if I'm reading what you're saying correctly, but 40dB is not "approaching" 60dB, in the sense of being near it on a logarithmic scale.  60dB is literally 100 times louder than 40dB; the difference between 40 dB and 43dB of amplification is equal to the difference between 0dB and 40dB of amplification.  In perceptual terms 60dB will "seem" about four times louder than 40dB.  So unless you routinely listen at -60dB of attenuation, amplifying it by 60dB is not a good test of audibility.  If it's still obvious to you after amplifying it by whatever your normal level of attenuation is, that's a better test of audibility.

[6233638]

I just wanted to say that the responses here are disappointing.

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"
 
Whether you consider it to be an "extreme example" or not, I was simply confirming that there is something wrong with the current dither implementation.
I used an example like that to try and make it really obvious - though not obvious enough, it seems.
I compared it against iZotope because Bob said that it has a perfect implementation of TPDF dither - and it seems to.
 
I don't know the technical reason for it, but it seems like Media Center may be using 1LSB rather than 2LSB as igorzep initially suggested?
 
Hopefully the second example will make things clear enough, or perhaps using headphones rather than speakers, and that will change your mind.
If it's still not obvious enough I can make a more extreme example, I just thought that -50dB would be sufficient.

[bobkatz]

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.

Please check that option out and then report back here. Thanks,


BK

[6233638]

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.

Please check that option out and then report back here. Thanks,
BK

24-bit comparison - sorry for the size, I uploaded the full tracks by mistake.
 
It's possible that the converter processes files differently from playback, but that seems unlikely?

[mwillems]

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"

I wasn't trying to suggest that you couldn't possibly be hearing something, and I'm sorry if that's how it sounded, I was just trying to explain why I thought that the dither implementation was unlikely to be audible in the normal course of events at the best of times.  I also offered some explanations for why I thought the test might not be well-designed to expose an audible problem, but I tried to clearly say that if there is a problem with the dither implementation it should be fixed, regardless of audibility, because distortion products can add up.  Reading back over it I can see how it sounded like I was gaslighting you, and I'm sorry for that, that really wasn't my intent.

I didn't hear a clear difference between your first samples, but on headphones I hear a definite difference in quality of the noise in the 24-bit samples you provided; the izotope sample is just white noise (or something like it), but the JRiver sample noise clearly varies in volume/tonality with the source material (it sounds like it may be modulated by it).  What I find confusing is that I would expect the modulation we're hearing in those samples would have been clearly visible in Bob's measurements.  So clearly something is up somewhere, because the two tests produced results that are hard to reconcile.  The explanation for the difference is probably to be found somewhere in the differences between your testing methodologies.  You may be on to something with:

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.

[6233638]

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)

[mwillems]

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

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!

But it may be that with more gain than 12dB combined with 16-bit dither, it could be easier to hear.

[6233638]

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 dither

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.

[bblue]

I have a very detailed and revealing system, and downloaded both example files for a listen.

Based on what I heard, I don't see how anyone would not be able to hear the clear differences between the first half and second half of the file 'distortion.flac' or the differences between 'izotope.flac' and 'media-center.flac' from the '24-bit Dither.zip' file.  In each example, the differences are virtually identical.  As 62 said, even at TPDF the noise is rather 'rough' compared to MBIT+ and its variants.  I played these samples through my Media Center using WASAPI out, and also VLC using a direct USB output.  Between those two there was a slight timbre difference between the samples, but the gross distortion of the Media Center samples remain the same.

I'm suspicious that something else might be going on with the Media Center examples, as in each case they sound like the noise is 'chopping' at around 30Hz or so.  It's anything but smooth, and one could call it distorted.  I've never heard anything like it here on my Media Center except for in these files.

Whatever, it's very very obvious here.

--Bill

[mwillems]

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.

So I performed some relatively "naive" listening tests and here's what I found based on the following parameters:

I used an old pair of Klipsch earbuds with a rated sensitivity of 115dB/mw hooked into two different sources, an Odac/O2 combo and the headphone jack of my Steinberg UR824.  In both cases I turned MC's internal volume to -60dB and turned the amplifier gain all the way up.  

The Odac/O2 does not have ASIO capability, so I used WASAPI, and I set the output bitdepth to 16 bit with attenuation set to -60dB. I could hear the music clearly, but any noise below it was quite soft.  I could hear a soft white noise below the music that was not present when playback was completely stopped.  Based on some differential testing, I believe that the white noise I was hearing was MC's dither, not the noisefloor of the equipment.  I did not hear noticeable noise modulation, although the levels of the noise in question were admittedly a little soft.

Not satisfied with that result, I thought I might force the issue by using the bitdepth simulator at home with my Steinberg.  With the Steinberg I tried an ASIO output and used the bitdepth simulator in PEQ to test a 16, 15, and 14 bit output with a -60dB signal.  The PEQ filter is especially useful because it allows you to toggle dither and so hear the signal with and without dither.  Using that method, with dither enabled on a 16-bit simulation, I only heard white noise below the music with no noticeable modulation, similar to the izotope recording above or what I heard in the O2.  

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.  

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.  

Admittedly this was a sighted and unscientific test, and I was using different program material (although I was using solo piano music to try and keep it similar). That said, I encourage anyone interested to try using the bitdepth simulator to recreate 623368's and my experiments and see what you think.  Basically set the bitdepth six or seven bits lower than your current volume level (i.e. 16 bits for -60dBFS, 6 bits for 0dBFS) and try toggling the dither check box and then gradually decreasing the bitdepth and retoggling.  6233638 I'm particularly interested in your impressions using the bitdepth simulator.

But for the record, I definitely did hear some changes in the volume of the dither noise along with the program material with MC's dithered signal, which I'm not sure what to make of, as Bob's measurement's did not appear to show any such modulation.

So it seems like we've got two possibilities:
Either
1) Dither is not being correctly applied on conversions (in which case we're just looking at a bug) or
2) We need to reconcile the two apparently inconsistent tests (i.e. clips with audible noise modulation, and Bob's measurements which don't seem to show that)

It seems like option 1) should be readily confirmable or disconfirmable.  If no one can confirm before the weekend, I may try and actually take measurements and see.

[6233638]

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.
 

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

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.
Reducing the bit-depth without dither at all will introduce similar distortion much sooner.

[bobkatz]

You're barking up the wrong tree. Whatever you have found may only be true for the method you used to produce the 16 bit file. The measurements and sonic observations I passed on earlier for JRiver's 24-bit dithered output remain true. DSP/options/checkbox "device uses 24 bits". In JRiver for PC. This produces an accurate, dithered 24-bit output.

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. It's certainly very clean. But as soon as I get a minute I'll do a gonger (noise modulation) test. The facts are that no one would be interested in producing a 16-bit output with JRiver. For what purpose? JRiver is not a DAW. Personally I would never use it as a file conversion tool. It's resolution and signal handling DOING WHAT IT IS INTENDED TO DO are impeccable. MC is not intended to be a signal processor for file production, at least I would never use it that way. It's intended to be a file playback tool to feed high quality DACs, all of which are capable of and perform better receiving 24-bit signals.

Who would need or desire to use River to produce a 16-bit output? Please tell me when you would need it. This thread is really starting to piss me off. Why are you ignoring the evidence I presented in other recent posts? The method you are using to produce a 16-bit signal is completely different and should not lead you to the conclusion that something is wrong. Read the rest of the thread, 2014 posts only. In 2013, Matt, with my help and guidance and that of others, produced a highly-functional 24-bit dithered output from JRiver on PC. Prior to that there was a problem. Those observations are still in this thread but way out of date. 

Damn, people are stubborn.

BK

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.

[bobkatz]

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?

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

BK

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

This seems related to the 2LSB discussion recently.

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

[bluescale]

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.

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?

[6233638]

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:

“[…] our dither is bit-perfect.  There are lots of ways to do a dither, and ours is chosen for strategic reasons.”

There are also many posts on the forum where people are recommended to use Media Center for volume control in their setup because, to paraphrase, "Media Center does it right, you don't know what your AVR is doing."
 
Perhaps it did work correctly and this is a recently introduced bug. I don't know.
But now that this problem has been found and is reproducible, should it not be corrected, rather than arguing over how bad a problem it is, or why it doesn't affect your particular setup?
 
I'm not asking for the dither to be changed to implement noise shaping, or license iZotope's MBIT+ dither algorithms for example, only that the current TPDF implementation be fixed.
 

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.
I don't see why it would be any different from other output methods though.
 
I don't have a good ADC or a device to record a digital signal from the PC to see whether or not ASIO differs from the rest of the program.
There is probably some software which can capture the ASIO output directly, but it really should not be necessary at this point, as we have shown that there is a problem.
 

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.
 
I don't know if the problems introduced by these errors only affect signals near the noise floor, or if there could be effects at higher levels as well.
 
And just because it may not be a problem in one setup, does not mean that it won't be in another.
I would think that checking the output in the digital domain would be far more accurate than passing it through your DAC, Amplifier, and Speakers when testing this sort of thing.

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.
If you only use the test that it passes, you might believe the implementation to be perfect.
Does that make it so?
 
Let's even ignore the fact that it is distorting - or that what I am calling distortion, you might not. As a layman, I'd say that it sounds distorted to me in the samples that I have posted - whatever the cause is.
 
When dither is properly implemented, the signal should not modulate the noise.  Surely you agree with that?
 
One of the more noticeable effects of this noise-floor modulation is that it sometimes goes completely silent in Media Center.
iZotope's TPDF implementation—which I trust to be correct since they are in the business of licensing their dither algorithms to other companies—is never silent, even when the track is playing silence.
 
I make no claims to being an expert on this subject whatsoever, I'm only describing the problems that I hear. Stuff like this goes right over my head.
However, could it be that Media Center is using <2LSB for its dither, which allows the signal to modulate the noise, while iZotope is using 2LSB?
For all I know, this could just be a variable which needs to be set in Media Center's code, rather than some major change.
 

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.
I have devices here which accept a 24-bit input, but actually only send 16-bit over their digital outputs.
I have no idea whether they handle this conversion correctly, but I know that Media Center should, if this gets fixed, and it would be best to send them a properly dithered 16-bit signal instead.
 
Most networked hardware is only 16-bit, and when using Gizmo/JRemote for control, volume would normally be adjusted by Media Center.
 
Listening carefully with headphones on and using the bit-depth simulator, I would say that the noise floor modulation starts to become quite noticeable at about 12-bit.
 
So with 16-bit devices, anything below -24dBFS is distorting.
Considering that the Volume Leveling target is -23dBFS, that's a problem.
 
 
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.

[bobkatz]

Now we are moving forward and on the same page. One thing about software, a programmer was asked by his boss if there are any bugs in the program. The programmer replied, "None that we have found yet."

On the same vein, as long as posters don't leap to conclusions that if they found something broken in one section of MC it must be broken everywhere else, I'm good with the suggestions to improve other aspects of MC.

Here are my feelings:

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.

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.

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)

[6233638]

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.
Now it could be argued that 16-bit hardware these days when 24-bit is cheap, is probably not very high quality, but I don't think that means this should be ignored.
I also think 16-bit is used in a lot of these devices to save bandwidth rather than compromise on quality.
 
As I previously posted before testing this, I had noticed some noise modulation on playback before, but since everyone else had posted that "media center does it right" with regards to dither/volume control, I assumed it was the hardware at fault and had not taken the time to test it.
 
After testing with both the bit-depth simulator—since it is far more convenient to use and seems to produce the same results—and outputting a 16-bit signal to my Benchmark DAC2, I do hear the modulation quite clearly once the bit-depth is reduced to 12-bit, which is only a 24dB attenuation in 16-bit, and very close to the target used for Volume Leveling.
 
This is at normal listening levels, not greatly amplified listening levels.
So if you are using 16-bit devices and have Volume Leveling active, everything you play is going to be affected by this.
 
Now I know that you would not normally send a 16-bit signal to a 24-bit device, but I did this to confirm that it's not the $99 AirPlay hardware at fault, since I can hear it on a $2000 DAC as well.

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.

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)

To be clear, I am not expecting MC to be a DAW.
I was only using the conversion feature for this test because it is the easiest way for me to get a "recording" of Media Center's output after making volume adjustments.
 
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.
Without being able to properly test it here, I can't dispute that the 24-bit ASIO output may be different though - but I don't think that is important when every other aspect of the program does have this issue.
 
As I see it, worst case scenario is that fixing this will audibly improve 16-bit playback, and may also improve the quality of 24-bit.
It should measurably improve the quality of 24-bit playback, even if it may not result in an audible change in many setups - but in some setups it may even be an audible improvement.
It has been suggested by companies like ESS that people are actually susceptible to hearing noise-floor modulation even when it should theoretically be far too quiet to hear. It's not that we are consciously aware of the noise floor, but that we pick up on the modulation of it as it changes.
 
And again, I'm not an expert on this so I don't know what the cause is. I just know that it's an audible problem in my setup that I had previously attributed to other devices.
I suspect that it is related to Media Center's dither using <2LSB, but I couldn't say for sure.
Hopefully Matt or Hendrick will be able to identify the cause and it will be a relatively easy fix.
From what I do understand of it, this paper that was linked to before seems like it might be helpful. I hope that it really does not have to be much more than tweaking the values used for the current dither implementation rather than being a big job.
 
And since the bit-depth simulator seems to produce similar results to playback, I would suggest that it might be a useful way to quickly confirm whether the issue has been fixed.
Reducing it to ridiculously low levels like 6-bit or even 4-bit will currently produce a lot of obvious distortion and noise modulation - so obvious that I don't think it is possible to miss it.
With correctly implemented TPDF dither, reducing the bit-depth to levels like this should really only be introducing louder and louder white noise, rather than sounding more and more distorted.

[bobkatz]

Well the AirPlay receivers I have in use, and the DLNA speakers that I tried recently were all 16-bit devices.

So, please tell us exactly what method you are using to reduce the wordlength.

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.

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

BK

[Matt]

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.

Yes, the bitdepth simulator is rough and dirty.  It definitely shouldn't be used in critical trials.

[mojave]

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.

[6233638]

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.
The 24-bit option for ASIO output may indeed be the one area of the program which dithers correctly. I just haven't confirmed that one way or the other.
 
File conversion (16 or 24 bit), 16-bit WASAPI Exclusive playback, and the simulator all have this issue.
If the issue only existed in the simulator, it wouldn't matter because no-one is going to use that for normal playback.
 

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.
The results I get from the simulator are very similar to what I get from playback and conversion though.
I just thought it might make things easier for Matt to test, since he seemed to have difficulty hearing the problem in my other comparisons and it's very obvious when you drop the simulator to something like 4-bit.
 

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.

[andyc56]

To quote Matt:

“[…] our dither is bit-perfect.  There are lots of ways to do a dither, and ours is chosen for strategic reasons.”

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

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.

[6233638]

OK, here is a recording from the 24-bit ASIO output: https://www.sendspace.com/file/sgthwz
 

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"

[bobkatz]

My FFT measurements show that MC's dither amplitude is even slightly higher than Izotope Ozone, so I can only assume that MC's dither is far greater than 1/2 a bit! I'm betting at least 2 bits peak to peak. I would have heard the distortion from 1/2 a bit, I have some strong methods to detect dither issues even down to the 24th bit.... (quiet room, extra analog gain when needed in the monitoring, superb DAC, good, trained ears).

But I must take a look at a bitscope and do some noise modulation tests to try to quantify MC's dither so we can close this case definitively. Regardless, my take on it has been that MC takes some liberty with the term bit-perfect. I think he means it in a different sense than the math you are trying to show below. From my point of view, if you add noise, you can't match the source, and that would not be bit-transparent.

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.

in the meantime I can sleep quite well knowing that MC is quite well dithered at 24 bits, at least with the ASIO output. I can hear the difference.

BK

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

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.

[andyc56]

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.

[bobkatz]

Any dither with zero mean is bit-perfect in the average sense, so that's not saying much.

True --- if the dither is properly implemented. But I have seen processors with DC offset, stuck bits, poor calculation resolution....
Which is not the case with JRiver. 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.

[andyc56]

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

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.

This is on page 94 in the page box of Adobe Reader, which is page 78 on the top page margin.

So the issues of distortion and noise modulation are separate: the distortion elimination being accomplished by rendering the first moment of the error independent of the input.  But noise modulation can only be eliminated by rendering the second moment of the total error independent of the input, which this rectangular PDF dither does not do.

He goes on to describe the optimum triangular PDF dither as follows:

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 delta²/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.

That's on page 96 in the page number box (page 80 of the document itself).

So per the above it's possible to eliminate distortion with the rectangular PDF dither, but not noise modulation.  The optimum triangular PDF dither eliminates both.  That is the concern.

[bobkatz]

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

I am aware of these, of course. 0.5 dB p-p is often misused as an "auto-black" method, but of course if you have auto-black like this, then you will also get noise modulation! To repeat my previous posts:

I measured the peak to peak amplitude of JRiver's 24-bit dither with Spectrafoo's FFT, comparing it with Izotope's dither. I mentioned that it is AT LEAST as high, in fact a hair higher p-p than Izotope. The randomness on the screen appears to be similar to that of Izotope as well. So I reached the conclusion that AT LEAST JRiver is in the ballpark and I've stated several times that I will do some tests for noise modulation in the near future. Keep in mind that MORE dither level does not hurt* as long as it is TPDF and at least the recommended p-p amplitude. Who could ask for more?  :-)

BK

* It takes many generations of flat 24 bit dither accumulated to even reach the noise floor of a DAC. In most situations even the nominal -120 dBFS noise floor of a good DAC with associated preamplifiers is inaudible.

[AndyU]

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

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?

[6233638]

ASIO set to output a 24-bit signal still distorts, I posted a small sample here: http://yabb.jriver.com/interact/index.php?topic=76912.msg633875#msg633875

[bluescale]

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.

My point was that JRiver should do it right, or not do it at all.  My guess is that dropping support for 16-bit devices is not a palatable option for the folks at JRiver...

[Sheriff1972]

watching this thread closely.

Bruno has been around the block a few times when it comes to digital and is seldom wrong.

How hard would it be to implement the 'fix' and send a this version of software out to a few people for testing?

I guess only Matt knows for sure

[bobkatz]

OK, here is a recording from the 24-bit ASIO output: https://www.sendspace.com/file/sgthwz
 I'd rather the dither be correct rather than "bit-perfect"

I'll check out your recording shortly. You made a .dmg file. This was on a Mac? I thought we were discussing JRiver ASIO on PC. Could you please tell us the provenance of your recording. Thanks,


Bob

[bobkatz]

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

Please tell us its provenance, 6233638... and what is your name, please.


Bob

[Hendrik]

You probably clicked the wrong download link, and hit an ad instead.
The proper link is a text link that says "Click here to start download from sendspace"

[bobkatz]

Andy, I completely sympathize. This thread was started by me back in early 2013 and you can follow its progress. I think you will note that very few people brought up any other options, perhaps none. So in general the vast majority of the JRiver audience expects the program to work, work properly, and not require that the user do much special to guarantee good quality sound. I was under the impression from the thread that WASAPI was dithered. Why not follow this whole thread through, from the beginning when the program was not properly dithered, to today, and you'll note that this is really an esoteric topic.

I don't use WASAPI so I can't speak for this with authority, but I feel your pain. Maybe it is dithered properly. Then there's 62xxxx's post of today, whose provenance was not given, with a sample flac file for examination and his claim that there is distortion. I am skeptical, but more than willing to go the mile and see what's up. I haven't checked it yet, but if we don't know how the file was created, down to the utmost detail, then we know next to nothing. A good scientist would have reported what the source is, how it was generated, what options were checked in JRiver, and how it was recorded.

BK

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?

[6233638]

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, 6233638

Media Center into ASIO Link, 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.

[Hendrik]

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.

[6233638]

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.
Am I correct in thinking that using the conversion tool should also use the same dithering when reducing the bit-depth?

[bobkatz]

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


BK

Sorry, I had not realized this was a problem with SendSpace.
Media Center into ASIO Link, 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.

[bobkatz]

How did Izotope record from ASIO link? Is this available as a direct driver input to Izotope?

BK

[AndyU]

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?

[mwillems]

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.

[AndyU]

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?

[mwillems]

Cheers. Can I ask how do you know that automatic correctly detects devices that support 24 bit output?

99% of my music is redbook CD quality music (16 bits).  When I output to one of those devices and look under audio path, MC tells me whether it's outputting at 16 bits or 24 bits.  When using WASAPI, MC has output at 24 bits to all my devices that support it when the automatic setting was engaged (i.e. it successfully detected which devices support 24-bit).  In some cases the devices themselves indicate on their displays what bitdepth they are receiving, and those devices have also confirmed that they are receiving the appropriate bitdepth.

The only hiccup I've ever had with detection was not with WASAPI, but with an M-Audio ASIO device that asked for a 32 bit input, but did not have a 32 bit DAC in it (so I needed to check the ASIO 24-bit box).

[Hendrik]

Cheers. Can I ask how do you know that automatic correctly detects devices that support 24 bit output?

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

[6233638]

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

I just couldn't find an easier way to get a digital "recording" of Media Center's ASIO output - though we now have confirmation from Hendrik that things don't change whether ASIO or WASAPI are used.
 
And via a 16-bit WASAPI output from the PC, this is audible during playback if you're reducing volume in Media Center. It doesn't get as bad as these extreme examples using the lowest bits of the signal, but the noise floor modulation and what sounds like some distortion, is audible.
 

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")
It's supposed to be bit-perfect, though I did not run any tests to confirm this.
 

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

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