We Need To Talk About Ones And Zeroes

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

@lalitk 

After perusing your virtual system following @mdalton ’s compliment of same, I would say that if my own system were anywhere near the state of evolution yours is in, I would likely be more open to evaluating components I currently consider secondary.

My own system would likely look very different than yours, and I suspect we enjoy different musical and listening styles. One thing they would probably have in common though is the NADAC stack. Why AES67 isn't better known / more prevalent in the audiophile world is beyond me.

It’s a beautiful system. Congratulations!

Like any well engineered solution, the best systems are in fact built based on facts or rules first, then trusting your ears from there.  
 

Arguments for trusting your ears alone are flawed.   Your ears can only hear what is there, not what may be missing.  Facts and rules come first to help have best chance of covering all the bases first thereby giving your ears the best chance of being the most happy. 
 

The primary goal of streaming/rental music services should be for discovering new artists/music.

If you like the album, buy it and pay the artist...not to mention permanent ownership.

If it’s only available in redbook CD, so be it...

If there is a 24bit studio master available, burn it on blu-ray and achieve the highest fidelity possible.

Getting into all the nitty gritty of error propagation, containment whatever and arguing it with all the supposed digital geniuses could drive someone nuts soon enough. No one here with the requisite engineering background hacked into or looked under the hood of everything to be sure of everything...

Yes but is it “high end” TCP/IP? 😬

@lalitk 

You know I love your system, and I’ve always enjoyed your contributions, but I am gonna have to disagree on this one.  Am reminded of Ptolemy.  For gosh sakes, everybody watched the sun go around the earth, and that fit nicely with some of our religious beliefs.  So when Ptolemy made the math to back up a geocentric model of the solar system work, it took 1400 years before we were finally able to get the science right - thank you Copernicus!  (Kyrie Irving has reasserted a flat earth view, but that’s probably for a different convo, lol!).  

So I think it’s pretty important to start with a sound theory and understanding of the science before we start trying to convince ourselves that we’re hearing stuff that, while it fits our religion, threatens to take us back to a pre-Copernicun world.  And I think that’s why the OP started this thread.

@lalitk 

Thank you for your post. In principle, I 100% agree with you.

That’s why I was careful to write that pre-streamer digital components should make no difference in sound quality. I was also careful to insert a qualifier about "all power supplies being equal". Finally, it is conceivable that, amongst the millions of possible component combinations, a new switch might correct some kind of incompatibility or condition caused by the old switch.

In short... I don’t know. I’m aware of opinions out there holding that passive digital components may have a positive impact on sound quality, and I respect some of them.

Claims of "stunning" or "transformational" differences, however, are 99.99% certain to be hogwash (the remaining .01% being due to correcting some equipment incompatibility as mentioned above). Barring the latter, folks making such ridiculous claims likely haven’t heard any difference at all, let alone a "stunning" one, and probably couldn’t tell the difference between the cannonade in the 1812 Overture and their wife slamming the lid on the trash can.

Which brings us to, if passive digital components do make a difference in sound quality, how big can that difference possibly be expected to be? How big of a positive impact can these components make, considering that the packets they transmit at that stage represent anything and everything besides music? I believe, very very little; and whether it’s worth pursuing it is a personal choice. Personally, I am not willing to spend time auditioning network switches, because the reward is more likely than not to not justify the investment. But that’s just me.

You mention measurements. I’m aware it’s something of a dirty word for some around here, but the good news is that the bit-perfectness (?) of audio streaming is demonstrable without any measurements involved, simply by checksumming the sent and received data.

For the record, I am biased toward science and rationality (in case you didn’t notice :); however, I think measurements are only as good as what they measure, and that they do not necessarily correlate to sound quality. I do believe John Atkinson’s work adds value to Stereophile reviews, creating a balanced approach.

I think I read somewhere that John Atkinson himself said he does not review digital components because "there is nothing to measure" (correct me if I made that up!).

“Router, switches, Ethernet cabling and the like should have zero effect on sound quality“
@devinplombier 

You’re absolutely right from a purely technical and engineering standpoint. However, many experienced listeners here reported audible differences when they tinkered with Ethernet cables, Routers/switches, Network isolators and filters ahead of a well designed streamer’s. 

The proof is in the pudding and in audio, your ears are the spoon.

