index.html

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

<NOBR>DVD+RW</NOBR> specification, &quot;true random write with 2KB
granularity&quot; 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, &quot;FLUSH
CACHE&quot; might do the trick. Another one is that under
&quot;underrun&quot; condition background formatting kicks off and has
to be explicitly stopped. &quot;Underrun&quot; 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
&quot;underrun&quot; 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
&quot;writeable&quot; 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 &quot;what a dirty
hack!!!&quot; 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
&quot;the dirty hack&quot; 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 &quot;quiet&quot; 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 &quot;jiffies,&quot; which is a
<B>platform-dependent</B> value representing time elapsed between timer
interrupts. But if we attempt to send down &quot;jiffies,&quot; 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
&quot;jiffy,&quot; 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 &quot;deficiency&quot; 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 &quot;TEST UNIT READY&quot;] as
&quot;NO SENSE/LOGICAL UNIT NOT READY/FORMAT IN PROGRESS&quot; sense
bytes but with &quot;GOOD&quot; status. Apparently any sense data with
&quot;GOOD&quot; status is discarded by the common SCSI layer.

<!--
<P ALIGN="JUSTIFY">As you might have noticed the time-out value for
&quot;CLOSE SESSION&quot; 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
&quot;finalize&quot; 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 &quot;notice&quot; 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 &quot;offended&quot; sectors are denoted with certain
linking chunk appearing as degraded <I>user data</I>, few bytes, which
are supposed to be &quot;corrected away&quot; by ECC
procedure<SUP>(**)</SUP>. DVD+ splices are in turn only few bits large
and are &quot;accounted&quot; 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
&quot;addressing information modulated into it,&quot; 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 &quot;guiding&quot; 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 &quot;native&quot; 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>