DIY CD drive based on a computer CDROM

Jump to Latest
#603
A slightly different slant...

When I saw this thread title I expected to see a somewhat different approach (though I didn't dig back through all 60-odd pages of backlog, so maybe I just missed...). Something like this:

It's speculated that one of the biggest problems that make CD transports sound different (and if two of anything sound different, at least one is committing an error) is the way basic audio playback more or less syncs the physical rotation of the disk to the nominal data rate that's needed to feed the converter. Sure, there's some bufferring between, but at best it makes the errors in that synchronization not cause a dropout - the servo still has to constantly adjust the rotational speed to try to keep the data arriving at the nominal rate. At best this produces more noise as the motor is driven now more, now less.

So if you're going to use an inexpensive data CD drive, why not put a good-sized computer in there? One with enough RAM to make both the coding and the buffering more interesting? Surely the drive-induced jitter can be decoupled if, instead of trying to keep it running at just the right speed it can just dump into a larger buffer (how many new CDs can you buy for the cost of enough RAM to buffer an entire CD these days? not many!) Then the playback only has to goose the much more accomodating CPU to shovel a chunk of data into the (smaller, dedicated) buffer in... ah yes, the output side of things.

The obvious prototype would use a standard sound card, but I have to confess that I've not paid attention to computer sound quality. I have good speakers, but eight foot tall full range panels don't fit alongside the monitor very well, so they're in the listening room, and the computer has a couple of cheap little squawkers (actually, they're quite tolerable for such small, inexpensive speakers, but how good do they need to be to play MP3s?) So I'm not sure what's needed here. Are there mass-market sounds cards that are good enough to use for audiophile-class output? How about if we plan on using a separate DAC - are there issues with the usual run of digital outputs on these things?

Surely someone's wandered off in this direction before...
 
#604
Re: A slightly different slant...

maney said:

So if you're going to use an inexpensive data CD drive, why not put a good-sized computer in there?
Click to expand...

You appear to be lost. There is a whole gamut of threads for the computer weenie.Threads on DRC, threads on using the PC as a crossover, threads attempting to make a PCI card but that may be in jest, threads on a dedicated linux based IDE i/f.... Wandered off? Stampeded more like.
 
#605
Back on topic?

At risk of reviving this thread.... I'm going to try and roughly summarize the 60 odd pages, and attempt to get this thread back on the original topic.

In the beginning, the design goal was to create an excellent sounding transport using a computer CD-ROM drive. The Meridian 588 was brought up as an example target goal.

Along the way, there was a significant discussion split between the control circuitry and sound recovery circuitry. This further devolved into a discussion about the relative merits of the digital line provided by some cd-rom drives. Kuei joined in somewhere in this fray and correctly pointed out the significant differences between DAE mode and "CD replay" mode.

To paraphrase that difference: Most CD ripping programs use DAE mode which allows for significant error correction and retry attempts in order to ensure that the correct bits are extracted. In CD replay mode, the player will stream the data with minimal error correction, if any at all. With modern drives and pristine CD's, there is no practical difference between these modes. With scratched discs, or other less pristine media, the difference is significant, as the digital steam reproduced in replay mode may not be bit accurate.

This significant data then caused another split in the discussion in terms of data recovery and the limitations of using uC/uP, and the timing involved in data extraction via DAE mode, and the buffering involved. This discussion led to using an off the shelf PC instead of just the drive.

I think we've moved way off the original topic at this point. So, to resurrect from one of the original design goals from an earlier post:
-------------------------------------------
Phase 0: Basic Operation
Block Diagram
Power Supply (separate control, cd-rom driver, cd-rom control)
Test the basic operation using cd buttons (if it has them) and digital/audio out.
A performance evaluation should be done so that we have a baseline for the more advanced phases.

Phase 1:
MCU and new buttons replaces stock buttons

Phase 2:
LCD

Phase 3:
IDE digital out
Added LCD functionality (Index etc)
Compare performance

Phase 4:
Buffered IDE digital out
DAE
compare performance

Phase 5:
Enhanced Clock with external output
compare performace

Phase 6:
MP3 and other formats
-------------------------------------------------

Personally, I believe phase 3 IDE digital out and Phase 4 Buffered IDE out, DAE mode should be the same thing.

I also still think this is an excellent project, however quite complex, and we may be at a stage where it no longer makes sense as a DIY effort. But, I'd like to at least explore it from the perspective of current chips and technology, as this was originated in 2003, and there have been significant changes since then.

