We Need To Talk About Ones And Zeroes

So much basic misinformation here!

I beseech you to understand what the word streaming means in digital networks, and how it differs from file transfers.  At its simplest, streaming prioritises getting something out (timeliness), over getting it right.  With streaming it is OK if some packets go missing, or get horribly corrupted, as long as there is a more or less steady stream of packets.

I beseech you to understand the difference between Internet Protocol (IP), Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). 

IP deals with basic network addressing.  TCP works on top of IP and includes error detection and recovery, guaranteeing accurate delivery of messages and files but not timeliness. A TCP/IP transfer is not complete until the entire message has been transmitted, checked and corrected.  If you want to 'stream' using TCP/IP without packet loss, you cannot start playback until the 'stream' has completed.  In other words, the stream has become a file transfer!

UDP also works on top of IP but does not guarantee delivery.  In general, UDP/IP is the protocol used for streaming, because it does not bother to stop and ask for retransmission.  Think about multicasting where a single stream is fed to a large number of receivers.  Not all receivers will get exactly the same packets because of transmission losses, which are not individually corrected!

I also beseech you to understand that Ethernet, on its own, does not guarantee packet delivery any more than pigeon post offers a delivery guarantee.  Sure, most pigeons will get home most of the time, but some sometimes get lost, get picked off by hawks, get shot down, or die on the wing.

On top of all this, even USB does not guarantee accuracy when streaming.  I recently posted in another thread:

From Wikipedia USB - Wikipedia

"As of 2024, USB consists of four generations of specifications: USB 1.x, USB 2.0, USB 3.x, and USB4."

So there is no such single thing as USB.  It is no longer even Serial!  There are now nine families of USB connectors.  For example, the USB-C connector has 24 pins and looks more like the purpose designed HDMI which is Parallel and eschews data packets.

USB was never designed for error-free streaming.

• A stream pipe is a uni-directional pipe connected to a uni-directional endpoint that transfers data using an isochronous,^[69] interrupt, or bulk transfer:

Isochronous transfers

At some guaranteed data rate (for fixed-bandwidth streaming data) but with possible data loss (e.g., realtime audio or video)

Interrupt transfers

Devices that need guaranteed quick responses (bounded latency) such as pointing devices, mice, and keyboards

Bulk transfers

Large sporadic transfers using all remaining available bandwidth, but with no guarantees on bandwidth or latency (e.g., file transfers)

Note the implications here.  Audiophiles often believe that because files and messages can be transferred error-free, that implies streams are error-free.  They aren't, but you do get your errors for free.

@nonoise

There are fundamental differences between digital video and digital audio.

Digital video is always lossy because compression is used to make the bit rate manageable.  4K Blu-ray uses less aggressive compression than streaming, but there is still compression.  The Motion Picture Expert Group has combined a range of lossy compression techniques which are realised as mpeg formats in various versions.

If no video compression were used, the bit rates are fairly easy to calculate.  Take the bits for one video frame and multiply by the frame rate of your choice.  The bits for one video frame are the bits per pixel times the number of horizontal pixels times the number of vertical pixels. At 24 bits per pixel and 4K resolution we need about 24 * 2,000 * 2,000 bits, or about 100-million bits per frame.  With a 60-Hz refresh rate, that's about 6-trillion bits per second.  Fortunately, there's not much change between most frames and the following one, and one compression technique is to just send the changes, with an occasional complete refresh.

Our eyes are much more forgiving than our ears.

Audio can be losslessly encoded at bit rates which are achievable with today's technology.  However, while lossless encoding and decoding can always recover the original digital sequence if all the packets are delivered and error corrected, it does not stop packets getting lost or corrupted when streaming.

@chrisoshea 

My advice to all on this thread…. Buy a Rega Planar 3, a Schiit Mani 2 phono stage and some records

I would say get a universal disk transport with HDMI outputs, and some SACDs, Blu-ray audio disks, 4K opera recordings and CDs.   You will always have your media, and it will always be as new because it won't wear out. Keep your fingers crossed that somebody will still be making transports if yours carks it!

Having said that, I have started buying records again ... but not if the music is also available on SACD!

@sns 

So on top of Qobuz using TCP/IP protocol

I know Qobuz claims to use TCP/IP but to many people, and it seems to many here, the internet is synonymous with TCP/IP.  TCP is only part of the internet. I have tried to show that UDP/IP is equally ubiquitous, and that conclusions on accuracy drawn from TCP do not apply to UDP.

Qobuz also claims on their website that "An analog audio signal is composed of a sine wave" when they probably mean an infinite set of sine waves.  They are careless with the truth.

Streaming is different from downloading, which can be bit-perfect using TCP/IP.  The functional difference is that you can start playback of a stream before it is complete.  Nothing in the world can guarantee the future will be error free.

TCP/IP only guarantees bit perfect transmission after the transmission is complete, and cannot guarantee how long that process will take.

Qobuz is very tight-lipped about the actual protocols used, which are proprietary. It is possible that they make a stream up from many small files which are transmitted using TCP/IP, but nothing guarantees all future files will be ready when playback gets to where they are needed.

The Euphony article you quote illustrates this well:

The best way to do this is to preload the complete song to RAM before playing

It does not address Qobuz but the major streamers have the same issues to face:

We don't know that much about Roon's internal workings

So I asked the web about "ethernet packet delivery guarantee" and Google's AI overview came back with:

