1. Home
  2. digital
  3. 194442-192372

We Need To Talk About Ones And Zeroes

Several well-respected audiophiles in this forum have stated that the sound quality of hi-res streamed audio equals or betters the sound quality of traditional digital sources.

These are folks who have spent decades assembling highly desirable systems and whose listening skills are beyond reproach. I for one tend to respect their opinions.

Tidal is headquartered in NYC, NY from Norwegian origins. Qobuz is headquartered in Paris, France. Both services are hosted on Amazon Web Services (AWS), the cloud infrastructure services giant that commands roughly one third of the world's entire cloud services market.

AWS server farms are any audiophile's nightmare. Tens of thousands of multi-CPU servers and industrial-grade switches crammed in crowded racks, miles of ordinary cabling coursing among tens of thousands of buzzing switched-mode power supplies and noisy cooling fans. Industrial HVAC plants humming 24/7.

This, I think, demonstrates without a doubt that audio files digitally converted to packets of ones and zeroes successfully travel thousands of miles through AWS' digital sewer, only to arrive in our homes completely unscathed and ready to deliver sound quality that, by many prominent audiophiles' account, rivals or exceeds that of $5,000 CD transports. 

This also demonstrates that digital transmission protocols just work flawlessly over noise-saturated industrial-grade lines and equipment chosen for raw performance and cost-effectiveness.

This also puts in perspective the importance of improvements deployed in the home, which is to say in the last ten feet of our streamed music's multi-thousand mile journey.

No worries, I am not about to argue that a $100 streamer has to sound the same as a $30,000 one because "it's all ones and zeroes".

But it would be nice to agree on a shared-understanding baseline, because without it intelligent discourse becomes difficult. The sooner everyone gets on the same page, which is to say that our systems' digital chains process nothing less and nothing more than packets of ones and zeroes, the sooner we can move on to genuinely thought-provoking stuff like, why don't all streamers sound the same? Why do cables make a difference? Wouldn't that be more interesting?

devinplombier
mitch2
4,750 posts
 

@cleeds - I am curious whether the transfer protocol really matters.  As you say,

“even hi-res audio requires a download speed of only around 10Mbps, so there’s plenty of time for any damaged packet to be re-sent.”

Therefore, regardless of whether a UDP/IP or TCP/IP protocol, doesn’t the entire data packet eventually arrive at the streamer where it is reclocked, sent on to the DAC, and then reclocked again (depending on whether a synchronous or asynchronous connection is used), and finally converted to analog and sent on?

I stream both Tidal and Qobuz, plus play files locally stored, through Roon and, in the context of a moderately high-end system, do not really perceive a sonic difference regardless of what is playing.

devinplombier OP
1,677 posts
 

@mitch2 

UDP can safely be ignored in the context of 2-ch digital streaming, together with all the AI-generated nonsense @richardbrand has been cut-and-pasting in this thread. Both Tidal and Qobuz use TCP, and TCP does ensure bit-perfect transfer of your PCM-encoded music to your streamer (I say PCM because I don’t think either service offers DSD as of now).

SACD is different in that it is encoded in DSD64 format. Now there are multiple considerations associated with this, and folks who are interested may want to read this blog post by Benjamin Zwickel - the founder and designer of respected DAC manufacturer Mojo Audio - who is considerably more qualified than I to dissert on the subject.

 

cleeds
6,593 posts
 

mitch2

... regardless of whether a UDP/IP or TCP/IP protocol, doesn’t the entire data packet eventually arrive at the streamer ...

It does if it's TCP/IP because any faulty packet is simply re-sent. That re-send isn't possible with UDP/IP, though, so an error is possible. The audibilty of that error is debatable, of course, and probably depends on the extent of the error in the first place.

mitch2
4,750 posts
 

Thank you for the explanation @devinplombier and @cleeds.

Both of my main two DACs are NOS R2R types so only PCM for me, and my system sounds great through either of them.  BTW, one of those DACs is Mojo Audio’s top DAC.

richardbrand's avatar
richardbrand
1,395 posts
 

@cleeds 

It does if it's TCP/IP because any faulty packet is simply re-sent. That re-send isn't possible with UDP/IP, though, so an error is possible. The audibilty of that error is debatable, of course, and probably depends on the extent of the error in the first place

Thank goodness at least one person here gets it!

Lots of people here claim to hear differences with digital streams and lost packets are one possible explanation.

@deep_333 

On the same note, buy a hires official studio master from qobuz, burn it on bluray disc and play it with your bluray transport....almost always/definitively sounds better than streaming the same album directly from qobuz or tidal...couldn’t be sure why.

There is a very simple explanation.  When you buy a download, you are essentially transferring a file.  You are not listening to it as it transfers, so timing is not critical. 

File transfers use the TCP/IP protocols.  The internet is a packet switched network, and individual packets may take completely different routes through the network and eventually arrive out-of-order, or corrupted, or not at all.

At the end of the transfer, TCP/IP guarantees either that the file is a bit-perfect copy or that the transfer has failed.

How does the TCP/IP receiver even know when the transfer has finished?  According to Google AI:

TCP/IP knows when a data transfer is complete through a four-way handshake involving FIN and ACK packets, ensuring both sides have signaled the end of the connection and acknowledged it. This process guarantees a reliable and ordered transfer. 

Here's a more detailed explanation:

  1. Data Transfer:

    TCP establishes a connection, breaks data into segments, and uses sequence numbers and acknowledgments to ensure reliable delivery. 

  2. Initiating Closure:

    When one side (client or server) has finished sending data and doesn't need to receive any more, it initiates the closure by sending a FIN packet. 

  3. Acknowledgement of Closure:

    The other side acknowledges the FIN with an ACK packet. 

  4. Return FIN:

    The receiving side, now also finished with data, sends its own FIN packet back. 

  5. Final Acknowledgement:

    The original sender acknowledges the FIN from the receiving side with a final ACK packet. 

  6. Connection Terminated:

    Once both sides exchange the FIN and ACK packets, the connection is officially terminated. 

In essence, the four-way handshake (FIN-ACK-FIN-ACK) signals that the transfer is complete and both parties have finished sending and receiving data. 

UDP/IP does none of this checking because it is attempting to keep a stream going

More to discover