bits is bits

How on earth can a busy CPU cause reduced sonics?

@grunge1000 

As @mclinnguy points out, a busier CPU will generate more EMI.

In a poorly thought-out system, or one that has weak links caused by subpar components, EMI can indeed affect sound quality.

On the other hand, a well-balanced and optimized system eliminates unwanted noise before it can affect the end sound. 

Not sure about turtles though.

LOL..Yea right..

I'm not a measurements freak, but please do explain how this happens. So--You can hear the difference between a CPU running at 10% as apposed to 60%.

The OP is making the assumption that a single, coordinated digital master exists at each streaming platform, which is false.

I’m a musician with my work on streamers since the beginning, and know what goes on behind the scenes. There are post-processes done on files, as well as different versions of masters that can do the rounds at the streamers for newer bands. Digital masters from magnetic tape also were done at different times, and you can hear a more recent digitization have wow/flutter and dropouts compared to the same tracks on another streamer recorded decades ago when the tape was fresher.

Bits are bits is another topic. The main degradations are timing errors (jitter), missing or reordered data (packet loss/dropouts), bit errors/CRC failures, buffer underruns causing gaps, and analog-domain problems after the DAC (ground noise, RFI, power‑supply noise). 

Jitter is the most well known issue. Jitter is about when samples are presented, not whether their bits match the checksum. A packet can pass CRC yet arrive with timing errors that smear transients or disrupt DMA/clock alignment at the DAC. Checksums don’t address clock phase noise, PLL wander, or USB scheduling jitter.

As well, higher‑level processing can change samples intentionally. Resampling, up/down conversion, dithering, or driver interventions can alter the bitstream in ways that are valid and checksum‑clean but still change the audible result. Checksums don’t govern these transformations.

The point being many of these alterations/transmission take place at some point at the platform, not to mention transport protocols, buffering strategies, error-handling strategies etc all differ and can contribute to quality changes. 

Its crazy to assume, with all the variables, experimentation and competition between companies not to mention different versions of files floating around that "a bit is a bit, and a master will always sound the same". I mean just use your ears, it’s obvious. I have my own digital masters and I compare them to the streaming services and sometimes, not always depending on the album, they don't sound alike. And I made the music. 

Jitter is the most well known issue. Jitter is about when samples are presented, not whether their bits match the checksum. A packet can pass CRC yet arrive with timing errors that smear transients or disrupt DMA/clock alignment at the DAC. Checksums don’t address clock phase noise, PLL wander, or USB scheduling jitter.

@clustrocasual Great post. I certainly am no expert in digital, or have read enough to make me understand 10% as much as people who design digital gear or work with digital in an audio capacity for a living. But this echoes what I have read over and over from the experts who do. And yes, I hear it too. 

Do you mind if I copy this paragraph and repost it the next time some networking "expert" states all "bit-perfect" check-summed digital sounds the same? 

Oh, and if you have a graph to prove the above please share it with Amir. 

“networking "expert" states all "bit-perfect" check-summed digital sounds the same”

@mclinnguy 

I get what you’re saying, it really does feel like we keep going in circles. Still, I like to think these discussions help someone quietly following along, even if the main voices don’t budge. Honestly, I’ve stopped trying to reason with folks who have no interest in learning or experimenting for themselves 😊