Halo by Parasound CD-1 (seedee done differently)

[Wmcmanus]

Although at $5k it's a pricey bugger, it's still not a complete outrage relative to a lot of the top shelf stuff. But what's interesting is the approach. Seems new and completely different to me, but maybe that's just what they want me to think.

I'd be interested in knowing what the technically inclined among us (i.e., those who know their ass from a hole in the ground when it comes to these things) might think...

http://www.parasound.com/news.php

[grawk]

So as I see it, it's basically ripping the cd using a reliable ripper, then playing it back with linux. But you still need the disc every time you play it. I guess it depends on the quality of the DAC they're using as to whether it's worthwhile, given that you can do similar things with computers and get to pick your own dac etc.

[skullguise]

Yeah, sounds a bit like what Chord did with their buffering/re-processing of the digital signal with one of their DAC's.

The more interesting potential to me is the Holm Acoustics SW, and what that does.....that sounds like a big part of the selling point for this.

[blessingx]

If you compare to PWT (and its new price) it seems to take the memory player idea further. Not sure the PWT was much of a seller though.

And theres been rumors of a 5K DAC coming soon from Parasound. Wonder if this is it?

Still would be fun to A/B against Paras new bowling alley-line CDP: http://www.parasound.com/ParasoundZ/zcd.php

[Torpedo]

The concept reminds me of the Memory Player at a more affordable point (if 5000 bucks may be considered affordable), without the storage capabilities, but including a DAC. Interesting, but not sure it's going to better a MBP with XLD for ripping, using Amarra for playback, and connected to a good USB DAC. Looks nice though

[Jon L]

Using CD Rom with large buffer for spinning CD's is not exactly novel, and all these types of CDP's lack THE major advantage of music server/computers IMO, i.e. abiliby to have instant access to all of your music collection without having to find/place/spin CD's!

Currently I have all my music on an external e-SATA drive->audio PC->Asynch Firewire->Firewire DAC with dedicated precision clock next to DAC chip.

Edited February 20, 2012 by Jon L

[Milosz]

I don't see the advantage to this scheme. Any CD player will use the Reed-Solomon error correction that's built into the Redbook standard for most errors, and this mathematically produces exactly the correct bits that are lost due to the error. This happens on-the-fly; all CD players have some kind of buffer where data is placed for some short period of time as the disc is read and the algorithm is run. More serious data read errors that cannot be overcome by error correction have some cut-and-paste replacement type thing that happens, basically if a block of data is lost that was too large to be recovered by the Reed-Solomon code, then the last good data is plugged in to the hole- this is "ERROR CONCEALMENT." And if an even larger block of data is missing, the player will mute. Beyond that, the disc is rejected. Obviously this "repeat" method of covering up errors is not a good thing to have going on with any regularity, it can be seen as a form of distortion- a fairly serious one. HOWEVER, in my experience, a CD in decent condition never reaches this point. I had an NAD CD player that had an indicator LED that showed when errors uncorrectable by Reed-Solomon recovery occurred- and unless a CD was in bad shape, the LED never lit.

Just to be clear, the Redbook standard for a CD provides that the amount of bits burned to the disc is essentially DOUBLED, the extra data being the Reed-Solomon checksum bits. So between the audio data and the additional error correction checksums, there is enough data to recreate the missing bytes with ZERO errors in the output, as long as the bit-error-rate is below some reasonable level. What's stored on the CD is just a series of numbers, and using math you can solve for missing pieces. See http://en.wikipedia....3Solomon_coding

Essentially it works like this:

Let's say we have three bytes from the data stream, in sequence as they are recorded on the CD

8456

8448

8439

For our error correction code, we will use the DIFFERENCE between each successive sample - thus:

DATA | Error Correction Code (calculated at the time the audio recording is being prepared to manufacture the CD)

8456

(8448 - 8456 =) -8

8448

(8439 - 8448=) -9

8439

So, we have three data samples from digitized audio, and two code numbers which are stored along with the audio data on the disk.

Let's assume the middle audio sample, 8448, is lost- can't be read from the CD.

DATA | Error Correction Code (calculated at the time the audio recording is being prepared to manufacture the CD)

8456

(8448 - 8456 =) -8

-missing!-

(8439 - 8448=) -9

8439

Well from the remaining known samples and the error correction code we do the following math

EXISTING SAMPLE (8439) + ERROR CORRECTION CODE (-9) = MISSING DATA = 8448

[This is an example only, a simplified version of what goes on with CD error correction]

So, you can see that the Solomon-Reed code result is ZERO data loss when the disc is being read, unless the number of errors is too great for the error correction setup. These minor read errors result in NO LOSS of audio, as the error correction scheme is mathematically perfect.

So, since the existing error correction built into a CD provides perfect recreation of the data originally recorded onto the CD unless the error rate climbs too high, and in real life the error rate never gets that high unless the CD is defective, has been used by someone as a coaster for his beer mug, or is otherwise generally pretty scuffed up, I don't really see the value of going through all of this extra trouble and expense.

And, if you are really concerned about playing back a CD with zero errors, you can always use your computer to rip the CD to Wav or other lossless format and check the resulting rip against the AccurateRip database. (Many CD-ripping programs will do this for you) If you rip a CD and the AccurateRip check says it error-free, then you have an absolutely, bit-for-bit identical, error free copy of the CD on your PC, which is EXACTLY the same data as released by the folks who made the CD. This is even MORE likely to be 100% perfectly bit-accurate than the "double read" idea in this Halo player, and you can do it with your existing PC and DAC, without spending the $5000 for the player.

See http://www.accuraterip.com/

Having said all this, I do want to go on to say that the Parasound Halo gear is generally really fine equipment, and in addition to this redundant read method for playback, I'm sure this player would have a very well implemented DAC and very clean sounding analog sections, good power supplies, beefy construction and so on.

Edited February 21, 2012 by Milosz

[Craig Sawyers]

That is a very good description. And of course the thing that is often missed is that what comes off the disc read system is very much an analog signal. It looks something like a noisy and several nanosecond jittery sine wave. The jitter comes from the focus and tracking servos work to keep the laser head in the right place taking account of disc eccentricity and out of flatness - and that is never perfect, hence the jitter. It is only after quite a lot of embedded processing in the standard chipsets that come with the mechanism that a digital signal we'd all recognise emerges.

Reading several times and summing the results only works if this is done in the analog signal domain - so at raw RF level. If you sum N times, the signal to noise and jitter are reduced by root(N) - so summing four times gives a factor of two. I guess it would be possible to flash digitise at maybe 8 bits at a GHz or so, and then multiple read and sum on the fly, but it seems very hard work, and I'm pretty sure that Parasound aren't doing that.

It is only after the analog RF data is processed and reclocked that jitter comes out of the equation. I'm not sure what Parasound's jitter spec actually is - psuedo peak to peak, or rms. I know that the jitter in my reclocked digital output (this is an ancient CDM1Mk2 mechanism and 1990 vintage chipset) is 100ps p-p, so around 17ps rms. That is measured on a Tektronix 7000-series sampling setup (7S11/S4 head and 7T11 timebase, 14GHz BW, 10ps p-p trigger jitter).

Incidentally, the CD mechanism that they are using seems to be a car (automotive) unit.