index.html

linux平台下的dvd刻录软件

calibrate their mechanics every time the media is loaded by sliding
the optical head some place, picking up the signal and noting the
physical block address underneath the lens. In order for this procedure
to work with re-writable/recordable media, that particular spot has to
be written to [or de-iced in DVD+RW case]. Some units slide the head to
30mm [radial] to calibrate, some to 35mm. In order to keep such players
"happy," make sure that at least 1GB is written [before you
attempt to mount it in DVD-ROM unit].

<P ALIGN="JUSTIFY">Other units attempt to seek to lead-out [or vicinity
of it] for calibration purposes. Now the catch is that it's perfectly
possible to produce a DVD+RW disc without lead-out. Most notably media
initially formatted with dvd+rw-format [apparently] doesn't have any
lead-out, not to mention that practically whole surface remains virgin.
If you fail to mount/play DVD+RW media, attempt to

<BLOCKQUOTE><PRE>dvd+rw-format -lead-out /dev/scd<FONT
COLOR="red">N</FONT></PRE></BLOCKQUOTE>

<P ALIGN="JUSTIFY">which relocates the lead-out next to outermost
written sector as well as makes sure there is no virgin surface before
it. Previously written data is <B>not</B> affected by this operation.
<!-- &quot;Should&quot; is a reminder of the project status,
&quot;experience gathering.&quot; I mean the best I can do is to state
that my hp dvd200i unit doesn't wipe any data when relocating the
lead-out.-->

<P ALIGN="JUSTIFY">Then non-finalized DVD+R and Sequential DVD-R[W]
discs don't have lead-out either<SUP>(*)</SUP>. If you fail to
mount/play DVD+R media and wish to sacrifice the remaining space for
immediate compatibility, just fill the media up<SUP>(**)</SUP>.
Alternatively if you master volume in a single take and don't plan to
use it for multi-sessioning<SUP>(***)</SUP>, you have the option to
invoke growisofs with <TT>-dvd-compat</TT> option and cut the real
lead-out directly after the first session.

<P>
<TABLE BORDER="0" WIDTH="95%" ALIGN="CENTER">
<TR VALIGN="TOP" ALIGN="JUSTIFY">
<TD><FONT SIZE="-1"><SUP>(*)</SUP></FONT>
<TD><FONT SIZE="-1">Well, there are lead-outs at the session edges, but
the problem is that &quot;End Physical Sector Number of Data Area&quot;
field in &quot;Control Data Zone&quot; of the lead-in contains address
of the largest media sector, which makes affected DVD[-ROM] players
calibrate at the outermost edge instead of the first session. Actually
I fail to understand why don't they burn the address of last sector of
the first session in the lead-in even on multi-session discs...
</FONT></TR>

<TR VALIGN="TOP" ALIGN="JUSTIFY">
<TD><FONT SIZE="-1"><SUP>(**)</SUP></FONT>
<TD><FONT SIZE="-1">But beware the <A HREF="#isofs4gb">4GB limit</A>!
If 4GB is already an issue, or if you don't feel like throwing
unrelated data on the media in question, then invoke '<TT>growisofs
<FONT COLOR="red">-M</FONT> /dev/scd0<FONT
COLOR="red">=/dev/zero</FONT></TT>' (supported by 5.6 and later).
Alternative is to re-master the whole volume, naturally with
<TT><NOBR>-dvd-compat</NOBR></TT> option.
<!-- then the easiest way is to create couple of holey
files with '<TT>touch huge<FONT COLOR="red">M</FONT>.void</TT>' and
'<TT>perl -e 'truncate (&quot;huge<FONT
COLOR="red">M</FONT>.void&quot;, 0x7ffffffe)'</TT>', and finally to
'<TT>growisofs -overburn -M /dev/scd<FONT COLOR="red">N</FONT> ...
huge*.void</TT>'. Otherwise you might have to re-master the volume with
<TT>-dvd-compat</TT> option.--></FONT></TR>

<TR VALIGN="TOP" ALIGN="JUSTIFY">
<TD><FONT SIZE="-1"><SUP>(***)</SUP></FONT>
<TD><FONT SIZE="-1">E.g. when mastering DVD-Video disc:-) Note that
<TT>-dvd-video</TT> option [passed to mkisofs] engages
<TT>-dvd-compat</TT> automatically.</FONT></TR>
</TABLE>

<A NAME="booktype"><P><HR WIDTH="50%" ALIGN="LEFT"></A>

