New Transport Approach

With never-ending advances in technology and tumbling prices, I wonder if any high-end audio CD player manufacturer is considering an approach such as this - populate the player with 700 megabytes of RAM and pre-read the whole CD into RAM. We know this is completely reliable (or else our beloved MS Office wouldn't work). Then the whole transport system could be shut down, eliminating any concerns about mechanical or electrical noise, and the "CD" could be played back straight from RAM through the DAC. It would seem like this would reduce or eliminate jitter completely. There would be an "initialization" time penalty, but I would think for the high-end market, that wouldn't be a huge deal. Any thoughts? -Kirk
Kirk, I like your suggestion. With the entire disc in RAM, any number of processing algorithms and could be applied and perhaps a substantial decrease in jitter when the signal is clocked out to the DAC directly. There would also be instantaneous track and search capabilites. But, alas we live in a 'I gotta have it right now' world and any buffering induced delay is not likely to be acceptable to the general population. Perhaps the audiophile community could support such a player. The huge advances in RAM the last 5 years may make this a possibilty. In the meantime, I like the multiple DAC approach of Accuphase in the DP-75V, but few of us can shell out its $11k price tag.

By the way, how long a delay are we talking about? Does anyone know how long it would take to read 700 meg to RAM from a CD-ROM on the best available disc drives?
I took a quick look and the fastest currently available standard CD-ROM reader with standard error correction is 40x. This would mean about 2 minutes of latency.

Another advantage of this approach would be to apply proprietary error correction on the read head based on allowing for retry.
Interesting idea, Kthomas. Myself and couple of guys at Audiogon had this same idea as well. We had assembled a lengthy dissertation on the benefits of this concept, and it was going to be part of "Multimedia" exploration. While it seems that audiophiles are not quite ready for multimedia, this concept could be a side effect of exploring the computer/audio integration.

For those of interest, please take a look at:
RamDac concept

The "Multimedia Site" itself is at:
Multimedia Initiative

We are getting close with this, as there are now real world products worth the consideration of audiophiles.
Great idea! Have you estimated the build of materials cost? I know of a couple of high end manufacturers that offer cd players which retail for $2500.00. Their total build of material cost is about $600.00. This example should help you calculate an approximate end retail cost of the RAM based unit, if it were offered by a high end company.
WOW! That's original. I like it. I make my living using Adobe Photoshop and greatly appreciate having the luxury of a one gig of RAM. It speeds up all functions greatly and reduces the need of constant writes to a hard drive.

Would there have to be any moving parts at all once the CD's information is stored in RAM?
Doesn't Meridian do some of this today in their new cd players? They don't load the whole disk in, but enough to read the data out of memory to eleminate the jitter issues...
You can buy 256Mb RAM SIMMs for $140 or so apiece - since you'd need three, the maximum cost would be $420, but I'm sure the wholesale bulk cost would be decidedly less. At this point, it would be a definite cost addition to the machine, non-trivial to the point that it would only be appropriate for a high-end player.

However, I would think that it would eliminate a lot of cost associated with a high-quality transport section. I don't know much about what goes into making a high-end transport high-end, but I'm sure there's significant parts cost associated with it. Since you'd be separating the reading of the disc from the playback of the music, you wouldn't need all physical separation, so maybe at the end of the day it wouldn't be that much of an uptick in parts cost. Maybe it would ultimately cost less

I think most high-end players use one form of buffering or another towards the same goals, but the advantage I see here is buffering the whole disc, since that is what allows you to shut down the transport mechanically during playback, as well as removing all real-time aspects of data retrieval off the CD. As Gunbei suggests, there would be no moving parts during playback which removes a whole raft of noise issues. I think Pls1's calculation of about 2 minutes to load a CD is about right which, while not ideal, certainly isn't out of the question considering the lengths most audiophiles are willing to go to better the sound of their system. -Kirk

This is a great idea and I am all for it!! Heck I'll even help write the software if I have time. However what about encrypted CDs and anti-piracy concerns? In the not distant future I think we can assume the RIAA will force us all to listen to encrypted CDs. There are CDs on the market today that are already watermarked. :-(

- Dan
As someone who designs Digital record and playback systems, I can tell you that this is done all the time, but for commercial applications. The problem is that for CD music, people want real-time playback. This just wouldn't be feasible for that. In addition the power required for refreshing the RAM would prohibit portable players. A better idea but one which also has drawbacks for real-time applications is to prefetch some fixed amount of data. Of course all of this is moot because even if you produce these transports, you'd have to redo the CD spec as it's designed for real-time reading and not bulk I-O.
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.
Even a cheap-o Sony Discman can buffer about 40 seconds, I think, of information into memory. I'm not an engineer, but it doesn't seem like it would be that difficult to read a whole CD into memory.
These methods are not new. They've just not been done with CDs. Two of my systems used this. One allowed you to preview CDs in the store and had tens of thousands of songs. Sampling was at 32kHz if I recall. Another system was used by a Jazz magazine to let people preview Jazz CDs over the phone. This had an even lower sampling rate and didn't sound too good. It was worse than MP3. There are different problems with CDs. You would think this would be simple but you end up taking a long time to load or you have to solve logistics problems when bit errors pile up and your buffer cache goes down. Nether one would be easy to push past marketing department.
Great idea but I will give you one word why it would never happen-- PIRACY. If you could upload the entire disk into the machines RAM, then it wouldn't be too hard for some criminal mind to figure out how to tap into the memory to make excellent copies of the disk. All that said, maybe they could develop some type of manner of preventing this but look how successful they have been preventing piracy to date i.e. almost not at all. It is this fear of piracy that would prevent your excellent audiophile idea from becoming a reality at least in the near term

Isnt this similar to what you are talking about the Knekt Kivor System  by LINN.
This would be one of the easiest things to pirate, and maybe that's why the CD mechanism was set up that way 20 years ago. I'm sure you can already do this now though with regular CDs. When the music industry decided on digital, they probably figured that since it costs a small fraction of what it costs to produce LPs, they would make enough to pay for piracy.
Just a thought...

You really would not need 700 MB ram.

I suggest using 128MB or 256MB of ram, and having a 14+ GB removeable hard drive in the unit.

This way an entire CD or DVD could be read into the hard drive. Data would flow from the hard drive to the RAM. From the RAM to the processor/DAC. Heck you caould have a huge 60GB HD in the unit with all of your favorite CD's scanned in.

Anyway, just a thought.
There is a company named Lansonic who is doing just what you describe - a disk-based audio component. It's got an ethernet interface on the back-end, audio-component interface (digital and analog) to feed a stereo system. It looks just like a server on the network, controllable by any other computer on the network. I haven't heard it, but would think reading the CD off the HD would eliminate the jitter issues, etc.

My big concern with purchasing one of these is the controlling software - usually hardware companies who need software write software that isn't up to par. It's not their specialty and it shows. If they ever prove to have the kinks worked out, it looks like a really flexible component. -Kirk