Theories, specs, and measurements are critical, but what you actually hear is the final word. If swapping a switch or cable makes music more alive, relaxed, or emotionally gripping in your system, then it’s real for you regardless of what measurements suggests. 

The best systems aren’t built by following rules, they’re shaped by listening, experimenting and trusting your own instincts. 

I am not at all horrified by any of this. I am thankful streaming works well enough to meet the quality standards I demand without a whole lot of fussing about. I appreciate that physical media may in fact be better but in the final analysis I am not sure the difference is audible. If I cannot hear the difference then its a non-problem.

For the application of producing sound, the networks job is to have enough bandwidth to deliver the data needed fast enough so the streamer can stream in real time.   So the network needs to have sufficient bandwidth for the job.  That’s pretty much a given with modern home network technology.  
 

For wireless connections, you have to make sure the wireless connection is strong enough.  Bandwidth will decrease with distance and can become a bottleneck if not done well. 
 

Thrn it’s the streamer and DAC working together to take the data off the network and convert it to sound.  This is where there are lots of possibilities and results can vary widely depending on specific implementations component to component.  
 

The good news is that the technology here is now fairly advanced as well and in practice realized well by many newer products at all price points.   

@richardbrand 

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

Some highly knowledgeable folks contributed their expertise to this thread, but rather than learning from their expertise you chose to go ask google AI.

Incidentally, as you know, 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, but the gist of it seems to be that 100% error-free transmission of a music stream cannot be 100% guaranteed 100% of the time. To which I’m happy to concur: A listener may get caught up in traffic in an underpass and their buffer times out, a submarine may sabotage an underwater backbone cable, etc.

What should be abundantly clear at this point, however, is that music streaming via Tidal and Qobuz, the only kind that matters to audiophiles in this day and age, is error-free absent a rare unrecoverable error; if an unrecoverable error happens, it will manifest in gross failure and playback will stop; and therefore, in no case is a TCP/IP stream or file transfer ever susceptible to the kind of subtle sound quality degradation that strikes fear at the heart of audiophiles. It will either work perfectly - meaning, your streamer will get exactly what Qobuz sent - or not at all.

So it stands to reason that that TCP/IP stream will remain unaffected by components it encounters in the home just like it was unaffected by the components it encountered in the depths of AWS - until it arrives at a component capable of modifying / altering sound quality, aka the streamer.

Router, switches, Ethernet cabling and the like should have zero effect on sound quality (again, all power supplies being equal), and devices claiming to "fix problems" with your home Internet are necessarily making false claims, since there are no problems there to fix.

Happy listening! 

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

At this level, absolutely nothing guarantees error free delivery. This is a straw-man argument where one picks and chooses what they feel is error free or not.

The question is, is it audible?  I'd say no.  What you hear is the quality of the streamer's performance and the original stream.  There are legitimate arguments to be made about any given device's jitter performance or DAC reproduction and that's about all.

So enjoy your cheapie cables. 

