[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: xcdroast problem (Re: SCSI emulation in kernel 2.4.17 Solved)



Thus spake Gregory Soyez (g.soyez@ulg.ac.be):

> Well, you're right, I placed the burner (using SCSI emulation)  on the same 
> IDE cable as the hard disk and I tried to burn from the hard disk.
> Actually, the guy I bough the writer suggested me to put the CD-reader and 
> the writer on two different IDE cables in such a way I can easily copy from 
> CD to CD. In such a case I had to put the burner in hdb because my CD-reader 
> is not ATA100.
> If I understand correctly your argument, I should move the burner to hdd and 
> pass through a temporary image on the hard drive when copying from CD to CD ?
> This may solve the problem, but maybe not.

You're certainly going to have bandwidth problems trying to burn on
the fly on the same IDE chain. Do you not have two though? Most MBs
have connections for two IDE cables, although I'm still not positive
there's sufficient bandwidth for copying on the fly. What write speed
were you using?

You should be able to connect your burner to your ATA100 controller
without difficulty (as I believe somebody else has already
indicated). Certainly my Promise ATA100 supports pretty much any IDE
device. 

Having said all of which, copying on the fly is generally not
recommended. 

One good reason: it is quite possible to get a clean copy of a CD onto
the hard disk even when the CD is flakey - cdparanoia is the classic
program for doing this - but this can sometimes require many
re-readings of sectors, complex correction algorithms etc. I have had
cdparanoia take several *hours* to read one particularly problematic
disc. 

There's no way you can do this on the fly as, no matter what speed you
burn at, you can't stop the burn to wait for data.

I use XCDroast and have had very few problems with it. My general
method is:
       1. rip the CD
       2. verify the CD (compares the hard disk image with the CD)
       3. burn

Yes it takes a little longer, but it means you can burn fairly quickly
and that's the only performance-sensitive part of the operation.

I say "fairly quickly" because the only time I suffered a buffer
underrun while burning was when trying to burn at 16x. The was from a
hard disc (ATA33 I believe) to a SCSI-2 burner. I'm figuring that the
IDE controller couldn't keep up.

So I now burn at 12x and have had very few problems since.
-- 
|Deryk Barker, Computer Science Dept. | Music does not have to be understood|
|Camosun College, Victoria, BC, Canada| It has to be listened to.           |
|email: dbarker@camosun.bc.ca         |                                     |
|phone: +1 250 370 4452               |         Hermann Scherchen.          |



Reply to: