Help my understanding of Digital Volume levels

[JG2020]

Another silly question - Is there software that can capture and record the digital stream before it leaves the USB outlet on the iMac, or does this all have to be done by hardware external to the iMac? I'm assuming the latter due to my limited knowledge of the way the usb bridge works on the motherboard. For now I will box on with recording the SPDIF coax out of the miniDSP and try to understand what I find.

Should be able to do with https://rogueamoeba.com/loopback/ and/or Audio Hijack and Soundsource from same site, in combination with Audacity for Mac.

 

[Mnyb]

Excellent, cant believe I didn't think of it. So I blew the dust off a USB CD drive and plugged into the iMac. Playing the same song that on Spotify would cause the DAC to overload, does not overload when played from the CD through the 'Music (formally iTunes?)' app to the DAC. Stays at -0.1 input level.

Get this. Spotify can play local files too. So ripped that CD to .WAV, loaded into spotify, played it and ... max level -0.1 input AKA not overloading.
Navigate to the stream of the exact same song (not a remaster, not an edit) and what do we get .. Overload. For those that are interested the album I am using is DAMN by Kendrick Lamar, but there are plenty more examples I can give. My music tastes are not up for discussion.

This leads me to believe the spotify stream is forced to be louder/clip for some reason. And when I was putting the miniDSP in the chain, it was truncating the clipping so the output to the DAC was corrected i.e. lowered to not overload the DAC input.


Now to get a Tidal Subscription.. and maybe cancel the spotify supscription after all these years. Shame on you Spotify. Could be jumping the gun here...

You might need more headroom to process lossy content like Spotify . The intersample overshoot problems actually a concern for lossy codes when decoding them . If you turn the volume down just a little does it help ?

Kendrick s music is probably produced close to 0dB you mention -0,1dB

Cue up an old album that does not sound so “loud” avoid a remastered version . Something aviable both on Spotify and and in your CD collection.

Is it possible to turn of “replay gain “ or what Spotify calls the function that equalise loudness between tracks in the MacOS Spotify app ?

I run the “spotty” plugin on logitech media server under Linux and have not noticed excessive overloads , I’ll be on the lookout for this . I do have Damn as lossless hmm....

 

[maverickronin]

You might need more headroom to process lossy content like Spotify . The intersample overshoot problems actually a concern for lossy codes when decoding them . If you turn the volume down just a little does it help ?

Crap. I totally blanked on that.

 

[McFly]

You might need more headroom to process lossy content like Spotify . The intersample overshoot problems actually a concern for lossy codes when decoding them . If you turn the volume down just a little does it help ?

Kendrick s music is probably produced close to 0dB you mention -0,1dB

Cue up an old album that does not sound so “loud” avoid a remastered version . Something aviable both on Spotify and and in your CD collection.

Is it possible to turn of “replay gain “ or what Spotify calls the function that equalise loudness between tracks in the MacOS Spotify app ?

I run the “spotty” plugin on logitech media server under Linux and have not noticed excessive overloads , I’ll be on the lookout for this . I do have Damn as lossless hmm....

Agreed on the intersample overs on lossless comment. But how would that explain no USB overloading when I play the same from the windows 10 laptop Spotify, all else remains equal?

-I ensure that volume normalization aka replay gain is disabled in every instance of the testing, and verify it by enabling it first (which does solve the problem but I do not wish to use it) and examining the volume decreasing on the RME input level meters, the disabling it and again getting the overload conditions.
-Turning down the volume one click in the spotify app indeed fixes the problem, but I want a full unmolested digital signal out to the DAC, thats what got me here.
-DAMN was one example of many many tracks that are "overloading" the input meters on the RME DAC. I will find one with.. more dynamic range I suppose. Some albums behave, for example a classic audiophile one Dire Straits - Dire Straits does not present the overload condition.

I guess what I'm trying to say is that one would assume having Spotifys "volume normalization" disabled would mean the loudest track in their entire library would set the digital volume "ceiling" and present to the DAC as 0.0 input, and anything else would be an equal or lower (quieter) figure.

 

