Help my understanding of Digital Volume levels

[hyperplanar]

Do you think going through VoiceMeeter change something in this regard?
Does it means VoiceMeeter, if used and to be optimized with Spotify, needs to be set with "Preferred Main SampleRate" of 44100Hz?
Will that be at the expense of other application sources which play higher sampling rates?
Is it relevant assuming that Spotify doesn't open the VoiceMeeter VAIO in exclusive mode?

Sorry, I've never used VoiceMeeter personally, so I'm not too familiar with the specifics. That being said, if Spotify is your main music source, it makes sense to set the default sample rate to 44.1 kHz. You'll avoid the possibility of >0 dBFS peaks produced by resampling getting clipped/limited somewhere in the Windows audio subsystem.
This does mean that higher sample rate sources will get resampled down to 44.1 kHz, but these "high res" sources tend to have a lot of headroom anyway, so it's less likely that you'll get clipped resampled peaks. On the other hand, tons of music on Spotify is mastered as hot as possible and has little headroom.

 

[Ron Kuper]

Thanks, makes sense.

Sharing more information I've gathered:
I've tested Roon with Tidal Hifi and it is getting 44.1 from Tidal (might be content dependent). So I guess 44.1 is the best option for me.

Also -VoiceMeeter (potato) doesn't seem to match to source app's sampling rate even if I use A2 - It uses the main sampling rate with the audio interface. Would've been nice if it did so we could have ideal sampling rates for each app.

 

[Degru]

Windows have something like this to avoid clipping:
https://matthewvaneerde.wordpress.c...audiometerinformation-and-full-scale-signals/

This processing can be bypassed by using WASAPI exclusive mode or ASIO.

Do you know at what stage this limiter is being applied? Mainly wondering if I would need to lower the volume in the music player itself or if I can just apply -1db preamp in EQ APO.

 

[bennetng]

Do you know at what stage this limiter is being applied? Mainly wondering if I would need to lower the volume in the music player itself or if I can just apply -1db preamp in EQ APO.

Try these files:
https://www.audiosciencereview.com/...y-of-software-volume-control.5922/post-172865

Specific to your question, you should use b.mp3 as the undistorted reference, then adjust the volume of a.mp3 so that it sounds like b.mp3. Try and see which volume control can achieve this goal in your shared mode + EQ APO configuration.

 

[Degru]

Try these files:
https://www.audiosciencereview.com/...y-of-software-volume-control.5922/post-172865

Specific to your question, you should use b.mp3 as the undistorted reference, then adjust the volume of a.mp3 so that it sounds like b.mp3. Try and see which volume control can achieve this goal in your shared mode + EQ APO configuration.

I think that test isn't quite relevant. It is more of a test of whether the MP3 decoder and music player use floating point for internal processing or not. AFAIK the output from the player to Windows is fixed-point so anything higher than 1 will be clipped off right at the source, and has nothing to do with the volume control(s) or limiters applied afterwards. This can be seen if you simply convert a.mp3 to a regular WAV file as well.

However, I did devise a more proper test. I generated a 0db 1khz sine wave in Audacity, then played it through VB-Audio Hifi Cable via DirectSound. Recording it back into audacity resulted in -0.128dB. However, applying -1db preamp in EQ APO resulted in exactly -1db output, so it appears that EQ APO does appear to prevent the limiting from happening.

It should be noted that this should be applied with EQ APO rather than Windows volume, since the Windows volume slider will control different things depending on what DAC you're using (and I'm not sure if Windows software attenuation happens before or after the limiter, since I cannot get exact attenuation to specific decibel values with the Windows slider)

Sadly there is also still some distortion added around -100db regardless of what I do, so DirectSound is not capable of "bit perfect" even with attenuation. But at least it's a little more optimized this way.

 

[bennetng]

I think that test isn't quite relevant. It is more of a test of whether the MP3 decoder and music player use floating point for internal processing or not. AFAIK the output from the player to Windows is fixed-point so anything higher than 1 will be clipped off right at the source, and has nothing to do with the volume control(s) or limiters applied afterwards. This can be seen if you simply convert a.mp3 to a regular WAV file as well.

However, I did devise a more proper test. I generated a 0db 1khz sine wave in Audacity, then played it through VB-Audio Hifi Cable via DirectSound. Recording it back into audacity resulted in -0.128dB. However, applying -1db preamp in EQ APO resulted in exactly -1db output, so it appears that EQ APO does appear to prevent the limiting from happening.

