Chord Electronics - Blu Mk. 2 - The Official Thread
Jun 29, 2017 at 8:54 AM Post #842 of 4,904
OK, so what do you use to rip your CDs? :wink:

A modest HP laptop running dBpoweramp for ripping. dBpoweramp does a superb job of tag retrieval - it checks up to four online databases and gives you a choice of tags, which of course you can override if you prefer. This is especially useful for classical music. It also rips quickly, and checks the accuracy of the rip against an online database of known rips - Accuraterip - so if yours gets a match you can be extremely confident you have an accurate rip. You get a choice of ripping formats, FLAC, WAV, ALAC etc, and a choice of compression levels for FLAC, and it shows cds with a reemphasis tag and gives you control over the folder structure of your rips. It is very unlikely Chord, with all due respect, could do anywhere near as good a job. Oh, and btw, you can use it to play cds from the disc drive in your laptop out to the USB port, so you could connect a laptop up to your Blu2 and play your cds. Which should give a result absolutely indiscriminable from the drive in the Blu2!

For playback I use a little fanless touchscreen Acer with an SSD running JRiver straight into my DAVE. Remote controllable from my iPad or iPhone with the superb JRemote. I also stream from the splendid Qobuz, a classical music lovers dream. If I ever get round to buying a little cd drive for my Acer I could junk ripping on my old HP - but I hardly ever rip nowadays so I'm not bothered.
 
Last edited:
Jun 29, 2017 at 9:22 AM Post #844 of 4,904
Guys, there is a multi billion dollar industry that reliably transfers data across USB. It's not magic. Asynchronous USB playback from any PC(or raspberry) delivers the same bits as a $10k CD transport. The buffering, the logic, the timing ....it's all going to guarantee the train of data is bit perfect. The differenceis you hear are 100% due to the analog RF noise making its way to the DAC section. Which we end up hearing in some fashion. So different playback software or different motherboards or ram disk or whatever does not change the fact that the bits always are perfect.
It's the analog noise that makes the difference. Any changes made to anything will alter the 'cloud' of invisible fuzz attaching itself to any conductor and perturbs the small signals near the DAC.
 
Jun 29, 2017 at 6:49 PM Post #845 of 4,904
Guys, there is a multi billion dollar industry that reliably transfers data across USB. It's not magic. Asynchronous USB playback from any PC(or raspberry) delivers the same bits as a $10k CD transport. The buffering, the logic, the timing ....it's all going to guarantee the train of data is bit perfect. The differenceis you hear are 100% due to the analog RF noise making its way to the DAC section. Which we end up hearing in some fashion. So different playback software or different motherboards or ram disk or whatever does not change the fact that the bits always are perfect.
It's the analog noise that makes the difference. Any changes made to anything will alter the 'cloud' of invisible fuzz attaching itself to any conductor and perturbs the small signals near the DAC.

Yes. The "analogue" transmission part of digital is the problem with digital.
 
Jun 30, 2017 at 2:15 AM Post #847 of 4,904
A modest HP laptop running dBpoweramp for ripping. dBpoweramp does a superb job of tag retrieval - it checks up to four online databases and gives you a choice of tags, which of course you can override if you prefer. This is especially useful for classical music. It also rips quickly, and checks the accuracy of the rip against an online database of known rips - Accuraterip - so if yours gets a match you can be extremely confident you have an accurate rip. You get a choice of ripping formats, FLAC, WAV, ALAC etc, and a choice of compression levels for FLAC, and it shows cds with a reemphasis tag and gives you control over the folder structure of your rips. It is very unlikely Chord, with all due respect, could do anywhere near as good a job. Oh, and btw, you can use it to play cds from the disc drive in your laptop out to the USB port, so you could connect a laptop up to your Blu2 and play your cds. Which should give a result absolutely indiscriminable from the drive in the Blu2!

For playback I use a little fanless touchscreen Acer with an SSD running JRiver straight into my DAVE. Remote controllable from my iPad or iPhone with the superb JRemote. I also stream from the splendid Qobuz, a classical music lovers dream. If I ever get round to buying a little cd drive for my Acer I could junk ripping on my old HP - but I hardly ever rip nowadays so I'm not bothered.

