About CD/DVD players. I am on my 5th “ripping” CD/DVD player (in 15 years), I also use EAC. I just replaced the last Lite-On with a Plextor. That failing 1 year old Lite-On drive (EAC timing errors) replaced the previous failed 4 year old Lite-On. It can be hard to detect if it is the drive or the CD is causing the timing errors, but generally if the timing error is on the first or track and there are no real apparent damage issues it tells me to try it on another drive. If the timing errors are on the last track and the total length is well past 60 minutes it could be both, it depends.
As a side note, after replacing the drive 2 weeks ago I re-ripped the last 3 CD because half had timing issues, the new Plextor ripped them flawlessly.
interesting to know. I’ve actually found some of the “newer” optical drives I use are more prone to failing (maybe built cheaper?) than the old ones, thus why I am using one from July 2000 .
An example would be that I find that most slim drives you get these days are just terrible (for reading and writing purposes), whereas some of these old beige “clunkers” are a little more reliable.
Yeh, I hear you! My second drive was a IDE Lite-On that was rock solid and had all the features, what a drive, but the new systems did away with IDE for SATA and the drive in the new system was “okay” but I finally bought a new SATA Lite-On to add to the system (it lasted 4 years), they do not make the new stuff to last. I still have the "paperweight) IDE Lite-On in hopes that somehow I can connect it to USB or SATA with a “converter”, I gave up on the 4th converter attempt because EAC was not reliable with that setup (I still have the drive, I place it on top of the scanner to help flatten the artwork).
There are less and less factories making drives. And each chases to make construction “more efficient” by using cheaper components.
I use Pioneer drives. (currently a BDR-207D) Still got a bit of an old stock of them.
I remember the first drives I used - built like battleships.
A few months back I thought my main ripping drive was developing a fault as it started to have a consistent timing error a few tracks into a rip on multiple CDs. Can’t remember what I did now, but poked around with a few EAC settings and it went away.
Yeah, in my line of work I get access to a lot of old tech equipment and have been slowly hoarding old optical disk drives that are good quality - like you said the ones that feel like mini battleships! In the hope they’ll tide me over for the moment
Oh good, I was getting concerned because of all this talk about how long the lightweight lite-on drives last glares at drive but now that I know how useful they still are I’m not worried
I have actually used both P-IDE and SATA CD (and DVD) drives with EAC, with a cheep no-name USB adaptor… and… it worked… But I’m also running EAC on Windows, inside of VMWare, on my OS X Mac… so I’m sure if VMWare is cooking the USB data or not before Windows an see it.
I also use my extra drives as weights to press down artwork (Digipacks) on my flatbed scanner! The lid is just not heavy enough to flatten paper folds.
For extracting digital audio, Plextor drives manufactured before 2010 (arguably before 2005), seem to be “The Best”. (or rather, “The Least Worst”, because no single drive is completely perfect, and you can get that last 1% of accuracy by using multiple drives and combining the results.) I did some research on what it would take to extract bit-accurate archival images of optical media, and the short short answer is I would need to build my own CD reader from scratch, or piggyback my own controller onto a zombiefied CD-Drive, reading the raw FM signal off the laser pickup. (But leaving the laser focusing servos track the groove.) Building my own drive entirely from scratch would allow me to experiment with some really weird use cases, such as reading a CD backwards through the top surface of the disc. (For CDs which are badly damaged on the bottom surface, but the reflective layer and top (printed) surface are undamaged. Also, cracked, broken, and shredded CDs may be partially recoverable by reading (laser scanning) each piece, and then reassembling them in software. (And, also, with my own reader, I can automatically scan the matrix info on the central hub, and make very high resolution scans of the printed in regions on the top surface. (Only just a silhouette based on reflectance and absorption, older CDs are just black text silkscreened on with an empty (transparent) background, so this is fine.)
But anyway…
I think over the past fifteen years, there have only been two or three actual companies which have still been manufacturing CD/DVD drives, and all of the other brand names you see on the market, are just one of those cheep OEM drives with a sticker on the drive (and a string in the firmware) saying the “Well known” brand name.
Anyway, take a look at the documentation of Schily’s cdrecord, or any twenty year old CD ripping software, and marvel at the absolutely huge list of insane firmware bugs that needed to be worked around by burning and ripping software. It’s incredible that anything ever worked at all.
And yes, I realize that what I’d ultimately be building is just a scanning microscope with the ability to distinctly resolve features at least 500nm² in size. A bilevel image, with each picture element representing a spot 500nm² gives a total image size of approximately 17,210,000,000,000 pixels (2.15125TB) for the 86.05 cm² program area of a compact disc… but there are ways to cook this data down much smaller in size without loss. And also, the scanning doesn’t necessarily need to be “fast” – fast enough to playback audio in real time – so it has a lot more time to think and look around for data that regular CD players don’t. (But it can also just go fast, computers are fast now.)
(The pits and lands on an audio CD are between 850nm and 3500nm long.)
CD players use a clever trick to greatly enhance contrast between the land(s) and pits, because each of the reflective surfaces are… supposedly… half a wavelength apart in physical distance. The circularly polarized 780nm light will experience destructive interference between the two reflections off of both the pit and the land at the same time…
I think it’s the circular polarization that really cancels out the reflections (like those old anti-glare CRT screen covers) Because the thing about this that doesn’t quite seem to make sense to me though is that the pits are only 100nm high (or deep), which is not “half” of 780nm. (I mean… that will still give you partial interference, which is better than nothing.) But, when you reflect circularly polarized light, the reflection will flip from clockwise polarization to counterclockwise polarization.
ECMA-130 is less than illuminating on this topic.
Anyway, if you have the time to scan the surface hight of an object (say with Confocal techniques), you don’t really need to rely upon this polarized light trick to distinguish the hight difference between two metal surfaces. In fact, I speculate that you could possibly even capture the light scattering off the edges of each pit on a large surface area, and computationally reconstruct that edge from the diffraction pattern. (I haven’t done the math on this or anything, but intuitively, if you can record all of the scattered light projected onto a sphere, you can just computationally reverse the spherical wavefront back into the point from which it scattered from. And you know it’s just a laser going in, so the transformation between the two will give you the necessary surface shape.)
Anyway, the scanner wouldn’t necessarily need to rotate the CD either, it could just XY raster scan from left to right and top to bottom across the surface, and reassemble/decode all the pieces in the correct order using software. Spinning the CD has the advantage of reading the lands and pits in sequential order so processing/decoding of the data can be done in parallel with the reading. I would also track the rotation angle of each pit. (The radius and angle.) Because… funnily… because the raw signal is self-clocking, it has no absolute size or position… You can scale the pits and lands up and down in length, and wind the track pitch wider or narrower than 1600nm. That’s why early CDRs were only 60min (535MB), and then 74min (650MB), and then 80min (700MB), and then 99min (870MB), and GD-ROM, and Plextor’s GigaRec… etc. Also, there were copy protection techniques which would time reads and seeks between various sectors of a CD-ROM… sectors which had been carefully laid out at certain distances apart from each other on the engraved glass master. If the CD-ROM was burned to a CD-R, the sectors would typically be written into different absolute positions on the disk, which would change the time it takes for the CD Drive to seek and read from them.
Speaking of copy protection, you can write anything you want, anywhere you want when mastering a disc. Many drives make too many assumptions about things like, CD-ROM sector numbers monotonically increasing in sequential order, and every sector address being unique and used only once. If you have two different blobs of data, and you record them sequentially, but duplicating the same sector number between them. Then depending on weather you drive is seeking forward or backwards when it’s searching for those sectors, it will either return the first blob or the second blob. Fun times!
Oh, and there’s also writing deliberate correctable and uncorrectable errors, that’s an old trick. The first copy protection technique I ever learned was for the Commodore 1541, if you deliberately write a disk with a correctable sector error, and then make a copy. The copy will no longer have the error, so you can tell that it’s a copy by just checking if the read error still exists. Anyway, the same trick works for CD-ROMs. There were also “weak” sectors, but I think that with the variability in CD-ROM Drives, especially if they cache reads, it’s not consistent enough to reliably use for copy protection. (The 1541 is just dumb enough for being such a smart floppy drive.) Though actually, I think there was an audio CD copy protection scheme of mastering with deliberate C2 errors, which were inaudible (corrected) when played back in a regular CD Player, but CD drives had a terrible time extracting digital audio from.
What was I talking about… yeah so anyway, I want (me or someone else) to build a Kryoflux for optical media, and on the extreme end of the data recovery scale, possibly read data off a CD that has gone through a shredder.
I actually have at least two CDs (manufactured circa 1990) with a ring of bronze colored oxidation around the outer edge. Those area of the disc are unreadable, but I believe that this is because the reflectivity of the metallic layer is much lower now (from being tarnished). Physically the shape of the polycarbonate hasn’t changed. so any technique for measuring (reading) the lands and pits which does not depend on a really high-contrast reflection should work… or… you know, just amplify the signal off the head in a conventional CD player. The reason why CD-RW discs were unreadable in many CD drives, is because they’re not shinny enough. Drives which can read CD-RWs know that they need to amplify the signal they’re reading off the disc.
Edit…
So, I should probably mention that the (laser) optical pickup in a CD player, can’t actually see the pits! The laser spot is too big. It’s seeing an analog brightness level on about four photodiodes. So, once the disc is spinning at about the right speed, and the laser is actually focused (long story) into a 1000nm wide spot, you’ll get a sine wave electric voltage, as the amount of light reflected goes up and down in brightness, since the pits are smaller than the laser spot, it never goes totally dark, it just dims slightly compared to only seeing the lands (which is 1500nm on either side of the written groove with the pits)
Since I had to look some stuff up… I found out about the quarter wave phase cancelation thing. So the index of refraction of polycarbonate is 1.55, so a 780nm laser slows down in the plastic to be 780nm/1.55=503nm. The pits are about 110nm to 130nm tall, and because the light is being reflected that doubles the amount of distance it needs to travel. 125nm+125nm=250nm which is half of 500nm
Anyway, so you’ve got this big laser spot, reflecting into some photodiodes, and from it’s point of view there are some dark spots scrolling in and out of it’s view, so the brightness (voltage) is going up and down. (There are usually six photodiodes for focus and tracking. The two on the outside edges are looking at the flat, lands, between grooves. The brightness (voltage) on those should stay constant. The four in the middle are both for focusing with a cylindrical lens (long story), and for detecting when the spot is too far to the left or right of the pits in the groove, because the brightness will be too different between the two photodiodes if the spot isn’t centered right. (And the two outer ones will see some modulation.))
There’s a short blurb in ECMA-130 §12.4 about crosstalk, when the laser spot is straddling across two tracks (groovy pits)… it just says not to do that… I mean, I guess it can make demodulation a lot harder because of noise…
So, about demodulation…
The one’s and zero’s you want to store on plastic and read back later… CDs, at this level, use a fourteen bit code, but only the 256 bit patterns, out of all the 16384 possible bit patterns, in which there are no less than two consecutive 0’s in a row, and no more than ten consecutive 0’s in a row between 1’s… To put it another way, you’ll only ever see a single “1” bit, with two or more (up to ten) “0” bits in between, before you see the next “1”. You will never see “11” or “101” for example.
This is carved into plastic (engraved into glass with a laser, but you know…) using a non-return to zero code (specifically NRZI) where the transition from high (voltage/reflectance) to low (voltage/reflectance) and from low to high, represent a “1” bit, and “doing nothing” represent between two and ten “0” bits. Physically, the edges between the pits and lands represent “1”, and the flat in between parts represent “0”. If you CD is spinning too fast or two slow, you’ll know right away because the "1"s will be too close together or too far apart. See it’s self-clocking!
So, the shortest pit representing “1001” is supposed to be, according to spec *cough*, between 833nm to 972nm. The longest pit, representing “100000000001” is between 3054nm and 3560nm long. The standards documentations refers to these as 3T, 4T, etc., 10T, and 11T. Where “T” is the duration of one channel bit… at the velocity an audio CD spins at for playback (about 1.2m/s to 1.4m/s) that comes out to 464ns per channel bit.
The voltage you’re going to see coming out of your photodiodes will be a sine wave though. If you happen to be reading a long consecutive sequences of 3T (the shortest) pits, with the smallest gaps in between, you’ll see this as a 720KHZ tone (when the disc is spinning at ~1.3m/s) A long consecutive repeating pattern of 11T sided pits (and lands in between) will produce a 196KHz tone.
It’s frequency modulation… modified frequency modulation.
This gets turned back into a square wave by watching for every time the voltage crosses in the middle (50%-ish) between the highest and lowest points. This is §12 and figure 6 in the ECMA-130 standard if you want to see a very confusing picture.
Anyway, the NRZI is demodulated to NRZ, by doing this… that is to say 0’s are actually all the same voltage, and 1’s are all the other voltage. (Rather than alternating in between each “1”, when they flip.). At this point, you’ve recovered the fourteen-bit binary patterns, and you can transform them back into your original eight bits.
There are also special sync mark codes, so you know where to start interpreting the bits you’ve got – and there is still so much more decoding you still need to do to get to PCM audio data… But at least at this point, you’ve gone from shinny plastic to some actual binary bits. When spinning the CD at ~1.3m/s±0.1m/s this channel bit rate is 4.3218MHz
Also, I forgot to mention, there’s three bits inserted between each of the fourteen-bit patterns that go into the NRZI encoder, for reasons… so every eight bits of data you care about, actually becomes seventeen bits of channel data, physically.
.
