Gordon Rankin Says I'm Wrong About USB Cable Sound!

[erin]

Audioquest's line of Ethernet cables are all Cat 7 and they range in price from really cheap (if there's a benefit) to "yikes!".

 

I'm going to buy two different models in the upper-middle of the line and depending on what I hear, one or both will go back. Like you said, simple!

 

Thanks for sharing your experience. Now I'm even more looking forward to trying it.

 

In that case you should probably obtain a reputable, but non "hi fi" branded CAT7 cable to compare to the Audioquest. Then you will know if it is the CAT7 in comparision to CAT5 or 6, which is making any difference.

[new_media]

Well according to this organisation, there are plenty of USB cables that meet the 90 ohm specification.

USB.org - USB-IF Compliance Program

 

Seems like you just need to find a cable that has passed the compliance testing.

 

Looks like the Belkin Gold Series is High-Speed USB Certified. I think I'll grab one of those. On sale for $7 at Amazon.

 

[k6davis]

In that case you should probably obtain a reputable, but non "hi fi" branded CAT7 cable to compare to the Audioquest. Then you will know if it is the CAT7 in comparision to CAT5 or 6, which is making any difference.

 

Excellent suggestion. Thanks.

 

That way, I'll be able to compare the quality non-audiophile Ethernet cable to two different grades of Audioquest cable.

 

That'll be interesting, for sure.

[beanbag]

Now, it won't be long before someone posts an attempt to totally repudiate everything you just posted... (*sigh*)

 

(*sigh star*) (The complex conjugate of sigh)

 

That would be me.

Rankin's explanation doesn't make sense, and this is from a guy who learned about USB audio protocols an hour ago.

Let's assume that USB audio streaming has no error correction, but maybe it has CRC error detection. If the USB cable were to flip a bit, then either it would A) alter one of the audio samples, or B) drop the whole packet. (This part I am not sure) I don't see how it is possible to "lose" a single sample.

 

In the case of B), packets contain 1ms worth of audio data. To lose that would not be a "subtle veiling effect", but a serious clobbering of the signal. If the difference in cable sound were due to packet loss, it would be a steady stream of these serious clobberings.

 

In the case of A) where the DAC allows bit flips, then that would be super easy to test for - just play nothing and let the 0's get turned into 1's, and you would get a steady stream of clicks and pops. Thankfully, Kenny confirmed that this does not happen either.

 

In any case, the "data loss" thru usb is supposed to be a very very small number, like once per month, like John S. said in another forum:

USB audio spec and jitter - John Swenson - Computer Audio Asylum

 

The point is that it is unlikely to affect the audio signal in only a subtle manner by these packet losses or bit flips.

 

That's what I think and you are free to correct me on any of these points.

[wgscott]

Truth is not established by social consensus nor appeal to authorities.

[Paul R]

thought there were dacs that could check for bit perfectness and haven't found errors. Does seem a bit of a strange claim, we've gone from ground plane noise to errors. 12% errors in win8 streaming, something wrong there.

 

USB streaming music is much like S/PDIF. It;s a do or die thing, with no chance to do any retries. Seems an odd way to use a digital cable to me, but I wasn't asked when they came up with the USB Audio protocol.

 

-Paul

[wgscott]

(*sigh star*) (The complex conjugate of sigh)

 

It does seem appropriate when trying to quantitate imaginary properties.

[wgscott]

Now you see that when I'm proven wrong, I will own up to it,

 

So, for those (like me) who are out of the loop, what, specifically, was proven wrong, and where is the proof?

[Paul R]

100% agreement from me George. Been there, done that. When I first joined the forum I was taken aback at how many seemingly "impossible" things people believed. Took a bunch of digging for the true truth before I even got a tooth in it, and to be perfectly honest, I am still not sure I know what is going on with some of this stuff.

 

In any case, Gordon is one of the top authorities about this stuff. John Swenson is not very far behind him. You might note that they booth present some seemingly incompatible reasons for USB cables to sound different. If you look a bit deeper into their thinking, they are really just emphasizing different aspects of the same issues. At least, I *think* they are. They may think differently.

 

Gordon does however, make the most gorgeous DACs. All of which are examples of why one would never retreat spending $10K on a DAC. Even my wee little Proton.

 

-Paul

 

