rpms/dvd+rw-tools/devel dvd+rw-tools-7.0.manpatch, NONE, 1.1 dvd+rw-tools.spec, 1.25, 1.26 index.html, 1.1, 1.2 dvd+rw-tools-5.17.4.8.6.manpatch, 1.2, NONE
fedora-cvs-commits at redhat.com
fedora-cvs-commits at redhat.com
Tue Feb 27 12:59:38 UTC 2007
Author: harald
Update of /cvs/dist/rpms/dvd+rw-tools/devel
In directory cvs.devel.redhat.com:/tmp/cvs-serv27297
Modified Files:
dvd+rw-tools.spec index.html
Added Files:
dvd+rw-tools-7.0.manpatch
Removed Files:
dvd+rw-tools-5.17.4.8.6.manpatch
Log Message:
- fixed specfile issues (#209985)
--- NEW FILE dvd+rw-tools-7.0.manpatch ---
diff -ur dvd+rw-tools-7.0/Makefile.m4 dvd+rw-tools-7.0-manpatch/Makefile.m4
--- dvd+rw-tools-7.0/Makefile.m4 2006-09-24 19:55:19.000000000 +0200
+++ dvd+rw-tools-7.0-manpatch/Makefile.m4 2006-10-09 10:44:31.000000000 +0200
@@ -191,7 +191,7 @@
LINK.o =$(LINK.cc)
prefix?=/usr/local
-manprefix?=$(shell case $(prefix) in (*/usr/?*) echo $(prefix)/man ;; (*) echo $(prefix)/share/man ;; esac)
+mandir?=$(shell case $(prefix) in (*/usr/?*) echo $(prefix)/man ;; (*) echo $(prefix)/share/man ;; esac)
bin_mode?=0755 # yes, default is *no* set-uid
minus_o:=$(shell [[ `id -u` == 0 ]] && echo "-o root")
@@ -199,10 +199,10 @@
install: dvd+rw-tools
[[ -d $(prefix)/bin ]] || mkdir -p $(prefix)/bin
install $(minus_o) -m $(bin_mode) $(CHAIN) $(prefix)/bin
- [[ -d $(manprefix)/man1 ]] || mkdir -p $(manprefix)/man1
- install $(minus_o) -m 0644 growisofs.1 $(manprefix)/man1
- -[[ -f rpl8 ]] && install $(minus_o) -m $(bin_mode) rpl8 $(prefix)/bin; :
- -[[ -f btcflash ]] && install $(minus_o) -m $(bin_mode) btcflash $(prefix)/bin; :
+ [[ -d $(mandir)/man1 ]] || mkdir -p $(mandir)/man1
+ install $(minus_o) -m 0644 growisofs.1 $(mandir)/man1
+ -[[ -f rpl8 ]] && install $(minus_o) -m $(bin_mode) rpl8 $(prefix)/bin || :
+ -[[ -f btcflash ]] && install $(minus_o) -m $(bin_mode) btcflash $(prefix)/bin || :
])
# common section
Index: dvd+rw-tools.spec
===================================================================
RCS file: /cvs/dist/rpms/dvd+rw-tools/devel/dvd+rw-tools.spec,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- dvd+rw-tools.spec 14 Dec 2006 17:35:44 -0000 1.25
+++ dvd+rw-tools.spec 27 Feb 2007 12:59:35 -0000 1.26
@@ -1,16 +1,17 @@
Summary: Toolchain to master DVD+RW/+R media
Name: dvd+rw-tools
Version: 7.0
-Release: 2%{dist}
+Release: 2%{?dist}
License: GPL
Group: Applications/Multimedia
Source: http://fy.chalmers.se/~appro/linux/DVD+RW/tools/dvd+rw-tools-%{version}.tar.gz
Source1: index.html
Patch1: dvd+rw-tools-7.0-phys.patch
Patch2: dvd+rw-tools-7.0-pthread.patch
+Patch3: dvd+rw-tools-7.0.manpatch
URL: http://fy.chalmers.se/~appro/linux/DVD+RW/
Requires: mkisofs >= 2.0
-BuildRoot: %{_tmppath}/%{name}-root
+BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildRequires: kernel-headers m4
%description
@@ -21,43 +22,44 @@
%setup -q -n %{name}-%{version}
%patch1 -p1 -b .phys
%patch2 -p1 -b .pthread
+%patch3 -p1 -b .manpatch
%build
export CFLAGS="$RPM_OPT_FLAGS"
export CXXFLAGS="$RPM_OPT_FLAGS"
-make WARN="-DDEFAULT_BUF_SIZE_MB=16 -DRLIMIT_MEMLOCK"
-cp %SOURCE1 index.html
+make WARN="-DDEFAULT_BUF_SIZE_MB=16 -DRLIMIT_MEMLOCK" %{?_smp_mflags}
+
+cp -p %SOURCE1 index.html
%install
rm -rf %{buildroot}
%makeinstall
-mkdir -p %{buildroot}%{_docdir}/%{name}-%{version}-%{release}
-cp -a index.html \
- %{buildroot}%{_docdir}/%{name}-%{version}-%{release}
-
%clean
rm -rf %{buildroot}
%files
%defattr(-,root,root)
%{_prefix}/bin/*
-%doc %{_docdir}/%{name}-%{version}-%{release}
+%doc index.html LICENSE
%{_mandir}/man1/growisofs.1*
%changelog
-* Thu Dec 14 2006 Harald Hoyer <harald at redhat.com> - 7.0-0%{dist}.4
+* Tue Feb 27 2007 Harald Hoyer <harald at redhat.com> - 7.0-2%{?dist}
+- fixed specfile issues (#209985)
+
+* Thu Dec 14 2006 Harald Hoyer <harald at redhat.com> - 7.0-0%{?dist}.4
- set pthread stack size according to limit (#215818)
-* Wed Dec 13 2006 Harald Hoyer <harald at redhat.com> - 7.0-0%{dist}.3
+* Wed Dec 13 2006 Harald Hoyer <harald at redhat.com> - 7.0-0%{?dist}.3
- use _SC_PHYS_PAGES instead of _SC_AVPHYS_PAGES to determine available memory
- Resolves: rhbz#216794
-* Fri Nov 03 2006 Harald Hoyer <harald at redhat.com> - 7.0-0%{dist}.2
+* Fri Nov 03 2006 Harald Hoyer <harald at redhat.com> - 7.0-0%{?dist}.2
- define RLIMIT_MEMLOCK, which should resolve the memlock problems
-* Thu Oct 26 2006 Harald Hoyer <harald at redhat.com> - 7.0-0%{dist}.1
+* Thu Oct 26 2006 Harald Hoyer <harald at redhat.com> - 7.0-0%{?dist}.1
- new version 7.0
* Wed Jul 12 2006 Jesse Keating <jkeating at redhat.com> - 6.1-4.1
Index: index.html
===================================================================
RCS file: /cvs/dist/rpms/dvd+rw-tools/devel/index.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- index.html 18 Nov 2004 15:57:02 -0000 1.1
+++ index.html 27 Feb 2007 12:59:35 -0000 1.2
@@ -2,15 +2,17 @@
<HEAD>
<BASE HREF="http://fy.chalmers.se/~appro/linux/DVD+RW/">
-<TITLE>DVD+RW/+R/-R[W] for Linux</TITLE>
-<META NAME="keywords" CONTENT="dvd, recording, burning, rewritable,
+<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 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,
- multi-session, growisofs">
-<META NAME="description" CONTENT="DVD+RW/+R/-R[W] support for Linux, NetBSD, Solaris, FreeBSD, HP-UX:
+ 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">
@@ -24,10 +26,11 @@
<P><HR>
<TABLE><TR>
<TD WIDTH="100%">
-<H1 ALIGN="CENTER"><A HREF="http://www.dvdplusrw.org/">DVD+RW</A>/+R/<A
+<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 at fy.chalmers.se>,
-August 2004</H5>
+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>
@@ -41,9 +44,9 @@
<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 DVD±RW/±R,
- things like backup, archiving, data exchange... The
- downloadable files are an <I>optional</I> <A
+ 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>.
@@ -65,22 +68,24 @@
<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 cdrecord?
+ 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 DVD recording
+ 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 cdrecord, DVD+RW/+R recording strategies are somewhat
- different from the one supported by cdrecord, so it simply
- doesn't work (nor does dvdrecord<A
- HREF="http://www.freesoftware.fsf.org/dvdrtools/">,</A> despite
- what <A
+ 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).</TR>
+ 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>
@@ -88,15 +93,16 @@
<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) 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
+<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
@@ -107,13 +113,14 @@
<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 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
+<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.
@@ -123,7 +130,7 @@
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 DVD media.</TR>
+ image to) all supported optical media.</TR>
</TABLE>
<P><TABLE CELLPADDING=4>
@@ -136,15 +143,15 @@
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 some unique quality, such as
- "seamless" multi-sessioning, not as reference to some
+ 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://www.fokus.fhg.de/research/cc/glone/employees/joerg.schilling/private/cdrecord.html">cdrtools</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
@@ -175,7 +182,7 @@
<P><TABLE CELLPADDING=4>
<TR VALIGN="top" ALIGN="justify">
-<TH>Q. <TH ALIGN="left">Does it work with <I>my</I> DVD burner?
+<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
@@ -185,16 +192,18 @@
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 [but not limited to] <NOBR>HP
+ 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-[12]xx0,</NOBR> <NOBR>TDK indiDVD 4x0N,</NOBR>
+ 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-[48]x1S,</NOBR>
- as well as <A HREF="-RW/">nonplus</A> units such as
- <NOBR>Pioneer DVR-x0[4567],</NOBR> <NOBR>LG GxA-40[248]x,</NOBR>
- <NOBR>Toshiba SD-R[56]112,</NOBR> <NOBR>Panasonic UJ-811</NOBR>
- and <NOBR>LF-D[35]1x...</NOBR></TR>
+ <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>
@@ -231,7 +240,8 @@
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.
+ 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">
@@ -261,15 +271,7 @@
<P><HR>
-<H3>Foreword/Disclaimer</H3>
-
-<P ALIGN="JUSTIFY">Given the absolute lack of initial support from
-vendor(s) dvd+rw-tools arose from guesswork. There still is a couple of
-fatal failures indicated by vendor-specific error codes (see Technical
-Ramblings) and I haven't <I>yet</I> figured out the way around them in
-kernel. <NOBR>User-land</NOBR> utilities on the other hand are
-considered matured enough to be deployed in "production
-environment."
+<H3>Foreword</H3>
<P ALIGN="JUSTIFY">As of May 2003 I've decided to advise users to
<B>turn to <<A
@@ -301,6 +303,9 @@
<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>
@@ -364,7 +369,7 @@
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 might be specific to
+switching it off reportedly helps. The problem appears to be specific to
some IDE chipsets...</FONT>
</TR>
</TABLE>
@@ -372,16 +377,17 @@
<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> storage devices
-of any kind 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 CD-ROM <I>and</I> CD-R[W] burner, then you won't
-have any troubles with DVD recording part. 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+RW 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.
+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>.
@@ -444,75 +450,53 @@
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"><B>If you have 1st generation drive</B> (Ricoh
-MP5120A and derivatives, see <A
-HREF="http://www.dvdplusrw.org/">dvdplusrw.org</A> for generation
-listings), do consider upgrading your firmware (see <A
-HREF="http://ext.ricoh.co.jp/dvd/asia/support/download/mp5120a/">Ricoh</A>
-page for latest version information). Fixed bug descriptions are vague,
-but at the very least after upgrade to 1.34 I could no longer reproduce
-infrequent "random positioning errors" when <I>reading</I> a
-file system with a lot of small files. 1.34 adds support for Verbatim
-media and 1.37 apparently for Memorex. Version 1.37 also implements a
-secret vendor-specific command which <A HREF="#booktype">reportedly
-improves compatibility</A> with a number of DVD-ROM drives (more about
-this matter in Technical Ramblings). <!--So for whatever it's worth do
-consider upgrading...-->
-
-<P ALIGN="JUSTIFY">Several 2nd generation unit (<A
-HREF="http://ext.ricoh.co.jp/dvd/asia/support/download/mp5125a/">Ricoh
-MP5125A</A> and derivatives) users have reported that their systems
-lock up the while recording DVD+R, but not DVD+RW. I myself have never
-experienced anything similar, but firmware upgrade did help those who
-has suffered from this. So that apparently even 2nd generation users
-should be considering firmware upgrade. Firmware upgrade is actually
-required if you want to burn 4x media in your 2nd generation unit.
-Well, it will still burn it at 2.4x, but without firmware upgrade you
-should expect deplorable results.
-
-<P ALIGN="JUSTIFY">As new media products and brands are being
+<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> It's not as
-simple as "1st" vs. "2nd generation" units anymore,
-so turn to your vendor to be sure. 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-4]00*.exe</TT></NOBR> files in <A
+<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 DVD+RW media.</B> Virgin
-DVD+RW media needs to be initally formatted prior usage. Once again,
-<B>only virgin 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>. To make formatting
-process reasonably fast, less than 1 minute, the media gets formatted
-only partially, as you can notice by observing a 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 are salesman's GB, i.e. 1000<SUP>3</SUP> and
-not 1024<SUP>3</SUP>.
+<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
-media unusable already after 10-20 reformats. It appears to be a
+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. Note that
-DVD+RW <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.
+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.
+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
@@ -520,7 +504,7 @@
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 multi-session related
+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
@@ -535,7 +519,7 @@
</UL>
<P ALIGN="JUSTIFY">Otherwise <I>everything</I> that applies to
-[multi-session] mastering with mkisofs applies to growisofs as well. For
+[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.:
@@ -549,7 +533,7 @@
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>
-multi-session backups, then you shall find <A
+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.
@@ -561,11 +545,12 @@
comparison between increments as well as fine-graded restore.
<P ALIGN="justify">Number of users asked about opposite to
-multi-sessioning: multi-volume support. Being essentially a recording
+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.webframe.org/main_eng.html">scdbackup</A> and <A
-HREF="http://www.serice.net/shunt/">shunt</A>. But back to growisofs...
+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
@@ -587,7 +572,7 @@
dumpsomething | growisofs -Z /dev/scd0=<FONT COLOR="red">/dev/fd/0</FONT>
</PRE></BLOCKQUOTE>
-<P ALIGN="JUSTIFY">Burning DVD±R implies extra limitations:
+<P ALIGN="JUSTIFY">Burning BD-R/DVD±R implies extra limitations:
<P><UL>
@@ -603,7 +588,7 @@
<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
-multi-border playback, even fewer support DVD+R multi-sessioning. In
+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.
@@ -613,31 +598,38 @@
work it around by reloading corresponding driver, most likely
'<TT>rmmod sr_mod</TT>'.
-<LI>Linux kernel 2.6 users might experience <A
+<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 multi-session media</A> with last session starting beyond
+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
+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 DVD±R multi-sessioning, you have to use
+<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 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>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, <NOBR>DVD±R[W]</NOBR>
-capacity is not larger than 4.4GB! It should also be noted that earlier
+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
@@ -767,17 +759,18 @@
the optical head some place, picking up the signal and noting the
physical block address underneath the lens. In order for this procedure
to work with re-writable/recordable media, that particular spot has to
-be written to [or de-iced in DVD+RW case]. Some units slide the head to
+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 DVD-ROM unit].
+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 dvd+rw-format [apparently] doesn't have any
-lead-out, not to mention that practically whole surface remains virgin.
-If you fail to mount/play DVD+RW media, attempt to
+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>
@@ -790,14 +783,14 @@
that my hp dvd200i unit doesn't wipe any data when relocating the
lead-out.-->
-<P ALIGN="JUSTIFY">Then non-finalized DVD+R and Sequential DVD-R[W]
-discs don't have lead-out either<SUP>(*)</SUP>. If you fail to
-mount/play DVD+R media and wish to sacrifice the remaining space for
-immediate compatibility, just fill the media up<SUP>(**)</SUP>.
-Alternatively if you master volume in a single take and don't plan to
-use it for multi-sessioning<SUP>(***)</SUP>, you have the option to
-invoke growisofs with <TT>-dvd-compat</TT> option and cut the real
-lead-out directly after the first session.
+<P 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">
@@ -809,7 +802,7 @@
of the largest media sector, which makes affected DVD[-ROM] players
calibrate at the outermost edge instead of the first session. Actually
I fail to understand why don't they burn the address of last sector of
-the first session in the lead-in even on multi-session discs...
+the first session in the lead-in even on multisession discs...
</FONT></TR>
<TR VALIGN="TOP" ALIGN="JUSTIFY">
@@ -845,13 +838,13 @@
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 DVD-ROM 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
+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
@@ -882,17 +875,18 @@
recognized. Well, it's actually understandable as it's the only one
that can be recognized and addressed by a DVD+RW vendor alone.
Recognition of other incompatibilities would require cooperation from
-DVD[-ROM] player vendors and that's something they apparently are not
-willing to show referring to the fact that DVD+RW format is not
-approved [and apparently never will be] by <A
+<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 DVD-ROM
-"Book Type" is virtually identical to DVD-ROM.</FONT></TR>
+<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
@@ -907,14 +901,14 @@
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 DVD[-ROM] vendors it's not possible to distinguish
-physical from logical format incompatibility, which I find important to
-tell apart in order to make sure at least logical format
+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 DVD-ROM. Now the catch is that the linear
-pit density in turn is same as of single-layer one. Meaning that if
-player makes assumptions about linear pit density based on
+reflectivity 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...
@@ -928,8 +922,8 @@
<A NAME="isofs4gb"><P><IMG SRC="isofs4gb.gif" WIDTH=144 HEIGHT=315
ALIGN="RIGHT"></A>
-<P ALIGN="JUSTIFY"><B>As for multi-session ISO9660 [DVD]
-recordings!</B> Unfortunately, Linux ISOFS implementation has certain
+<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
@@ -947,20 +941,23 @@
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</I> the
-maximum interoperability, you should <B>not let any session
+"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
+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 recordings.
+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">
@@ -981,16 +978,20 @@
<P ALIGN="JUSTIFY"><B>Why media reload is performed after every
recording with growisofs?</B> Well, it's performed only if you didn't
-patch the kernel:-) But no, I'm not insisting on patching the kernel!
+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 reason. In order to optimize file access
+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 to flush/resync the block cache.
+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>
@@ -1167,28 +1168,29 @@
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 you
-apparently have to choose between
+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 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 achieved 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">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
@@ -1224,8 +1226,8 @@
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.
+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
@@ -1242,17 +1244,36 @@
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_5/Spec/">Mt. Fuji draft</A>
-buffer underrun protection is not even an option in DVD-R DAO. It's
-defined in Incremental Sequential mode and DVD-RW context. By the way,
-note that this draft also discusses 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>
+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,
--- dvd+rw-tools-5.17.4.8.6.manpatch DELETED ---
More information about the fedora-cvs-commits
mailing list