<P ALIGN="JUSTIFY">Then we have logical format compatibility
issue(s). Probably the very ground for all the controversy around
DVD+RW, rather around DVD+RW media not being playable in a whole range
of players. DVD+RW Alliance was keen to blame on DVD-ROM vendors, even
claiming that they deliberately block playback. But the fact is that
format specifications don't explicitly say that unrecognized format
[designated by &quot;Book Type&quot; field in &quot;Control Data
Zone&quot; of the lead-in] should be treated as DVD-ROM and [in my
opinion] it was rather naive of them to claim and expect that the media
will be playable in &quot;virtually all players.&quot; This deficiency
was recognized by practically all DVD+RW vendors [well, apparently by
&quot;traditional&quot; DVD+RW vendors and not &quot;latest
generation&quot; vendors such as Sony, NEC, TDK...] and a <A
HREF="tools/dvd+rw-booktype.cpp">secret</A> vendor-specific command
manipulating this &quot;Book Type&quot; field was implemented. So if
you fail to mount/play DVD+RW media, you <I>might</I> have an option to

<BLOCKQUOTE><PRE>dvd+rw-booktype -dvd-rom -media /dev/scd<FONT
COLOR="red">N</FONT></PRE></BLOCKQUOTE>

<P ALIGN="JUSTIFY">Once again. <B>Not all vendors support this and you
can't expect this utility to work with all recorders.</B>

<P ALIGN="JUSTIFY">It's naturally not possible to manipulate the
&quot;Book Type&quot; field on DVD+R media, that is not after the
lead-in is written [which takes place at the moment the first session
gets closed]. But it might be possible to control how it [lead-in] is
going to be branded by programming the drive <I>in advance</I>:

<BLOCKQUOTE><PRE>dvd+rw-booktype -dvd-rom -unit+r /dev/scd<FONT
COLOR="red">N</FONT></PRE></BLOCKQUOTE>

<P ALIGN="JUSTIFY">Meaning that if you fail to play DVD+R media, you
can attempt to burn another disc with more appropriate unit settings.
For more background information about dvd+rw-booktype, see <A
HREF="http://www.dvdplusrw.org/Article.asp?aid=42&hl=bitsetting">&quot;Compatibility
Bitsettings&quot; article at dvdplusrw.org</A>.

<P ALIGN="JUSTIFY">There [potentially] are other logical
DVD+RW<SUP>(*)</SUP> format incompatibilities, but the &quot;Book
Type&quot; issue discussed above is the only one &quot;officially&quot;
recognized. Well, it's actually understandable as it's the only one
that can be recognized and addressed by a DVD+RW vendor alone.
Recognition of other incompatibilities would require cooperation from
DVD[-ROM] player vendors and that's something they apparently are not
willing to show referring to the fact that DVD+RW format is not
approved [and apparently never will be] by <A
HREF="http://www.dvdforum.org/">DVD Forum</A><SUP>(**)</SUP>.

<P>
<TABLE BORDER="0" WIDTH="95%" ALIGN="CENTER">
<TR VALIGN="TOP" ALIGN="JUSTIFY">
<TD><FONT SIZE="-1"><SUP>(*)</SUP></FONT>
<TD><FONT SIZE="-1">Finalized DVD+R media branded with DVD-ROM
&quot;Book Type&quot; is virtually identical to DVD-ROM.</FONT></TR>
<TR VALIGN="TOP" ALIGN="JUSTIFY">
<TD><FONT SIZE="-1"><SUP>(**)</SUP></FONT>
<TD><FONT SIZE="-1">To which I say &quot;so what?&quot; DVD Forum is an
alliance of manufacturers just like DVD+RW Alliance is. It [or any
other party for that matter] has no authority to deny a technology
development initiative.</FONT></TR>
</TABLE>

<P><HR WIDTH="50%" ALIGN="LEFT">

<P ALIGN="JUSTIFY">Finally there is a physical incompatibility issue.
They claim that there are optical pick-ups out there not being capable
to decode the track because of low reflectivity of DVD+RW media
surface. I write &quot;they claim,&quot; because in the lack of
cooperation from DVD[-ROM] vendors it's not possible to distinguish
physical from logical format incompatibility, which I find important to
tell apart in order to make sure at least logical format
incompatibility issues don't persist over time. It might be as trivial
as following. As you surely know [already], DVD+RW has same
reflectivity as dual-layer DVD-ROM. Now the catch is that the linear
pit density in turn is same as of single-layer one. Meaning that if
player makes assumptions about linear pit density based on
reflectivity, then it won't be able to trace the track... But either
way, there is very little you can do about this one, but to try another
player...

<P><HR>

<H3>Technical Ramblings</H3>

<P><HR WIDTH="50%" ALIGN="LEFT">

<A NAME="isofs4gb"><P><IMG SRC="isofs4gb.gif" WIDTH=144 HEIGHT=315
ALIGN="RIGHT"></A>