It should be noted that this should be applied with EQ APO rather than Windows volume, since the Windows volume slider will control different things depending on what DAC you're using (and I'm not sure if Windows software attenuation happens before or after the limiter, since I cannot get exact attenuation to specific decibel values with the Windows slider)

Sadly there is also still some distortion added around -100db regardless of what I do, so DirectSound is not capable of "bit perfect" even with attenuation. But at least it's a little more optimized this way.

See this video from 3:40, very carefully:

It is a flac as indicated in foobar's status bar, and it is a 16-bit flac, so it has nothing to do with floating point mp3 decoding. You can see that when using DirectSound, the volume control of foobar, regardless of volume level, always produce artifacts. The only way to eliminate this is changing the ReplayGain preamp value. That's because when using DirectSound, foobar's volume control doesn't belong to foobar itself, it is actually windows mixer's per-application volume control.

Then read this:
https://www.audiosciencereview.com/...mpling-not-actually-that-bad.9092/post-257717

You can see that with a little bit of volume adjustment from the audio player, artifacts are far below -100dB, so if you only get "some distortion added around -100db", your signal chain is far from ideal. Just in case you wonder the settings for my MPC-HC, here are some screenshots:

"System Default" means the audio device is same as the one being chosen in Windows' OS audio properties. If there is a need, you can change it to others.

 

[Degru]

See this video from 3:40, very carefully:

It is a flac as indicated in foobar's status bar, and it is a 16-bit flac, so it has nothing to do with floating point mp3 decoding. You can see that when using DirectSound, the volume control of foobar, regardless of volume level, always produce artifacts. The only way to eliminate this is changing the ReplayGain preamp value. That's because when using DirectSound, foobar's volume control doesn't belong to foobar itself, it is actually windows mixer's per-application volume control.

Then read this:
https://www.audiosciencereview.com/...mpling-not-actually-that-bad.9092/post-257717

You can see that with a little bit of volume adjustment from the audio player, artifacts are far below -100dB, so if you only get "some distortion added around -100db", your signal chain is far from ideal. Just in case you wonder the settings for my MPC-HC, here are some screenshots:
View attachment 98328

"System Default" means the audio device is same as the one being chosen in Windows' OS audio properties. If there is a need, you can change it to others.
View attachment 98329

My signal chain was a purely software-based bit-perfect digital loopback. It literally cannot get more ideal than that, but I may have misconfigured something.

The test in the video is completely different from what you sent, which was an MP3 file that was clipped because it contained values outside of 0-1.

Anyways, I would be curious to see the test in the video reproduced using EQ APO's preamp to lower volume instead of the replaygain. I merely want to see if there is a system-wide way of accomplishing it instead of relying on whatever software volume a given app may or may not have.

 

[bennetng]

My signal chain was a purely software-based bit-perfect digital loopback. It literally cannot get more ideal than that, but I may have misconfigured something.

The test in the video is completely different from what you sent, which was an MP3 file that was clipped because it contained values outside of 0-1.

Anyways, I would be curious to see the test in the video reproduced using EQ APO's preamp to lower volume instead of the replaygain. I merely want to see if there is a system-wide way of accomplishing it instead of relying on whatever software volume a given app may or may not have.

Just in case you don't know, I am the uploader of the video, in this post:
https://www.audiosciencereview.com/...y-of-software-volume-control.5922/post-132450

As a matter of fact, both foobar and MPC-HC decode these lossy codecs to floating point PCM, then apply volume control (gain) within the player and send to the output. I can simply use plain floating point PCM files but they are too big to attach on this forum and plain floating point PCM files are not widely used as a consumer format. In the case of MPC-HC, apart from DirectSound, it also supports other shared mode API (MME and "internal", the base of shared mode). In either case, if you are able to attenuate the float data to somewhere below 0.98, then the limiter will not be triggered. That means the "clipped" mp3 file can be reverted by using the player's internal gain.

The "clipped" mp3 file, when played with WASAPI exclusive mode or ASIO with full volume, is supposed to be hard-clipped. When played with shared modes, the limiter could be activated and the file could become hyper-compressed instead of hard-clipped, so listen for this difference to judge if the limiter is in effect or not, instead of simply looking at level like this...

Recording it back into audacity resulted in -0.128dB. However, applying -1db preamp in EQ APO resulted in exactly -1db output

