Messages in this thread | | | Subject | Re: IDE CD drivers vs SCSI CD driver | Date | Sun, 20 Jul 1997 18:49:18 -0400 (EDT) | From | "Michael H. Warfield" <> |
| |
B. Chow enscribed thusly:
> This is just a little inconsistency.
> I have a CD that somebody burned for me, and it's possible that it was not > correctly written. However, the Linux SCSI driver and MSDOS seem to be > able to read the CD fine. The Linux ATAPI CD driver pukes and gags at the > CD and complains about the iso9660 fs on the disk to be incorrect. Any > ideas why this is happening?
Two possibilities...
1) What color is the CD. (Yes, I said what color).
There are three common dye medias you are likely to encounter, differentiated by their color. You may find Yellow (Gold), Green, and Blue. Gold is typically the least expensive and longer lived than the Green. The Green is currently the "most popular" but is slightly more expensive than the Gold, has a shorter life expectancy, but has much better compatibility than does the Gold. The Blue is manufactured only by Verbatum although it is remarketed under numerous other labels. In quantity, it can be cheaper than the Green with all the better compatibility with older drives and yet it is promoted as having a longer data life than even the yellow. All will outlive me... My personal preference is the Blue Verbatum (or whatever label the blue is available under).
If the color of the recording layer is Yellow and you have an older (or just fussier) drive, you may have a media compatibility problem. This is pretty much a well known compatibility problem between "Gold CD's" and older Audio CD players and older CD Roms. Some drives get fussy if they get dirty and make them more sensitive to problems with Gold CD's.
That being said - I would probably guess that this is NOT likely to be your problem though...
2) Data padding...
Most data CD's have a runout datapad of anywhere from 30K to 300K of zero's following the ISO 9660 image. The problem comes in with some of the drivers which attempt to cache "read-ahead" and read past the end of the file system. If it's padded, no harm done. If it's not, you can have totally bogus errors. It could be that the IDE driver is attempting to read-ahead and running into an End Of Media error off the end of the data track. The SCSI driver may be behaving a little better.
My guess would be that you most likely have a CD with an ISO 9660 file system which was not padded out with zeros when cut. The SCSI driver is handling this properly while the IDE driver is blowing and error at EOM.
I ran into a REAL problem with a pressing house one time when I did NOT add that padding to my data. They insisted that they would not even press the CD's because some CD drives would not read them without that padding. They remaster three of my masters before consulting me and totally screwed the RockRidge extensions. They ended up eating over 3000 pressed CD's and paying for shipping replacements. I now pad ALL of my masters with 300K of zeros and they won't even think about remastering my masters even at gun point! The cdwrite utility will only pad with 30K of zeros (the mastering house INSISTED on 300K - 150 2K blocks - go figure...). I ended up modifing cdwrite to pad out by 300K just to make sure these clowns would never even be tempted.
> -bc
Mike -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 925-8248 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
| |