Music from hard drive better than CD?

Using error correction when extracting information from a CD is just an extra level of validation that you're getting a bit-accurate copy of the media. It takes longer, but worth it when you're looking for the best possible reproduction. You can think of it as a second scan of every ring, and you're right in thinking it has nothing to do with playback.

Apple Lossless Compression is bit-accurate and just involves a storage compression routine. Compression has gotten a bad rap from the audiophile community (sometimes for good reason) because of the inherent loss in mp3 and other compression schemes. When ALC tracks are played back, you get the same 16-bit 44.1 KHz signal that would be coming from a cd or wav/aiff file. Just like using winzip or stuffit to compress a Word document then uncompressing it later.

Ah, thank you Ghunter. That explains the extra time it takes. So it's essentially double-checking that the data read on the first scan was correct, and if not, I assume it does a third and possibly a fourth till it gets some consistancy? Other than the possibility of actually missing some data, or adding some that isn't there, such an error as error-correction seeks to correct would not be an error that effects overall PRAT, as Nickway seems to be experiencing a problem with..true? In other words, the error-correction is not going to help with a frequency mismatch - wouldn't that be a function of the interface/communication between hard drive and card (in this case the Mbox), and DAC...or, alternatively, harddrive and DAC depending upon your set up? If the harddrive feeds the data at something less than 44.1KHz are the components downstream able to correct for that using a unidirectional connection such as S/PDIF, or Toslink? Or am I mistaken? Is there information sent with the data/signal, that tells the receiving end at what frequency it is sent? Sorry if my questions are pretty fundamental, but I'm just trying to understand all this stuff better.

Marco

Marco, for someone who's learning you've got a pretty good grasp of this!

What you're talking about here is also known as jitter. Here are a few articles that explain what's going on:

http://www.soundonsound.com/sos/Apr03/articles/digitalclocking.asp

http://www.benchmarkmedia.com/appnotes-d/jittercu.html

Thank you Ghunter. Both excellent links. The first one did help me understand it better and is well-written...the Benchmark data was a bit more 'academic content-rich' and I need to read it again with more time. I guess I've got the basics down, but mine is far from an authorative knowledge on the subject. That simple illustration of amplitude error caused by jitter in the first link says a lot. I wasn't getting that clocking information is sent with the signal via S/PDIF. I didn't see Toslink mentioned in my quick read of the first link, though they do mention S/PDIF optical...are they one and the same? Here's a passage from that first link:

Remember that you can synchronise clocks in digital equipment with more than just the classic BNC cable. Both AES-EBU and S/PDIF (coax and optical) signals carry clock information within the audio data stream, for example, and so recorders can often be synchronised using their input signals, rather than having to use dedicated word-clock cables.

My understanding is that Toslink is the least desirable of the ways to transfer digital information...would the clocking have something to do with that? If not, what is it about Toslink that is frowned upon? Seems like it would be favored being so inexpensive. Or am I just wrong there?

Marco

Are there any good hard disk dedicated players? Rather not use a PC or Apple w/ full screen. What about the new McIntosh player? Any body tried it yet?