> >I had problems like this some years ago on the 3DO videogame system,
> >working with CD-ROM drives made by MKE (Matsushita / Panasonic).
> >In this particular case, I *KNOW* for certain that the CD-ROM driver
> >and the operating / file system were *NOT* reading ahead (since I wrote
> >all of the code involved).
>
> I cannot believe this. You should verify your statement.
I was there, Jörg. I wrote the whole CD-ROM drive driver, and all
of the filesystem code in the operating system. I spent several days
figuring out what the problem was, and devising a fix. I discussed
the problem at some length with the firmware engineers at Matsushita.
I know what I'm talking about (at least in this case).
> If I take such a CD and read it with "readcd" I have no problems if I don't
> read the run-out sectors.
>
> >The problem turned out to be the drive's own firmware, and its management
> >of the drive readahead buffer. It turned out that if you try to
> >read the last Mode 1 block on the CD-R, the firmware would gag when it
> >hit the end of this block and hit the first audio-like block in the
> >leadout, and it would return bad data or a "mode error" indication
> >as a result.
>
> This is definitely not true for all drives I own. The problem has been
> reproted for several differnt drives and all reporters that I had
> written to personally have been able to read the CD using the drive in
> question when telling readcd to ommit the last two blocks.
Well, my point is that there *ARE* some drives out on the market
which have problems with these sorts of discs. Other drives...
perhaps more recent ones, perhaps just different... don't have problems.
The fact is, though, that some vendors' drives _do_ have problems
with this sort of disc - and that such discs _do_ appear to be
violating the strict "letter of the spec" by not having some
padding blocks (written in Mode 1) after the last significant block
in the filesystem.
> >So - Jörg - I _strongly_ encourage you to have the "-pad" option
> >be the default, in the next version of mkisofs - provide a "-nopad"
> >option for those who really wish to skate close to the edge. I really
> >do believe that without this padding, mkisofs/cdrecord are writing
> >CD-ROMs which do not meet the letter of the spec. Although some
> >operating systems and CD-ROM drives seem to tolerate these disks
>
> This are OS that are written correctly...
OK, let's grant that the Solaris architecture is more tolerant of
out-of-spec discs. I have no problem at all in accepting that
fact.
However, it appears to me that the very PURPOSE of the spec's requirement
for several padding blocks, is to _relieve_ the operating system of
the need to be pedantically careful about reading past the end of
the filesystem data.
There's an old axiom in the business - "Be liberal in what inputs you
will accept, and conservative in what outputs you generate."
I agree, Linux (and FreeBSD) have a behavior which makes them
intolerant of this particular spec violation. That's not good,
and it would be beneficial for these systems' kernels to behave
better. I seem to recall that the last time this discussion came
up, someone was reporting that a Mac or Windows system was having
trouble reading these discs accurately, as well.
Solaris is clearly very liberal (accepting) in what it can accept
This is a point in its favor, no doubt.
However - it seems to me that mkisofs is not being conservative
enough in its default behavior. When it, and cdrecord, are used
with their default options, the resulting disc does _not_ appear
to comply with the strict letter of the spec.
I think this is a bad thing. Furthermore, it is _unnecessarily_
bad. Having mkisofs pad its output by default would have *very*
little negative effect (a trivial increase in the size of filesystems),
would make the discs more portable, and would save users of the
cdtools package some amount of money in "coasters". Turning off
the padding could still be made available as an option, for those
who are sure that they will not need it.
I would guess that if you look at commercial CD-ROM mastering
packages for Mac and Windows systems, you'll probably find that
they pad the filesystem images automatically.
I urge you to do likewise. It will make cdtools a better
package.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
