Paul Thompson <[EMAIL PROTECTED]> "... And if you are trying to copy from an internal CD drive to the burner it will almost surely be too slow."
CD Drive-to-CD drive copies are almost never problem free. You are relying on too many things to keep up. "... I've found the best way for me, using a 4x Yamaha burner on a 7100/80, is to copy data to the hard drive first and then copy it to the burner. ..." Essentially, burning a CD is not a "multitask" situation. You want a direct HD to Burner file transfer and nothing else. You also have to be careful about all the "easy, convenient" default settings in your OS and applications. Disable every single one that may demand CPU time without notification. Your burner and burn app's readme will identify the usual suspects; read it and do what it says. Some typical culprits: Any Antivirus setting except check manually. Disable every other option. Any "helpful" utility setting that is supposed to save you from yourself. Norton Unerase and the like should not be running. No AppleTalk or other networking SW that might "check" to see if your telephone/internet company is still in business every 7 minutes. All File Sharing must be off. Disable OS settings like: Software Update: Update Automatically Date and Time: Network Time Server: Automatically (this one is a big cause of burn failures) Sherlock: Index Automatically ... etc. In fact, I never allow "Automatic" anything to happen on my CPU. If I want it done, I'll tell it when to do it. Startup with a "burn only" extension set. Sometimes it helps to look at how your devices communicate. SCSI and FireWire are Peer-to-Peer protocols and rarely have problems with each other. This is unrelated to the kinds of grief SCSI can give when it doesn't work properly for who-knows-what reason; a working SCSI setup is pretty slick. Even more important, both these protocols can transfer data directly to wherever without asking anybody what to do or how. IDE and USB are not; they rely on well-behaved devices on the chain and need instructions from the CPU to tell them what to do next. The rule with internal IDE is: Always transfer from one channel to the other (most IDE interfaces have 2 channels) Always transfer from Master to Master where possible (all IDE interfaces support 1 Master and 1 Slave per channel). Transferring from Master to Slave on different channels USUALLY is OK, but transferring from Master to Slave on the same channel is almost definitely not going to work if speed is an issue. The reason is the Master drive controls the channel, and the slave can not do anything until the Master releases the channel. If for example your OS is on the Master IDE drive, using a second (slave) HD for data transfer will fail every time the OS asks for HD access, because the OS is on Master and Master will kick Slave off the bus until it's good and ready to give it back. This is why Desktop Macs (like G4s) have the internal HDs on one channel and the removeable drives (CDR and Zip) on the other. So CD to HD is OK; CD to Zip is bad (the Zip drive is the slave to the CD on the external drive channel). And it's also why you shouldn't feel too envious of PC geeks with a full complement of drives loaded at the front of the case; unless they sprung for SCSI or extra IDE cards, they probably won't work if another drive is running at the same time. -- Mac Canada is sponsored by <http://lowendmac.com/> and... Shop Canadian, visit Mantek Services <http://www.mantek.mb.ca> Low Prices That Will Keep YOU and Your MAC Smiling Support Low End Mac <http://lowendmac.com/lists/support.html> Mac Canada info: <http://lowendmac.com/lists/mac-can.shtml> Send list messages to: <mailto:[EMAIL PROTECTED]> To unsubscribe, email: <mailto:[EMAIL PROTECTED]> For digest mode, email: <mailto:[EMAIL PROTECTED]> Subscription questions: <mailto:[EMAIL PROTECTED]> Archive: <http://www.mail-archive.com/mac-canada%40mail.maclaunch.com/> Using a Mac? Free email & more at Applelinks! http://www.applelinks.com
