Let's develop an ASR inter-sample test procedure for DACs!

[erazortt]

According to the SDK documentation it should be available. Or at least it should be possible to do if the application (wiim in this case) chooses to do so. From changelog:

SpStreamInfo:

But its the Spotify App from Spotify I am using, on my phone. And this does not allow for that. If their own app does not do that, what is the chance that some manufacturer will implement this.

And is this SDK really for spotify connect? Or for the development of an App to be run inside the device? Because I am talking about Spotify Connect and not the app insde the Wiim. Spotify and Tidal Connect are not dependent on the App inside the Wiim. And I think most people use it that way. Because like this you just use the app you already have installed on the phone, in this case Spoify. Tidal does the same thing. That is especially useful for guests who want to play some of their music.

 

[erazortt]

And how does it look with volume normalization enabled?

And also, do you think that spotify has different tracks, one for without normaliztion and one with? And then one for the "Quiet", one for "Normal" and one for the "Loud" setting? I can hardly believe that. Why should they? I bet they are using the same unnormalized track, transmit that to the device, decode that there, and only then apply those settings. But as I said, non of these settings exist if you use Spotify Connect (via the official Spotify app from Spotify).

 

[danadam]

But its the Spotify App from Spotify I am using, on my phone. And this does not allow for that. If their own app does not do that, what is the chance that some manufacturer will implement this.

AFAIU Spotify Connect means that you can control the device from the spotify app on your mobile. In order to do that, there has to be a code running on the device and that code uses the SDK. That code, in the nomenclature of the SDK is called "Application":

Application The partner code that uses the eSDK.

And that's what I meant in my comment.

And also, do you think that spotify has different tracks, one for without normaliztion and one with?

No, they have a single track, which the client (desktop) decodes to PCM in float format and then applies the normalization. So if there are samples which end up greater than 1.0 after decoding, they won't be clipped when the normalization is enabled.

 

[erazortt]

No, they have a single track, which the client (desktop) decodes to PCM in float format and then applies the normalization. So if there are samples which end up greater than 1.0 after decoding, they won't be clipped when the normalization is enabled.

Well but then the damage on the track was already done since with spotify we are now talking about lossy compression. And lossy compression creates its own overshoots, which are also not only intersample, but real sample overshoots. So if the track is that loud during encoding, then there is no way to heal that. I have explicitly used Spotify Connect, to be sure to get the real track and not a post processed version of it which might have gotten volume changes before being trasmitted via SPDIF.

Here the showcase what lossy compression does with loud tracks. You see the waveform of the original flac track from my previous post, now I have decreased its volume by 3db, converted that to aac (maximal bitrate) and then zoomed into the (decoded) waveform:

Everything above the red line are actual samples which are higher then -3dBFS. But since I encoded the original at -3dBFS, all those would have needed to be above 0dBFS, and since thats not possible it would have been clippings. And we are talking actual samples here, not intersample peaks. This is the issue with lossy compression, if the original too close to 0dBFS.

So coming back to the discussion. This is why lossy compression compounds the problem of intersample peaks. Becasue if we are already that loud that those intersample peaks are a problem, what happens when we additionally get clipping from the decoder because it would have wanted to put real samples above 0dBFS.

 

[danadam]

So if the track is that loud during encoding, then there is no way to heal that.

Of course there is. It is exactly what I wrote in what you quoted. Decode it to PCM in float format and reduce the volume before converting to integer format. Here are some examples:

What exactly happens to a master after it's been sent to Spotify?

I was reading ASR’s thread on inter-sample overs, and one of the things that caught my attention was that peaks over 0dBFS are not just caused by oversampling but also by lossy encoding, among other things. I use Spotify to listen to most of my music, and I’ve always kept audio normalization...

www.audiosciencereview.com

 

[erazortt]

Of course there is. It is exactly what I wrote in what you quoted. Decode it to PCM in float format and reduce the volume before converting to integer format. Here are some examples:

What exactly happens to a master after it's been sent to Spotify?