Having said this, having heard horror stories of lightning traveling down the cable modem and taking out multiple PCs, TVs and other devices at once without leaving any visible damage I use medical grade Ethernet isolators at the end of long (30') runs. 

Ahhh, the power of buffers and asynchronous output.

What I think many are missing is the idea that streamers are not like the phone of old, with effectively one solid circuit between the caller and listener.    There are two separate processes going on at once.  The part that feeds the buffer and the part that doles out the end result.

For pre-recorded media the buffer/bucket can be 30s big or bigger.  The part that gets the stream feeds it into the bucket ahead of time.  The idea is to have enough time that when the TCP/IP stream says "I’m missing packets" or "I have a broken connection" it has time to communicate back to the source and re-request the missing data or start the stream again.  It’s a subtle science here in making the guess as to what the best strategy is to get things going again and when to declare surrender.    If you stream music in your car you have no idea how much your phone is relying on these buffers to get you through the bridge without interruption. 

Here I monitor my Internet access very closely and have failover Internet so when my cable Internet goes away my cellular Internet takes over.  The process takes about 10-20 seconds.  I can tell you that this has happened repeatedly and this has not affected my music.  Of course there are severe Internet events which eventually stop everything but the power of my streamers to driver right over those bumps is a testament to how resilient this whole process is.

While the feeder is busy fixing up the missing data your DAC or TV still has those 30s of data to offer you, so hopefully the stream gets fixed before the bucket is empty. 

We keep talking about noise.  Ethernet is naturally galvanically isolated to a few hundred volts.  It has to be.  Fiber of course is as well.  The bigger issue in my mind are either surges which are high enough to break through that isolation or your Ethernet cables leaking into your AC or interconnects.

Noise in network transmission is not additive.  My router doesn't add noise to the signal from the cable provider.  Any noise is between my router and the next device down.  Reliability is additive, but not noise.  If you have an Ethernet cable capable of 1GigE with no packet loss and no jitter then congratulations, you've done all you can.

The issue that then remains is jitter on the output.  The input and output streams share a buffer and making sure that they do not interfere with each other is another subtle science, which I’m sure is now tackled by a variety of low level libraries available for the particular microprocessor your streamer uses.  I’m not saying they are all equivalent, but that how well your streamer handles this matters. 

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

Yes but is it “high end” TCP/IP? 😬

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. 

@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

@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

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.

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 

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

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.

I highly doubt bluray players/transports for blu-ray audio are going obsolete any time soon...

Panasonic is bound to keep it alive...Sony playstation consoles will be around forever...thanks to the ever growing number of gamer dudes. In fact, i believe sony has been killing other manufacturers off (yamaha, for instance) w.rt the bluray market. Essentially, they take a loss with ps5 player/console sales & make their money with game sales and subscriptions. But, to be fair,  the ps5 is a very high quality bluray transport for audio. I wouldn’t know about video, am not a videophile.

The future of sacd could be bleak. 

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!

richardbrand

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.

No, Qobuz is correct - analog audio is just a series of sine waves (and cosines). That's the Fourier Theorem. If you doubt that, just look at the squiggles on an LP - a series of sine waves. It's not infinite, though. To do that you'd need infinite bandwidth, which isn't needed and isn't possible.

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.

But the future is "error free" because Qobuz is using TCP/IP and the file is at least partly cached before playback begins. And 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.

TCP/IP only guarantees bit perfect transmission after the transmission is complete ...

It isn't clear what you mean here. TCP/IP guarantees perfect transmission with the transmission of each packet. Each packet is "complete" unto itself.

Qobuz is very tight-lipped about the actual protocols used ...

My experience is just the opposite - I've found Qobuz to be remarkably accessible and transparent about its protocols. My information regarding how Qobuz works comes right from its US execs David Solomon and Dan Mackta.

My only connection with Qobuz is as a paid subscriber and to be clear, I have issues with the service. In particular, its files are often the "remastered" compressed versions, so my local files often sound better. But facts are facts, and Qobuz delivers bit-perfect audio direct to your streamer, provided your connection speed and network are capable to the task. And for audio, those requirements are minimal - almost trivial here in the third millenium.

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. 

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

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

@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

... anyway, UDP is used only when latency is more important than accuracy: telephony, gaming, live sports. It is not used at all for audio streaming because latency isn’t that important, but accuracy is. Accordingly, both Tidal and Qobuz stream over TCP. Not sure what Spotify does, but no one cares.

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

"Noise" and the so-called "jitter" are immaterial to digital-to-digital transmissions, and the vast majority of quality DACs readily handle noise and jitter before they can get to where they might negatively impact sound quality.

It’s probably safe to say that digital components (ie components whose inputs and outputs are both digital), and that have no onboard processing power, such as switches, routers, digital cables, etc. do not have a bearing on sound quality (again, all power supplies being equal).

Streamers, at least theoretically, should not either (digital in, digital out) but they do, or at least they can.

Streamers are computers in a pretty case, and even the weak-kneed Raspberry Pi-class CPUs employed by Aurender and the like have plenty enough power to handle relatively sophisticated DSP, thereby giving the designer wide latitude to transform the sound at will.

It isn’t that hard for DSP to make a streamer sound like a tube amp or, why not, a broken phone booth. Wanting to harness that power is understandable; what would you do if you made and sold high-priced streamers? Presumably, you would give your customers a taste of what you know they crave, just like the chef-owner who ladles fat and sugar in every dish up to just beneath the threshold of detectability. Pulling it off is a minor art form, but you don’t catch flies with vinegar.

DACs are half-analog, so of course they can make a difference in sound quality. So can upsampling, DSD conversion, and other signal processing taking place within the digital realm, but that’s a whole other conversation.

Personally, I believe system voicing is the job of the amps / speakers pairing. If any additional voicing is desired, it should be handled at the preamp level.

If every component in your system, including your digital chain - which should be absolutely neutral - intentionally dials in some level of euphonic distortion, pretty soon things become unmanageable. It’s like newspapers where every single writer is now a columnist whose important opinion on national affairs deserves to be heard, including food writers.

@richardbrand 

After seeing your post of last night I worried local winemakers were boosting their product with methanol. I'm relieved to see you're OK this morning 🙂

@richardbrand 

Thanks for the clarification. I hope I can remember it. Something tells me that this noisy streaming chain is purpose built for longevity and reliability as best they can while keeping the bottom line in mind. Purpose built but not that elegant. 

All the best,
Nonoise

So on top of Qobuz using TCP/IP protocol,  streamers and their operating systems has a bearing on delivering bits. Here is a read in regard to how Euphony OS (which I use) delivers data to dac, https://euphony-audio.com/hesk/knowledgebase.php?article=18

richardbrand

... In general, UDP/IP is the protocol used for streaming ...

That's not the case with providers such as Qobuz, which use TCP/IP protocol. That delivers bit-perfect data right to your streamer.

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

 The other glaring variable in resolution is antique coaxial internet service versus fiber optic or microwave mesh. At my old house I was limited to coaxial and it was not pretty. The technician told me he had a job for life replacing coax connectors under the sidewalk. They lose continuity like clock work in summer heat. 

It seems to me, and in this bunch there is someone who will correct me if they think I am wrong... :) IT seems to me that there are very few things that determine the accuracy of the played signal out of our streamers. Number one is the source file. How good was it? SACD or at the other end an mp3 file? And then at the end of the digital transmission chain is the accuracy of the DAC that we use to decode the digital file and finally then our playback equipment...amplifier and speakers or headphones. Everything else in the middle is basically the same for everyone. Its all ones and zeros with error correction built in. So that part is the same for everyone. The difference is truly in our playback equipment and I am going out on a limb and say any audible differences within today's DACs are negligible and surely well below the threshold of hearing and definitively well below my ability to discern the differences. And even if I COULD hear the difference between my 329 dollar DAC and a 30,000 dollar DAC, my common sense and budget dictates I buy the 329 dollar unit. I know there are those here that could and would buy the 30k unit but I also suspect the reasons for doing so go above and beyond perceived better performance. Any of you guys going to admit to a leaning towards buying something for its looks? I have done so in the past...and probably will again. Any takers?

