[sdiy] OT: Scratchy CDs

[Tim Parkhurst]

One thing you gotta remember about CDs is that they are a relatively slow
mechanical system. Also, they were originally designed for audio playback
(audio playback is considered '1X', very little random access). I think this
influenced a lot of the original specs for how CDs are burned and played
back, even though the requirements for a data system are VERY different
(sort of like the difference between an LP and a hard drive).


Tim Servo

"I love America more than any other country in this world, and, exactly for
this reason, I insist on the right to criticize her perpetually." 
-James Baldwin, Notes of a Native Son



> -----Original Message-----
> From: ChristianH [mailto:chris at scp.de]
> Sent: Tuesday, September 23, 2003 9:32 AM
> To: synth-diy at dropmix.xs4all.nl
> Subject: Re: [sdiy] OT: Scratchy CDs
> 
> I never completely understood this, but AFAIK there is no decent
> _random_access_ read command for audio data with a CD-ROM drive. Once a
> program has to stop reading, in order to write the data to disk, it only
> can 'go back a little bit' and start reading sequentially again. It has
> to put the newly read data into relation to the previous chunk, usually by
> looking for an overlapping identical data area. This resynchronization
> process can be implemented well, or it can be done sloppy. If it's not so
> good, it can fall for repetitive audio contents. Happens easily with
> sparse techno stuff (especially if it's sample based ;-), or with quite
> the opposite, long pad chords without any rhythm.
> 
> I heard rumors that SCSI drives are better in this respect, but don't
> know what may be the reason for that. Might be one of those myths as
> well. At least I never had a single stutter problem when reading audio
> CDs using the trusty old SCSI TEAC CD-R55 burner and an age old version
> of the WinOnCD software.
> 
> 
> But what's puzzling me, is just the nature of my game - oops, I mean,
> that the error correction failure affects only very short sample runs.
> With floppies, it was quite common for a whole sector to fail. And IIRC,
> the sample bits on a CD aren't simply coded as pits or no pits, but
> instead certain pit runs are combined and interpreted. I'd expect some
> bit level resynchronization problems, if there are bits missing. But
> maybe exactly that was the intention for combining several bits into
> runs, and by having redundancy (by allowing only a certain number of bit
> combinations) this might be helpful for quick resync.
> 
> pleased to meet you, hope you guess my name...
> Christian
> 
> 
> 
> On Tue, 23 Sep 2003 17:39:04 +0200 Ingo Debus wrote:
> 
> >
> > Am Montag, 22.09.03 um 22:25 Uhr schrieb ASSI:
> >
> > > The error correction process for an audio CD is rather complicated and
> > > as you found out, when all else fails, the drive will output the last
> > > known good sample in the absence of any better information.
> >
> > Does this error correction also work when a track is "ripped" (or
> > however it's called) via a CD-ROM drive in a computer? I was always
> > under the impression that it does not, since I got so many bad data
> > when ripping with my old computer. I always had to proof-listen before
> > burning a CD. How good the ripping worked seemed to be dependent of how
> > much the CD was scratched, but even badly scratched CDs play well on an
> > audio CD player.
> >
> > Ingo



***************************************************************************
This message is confidential.  The information contained in
this e-mail message is intended only for confidential use of the
recipient(s) named above. If the reader of this message is not the intended
recipient or an agent responsible for delivering it to the intended
recipient, you are hereby notified that you have received this document in
error and that any review, dissemination, distribution, or copying of this
message is strictly prohibited.  If you have received this communication in
error, please notify us immediately by e-mail, and delete the original
message.
***************************************************************************