If you are always getting artifacts at around -100dB then your signal chain is compromised, even for shared mode and audio data within +/-1.0. That's for sure. So check about it.

 

[Degru]

Just in case you don't know, I am the uploader of the video, in this post:
https://www.audiosciencereview.com/...y-of-software-volume-control.5922/post-132450

As a matter of fact, both foobar and MPC-HC decode these lossy codecs to floating point PCM, then apply volume control (gain) within the player and send to the output. I can simply use plain floating point PCM files but they are too big to attach on this forum and plain floating point PCM files are not widely used as a consumer format. In the case of MPC-HC, apart from DirectSound, it also supports other shared mode API (MME and "internal", the base of shared mode). In either case, if you are able to attenuate the float data to somewhere below 0.98, then the limiter will not be triggered. That means the "clipped" mp3 file can be reverted by using the player's internal gain.

The "clipped" mp3 file, when played with WASAPI exclusive mode or ASIO with full volume, is supposed to be hard-clipped. When played with shared modes, the limiter could be activated and the file could become hyper-compressed instead of hard-clipped, so listen for this difference to judge if the limiter is in effect or not, instead of simply looking at level like this...



If you are always getting artifacts at around -100dB then your signal chain is compromised, even for shared mode and audio data within +/-1.0. That's for sure. So check about it.

Yes I was aware you were the uploader.

I guess I misunderstood things. I tried something else.

I played file in foobar, into my normal DAC, through directsound. My Windows settings for the DAC are set to 44100hz, 32bit.

I recorded the result in Audacity directly from the output device with its "WASAPI" option. This eliminates any third party software from the equation. It also appears to record the audio in floating point 32 bit, *before* the limiter is applied but *after* EQ APO takes effect. This seemingly clears up the order that the audio travels along the chain of APO's acting on it. It also proves me wrong; foobar does in fact output floating point to Windows. This means applying a preamp in EQ APO does prevent the limiter from kicking in, which answers my original question.

Listening to the audio, I actually get very compressed rather than clipped playback. I am unsure why I was getting clipped audio before; perhaps I had WASAPI output set by accident.

 

[DDF]

In computer digital audio, digital clipping can be caused without explicitly adding gain, by:

• intersample overs on any audio stream upsampled: ie an input at a lower sample rate than the system sample rate
• envelope waveform gain created simply by a lossy filtering task itself, such as a high pass. This is shown here, where a lossy high pass filter changes the phase relationship between frequency components and causes envelope gain depending on the signal.

In EAPO, a pre-amp can be set (eg -4 dB), to help avoid clipping over the vast majority of both of these use cases

Unfortunately, the window audio stack also includes a hard limiter, CAudioLimiter that causes any signal above -0.2dBFS to hard clip even if the file is clean and there is no other processing. More info here and here. So if a digital file is mastered to be normalized to ~ 0dBFS (loudness wars!), it needs to be attenuated at least 0.2 dB before it sees Windows CAudioLimiter.

CAudioLimiter must before the Windows mixer output to be effective. EAPO's pre-amp wouldn't protect from CAudioLimiter as it operates on the audio stream after the mixer (one filter works on all streams simultaneously).

So, how to protect from CAudioLimiter? An obvious choice is to set every single application volume at at least -0.2 dB.

EAPO also provides processing before the mixer (pre-mix stage, info here):

EAPO doesn't document if pre-mix processing is before CAUdioLimiter. Out of curiosity, has anyone looked into this (@bennetng ?)

PS WASAPI and ASIO aren't options here, this scenario applies to a system with filtering

 

[DDF]

Apologies for the earlier premature "send", post is complete now

 

[bennetng]

EAPO doesn't document if pre-mix processing is before CAUdioLimiter. Out of curiosity, has anyone looked into this (@bennetng ?)

Strange that your "@" did not show up in "Alert" after I logged in, I think I already enabled the alert function correctly.

I already have another virtual audio device installed (BASSMIDI), my soundcard also has a proprietary driver with hardware routing and effect support so I don't want to further clutter my system by installing EQ APO, but you can read this thread, try the test files and read the replies to determine where the limiter is located in your specific environment, and how to get rid of it. From what I read the claim that EQ APO creates distortion at around -100dB is hardly ideal, regardless of audibility. Windows mixer also works in floating point and is able to do better than that. As I have not tried EQ APO myself I am not sure if it is caused by the limiter or something else specific to EQ APO.