All of this is over my head but my lying eyes don't deceive me. Blu Ray players are head and shoulders above streaming. Period. From AI Overview:

Streaming services use compression techniques (like HEVC/H.265) to reduce file sizes and bandwidth usage, which can lead to some data loss. Blu-ray players, especially 4K, use less aggressive compression (H.264/AVC) to preserve more details. 
Streaming services typically use lower bitrates (data transmission rate) than Blu-ray players. For example, a 4K Blu-ray might have a bitrate of 40-70 Mbps, while a streaming service might only offer 10-25 Mbps.
Due to lower bitrates and more aggressive compression, streaming can sometimes show more visible compression artifacts, like banding, blocking, or a loss of detail in dark or fast-moving scenes. Blu-ray, with its higher bitrates and less compression, generally produces a clearer, sharper, and more detailed image.
Blu-ray often includes lossless audio formats (like DTS-HD Master Audio or Dolby TrueHD), which provide better sound quality than the compressed audio formats used in streaming (like Dolby Digital Plus) according to Audio Science Review (ASR) Forum (of all sources).
Blu-ray discs can store significantly more data than a streaming service. A standard 1080p Blu-ray can hold up to 50GB, while a 4K Blu-ray can hold up to 100GB.Streaming services, on the other hand, compress the video into much smaller files, often in the range of 10-13GB for a 4K movie.
 

The argument that a Ferrari doesn't turn blue for a moment is specious. What streaming does is change the color tone from something like Rosso Barchetta to Rosso Berlinetta or Rosso Cino or even worse, Rosso Corsa. 

