1296 lines
64 KiB
HTML
1296 lines
64 KiB
HTML
<HTML>
|
|
|
|
<HEAD>
|
|
<BASE HREF="http://fy.chalmers.se/~appro/linux/DVD+RW/">
|
|
<TITLE>Blu-ray Disc/DVD+RW/+R/-R[W] for Linux</TITLE>
|
|
<META NAME="keywords" CONTENT="dvd, recording, burning, rewritable, mmc,
|
|
dvd+rw, dvd+r, dvdplusrw, dvd-rw, dvd-r, dvd-ram,
|
|
dvd+r double layer, dvd+r dl, dvd-r dl,
|
|
blu-ray, blu-ray disc, bd, bd-r, bd-re,
|
|
linux, netbsd, openbsd, solaris, freebsd, hp-ux, irix, unix,
|
|
mac os x, windows, mingw, win32, win64,
|
|
hp, ricoh, philips, sony, nec, plextor, benq,
|
|
optorite, lite-on, pioneer, lg, panasonic, matshita,
|
|
multisession, growisofs">
|
|
<META NAME="description" CONTENT="Blu-ray Disc/DVD+RW/+R/-R[W] support for Unix:
|
|
user-land utilities and optional Linux
|
|
kernel patch">
|
|
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
|
|
<LINK REL="icon" HREF="dvdplusrw.ico" TYPE="image/x-icon">
|
|
<LINK REL="shortcut icon" HREF="dvdplusrw.ico" TYPE="image/x-icon">
|
|
</HEAD>
|
|
|
|
<BODY BGCOLOR="#C0C0C0" TEXT="#000000"
|
|
LINK="#0000D0" VLINK="#502090" ALINK="#FF0000">
|
|
|
|
<P><HR>
|
|
<TABLE><TR>
|
|
<TD WIDTH="100%">
|
|
<H1 ALIGN="CENTER"><A HREF="Blu-ray/">Blu-ray Disc</A>/<A
|
|
HREF="http://www.dvdrw.com/">DVD+RW</A>/+R/<A
|
|
HREF="-RW/">-R[W]</A> for Linux</H1>
|
|
<H5 ALIGN="CENTER">by <appro@fy.chalmers.se>,
|
|
September 2006</H5>
|
|
<TD VALIGN="top"><A
|
|
HREF="http://www.ioss.jp/sohodiy/vol02-part01.html"><IMG
|
|
SRC="japanese.gif" WIDTH=48 HEIGHT=19 BORDER=0 ALT="Japanese"></A>
|
|
</TR></TABLE>
|
|
<P><HR>
|
|
|
|
<P><TABLE CELLPADDING=4>
|
|
<TR VALIGN="top" ALIGN="justify">
|
|
<TH>Q. <TH ALIGN="left">What is this page (not) about?</TR>
|
|
<TR VALIGN="top" ALIGN="justify">
|
|
<TD>A.<SUP> </SUP>
|
|
<TD>Maybe to your disappointment it is <B>not</B> about
|
|
video<SUP>(*)</SUP>. The scope of this page is primarily
|
|
computer storage applications of Blu-ray Disc and
|
|
DVD±RW/±R, things like backup, archiving, data
|
|
exchange... The downloadable files are an <I>optional</I> <A
|
|
HREF="linux-2.4.patch">Linux 2.4 kernel DVD+RW patch</A> and a
|
|
couple of user-land utilities dubbed as <NOBR><A
|
|
HREF="tools/?M=D">dvd+rw-tools</A></NOBR>.
|
|
|
|
<P><TABLE BORDER="0" ALIGN="LEFT">
|
|
<TR VALIGN="TOP" ALIGN="JUSTIFY">
|
|
<TD><FONT SIZE="-1"><SUP>(*)</SUP></FONT>
|
|
<TD><FONT SIZE="-1">Though it doesn't mean that you can't burn
|
|
DVD-Video discs with dvd+rw-tools. [Unlike Video-CD] DVD-Video
|
|
is "molded" in an ordinary data file system and
|
|
therefore no explicit support by the burning program is
|
|
actually required. In other words it is the DVD-Video
|
|
<I>content preparation</I> which is beyond the scope of this
|
|
page.</FONT></TR>
|
|
</TABLE>
|
|
</TR>
|
|
</TABLE>
|
|
|
|
<P><TABLE CELLPADDING=4>
|
|
<TR VALIGN="top" ALIGN="justify">
|
|
<TH>Q. <TH ALIGN="left">Kernel patch? This sounds too complicated
|
|
already! Can't I just use [vanilla] cdrecord?
|
|
|
|
</TR>
|
|
<TR VALIGN="top" ALIGN="justify">
|
|
<TD>A. <TD>It should be explicitly noted that the <B>user-land
|
|
utilities, dvd+rw-tools,</B> do suffice for BD/DVD recording
|
|
without explicit kernel support. So if they <A
|
|
HREF="#tutorial">fulfill your requirements</A>, <I>then</I>
|
|
<B>patching the kernel is</B> by all means <B>optional.</B> As
|
|
for [vanilla] cdrecord, non-CD recording strategies are
|
|
somewhat different, so it simply doesn't work (nor does
|
|
dvdrecord with media other than DVD-R[W], despite what <A
|
|
HREF="http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/release-notes/x86/">RedHat
|
|
7.3 Release Notes</A> say). On additional note Linux kernel
|
|
version 2.6>=10 is equipped with <A
|
|
HREF="http://web.telia.com/~u89404340/packet.html">packet
|
|
writing driver</A> which supports even DVD rewritable media,
|
|
but I haven't tested it myself, so don't ask:-)</TR>
|
|
</TABLE>
|
|
|
|
<P><TABLE CELLPADDING=4>
|
|
<TR VALIGN="top" ALIGN="justify">
|
|
<TH>Q. <TH ALIGN="left">What is the kernel patch good for then?
|
|
</TR>
|
|
<TR VALIGN="top" ALIGN="justify">
|
|
<TD>A. <TD>DVD+RW (but not DVD+R nor any DVD-dash) is a true random
|
|
write access media and therefore is suitable for housing of an
|
|
arbitrary file system, e.g. <B>udf,</B> vfat, ext2, etc. This,
|
|
and this alone, qualifies DVD+RW support for kernel
|
|
implementation. <I>However,</I> I have to recommend to
|
|
<B>deploy it with caution</B>, see <A HREF="#udf">tutorial</A>
|
|
for further details. Also note that not all OEMs seem to live
|
|
up to the promise of true random write access. As for the
|
|
moment of this writing apparenly only 2nd generation
|
|
Ricoh-based units (see <A
|
|
HREF="http://www.dvdplusrw.org/">dvdplusrw.org</A> for
|
|
generation listings) equipped with later firmware can sustain
|
|
I/O fragmentation (see Technical Ramblings below for further
|
|
details) and perform <I>reliably</I>.
|
|
</TABLE>
|
|
|
|
<P><TABLE CELLPADDING=4>
|
|
<TR VALIGN="top" ALIGN="justify">
|
|
<TH>Q. <TH ALIGN="left">What are the dvd+rw-tools for?</TR>
|
|
<TR VALIGN="top" ALIGN="justify">
|
|
<TD>A. <TD>As implied/already mentioned - <B>to master the <A
|
|
HREF="Blu-ray/">Blu-ray Disc</A> and DVD media, both +RW/+R and
|
|
<A HREF="-RW/">-R[W]</A>.</B> I could simply refer to the
|
|
tutorial below, but figured that couple of words about the
|
|
[original] design ideas behind <B>growisofs, the principal
|
|
burning utility,</B> wouldn't harm. Even though a modified
|
|
kernel can let you put for example an ext2 file system on
|
|
DVD+RW, it's probably not very practical, because you most
|
|
likely want to access the data on an <I>arbitrary</I> computer.
|
|
Or in other words you most likely want ISO9660. The trouble is
|
|
that you might as well want to <I>add</I> data now and then.
|
|
And what options do you have in the lack of multiple sessions
|
|
(no, DVD+RW has no notion of multiple sessions)? Complete
|
|
re-mastering which takes more and more time as data set grows?
|
|
Well, yes, <I>unless</I> you employ growisofs! Growisofs
|
|
provides the way to both lay down <I>and</I> grow an ISO9660
|
|
file system on (as well as to burn an arbitrary pre-mastered
|
|
image to) all supported optical media.</TR>
|
|
</TABLE>
|
|
|
|
<P><TABLE CELLPADDING=4>
|
|
<TR VALIGN="top" ALIGN="justify">
|
|
<TH>Q. <TH ALIGN="left">But if they support both + and - recording
|
|
strategies, why are they called dvd+rw-tools?</TR>
|
|
<TR VALIGN="top" ALIGN="justify">
|
|
<TD>A. <TD>For historical/nostalgical reasons, as originally they did
|
|
support exclusively DVD+plus. On the other hand now, when the
|
|
vast majority of DVD burners that are being introduced to the
|
|
market today are DVD+capable, the name most likely refers to
|
|
your unit in either case. And you can always consider the plus
|
|
in the name as notion of a unique quality, such as
|
|
"seamless" multisessioning, not as reference to some
|
|
particular format:-)</TR>
|
|
</TABLE>
|
|
|
|
<P><TABLE CELLPADDING=4>
|
|
<TR VALIGN="top" ALIGN="justify">
|
|
<TH>Q. <TH ALIGN="left">Do I still need <A
|
|
HREF="http://cdrecord.berlios.de/old/private/cdrecord.html">cdrtools</A>?
|
|
</TR>
|
|
<TR VALIGN="top" ALIGN="justify">
|
|
<TD>A. <TD>Yes. It should be explicitly noted that <B>growisofs is a
|
|
front-end to mkisofs,</B> i.e. invokes mkisofs to perform the
|
|
actual ISO9660 file system layout. Secondly, the DVD burners
|
|
available on the market can burn even CD-R[W] media and
|
|
cdrecord is the tool for this job [and this job only].</TR>
|
|
</TABLE>
|
|
|
|
<!--
|
|
<P><TABLE CELLPADDING=4>
|
|
<TR VALIGN="top" ALIGN="justify">
|
|
<TH>Q. <TH ALIGN="left">There are dual-format DVD+RW/-RW units
|
|
available on the market, e.g. SONY DRU500. Can I use
|
|
dvd+rw-tools with it/them?
|
|
</TR>
|
|
<TR VALIGN="top" ALIGN="justify">
|
|
<TD>A. <TD>If the question is if you can use dvd+rw-tools to master the
|
|
DVD+RW/+R media in a ±RW drive, then the answer always
|
|
was "definitely yes." If the question really is if
|
|
<B>you can use dvd+rw-tools to burn even DVD-R[W] media,</B>
|
|
then I have the pleasure to inform you that as of version 5.0
|
|
dvd+rw-tools provide <I>experimental</I> support even for
|
|
recording of DVD-R[W] media and refer you to <A HREF="-RW/">a
|
|
dedicated page</A> for further details.</TR>
|
|
</TABLE>
|
|
-->
|
|
|
|
<P><TABLE CELLPADDING=4>
|
|
<TR VALIGN="top" ALIGN="justify">
|
|
<TH>Q. <TH ALIGN="left">Does it work with <I>my</I> recorder unit?
|
|
</TR>
|
|
<TR VALIGN="top" ALIGN="justify">
|
|
<TD>A. <TD>If your unit is <A
|
|
HREF="http://www.t10.org/drafts.htm#mmc3">MMC</A> compliant,
|
|
then the answer is "<A HREF="hcn.html">most likely</A> it
|
|
just does." Well, as the probability of your unit being
|
|
non-MMC compliant is virtually zero, the answer in practice is
|
|
unconditionally "<A HREF="hcn.html">most likely</A>."
|
|
The [core] tools were reported to work with a wide range of
|
|
drives, including <I>[but not limited to]</I> <NOBR>HP
|
|
dvd[12345]x0i,</NOBR> <NOBR>Ricoh MP512x,</NOBR> <NOBR>Philips
|
|
DVDRW[248]xx,</NOBR> <NOBR>SONY DRU-[157]x0,</NOBR> <NOBR>NEC
|
|
ND-[1234]xx0,</NOBR> <NOBR>TDK indiDVD 4x0N,</NOBR>
|
|
<NOBR>Plextor PX-[57]xx,</NOBR> <NOBR>Benq DW[48]00A,</NOBR>
|
|
<NOBR>OptoRite DD0[24]0x,</NOBR> <NOBR>Lite-On
|
|
LDW-[4816]xxS,</NOBR> as well as <A HREF="-RW/">nonplus</A>
|
|
units such as <NOBR>Pioneer DVR-x0[45679],</NOBR> <NOBR>LG
|
|
GxA-40[248]x,</NOBR> <NOBR>Toshiba SD-R[56]112,</NOBR>
|
|
<NOBR>Panasonic UJ-811</NOBR>, <NOBR>LF-D[35]1x,</NOBR> and not
|
|
the least <A HREF="Blu-ray/">all-mighty</A>
|
|
<NOBR>SW-5582...</NOBR></TR>
|
|
</TABLE>
|
|
|
|
<P><TABLE CELLPADDING=4>
|
|
<TR VALIGN="top" ALIGN="justify">
|
|
<TH>Q. <TH ALIGN="left">Is there a GUI front-end available for
|
|
dvd+rw-tools?
|
|
</TR>
|
|
<TR VALIGN="top" ALIGN="justify">
|
|
<TD>A. <TD><A HREF="http://www.k3b.org/">K3b,</A> version 0.10
|
|
and later, and <A
|
|
HREF="http://ftp.gnome.org/pub/GNOME/sources/nautilus-cd-burner/">nautilus-cd-burner,</A>
|
|
version 0.5.1 and later, are both hiding growisofs behind their
|
|
pretty buttons and menus:-) Keep in mind that those are not
|
|
directly related to <NOBR>dvd+rw-tools</NOBR> development
|
|
effort and GUI users should turn elsewhere for <I>end-user</I>
|
|
support. Oh! dvd+rw-tools 5.10.x is a minimum requirement for
|
|
GUI frontends...</TR>
|
|
</TABLE>
|
|
|
|
<P><TABLE CELLPADDING=4>
|
|
<TR VALIGN="top" ALIGN="justify">
|
|
<TH>Q. <TH ALIGN="left">I don't run Linux. What are my options?
|
|
</TR>
|
|
<TR VALIGN="top" ALIGN="justify">
|
|
<TD>A. <TD>Version 5.4 adds support for <B><A
|
|
HREF="http://www.mosha.net/05-dvdrw/dvdrw.shtml">OpenBSD</A>/NetBSD.</B>
|
|
Version 5.6 adds support for <B>Solaris 2.x</B> <FONT
|
|
SIZE=-1>[<A HREF="solaris.com.html">commercial licensing</A>
|
|
terms for distribution on Solaris are to be settled with <A
|
|
HREF="http://www.inserve.se/">Inserve Technology</A>]</FONT>.
|
|
Version 5.8 features <A
|
|
HREF="http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/creating-dvds.html"><B>FreeBSD</B></A>
|
|
port contributed by Matthew Dillon, FreeBSD Development Team
|
|
alumnus. <NOBR>Hewlett-Packard</NOBR> Company has donated
|
|
<B><NOBR>HP-UX 11</NOBR></B> support for
|
|
5.14<SUP>(*)</SUP>. <B>IRIX 6.x</B> support appears in
|
|
5.19, <B><A HREF="tools/win32/">Win32</A></B> one - in 6.0,
|
|
while <NOBR>Mac OS X</NOBR> - in 7.0...
|
|
|
|
<P><TABLE BORDER="0" ALIGN="LEFT">
|
|
<TR VALIGN="TOP" ALIGN="JUSTIFY">
|
|
<TD><I>¡</I>
|
|
<TD><I>Common usage tip!</I><SUP> </SUP>Whenever
|
|
separately available [and unless stated otherwise], do <B>use
|
|
character-type device entry with <NOBR>dvd+rw-tools,</NOBR></B>
|
|
e.g. OpenBSD/NetBSD users should stick to <TT>/dev/<FONT
|
|
COLOR="red">r</FONT>cdXc</TT>.</TR>
|
|
<TR VALIGN="TOP" ALIGN="JUSTIFY">
|
|
<!-- <TD><FONT SIZE="-1"><SUP>(*)</SUP></FONT>
|
|
<TD><FONT SIZE="-1">FreeBSD tip! If you have an IDE unit, <A
|
|
HREF="http://www.cuivre.fr.eu.org/~thomas/atapicam/">atapicam</A>
|
|
is your mantra! Secondly, if you have <TT>devfs</TT> mounted,
|
|
you might have to <A HREF="fdescfs.sh">mount</A>
|
|
<TT>fdescfs</TT> as well.</FONT></TR> -->
|
|
<TR VALIGN="TOP" ALIGN="JUSTIFY">
|
|
<TD><FONT SIZE="-1"><SUP>(*)</SUP></FONT>
|
|
<TD><FONT SIZE="-1">As of 5.14 HP-UX support was classified as
|
|
"initial." Version 5.18 in turn is the one which has
|
|
undergone <A HREF="tools/HP/">HP quality assurance</A> testing
|
|
and is delivered on <A HREF="http://www.software.hp.com/">HP
|
|
software depot</A>.</FONT></TR>
|
|
</TABLE>
|
|
</TR>
|
|
</TABLE>
|
|
|
|
<P><HR>
|
|
|
|
<H3>Foreword</H3>
|
|
|
|
<P ALIGN="JUSTIFY">As of May 2003 I've decided to advise users to
|
|
<B>turn to <<A
|
|
HREF="mailto:cdwrite@other.debian.org">cdwrite@other.debian.org</A>>
|
|
on support matters.</B> It's an open list, meaning that you don't have
|
|
to be <A HREF="http://lists.debian.org/cdwrite/">subscribed</A> to post
|
|
a problem report. List archives can be found at both <A
|
|
HREF="http://lists.debian.org/cdwrite/">subscribe page</A> and <A
|
|
HREF="http://www.mail-archive.com/cdwrite%40other.debian.org/">mail-archive.com</A>.
|
|
<B>When submitting report, provide versioning information, exact
|
|
command line, <I>exact output</I> generated by the program and
|
|
complement it with <NOBR>dvd+rw-mediainfo</NOBR> output for
|
|
<I>resulting</I> recording.</B> Do check couple of last <A
|
|
HREF="http://lists.debian.org/cdwrite/">archived months</A>, as the
|
|
issue might have been discussed <I>recently</I>. If you've chosen to
|
|
contact me personally and haven't heard back within a week or so, then
|
|
you most likely overlooked something on this page. Please read it more
|
|
attentively<A HREF="keys.txt">...</A>
|
|
|
|
<P ALIGN="JUSTIFY">Special thanks for hardware donations [in
|
|
chronological order]:<BR>
|
|
|
|
<A HREF="http://www.inserve.se/"><IMG SRC="inserve.gif"
|
|
ALT="Inserve Technology" BORDER=0></A>
|
|
|
|
<A HREF="http://www.hp.com/"><IMG SRC="hp.gif"
|
|
ALT="HP" BORDER=0></A>
|
|
|
|
<A HREF="http://www.linuxfund.org/"><IMG SRC="linuxfund.gif"
|
|
ALT="LinuxFund" BORDER=0></A>
|
|
|
|
<A HREF="http://dmu.commtech-fastcom.com/"><IMG
|
|
SRC="commtech.gif" ALT="comm*tech" BORDER=0></A>
|
|
|
|
<A NAME="tutorial"><P><HR></A>
|
|
|
|
<H3>Tutorial</H3>
|
|
|
|
<P><HR WIDTH="50%" ALIGN="LEFT">
|
|
|
|
<UL>
|
|
|
|
<P><LI><P ALIGN="JUSTIFY">If your burner unit is managed by some
|
|
<NOBR><B>Linux<SUP>(*)</SUP></NOBR> removable media
|
|
automounting/autoplaying facility</B>, such as autofs, supermount,
|
|
subfs/submount, magicdev, autorun or similar, take it <B>out</B> of its
|
|
control! I can't help you with the latter, check your system
|
|
documentation (such as google perhaps:-) for specific instructions.
|
|
<FONT COLOR="brown"><B>Failure to take your unit out of
|
|
<NOBR>Linux<SUP>(*)</SUP></NOBR> automounting/autoplaying facility
|
|
control can result in busted recording, a coaster!</B></FONT> At the
|
|
very least you have to make sure your unit is not automounted during
|
|
recordings. <!-- Linux kernel should have/implement "open for
|
|
exclusive use," but it doesn't. Therefore the trouble... --->
|
|
|
|
<TABLE BORDER="0">
|
|
<TR VALIGN="TOP" ALIGN="JUSTIFY">
|
|
<TD><FONT SIZE="-1"><SUP>(*)</SUP></FONT>
|
|
<TD><FONT SIZE="-1">dvd+rw-tools support Solaris volume manager and
|
|
IRIX mediad in more gracious manner and it's safe to leave recorder
|
|
under <I>their</I> control.</FONT></TR>
|
|
</TABLE>
|
|
|
|
<P><LI><P ALIGN="JUSTIFY">Remember to <B>consult <A
|
|
HREF="hcn.html">Hardware Compatibility Notes</A></B> for possible
|
|
caveats or vendor-specific instructions for your unit. Well, such
|
|
reminder belongs at the end of tutorial, but I consider it important
|
|
enough to bring it up already here:-)
|
|
|
|
<P><LI><P ALIGN="JUSTIFY"><B>If you have an IDE unit and run 2.4.x
|
|
kernel,</B> you most likely want to "route" it through ide-scsi
|
|
emulation layer by either:
|
|
|
|
<P><UL>
|
|
<LI>passing "<TT>hd<FONT COLOR="red">X</FONT>=ide-scsi</TT>"
|
|
argument to kernel;
|
|
<LI>appending following lines to your /etc/modules.conf:
|
|
<BLOCKQUOTE>
|
|
<PRE>options ide-cd ignore=hd<FONT COLOR="red">X</FONT>
|
|
pre-install sg modprobe ide-scsi
|
|
pre-install sr_mod modprobe ide-scsi
|
|
pre-install ide-scsi modprobe ide-cd
|
|
</PRE></BLOCKQUOTE>
|
|
</UL>
|
|
|
|
<P ALIGN="JUSTIFY">Keep in mind that once hd<FONT COLOR="red">X</FONT>
|
|
is routed through ide-scsi, you can no longer refer to <TT>/dev/hd<FONT
|
|
COLOR="red">X</FONT></TT><SUP>(*)</SUP>, but to corresponding
|
|
<TT>/dev/scd<FONT COLOR="red">N</FONT></TT> only.
|
|
|
|
<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, except as in <TT>hdparm -d [0|1] /dev/hd<FONT
|
|
COLOR="red">X</FONT></TT>. <B>As for DMA settings.</B> Several users of
|
|
NEC[-based] units have reported that their systems crash during DVD
|
|
recording. The problem appears to be related to DMA settings, at least
|
|
switching it off reportedly helps. The problem appears to be specific to
|
|
some IDE chipsets...</FONT>
|
|
</TR>
|
|
</TABLE>
|
|
|
|
<P><LI><P ALIGN="JUSTIFY"><B>If you have an external unit,</B> just get
|
|
it working as CD-ROM first. I myself have no personal experience
|
|
whatsoever with <A HREF="http://www.linux-usb.org/">USB</A> or <A
|
|
HREF="http://www.linux1394.org/">IEEE1394/Firewire</A> optical storage
|
|
devices and have to direct you elsewhere for specific instructions. I
|
|
however am confident that if you manage to get your drive working
|
|
<I>reliably</I> as <NOBR>CD-ROM</NOBR> <I>and</I> <NOBR>CD-R[W]</NOBR>
|
|
burner, then you won't have any troubles with dvd+rw-tools either. USB
|
|
connected drives were reported to be working fine since eternity.
|
|
Firewire connected drives in turn were reported to fail miserably under
|
|
2.4.18. The failure didn't seem to be DVD recording related as it
|
|
reportedly failed burning even CD-R media. Firewire support was
|
|
substantially revamped in 2.4.19, and dvd+rw-tools were reported to
|
|
work with this and later kernels.
|
|
|
|
<P><LI><P ALIGN="JUSTIFY">If you're running 2.4.19 or .20, consider
|
|
applying <A HREF="sg-2.4.19.patch">this drivers/scsi/sg.c patch</A>.
|
|
The bug is fixed in .21. I write "consider" and not
|
|
"do" for the following reasons:
|
|
|
|
<P><UL>
|
|
<LI>dvd+rw-tools are not affected by this bug (as they don't use SG_IO
|
|
interface), cdrecord [potentially] is;
|
|
<LI>I however haven't actually experienced the problem with cdrecord
|
|
(maybe yet, kernel could have managed to keep buffers neatly aligned
|
|
while talking to cdrecord those times I tried), it was VMware that has
|
|
failed miserably on me;
|
|
</UL>
|
|
|
|
<P ALIGN="JUSTIFY">As of version 5.6 dvd+rw-tools add support for SG_IO
|
|
pass-through or in other words support for Linux 2>=5[.43],
|
|
where "generic" SCSI interface can be bypassed by issuing
|
|
SG_IO ioctl directly against block device, such as <TT>/dev/hd<FONT
|
|
COLOR="red">X</FONT></TT>. I wish it worked without need for <A
|
|
HREF="http://marc.theaimsgroup.com/?t=105410790500005&r=1&w=2">interim</A>
|
|
patches <A HREF="ide-cd-2.5.69.patch">#1</A> and <A
|
|
HREF="ide-cd-2.5.69.+patch">#2</A>, (the latter is relative to
|
|
2.5.69-75, the 1st problem is addressed in .71, 2nd one - .75-bk3 in
|
|
"<A
|
|
HREF="http://marc.theaimsgroup.com/?l=linux-kernel&m=105787192005635&w=2">last
|
|
minute</A>" prior first 2.6 cut. As for 2.6 in more general sense.
|
|
As you can imagine this new interface renders ide-scsi layer
|
|
superfluous and "the[ir] official plan™" is to scrap
|
|
it. I'm not really fond of the idea, but not for /dev/sg* account. I
|
|
mean I [personally] would prefer to keep ide-scsi and use SG_IO
|
|
pass-through with <TT>/dev/scdN</TT>, rather than with
|
|
<TT>/dev/hdX</TT>:-)
|
|
|
|
<P ALIGN="JUSTIFY">If you have to make dvd+rw-tools work under Linux
|
|
kernel 2.6.8, then upgrade the tool-chain to 5.21.x or later and
|
|
manually reward the installed binaries with set-root-uid flag. But the
|
|
"supported" recommendation is to just stay away from this
|
|
particular kernel version. <B>As for 2.6>8, dvd+rw-tools 5.21.x is
|
|
requirement.</B> Oh! dvd+rw-booktype utility would require set-root-uid
|
|
privilege then. Given its semi-official status and the fact that this
|
|
utility works only with limited number of units, installation procedure
|
|
<I>abstains</I> from installing dvd+rw-booktype set-root-uid, leaving
|
|
this security sensitive choice to the end-user.
|
|
|
|
<P><LI><P ALIGN="JUSTIFY"><B>Download, unpack and compile the <A
|
|
HREF="tools/?M=D">the tool-chain</A>.</B> To build the thing do pick the
|
|
.tar.gz archive, which contains Makefile as well as .spec file. You
|
|
will <B>need both C and C++ compilers</B> installed. Separate
|
|
source code files found in the <A HREF="tools/?M=D">download catalog</A>
|
|
are provided mainly for on-line reference purposes (such as <A
|
|
HREF="tools/growisofs.c">revision history</A>:-).
|
|
|
|
<P ALIGN="JUSTIFY">If your Linux kernel supports multiple ABIs (e.g.
|
|
Linux-sparc64 can run even 32-bit Linux-sparc applications, as well as
|
|
Linux-x86_64 can execute legacy 32-bit i386 binaries), make sure you
|
|
compile for <I>native</I> 64-bit ABI (which can normally be done with
|
|
'<TT>make TARGET_ARCH=-m64</TT>'). The problem here is that 64-bit
|
|
kernel has to explicitly convert ioctl structures passed by 32-bit
|
|
applications and apparently it does really lousy job when it comes to
|
|
CDROM_SEND_PACKET ioctl deployed by dvd+rw-tools.
|
|
|
|
<P><LI><P ALIGN="JUSTIFY">As new media products and brands are being
|
|
introduced to the market all the time, it apparently pays off to
|
|
<B><I>periodically</I> check for firmware updates.</B> For elder units
|
|
firmware update might even be an <B>absolute requirement</B> for using
|
|
new media. Special note for HP users. HP no longer posts firmware
|
|
updates on a web-page. Instead they let some Windows auto-update gizmo
|
|
to pick firmware updates among <NOBR><TT>dvd[1-6]00*.exe</TT></NOBR>
|
|
files in <A
|
|
HREF="ftp://ftp.hp.com/pub/information_storage/software/">their FTP
|
|
directory</A>, so that readers of this page tend to miss them...
|
|
|
|
<P><LI><P ALIGN="JUSTIFY"><B>Formatting the BD and DVD+RW media.</B>
|
|
Virgin BD and DVD+RW media needs to be initally formatted prior usage.
|
|
Once again, <B>only virgin BD and DVD+RW media needs to be
|
|
formatted.</B> As of version 5.10 growisofs detects blanks and applies
|
|
initial formatting procedure automatically. Otherwise same effect can
|
|
be achieved by passing the device name, e.g. <TT>/dev/scd0</TT>, as an
|
|
argument to <A HREF="tools/dvd+rw-format.cpp">dvd+rw-format</A>. Well,
|
|
in <A HREF="Blu-ray">BD case</A> it does offer more flexibility than
|
|
growisofs. To make formatting process reasonably fast, less than 1
|
|
minute, the media gets formatted only partially, as you can notice by
|
|
observing progress indicator displayed by dvd+rw-format. The final
|
|
indicator value varies from firmware to firmware, values as low as 1.6%
|
|
were observed. But it does not mean that you can only write that
|
|
little. The unit keeps formatting <I>transparently</I>, as you add more
|
|
data. Oh! Do keep in mind that DVD capacity of 4.7GB is expressed in
|
|
salesman's GB, i.e. 1000<SUP>3</SUP> and not 1024<SUP>3</SUP>. And
|
|
so is one of BD.
|
|
|
|
<P ALIGN="JUSTIFY">It was observed that excessive reformats can render
|
|
DVD+RW media unusable already after 10-20 reformats. It appears to be a
|
|
firmware deficiency, not some common media defect [at least it was
|
|
perfectly possible to salvage the media in a unit of different brand],
|
|
but I don't recommend [enforced] reformat in either case.
|
|
|
|
<P ALIGN="JUSTIFY">Note that <B>re-formatting procedure does not
|
|
substitute for blanking.</B> If you want to nullify the media, e.g. for
|
|
privacy reasons, do it explicitly with '<TT>growisofs <NOBR>-Z</NOBR>
|
|
/dev/scd<FONT COLOR="red">N</FONT>=/dev/zero</TT>'. Otherwise just
|
|
write over previous recording as it simply wasn't there, no
|
|
re-formatting is required.
|
|
|
|
<!---
|
|
<P ALIGN="JUSTIFY">DVD+R media does not require any formatting
|
|
procedure applied and is ready to use out-of-the-box. Apparently, a
|
|
reminder that 1st generation units (Ricoh MP5120A and derivatives)
|
|
are not capable of burning DVD+R is needed.--->
|
|
|
|
<A NAME="growisofs"><P></A><LI><P ALIGN="JUSTIFY"><B>Burning with <A
|
|
HREF="tools/growisofs.c">growisofs</A>.</B> There is hardly a need for
|
|
manual for growisofs. In a nutshell growisofs just passes all command
|
|
line arguments to mkisofs and dumps its output directly onto the media.
|
|
The first part means that you basically can [well, <I>should</I>]
|
|
consult <A HREF="mkisofs.8.html">mkisofs manual page</A> and
|
|
accompanying reference documentation (including multisession related
|
|
section[s]) and the second part means that you shouldn't expect an
|
|
ISO-image on the standard output (nor make sure you have enough free
|
|
temporary storage<TT>:-)</TT>. Differences from mkisofs command line
|
|
are:
|
|
|
|
<P><UL>
|
|
<LI>you may not use -o option;
|
|
<LI>you don't have to specify -C option, growisofs will construct one
|
|
for you;
|
|
<LI>there is internal -Z option for initial session recording, this
|
|
substitutes for originally suggested 'mkisofs | dd of=/dev/scd0';
|
|
</UL>
|
|
|
|
<P ALIGN="JUSTIFY">Otherwise <I>everything</I> that applies to
|
|
[multisession] mastering with mkisofs applies to growisofs as well. For
|
|
example just like with mkisofs you should make a note on which options
|
|
you used to master the initial "session" with and stick to
|
|
them, e.g.:
|
|
|
|
<P><BLOCKQUOTE><PRE>
|
|
growisofs -Z /dev/scd0 <FONT COLOR="red">-R -J</FONT> /some/files
|
|
growisofs -M /dev/scd0 <FONT COLOR="red">-R -J</FONT> /more/files
|
|
</PRE></BLOCKQUOTE>
|
|
|
|
<P ALIGN="JUSTIFY">Oh! Do make sure you have at least mkisofs <FONT
|
|
COLOR="red">1.14</FONT> on your $PATH (mkisofs 1.14 is part of cdrtools
|
|
1.10). If you consider passing <TT>/same/files</TT> as argument, or in
|
|
other words consider deploying growisofs for <I>incremental</I>
|
|
multisession backups, then you shall find <A
|
|
HREF="mkisofs-2.01a16-root.diff">this '-old-root' extension</A> to
|
|
mkisofs <FONT COLOR="red">2<A
|
|
HREF="mkisofs-2.0-root.diff">.</A>0-2.01</FONT> simply indispensable.
|
|
The idea and implementation by <A
|
|
HREF="http://home.pages.de/~ohly/#mkisofs-root">Patrick Ohly</A> is to
|
|
"graft" recording sessions as separate directories. Each
|
|
backup increment/directory is ment to contain both updated files and
|
|
<I>references</I> to previously backed up ones, which facilitates
|
|
comparison between increments as well as fine-graded restore.
|
|
|
|
<P ALIGN="justify">Number of users asked about opposite to
|
|
multisessioning: multivolume support. Being essentially a recording
|
|
program growisofs does not support multiple volumes by itself. There're
|
|
couple of front-ends I can recommend that arrange for this: <A
|
|
HREF="http://scdbackup.sourceforge.net/main_eng.html">scdbackup</A> and
|
|
<A HREF="http://www.serice.net/shunt/">shunt</A>. But back to
|
|
growisofs...
|
|
|
|
<P ALIGN="JUSTIFY"><B>In addition to intuitive -Z interpretation,</B>
|
|
growisofs [version 3.3 and later] recognizes special form of -Z command
|
|
line option which permits burning of arbitrary pre-mastered images. The
|
|
"magic" command is:
|
|
|
|
<P><BLOCKQUOTE><PRE>
|
|
growisofs -Z /dev/scd0<FONT COLOR="red">=</FONT>image.iso
|
|
</PRE></BLOCKQUOTE>
|
|
|
|
<P ALIGN="JUSTIFY">where <TT>image.iso</TT> represents an <I>arbitrary
|
|
object</I> in the file system, such as file, named pipe or device
|
|
entry. No, nothing is "growing" here and command name is
|
|
counter-intuitive in this particular context. And here is even less
|
|
intuitive<TT>:-)</TT> If you wish to burn down output generated by an
|
|
arbitrary program, you can use:
|
|
|
|
<P><BLOCKQUOTE><PRE>
|
|
dumpsomething | growisofs -Z /dev/scd0=<FONT COLOR="red">/dev/fd/0</FONT>
|
|
</PRE></BLOCKQUOTE>
|
|
|
|
<P ALIGN="JUSTIFY">Burning BD-R/DVD±R implies extra limitations:
|
|
|
|
<P><UL>
|
|
|
|
<LI>Needless to say that you have only one shot with -Z
|
|
option<TT>:-)</TT>
|
|
|
|
<!---
|
|
<LI>Apparently media needs to be manually reloaded [ejected and pushed
|
|
back again] after every burning session (well, if you haven't patched
|
|
the kernel that is<TT>:-)</TT>
|
|
--->
|
|
|
|
<LI>Unlike DVD+RW, DVD±R media does have notion of multiple
|
|
sessions. <I>However!</I> Not all legacy units can "see"
|
|
beyond the first one. Few DVD-ROM units are capable of DVD-R
|
|
multiborder playback, even fewer support DVD+R multisessioning. In
|
|
other words your DVD burner might be the only unit in your vicinity
|
|
capable to access data added at different occasions.
|
|
|
|
<LI>Even if your DVD unit does "sense" multiple sessions,
|
|
Linux kernel [2.4] sometimes fails to pull that information from the
|
|
drive<TT>:-(</TT> Till the problem is looked into and resolved you can
|
|
work it around by reloading corresponding driver, most likely
|
|
'<TT>rmmod sr_mod</TT>'.
|
|
|
|
<LI>Linux kernel 2.6<<A
|
|
HREF="http://marc.theaimsgroup.com/?l=linux-kernel&m=110330852622064&w=2">10</A>
|
|
users might experience <A
|
|
HREF="http://marc.theaimsgroup.com/?l=linux-kernel&m=108827602322464&w=2">problems
|
|
mounting multisession media</A> with last session starting beyond
|
|
2.2GB boundary. As fast-acting remedy I can suggest to route your unit
|
|
through ide-scsi, the way it was under 2.4. Even though it's declared
|
|
unsupported it actually still works in 2.6 (I for one still use it).
|
|
|
|
<LI>If you go for BD-R/DVD±R multisessioning, you have to use
|
|
mkisofs from <A HREF="ftp://ftp.berlios.de/pub/cdrecord/">cdrtools-2.0
|
|
or later</A> or apply <A HREF="multi.diff">this patch</A>.
|
|
|
|
<LI>And when it comes to <B>DVD+R Double Layer and <NOBR>DVD-R</NOBR>
|
|
Dual Layer recordings,</B> growisofs applies yet another limitation,
|
|
purely artificial. Taking into consideration Double Layer media prices
|
|
growisofs is programmed to <B>refuse to perform <I>unappendable</I>
|
|
recordings which are less than 1/2 of blank capacity</B> and to advice
|
|
to use single layer media instead.
|
|
|
|
<LI>DVD-R Dual Layer multisessioning is not supported for a reason
|
|
discussed on the <A HREF="-RW/#nomultisess">-RW companion page</A>. Once
|
|
again, as of the moment of this writing <NOBR>DVD-R</NOBR> Dual Layer
|
|
recordings come out unappendable and can not be grown.
|
|
</UL>
|
|
|
|
|
|
<P ALIGN="justify">And once again, do keep in mind that 4.7GB are
|
|
salesman's GB, i.e. 1000<SUP>3</SUP> and not 1024<SUP>3</SUP>. If
|
|
translated to "real" GB, single layer
|
|
<NOBR>DVD±R[W]</NOBR> capacity is not larger than 4.4GiB, and BD
|
|
- not larger than 23.3GiB! It should also be noted that earlier
|
|
growisofs versions did not check if there is enough space on media to
|
|
accommodate the data set to be burned, meaning that it was your sole
|
|
responsibility to make sure "overburn" condition is not
|
|
raised. As of version 5.2 growisofs performs the necessary checks
|
|
for you and refuses to start recording if "overburn"
|
|
condition appears to be unavoidable. This behaviour can be overridden
|
|
with <TT>-overburn</TT> command-line option.
|
|
|
|
<P><LI><P ALIGN="justify">If you're satisfied with growisofs, then you
|
|
should <B>just proceed to <A HREF="#compat">the next chapter</A></B>
|
|
and abstain from applying the <B>optional 2.4.x kernel patch.</B> If
|
|
you haven't stopped reading beyond this line, <A
|
|
HREF="linux-2.4.patch">download</A> the patch, apply it, rebuild the
|
|
kernel or modules and re-install (kernel or cdrom.o and sr_mod.o
|
|
modules, whichever appropriate), but don't ask <I>me</I> <A
|
|
HREF="http://www.linuxhq.com/patch-howto.html">how</A>. As you could
|
|
have noticed, patch targets SCSI CD-ROM module. This means that you
|
|
<I>have to</I> "route" your IDE unit through ide-scsi to get this one
|
|
working. To see it in action, insert formatted DVD+RW media and try to
|
|
access it, '<TT>dd if=/dev/scd<FONT COLOR="red">N</FONT> count=0</TT>'
|
|
would do. Then verify that kernel logs "<TT>sr<FONT
|
|
COLOR="red">N</FONT>: mmc-3 profile: 1Ah</TT>". You should now be
|
|
able to '<TT>mkisofs -pad . | dd of=/dev/scd<FONT COLOR="red">N</FONT>
|
|
obs=32k</TT>' or even '<TT>mke2fs -b 2048 /dev/scd<FONT
|
|
COLOR="red">N</FONT></TT>' and observe kernel logging "<TT>sr<FONT
|
|
COLOR="red">N</FONT>: dirty DVD+RW media</TT>."
|
|
|
|
<!--<P ALIGN="justify">If you have previous patch version applied, then you
|
|
have to back it out first. The simplest way is probably to restore
|
|
<TT>drivers/scsi/sr*.[ch]</TT> and <TT>drivers/cdrom/cdrom.c</TT> from
|
|
your original Linux source code ditribution.-->
|
|
|
|
<P ALIGN="JUSTIFY"><B>Linux 2.6</B> DVD+RW kernel support is planned in
|
|
line with DVD+MRW kernel support. This [unfortunately] means that
|
|
industry has to deliver a DVD+MRW capable unit first. Yes, the last
|
|
sentence means that despite all the promises, there are no such units
|
|
available on the market yet. As of the 1st of August 2003, Ricoh MP5240A,
|
|
Philips DVDRW416K or BenQ DW400A do <B>not</B> actually implement
|
|
Mt.Rainier/EasyWrite support. It remains to be seen if they will offer
|
|
it in form of firmware upgrade. In either case, the [original] project
|
|
goal is not only read-write support for DVD+[M]RW capable units
|
|
themselves, but even playback of DVD+MRW formatted media in legacy
|
|
DVD-ROM units (when defect list will be read and interpreted by OS
|
|
software in opposite to Mt.Rainier firmware).
|
|
|
|
<A NAME="udf"><P><LI></A><P ALIGN="justify">Even though kernel now
|
|
permits to build and mount arbitrary file system, there is one thing you
|
|
<I>must</I> keep in mind before you just proceed, no matter how
|
|
tempting it might appear.
|
|
|
|
<P ALIGN="justify">As you might know DVD+RW media can sustain only
|
|
around 1000 overwrites. The thing about fully fledged file systems
|
|
is that every read [or tight bunch of 'em] is accompanied by
|
|
corresponding i-node update or in other words a write! Now, let's say
|
|
you lookup the mount point (e.g. ls /mnt/dvd) ten times a day. This
|
|
gives you a 100 days lifetime on your mountpoint and therefore media.
|
|
Not really much, huh? So do use <TT>noatime</TT> mount option with
|
|
DVD+RW media or have it mounted read-only most of the time. However!
|
|
Every read-write mount "costs" a super-block update. So that
|
|
if you remount the media say 3 times a day, it would last for about a
|
|
year [<A
|
|
HREF="http://people.mandrakesoft.com/~quintela/supermount/">supermount</A>
|
|
would exhaust the "budget" way sooner]... Defect management
|
|
[in firmware, a.k.a. <A
|
|
HREF="http://www.licensing.philips.com/information/mtr/">Mt.Rainier</A>,
|
|
or at file system level] would improve the situation, but ideally
|
|
file system driver should definitely refrain from modifying the
|
|
super-block [marking it dirty] if nothing was actually written since
|
|
last mount. Given the development status of <A
|
|
HREF="http://sourceforge.net/projects/linux-udf/">Linux UDF</A> the
|
|
chances for seeing the latter implemented [for UDF] are more than just
|
|
conceivable. The request is already filed and even possible solution is
|
|
being discussed. But why not give UDF a shot already then? By default
|
|
UDF write support is unfortunately disabled and you might have to
|
|
reconfigure the kernel and rebuild modules. Alternatively [my preferred
|
|
option actually] fetch the code at <A
|
|
HREF="http://sourceforge.net/projects/linux-udf/">SourceForge</A> and
|
|
build the module separately. Of course you will have to fetch and build
|
|
udftools as well. But once it's done just type:
|
|
|
|
<P><BLOCKQUOTE><PRE>
|
|
mkudffs --spartable=2 --media-type=cdrw /dev/scd<FONT COLOR="red">N</FONT>
|
|
mount -o rw,noatime /dev/scd<FONT COLOR="red">N</FONT> /mnt/cdrom
|
|
</PRE></BLOCKQUOTE>
|
|
|
|
<P ALIGN="JUSTIFY"><TT>mkudffs</TT> command line options were suggested
|
|
by UDF maintainer, Ben Fennema.
|
|
|
|
<P><LI><P ALIGN="JUSTIFY">Performance optimization. This paragraph
|
|
applies only if you've patched the kernel. As some of you might
|
|
remember the original recommendation was "do use <TT>obs=32k</TT>
|
|
for optimal performance." Well, it was rather naive of me to say
|
|
so, as common block device layer <I>completely</I> reorganizes the
|
|
stream so that '<TT>>/dev/scd0</TT>' is as good as '<TT>|dd
|
|
of=/dev/scd0 obs=32k</TT>'. It should also be noted that dumping to
|
|
/dev/scd0 puts quite a pressure on VM subsystem, as the data passes
|
|
through block buffer cache. To minimize the pressure and improve
|
|
overall system performance bind the cdrom device to a raw device, e.g.
|
|
'<TT>raw /dev/raw/raw1 /dev/scd0</TT>', growisofs will locate and use
|
|
it automatically. obs=32k makes perfect sense with /dev/raw devices,
|
|
but dd (as well as most other programs, e.g. tar) won't work as
|
|
/dev/raw expects specifically aligned buffer... As <I>temporary</I>
|
|
workaround, just to get you going so that you can start figuring things
|
|
out, consider <A
|
|
HREF="http://fy.chalmers.se/~appro/LD_*-gallery/index.html?aligned_io#aligned_io">this
|
|
"hacklet"</A>...
|
|
|
|
</UL>
|
|
|
|
<A NAME="compat"><P><HR></A>
|
|
|
|
<H3>Compatibility: caveat lector</H3>
|
|
|
|
<P><HR WIDTH="50%" ALIGN="LEFT">
|
|
|
|
<P ALIGN="JUSTIFY">This paragraph discusses "DVD-ROM
|
|
compatibility," or playability of already recorded media in legacy
|
|
units. Blank media compatibility issues, or cases such as failure to
|
|
start or fulfill recording because of poor media support by burner
|
|
firmware, are beyond the current scope. Turn to your vendor for list of
|
|
supported media and/or to the <A
|
|
HREF="mailto:cdwrite@other.debian.org">public</A> to share your
|
|
experience.
|
|
|
|
<P ALIGN="JUSTIFY">In order to optimize seek times DVD[-ROM] players
|
|
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 terms]. 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 <NOBR>DVD-ROM</NOBR> 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 <NOBR>dvd+rw-format</NOBR> [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.
|
|
<!-- "Should" is a reminder of the project status,
|
|
"experience gathering." 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 "End Physical Sector Number of Data Area"
|
|
field in "Control Data Zone" 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 ("huge<FONT
|
|
COLOR="red">M</FONT>.void", 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 "Book Type" field in "Control Data
|
|
Zone" 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 "virtually all players."
|
|
This deficiency was recognized by practically all DVD+RW vendors [well,
|
|
apparently by "traditional" DVD+RW vendors and not
|
|
"latest generation" vendors such as Sony, NEC, TDK...] and a
|
|
<A HREF="tools/dvd+rw-booktype.cpp">secret</A> vendor-specific command
|
|
manipulating this "Book Type" 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
|
|
"Book Type" 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">"Compatibility
|
|
Bitsettings" article at dvdplusrw.org</A>.
|
|
|
|
<P ALIGN="JUSTIFY">There [potentially] are other logical
|
|
DVD+RW<SUP>(*)</SUP> format incompatibilities, but the "Book
|
|
Type" issue discussed above is the only one "officially"
|
|
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> "Book Type" 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 "so what?" 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 "they claim," 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
|
|
"stretch" 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] "DVD+RW support"
|
|
<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
|
|
"CLOSE TRACK/SESSION (5Bh)" <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.
|
|
"Fragmented" 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. "Fragmented requests" 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 "COMMAND SEQUENCE ERROR
|
|
(2Ch)" ASC. This is the second essential of "DVD+RW
|
|
support," namely injecting of "SYNCHRONIZE CACHE (35h)"
|
|
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> "SYNCHRONIZE CACHE (35h)" doesn't
|
|
seem to be sufficient and the unit keeps replying with "COMMAND
|
|
SEQUENCE ERROR (2Ch)" 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
|
|
<NOBR>DVD+RW</NOBR> specification, "true random write with 2KB
|
|
granularity" part in particular. Instead they apparently expect
|
|
host to apply procedure pretty much equivalent to <NOBR>DVD-RW</NOBR>
|
|
Restricted Overwrite. To be more specific host seems to be expected to
|
|
coalesce 2KB requests and perform aligned writes at native DVD ECC
|
|
blocksize, which is 32KB. Formally this should not be required, but
|
|
it's the reality of marketplace:-(
|
|
|
|
<P ALIGN="JUSTIFY">This one really beats me. Sometimes the unit
|
|
simply stops writing signaling a vendor specific positioning error,
|
|
03h/15h/82h to be specific. Especially if the media is newly formatted.
|
|
Couple of work theories. One is that block buffer cache reorders
|
|
requests so that they are not sequential anymore, "FLUSH
|
|
CACHE" might do the trick. Another one is that under
|
|
"underrun" condition background formatting kicks off and has
|
|
to be explicitly stopped. "Underrun" is in quotes because
|
|
the unit is supposed to handle temporary data stream outages
|
|
gracefully. If you run into this (you most likely will), try to
|
|
complement growisofs command line with [undocumented]
|
|
<TT>-poor-man</TT> option (which has to be first in the command line).
|
|
This option eliminates request reorders and minimizes possibility for
|
|
"underrun" condition (by releasing the pressure off VM
|
|
subsystem).
|
|
|
|
<P><BR>
|
|
|
|
<P ALIGN="JUSTIFY">The original idea was to implement DVD+RW support in
|
|
drivers/cdrom/cdrom.c. Unfortunately SCSI layer maintains private
|
|
"writeable" flag controlling the ability to issue WRITE
|
|
commands. The flag is impossible to reach for from the Unified CD-ROM
|
|
driver. But why am I talking about SCSI when there are only IDE units
|
|
out there (at least for the time being)? Well, as you most likely want
|
|
to occasionally burn even CD-R[W] with cdrecord you want it to go
|
|
through ide-scsi emulation layer anyway. So I figured that SCSI CD-ROM
|
|
driver is the one to aim for even for DVD+RW.
|
|
|
|
<P ALIGN="JUSTIFY">Unfortunately it was not possible to implement it
|
|
completely in sr_mod.o<TT>:-(</TT> Minor drivers/cdrom/cdrom.c
|
|
modification was required to sense the media before decision about
|
|
whether or not to permit write open. That's because DVD+RW drives are
|
|
morphing their behaviour after currently mounted media and it's
|
|
essential to identify newly inserted media.
|
|
|
|
<P ALIGN="JUSTIFY">Special comment about "what a dirty
|
|
hack!!!" To my great surprise it turned out that time-out value you
|
|
pass in cdrom_generic_command is simply ignored and time-out is set to
|
|
pre-compiled value of 30 seconds. Unfortunately it's way too low for
|
|
formatting purposes and I had to do something about it. Alternative to
|
|
"the dirty hack" was to add another argument to sr_do_ioctl
|
|
and modify all the calls to it... I've chosen to take over those 31
|
|
unused bits from the "quiet" argument instead of modifying
|
|
all the calls (too boring).
|
|
|
|
<P ALIGN="JUSTIFY">But even if time-out value passed down to kernel
|
|
(with <I>either</I> CDROM_SEND_PACKET or SG_IO ioctl) is taken into
|
|
consideration, it's apparently not interpreted as user-land code
|
|
expects it to. As I figured... There is no documentation on
|
|
CDROM_SEND_PACKET, but following the common sense most programmers
|
|
(including myself:-) expect it to be interpreted in at least
|
|
platform-independent manner, such as milliseconds maybe? SG_IO timeout
|
|
in turn is <A
|
|
HREF="http://www.torque.net/sg/p/sg_v3_ho.html#AEN215"><I>documented</I></A>
|
|
to be measured in milliseconds... Neither of this holds true! Kernel
|
|
treats these values as "jiffies," which is a
|
|
<B>platform-dependent</B> value representing time elapsed between timer
|
|
interrupts. But if we attempt to send down "jiffies," it
|
|
might turn out wrong too [at least for the moment of this writing]. The
|
|
catch is that [IA-32] kernel developers figured it's cool to shorten
|
|
"jiffy," but didn't care to provide user-land with actual
|
|
value (well, not of actual interest, too much legacy code to deal with)
|
|
<I>nor</I> <A HREF="scsi_ioctl-2.5.69.patch">scale</A> timeouts
|
|
accordingly in respect to the legacy value of 10ms.
|
|
|
|
<P ALIGN="JUSTIFY">There is another kernel "deficiency" I ran
|
|
into while working on the (original version of) dvd+rw-format utility.
|
|
The drive provides background formatting progress status, but
|
|
unfortunately it's impossible to access it. That's because progress
|
|
counter is returned [in reply to "TEST UNIT READY"] as
|
|
"NO SENSE/LOGICAL UNIT NOT READY/FORMAT IN PROGRESS" sense
|
|
bytes but with "GOOD" status. Apparently any sense data with
|
|
"GOOD" status is discarded by the common SCSI layer.
|
|
|
|
<!--
|
|
<P ALIGN="JUSTIFY">As you might have noticed the time-out value for
|
|
"CLOSE SESSION" is 3000 seconds. Does it really take that
|
|
long? It might... Disappointed? Don't be! It might happen <I>only</I>
|
|
when <I>reformatting</I> used media. Formatting of the <I>blank</I>
|
|
media doesn't take longer than a couple of minutes. <I>Reformatting</I>
|
|
in turn takes as long as it takes to nullify whatever you had on the
|
|
media which requires corresponding time-outs. But do you <I>have to</I>
|
|
reformat? Well, only if media contains sensitive data, the new data set
|
|
is smaller than the current one and (for some reason) will be easier
|
|
for potentially rival party to get hold of it (in other words when
|
|
there is a risk for sensitive data to get exposed). Another reason is
|
|
when you want to reuse the media as a master copy for DVD-ROM
|
|
manufacturing and want formatted capacity to reflect data set size.
|
|
Otherwise there is <I>no</I> reason to reformat and as long as you
|
|
don't you won't be disappointed with how long does it take to
|
|
"finalize" the media.
|
|
-->
|
|
|
|
<P ALIGN="JUSTIFY">It was pointed out to me that DVD+RW units work with
|
|
Acard <A HREF="http://www.acard.com/eng/product/scside.html">SCSI to
|
|
IDE bridges</A>.
|
|
|
|
<A NAME="plusvsminus"><P><HR WIDTH="50%" ALIGN="LEFT"></A>
|
|
|
|
<P ALIGN="JUSTIFY"><B>What does <A
|
|
HREF="http://www.cdfreaks.com/article/113"><I>plus</I></A> in DVD+RW/+R
|
|
stand for?</B> Originally this paragraph started as following:
|
|
|
|
<BLOCKQUOTE><P ALIGN="JUSTIFY">The key feature of DVD+RW/+R media is
|
|
high [spatial] frequency wobbled [pre-]groove with addressing
|
|
information modulated into it. This makes it possible to resume
|
|
interrupted [or deliberately suspended] burning process with accuracy
|
|
high enough for DVD[-ROM] player not to "notice" anything at
|
|
playback time. Recovery from buffer underrun condition in DVD-RW/-R
|
|
case in turn is way less accurate procedure, and the problem is that
|
|
the provided accuracy is very much what average player can tolerate.
|
|
Now given that both provided and tolerated inaccuracies are
|
|
proportional to respectively writing and reading velocities there
|
|
basically no guarantee that DVD-RW/-R recording that suffered from
|
|
buffer underrun will be <I>universally</I> playable.</BLOCKQUOTE>
|
|
|
|
<P ALIGN="JUSTIFY">Well, it turned out that I was wrong about one
|
|
thing. <!--About projecting CD-R[W] buffer underrun recovery procedure
|
|
to DVD-R[W] to be specific.--> I failed to recognize that DVD-R[W]
|
|
groove also provides for <I>adequately</I> accurate recovery from
|
|
buffer underrun condition/lossless linking. Not as accurate as DVD+RW,
|
|
but accurate enough for splices to be playable in virtually any
|
|
DVD-ROM/-Video unit. Yet! When it comes to DVD-R[W] recording
|
|
specificaton apparently insists that you choose between
|
|
|
|
<UL>
|
|
<LI>buffer underrun protection and
|
|
<LI>full DVD-ROM/-Video compatibility.
|
|
</UL>
|
|
|
|
<P ALIGN="JUSTIFY">The specification asserts that the latter is
|
|
achieved only in Disc-at-once recording mode and only if data-stream
|
|
was maintained uninterrupted throughout whole recording. Once again.
|
|
Even though most vendors implement lossless linking in DAO
|
|
mode<SUP>(*)</SUP>, <I>full</I> DVD-ROM/-Video compatibility is
|
|
guaranteed only if recording didn't suffer from buffer underruns. The
|
|
problem is that "offended" sectors are denoted with certain
|
|
linking chunk appearing as degraded <I>user data</I>, few bytes, which
|
|
are supposed to be "corrected away" by ECC
|
|
procedure<SUP>(**)</SUP>. DVD+ splices are in turn only few bits large
|
|
and are "accounted" to sync patterns, <I>not to user data
|
|
area</I>. So that even if suffered from buffer underrun, DVD+ sector is
|
|
logically indistiguishable from DVD-ROM. Which is why it's commonly
|
|
referred to that DVD+RW/+R combine DVD-ROM/-Video compatibility with
|
|
[unconditional] buffer underrun protection.
|
|
|
|
<P ALIGN="JUSTIFY">As already mentioned, DVD+ groove has
|
|
"addressing information modulated into it," ADIP (ADress In
|
|
Pre-groove). This gives you an advantage of writing DVD+RW in truly
|
|
arbitrary order, even to virgin surface and practically instantly
|
|
(after ~40 seconds long initial format procedure). In addition, DVD+RW
|
|
can be conveniently written to with 2KB granularity<SUP>(***)</SUP>.
|
|
DVD-RW in turn can only be <I>overwritten</I> in arbitrary order.
|
|
Meaning that it either has to be completely formatted first (it takes
|
|
an hour to format 1x media), or initially written to in a sequential
|
|
manner. And it should also be noted that block overwrite is
|
|
<I>never</I> an option if DVD-RW media was recorded in [compatible]
|
|
Disc-at-once or even Incremental mode, only whole disc blanking is.
|
|
|
|
<P ALIGN="JUSTIFY">Unlike DVD-R[W], DVD+R[W] recordings can be
|
|
suspended at any time without any side effects. Consider following
|
|
scenario. You have a lot of data coming in [at lower rate], which is to
|
|
be recorded into one file. Meanwhile it turns out that you have to
|
|
retrieve previously recorded data. This would naturally require
|
|
suspention of recording. Most notably in DVD-R [and naturally DVD-RW
|
|
Sequential] case it would result in a hole in the file being recorded.
|
|
So called linking area, most commonly 32KB gap, has to be introduced.
|
|
So that you either have to wait till the file is complete or figure out
|
|
how to deal with holey files. Thanks to ADIP, DVD+R recording is
|
|
resumed from the very point it was suspended at. In DVD-RW Restricted
|
|
Overwrite case no gaps are introduced, but if the media was formatted
|
|
only minimally, suspension/resuming procedure has to be applied and it
|
|
takes ~40 seconds to perform one. In DVD+RW case, suspension/resuming
|
|
is instant regardless media state.
|
|
|
|
<P ALIGN="JUSTIFY">What does all of the above mean in practice? Well, I
|
|
was actually hoping that readers would [be able to] figure it out by
|
|
themselves. Apparently a couple of "guiding" words are
|
|
needed... It means that it's trivial to employ DVD+RW for housing of
|
|
live and arbitrary file system, no special modifications to target file
|
|
system driver are required... Real-time VBR (Variable Bit Rate) Video
|
|
recordings are children's game...
|
|
|
|
<P ALIGN="JUSTIFY">Sometimes DVD+RW/+R recording strategy is referred
|
|
to as packet writing. I myself am reluctant to call it so (or
|
|
TAO/SAO/DAO) for the following reason. Despite the fact that DVD-R[W]
|
|
provides for lossless linking (within a packet/extent only),
|
|
packets/extents are still denoted with certain linking information
|
|
which distinguishes it (recording mode in question) from e.g.
|
|
Disc-at-once. Now the point is that written DVD+RW/+R media, rather its
|
|
Data Zone, does not contain <I>any</I> linking information and is
|
|
logically indistinguishable from one written in DVD-R[W] Disc-at-once
|
|
mode (or DVD-ROM for that matter).
|
|
|
|
<P ALIGN="JUSTIFY">It's maintained that signal from DVD+ groove (the
|
|
one essential for recording, not reading) is much stronger, which makes
|
|
it quite resistant to dust, scratches, etc.
|
|
|
|
<P ALIGN="JUSTIFY">Now we can also discuss differences between
|
|
Double/Dual Layer implementations. DVD+R Double Layer permits for
|
|
arbitrary layer break positioning yet maintaining <I>contiguous logical
|
|
block addressing</I>. In other words address of the block following the
|
|
break is always address of the block preceding one plus 1, even for
|
|
arbitrarily positioned break. <NOBR>DVD-R</NOBR> Dual Layer on the
|
|
other hand implies unconditionally disjoint logical block addressing
|
|
[for arbitrarily positioned layer break that is]. This is because block
|
|
addresses as recorded by unit are pre-defined by <NOBR>DVD-dash</NOBR>
|
|
groove structure. In practice it means that file system layout has to
|
|
effectively have a hole, which "covers" twice the space between chosen
|
|
layer break position and outermost edge of the recordable area. And in
|
|
even more practical terms this means that mastering programs have to be
|
|
explicitly adapted for <NOBR>DVD-R</NOBR> layer break positioning.
|
|
Unlike DVD+plus that is.
|
|
|
|
<P>
|
|
<TABLE BORDER="0" WIDTH="95%" ALIGN="CENTER">
|
|
<TR VALIGN="TOP" ALIGN="JUSTIFY">
|
|
<TD><FONT SIZE="-1"><SUP>(*)</SUP></FONT>
|
|
<TD><FONT SIZE="-1">According to <A
|
|
HREF="ftp://ftp.avc-pioneer.com/Mtfuji_6/Spec/">Mt. Fuji draft</A>
|
|
buffer underrun protection is not even an option in DVD-R DAO: "If a
|
|
buffer under-run occurs, the logical unit <B><I>shall</I></B> stop
|
|
writing immediately and the logical unit <B><I>shall</I></B> start
|
|
writing of Lead-out." Protection is defined in Incremental Sequential
|
|
mode and DVD-RW context. By the way, note that earlier versions of this
|
|
draft also discuss DVD+RW. You should be aware that they refer to
|
|
abandoned version which has very little to do with DVD+RW/+R
|
|
implementation being discussed here.</FONT></TR>
|
|
<TR VALIGN="TOP" ALIGN="JUSTIFY">
|
|
<TD><FONT SIZE="-1"><SUP>(**)</SUP></FONT>
|
|
<TD><FONT SIZE="-1">ECC redundancy does permit for more degradation,
|
|
more that this linking chunk that is, so that it hadly affects the
|
|
playability.</FONT></TR>
|
|
<TR VALIGN="TOP" ALIGN="JUSTIFY">
|
|
<TD><FONT SIZE="-1"><SUP>(***)</SUP></FONT>
|
|
<TD><FONT SIZE="-1">DVD "native" block size is 32KB, and 2KB
|
|
granularity is nothing but a trick, but you're excused from playing it,
|
|
i.e. reading 32KB, replacing corresponding 2KB and writing 32KB
|
|
back.</FONT></TR>
|
|
</TABLE>
|
|
|
|
<P><HR>
|
|
|
|
<SPACER TYPE="block" WIDTH="100%" HEIGHT="100%">
|
|
|
|
</BODY>
|
|
</HTML>
|