Now you see that when I'm proven wrong, I will own up to it, unlike many who just sulk off the thread only to show up somewhere else spouting the same bullpuckey. This doesn't mean that I'm about to run out and buy a megabuck USB cable. I haven't heard any improvement great enough to make me do that, I'm simply not that neurotic about this stuff.

 

And this new knowledge doesn't let the cable manufacturers off the hook though for making expensive USB cables that are not only wrongly designed, but really aren't designed at all. Looks as if they just grab some 4-conductor shielded wire and solder couple of USB connectors on it and run it up the flag pole with a high price tag and see who salutes it! IOW, "They built it, not know what they built, he sold it, not knowing what he was selling and the audiophile bought it, not knowing what he was buying." What a way to run a railroad! No wonder there is so much skepticism in this hobby.

[Paul R]

Snort - that would most seriously not be you. Not by 10K rows of Apple Trees.

 

Both Gordon and John are most certainly correct in what they say, though I will admit, neither one of them may have the whole story. Even together there are probably some facts missing or not properly explained.

 

As for packet loss - go look up the USB Audio transmission protocols.

 

-Paul

 

 

(*sigh star*) (The complex conjugate of sigh)

 

That would be me.

Rankin's explanation doesn't make sense, and this is from a guy who learned about USB audio protocols an hour ago.

Let's assume that USB audio streaming has no error correction, but maybe it has CRC error detection. If the USB cable were to flip a bit, then either it would A) alter one of the audio samples, or B) drop the whole packet. (This part I am not sure) I don't see how it is possible to "lose" a single sample.

 

In the case of B), packets contain 1ms worth of audio data. To lose that would not be a "subtle veiling effect", but a serious clobbering of the signal. If the difference in cable sound were due to packet loss, it would be a steady stream of these serious clobberings.

 

In the case of A) where the DAC allows bit flips, then that would be super easy to test for - just play nothing and let the 0's get turned into 1's, and you would get a steady stream of clicks and pops. Thankfully, Kenny confirmed that this does not happen either.

 

In any case, the "data loss" thru usb is supposed to be a very very small number, like once per month, like John S. said in another forum:

USB audio spec and jitter - John Swenson - Computer Audio Asylum

 

The point is that it is unlikely to affect the audio signal in only a subtle manner by these packet losses or bit flips.

 

That's what I think and you are free to correct me on any of these points.

[new_media]

So, for those (like me) who are out of the loop, what, specifically, was proven wrong, and where is the proof?

 

Cliff's Notes Version:

 

George has previously heard differences in USB cables but chalks it up to his imagination, not believing it to be physically possible. His conversation with Gordon Rankin convinces him otherwise.

[erin]

Looks like the Belkin Gold Series is High-Speed USB Certified. I think I'll grab one of those. On sale for $7 at Amazon.

 

 

The Belkin F3U133 is certified.

 

Pro Series Hi-Speed USB 2.0 Cable

 

http://www.amazon.com/Belkin-F3U133-06-Series-Hi-Speed-Six-Feet/dp/B00000J1TX

 

 

USB.org - View Catalog Item

 

 

But that was the only cable I could see listed on the USB.org website for Belkin that was certified. Not to say that the cable you mention isnt, but its not on the USB website. I'd go for the F3U133 which looks more solid anyway. But, the shortest length is 6 ft. If you want shorter, perhaps the gold one is OK.

[beanbag]

Both Gordon and John are most certainly correct in what they say,

 

They are certainly not "both correct" because John S claims one USB transmission error per month, i.e. all the bits get to the DAC just fine.

[new_media]

The Belkin F3U133-16 is certified.

 

Pro Series Hi-Speed USB 2.0 Cable

 

Amazon.com: Belkin Pro Series USB Device Cable 16 Feet: Electronics

 

 

USB.org - View Catalog Item

 

 

But that was the only cable I could see listed on the USB.org website for Belkin that was certified. Not to say that the cable you mention isnt, but its not on the USB website. I'd go for the F3U133

 

That's the same model number, and you can see the certification logo near the bottom of the packaging there.

[Harpy]

We all talking Asynchronous Transfer?

[erin]

That's the same model number, and you can see the certification logo near the bottom of the packaging there.

 

Ok, you are correct. I didnt see that untill I checked on Amazon after reading your comment

[speavler]

Looks like the Belkin Gold Series is High-Speed USB Certified. I think I'll grab one of those. On sale for $7 at Amazon.

 

 

it's what i use!

[Harpy]

