Question

Connect, Meridian and MQA

  • 27 January 2017
  • 56 replies
  • 7661 views

Will using a Connect with a Meridian Explorer DAC allow full resolution MQA?

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.

56 replies

A thoughtful piece from Linn (who presumably are no friends of Meridian)
LOL. They wouldn't be, because this also encroaches on their music downloads business, from which website:
"Linn makes download files available in three quality levels: MP3 (good), CD Quality (better) and Studio Master (best)."
Studio master is 192khz;)


The battle of the snake oil masters.
A thoughtful piece from Linn (who presumably are no friends of Meridian)
LOL. They wouldn't be, because this also encroaches on their music downloads business, from which website:
"Linn makes download files available in three quality levels: MP3 (good), CD Quality (better) and Studio Master (best)."
Studio master is 192khz;)
A thoughtful piece from Linn (who presumably are no friends of Meridian): https://www.linn.co.uk/blog/mqa-is-bad-for-music
I've seen engineering specs for perpetual motion machines with more credibility.
It doesn't look like Archimago buys it either. Scroll down to "MQA-encoded CD".
Rather than as a move worthy of celebration by MQA proponents, I think this is more a sign of MQA's "last stand".
Badge +1

...
Speculation: increasing the negative waveform by 1 bit could lead to minor clipping. Could this be why a limiter is needed?


That doesn't appear to be the case. In addition to truncating to 16-bits and the filling the bottom byte of the S/PDIF 24-bit sample with "junk", the limiter appears to be clamping the digital output amplitude to -1.4 dBFS (16-bit sample level ~27880 out 32768) for levels above this.

Using a 24/44.1 test track that sweeps every pos/neg sample value from 0 to FS at 24-bit, results in a 22050 Hz tone that increases in amplitude over time, per:


When the track is played on the Connect, with the digital output captured, when compared to the original, the following visualization shows the limiter in action at the higher amplitude level, getting more aggressive at the higher levels. One possibility for this behavior is to minimize inter-sample peak clipping, but considering current mastering practices of normalizing to 0dBFS, and that this "clamping" is only occurring for higher levels, this will result in a non transparent reproduction of most current album releases.

Look back at this post. Anything arriving in 24-bit MQA would evidently be truncated to 16-bit, removing the ultrasonics 'origami', and leaving 13-15 bits of resolution above the noise.

As for the idea of 16/44 'Red Book' MQA as described in that Stereophile article, forgive my scepticism but it all sounds rather reminiscent of HDCD. To be compatible with regular 16/44 PCM any extra information must be buried in the least significant bits, raising the noise floor on a standard decoder. Any real benefit must surely lie in more careful mastering, which might as well be delivered in plain old 16/44 PCM.

And
An MQA CD is a Red Book CD and is 100% compatible with any existing CD player.... if the bitstream is passed to an MQA decoder, it is unfolded to 176kHz (in this case) and rendered to the DAC at 24-bit.
really does stretch credulity. 24/176 content in an uncompressed 16/44 carrier which retains Red Book PCM compatibility?!


I've seen engineering specs for perpetual motion machines with more credibility.
Look back at this post. Anything arriving in 24-bit MQA would evidently be truncated to 16-bit, removing the ultrasonics 'origami', and leaving 13-15 bits of resolution above the noise.

As for the idea of 16/44 'Red Book' MQA as described in that Stereophile article, forgive my scepticism but it all sounds rather reminiscent of HDCD. To be compatible with regular 16/44 PCM any extra information must be buried in the least significant bits, raising the noise floor on a standard decoder. Any real benefit must surely lie in more careful mastering, which might as well be delivered in plain old 16/44 PCM.

And
An MQA CD is a Red Book CD and is 100% compatible with any existing CD player.... if the bitstream is passed to an MQA decoder, it is unfolded to 176kHz (in this case) and rendered to the DAC at 24-bit.
really does stretch credulity. 24/176 content in an uncompressed 16/44 carrier which retains Red Book PCM compatibility?!
Badge +1
There has been past reports that the SONOS equipment could not playback Hi-Res audio, ie word size > 16-bits, or sample rates over 44.1 kHz. I was totally surprised today when I discovered that my Connect with v7.2 firmware was in fact now capable of playback of a 24-bit tracks, up to 48kHz.

Without testing thoroughly, I found that the Connect now supports the playback of: 24-bit/44.1 and 24-bit/48 kHz WAV's and FLAC's but would NOT play 24-bit 88 kHz tracks, so I am assuming that is applicable to anything greater than 48 kHz.

With respect to MQA:
It would appear that the MQA tracks on TIDAL are 24-bit FLAC's of which the streamed sample frequencies may vary depending on the MQA mastering decisions. I've read reports that the MQA tracks on TIDAL are either 44.1 or 48 kHz (MQA encoded/folded), where the original sample rates (after all MQA decode unfold) vary between 44.1 and 192 kHz.

