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

... 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.

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.

@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

@cleeds 

Qobuz is correct - analog audio is just a series of sine waves (and cosines). 

Qobuz would be correct if that is what they said, but it ain't.  My quote was precisely copied from their website "An analog audio signal is composed of a sine wave".  This is ridiculously wrong.

Fourier theory says than an arbitrary repeating waveform can be constructed from an infinite series of sine waves, being the odd harmonics of the base frequency.

Fourier transforms are often used to convert between the time domain and the frequency domain, so much so that many audiophiles only think about frequencies.

The extreme case is a square wave which does require an infinite series.  Unfortunately, transforming the transform to get the square wave back produces spike artifacts.

Can you share what you know about how Qobuz actually works "My information regarding how Qobuz works comes right from its US execs David Solomon and Dan Mackta".

These gentlemen seem to have sales roles

So I asked Google AI "how does TCP/IP correct for packet loss and corruption"?

UDP/IP does none of these things. I have added italics:

TCP/IP uses mechanisms like checksums, sequence numbers, and retransmission to ensure reliable data delivery, handling both packet loss and corruption. TCP detects missing or corrupted packets and requests their retransmission, ensuring that data arrives in the correct order and without errors. 

Here’s a more detailed breakdown:

1. Error Detection (Checksums):

  • TCP uses a checksum to verify the integrity of data during transmission. The sender calculates a checksum based on the data and sends it along with the data. The receiver recalculates the checksum and compares it to the received value. If they don’t match, it indicates data corruption, and the receiver requests retransmission from the sender. 

2. Sequence Numbers and Acknowledgements:

  • TCP uses sequence numbers to track the order of packets. If a packet is lost or arrives out of order, the receiver can use these sequence numbers to detect the issue and request retransmission.
  • The receiver sends acknowledgements (ACKs) back to the sender, indicating which packets it has received successfully. If the sender doesn’t receive an ACK within a certain timeframe, it assumes a packet is lost and retransmits it. 

3. Retransmission:

  • If a packet is lost or corrupted, the sender will retransmit it, ensuring that the receiver eventually gets all the data it needs. 
  • The sender also implements timers to ensure that lost or corrupted packets are retransmitted within a reasonable time. If the timer expires without an ACK, the sender retransmits the packet. 

4. Flow Control:

  • TCP employs flow control to prevent the sender from sending data faster than the receiver can handle. This helps avoid packet loss due to buffer overflows on the receiver’s end. 

5. Congestion Control:

  • TCP also includes congestion control mechanisms to avoid network congestion, which can lead to packet loss. These mechanisms help regulate the rate at which data is transmitted, preventing the network from becoming overloaded. 

In summary: TCP/IP uses a combination of error detection (checksums), sequence numbers, acknowledgements, retransmission, flow control, and congestion control to ensure reliable data delivery, handling both packet loss and corruption.