This has a data sheet with all the cable measurements, so there is no guessing:

http://media.digikey.com/pdf/Data%20Sheets/Phoenix%20Contact%20PDFs/1654853.pdf

 

Guessing it would be a non consumer grade cable at $61 a meter.

[Miska]

Since USB receivers have no error correction (this was news to me) a dropped bit gets interpolated at the DAC, and distortion increases. He says that this situation is not helped by the fact that Windows, including Win 8, generate 12% more hard errors in a digital audio bitstream than does Apple's OSX!

 

If this would be the case, you would get very noticeable crackle and pop while playing back audio. Especially with DoP. The errors cannot be clever enough to hide only in the LSB bits (and DSD doesn't have such)...

 

Curiously, I have not had a single error on files located on USB HDD's... (and for example M2Tech hiFace uses bulk mode transfers, and I believe that's the case with Mytek and exaSound too, same mode is used for HDDs)

[Allan F]

Rankin's explanation doesn't make sense, and this is from a guy who learned about USB audio protocols an hour ago.

 

Thank you. I think that is all we need to know.

[Stereolab42]

If this would be the case, you would get very noticeable crackle and pop while playing back audio. Especially with DoP. The errors cannot be clever enough to hide only in the LSB bits (and DSD doesn't have such)...

 

Curiously, I have not had a single error on files located on USB HDD's... (and for example M2Tech hiFace uses bulk mode transfers, and I believe that's the case with Mytek and exaSound too, same mode is used for HDDs)

 

With USB Mass Storage devices, the data itself is actually transmitted using the "bulk" protocol, which does have inherent checks for data integrity:

 

How to send USB bulk transfer requests (Windows Drivers)

 

"A USB bulk endpoint can transfer large amounts of data. Bulk transfers are reliable that allow hardware error detection, and involves limited number of retries in the hardware.... Bulk endpoints are optional. They are supported by a USB device that wants to transfer large amounts of data. For example, transferring files to a flash drive, data to or from a printer or a scanner... The endpoint has CRC bits to check for errors and thus provides data integrity. For CRC errors, data is retransmitted automatically."

 

It really can't be otherwise, file storage is too important to allow for even a bitflip per month to make it to disk. This is, of course, not the case with the USB "isochronous" protocol, used for audio streaming, which does not have any error correction. And thus we have the argument for audiophile USB cables.

[Miska]

This is, of course, not the case with the USB "isochronous" protocol, used for audio streaming, which does not have any error correction. And thus we have the argument for audiophile USB cables.

 

So just use one of the interfaces that use bulk mode transfers instead of isochronous ones...

 

I never liked USB Audio Class, it is over complex while at the same time having stupid design for the transfer model (1 ms packet rate with variable packet size based on async feedback).

 

Just for fun, compare source code of Linux UAC driver vs hiFace driver.

 

P.S. Or even better, use PCIexpress or Thunderbolt interfaces and gain direct busmaster DMA without wasting CPU time building special audio transfer packets.

[manisandher]

Well, it wasn't that long ago that many 'experts' (Gordon included?) were saying that USB cables could not sound different if used in async USB mode. Those of us who tested this knew it was incorrect - USB cables continued to sound different. Having tried a bunch of USB cables myself, I took the plunge (only fairly recently) and bought an expensive 'Tellurium Black Diamond' USB cable. And yes, it sounded totally different to any of the others I had (generally smoother sounding).

 

For about the same outlay as the Tellurium Black Diamond, I had my Phasure NOS1 DAC upgraded to 'a' status. The NOS1a is totally immune to effects of the USB cable and/or PC. I can verify this - the Tellurium Black Diamond now sounds identical to a $1 stock USB printer cable.

 

All the 'experts' (Rankin, Swenson, Smith, etc) are right. But only one has come up with a solution.

 

Mani.

[Miska]

For about the same outlay as the Tellurium Black Diamond, I had my Phasure NOS1 DAC upgraded to 'a' status. The NOS1a is totally immune to effects of the USB cable and/or PC. I can verify this - the Tellurium Black Diamond now sounds identical to a $1 stock USB printer cable.

 

I believe both versions go to the bulk mode transfer category. So whatever difference there was, it likely wasn't due to transfer errors. Probably more due to typical issue of computer noise leaking to the DAC.

[Snowmonkey]

Truth is not established by social consensus nor appeal to authorities.

Climate change?