And no, CAudioLimiter is not always active when not using exclusive mode, as there are many shared modes and different implementations in different software. For example, my old (2004) Adobe Audition 1.5 was released before Windows Vista and it does not support WASAPI exclusive mode, but it is not affected by CAudioLimiter.

 

[DDF]

Thanks for the response. Yes, I'm aware windows mixer is floating point (it would be a disaster otherwise).

A couple years back, I tested EAPOs distortion plus noise performance in digital loopback, running the system at 24 bit 44.1. It was faultless running a simple biquad notch, it just executed the biquad filtering with no truncation or distortion. So I can't agree with other poster's claim that it truncates to 13 bits by default, my measures showed otherwise. However, it uses 32 bit single precision floating point math and I guess it is possible to bump up against the limits of that. See here. It's worth exploring where that limit is.

Prior to posting I had tried your a,b test but it was inconclusive. I'll look more closely at the waveform in Audacity and report back if anything new pops up.

Can you confirm that CAudioLimiter isn't active in shared mode by default, with Win10? I researched before posting and all that I could find was one claim from 2011 that it was. I can't think of why Windows would constrain it's application to exclusive mode.

Thanks for pointing out the other thread as I wasn't aware of it despite searching before posting. Maybe @BDWoody wants to move this thread there?

 

[bennetng]

Can you confirm that CAudioLimiter isn't active in shared mode by default, with Win10? I researched before posting and all that I could find was one claim from 2011 that it was. I can't think of why Windows would constrain it's application to exclusive mode.

I don't think I can confirm anything. For example, I posted a Youtube video showing the limiter in action when using the DS output, but that's from an older version of foobar (1.5x). Since 1.6 foobar dumped the DS output and uses WASAPI shared mode out of the box and the limiter now works in a different (better) way: There is no need to rely on ReplayGain preamp/metadata to defeat the limiter, foobar's built-in volume control can deal with it provided there is enough attenuation.

https://www.foobar2000.org/changelog

1.6
Default output mode is now WASAPI shared.
Removed mixer volume sync feature due to bugs.

1.6.1
Changing volume no longer affects Windows Mixer sliders; restarting foobar2000 no longer resets Windows Mixer slider to 100%.

1.6.2
Added workaround for too quiet playback since removal of Windows Mixer volume slider synchronization in previous versions.

Obviously, the changes are based on (potentially conflicting) feedback from different users, so the developers checked if the Windows mixer can visually reflect the volume settings or not. Which means mixer value is changed by external apps, but the mixer UI did not reflect the changes.

The change from DS to WASAPI shared mode was inspired by this developer, he also mentioned about the limiter, in 2019:
https://hydrogenaud.io/index.php?topic=116739.msg967977#msg967977

 

[Mistake]

I think that test isn't quite relevant. It is more of a test of whether the MP3 decoder and music player use floating point for internal processing or not. AFAIK the output from the player to Windows is fixed-point so anything higher than 1 will be clipped off right at the source, and has nothing to do with the volume control(s) or limiters applied afterwards. This can be seen if you simply convert a.mp3 to a regular WAV file as well.

However, I did devise a more proper test. I generated a 0db 1khz sine wave in Audacity, then played it through VB-Audio Hifi Cable via DirectSound. Recording it back into audacity resulted in -0.128dB. However, applying -1db preamp in EQ APO resulted in exactly -1db output, so it appears that EQ APO does appear to prevent the limiting from happening.

It should be noted that this should be applied with EQ APO rather than Windows volume, since the Windows volume slider will control different things depending on what DAC you're using (and I'm not sure if Windows software attenuation happens before or after the limiter, since I cannot get exact attenuation to specific decibel values with the Windows slider)

Sadly there is also still some distortion added around -100db regardless of what I do, so DirectSound is not capable of "bit perfect" even with attenuation. But at least it's a little more optimized this way.

Hi, Degru

