Skip to main content
Peter Mc
August 23, 2016
Question

Connect no longer bit-perfect?

  • August 23, 2016
  • 450 replies
  • 29769 views
It looks like the Connect is no longer bit-perfect. Here's my evidence: let's discuss this.

First, I constructed a wav file of pink noise with amplitude ramping up from zero to digital max and back to zero.
I play this through my Connect and record the SPDIF output from the coax output into my PC.
The recording uses a Scarlett 8i6 audio interface set to use the Connect as master clock.
I record into a DAW (Sonar) multiple times - all instances are identical.
However, this recorded signal is not quite the same as the original wav file - it can be up to -21dB different.
See https://www.dropbox.com/s/t8od479xo9hi5el/connect_diff.PNG?dl=1
Note the expanded scale on the difference (third) track.

It looks like the difference gets larger when the signal is larger. To confirm this, I import the
original and difference files into Matlab and plot the raw data (difference vs original). There is clearly audio compression
happening here. See https://www.dropbox.com/s/p1yq6wcqafvnhaj/diff_vs_orig.png?dl=1
The scale is such that digital maximum is 1.

There also appears to be a slight bias when the waveform is negative and the signal is below the
compression threshold. See an expanded version of the previous plot
https://www.dropbox.com/s/9001tl9mkle4wly/diff_vs_orig_zoom.png?dl=1

Happy to answer questions about the method and conclusions.

Cheers, Peter.

