DVD ->DVDR/W directly won’t work well with low spec machines.
I’ve found that I can copy Litey->Litey @ 4x on my celery 300 if the original is a burnt disc, and I am duplicating the entire disc, rather than just file copy.
HD->DVDR/W is the safest option to go for slower machines.
On the fly copying means an optical drive to another optical drive, without an intermediate image file created on a HD.
Actual channel locations (primary/secondary, master/slave) are irrelevant…
Optimally though, if you intend to do alot of On-the-fly copying, it is best to ensure that the two optical drives involved are on seperate IDE channels, so they won’t be fighting with eachother for transfer time.
i thought it was bad for optical drive to optical drive copying, since only one device on an IDE channel can be used at once?
So even if one device can access the channel at a time, even if both optical drives are on the same IDE channel, on the fly copying is still possible?
The drive itself will work in any machine. Whether the burning software supports DVD writing for Win98 is another matter entirely.
Nice Thread Hijack, by the way.
Yes & no.
Technically only one drive can be receiving/sending data to the controller on the IDE bus at any instant.
But all devices have buffers, so data isn’t being directly fed straight to the laser.
Data will be read into the reading drives internal buffer.
The IDE bus is locked (by the readin drive) & the data sent to the IDE controller (and system RAM). The reading drive will then unlock the bus again.
The IDE controller will then lock the IDE bus & send the Data from Ram to the Writing devices buffer. It will then unlock the IDE bus when it’s finished.
The writing drive then retrieves the data in it’s buffer (as required) and sends it to the laser.
If you are writing at a lower speed, then the Writing Drives buffer will empty slower & hence the data stream will be continuous to the writing laser, as long as there are no long delays in locking/unlocking buffers & so long as nothing goes wrong.
Of course, this is a simplification, as the reading drive and writing drive are continually demanding control of the IDE bus, and often they will want to transfer/receive data at the same time. So one of them has to wait for the other to release the IDE bus. Fine for small transfers.
Unfortunately, it is common for some optical drives to have “incompatabilities” with other optical drives & sometimes they don’t release the bus correctly, hence locking up the IDE chain.
When you have the two optical drives (alone) on seperate IDE channels, this should never occur, hence is safer.
Burn-proof goes a long way to fixing many issues, as the writing drive can stop & wait for the reading drive to behave, but many drives have burn-proof which requires the burning software to activate it, rather than the drive activates it automatically, hence it results in a coaster regardless since the bus is locked & the burning program can’t communicate with the burner until it’s too late.