New Transport Approach

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.

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.

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.

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.

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.