<P ALIGN="JUSTIFY"><B>As for multi-session ISO9660 [DVD]
recordings!</B> Unfortunately, Linux ISOFS implementation has certain
deficiency which limits interoperability of such recordings. In order
to understand it, have a look at sample ISO9660 layout to the right...
Now, the problem is that isofs i-nodes<SUP>(*)</SUP> are 32 bits wide
(on a 32-bit Linux) and represent offsets of corresponding directory
entries (light-greens), byte offsets from the beginning of media. This
means that no directory (green areas) may cross 4GB boundary without
being effectively corrupted<TT>:-(</TT> It should be noted that in
reality it's a bit better than it looks on the picture, as mkisofs
collects all the directories in the beginning of any particular session
(there normally are no blues between greens). The <I>first</I> session
is therefore never subject to i-node wrap-around, but not the
<I>subsequent</I> ones! Once again, <FONT COLOR="blue">files</FONT>
themselves may reside beyond the <FONT COLOR="brown">4GB</FONT>
boundary, but not <FONT COLOR="green">the directories</FONT>, in
particular not in further sessions. Having noted that directory entries
are actually <I>specified</I> to start at even offsets, I figured that
it's <A HREF="isofs-2.4.patch">perfectly possible</A> to
&quot;stretch&quot; the limit to 8GB. But in order to <I>assure</I> the
maximum interoperability, you should <B>not let any session
<I>start</I> past 4GB minus space required for directory
structures</B>, e.g. if the last session is to fill the media up, it
has to be >400MB. As of version 5.3 growisofs refuses to <I>append</I>
a new session beyond 4GB-40MB limit<SUP>(**)</SUP>, where 40MB is
pretty much arbitrary chosen large value, large for directory catalogs
that is. Yet it doesn't actually <I>guarantee</I> that you can't suffer
from i-node wrap-around. Interim <A HREF="isofs-2.4.patch">fs/isofs
kernel patch</A> was addressed to those who have actually ran into the
problem and have to salvage the data. Even though permanent solution
for this problem appears in Linux kernel 2.6.8 (thanks to Paul Serice
effort), growisofs keeps checking for this 4GB limit in order to ensure
broader compatibility of final recordings.

<TABLE BORDER="0" WIDTH="95%" ALIGN="CENTER">
<TR VALIGN="TOP" ALIGN="JUSTIFY">
<TD><FONT SIZE="-1"><SUP>(*)</SUP></FONT>
<TD><FONT SIZE="-1">i-node is a number uniquely identifying a single
file in a file system</FONT>
</TR>
<TR VALIGN="TOP" ALIGN="JUSTIFY">
<TD><FONT SIZE="-1"><SUP>(**)</SUP></FONT>
<TD><FONT SIZE="-1">well, as DVD+R Double Layer support was introduced
in 5.20, <TT>-use-the-force-luke=4gms</TT> option was added to override
this behaviour (naturally recommended for Linux kernel 2.6>=8 users and
kernel developers only;-)</FONT>
</TR>
</TABLE>

<P><BR>

<P ALIGN="JUSTIFY"><B>Why media reload is performed after every
recording with growisofs?</B> Well, it's performed only if you didn't
patch the kernel:-) But no, I'm not insisting on patching the kernel!
All I'm saying is that in the lack of kernel support, media reload is
performed for the following reason. In order to optimize file access
kernel maintains so called block cache, so that repetitive requests for
same data are met directly from memory and don't result in multiple
physical I/O. Now the catch is that block cache layer remains totally
unaware of growisofs activities, growisofs <I>bypasses</I> the block
cache. This means that block cache inevitably becomes out of sync,
which in turn might appear to you as corrupted data. Media reload is
performed to flush/resync the block cache.

<P><BR>

<P ALIGN="JUSTIFY"><B>What does [kernel] &quot;DVD+RW support&quot;
<I>really</I> mean?</B> Even though DVD+RW has no notion of [multiple]
sessions, to ensure compatibility with DVD-ROM it's essential to issue
&quot;CLOSE TRACK/SESSION (5Bh)&quot; <A
HREF="http://www.t10.org/scsi-3.htm">MMC</A> command to
terminate/suspend background formatting (if any in progress) whenever
you intend to eject the media or simply stop writing and want better
read performance (e.g. remount file system read-only). This is what the
patch is basically about: noting when/if media was written to and
"finalizing" at unlock door.

<P ALIGN="JUSTIFY"><B>Secondly</B>, whenever you employ fully fledged
file system, I/O requests get inevitably fragmented.
&quot;Fragmented&quot; means following. Even though you can address the
data with 2KB granularity, it [data] is physically laid out in 32KB
chunks. This in turn means that for example writing of 2KB block
involves reading of 32KB chunk, replacing corresponding 2KB and writing
down of modified 32KB chunk. &quot;Fragmented requests&quot; are those
that are smaller than 32KB or/and cross the modulus 32KB boundaries. In
order to optimize the process certain caching algorithm is implemented
in unit's firmware. Obviously it can't adequately meet all possible
situations. And so in such unfortunate situations the drive apparently
stops processing I/O requests returning &quot;COMMAND SEQUENCE ERROR
(2Ch)&quot; ASC. This is the second essential of &quot;DVD+RW