[McFly]

Dual installed mojave. Sigh. Results worse. Mojave seems to upsample everything to 192khz, meaning even more overloading, even on albums which didn't in Catalina, e.g. dire straits. Now my Catalina install plays everything at 192khz...

Time to ditch macOS or try Tidal i suppose in the interest of chasing intersample overloads and digital clipping I might as well be streaming at CD quality..

 

[Blumlein 88]

Read the RME section on its digital volume control. If you can drop the volume on the RME from 0 db to -4db you likely will stop all overs, and you aren't losing anything in sound quality.

Also I forgot the RME has a built in bit test capability to see if bit perfectness is maintained. There are test files you download and explanations of how to use it in the manual.

But to reiterate, just turn down the RME until over's stop. You aren't losing anything.

 

[RayDunzl]

Turning down the volume one click in the spotify app indeed fixes the problem

That would work for me.

 

[Mnyb]

That would work for me.

Yes the spotify app probaly uses 24bit format on the output is it not ? and the RME can use 24 bit the input , so there is no real loss anywhere so you just shift bits . the source is usually 16bit and the odd hires can at best equal 20-21bit in practice . the actual SQ on most music including revered audiophile classics from the analog era rarely hits 16bits i would gues much less like 13 bits .
In case of 16bit master in a 24bit system i think you can lower the volume like -40dB or somesuch before any truncation takes place (and a good digital volume uses dithered conversion and does not simply truncate).
If the gain stagin of you hifi is reasonable the volume at low volumes will be so low that it does not matter anyway

 

[McFly]

That would work for me.

I understand it would for most, and is what I am doing currently. But this is audio science review and not Audio "it'll do" Review. I'm trying to figure out why a spotify stream digitally overloads a DAC from a Mac/iOS machine and not a Windows one. I would ask the question on the spotify forum but really, has anyone seen those forums? They're a shambles.

Read the RME section on its digital volume control. If you can drop the volume on the RME from 0 db to -4db you likely will stop all overs, and you aren't losing anything in sound quality.

Also I forgot the RME has a built in bit test capability to see if bit perfectness is maintained. There are test files you download and explanations of how to use it in the manual.

But to reiterate, just turn down the RME until over's stop. You aren't losing anything.

I also understand this. But I am talking about the input level to the DAC i.e. pre-FX, not post-FX, being overloaded. No volume level at the DAC is going to stop the source from overdriving the signal, just like an analogue preamp with an overloaded input. I am using the ADI 2 DAC direct to a power amplifier.

I am not upset or really bothered by the fact it's happening as there is no audible distortion - most likely due to 'digital headroom' inside the RME's input. I am just trying to understand why it is happening and possibly avoid it, and would it be causing clipping on the outgoing analogue signal, audible or not. In a perfect world, I would set spotifys volume to 100%, and use the DACs volume control. But seeing as Spotifys volume at 100% appears to be more like 101-105%, why would one want that? 100% should be just touching the digital 'ceiling', should it not?

P.S. the "bit-test" files worked perfectly when played from the iMac to the RME DAC, be it from the 'Music' app or played from inside 'Spotify'. I am getting the overloads from streamed songs, only on an iMac/iOS device.

 

[bennetng]

-Turning down the volume one click in the spotify app indeed fixes the problem, but I want a full unmolested digital signal out to the DAC, thats what got me here.

There is no such thing as "unmolested" lossy. Even if the master is quiet enough and there is no 0dBFS+ actual sample values in the decoded waveform, different decoders still decode differently when using 100% volume.
https://www.audiosciencereview.com/...tively-best-most-compliant-mp3-decoder.10886/

Would it be easier if I use lossy video as example?
https://www.audiosciencereview.com/forum/index.php?threads/hi-res-8k-magic.4953/post-110857

 

[McFly]