Ethernet, at its core, is a best-effort delivery protocol, meaning it does not guarantee that every packet will be delivered or that they will be delivered in the order they were sent. While Ethernet frames are encapsulated in IP packets, which in turn can be part of TCP or UDP protocols, the underlying Ethernet layer itself doesn't provide delivery guarantees. 

@devinplombier 

Audio streaming presents a very, very light load in Ethernet terms, and error-free transmission is a given

It is not a given, not by Ethernet.  Ethernet on its own does not guarantee packet delivery, nor timing, nor error-free status.  You need higher level protocols, which may operate over Ethernet, if you want to guarantee delivery and error correction. 

Ethernet timing is indeterminate, because unlike USB there is no central controller managing timing.  However, as you point out, it is usually fast, depending on the version.  Early Ethernet was under 3-million bits per second, though, which is not really enough for a CD let alone high res.  Ethernet does have significant overheads.

You might care to rethink your statement that latency is not important for audio. It is the reason streaming was introduced.

Also most Ethernet network components including routers, switches and gateways do include processors and do a fair bit of work on each packet.  They build up lists of Ethernet devices connected to each port and only forward packets to the necessary port(s)

@devinplombier

 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

I ploughed through the article and quickly guessed that Mojo Audio does not natively support DSD!  Talk about bias.

The author mistakes DAC for ADC, which is forgivable.  However, the statement that "Even Sony no longer supports DSD and SACD" is laughable. 

@devinplombier 

together with all the AI-generated nonsense @richardbrand has been cut-and-pasting in this thread

Google AI has access to all the nonsense on the web, including yours, but it is intelligent at processing the entire content.  If the consensus it reaches agrees more with my understanding than yours, think perhaps that you just may not be entirely right.

What I have tried to do here is to back up three assertions with the best sources of information you just might believe, one being Wikipedia and the other Google AI.

You labelled this topic "We Need To Talk About Ones And Zeroes" and we clearly do, because there is so much misinformation surfacing here.

My backed-up assertions are

1. Streaming does not guarantee packet delivery nor bit-perfect accuracy
2. Ethernet on its own does not guarantee packet delivery nor packet accuracy nor packet timing
3. USB when used for streaming does not guarantee error-free delivery

I understand why audiophiles who have committed to streaming might react in horror to these assertions.  I urge you to do your own research with an open mind.

There are much better formats than 2-channel PCM, after all!

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

@devinplombier 

A person relies extensively on cut-and-pasting at the risk of appearing lazy and unintelligent.

... we all have access to google AI and we would know how to query it if we felt like it. Doing it on our behalf adds no value and merely pollutes the thread.

No one can be expected to read 2,000 words of google-generated drivel and I admit I did not - so if I missed something I apologize

I like Google AI because anyone can re-run a query - you are not reliant on what a single contributor 'knows', and can 'remember', and can 'articulate'.  It is not as if I  am so unintelligent and ignorant and lazy that I never contribute original content!

Unfortunately, it is obvious that many contributors here do not have much technical understanding or do even basic research.  Witness your own assertion that most network components do not have processors, though they clearly perform logic!

You now seem to agree that streaming is not guaranteed to be 100% perfect.  I have no idea whether this is audible (except for obvious drop-outs) but many people report hearing differences.  Data loss and un-corrected errors are one possible explanation.

@mapman 

So the network needs to have sufficient bandwidth for the job.  That’s pretty much a given with modern home network technology

If you are streaming over the internet, you should also include the myriad of servers, routers and connections that make up the paths from music server to your home network and are shared by millions of other users.  All of which is often conveniently hidden by drawing the internet as a cloud, which is the last thing it actually is.

There is a fully engineered network design which uses a seven layer model - the Open Systems Interconnection (OSI) international standard but by and large we have chosen to use something quite different - the Internet.

The Internet has grown like topsy, and contains almost no standards.  About the best you can hope for are RFCs - Requests For Comment.  It only contains four layers!  Its address range prior to IPv6 is a pathetic 64,000 times smaller than Ethernet addresses - no wonder it has run out!  IPv6 fixes this but is really struggling to take off.

@deep_333 

where some dudes are telling him that there is no musical information below 30hz (facepalm) and a sub getting down to 10hz is meaningless...

The organ in the Sydney Town Hall has a 64-foot pipe which can be felt if not heard at about 10-Hz.  Stuart pianos from Australia can go down to 16-Hz.

Some organs that don't have the space or money for long pipes make use of your 'doppler' effect to produce low notes from two high-frequency (above audble) pipes.  It is really an interference effect, not true doppler which is caused by a speed difference between a source and a listener ...

@yoyoyaya 

Unfortunately, I am old enough to remember the launch of CD.  An astonishing 10 bits (roughly) are used for every 1 bit of the signal.  The claim is that errors can be detected and corrected for up to 4,000 consecutive bit errors, and there is no obvious discontinuity if 7,000 bits are wrong. As a demonstration, a 1/8 inch hole was drilled right through a CD and it played with no apparent adverse effects.

Philips knew the benefits of four-times oversampling from the get go which is why its early CD players sounded better than the competition.  Oversampling allows much gentler filters to be used.

Philips also recognised the difficulty of trimming resistors in their resistance ladder DACs, and only bothered to decode the most significant 14 bits.

PCM advocates should understand that none of this matters with Direct Stream Digital, where the low pass filter is in the mega-Hertz region and every bit is equally important.