Interesting and thank you for taking the time to reply but I last had a computer with a CD drive about 4 years ago. I am also 100% Mac in my home and office (my office is in my home) but I guess some of the software you mention may be available for Macs.
Anyway, I have Blu2 so I don't need to rip for the moment. :wink:

The question of course is whether you are right in your suggestion that playing CDs on a laptop direct into the Dave should be the same as using the CD output from Blu2. The digital file might be the same but it would seem that RF and other interference is widely thought to be important. The same issue might be present with your Acer which you use to playback your ripped files. It may therefore be that I get a better result playing my CD on my Blu2 than you do playing your ripped files with your system due to less interference.:wink:
 
Jun 30, 2017 at 3:54 AM Post #848 of 4,904
Guys, there is a multi billion dollar industry that reliably transfers data across USB. It's not magic. Asynchronous USB playback from any PC(or raspberry) delivers the same bits as a $10k CD transport. The buffering, the logic, the timing ....it's all going to guarantee the train of data is bit perfect. The differenceis you hear are 100% due to the analog RF noise making its way to the DAC section. Which we end up hearing in some fashion. So different playback software or different motherboards or ram disk or whatever does not change the fact that the bits always are perfect.
It's the analog noise that makes the difference. Any changes made to anything will alter the 'cloud' of invisible fuzz attaching itself to any conductor and perturbs the small signals near the DAC.

This is not correct. Bits are only perfect when there is error correction.

This does not happen with USB audio. Please do some research and you will see this is the case.

NO error correction for USB audio.

Suggest you google some articles by Gordon Rankin on USB audio transmission, which is completely different to send a file for printing through USB

I repeat again, USB audio has NO error correction, and a Vertere DFI USB cable makes my Dave more musical than a cheap USB 2.0 certified cable. Digital audio transmission is still analogue, and analogue cables poorly made will not deliver bits at that speed and at that quantity properly to Dave, or Mojo for that matter.

I can easily hear the impact of a vertere USB cable on my Chord Mojo. I can hear it, and all I can say to the cable deniers and unbelievers, is that there have always been cable deniers, and will always be. The cable believers buy good quality cables, educate themselves, and get more performance from their expensive and high quality Chord Dacs.

Now if one doesn't have the amplifier, speaker or ears to hear the difference, that's another story.
 
Last edited:
Jun 30, 2017 at 4:04 AM Post #849 of 4,904
a copy paste of Gordon Rankin interview who invented USB audio.

http://www.digitalaudioreview.net/2016/05/gordon-rankin-on-why-usb-audio-quality-varies/



While all of these interfaces (Firewire, SPDIF, USB, Ethernet, Thunderbolt so forth) have pecifications. The % differential from one supplier to another in electrical, cabling, device and host seem to vary quite a bit.“


“All data moving between a host computer and a device over USB is done electrically. There are different speeds and different protocols that determine how a device and the host communicate.”

“Any interface between two points cannot be totally error free. If you use a hard drive over USB, Ethernet or Firewire there are transmission errors. That means the transmitting device is told to resend the packet that has the error in it. Most of the time this is one bit in a packet size of length X.”

“Remember, the carrier is modulated on the data so the larger X, the bigger chance of errors. Also the faster the interface the more chance that there will be an error.”

“The three main USB transmission protocols are Bulk, Interrupt and Isosynchronous. Bulk (used for data transfer to a hard drive) and Interrupt are error correcting. Isosynchronous (used for audio) is not.”

“Bulk and Interrupt are immediately NAK (negative acknowledgement). The receiver is designed to detect a bad packet immediately and the packet is resent.”



“For USB audio, the receiving device is basically translating a serial stream of data with a clock interwoven throughout. At the end of the packet sits some sort of block check. If the block check does not match the data then that packet is flagged as an error.”

“With Isosynchronous USB transmission, packets are sent without any error correction / resending. But guess what? This is the USB protocol used for audio frames. The bad news is they are not error free. The good news is these Isosynchronous frames are afforded the highest priority in the system.”

“A couple of years ago, I bought an expensive Tektronix USB setup. I have had protocol analyzers since designing my first USB DACS some twelve years ago. The Tektronix is useful because it allows me to see errors better both in electrical and data packets.”

