To be a bit more precise, you can refer to STP and UTP (Shielded/Unshielded Twisted Pair). As far as I have understood it, all of cat 5/5e/6/6a can exist in both varieties. The difference between cat6 and cat6a is that the latter has limits on crosstalk with adjacent cables; as I understand it it applies to the cables as-installed, not in any specific testing environment. Given that, STP certainly helps if you’re running several cables next to each other - but it’s not a strict requirement, and UTP is cheaper.
Cat7, which this claims to be, is subtly different: While UTP shields nothing, and STP has a shield around the entire cable, Cat7 shields each pair separately and the cable as a whole. However, I don’t actually think it qualifies as cat7 when terminated with a normal plug - there’s a bit too much crosstalk in the sections where the wires are parallel, so you’re supposed to use something fancier.
edit:
To be really exact: STP is imprecise and could mean any type of shielding. There is, of course, more than one way to specify precisely what you mean… the relevant standard, which most people seem to ignore, says to use x/yTP , where x and y can be S for a braided shield, F for foil, SF for both, or U for nothing; x is cable and y is each pair.
Cat6 typically comes as U/UTP, or F/UTP.
Cat7 requires something like F/FTP or SF/FTP .
Maybe the Ethernet cables are sold out, but you can still grab a set of these for under 7000 quid. Of course, they’re plain old analog, but they seem to have a pretty high bafflegabbium content.
It doesn’t matter, parity check in TCP will always check to see that all the information is transmitted perfectly. If, for some reason, the transmission fails, you would get quite noticeable errors, squawks, pops or lost frames, not a different quality of sound. The only effect of shielding would be in transmission speed, as packet-drops would force re-transmission. Spending money on a good D/A-converter would be much more sensible and would actually make a difference…
One of the comments on the audiostream web-page linked to previously does a better job of explaining this…
No mention of the drivers needed to make theses cables work optimally. Each system needs a pair of custom drivers to provide for maximum error avoidance. Fortunately, I can craft these drivers with only a short site visit and three weeks to fine tune at my lab. The cost for the matched pair of custom drivers runs between $2700 and 3500 for typical systems of this nature plus expenses. They can be installed by the user from files emailed from the lab. The installation procedure required months to perfect, but now seems like nothing at all. The improvement is astonishing provided everything else is up to standards. Watch out for those inconsistent weather patterns. They can wreak havoc on high end audio if you have sensitive ears.
Sure, any part of the path that uses TCP (or SCTP, not that it’s had much uptake) will eventually get a bit-perfect copy to the other end, barring really atrocious conditions - and the worst that could plausibly happen is a stutter if you manage to run out of buffered data.
The only setting where I can see this matter is if you were dumping decoded data directly into the D/A through a network cable with minimal buffering. I can’t imagine why anyone would do that, but if for whatever reason that’s what you wanted, it would probably be best to blast it through as UDP packets with no checksums, since you don’t have time for retransmits and a bitflip might be less audible than a dropout.
Even there you wouldn’t get any timing issues, since something on the receiving end would have to handle the packets of data and dump them into the D/A. To get jitter and such, you’d basically have to use the TP cable as no more than a standardized media to run a bitstream over, and dump that (unpacketized) bitstream directly into the decoder. It’s not at all impossible that someone has done, or at least considered, this - it would be something like TOSLINK with a copper transport. I doubt that’s what this cable will be used for, though.
I suppose this will satisfy audiophiles until they can directly quantum entangle the particles of their vinyl with the particles of their speaker cones.
A lot of users make the mistake of listening to their own systems. Problem is, any time you’re observing a signal you’re inevitably going to change it. To maintain perfect fidelity, you really shouldn’t even be turning your system on. Even looking at is iffy: I recommend keeping it behind a locked door.
I’m not going to worry about this. I generally listen to only one octave at a time with replays for each successive octave. It takes longer, but there’s no multi-octave latency effect and I find that I pay more attention.
While that’s true for data transmission, what some were pointing out earlier is that it’s somewhat ambiguous in the original link that we’re talking about digital or analogue signals in the first place. Indeed, the poster I originally replied to was referring to his own setup, where he uses CAT5 as speaker cables for analogue audio - which is why I referred to shielding.
You’re quite right that in a digital situation all losses are dealt with by error correction, and problems would be very readily apparent from the noises heard. On the other hand analogue signals could be affected in many ways… I’m not saying he should shield his cables by placing £2000 blocks of wood between the cables and the carpet, but rudimentary shielding of cables carrying analogue signals may give results in certain situations. How far to go and diminishing returns for effort given (and the snake-oil aspect of some of these “solutions”) are the bread and butter of these audiophile “products”.