When streaming audio, there's really no doubt that all the packets get there in time and in order but that's a numbers game. That's all that's being discussed and relies on everyone to just take their word for it as they can hear the difference.The signal in a CDP isn't compressed and travels a matter of inches while the streamed version is compressed and then uncompressed and travels around the world. 

This numbers game presupposes that the resultant sound is not in the least affected when compressed and uncompressed and focuses only on the numbers. That's the very definition of a red herring:

A red herring is something that misleads or distracts from a relevant or important question. It may be either a logical fallacy or a literary device that leads readers or audiences toward a false conclusion.

How many here jumped on the MQA bandwagon only to see it shot down? That compression scheme corrupted the sound. How many are fully invested in streaming and find the need to validate it to others? There are so many previous threads on this that, in the end, went nowhere. Both sides stayed put. 

A casual search on the internet shows more contradictions to arguments for streaming not being brought up but well known to those who can rattle off numbers and protocols like there's no tomorrow. It's in threads like this that one can find consensus to put forth their arguments without fear of being challenged. I certainly don't have the chops for that but there are so many recording engineers online that say otherwise as well but they rarely frequent sites like this. Some have in the past and when they do, the thread goes silent for awhile and then gathers momentum, picking up where it left off with the hopes of not hearing from them again. 

It's not that those who prefer CDs and better quality endpoint devices think there's magic in our choices though we are told that.  It's the ones who say that a compressed signal can travel through a dirty and noisy chain and remain its virgin self when uncompressed that abide by magic.  

All the best,
Nonoise

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.

How this pedestrian interface became quasi-standard in high-end digital audio is puzzling.

likely due to no agreed upon standard amongst manufacturers. Agree that an interface optimized for high-end audio would be very beneficial 

But it's not 1's and 0's though. Is it. 😘

USB was developed almost 30 years ago to replace and consolidate the old serial, parallel and PS/2 ports for PC peripherals, and later became ubiquitous in small electronics chargers.

How this pedestrian interface became quasi-standard in high-end digital audio is puzzling.

USB evolved tremendously over the decades and USB4 is a powerhouse, however many of today’s high-end DACs and streamers are still stuck in the USB 2.0 era.

I cant tell the difference between Tidal MAX recordings and the same high res on the HD in my Aurender N20 > MSB Cascade > MSB M500 Monos > Estelon Forzas.

My general understanding is as long as the bits arrive faster than they need to be used up (filling the buffer), that a decent DAC will convert them nicely to analog.

I dont subscribe to the "hifi router" camp lol , nor switches or CAT6 etc.

I don’t know if any of this resonates with those following this thread

@livinon2wheels 

It certainly resonates with me. I believe the choices you’ve made show admirable self-awareness. More often than not it’s not so much what we do that matters as why we do it. Best wishes for a prompt return to normal after the tragedy you’ve experienced.

Ok I'll chime in...the equipment we buy whether its an 80 dollar wiim mini or the top of the line wiim, will in many cases will be wholly adequate because it isnt the weak link in the chain. Many of us or at least some of us have quite limited financial means to buy stupid expensive equipment and I put myself in that category. Choices are made based on bang per buck, feature set and yes overall performance too. Streaming hi bit rate audio is on most affordable equipment going to be just as good as physical media held in your hand. Are there issues with streaming? Well sure there are...sometimes its just not good, but most of the time it is superb. The physical media is better, more stable and provides consistent performance. Its also a lot more 'work' - getting up from something I am working on to change a CD is not a welcome interruption. Streaming avoids that event and just keeps going like the energizer bunny. Choose a stream and get to doing whatever it is you need to do while you enjoy some tunes in the background...maybe a fave comes on and you crank it up and take a  'song break' from your work. Or maybe its a kick back evening, a few drinks some good music from a favorite channel...at near concert levels. Oh yeah I have done a few of those. OR maybe its streaming in the kitchen while you make dinner. Streaming is compelling, both for its really high quality and for its convenience. I may never replace all those CDs I lost in the fire...but the jury is still out on that. As far as the equipment you use, choose what you like you only have to justify your choice to yourself. If a 30,000 dollar Streamer/DAC is what it takes to make you happy then go for it, my 339 dollar Wiim Ultra streamer and the emotiva amp that follows it along with a cheap 10" sub and a pair of Opal bookshelfs from Dayton audio represents a roughly 2000 dollar investment that makes my desktop system an amazing experience. Especially for the money. None of these components are the best in their category probably, but the whole is greater than the sum of the parts. And it just works. No fuss, Astonishing performance especially for piano music, which in my experience is extremely hard to reproduce accurately. Yet I find myself listening to mostly Piano music on this cheap little system.  The drawbacks: it does not have the dynamic range to play at live levels for orchestral or rock concerts... but that isnt how I use this system. Living in an apartment with neighbors requires a certain amount of restraint in using the loud pedal. So...it is enough for the circumstances. And I think that is the real message here, we all have different living situations and have differing requirements and preferences. There is no 'one size fits all' in making these choices. My vote is for streaming for its convenience and not requiring storage space for the physical media. Since I lost most of that in the fire, replacing the media and the storage cabinets to hold it all is a sizable investment that is getting harder by the day to justify. I am trying to simplify my life not make it more complicated. I don't know if any of this resonates with those following this thread, but as Mark Knopfler would say "do your worst" :)

