Ending the Windows Audio Quality Debate

[Davide]

I have read the ITU-R BS.1770 document with interest, which explains how to measure true peaks.
It says that oversampling to 192khz is the minimum to determine true peaks.
Therefore, once the Windows mixer is set to this frequency and a pre-attenuation of -3.5dB is set, there should be no risk of further peaks in the DAC due to its oversampling.
Unexpected true peaks should eventually be caught by the Windows limiter at this point.
It would just be interesting to know if the limiter can create new true peaks at this point, also given the distortion it introduces.

 

[BeerBear]

It would just be interesting to know if the limiter can create new true peaks at this point, also given the distortion it introduces.

It sure can. But at 192k it's unlikely to be a significant issue. As you probably know by now, true peak overshoots are more of a problem at "lower" sample rates (44/48k), while at 192k the samples map the actual waveform quite accurately.

At this point we could also mention that True Peaks™, as defined by that document, don't necessarily coincide with the actual peaks produced by a DAC. That's because not all DACs oversample in the same way, with the same filters... And they also have different amounts of internal headroom, so actual clipping might or might not happen (BTW, here is an interesting ISP clipping test).

 

[dasdoing]

has anybody ever found a comercial realease that has audible intersample peaks? I don't think they exist. it's a single sample after all

 

[Offler]

has anybody ever found a comercial realease that has audible intersample peaks? I don't think they exist. it's a single sample after all

Speaking of commercially available media (CDs, streams whatever) the answer is no.

Speaking of gaming or computer triggered sounds, there is at least possibility.

 

[BeerBear]

has anybody ever found a comercial realease that has audible intersample peaks?