I was reading ASR’s thread on inter-sample overs, and one of the things that caught my attention was that peaks over 0dBFS are not just caused by oversampling but also by lossy encoding, among other things. I use Spotify to listen to most of my music, and I’ve always kept audio normalization...

www.audiosciencereview.com

If its being done if float yes, true. But the point is, that normalization is not available when using Spotify Connect. You suggest that this would be something which Wim needs to implement on their side. Does anybody know if any manufacturor has implmented Spotify Connect in a way where the normalization setting would be available in the Spotify App? I'm asking because I have used Spotify Connect steering multiple devices, and I have never seen that this option would have been enabled.
Or to move away from Spotify, does Tidal allow for volume normlization in their app when using Tidal Connect?

 

[JIW]

Just to show how the state of things ist when we are talking streaming:
View attachment 427966
So above is an already bad lossless flac file which I bought from Quobz. At the bottom we see what we get if we stream that track via Spotify (I recoreded directly the digital signal from the SPDIF output of the Wiim Ultra). Hmm, that looks really bad.. I mean AAC is actually a really good encoder and at a bitrate of 192 kbps is would be able to be really completly transparent, and Spotify uses 320 kbps. However, it was never intended to be able to encode near to 0dBFS, or god forbid above 0dBFS. And what we see here is how badly the whole industry is in denail of that issue.

It really saddens me to say that, but the audiophiles are right: only lossless, bit perfect streams are the way to go here. Not because the lossy compression was soo bad, but because it is complely missued!
And even worse, concerning the analog outputs from our hardware (which I showed in posts #642, #644), or even worse from resamplers (#621), the only way out for the consumer is to use lossless sources with as much sampling rate as possible!! The audiophiles were right concerning high-res, all that time! Can you belive what I just wrote?! I cannot even belive myself what I just wrote! And why, because of the high sampling rate of high-res it allows for only very minuscule intersample peaks in the hearable range!

Here's the plots which is backing that up with actual science.
First the same plot I showed in post #647 which was at 44.1kHz sampling rate:
View attachment 427972

And now at 192kHz:
View attachment 427974
Look at the values of the ordinate (aka y-axis). The difference is not as the factor between 192kHz and 44.1kHz would suggest (192/44.1=4.35) but its actually a factor 20.72 better!

So here we are, because nobody in the industry cares, the user has to actully follow what audiophiles have always been saying and use lossless high-res sources. And actually DSD (aka SACD) is the kings here because it brings the problem problem down to a mathematically perfect 0! And really, I must ask, is that perhaps what our audiophile friends though they heared, when they said that bitperfect highres and SACD sounded more "natural" than resampled, lossy sources?

Even for high sample rate formats, ISOs will approach infinity as the frequency approaches the Nyquist frequency. It is of course lower in audible band, but why restrict the concern to that if the oversampling filter being overloaded produces distortion for any sample rate? Simply reducing the volume before sample rate conversion goes a long way and as you show, assuming only harmonic distortion products in the audible band, a little over 1 dB will do the trick at 44.1 kHz. Still, those high level harmonics can produce intermodulation distortion or damage downstream components.

If one already owns the files, an easy thing to do is determine the true peak value by volume-reduced many-fold oversampling and lower the volume such that the peak does not exceed the digital maximum value at very high sample rates, e.g. 705.6 kHz or 768 kHz.

 

[xplo5iv]

As I read the comments with regards to ASRC's such as in the AD DSP chips, I can't understand why they'd be problematic in themselves, as they're 32 bit chips and therefore have significant headroom.
What am I missing? Are they not capable of correctly using the extra bits available?

 

[AnalogSteph]

as they're 32 bit chips and therefore have significant headroom.

Internally, that is. I had a look and it seems that 4 bits are added to incoming 24-bit data for headroom (translating to ~24 dB worth):

https://ez.analog.com/dsp/sigmadsp/w/documents/5169/what-are-the-number-formats-for-sigmadsp

Doesn't mean the ASRCs do.

It shouldn't really matter for things like a DSP crossover anyway, as normally you'd be far away from 0 dBFS levels due to the DSP being preceded by master volume. Unless, of course, that is actually inside the DSP.