@mdalton

That thread you linked is very good indeed. It features some definitive viewpoints.

I don't need to read anything from anybody anymore. I know the truth.

There is light at the end of the tunnel.

one of my favorite threads ever.  starts with servers - one guy claims servers need a couple weeks burn-in before their sound is optimal - but then makes a hard right on page 3 to switches, where one guy explains that the reason you can’t hear a difference between a $20 switch and a $700 switch is that you have to spend at least $3500 on a switch before there’s a difference.  Not making this up:

old thread

A complex topic when allied to digital music reproduction, made more difficult by S/PDIF.

Assuming sound engineering the bits at the output of the receiver in your device at the end of the Cat 5 cable are precisely the same as the bits stored at the source.  If they were not the modern world would collapse as no transaction could be relied upon.

Setting aside the linearity of the DAC chip(s) there are then, however, two (digital) issues that arise; what data gets presented to the DAC processor (the component(s) inside the "DAC" box that generate the analog signal) and when is that data presented. 

Unlike the TCP/IP ethernet or WiFi connection the S/PDIF has error detection but not correction so a truly terrible digital interconnect could, I suppose, result in bit errors, resulting in data loss.

My suspicion is that any unwanted artifacts that are caused by changing between decent digital cables are caused by jitter being introduced and not eliminated by processing before the data is presented to the actual DAC chip(s).

I did an experiment with different cables between my Aurender N100SC and the Esoteric K-01XD.  My baseline is the Cardas Clear USB connection, and I do have an external Stanford Systems Research rubidium clock.

The three cables that I tested were an MIT from the 90's, a "Trubutaries" Video Cable - not high end, not even a specific digital interconnect, and a two meter audio junk interconnect from who knows when (or why).

I did not listen extensively but the MIT cable and the Video cable were indistinguishable.  The junk interconnect however was clearly not up to the task, the sonic quality sounded like hard clipping was occurring!  

The Esoteric K series DACs have buffering and clock synchronization before the actual DAC processor, that appears to have taken care of any jitter issues.

I suspect that the audio cable did not have the bandwidth to support the 1.2MHz 24 48 S/PDIF signal and so there were data errors. (S/PDIF has a parity bit, hence 25x48,000  = 1.2MHz).

BTW, I take exception to a total dismissal of switch mode power supplies.  OK regarding wall-warts, but, for example, Benchmark have transitioned to use SMS to reduce noise.  It all depends on the quality of the power supply.

Once again, my apologies if I am a bit off-topic, but an interesting question makes my mind diverge onto allied topics.

I keep reading the same old stance from folks that either don’t stream or streaming for fun with their fancy analog or CD players. You know who you are :-)

It’s not about the data but about the context (emotional, physical, psychological) in which it’s delivered. Think about it before you eager to call out the cult-like belief in well designed streamers with premium parts without understanding why something works and works well over mass produced streamers. 

I have compared streamers ranging from $500 to $25K. You don’t have to spend $25K to get a great sound, but pick a streamer that is well engineered to deliver bit-perfect digital output by implementing low-noise design, stable clocking, robust power supply and isolation (ethernet noise or power rail interference). 

So why some of the streamers sound different? Because they prioritize  aforementioned underlined elements that ultimately impacts how bitstream is distributed to your DAC. 

The message should be; don’t fall for over-priced pseudo tech without due diligence be it a DAC, Streamer or Switches.