There is no such thing as "unmolested" lossy. Even if the master is quiet enough and there is no 0dBFS+ actual sample values in the decoded waveform, different decoders still decode differently when using 100% volume.
https://www.audiosciencereview.com/...tively-best-most-compliant-mp3-decoder.10886/

Would it be easier if I use lossy video as example?
https://www.audiosciencereview.com/forum/index.php?threads/hi-res-8k-magic.4953/post-110857

So the windows machine that plays the spotify stream to the DAC and never presents an overload level into the DAC is truncating the spotify stream in the windows USB audio drivers before it is passed to the dac USB input, and the iMAC is just sending the stream straight into the DAC which happens to have intersample overs due to the lossy nature of the stream? Am I getting close?

 

[Mnyb]

It is interesting why it works on windows and not spotify ! it sure must be in the spotify app .

Sadly i've seen spotifys forums , they are not conductive to any serius discussions at all.
Mostly because their wierd and buggy software on every platform and they never fix bugs so everyone is desperate , strange decision's regarding functions and features that comes and goes and many features that really anoys everyone so it turn into whining contest

 

[bennetng]

So the windows machine that plays the spotify stream to the DAC and never presents an overload level into the DAC is truncating the spotify stream in the windows USB audio drivers before it is passed to the dac USB input, and the iMAC is just sending the stream straight into the DAC which happens to have intersample overs due to the lossy nature of the stream? Am I getting close?

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.

 

[Blumlein 88]

I understand it would for most, and is what I am doing currently. But this is audio science review and not Audio "it'll do" Review. I'm trying to figure out why a spotify stream digitally overloads a DAC from a Mac/iOS machine and not a Windows one. I would ask the question on the spotify forum but really, has anyone seen those forums? They're a shambles.



I also understand this. But I am talking about the input level to the DAC i.e. pre-FX, not post-FX, being overloaded. No volume level at the DAC is going to stop the source from overdriving the signal, just like an analogue preamp with an overloaded input. I am using the ADI 2 DAC direct to a power amplifier.

I am not upset or really bothered by the fact it's happening as there is no audible distortion - most likely due to 'digital headroom' inside the RME's input. I am just trying to understand why it is happening and possibly avoid it, and would it be causing clipping on the outgoing analogue signal, audible or not. In a perfect world, I would set spotifys volume to 100%, and use the DACs volume control. But seeing as Spotifys volume at 100% appears to be more like 101-105%, why would one want that? 100% should be just touching the digital 'ceiling', should it not?

P.S. the "bit-test" files worked perfectly when played from the iMac to the RME DAC, be it from the 'Music' app or played from inside 'Spotify'. I am getting the overloads from streamed songs, only on an iMac/iOS device.

Actually with digital if you are suffering from intersample overs turning down the volume prevents those. Unlike an analog preamp.

Since it now seems okay with Windows and not with Mac, then the two datastreams are different. The question would be why. You can take a digital file and normalize it to 0 db. That means no sample values are above 0 db obviously. However upon playback some waveforms will peak above 0 db and be overs. So is Spotify doing this to files? Is Windows changing values to prevent overs? I don't know. For playback it really doesn't matter. Just turn down the volume with a Mac/IOS device in use.

 

[hyperplanar]

OP please open Audio MIDI Setup in Applications > Utilities and make sure your sample rate is set to 44.1 KHz. I tried Spotify on macOS with volume normalization off playing the Kendrick album and it never passes -0.0. On the other hand if I set my interface to a different sample rate it readily passes 0 dBFS, probably because the CoreAudio resampler works in floating point or has headroom otherwise allowing those peaks to come through instead of being clipped at 0 dBFS.

It's not possible for Spotify to output anything over 0 dBFS, but processes afterwards such as OS resampling can certainly change that. Basically the signal flow goes something like this:

Spotify OGG decode/ReplayGain normalization (16-bit integer output) -> Spotify volume control (24-bit integer output) -> OS audio subsystem (potential resampling in float) -> audio interface input

