[vorbis] cdparanoia mailing list ?

[Ed Sweetman]

On Fri, 2002-03-15 at 15:52, Monty wrote:
> 
> 
> 
> On Fri, Mar 15, 2002 at 03:18:02PM -0500, Ed Sweetman wrote:
> > I've never seen any atapi ide cdrom not work with the standard ide cdrom
> > driver.  
> 
> This is mostly an issue for older drives.  Any MMC compliant drives will at
> least mostly work with the ATAPI driver.
> 
> Cdparanoia knows about fifty different historical/proprietary read
> commands.  The kernel IDE/ATAPI interface knows one (two if you turn
> on some ifdefs).
> 
> > As for configuring as scsi, you may get some kind of driver
> > error checking, maybe. 
> 
> Yes, bigtime.  The ATAPI interface, upon seeing any reported error will
> retry forever until it gets 'a good read'.  This is a good way to
> cause damagaed/defective discs or buggy drives to just randomly never
> finish.

I dont know about it being random, if it's a damaged disk it's sort of a
given of when it's going to loop.  On those tracks cdparanoia keeps
trying and trying and trying with error correction on,  so i resort to
-Z and take whatever crap i get from that disk error to get the rest of
the track rather than not get it at all or only partially.  I dont see
how the scsi interface is going to "fix" these disc errors, It would
either stop the rip of that track upon the error and thus stop
cdparanoia or it would stop the rip of the track and cdparanoia would
continue ahead, giving you a skip (how audio cdplayers deal with errors)
Something that cdparanoia could very well do on it's own upon meeting an
error that just wont go away for one reason or another. 
 
> >  But you cant beat the ide cdrom driver for ide
> > drives, especially with the DMA transfer patch.  Ripping with dma means
> > you use about 2% to negligable cpu to read audio cds. 
> 
> That patch breaks some of cdparanoia's error checking badly.
> Specifically, it will make it harder for cdparanoia to detect
> unreported sector boundary errors because that DMA patch is actually
> splitting requests into single sector transfers and cdparanoia will
> not be able to detect or prevent it.  Cdparanoia's checking algorithms
> all assume >1 sector transfers.
> 
> It makes it much more likely that skipping/loss of streaming will not
> be detected, especially if the drive manages to screw up boundaries
> consistently, a problem in many models.

<p>from what i read in the patch and from what i've understood from the
maintainer, it only does single sector transfers when it experiences an
error (single frame dma transfer i'm assuming is your single sector dma
transfer).   The patch then tries again using this single frame, if it
recieves another read error it will revert to multi frame pio (plain
functionality from the ide cdrom driver now).  So you get multi-frame
dma by default with the patch, but if an error occurs it drops to single
frame dma and if still an error is found it drops to multi pio. 

That said, i haven't had any problems with cdparanoia reporting errors
in the same places that it used to report errors, just without all the
cpu usage.

> > The scsi driver
> > wont do that for ide drives i dont believe.  
> 
> The SCSI driver has always used DMA, even implementing memory
> scatter/gather, something the IDE patches can't do (thus the single
> secotr tranfers).
> 
> Monty
> 

hrmm, I'll have to try the scsi driver to see if it's dma audio ripping
is any better than this patch is for me.  

<p>--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.