One premise of MQA encoding is that the encoded file can still be played on equipment that does not support MQA decoding. If the Connect is now capable of decoding 24-bit 48 kHz, there should be no issue with streaming MQA files from TIDAL without any MQA decoding on SONOS equipment. Although, I am not sure that this would provide any benefit other than format playback compatibility.

There still remains the question of when streaming an MQA Track from TIDAL on Sonos equipment, what content is actually being negotiated and delivered in the stream to the Sonos equipment. I have a Bluesound Node 2 which does support playback of hi-res and MQA and I have a SONOS Connect. In some random MQA track selections, but without any formal analysis, when monitoring the transfer byte counters on my router, I can confirm that the transfer bytes for playing back of MQA track on a SONOS Connect is much less than the transfer bytes when playing that same track on my Bluesound Node2 -- as such, I have to assert that in all likelihood only 16 bit (likely 16/44.1) variants of the MQA tracks are being negotiated and delivered to Sonos equipment. I’d make this assertion as 16/44.1 was the legacy claimed max resolution supported by Sonos.

For an MQA selection, if the streamed FLAC’s delivered from TIDAL to SONOS equipment, are only 16/44.1, then I cannot imagine that they would include MQA encoding as the bits are no longer available for the MQA encoding overhead. But, on Mar 16, 2017, this post http://www.stereophile.com/content/mqa-encoded-cds-yes discusses the encoding of MQA tracks to 16/44.1 for CD Media. In this case, the original master is folded/encoded to a 16/44.1 MQA file. Is this what is being done on TIDAL for streaming to Sonos equipment? This could be simply validated, if Sonos Connect out was “bit perfect”, by feeding the S/PDIF output of a Connect to another device that does support MQA decode and verify that the MQA content is decodable on that device -- which I believe is what was asked in the OP.
Badge +1

...
Interestingly, I noted a similar error in my post on the Connect not being bit-perfect (although that was at 16 bits).
...


Prior to v6 of the Connect Firmware, the S/PDIF digital output was "bit perfect" to the input.

Background of S/PDIF:
The S/PDIF protocol per IEC60958 transports a sample within a 32-bit word. The actual sample within the S/PDIF word is a effectively a 24-bit sample. For 16-bit input, audio, the "extra bits" in the S/PDIF sample are set to 0. Thus, when outputting 16-bit samples on S/PDIF there is a word length expansion from 16-bit to 24-bit -- this is what CD Players with a S/PDIF output do.


To clarify bit perfect, the expectation is that for a 16-bit sample, the S/PDIF 24-bit sample will contain the 16-bit sample in the top 16 bits of the sample, and the bottom 8 bits will be 0. This is a form of up conversion, no precision is lost, and the application of dither is not required. Further, sound level amplitude is maintained relative to full scale for the sample word size.

It appears that with the Connect v6.x firmware in late 2015, rather than filling the extra bits in the S/PDIF word with 0 bits, SONOS implemented a S/PDIF word fill algorithm where the extra bits were algorithmically determined, which at that time appeared to be based on sample position over time and was not either randomly, or sample derived. In addition, the result of this word fill algorithm, was that all negative samples were off by -1 (ie -1 => -2, etc).

At the time I felt that SONOS may have been preparing themselves for handling 24-bit, 44.1 playback. I have never looked into this further.
Thanks. Leaving aside the speculation on the 1 bit dislocation for negative samples, this does appear to confirm that the lowest byte is sawn off which, to return to the original topic, means that playing MQA is a complete waste of time apart from the convenience of compatibility. What remains in the upper 16 bits is 1-3 bits worse in terms of dynamic range than a true 16/44 or 16/48.
OK, I think I understand now. Here's another version of the zoomed-in plot from above.


The scale is now in terms of signed 24 bit integers rather than normalized. Values from 0 to 255 come from the least significant byte of a 24 bit number. Look at the Y values for the output. The first positive value is 256, the next 512 and so on. Since the first byte goes from 0 to 255, it is not needed to represent multiples of 256 and so is zero as expected.

However, the negative Y values are shifted by 1, starting at -257, then decreasing in steps of 256. This means the least-significant byte is needed to represent these values. There appears to be a 1-bit error here for the negative waveform only.

Interestingly, I noted a similar error in my post on the Connect not being bit-perfect (although that was at 16 bits).

So the summary is, 24 bit music gets truncated to 16 bits, but the lowest-order byte is not identically zero because of a 1 bit error in the representation of the negative waveform.