I haven't, but I also haven't looked very hard. And I'm not aware of any large scale test of this, even though it would be easy to do, at least if you don't mind using software instead of sending the music through actual DACs.
So, until proper large scale testing is performed, the magnitude of this problem remains unknown. (But I believe, based on my limited testing, that it's not a significant problem.)

 

[Davide]

has anybody ever found a comercial realease that has audible intersample peaks? I don't think they exist. it's a single sample after all

Here someone did some measurements of Spotify and found TPs above 0 dBFS.
Streaming services encode lossless masters in lossy codec and this results in a 99% increase in TP (see iZotope).
Furthermore, Spotify applies a -1dBTP limiter when selecting a -11 LUFS normalization, so it cannot be excluded that intersamples arise as a result of the limitation (which remains at 44.1kHz).
In any case, from Spotify informations you can understand how the TP largely depend on the mastering of the song. Almost nothing if not the competence of the mastering engineer forbids the appearance of a TP.
Then how much such clipping can be problematic in the analog world is another matter. True It probably clips less than half a wave, so I wouldn't talk about DC. In fact, I believe this is the reason why there are no problems with the speakers, nor audible disturbances.
Then as mentioned above, it also depends on how DACs manage oversampling and ISP.
Also it must be said that if one adjusts the volume in the digital domain, they will probably have so much headroom that the problem does not exist.

 

[dasdoing]

Here someone did some measurements of Spotify and found TPs above 0 dBFS.
Streaming services encode lossless masters in lossy codec and this results in a 99% increase in TP (see iZotope).
Furthermore, Spotify applies a -1dBTP limiter when selecting a -11 LUFS normalization, so it cannot be excluded that intersamples arise as a result of the limitation (which remains at 44.1kHz).
In any case, from Spotify informations you can understand how the TP largely depend on the mastering of the song. Almost nothing if not the competence of the mastering engineer forbids the appearance of a TP.
Then how much such clipping can be problematic in the analog world is another matter. True It probably clips less than half a wave, so I wouldn't talk about DC. In fact, I believe this is the reason why there are no problems with the speakers, nor audible disturbances.
Then as mentioned above, it also depends on how DACs manage oversampling and ISP.
Also it must be said that if one adjusts the volume in the digital domain, they will probably have so much headroom that the problem does not exist.

Spotify changed recently (1 year ago?)

they normalize without a limiter for "normal" and "quiet" while never exceeding -1dBFS true peak.
the limiter gets used in the "loud" setting if necessary, but whoever needs this setting doesn't have a quality playback anyways lol

Loudness normalization - Spotify

support.spotify.com

speaking of which, I hate when tracks are quieter than others (probably because of the true peaks). I might even use the loud setting in the future lol. the quality of the limiter should be good enough

 

[bennetng]

(BTW, here is an interesting ISP clipping test).

It is a very old post in 2018 and the purpose is to show that there is no need to buy anything claims to be able to deal with intersample over. The first thing to do obviously, is to prove (to those who don't know or don't trust measurements, only their ears) that reducing digital volume in an earlier stage can solve the issue, and this proof requires a test signal that can actually create audible clipping artifacts.

Recently I post much less frequently in ASR because very similar topics repeat and repeat too often and I get bored. Also, @edechamps has already proposed a method to defeat the Windows limiter in a reliable way without relying on exclusive mode or installing additional software, so I think the whole thing is solved already. What users choose to do is their own freedom.

 

[krabapple]

It is a very old post in 2018 and the purpose is to show that there is no need to buy anything claims to be able to deal with intersample over. The first thing to do obviously, is to prove (to those who don't know or don't trust measurements, only their ears) that reducing digital volume in an earlier stage can solve the issue, and this proof requires a test signal that can actually create audible clipping artifacts.

Yes. Emphasis added in case anyone missed it.

 

[Davide]

I was doing more loopback tests in Windows and noticed a weird thing that I can't explain.
With Audacity I play mono 44.1/16 WAV files with white noise and analyze the loopback in REW RTA through VB Hi-Fi Cable.
ALL, and I mean ALL, the volumes are set to 100%, including those relating to the Windows mixer (yes, all those dozens of adjustments that Windows integrates for no reason).
Yet if in Audacity I set the WASAPI driver instead of MME or DS, in REW I measure about -1 dBFS RMS less.
The strange thing is that if I play a 1kHz tone at a fixed level, there is no such difference.
I also installed Eq APO to bypass hidden APOs, but nothing changes. And I have seen that it works both with DS, MME and WASAPI (if I apply with -6dB of attenuation for example, I detect it with all used drivers).
Also, similar issue with Foobar. All 100%, yet the Foobar level is -6 dBFS or so. And there is no ReplyGain set (verified).

WHY?!

MME DRIVER

DS DRIVER

WASAPI DRIVER

FOOBAR

Don't look at the scales of the axis because they are incorrect. I had set RTA wrong, but the level analysis window is correct, as well as the spectrum shown.

 

[dasdoing]

I was doing more loopback tests in Windows and noticed a weird thing that I can't explain.
With Audacity I play mono 44.1/16 WAV files with white noise and analyze the loopback in REW RTA through VB Hi-Fi Cable.
ALL, and I mean ALL, the volumes are set to 100%, including those relating to the Windows mixer (yes, all those dozens of adjustments that Windows integrates for no reason).
Yet if in Audacity I set the WASAPI driver instead of MME or DS, in REW I measure about -1 dBFS RMS less.
The strange thing is that if I play a 1kHz tone at a fixed level, there is no such difference.
I also installed Eq APO to bypass hidden APOs, but nothing changes. And I have seen that it works both with DS, MME and WASAPI (if I apply with -6dB of attenuation for example, I detect it with all used drivers).
Also, similar issue with Foobar. All 100%, yet the Foobar level is -6 dBFS or so. And there is no ReplyGain set (verified).

WHY?!

MME DRIVER
View attachment 298731

DS DRIVER
View attachment 298733

WASAPI DRIVER
View attachment 298734

FOOBAR
View attachment 298736

I noticed the Foobar volume diference before. didn't care to much to analise it since I rarely use it.

for the other, make sure you use periodic noises so always the exact same noise hits the analyser

 

[Davide]

It seems that I found the difference.
With Audacity I played two 2Hz - 22kHz sweeps, one sampled at 44.1/16 and one at 192/24, and analyzed the response with the REW RTA.
Please note that my Windows mixer is set to 192/24.
For unknown reason, with 44.1kHz signal and the WASAPI Shared driver there is a roll off starting from 17kHz towards the ultrasonic band, which with full band white noise results in a difference of 1 dBFS RMS.
It is also visible in my previous graphs, although the scale of the axes is wrong.
Don't pay attention to the artifacts because they are due to the first seconds of opening the driver by REW.
Also, the comb pattern is due to the FFT lenght (it's a live averaging of a sweep).

44.1kHz SWEEP with MME/DS DRIVER

44.1kHz SWEEP WASAPI SH. DRIVER (NOTE THE ROLLOFF IN AUDIO BAND)

192kHz SWEEP with MME/DS DRIVER

192kHz SWEEP with WASAPI DRIVER

Honestly, I can't figure out what that WASAPI driver roll off is about.
Can anyone explain to me what the difference is?
To me it seems that with WASAPI driver different oversampling (and consequently LPF) algorithm is applied, but hard to believe that audio path has different resempler.

To recap the flow:
1) two WAV signal at 44.1kHz and 192kHz
2) Audacity as player with project set to 192kHz
3) Audacity output drivers switched from MME/DS/WASAPI
4) VB CABLE HIFI output set at 192kHz/24bit
5) VB CABLE HIFI input set at 192kHz/24bit
6) REW with JAVA driver set at 192kHz
7) REW RTA with 32k FFT

 

[BeerBear]

Foobar having a lower volume is a bug. It was mentioned in this thread too, for example here.

