analog or digital cables???

[ddmeltzer8]

Hi.
Is there any reason to choose analog over digital cables,or vice versa?
Thanks.

[Zero999]

Please provide more information.

Cable is inherently analogue.

Are you talking about sending audio via Ethernet vs analogue?

[Brumby]

Cable is inherently analogue.

This  ^ ^ ^ ... but there's more to it.

Please provide more information.

Yes, more information is necessary before we can offer any sort of useful response.

[spec]

Is there any reason to choose analog over digital cables,or vice versa?

Definitely ddmeltzer8

Like any other component in a design, you must choose the appropriate cable for the job.

But in many cases the cable is relatively unimportant- if you are just sending a few switch closures to an MPU, for example.

In some cases the cable must match a very strict specification, like Ethernet, USB, RS485, LVDS, etc.

Then you get cabling for handling power, like your house wiring or car wiring, which has completely different requirements.

At the very extreme there are microwaves where coaxial cable and connectors are mandatory and  must be of the highest quality. 

[ataradov]

The thing was that some cables was made for transferring digital audio better than other cable made for analog audio.

This is BS to extract money from suckers.

[Mr.B]

I agree with Alex - assuming the well known context of audiophool websites.

However, there is a valid argument that, in certain types of installations, a fibre cable carrying digital audio may be superior to a copper cable carrying analog audio.

[Gyro]

If, by digital audio, you mean an S/PDIF connection, then its impedance specification is 75 ohms. Using a 75R impedance coax cable will result in minimum reflections and best edge transitions. This is the only case where it will make a difference - on an actual high frequency digital data stream.

If you are talking about any other sort of audio connection, then the impedance of the cable makes no difference at audio frequencies. Really poor cable, with just a few strands of wire forming the screen might be more susceptible to noise pickup but that's about it.

General 'Digital audio' type hype on standard audio interconnects is just that - hype!

[Benta]

The thing was that some cables was made for transferring digital audio better than other cable made for analog audio.

This is BS to extract money from suckers.

+++1

[ArthurDent]

I cycle all my audio cables through a liquid nitrogen bath to align the crystals in the 100% pure copper to be inline with the current flow. Further improvement is realized by orienting the tube amplifier to be facing the left side of the flat earth. 

[Brumby]

I like this answer as a general comment:

If, by digital audio, you mean an S/PDIF connection, then its impedance specification is 75 ohms. Using a 75R impedance coax cable will result in minimum reflections and best edge transitions. This is the only case where it will make a difference - on an actual high frequency digital data stream.

If you are talking about any other sort of audio connection, then the impedance of the cable makes no difference at audio frequencies. Really poor cable, with just a few strands of wire forming the screen might be more susceptible to noise pickup but that's about it.

General 'Digital audio' type hype on standard audio interconnects is just that - hype!

With this adding some specifics in differentiation of various uses:

Like any other component in a design, you must choose the appropriate cable for the job.

But in many cases the cable is relatively unimportant- if you are just sending a few switch closures to an MPU, for example.

In some cases the cable must match a very strict specification, like Ethernet, USB, RS485, LVDS, etc.

Then you get cabling for handling power, like your house wiring or car wiring, which has completely different requirements.

At the very extreme there are microwaves where coaxial cable and connectors are mandatory and  must be of the highest quality. 

If you could find that link, we could address what it says more precisely.

[bson]

The problem with AES/EBU and derived signal standards (SPDIF for consumer price points) is that the sample clock is embedded in the bit stream.  This means waveform integrity is everything since, well, it's the sample clock.  The consumer coax variety is single-ended, meaning the shield braid or foil is also the signal return path, which degrades its ability to act as a shield.  AES/EBU runs over XLR, so is both differential and has a shield separate from the signal return lead.  TOSlink had the potential to be totally immune to noise and reflections, but the transceivers were made to be as cheap as humanly possible for the consumer market, and never performed well.  Toshiba never targeted anything past a consumer audience for whom cost is everything.

Impedance matching is also critical, at 100Ω.  Even though short runs will have trivial reflections, any reflection will manifest itself as sample clock jitter.  This is simply unavoidable since the waveform contains the sample clock.  (Not only that, but it will also be signal self-modulated!) SPDIF can be done perfectly well in this regard; however an AES/EBU or I2S (over USB 3, HDMI, or CAT5) interface from a reputable brand (not talking eBay kit stuff here) is almost guaranteed to do it right.  (Even Chinese ones, like Audio-GD or Yulong Audio will design for proper termination.)  And if it has an AES/EBU interface, use it!

The reason the sample clock is in the bitstream is that AES/EBU was intended as a digital replacement for analog interconnects; this means if the source plays a little faster, the clocking is sped up a little; if plays slower the clocking is slowed down.  This is required for uses like maintaining frame-accurate sync with video (especially for transfers, or splicing between cameras or audio sources), between multiple channels, or trick play.  For a purely home audio application it's obviously superior in every way to have a packet format that specifies the nominal sample rate and then flow-control the transfer to the playback device and let it clock it locally from a low jitter XO.  But that doesn't work for many professional applications.