The Shunyata Research OMEGA-X-Ethernet Cable

I am only familiar with quality engineering principles for medical devices and for audio (music files).  Let’s stay with music files.  Protocols, including the Red Book Standard, UPnP, UDP, TCP/IP uses cyclic redundancy checks and imbedded check code sequences to assure data is not corrupted or lost.  The equipment buffers the data packages and performs redundancy checks to assure bit perfect files.  I am not familiar with your example where there was immediate data transfer without benefit of redundancy checks.  
 

We agree that audio is not only about bit perfect data packet transfer since transmission. The Ethernet protocols, and rugged digital audio protocols above only assure accurate transfer including sequencing. These protocols use packet  switching and stacking.  Each packet is timestamped and reassembled.  The timing critical to sound reproduction that produces jitter is a continuous conversion of digital data to analog.  This is handled by streamer, DAC, or external clocks after the Ethernet cable in the system circuit.  So, I do not believe the Ethernet cable has a direct effect on jitter.  Rather, if not shielded, it can have an indirect effect by RF coupling that can affect streamer and DAC clock performance, and produce RFI distortion in the analogue signal as I experienced.  

@jsalerno277 

The equipment buffers the data packages and performs redundancy checks to assure bit perfect files.

The sending device cannot know if there was an issue with the receiving device, unless the receiving device informs the sending device.  That is where timing issues for a DAC will surface, either with gaps in the data stream, or out-of-order packets (which is not a problem for downloading your bank statement, because as long as all of the packets eventually arrive, the computer knows how to assemble the file).  But when a DAC is playing the bits, in real time, as they arrive, problems with packets will result in jitter.

Some DAC boxes do buffering (not the actual DAC, but a chip under the same hood).  That buffering chip is now acting as a transport and clocking the bits that it is feeding to the DAC.  So under those conditions, lost packets / retransmissions will not matter (well, as long at the drops are not severe).

But DACs that do just their purpose-built function, and leave the transport business to a digital-to-digital converter (DDC) or to a streamer, then bit-perfect timing from the sending device becomes critical.

Whatever the last chip is that connects to actual DAC chip is critical for timing.  If it is a buffering chip, then it is the critical chip doing the transporting of the bits to the DAC.

Rather, if not shielded...

Yes.  True for all cables.

When it comes to a stereo sounding wonderful, there are numerous levels of wonderful.

My DAC sounded wonderful, until I added a DDC into the data chain, and had the DDC feed my DAC the bits.  The DDC uses two, ultra precise clocks (one for 44,100 Hz and its multiples, and one for 48,000 Hz and its multiples).

With the DDC feeding my DAC a less jittery bit stream (jitter I never heard), I reached a new level of wonderful, due to less jitter.  Now I can hear the jitter that I had previously never heard (or never recognized).  If I remove my DDC, I hear the jitter.  If I had never inserted that DDC, I never would have heard the jitter.

You purchased a $500 Ethernet cable that was not suited for audio.  Perhaps one that is suited for audio will get you to a new level of wonderful, more so than your very good Blue Jeans cable?  No way to know until you try.  That is how I found out with my system.

@seymour-krelborn 

The OP focus is on the network Ethernet cable.  You are focusing on the DAC.  

We agree data packets transmitted over the Ethernet can be corrupted.  The bits travel on an electric current and any electrical anomaly can cause corruption. Think of streaming television where, in an electrical disturbance you can have screen dropouts.  
 

What I continue to stress is that Ethernet protocols are robust with built-in error detection such as CRC (Cyclic Redundancy Check) and imbedded check code sequences that flag an error. The Ethernet protocol will simply request that packet again.  Streamers and DACs do no rely on corrupted packets;  rather, they buffer until  a correct, complete packet is received.  So, in a well-functioning network, you won’t hear sound quality issues because the data is either correct or it’s re-requested, unless the buffer is too small or network latency is extreme, where you could have dropouts.  Audio file protocols are also robust with similar redundancy checks.  Therefore, audio files are bit perfect on properly designed streamers and DACs on a functioning network due to Ethernet protocols and industry digital music file protocols.
 

The Ethernet assures accurate data packs not timing that you are discussing, unless, as I stated before, the electrical signal over Ethernet carries RF coupled to the streamer or DAC click, where clock function is affected.  Timing from an audiophile perspective is critical when the sequenced  bit perfect data packages are converted to analogue.  So the Ethernet has assured the streamer or DAC has received a bit perfect file in sequence.  The conversion of the sequence is to be at standard timing (44.1, 96 KHz as an example).  The clock assures the standard file timing is accurate at conversion.   If there are timing errors in the digital data packages the resulting analogue voltage steps can jitter, which can introduce noise in the analog waveform. That jitter, in turn, can raise the perceived noise floor, blur subtle details, and reduce soundstage precision.  You experienced better timing is directly proportional to sound quality when you added the external clock.  My experience was different.   The $500 audiophile Ethernet cable was from a very respectable audiophile cable designer/manufacturer.   However, its metal connector housing was coupling RF.   The well designed cheaper cable produced improved SQ because it better insulated RF.  
 

in conclusion:

1. The Ethernet can send corrupted data packages
2. The redundancy in the Ethernet protocols assure data package correction and bit perfect data at the user level if the network connection is sound.  
3. The Ethernet protocols assure correct data sequencing, but this is different from audiophile timing concerns. 
4. Digital music file protocols assure bit perfect music files are timed properly at conversion to analogue.  
5. Therefore, the Ethernet cable does not affect jitter directly.   The way the Ethernet cable can affect jitter is if it is improperly shielded and permits RF coupling affecting clock performance. 
6. Ethernet cables can affect sound quality simply due to physics.  The degree of the effect and the benefit / cost ratio of expensive cables can continue ad nauseam.

Interesting exchange.  Thanks.  Have a phenomenal day and listening experience   

@jsalerno277 

+1 

I agree 100% with your post. 

Thanks.

So not to derail, but what about other digital cables then?   Spdif, AES, USB?   I have not deep dived the Ethernet cable rabbit hole, so I can't speak to that.  I use Supra 8 in my studio because it was recommended to be a solid cable and wasn't insanely expensive.  And I use a BJ cable in my other system.  But I have noticed a pretty massive difference between different spdif and USB cables.  Many people argue the same things for those - that it's all 1s and 0s it can't matter.  Clearly it does though as a kimber d60 clearly outperforms the BJC I had before.  And each tier of Shunyata USB gave me improvements from my PC to my RME interface.  All of this is to say, just listen to your system and use your ears.  Swap cables back and forth several times.  Make note of what you're hearing and then see if it's repeatable. 

Also side thought - make sure all power cables are away from other cabling because this actually makes a giant difference on a revealing system.  Just spent some time reorganizing my cables and it made a substantial difference on my secondary system!