“The big thing that many people don’t realize is that not all USB ports are created equal. Not all USB cables are created equal and it’s the same for devices and even operating systems. Since getting the Tektronix I have tested probably thirty different USB cables on the fifteen computers in my lab. These computers run a variety of operating systems and the Tektronix results vary between computers even when the cable remains the same. Lets just say it’s not as pretty as I thought it would be.”

“Just a couple of things to think about in regards to USB ports. First, look to see what else is located on that tree. Each USB port can handle 127 devices. Sometimes there are additional ports hidden (inside your computer) and there are internal devices sitting on those ports – this could be the same tree that is hosting your USB DAC”.



“You can see in the lower tree, USB Hi-Speed Bus, Hub*, Hub, Apple Internal Keyboard/Trackpad, BRCM20702 Hub, Bluetooth USB Controller. On some computers, Hub* will actually be a external port and if you plugged your DAC in there you’re sharing it with all the devices below it.”

“On the PC, you can use this helpful application from Thesycon.”

“Alternatively, if you know your way around Device Manager you can go through that to find the USB tree. Although neither of these really give you a good indication of which port is on which internal hub, if you ARE able to place your DAC on a direct port you will be best served.”

“Speed plays an important part in all of this too. You may have heard the terms UAC1 and UAC2 – these are USB Audio Class protocols. UAC1 was designed for Full Speed device and host interaction. A data packet is sent every 1ms. In that packet are up to 1023 frames.”

“In high speed or UAC2 those 1024 frames each contain eight micro frames. Therefore, the amount of data we can send over UAC2 is basically eight times greater than that of UAC1. But with more data at faster speeds comes more errors and system configuration becomes harder. I almost never see an error on a UAC1 device, on a UAC2 device I can pretty much count on errors in both directions.”



“For optimum results, at least in theory, it’s best not to use a USB hard drive for your library with a USB DAC connected to the same host device. Think of it this way: your music software is reading from the hard drive in a synchronous manner and then writing to the DAC in that same synchronous manner and, as the DAC has priority, the music software might fault when reading the disk – this can lead to really bad sound.”

“Also, it’s probably best not to put the library on the system disk – because system stuff has really high priority over music playback software and again the music software can fault and bad sound will result. When a music app faults it becomes NON-bit true. One workaround for this is to choose a music app with memory buffering but in my experience even that’s not guaranteed to be 100%.”

“A good example of this is when we transitioned from Full Speed USB to High Speed USB DACs. A lot of the really expensive USB cables from audio companies failed miserably; I doubt many of these cables were even tested for High Speed compliance.”

“To summarise: the problem with USB Audio is that Isosynchronous USB frames are not error correcting. Therefore the sonic outcome of any USB system is dependent on the host to device differential.”

“Twelve years ago, I pretty much thought as many people do today: that USB was the answer to our S/PDIF quandaries. In some ways it is a good deal better. We have Asynchronous Isosynchronous so the device and host know about sample rates, bit rates, clocking options and a host of other things. But cables make a difference, computer brand and quality make a difference and even the device makes a difference.”

“I will try and capture some data errors on the Tektronix. The problem is that it does not accumulate errors. It also does not stop on errors. I have to actually push a button capture it and then pipe that to my screen.”



“What this is showing is the event table or the decoding of the USB Bus as seen by the Tektronix scope. We are using a Tektronix Differential Probe and their USB Analysis package. I made a little Male/Female HS USB board and that is plugged into a MacBook Air. I am using the Faber Acoustics Signal Scope Pro to send a 1KHz Sine wave to a Wavelength Crimson DAC @ 176.4K sampling rate. This is a program I use to test basic DACs of all kinds. This is also a pretty basic setup compared to audio transmission.”

“As per the above, a packet sent by the host to the Crimson has a CRC16 error. You can see that in the error column.”

TL;DR? What we have here is an explanation with screenshot proof that USB audio transmission isn’t bit true – enough evidence to reject any null hypothesis that assumes 1) all bits sent will all arrive intact and 2) re-transmission sorts out any detected errors. The Isosynchronous protocol used for audio data checks for errors but does not do any error correction (by way of retransmission).

Bringing it all back home, the iFi iPurifier 2 likely improves the sound of the Sonicorbiter SE because it minimises transmission errors by making lighter work for the Mytek Brooklyn’s USB receiver chip.