I would also like to point to the Creek CD 50 mkII as another example target. Whereas Meridian is famous for their DSP processing, which is probably heavily used in the 588, I don't believe the Creek unit does. I believe the Creek player is exactly what we were hoping to build when this thread first kicked off. Does this project still make sense? Can we build something similar to the Creek unit for significantly less, while reusing old CD-ROM drives we have laying around? Can we use a uC/uP and DAE mode with true bit accurate data recovery and buffer it correctly to feed and external DAC? Will the extra complexity of DAE mode and the associated error correction capability result in improved sound?

If I'm totally off base, I apologize for misinterpretting this thread. I've just spent several hours reading all 60 odd pages, though I admit I rushed through most of the later pages, because it seems to have drifted away from the initial intent. I'll just go start a new thread for a DIY project to see if we can build a Creek like player on the cheap.

Thanks!
 
#606
Tsai, that Creek player seems to be a rather minimal version of what I was thinking of. The idea of taking a random CD-ROM drive and adding just enough logic to translate button presses to commands to it seems pretty pointless. The audio out, whether form the internal DAC (cheap yuck!) or its almost-raw digital stream of unknown, probably mediocre stability in the time domain, could be expected to appeal to those who think MP3s sound great.

What the Creek does that I noticed is decoupling the data clock from the vagaries of the CD's rotation. From the description I read, they seem to have reduced the "computer" to a specialized state machine. This is arguably a good design for production (though given a $1500 list price, I wonder if it was chosen more for hardware part economy or just because that was a design they could manage in-house, assuming they wanted to avoid using an OEM single-board computer). For a DIY effort, the simpler hardware may not be worth the added design effort of rolling a state machine and programming it. OTOH, if you enjoy programming something like that, more power to you.
 
#607
#609
Controller Kits

mysound said:
I'm building something similar and found a couple of people that supply cd-rom controller kits:


http://www.diyaudio.com/forums/show...30529&perpage=10&highlight=cdrom&pagenumber=1 - (i've just ordered this from Prajit)

http://www.rockna-line.com/cdrom.htm - hasn't replied to emails

http://www.geocities.com/controller_kit/


any others out there?
Click to expand...
Hi MySound,

I have the controller from Rockna, and although it seems to be well constructed, it took forever to get it, communication was difficult, and it did not come with cables or a remote control. The pushbuttons on the PCB are burried in a jungle of taller components. It will be necessary to bypass them with parallel push buttons mounted elswhere. There is some reasonable support information on their web site. I have not actually hooked it up yet to see if it works well.

I also have the kit from Prajit. It appears to be fairly well constructed also, and the linear layout of the pushbuttons on the back side of the pcb, along with the IR sensor might make casing it up with access to the push buttons possible. Virtually no documentation, but it looks pretty simple.

I also picked up a couple of units from Muka who actually bought them in China and mailed them to me (I think he lives in Hong Kong). He was very nice and easy to deal with. The PCB is very well made, the kit is complete. The on PCB pushbuttons are small and very close together. They will also need to be bypassed with some parallel chassis mount push buttons. The web site for the manufacturer is in Chinese, so difficult even with Google language tools. On request, he emailed me a schematic. I don't know if Muka would be willing to pick up some more, but it can't hurt to ask him:

email: muka2000@sinatown.com

Forum Thread: http://www.diyaudio.com/forums/showthread.php?s=&threadid=69850

Robert
 
#610
All of these controller kits operate the drive in cd-replay mode, not DAE mode. There are 2 problems with this: jitter, and read error.

The jitter level of the digital out on the cd-rom drive is pretty random. It can be good, it can be miserable. A simple buffer and reclock could fix that.

The second problem is more of an issue. In cd-replay mode, any read errors are glossed over. From the cdparanoia faq: "The audio CD is not a random access format. It can only be played from some starting point in sequence until it is done, like a vinyl LP. Unlike a data CD, there are no synchronization or positioning headers in the audio data (a CD, audio or data, uses 2352 byte sectors. In a data CD, 304 bytes of each sector is used for header, sync and error correction. An audio CD uses all 2352 bytes for data). The audio CD *does* have a continuous fragmented subchannel, but this is only good for seeking +/-1 second (or 75 sectors or ~176kB) of the desired area, as per the SCSI spec." Because of the lack of header, sync, and error correction info in the raw sector, there is no way to determine accuracy of the data read during replay as the disc is streaming in replay mode, and providing data in real time as it's read from disc.

In DAE mode, we can target individual sectors and reconstruct the subchannel information and detect read errors. This also allows time to re-read the sector, as we can operate the drive in faster than 1x speed when using DAE mode.

