Continuing because clumsy keyboarding posted before finished.
The framing protocol may or may not have additional parity and checksum error correction. A checksum is a calculated number that represent a mathematical calculation of the total value of the block to make sure there were no errors. If the checksums do not match, the block is discarded and retransmitted.
So that is just a portion of what is going on at the digital level to make sure that the data is what it should be. What about those 1s and 0s themselves. Although we call it digital, it is actually based on analog voltage levels. Once 12 volt and 5 volt, but even though still called 5 volt, most modern high speed circuits are based on a 3 volt threshold. That means anything greater than 2.8 volts is considered a 1, and anything lower is considered a 0. Moving that at todays speeds means that the clock that moves the data from place to place, and the voltage along the whole path is stable and consistent. The enemy of both of those is noise, temperature, and voltage ripple. Noise is easy to understand, temperature will cause the clock to be a little faster or slower, and also cause the transmitting and receiving chips to slightly change their response time to voltage changes. And the voltage ripple will cause the threshold for detecting whether it is a 1 or 0 to move slightly up or down. All this is to say that 1s and 0s are not so simple and the faster the data stream the more critical everything becomes. The quality of all the components, and the circuit design can and do have a big impact on how faithful the digital data is transported.
I have not read the full specification for the framing and absolute data rate for PCM and DSD data over various transport protocols (USB, S/PDIF, and ethernet). Each transport will have its own error detection and correction methods which is why some components sound better using one or the other transport. It is that their circuitry handles that protocol with better accuracy. It may be better noise rejection, better clock control, better voltage regulation through all the stages, or a combination of all of them.
The word length and error handling for most digital data have a long history, and you will seldom find an error in text in digital transmission. More likely, the whole message will be unreadable because the circuitry has detected errors at some level and rejected the whole thing. In pictures and video, the protocols really don’t care about single, and even multiple bit (word) errors because you will never be able to spot them in the mass of data that makes up even a small greyscale image. If the errors for images for video get too high, much like with text, the circuits and protocol will reject the whole thing as unreadable. That is not exactly the same with audio data.
Clock and noise are likely the biggest weak points for audio data from what little I know of the audio specs, but voltage and temperature will also cause problems. From what I have quickly scanned, digital audio in and of itself does not have any error correction built in, so it relies only on the transport protocol and framing for any error correction. What is contained in the block of words is assumed to be correct.
So, in summary, I believe that everything in the chain of digital audio data can and will have an audible effect on the final sound, whether you can hear it or not. Will it show in the specs, a sonograph, or a waveform comparison? You would not be able to find it visually, or come up with a way to measure it with electrical instruments, but could you hear it if you are listening for it? The more complex and layered the final audio output, the more likely you are to notice differences.
Moving digital audio data that represents 30Hz to 22kHz and 0db to 100db sound levels is not simple 1s and 0s.