The output that Spotify passes out from its ogg decoder is 16-bit integer, and stays so even if volume normalization is used (hence a potential loss of resolution, although negligible unless you're using the quiet setting which normalizes to -23 LUFS I think). The problem is that if normalization isn't used, this leaves no headroom so any full-sample overs are clipped when decoding.

Spotify's volume control (separate from the normalization function) does operate in 24-bit, but lowering Spotify's volume won't recover those clipped peaks from the 16-bit decoding stage. So really there's no way to win here: normalization off clips FS overs produced by the Vorbis compression, normalization on normal dynamically limits any song quieter than -14 LUFS's peaks to -1 dBFS and sounds bad in the process, normalization on quiet rarely limits songs as not many songs are quieter than -23 LUFS, but you lose out on resolution here since the normalization is done in 16 bits.

Ideally the signal flow would be:

Spotify OGG decode/ReplayGain normalization (32-bit floating point output) -> Spotify volume control (32-bit floating point output) -> OS audio subsystem

Then all the potential causes of clipping can be addressed by lowering the digital volume on your interface or in Spotify.

 

[McFly]

OP please open Audio MIDI Setup in Applications > Utilities and make sure your sample rate is set to 44.1 KHz. I tried Spotify on macOS with volume normalization off playing the Kendrick album and it never passes -0.0. On the other hand if I set my interface to a different sample rate it readily passes 0 dBFS, probably because the CoreAudio resampler works in floating point or has headroom otherwise allowing those peaks to come through instead of being clipped at 0 dBFS.

It's not possible for Spotify to output anything over 0 dBFS, but processes afterwards such as OS resampling can certainly change that. Basically the signal flow goes something like this:

Spotify OGG decode/ReplayGain normalization (16-bit integer output) -> Spotify volume control (24-bit integer output) -> OS audio subsystem (potential resampling in float) -> audio interface input

The output that Spotify passes out from its ogg decoder is 16-bit integer, and stays so even if volume normalization is used (hence a potential loss of resolution, although negligible unless you're using the quiet setting which normalizes to -23 LUFS I think). The problem is that if normalization isn't used, this leaves no headroom so any full-sample overs are clipped when decoding.

Spotify's volume control (separate from the normalization function) does operate in 24-bit, but lowering Spotify's volume won't recover those clipped peaks from the 16-bit decoding stage. So really there's no way to win here: normalization off clips FS overs produced by the Vorbis compression, normalization on normal dynamically limits any song quieter than -14 LUFS's peaks to -1 dBFS and sounds bad in the process, normalization on quiet rarely limits songs as not many songs are quieter than -23 LUFS, but you lose out on resolution here since the normalization is done in 16 bits.

Ideally the signal flow would be:

Spotify OGG decode/ReplayGain normalization (32-bit floating point output) -> Spotify volume control (32-bit floating point output) -> OS audio subsystem

Then all the potential causes of clipping can be addressed by lowering the digital volume on your interface or in Spotify.

Thank you.

 

[McFly]

I think windows is changing the stream to prevent the overs leaving the usb outlet. As per

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.

 

[hyperplanar]

I think windows is changing the stream to prevent the overs leaving the usb outlet. As per

Can’t test this right now but I suspect the input to the DAC has no headroom in Windows so it caps out at 0 dBFS, even after resampling which would produce peaks higher than that. So those peaks would just be chopped off.

If this isn’t the case and Windows does output with headroom to the DAC, then maybe each audio source is individually limited to 0 dBFS, even after resampling.

 

[SPiTFiREgr]

OP please open Audio MIDI Setup in Applications > Utilities and make sure your sample rate is set to 44.1 KHz. I tried Spotify on macOS with volume normalization off playing the Kendrick album and it never passes -0.0. On the other hand if I set my interface to a different sample rate it readily passes 0 dBFS, probably because the CoreAudio resampler works in floating point or has headroom otherwise allowing those peaks to come through instead of being clipped at 0 dBFS.

It's not possible for Spotify to output anything over 0 dBFS, but processes afterwards such as OS resampling can certainly change that. Basically the signal flow goes something like this:

Spotify OGG decode/ReplayGain normalization (16-bit integer output) -> Spotify volume control (24-bit integer output) -> OS audio subsystem (potential resampling in float) -> audio interface input

The output that Spotify passes out from its ogg decoder is 16-bit integer, and stays so even if volume normalization is used (hence a potential loss of resolution, although negligible unless you're using the quiet setting which normalizes to -23 LUFS I think). The problem is that if normalization isn't used, this leaves no headroom so any full-sample overs are clipped when decoding.

Spotify's volume control (separate from the normalization function) does operate in 24-bit, but lowering Spotify's volume won't recover those clipped peaks from the 16-bit decoding stage. So really there's no way to win here: normalization off clips FS overs produced by the Vorbis compression, normalization on normal dynamically limits any song quieter than -14 LUFS's peaks to -1 dBFS and sounds bad in the process, normalization on quiet rarely limits songs as not many songs are quieter than -23 LUFS, but you lose out on resolution here since the normalization is done in 16 bits.

Ideally the signal flow would be:

Spotify OGG decode/ReplayGain normalization (32-bit floating point output) -> Spotify volume control (32-bit floating point output) -> OS audio subsystem

Then all the potential causes of clipping can be addressed by lowering the digital volume on your interface or in Spotify.

That is the single post of truth in this thread. Mojave or any macOS doesn't "resample everything" on it's own.

CoreAudio is by far the most transparent framework for handling audio. The Spotify app fetches the 320kbit/s Ogg Vorbis streams from it's CDN, decodes them, applies the Loudness Normalisation (if enabled), applies any Gain adjustment (if set) and feeds the 24-bit stream to CoreAudio. That's it for Spotify, that's it for any app on your system. You have to then check your CoreAudio/Device driver/DAC settings

P.S. It's really funny how the blame game rotated. Cancelling Spotify to get a Tidal subscription -> Uninstalling Catalina to get Mojave -> Stop using macOS to get Windows, what's next? Suing RME?

 

[Ron Kuper]

OP please open Audio MIDI Setup in Applications > Utilities and make sure your sample rate is set to 44.1 KHz. I tried Spotify on macOS with volume normalization off playing the Kendrick album and it never passes -0.0. On the other hand if I set my interface to a different sample rate it readily passes 0 dBFS, probably because the CoreAudio resampler works in floating point or has headroom otherwise allowing those peaks to come through instead of being clipped at 0 dBFS.

It's not possible for Spotify to output anything over 0 dBFS, but processes afterwards such as OS resampling can certainly change that. Basically the signal flow goes something like this:

Spotify OGG decode/ReplayGain normalization (16-bit integer output) -> Spotify volume control (24-bit integer output) -> OS audio subsystem (potential resampling in float) -> audio interface input

The output that Spotify passes out from its ogg decoder is 16-bit integer, and stays so even if volume normalization is used (hence a potential loss of resolution, although negligible unless you're using the quiet setting which normalizes to -23 LUFS I think). The problem is that if normalization isn't used, this leaves no headroom so any full-sample overs are clipped when decoding.

Spotify's volume control (separate from the normalization function) does operate in 24-bit, but lowering Spotify's volume won't recover those clipped peaks from the 16-bit decoding stage. So really there's no way to win here: normalization off clips FS overs produced by the Vorbis compression, normalization on normal dynamically limits any song quieter than -14 LUFS's peaks to -1 dBFS and sounds bad in the process, normalization on quiet rarely limits songs as not many songs are quieter than -23 LUFS, but you lose out on resolution here since the normalization is done in 16 bits.

Ideally the signal flow would be:

Spotify OGG decode/ReplayGain normalization (32-bit floating point output) -> Spotify volume control (32-bit floating point output) -> OS audio subsystem

Then all the potential causes of clipping can be addressed by lowering the digital volume on your interface or in Spotify.

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?