In <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] asked:
> >From: [EMAIL PROTECTED] (Bill Davidsen)
> >No drive property tables need be compiled in, only an option to specify
> >the name of the user defined drive properties table. Nothing which
> >changes should be compiled in, but the ability to read such a table at
> >run time could be.
>
> >I'm *not* saying I think this is a great idea, but if you should decide
> >to provide this I believe it should be in the same n,n,n notation used
> >elsewhere, not by drive vendor. If the drive does not return good id,
> >let the user be responsible for getting the limitations.
>
> What do you believe should be in there ?
>
> Note that if you are pedantic, more than 74 minutes may cause problems...
Sorry for the slow reply, I thought a bit and went on vacation for a few
days. The only thing I can see of interest would be the limit of the
drive hardware, which the user would have to get from specs or a web
site, and perhaps an option to stop if the drive limit were exceeded,
and another option to stop if the media limit were exceeded.
To turn the question around, you probably know more about CD burner
hardware and technology than anyone else on the list, are there other
things which could be put in a "limits and options" file to reduce the
risk of bad burns?
--
-bill davidsen ([EMAIL PROTECTED])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
