index.html

最新的linux下dvd刻录软件,支持DVD+RW、DVD-RW光盘刻录。

<!-- &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
<NOBR>DVD-R[W]</NOBR> 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 multisessioning<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 multisession 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 <NOBR>DVD-ROM</NOBR>
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
<NOBR>DVD[-ROM]</NOBR> 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
<NOBR>DVD-ROM</NOBR> &quot;Book Type&quot; is virtually identical to
<NOBR>DVD-ROM.</NOBR></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 <NOBR>DVD[-ROM]</NOBR> 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 <NOBR>DVD-ROM.</NOBR> 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 multisession ISO9660 [DVD]
recordings!</B> Unfortunately, Linux ISOFS implementation had 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
maximum interoperability,</I> 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 2.4
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 DVD recordings. This check is not
performed for Blu-ray Disc recordings, as probability that a member of
such user community would run something elder than 2.6.9 is considered
diminishingly low.

<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 do not insist on patching the kernel!
All I'm saying is that in the lack of kernel support, media reload is
performed for the following reasons. 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 when flushing the block cache is not an option, e.g. only
privileged user is allowed to perform it. Second reason is to force
kernel to readjust last addressable block in case it was changed as
result of recording. This is done to preclude spurious "attempts to
access beyond end of device."

<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
support,&quot; namely injecting of &quot;SYNCHRONIZE CACHE (35h)&quot;
MMC command in reply to the error condition in question. The command
flushes the cached buffers which makes it possible to resume the data
flow.

<P ALIGN="JUSTIFY"><B>Unfortunately</B> the above paragraph doesn't
seem to apply to the 1st generation drives, Ricoh MP5120A and
derivatives<TT>:-(</TT> &quot;SYNCHRONIZE CACHE (35h)&quot; doesn't
seem to be sufficient and the unit keeps replying with &quot;COMMAND
SEQUENCE ERROR (2Ch)&quot; going into end-less loop. This makes it
impossible to deploy arbitrary file system. I'm open for
suggestions... Meanwhile the I've chosen to simply suspend I/O till the
media is unmounted. Even 2nd gen unit were reported to exhibit similar
[but not the same] behaviour under apparently extremely rare
circumstances. At least I failed to reproduce the problem... The problem
reportedly disappears with firmware upgrade...

<P ALIGN="JUSTIFY"><B>Then</B> some [most?] of post-2nd gen units, from
most vendors, seem to not bother about complying with