p.s. Volume is set to fixed - I haven't tried variable.
In a loopback test (8i6 out from DAW to 8i6 in, no Sonos gear involved), I get bit-perfect cancellation.
    This topic has been closed for further comments. You can use the search bar to find a similar topic, or create a new one by clicking Create Topic at the top of the page.

    450 replies

    April 5, 2017
    If your ALAC file has the iTunNORM tag set (and it's non-zero) then it will have a different volume level from the WAV version. This applies whether it's a ZP/CONNECT or a PLAY.

    Which would suggest that this is a different subject from the topic of this thread? And not something caused by or done at the time the 1dB cut at 100% max volume was done?
    ratty
    April 5, 2017
    If your ALAC file has the iTunNORM tag set (and it's non-zero) then it will have a different volume level from the WAV version. This applies whether it's a ZP/CONNECT or a PLAY.

    Which would suggest that this is a different subject from the topic of this thread? And not something caused by or done at the time the 1dB cut at 100% max volume was done?

    Correct. Normalisation and limiting (the genesis of this thread's topic) are two quite different things. The first preserves the dynamic range, the second does not (and adds distortion).
    Majik
    April 5, 2017
    If your ALAC file has the iTunNORM tag set (and it's non-zero) then it will have a different volume level from the WAV version. This applies whether it's a ZP/CONNECT or a PLAY.

    Which would suggest that this is a different subject from the topic of this thread? And not something caused by or done at the time the 1dB cut at 100% max volume was done?


    Yes, and that's the point I've been trying to get across.

    The limiter is not volume normalisation.

    The limiter and volume normalisation are two entirely different things. They are only related because Sonos has chosen to use a limiter to deal with some potential side-effects of volume normalisation.

    Unfortunately this limiter also seems to be in play when no volume normalisation is being used.

    If you are arguing that discussions around volume normalisation in general should be in a different thread, then you may be right.

    Cheers,

    Keith
    April 5, 2017

    If you are arguing that discussions around volume normalisation in general should be in a different thread, then you may be right.

    Only because there is an easy workaround to the subject of this thread: by using Connect in variable mode below 87% of max volume, whereby no dynamic range is lost and the song can be heard as recorded.
    Majik
    April 5, 2017

    And from discussions here it would appear that these are needed for just Connect units? I have to still see what happens with the two files - ALAC and WAC - on my zp90 zone, but are you suggesting that both will deliver the same sound levels when volume levels are the same? But is not the case with the 1 pair, so that is also doing what the Connect is found to be doing.


    I'm not quite sure what you are asking here. In theory the ZP90 and Connect should deliver the identical output for the same track at the same digital volume level if the volume control is set below the limiter threshold and if no volume normalisation tags are present.

    I am being very careful with my phrasing here. The ZP90 and Connect only have an output level (either digital or analogue). They don't really have a "volume" as they are neither power amplifiers nor speakers. The Sonos "volume control" really is a digital gain control.

    If you try to compare with the Play:1 (or other Play:x speakers) then all bets are off because you are then putting this output through a digital amplifier/speaker matrix with it's own characteristics, including (I believe) additional per amplifier DSP in the case of units like the Play:5.

    If you are asking whether the limiter impacts the Play:1s and other Sonos speakers, then my best answer to this is "probably, but it's almost certainly irrelevant". Why irrelevant? Because in a Play:1 any impact the limiter has is likely to be near the top of the amplifier range and of the speaker & enclosure's capability to convert electrical signals to sound. There are likely to be significant non-linearities at this point which mask any significant impacts of the limiter (assuming it is present in these units). It's also likely that other DSP comes into play at this point which is speaker-model specific.

    It's relevent with the Connect because a typical use-case is to have the Connect set to fixed output (i.e. effectively digital volume control at 100%) and have the digital signal fed into a DAC with the DAC volume control used to control how loud it is. In this case, the limiter in the Connect will be impacting the signal at any volume level

    The above is relating specifically to the limiter. The rest of your post was talking about volume normalisation which is a related (due to Sonos implementation) topic, but really is an entirely different conversation.

    Cheers,

    Keith
    April 5, 2017

    If you are asking whether the limiter impacts the Play:1s and other Sonos speakers, then my best answer to this is "probably, but it's almost certainly irrelevant". Why irrelevant? Because in a Play:1 any impact the limiter has is likely to be near the top of the amplifier range and of the speaker & enclosure's capability to convert electrical signals to sound....

    The rest of your post was talking about volume normalisation which is a related (due to Sonos implementation) topic, but really is an entirely different conversation.

    Right. Which again makes the point made just before this quote, about these being two different subjects. With the limiter and this thread, if applicable to Connect Amp/play units, applicable only so in extreme regions where its effects are unlikely to be audibly noticed. And to not come into play where the Connect is left below 87% of max output.

    While normalisation affects every Sonos product the same way, and cannot be easily turned off. And is noticed only where albums contain songs that are intentionally recorded at widely varying average volume levels, when these albums are played in album play mode.
    Majik
    April 5, 2017

    But if all that is being done is shifting of the sound levels for the entire dynamic range of the song to either side of the recorded level, it isn't a big deal to the extent that I feel any need for workarounds, that will probably only ending up making my playlist experience even worse than what it is today, where, because some CDs and sources still play louder than others, mixed source playlists aren't usable in the way they ought to be. I wonder how much of this is because of errors in the tagging that Sonos is merely responding to. iTunes has an option for turning normalisation off, if memory serves me well, and I agree that all Sonos needs to do is provide this option.

    I also haven't heard any users of the 5 units, that have found it to be a HiFi speakers, have any complaints on this count. Most people, I suppose, are just setting the volume levels to where they need to be, and making an occasional tweak to the volume control if/when needed. Which is what was being done with legacy kit as well.


    To be clear, this is now discussing volume normalisation, not the limiter.

    The volume normalisation implementation on Sonos has always been half-assed. In some case it works quite well. In others it works quite badly. One of the main issues is it can't be disabled easily.

    Bearing in mind that mixed genre/age playlists will normally suffer from huge variations in level between tracks regardless of source or volume normalisation issues (of course, the aim of volume normalisation is to correct this, but it could potentially be counter-productive in cases where some files have normalisation tags and others do no). I suspect that, in many cases, the impact of spotty volume normalisation support from different sources on (for instance) a mixed source playlist of pop/rock tracks spanning 5 decades would probably be fairly neutral.

    But it does depend highly on the playlist.


    While normalisation affects every Sonos product the same way, and cannot be easily turned off. And is noticed only where albums contain songs that are intentionally recorded at widely varying average volume levels, when these albums are played in album play mode.


    Potentially it could have adverse impacts on a playlist where some tracks have normalisation tags and some do not, if the tracks in the playlist were recorded with similar levels to start with. The obvious and well-discussed example is for tracks from a single album, but it could apply to other playlists too.

    Cheers,

    Keith
    April 5, 2017

    The volume normalisation implementation on Sonos has always been half-assed. In some case it works quite well. In others it works quite badly. One of the main issues is it can't be disabled easily.

    While granting the second point, is there any one else that has done a better job of normalisation given what seems to be a wide variance in how tracks may carry the required information?
    Majik
    April 5, 2017
    Yes.

    The old Slimdevices systems had Replaygain support with user control allowing the user to easily select between the following options:

    (IMO it was about the only thing that was significantly better on the Squeezeboxes compared to Sonos)

    * Track by track normalisation
    * Album-based normalisation
    * Auto mode where it would attempt to adjust the normalisation used depending on the playlist
    * Normalisation disabled

    Personally I'm not sure the "auto" mode is that useful.

    The key is to allow user control. Any type of volume normalisation implementation which tries to second-guess what the user wants and doesn't allow the user to override it is fundamentally broken by design.

    Cheers,

    Keith
    ratty
    April 5, 2017
    It depends what you mean by 'better job'. Most media players which support normalisation tags offer three options: album gain, track gain or OFF. In the first two cases they obviously depend on the user (or service) having tagged appropriately.

    The track gain figure adjusts the level based on the average track loudness. The album gain figure is based on the average album loudness. By definition that figure is the same for all the tracks in the album.

    Tools which add gain tags traditionally also add peak tags, representing the largest sample in the track or album. The media player can use this to avoid applying too much gain and going into clipping. Sonos ignores the track peak figure; another reason why the implementation is rather half-baked.