The roll-off in Audacity when using WASAPI looks to be caused by the playback SRC setting (in Preferences under 'Quality').
I guess Audacity resamples the audio to the target rate when using WASAPI, but leaves resampling to Windows when using MME/DS. (Foobar does its own resampling too, by the way.)

 

[Davide]

I managed to get around the problems related to the players and finally carry out the test I wanted.

I compared the Windows resampler to the venerable iZotope RX 10 with DeltaWave, using full band white noise signal sampled at 44.1/16 and upsampled to 192/24.

IZotope resampler & dither was left with the default settings.

Here are the results (stats are from iZotope RX 10 analyzer):

STATS OF ORIGINAL TEST SIGNAL (RANDOM WHITE NOISE FULL BAND MONO 44.1kHz 16bit DITHERED, GENERATED WITH REW)

STATS OF SIGNAL UPSAMPLED AND DITHERED WITH IZOTOPE RX 10

STATS OF SIGNAL LOOPED BACK FROM WINDOWS MIXER @ 192/24 WITH WASAPI SH. DRIVER (VB CABLE HIFI ASIO BRIDGE)

RESULTS OF DELTAWAVE (BLU IS WINDOWS LOOPBACK, WHITE IZOTOPE RX 10)

As can be seen, the big difference in the audible (almost) band lies in the LPF filter of the two resamplers, which causes differences in the order of -60dB towards the cut off frequency.
iZotope's resampler has a less steep rolloff, but starts at exactly 20kHz and has virtually zero residual noise (-160dB).
Windows has some leakage up to 21/22kHz and then attenuates more quickly to almost -130dB.
Tiny phase shifts also appear, I assume in Windows. But they are ridiculous.
Also, Windows produces about 0.5dB more of true peaks level.
Let me say I cannot figure out why iZotope predicted true peaks differ so much, especially compared to the original signal... but this is another matter.

Obviously changing the iZotope resampling settings could vary its results, for better or for worse. I didn't want to experiment too much in this sense because I was mostly interested in the difference in the udible band, not beyond the cutoff nor in the transition band.

And in fact practically in the whole audio band it can be seen that the delta is around -128dBr.
I think PK Metric is -111dBr due to LPF differences.
I'm not sure why they are expressed as dBFS, they should be dBr, but maybe I'm missing something.

EDIT. I tried to apply LPF @ 16kHz with DeltaWave filter function to see if PK Metric improve, but strangely it only goes to -113dBr, although visually the corrected spectrum is around -128dBr.
There will be something in the metric that I don't remember... or its LPF is hitting... maybe @pkane could explain.
Not bad anyway, the difference remains inaudible.

With this test I can say that I consider the Windows resampler to be perfectly functional and completely inaudible.
I can leave Windows at 192/24 and not care about sampling the music I hear from various sources because resampling has no impact anyway.
The only thing to do is disable the limiter or put a few dB attenuation via Eq APO to prevent distortion.

 

[Sokel]

Foobar having a lower volume is a bug. It was mentioned in this thread too, for example here.

The roll-off in Audacity when using WASAPI looks to be caused by the playback SRC setting (in Preferences under 'Quality').
I guess Audacity resamples the audio to the target rate when using WASAPI, but leaves resampling to Windows when using MME/DS. (Foobar does its own resampling too, by the way.)

Have or had?
Can't see any difference in level,it's the exact same:



Multitone



foobar

 

[Davide]

Have or had?
Can't see any difference in level,it's the exact same:

View attachment 298962

Multitone

View attachment 298963

foobar

I haven't done much testing but I have seen that -6dB happens with mono track.

 

[Sokel]

And that's foobar loaded with an array of DSP (sox to 352.8K,Mathaudio EQ,etc) :



1.5db lower

 

[Sokel]

I haven't done much testing but I have seen that -6dB happens with mono track.

Tested mono too,no difference

(all measurements with ASIO drivers,I don't even try with anything else,it's a mess to set-up)

 

[BeerBear]

Have or had?
Can't see any difference in level,it's the exact same:

It's the same for me too, because the bug doesn't happen on my system. And I believe it doesn't happen for most people either.
Whether the bug appears or not I think depends on some specific usage... I forgot the details, but you can find them in the threads on the HA forum.

 

[BeerBear]

I haven't done much testing but I have seen that -6dB happens with mono track.

Oh yeah, it's good that you mentioned this. We're now talking about two different issues here.
Foobar does put out a 6dB lower signal when playing mono tracks over WASAPI shared (I didn't test with ASIO). This is by design and is explained here. That's why I started to use "Convert mono to stereo" in Foobar's DSP a long time ago. I had already forgotten about it.

But there is also a separate issue, a bug, which happens/happened when IIRC the Foobar's volume got stuck at some lower position in the Windows mixer. I refer you to those HA threads for more details, maybe it's already been fixed...