I also meet same problem with -0.13 dB and do some research. I use foobar2000 v1.6 (default output mode (WASAPI shared)) to play signals and GoldWave v6.52 to record it. Why GoldWave? Because it has option to record digital loopback. So it able to record all played digital data including constant non zero levels which always removed when you do analog recording. And of course it didnt record any noise. Initialy, I generate -1 dBFS sine wave play it and record. Recorded level was exact -1 dBFS. I align played and recorded data in time and subtract one from another. I got total cancelling, I mean totally zeros in all samples, no any residual noise or distortions.
Next, I generate full scale (0 dBFs) sine wave play it and record. Recorded peak level was -0.13 dBFS. After aligning and subtraction I found that each time waveform becomes greater than -0.2 dBFS (sample value=32021 for 16 bit signed integer) it becomes soft clipped! It clearly seen how it was done, soft exponential ramp, gain adjustment and release. Moreover, this softclipping stops to affect signal only when waveform goes down to ~-6 dBFS. In spectrum I see harmonics from clipping. And this is audible distortion. In ABX test I clearly differ 0dBFS sine wave and -0.26 dBFS sinewave (scale factor 0.97, no influence from clipping) by introduced distortions (ABX test, 0% of errors). With WASAPI event output mode I didn't hear diffecence, it abscent or inaudible.
It better to use something like SPDIF for digital feedback, it allows to check WASAPI event output. I play data by foobar with WASAPI event mode to external USB soundcard with SPDIF. I record SPDIF data by oscilloscope and decode it (yes I know how to do it) and check output sample values - it exact same. So WASAPI shared mode is definitly NOT bit perfect output. WASAPI event/push do bit perfect (not almost sure).

 

[Degru]

Hi, Degru

I also meet same problem with -0.13 dB and do some research. I use foobar2000 v1.6 (default output mode (WASAPI shared)) to play signals and GoldWave v6.52 to record it. Why GoldWave? Because it has option to record digital loopback. So it able to record all played digital data including constant non zero levels which always removed when you do analog recording. And of course it didnt record any noise. Initialy, I generate -1 dBFS sine wave play it and record. Recorded level was exact -1 dBFS. I align played and recorded data in time and subtract one from another. I got total cancelling, I mean totally zeros in all samples, no any residual noise or distortions.
Next, I generate full scale (0 dBFs) sine wave play it and record. Recorded peak level was -0.13 dBFS. After aligning and subtraction I found that each time waveform becomes greater than -0.2 dBFS (sample value=32021 for 16 bit signed integer) it becomes soft clipped! It clearly seen how it was done, soft exponential ramp, gain adjustment and release. Moreover, this softclipping stops to affect signal only when waveform goes down to ~-6 dBFS. In spectrum I see harmonics from clipping. And this is audible distortion. In ABX test I clearly differ 0dBFS sine wave and -0.26 dBFS sinewave (scale factor 0.97, no influence from clipping) by introduced distortions (ABX test, 0% of errors). With WASAPI event output mode I didn't hear diffecence, it abscent or inaudible.
It better to use something like SPDIF for digital feedback, it allows to check WASAPI event output. I play data by foobar with WASAPI event mode to external USB soundcard with SPDIF. I record SPDIF data by oscilloscope and decode it (yes I know how to do it) and check output sample values - it exact same. So WASAPI shared mode is definitly NOT bit perfect output. WASAPI event/push do bit perfect (not almost sure).

Thanks for confirming. Very interesting to know that the limiter doesn't turn off until it drops that low. Would explain why it is such an audible effect across all kinds of music.

 

[bennetng]

Another example with real music (makes more sense as real music have rapid changing peaks) to show the limiter in action:
https://www.audiosciencereview.com/...-music-players-foobar-jriver.7412/post-188141

 

[Monstieur]

CoreAudio on macOS accepts 32-bit float exclusively. All applications including Safari, iTunes, and Spotify can thus output above 0 dBFS without clipping. The decoders in these apps are also typically 32-bit float and not integer, so they can output above 0 dBFS to CoreAudio without resampling or clipping.

If the output device supports 32-bit float such as on the ADI-2 DAC, CoreAudio passes the audio through without resampling or clipping and you'll see overloads in TotalMix FX. You can then attenuate the audio within TotalMix FX to avoid clipping. macOS preserves the fidelity of the audio throughout the chain and lets the output device handle clipping. The fact that you see overloads on the device is a good thing - you can attenuate the audio at which ever stage you want to avoid clipping.

If the output device supports only integer, CoreAudio will resample and clip the output if required.

On Windows, WASAPI accepts both 32-bit float and integer, so integer output applications may clip the audio internally. In addition to this, CAudioLimiter clips all full-scale audio when the output device is integer. I don't know if CAudioLimiter is bypassed with a 32-bit float output device.