The difference between Qoboz stream vs purchased songs

OP,

A digital download is usually the same format as as when it’s streamed, so there’s little to no difference in the sound when played on either.

@fredrik222 

Like Juan from Bliss Hifi, I’ve heard differences in the quality of the presentation that has me shrugging my shoulders.  The first ‘what the…” moment was when I totally upgraded the power feeding my system.  The second was when I upgraded the 3’ Ethernet cable from the wall to my streamer.  Both of these transformed my system with the Ethernet upgrade having the lesser improvement, but I really don’t understand this difference given what you said, and I have no reason to doubt you, that error correction is the same.  It makes sense that it is the same in that Ethernet protocol is set, but it leaves me at a loss as to how changing the Ethernet cable can make a difference.  Either I have a preference for a low bank account balance, or there is something else going on.

@cleeds It's not an attack on your person, it's 100% a statement of facts. You don't know anything about Ethernet or TCP/IP. The link you provide here goes to speedtest.net, so that proves that you still don't understand it. 

If you are talking about disconnecting the cable, like I said previously, you would fail the DRM check, so no cache playback without internet access. However, Bryston is known for its bad streaming capabilities, including it's small cache and how that is causing issues. So, what you have is a uniquely poor implementation.

Further more:

"

The Nitty Gritty
Playback quality is governed by the maximum you choose (see Figure 4). On mobile, you have the ability to set separate quality caps for streaming on Wi-Fi and mobile networks. In the desktop app settings, you have the option to take exclusive control of the selected audio device. Using exclusive control, I watched my DAC display its automatic switch to different sample rates as I played different tracks, barring Windows Core Audio from resampling my Qobuz stream. The mobile app does not cache audio more than a handful of seconds in advance, but the desktop app caches the entire track at once. 

The caching is a nice feature because it visibly builds your offline library if you check an option in the app’s settings, adding all cached tracks to the offline library. You’d be right to be concerned about Qobuz monopolizing your storage space as it automatically caches all music played. Under music playback settings, you can set the maximum cache size from 500 MB to 100 GB. As a bonus to those with multiple hard drives, Qobuz allows you to set a new location for cached music to reside. The music download location can also be changed in the settings, and you can monitor how much space it is using. 
"

https://audioxpress.com/article/exploring-qobuz-high-resolution-streaming

@cleeds I really don't know how much more you need to show you are wrong, but wrong you are.

fredrik222

It’s not an attack on your person, it’s 100% a statement of facts. You don’t know anything about Ethernet or TCP/IP.

Begging the question, a.k.a. circular reasoning, logical fallacy.

The link you provide here goes to speedtest.net, so that proves that you still don’t understand it.

That speedtest link shows that the test I performed - which disproves your claim outright - was not caused by poor interconnect speed. I’ve since duplicated the test with other equipment. Feel free to tell us what equipment you’ve used to achieve different results.

I really don’t know how much more you need to show you are wrong, but wrong you are.

I’ve provided the results of actual demonstrations. And, you still conflate streaming, caching, and downloading, as though they were all the same thing.

Streamed Quboz tracks are not downloaded in full to cache before playback starts. It’s unclear why you refuse to acknowledge that, especially given that it’s been proven in demos.

"Streaming cannot do this.  Streaming must keep up with the music so streaming always has error management tool that interpolates for any missing bit and moves on"

Depends on the protocol in use.   Certainly UDP by itself can lose packets and so loss has to be accounted for at the application level.  But this is not how data streaming is done these days (and hasn't for some time).

Today, we use RTSP (Real Time Streaming Protocol) or SCTP (Stream Control Transport Protocol) which provides a true IP connection allowing error handling at the network layer, so you rarely lose packets unless your ISP is having an issue.   These protocols even support play, stop, and pause.   SCTP is preferred because it actually breaks the stream into chunks of data and will provide network level error correction, and thus is superior because the packets delivered will be a faithful to the data sent.

To reiterate, if you're having trouble with data retransmission, it's an ISP problem and you can spend an 6 figures in getting the most sophisticated networking gear in your house and will have no impact if your ISP has a problem (or the internet itself is having a problem).

If you think you're having a data issue; before you spend money on cables, special switches and routers, hire a local communication company that can check if you're having packet loss.  It will cost you a lot less than buying new network hear and you'll have data to based your decision on.