Furthermore, with lower noise on the line, the USB receiver chip no longer needs to kick into a higher, noise-inducing operational gear to ensure that it reads the incoming data correctly.

In other words, USB audio isn’t simply a matter of bits leaving the host PC/streamer and arriving AOK at the DAC. The quality of that which sits in-between matters.
 
Jun 30, 2017 at 4:29 AM Post #850 of 4,904
The CD mech in the Blu2 is a bit like putting a haybox in the trunk of a Ferrari. Sure, some people still have horses, and sure some people want to pull a Ferrari with one .. but most people ... :wink:

In case you haven’t got it Blu Mk II is a “second generation FPGA CD transport” that has an up sampler built in to it. Please read again, CD transport designed for upsample CD (or BNC/S/PDIF input) to 705.4kHz. The CD mechanic fill an essential purpose for those that like to spin CDs. USB was incorporated later on so it can also be used to stream from a NAS or computer. Absolutely no need to critic the use of a medium many has big collection of and that is still sold and manufactured. Your desire to get an M-scaler without a CD transport is noted and understood. But just because you doesn’t want a CD transport should not mean constant thrashing and mocking of those who does.
 
Jun 30, 2017 at 4:31 AM Post #851 of 4,904
Chord's Windows driver re-transmits faulty data - so for Windows it is bit perfect.
Secondly - if it were not bit perfect, DSD with DoP would fail big time, with easily audible consequences.
Thirdly - I have checked the M scaler with tests that lasts for hours. One faulty bit would be measurable - and it did not fail, even over a whole day (I was testing for internal overloads so I needed to run it for a whole day - no overloads, no bit errors).

Of course we are talking about USB here. CD's themselves may not be bit perfect as CD was not designed to be bit perfect.
 
Last edited:
Jun 30, 2017 at 6:35 AM Post #852 of 4,904
Interesting and thank you for taking the time to reply but I last had a computer with a CD drive about 4 years ago. I am also 100% Mac in my home and office (my office is in my home) but I guess some of the software you mention may be available for Macs.
Anyway, I have Blu2 so I don't need to rip for the moment. :wink:

The question of course is whether you are right in your suggestion that playing CDs on a laptop direct into the Dave should be the same as using the CD output from Blu2. The digital file might be the same but it would seem that RF and other interference is widely thought to be important. The same issue might be present with your Acer which you use to playback your ripped files. It may therefore be that I get a better result playing my CD on my Blu2 than you do playing your ripped files with your system due to less interference.:wink:

Yep, over the last few years I have switched to iMacs, iPads and iPhones and am very pleased. But I got into ripping years ago, so my ripped music is still on Windows machines which, it has to be said, do an excellent job. Also it is the case that my preferred playback software, JRiver, and ripping software, dBpoweramp were only available on Windows years ago. But nowadays JRiver is available for Macs, and does a great job of ripping, organising your collection and playing back (though it still has a bit of a Windows feel which can irritate some Mac fanatics).dBpoweramp too has an OSX variant. But Mac folks seem to like Audirvana + for playback, and XLD for ripping. Im not fussed, and happy enough not to bother changing.

If you have a rainy afternoon you could do worse than buy an external CD drive for one of your Macs, rip a few of your CDs and experiment with playing them back through your Blu2. iTunes, as long as you set it to lossless ripping and wind the volume control to maximum will do a good enough job as an experiment; JRiver, Audirvana and dBpoweramp all have free trials if you want to checkout arguably better alternatives. And then with a Mac connected to your Blu2 you could download some hi res stuff to listen to - hyperion and linn both have superb classical download sites.

Sure my Acer might produce some RF, but then again Rob has done all sorts of galvanic isolation and RF suppression voodoo to the USB input of the DAVE, so it hopefully doesn't get through, and then again the CD logic inside the Blu2 might do the same, or produce different digital hobgoblins, and the power supply, servos etc might have an impact. Plus, as Rob has said above, CDs themselves may not be bit perfect .. You are in a great position to make a straight comparison between a CD and a rip of that CD. Would be genuinely interested in your findings.
 
