New Transport Approach

I only envisioned this as a high-end application - hence, no need for portable players, etc., and an acceptance of the initial delay for the improved performance, since audiophiles are the type that are willing to go to these lengths. I'm not sure about the power requirements prohibiting portable players anyway, though - we already have portable MP3 players which are the same thing with compression, though the goal is ease of use and amount of music as opposed to better audio performance.

I'm definitely NOT a designer of digital recording and playback systems, but I've integrated lots of related but unconnected systems in my professional life. It would seem here that you already have a functional (and cheap!) design for reading a CD into RAM, and as others have noted, it's already incorporated into many high-end players to cache data in RAM and re-clock it out to the DAC. I don't want to over-trivialize it, but it seems like a little "glue" to put the two together would suffice.

I agree with everyone that in the "I want it NOW" environment we currently live, the loading delay would be unacceptable for a mass consumer version of this, even if it was cost-effective. -Kirk

It's a LOT more than a little glue. Do NOT compare time for reading a CD ROM with an audio CD. They have different data formats. Have you ever read an entire CD for the purposes of burning. That's the load time we're talking about. To do what you want you would need a new format or greatly increase the CD read time. Caching a SMALL amount is different than reading a whole disc. On one system I know of it takes 3 seconds to cache 10 seconds of audio. Extrapolate that out to 80 minutes. This isn't practical. That's why commercial digital systems don't use the CD format. It's based on technology that's 20 years old. The CD format was designed to be efficient with the state of the art data retrieval and processing in 1981. Besides most of these ram reclockers aren't as good as the better CD playback systems. Your final product could be worse. It wasn't a good engineering solution when I looked into it 10 YEARS AGO, and it still isn't.

From the Meridian website:

In the 800 Reference CD Machine, the audio data is read asynchronously in blocks using high-speed, high-integrity CD ROM drives. This data is checked for integrity, corrected and triple buffered to ensure that the audio output timing is independent of the drives for the first time.

Unfortunately Merridian has simply spewed some vague marketing terms. On more than one occasion I have found what I believed to be intentional misleading information. The worst was about "true" 24 bit machines. But not to stray here. What they've said really means nothing. Asynch vs. synch is often in how you defie it. In any case any CD / transport can claim asynch reads. Nothing to see here. The rest of that says nothing either. All CD players and transports check data for integrity, it's in the spec. Evereyone corrects the data, again in the spec. Dos it actually re-read the data if there's errors? It doesn't say. Triple buffering will prevent under-run. But again there's not enough detail to determine if they're doing something or if it's typical marketing BS.

I've been holding off buying a CD/DVD player for this very reason: I expect this read-from-memory to be about a year from now.

Meridian does do the seminal portion of this concept: its FIFO buffering through multiple processors allows multiple reads of the source, then actually pushes the music through the preamp from ROM. Perhaps, this is why they recently moved from a standard CD Transport to a computer CD mechanism.

Regardless of why; to me the when is more the matter. My recommendation is to NOT upgrade your CD/DVD player until this technology is here: it is an idea waiting to happen.