CD-ROM controller Source code and Circuit diagram here.......

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
Please, translate it

Hello nFORCE,

Please translate, at least, part values in cir.pdf file, because some of them are hard to read on pcb.

As I see from source and schematics it does what it should - play, pause, next, previous, stop, eject. It's the first time I saw only those routines without all mp3 related stuff :)

Is that your site. If it is, does it work OK (is it debugged)?

Thank You.
 
cdrom or expensive audio transport

Is there any disadvantage to using a cdrom for audio cd playback?

I see creative has a IR remote model and I was thinking of putting it in a nice box rather than buying an expensive transport or building the homeoptics kit.

I disected a cdrom and removed the tray the other day. It worked fine as a top load transport. I havent tryed to get the digital signal off of it and I dont know if this is compatible with an conventional audio DAC.

Any ideas? Cant get a clear answer to whether good vs decent transports produce different quality data?

Fritz
 
hey where can i get teh schematic for this id like to try it. i was just going to take the audio out of teh back and put taht into my pre amp since all you have to do is press forward buttin and it will start playing cd.. done it befor for simple plesure uses..

J' id like teh schematic for teh pcb and ect ect and the parts use to create desplay.
 
From what Ive read there is correction software that will do some interpolation before the unit audibly misreads. The MArk Levinson site talks about the data getting clocked inacurately if the transports clock is not accurate. Then I guess the DAC might spit out a sound at the wrong time?


Fritz
 
I'm not sure we are talking about the same thing - if you are allowing the transport to do your DAC (using the audio connector in the back) then I would for sure expect different signals, based on the quality of the DAC.

However, data is data - if you have the buffering right I don't think there would be any distortions from different drives. Again, if there were, all the CD's in the world used for PC work would have SERIOUS problems.
 
it's well to remember that the formats of audio and data on cds are completely different, even when data reproduction (error corrected) is perfect, audio (not error corrected because 'you can't hear it anyway' as the wise engineers say) needn't be. Also the idiotic multiplexed data/clock interface (another invention of a corporate genius ) is what created the whole market for transports. And yes, they do sound very different.

peter
 
Hi Peter,

Thats more than I found in 30 minutes of searching the web. So the clock "time stamps" the peice of data and the error in this process causes the data to be played at the wrong time?
Do you know of any sites where this is explained or even a topic I could search.
Thanks
Fritz
 
analog_sa:

Are you talking about Red book vs Yellow book?

There is error correction in Red book, it uses CIRC (Cross Interleaved Reed Solomon Code). Do you mean this is ineffective or not inserted? I haven't looked at it in detail, interested in your response.

Isn't jitter normally an issue with CDR's that push the 80 minute boundary? (i.e. CD-R jitter , or does it occur with commercial CD's as well?
 
how do i listen to thee? let me count the ways

Of course the quick and dirty way to get audio from a cdrom is from the analog audio output in the back, it's line level, however probably not nearly as nice as a stand alone $50 cd player.

The digital signal from the back of many (not all) cdrom's is a TTL compatible SPDI/F sort of mickey-mouse thing that comes from the 'cdplayer' section of the controller IC in the cdrom. Though I have never measured it (and will never bother) I'm sure the jitter performance is not too good, living in a noisy environment like a cdrom drive, further more - to my knowledge - its not impedence matched to be transmitted to a 50ohm DAC input. I'm not saying it won't work, chances are it will, but uhhh... It's not going to be like using a decent transport.

The best method I can think of for audio extraction from a cdrom drive is reading the data directly off the disk with the ATAPI commands, using a fast hybrid DSP/microcontroller and creating the (slave) I2S signal from there and hand it over to a dedicated SPDIF transmitter. Apparently the hybrid DSP/micros let you control fast DSP functions and data crunching, moving and shaking with simple microcontroller-ish code. I dare someone to make this... it would be an excellent transport... hmmm now i think i might know my next project! :D

Cheers, Dan
 
John,

There is error correction in Redbook, and it works. It works for missing data on the CD, for example if its scratched and doesn't have some bytes where the scratch is. It can recover that data within limits, in fact the correction is so spread out physically, that you could have a quite sizable scratch and still read perfect data off a disk.

The correction scheme for data is much more complex, as it is absolutely critical for every bit to be correct in software programs. If a bit was intentionally read wrong (as an errant bit) the software would not opperate correctly, or maybe not at all.

However if your missing a bit out of a song, it's still a song. (mp3 anyone?)

Anyway, I'm a cdrom slob, I have some massively scratched up cdroms that I've been using as coasters for the last 6 mos, and I can still read the software off them with no errors, however some of my slightly less scratched CD's skip.

Jitter is a different can of worms, jitter is when your data gets all mangled because of timing and clocking issues. Not because its not there, but because it (the data or the clock) isn't there at the right time.

Good transports make the most of both worlds. They utilize error detection and correction to its fullest extent to make up for data that's missing (and if unrecoverable, mute or interpotate the output). They also employ very clean PSU's, clocks and PCB's to reduce the effects of jitter as much as possible.

So, back to the original subject of cdroms, I know they are quite capable of taking care of error correction (as in data reads) and I guess its up to us to take care of the jitter. can a cdrom be a high-end transport? By pressing the play button, no - by reading the data bus, yes.

Hope that helps. Cheers big ears!

Dan
 
ps

I've never played with 80 minute CDRs yet, (as audio CD's) wait.. maybe I have... oh well, anyway, I've never looked into there 'jitter' performance, but I imagine this is a completely different aspect as well.

Normally in terms of transports and DAC's we use the term jitter loosely to talk about the timing of the signals already in a usable form (eg: I2S, SPDI/F). However, the disk can't change these characteristics.

I believe the physical form of the data on the 80m CDR's has been slightly compressed together. Which might not be a problem with good optics, but I can imagine that the servos must be working overtime to keep up with a slightly faster than norm physical track, and some read errors might occour. I guess this could be called jitter, but it shouldn't be confused with the jitter in the circuits.

My stupid 80minute CDR jitter analogy: If you drive a car with a manual transmission, and your cruising speed and drive-train is well matched to your engine RPM, then everything is smooth, however (like in low gear) when there is a large difference between your engine speed and your drive-train, it does the jerk-jerk-jerk thing until there is an equilibrium. The jerking would be the equivalent to the servos adjusting the speed of the motors, and causing read errors. The CDR however may never smooth out to an equilibrium, because its expecting slower data, like as if you were to keep letting off the gas pedal... you'd never stop jerking, even after you die, I'm affraid the effects could be devistating!:att'n:

Sorry for the long PS

Dan

(oops, am i supposed to sign my name after a PS?)
 
No name Dan: ;)

Very informative post - I posted a link above to the jitter web pages for CD-R's that describes the issue as well, they say it's similar to what you mention. It also sounds like sometimes on CD-R's the pits aren't perfectly written, so you get a 'slop' on the the edge of a pit that can result in a smearing out of the 0/1 transition. As a result, a bit can get misinterpreted.

My hunch is that the disk would have to be pretty bad though for this to be a real issue due to the CCIR - otherwise all those data CD-R's wouldn't read too well, but then again we don't burn CD's that often at 24x.

I agree with the idea of a good transport having a clean PSU, etc, although my gut feeling as an extreme objectivist (I guess I need to be a card carying member) is that as long as the circuit is 'reasonable' (designed and working properly :xfingers: ), data should be data, and Digital is all about data.

I'm still fuzzy on analog_sa's statement that the clock is 'mixed in' with the data in a way that doesn't give you good framing (jitter) though, I think that's a different effect.
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.