Last edited:
Jun 30, 2017 at 7:09 AM Post #853 of 4,904
Chord's Windows driver re-transmits faulty data - so for Windows it is bit perfect.
Secondly - if it were not bit perfect, DSD with DoP would fail big time, with easily audible consequences.
Thirdly - I have checked the M scaler with tests that lasts for hours. One faulty bit would be measurable - and it did not fail, even over a whole day (I was testing for internal overloads so I needed to run it for a whole day - no overloads, no bit errors).

Of course we are talking about USB here. CD's themselves may not be bit perfect as CD was not designed to be bit perfect.


Dear Rob are you talking about the CHORD ASIO driver.

Is there any documentation on the error correction, as I cannot find any.

With J river and Chord ASIO driver, I can hear the difference between a Vertere USB cable (175 GBP) and a bog standard one that costs 10 GBP.

Not sure why, or how, but if you are ever in Dubai, it would be fun to play a demo for you and see what you think. Maybe it's all in my head, but then my friends can easily hear the difference too.

I know you told me to not spend too much money on USB cables, but Vertere make one that costs 1250 GBP, and I am tempted by it, as their entry level DFI is already very good....
 
Last edited:
Jun 30, 2017 at 7:20 AM Post #854 of 4,904
“The three main USB transmission protocols are Bulk, Interrupt and Isosynchronous. Bulk (used for data transfer to a hard drive) and Interrupt are error correcting. Isosynchronous (used for audio) is not.”

“Bulk and Interrupt are immediately NAK (negative acknowledgement). The receiver is designed to detect a bad packet immediately and the packet is resent.”

“For USB audio, the receiving device is basically translating a serial stream of data with a clock interwoven throughout. At the end of the packet sits some sort of block check. If the block check does not match the data then that packet is flagged as an error.”

“With Isosynchronous USB transmission, packets are sent without any error correction / resending. But guess what? This is the USB protocol used for audio frames. The bad news is they are not error free. The good news is these Isosynchronous frames are afforded the highest priority in the system.”

Dear Rob, are you saying the Chord Asio driver is able to resend packets?


 
Jun 30, 2017 at 8:17 AM Post #855 of 4,904
“The three main USB transmission protocols are Bulk, Interrupt and Isosynchronous. Bulk (used for data transfer to a hard drive) and Interrupt are error correcting. Isosynchronous (used for audio) is not.”

“Bulk and Interrupt are immediately NAK (negative acknowledgement). The receiver is designed to detect a bad packet immediately and the packet is resent.”

“For USB audio, the receiving device is basically translating a serial stream of data with a clock interwoven throughout. At the end of the packet sits some sort of block check. If the block check does not match the data then that packet is flagged as an error.”

“With Isosynchronous USB transmission, packets are sent without any error correction / resending. But guess what? This is the USB protocol used for audio frames. The bad news is they are not error free. The good news is these Isosynchronous frames are afforded the highest priority in the system.”

Dear Rob, are you saying the Chord Asio driver is able to resend packets?

I was told by Chord that the Windows driver re-sent error data; I presume this must apply to ASIO as well. Certainly ASIO (on Mojo) sounds a little better than WASAPI, and my thinking on this is simply processor overhead. The APx555 uses the ASIO driver, and I would immediately see poor measurements if it was not bit perfect - and I have never seen any at all. So all the available evidence is that conclusively the USB data is completely bit perfect. Indeed, the data rate for USB audio is pathetically slow compared to 480 Mbs that USB 2 is capable of.

My experience is I have failed to hear any consistent difference with USB cables at all with Mojo/Hugo2/Dave/Blu2. But that does not mean you are incorrect in hearing a change; most audio amplifiers are not designed to prevent RF noise from upsetting the sound quality (no other designers talk about RF noise and sound quality, let alone noise floor modulation which is the mechanism for it being audible), so it's not inconceivable that the RF characteristics of the USB cable is upsetting your power amp. I recall that before I latched onto the importance of RF noise, pre and power amps were incredibly sensitive to RF sources in the same room; indeed, in my university flat, my system was sensitive to the fluorescent lights in the kitchen; and once I designed amplifiers with this problem in mind then it simply no longer mattered.

Remember that in any case YMWV. Different systems, different sensitivities....
 

Users who are viewing this thread

Back
Top