Speculation: increasing the negative waveform by 1 bit could lead to minor clipping. Could this be why a limiter is needed?
Yes, you're absolutely right. That plot just looks like truncation. There's something I'm not understanding about converting 3 bytes into 2 in my software when looking at the raw numbers. I'm not going to get there tonight - brain is too tired.
Maybe I'm misinterpreting, but in the second plot it looks like, for each quantum on the output, there's a spread of input values. Is this not back to front? Would dither (or some other random noise) not translate each quantum on the input to a spread of output values? In other words the lines of blue dots would be vertical not horizontal?
I don't think there is any sample scaling. Ignoring the high-amplitude limited values, there is a one-to-one relation between input and output except at very small scales where the dither is evident. Let's see if these plots help: 1 is full scale, the second plot is zoomed in;


Can you detect whether there's any sample scaling going on? I know you've tried to avoid hitting the limiter, but something somewhere is either scaling the samples or noise is being injected into the lowest byte, perhaps by unnecessary dither.
Yes, I expected the lowest byte to be zero. I'm perplexed that it isn't, particularly for the 16 bit wav. I can demonstrate that the source 24 and 16 bit wavs are identical in the first and second bytes, and that the 24 bit file contains non-zero information in the third byte.

I suspect something changed in 7.2 - my third plot in the "Connect no longer bit perfect?" thread looks different now. The horizontal line is thicker due to dither (or whatever).
If 24-bit and 16-bit inputs generate identical outputs that suggests the former is simply truncated early on, assuming of course that the 24-bit version contains real 24-bit information at the outset. Why the lowest byte is then non-zero -- for either -- is another question. At 100% volume the lowest byte would be expected to be empty.
both outputs differ from the original by a signal with a distribution that is roughly Gaussian (except for the absence of long tails), centred on the last 1/2 bit, and of maximum width plus and minus 1 bit. That looks very much like dither but it's not random in time (because it is identical for the 24 bit and 16 bit sources). Strange!
At some time in the future, do remember to let us lesser mortals know the implications of this research, if relevant to our use of Sonos!
Already tried that - the outputs are identical. Not sure what that says about the dither hypothesis, but both outputs differ from the original by a signal with a distribution that is roughly Gaussian (except for the absence of long tails), centred on the last 1/2 bit, and of maximum width plus and minus 1 bit. That looks very much like dither but it's not random because it is identical for the 24 bit and 16 bit sources. Strange!
If the limiter is applied on a per-sample basis then, yes, the volume setting shouldn't make any difference. As a control, why don't you downconvert the 24-bit WAV to 16-bit and see what the lower byte on the coax contains?
Here's a thought: if Sonos players can now handle 24 bit files, why bother truncating and dithering? The 24 bit file has already been transferred across the network to the player, so there is nothing to gain in terms of network speed. They could just spit out the full 24 bits through the coax, or even through the internal DAC.
I thought Ryan's statement pertained to decoding 24 bit FLAC files. I didn't interpret it to cover handling 24 bit wav (output at 16 bit) as well. I wonder if Sonos is preparing for further changes here?

Why is a pre-2011 Connect necessary? Surely any Connect in Fixed volume mode will do providing the high-amplitude limited values are ignored? In fixed volume mode, the volume is a maximum and should not populate the lowest byte with anything. Or am I missing something here late on a Sunday night?

Cheers, Peter.
Ryan said that as a side-effect of some other changes, Sonos would no longer have indigestion when confronted with 24-bit files.

There's also a suggestion that maybe only the top 16 bits are passed on down the audio pipeline.

I suspect that the only valid analysis of the lowest byte on the S/PDIF would be with a pre-2011 unit in Fixed Volume or 100%. Any volume change would populate the lowest byte with low order information.
It would be intriguing if someone could analyse the digital output of a ZP80/90 or pre-2011 CONNECT, in Fixed volume. The question is: what's in the lowest 8 bits of the 24-bit S/PDIF?

Not quite, but I can analyse the output of a post-2011 Connect and ignore the high-amplitude parts of the waveform where the limiting occurs. So here are some surprising results (at least to me).

1. 24 bit/44.1 wav (and FLAC) files play fine. I didn't know this.

2. Recording the 24 bit coax output, there is information in the lowest byte.

3. It looks like it is dither.

4. A 16 bit file is also dithered. It is generally considered a big no-no to dither an already dithered file.

That's it for the moment - I'm still trying to get my head around all this.

Cheers, Peter.
Wouldn't it be great if Sonos could support unmodified transport of MQA and 24/96 and 24/192 files? I'd happily pay for a "Sonos Connect HD/MQA" device.
From my point of view, Sonos is great at transport....

And how long do you think that would last, when asked to cart around files up to 6 times larger than CD quality? I'd wager that all that inaudible -- some would say destructive -- ultrasonic information would quickly put paid to Sonos' reputation for 'rock solid wireless'.