Maney, I agree that they seem to have reduced the "computer" to a finite state machine, but that is similar to what I would like to try. I'm not sure how to operate the cd-rom drive in DAE mode without it? My ideal project would read data off disc using DAE mode getting the digital data from the IDE connector, and perform error detection and correction at this stage to ensure we are getting the most accurate bits from the discand dump into a buffer. This initial read stage does nothing about jitter. The secondary stage would use a high quality clock to stream data from the buffer to a digital output. This stage is where jitter is addressed. The resulting stream at the digital output after these two stages should present the most accurate possible data and the lowest possible jitter, which are the two key pieces to a high quality transport as I know it.

Thoughts?
 
#611
What is the different of the digital out for the IDE connector with circuit and the built in SPDIF output?

Today I use the SPDIF on an AOPEN DVD-Rom connected to a very nice
DAC who rebuild the whole signal from the DVD-rom. It’s sounds very nice.
I’m missing to bee able to play DVD-audio and Sacd.
 
#612
Progg70,

In cd playback mode, the cd will stream the data out the digital out port. All 2352 bytes in a sector are streamed directly.

Assume that a portion of the sector reads "111000111"

If the laser mistracks and reads "110100111" that is sent to the digital out port instead of the correct bits, because there is no provision for error detection or correction in cd-playback mode.

In DAE mode, I think the spidif output is disabled (I don't know for sure), so you can only get the bits from the IDE interface.

Ideally, with DAE mode you can have an algorithm like this:
sub ReadData(x)
get data from sector X
calculate hash for X
compare hash with ??
if not equal, repeat ReadData(currentSector)
else ReadData (nextSector)

This allows multiple attempts to read a sector in case of random laser track errors.
 
#613
tsai said:
All of these controller kits operate the drive in cd-replay mode, not DAE mode. There are 2 problems with this: jitter, and read error.

The jitter level of the digital out on the cd-rom drive is pretty random. It can be good, it can be miserable. A simple buffer and reclock could fix that.


Maney, I agree that they seem to have reduced the "computer" to a finite state machine, but that is similar to what I would like to try. I'm not sure how to operate the cd-rom drive in DAE mode without it? My ideal project would read data off disc using DAE mode getting the digital data from the IDE connector, and perform error detection and correction at this stage to ensure we are getting the most accurate bits from the discand dump into a buffer. This initial read stage does nothing about jitter. The secondary stage would use a high quality clock to stream data from the buffer to a digital output. This stage is where jitter is addressed. The resulting stream at the digital output after these two stages should present the most accurate possible data and the lowest possible jitter, which are the two key pieces to a high quality transport as I know it.

Thoughts?
Click to expand...

Sounds like a great plan... good analysis of the task at hand.

I don't know either how DAE is accomplished. Hopefully it works below the level of needing software processing outside the drive, and a simple controller could do it for us.

OTOH, maybe the reclock/cleanup of the standard SPDIF out might be the simpler way to go, if it isn't the only way... (assuming no DAE w/o a computer)

Anyone try/hear about something like this? Think just a reclocker might do the job, or supplying a high quality clock for the drive, derived from the outboard DAC clock?
 
#617
Hello

I made a diy cd drive and dac based on a cdrom.

To minimize jitter, i took a guido tent XO at 33.8 Mhz.
The cdrom drive asus 520 is also 33.8 Mhz.

Then I reclock the entire cdrom drive with this clock, and the Dac also with this clock too.

Here some information :

http://www.diyaudio.com/forums/showthread.php?postid=554556#post554556

http://www.diyaudio.com/forums/showthread.php?postid=554767#post554767

http://www.diyaudio.com/forums/showthread.php?postid=569718#post569718

http://www.diyhifi.org/forums/viewtopic.php?p=4883#4883

Philippe
 
#620
...ships and shoes and sealing wax, of state machines and things.

Tsai, I think my basic idea is that I have more than enough parts sitting around to put together an adequate computer, so that's a much quicker route, for me, to getting a working testbed than the state machine design. (I've worked on those in the dim and distant past, and if the hardware constraints were much more stringent then, we also weren't doing anything so involved as this error correcting business seems likely to be.) And as I tried to suggest earlier, I'm interested in comparing CD playback with ripping the whole thing and playing back from a hard drive. It's hard to see why the former couldn't be made to work as well, but there is the fact that the error handling is entirely inside the disk drive rather than being intertwined with the buffering...

I also have some vaguer, longer-range notions about playing around with the oversampling / digital reconstruction filtering thing, which I think even an older CPU that I don't want to use as a desktop might have plenty of horsepower for. Of course this is getting on into the DAC side of things, but that's okay with me. 🙂

For any of these design points (including the minial state machine), I think one key element will always be a circular buffer into which the source processing appends data asynchronously (just have to not overrun the current output point nor fall behind), and the very stable, low-jitter readout to generate the output data stream.
 
You must log in or register to reply here.
Top Bottom