Re: Announcing cdrskin-0.7.2

[D. Hugh Redelmeier]

| From: Thomas Schmitt 

| Some of my own experiments yielded surprising
| setbacks. E.g. i replaced
|gfpow[44 - i]
| by
|h45[i]
| with a suitable constant array h45[].
| This was 7 percent slower !
| (I suspect a less fortunate cache situation.)

Right.  gcc can fold the constant 44 into indexing.  You might have
saved a unary - operation, but I don't know.  But, as you suggest, an
extra burden on a cache may be a problem.

Even worse: the price of a cache burden depends on the CPU's cache
implementation and size so testing on one machine does not give a fair
overview of performance on other machines.

| > In burn_rspc_div, you return -1 if the division is by 0.
| 
| This has been replaced by a specialized
| burn_rspc_div_3() which divides by (x^1+1).
| Less ifs, less array lookups, but no speed-up:
| 
| /* Divides by polynomial 0x03. Derived from burn_rspc_div() */
| static unsigned char burn_rspc_div_3(unsigned char a)
| {
| if (a == 0)
| return 0;
| if (gflog[a] >= 25)
| return gfpow[gflog[a] - 25];
| else
| return gfpow[230 + gflog[a]];
| }  

Given that gfpow is doubled, this code should be faster and simpler:

| {
| if (a == 0)
| return 0;
| /* Note: gflog(x^1 + x^0) == 25 */
| return gfpow[(255 - 25) + gflog[a]];
| }  

I think that 0x03 has a multiplicative inverse too.  This would allow
a division to be replaced by a multiplication.

Since fglog(0x03) is 25, the multiplicative inverse ought to have a
gflog of -25 == 230.  It turns out that gflog(244) == 230 so 244 ==
0xF4 appears to be the multiplicative inverse.  It surprises me that
0xF4 + 0x03 == 0xFF (for either kind of +!).

So, not too surprisingly, 255-25 could be replaced by 0+230.  No
advantage, just interesting.  It still requires the gfpow table to be
doubled.

| I trust in gcc -O2 that it handles the double
| lookup of gfpow[a] properly.

Probably.

| The code swallowed far more obvious workload
| improvements without showing speed reactions.

Right.  I'm shooting in the dark given that I'm not testing let alone
measuring.

| 
| 
| I see some potential in parallelization.
| We have at least 32 bit for exor operations.
| There are two neighbored bytes multiplied by
| the same byte simultaneously.
| 
| But already now a 1000 MHz CPU can easily feed
| a 48x CD stream. I am not aware of faster CD
| media. And this stuff is for CD only.

OK.

Any further improvement should probably be guided by measuring for hot
spots.


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org

Re: Announcing cdrskin-0.7.2

[D. Hugh Redelmeier]

| From: Thomas Schmitt 

| I have to correct myself:
| > I.e. the indice of the power and log table
| > represent natural numbers, not polynomials.
| 
| The indice of the power table are natural
| numbers, the indice of the log table
| are polynomials.

Thanks for your very useful explanations.

The logs are whole numbers.  I was taught that 0 is not included in
natural numbers.  This is a matter of dispute among mathematicians;
see the first paragraph of:
http://en.wikipedia.org/wiki/Natural_number

As you explained elsewhere, they are actually the integers mod 255.

As such, your original gfpow table should have had a size of
255 elements, not 256.  Your initializer only initialized 255, leaving
the last (unused) element to be implicitly initialized with 0.  In
fact, no entry of gfpow should be 0 because no power of x is 0.
Luckily, that wrong entry would never be used.

| One has to unroll the table gfpow[] up to 511
| elements because the highest sum of two gflog[]
| elements is 510.

The smallest log is 0.  The largest is 254 (not 255).  So
the range of sums of pairs of logs is [0-508].  So you actually need
only 509 elements in the expanded table.

It seems easier to just double the table of 255 elements to 510
elements.



I'm glad that eliminating the % made a significant speedup.

That leads me to wonder about a different idea that might or
might not cause a speedup.

In burn_rspc_mult:
453if (a == 0 || b == 0)
454 return 0;

On most modern machines, branches are slow.  This test requires two
branches.  So it might be faster to use "|" in place of "||" because
only one branch would be required.

That depends on the compiler knowing how to calculate == without
branching.

If the compiler is not smart enough, this test should do the same job:
((a + 0xFF) & (b + 0xFF) & 0x100) == 0
Explanation: a + 0xFF will have the 0x100 bit on UNLESS a was zero.
The result of the first & will have that bit on unless either a or b
was zero.

So would this:
((a - 1) | (b - 1)) < 0
Explanation: a - 1 will be less than 0 if and only if a was 0.  The result of
the | will be negative if and only if one of its operands was negative.

This second test won't work on a class of machines that I've never
seen: ones where sizeof(unsigned char) == sizeof(int).  Why?  Because
C's promotion rules mean that a - 1 on such a machine would be done in
type unsigned int, and thus the result could never become negative.
(Actually, some compilers from before the C Standard have this
too.)

Here is a more bullet-proof version of the second test:
(((int)a - 1) | ((int)b - 1)) < 0

As you can see, these tricky tests require several extra operations to
save a branch.  I would expect that to be faster on most modern
processors but I have not tested this.



In burn_rspc_div, you return -1 if the division is by 0.
-1 isn't really a nice unsigned char value.

Do you know if this case ever comes up?  If it "should" not, for some
values of "should", perhaps the function could abort instead.

467 d = gflog[a] - gflog[b];
468 if (d < 0)
469 d += 255;
470 return gfpow[d];

Now that you have the doubled table, I guess that this could be
rewritten as:

return gfpow[gflog[a] - gflog[b] + 255];



Looking at next_bit().  These comments are REALLY unimportant.

- is there any reason that the & 0x3fff is needed?  How would the
  0x8000 bit get set?

- should the type of the result of next_bit (and ret) be unsigned
  short?

673 ecma_130_fsr = (ecma_130_fsr >> 1) & 0x3fff;
674 if (ret ^ (ecma_130_fsr & 1))
675 ecma_130_fsr |= 0x4000;

ecma_130_fsr >>= 1;
ecma_130_fsr |= (ret ^ (ecma_130_fsr & 1)) << 14
Simpler?



Several functions unconditionally return 1.  For example
burn_rspc_p0p1.  In that case at least, the caller ignores the result.
Why not define the function with a return type of "void"?


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org

Re: Announcing cdrskin-0.7.2

[D. Hugh Redelmeier]

| From: Thomas Schmitt 

| A new source module ecma130ab was committed
| to libburn SVN yesterday.

Sounds good.

| I would appreciate if you had a look at the
| explanations at lines 8 to 115 whether you find
| any mistakes or gaps.
|   http://libburnia-project.org/browser/libburn/trunk/libburn/ecma130ab.c

I'm not really qualified to do a good audit.  And I was too lazy to
chase down all references.  From what I could tell, it looked good.

I don't understand the multiplication by logarithms (again, I haven't
looked it up).  Why are the two logs added as integers (+) rather than
as polynumials (^)?  Why do you do % 255 rather than 256?  Note that
the gfpow table has 256 entries.  I do know that 0 has no log.

If you double the gfpow table's size you could elminate the % 255.  I
would guess that this would increase the speed.  I don't know if
multiplication takes a significant percentage of the time.

(I ran out of time after reading the first function!)

Does ECMA provide any "test vectors" for you to test your code with?
Unit tests might be very useful!


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org

Re: Announcing cdrskin-0.7.2

[D. Hugh Redelmeier]

| From: Joerg Schilling 

| I am not shure whether you know that you are responding to a social problem.

I certainly see a nasty tone on this message.

I'm not going to judge who is right and who is wrong.  This is a long
conflict, as far as I know.

My humble suggestion: everyone should tone the rhetoric.  Surely all
the points have already been made.  Continued sniping reflects badly
on everyone.

As a user, I'm thankful for Joerg *and* everyone else who has helped
to develop this code.


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org

Re: Announcing cdrskin-0.7.2

[D. Hugh Redelmeier]

| From: Thomas Schmitt 
| Do you know by chance a smart student who can
| contribute an implementation or explanation of
| ECMA-130 Annex A ?
| 
| "The RSPC is a product code over GF(28) producing
|  P- and Q-parity bytes. The GF(28) field is
|  generated by the primitive polynomial
|  P(x) = x8 + x4 + x3 + x2 + 1
|  The primitive element a of GF(28) is
|  a = (0010) where the right-most bit is the
|  least significant bit.
|  [...]
| "
| The words "RSPC" and "P- and Q-parity bytes"
| belong to the CD sector format specs. But the
| others must be established mathematic terms.
| (How is this connected to a Fourier
|  transformation of the bit sequence on time
|  domain ? Urgh ! Analysis ! On a finite set !)

I am not a mathematician.

I'd guess that this is really GF(2^8).  GF stands for Gallois Field.
Gallois Fields have size p^m where p is a prime (in our case, 2).

Ahh.  The standard confirms this:
  http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-130.pdf

Thus all elements of GF(2^8) would be polynomials of degree 7 or less.
The coefficients are from the integers mod 2 and thus any polynomial
in this field can be represented as 8 bits.

The primitive polynomial would be:
P(x) = x^8 + x^4 + x^3 + x^2 + x^0

See http://en.wikipedia.org/wiki/Finite_field

RSPC seems to be Reed-Solomon Product-like Code.  See
  http://en.wikipedia.org/wiki/Finite_field

>From that article, it looks as if the discrete Fourier transform you
require can be done by a cook book method:
  http://en.wikipedia.org/wiki/Berlekamp-Massey_algorithm

I admit that I'm shooting from the hip here.  But it seems as if the
internet has enough information to get to a solution.


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org

Re: growisofs should have a method for padding

[D. Hugh Redelmeier]

| From: Patrick Ohly <[EMAIL PROTECTED]>
| Date: Tue, 24 May 2005 22:16:34 +0200

| On Thu, 2005-05-12 at 01:26 -0400, D. Hugh Redelmeier wrote:
| > The conventional work-around is to always pad when writing a CD/DVD.
| > Ugly, but true.  (I agree that this isn't the correct fix, but the
| > problem has not been fixed in a year, so it isn't going away soon.)
| 
| As a matter of fact, for CDs it is exactly the right solution. As
| discussed on this list in April 2000 under the subject "Reading out
| data CDs" (not sure whether any public archive has those emails),
| the Yellow Book standard for data CDs requires data tracks to end
| in 150 empty blocks (300KB).

That thread seems to be:
http://groups.google.ca/group/mailing.comp.cdwrite/browse_frm/thread/ab41402747ff62af/568f34f142e706bd?tvc=1&q=%22reading+out+data+cds%22&hl=en#568f34f142e706bd
Your message (number 10) seems relevant, but the padding is expressed
in seconds, so I'm not 100% convinced that it applies to data.

I tested Fedora Core 4 binary .iso files and found that each ended in
601 or 602 blocks of 512 zeros.  This seems consistent with what you
say.

| Therefore a CD writing file system is allowed to read ahead up to
| 150 blocks after the end of the last block with real data
| and should not run into read errors there. How it should handle
| read errors is a different question, but it doesn't change the fact
| that it only occurs with broken CDs or when reading valid CDs
| beyond the end of the last block with user data.

It also happens when software tries to find the whole (raw) content of
the .iso file on the raw cdrom.  When does this happen?

- when trying to duplicate a CD

- when trying to compare a CD with a .iso

- When trying to compute a cryptographic hash of the contents of a CD.
  k3b seems to do this.  So do various check-before-installing codes.

So it still seems wise to add padding beyond the length of the .iso
file.

Here is my quicky script to count the blank blocks at the end of a
.iso file.  I realize that the zeros ought to be in sectors of 2048
bytes, but checking in units of 512 seemed a little more informative.

 isozeros script 
# isozeros: test for zero blocks at end of .iso

set -e -u

bs=512

for fn
do
sz=`isosize "$fn"`
szb=`expr $sz / $bs`
i=$szb
while [ $i -ge 1 ]
do
i=`expr $i - 1`
if ! dd if="$fn" skip=$i bs=$bs count=1 2>/dev/null | cmp 
--bytes $bs - /dev/zero
then
i=`expr $i + 1`
break
fi
done
echo "$fn has `expr $szb - $i` blocks of $bs bytes of zeros at the end"
done
 end 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: growisofs should have a method for padding

[D. Hugh Redelmeier]

| From: D. Hugh Redelmeier <[EMAIL PROTECTED]>
| Date: Thu, 12 May 2005 01:26:13 -0400 (EDT)

| The 2.6 kernel's CD/DVD driver has the unfortunate propensity to read
| ahead past the end of a CD/DVD.  It then reports an error, even if the
| actual read request was completely legitimate.  See, for example,
|   <https://www.redhat.com/archives/fedora-list/2005-March/msg02774.html>
| 
| The conventional work-around is to always pad when writing a CD/DVD.
| Ugly, but true.  (I agree that this isn't the correct fix, but the
| problem has not been fixed in a year, so it isn't going away soon.)
| See, for example,
|   <https://www.redhat.com/archives/fedora-list/2005-March/msg03201.html>

The variant of cdrecord shipped in Fedora Core 3 is calls itself
Cdrecord-Clone 2.01-dvd.  This burns coaster DVDs for me, but it does
have a nice --padsize option.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161021

growisof does not have a --padsize option :-(

Since copying a .iso takes a lot of time and space, I wrote a script
to alter a .iso in place.  It adds or removes padding in the amount I
think needed: 128k byes.  With a padded .iso, I don't need the
--padsize option.

 isopad script 
#!/bin/sh

# isopad [+] [-] isofile...
#
# The Linux IDE CD driver in 2.6 tries to read ahead, even past the end of the
# CD or DVD.  Even when the program issuing the original read request was only
# trying to read legitimate parts of the disc (albeit near the end).
# The result is spurious I/O errors and read failures.
# It does not seem that this driver bug is going to be fixed soon.
#
# This program is intended to facilitate a workaround.  It can pad (or unpad)
# a .iso file so that, when it is burned, the resulting disc will allow
# reads past the end of the content to succeed.
#
# "+" means pad the following .iso files.
# "-" means remove all padding.
# neither means test file and iso sizes.
#
# To see how much readahead is enabled on a drive: hdparm -a /dev/hdc
#
# Why do the padding in place, rather than on a copy of the file?
# .iso files are usually quite large so copying takes a lot of time and space.
#
# Copyright 2005 D. Hugh Redelmeier
# License: GPL
# Version: Sat Jun 18 02:31:48 EDT 2005

# stop at the least sign of trouble
set -u -e

# op is "", "-", or "+": operation to be performed
op=""

for fn
do
case "$fn"
in
"-h"|"--help")
echo "Usage: $0 [-|+|] isofile..."
;;
"+"|"-")
op="$fn"
;;
*)
isosize -x "$fn"
isz=`isosize "$fn"`
fsz=`stat --format='%s' "$fn"`

# conventional block size for CDs
bs=2048

# my guess at a sufficient amount of padding (in blocks)
pb=64

if [ $fsz -lt $isz ]
then
echo "$fn is shorter ($fsz) than it should be ($isz)" 
>&2
exit 3
elif [ ` expr $fsz % $bs ` -ne 0 ]
then
echo "$fn file size ($fsz) is not a multiple of $bs" >&2
exit 4
elif [ ` expr $isz % $bs ` -ne 0 ]
then
echo "$fn isosize ($isz) is not a multiple of $bs" >&2
exit 5
else
case "$op" in
"")
if [ $fsz -eq $isz ]
then
echo "$fn: isosize == file size == $fsz"
else
echo "$fn: isosize $isz; file size $fsz"
fi
;;
"+")
echo "$fn: padding with $pb blocks of $bs zero 
bytes"
dd if=/dev/zero bs=$bs count=$pb >>"$fn"
;;
"-")
if [ $fsz -eq $isz ]
then
echo "$fn: already $fsz bytes"
else
echo "$fn: truncating from $fsz to $isz 
bytes"
dd if=/dev/null of="$fn" seek=$isz bs=1
fi
;;
esac
fi
;;
esac
done
 end 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: growisofs should have a method for padding

[D. Hugh Redelmeier]

| From: [EMAIL PROTECTED]

| Are there really such errors with DVD now ?
| With CD there is an embarrassing tradition for that.

I'm not sure that it happens with a DVD.  I know it happens with CDs.
I would have expected that what was true of CDs would be true with
DVDs.

My one experiment (burning a DVD of Fedora Core 4 test 3 for x86_64)
with growisofs worked fine without padding.

| Did you already try something like this ?
| 
|   ( cat imagefile ; dd if=/dev/zero bs=2K count=150 ) | \
|   growisofs -use-the-force-luke -dvd-compat -Z /dev/sr0=/proc/self/fd/0

My (likely outdated) experience passing a CD-sized chunk of bytes over
a pipe was quite unpleasant.  It mad the system's performance quite
unpleasant.

| growisofs forwards options of mkisofs but not
| those of cdrecord. 
| mkisofs option -pad should be active by default
| but this padding is added to the image file.

Yeah, -pad is for mastering, but something like it could be added to
the Burning phase, I think.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: growisofs should have a method for padding

[D. Hugh Redelmeier]

| From: Volker Kuhlmann <[EMAIL PROTECTED]>

| Completely forget all your this-year's redhat references. This problem
| existed at least with kernels 2.2 and 2.4, and is probably as old as
| Linux (see references to it for kernels 1.3 in older mkisofs/cdrecord
| source around the -pad option). In 2.2 it didn't usually show, in 2.4 it
| was difficult to prevent.

I've not experienced it until 2.6.

I often read raw CDs to compare what is on the CD with a .iso file.

My recollection is that before 2.6, there was code to better guess the
size of a volume.  I was told this, so I don't know what form the code
took.

| Adding zeros to your image files doesn't change your checksums if you
| compute them properly, ie on the ISO image only. I've got scripts for
| all the above in my scriptutils package. It does damage any signatures
| though, there you ought to use padding with mkisofs.

I think that K3B does an md5sum of the disk, taking its idea of file
length from the drive.  This just does not work.

The md5sum command does not take a length argument, so you need to use
dd piped to md5sum, where the dd does the truncating.  My (long ago)
experience with this pipeline was quite unpleasant: I think that it busted 
the disk cache (as in: the cache was ineffective, not buggy).

| The default 20k padding was nowehre near enough on some DVD ISOs on 2.4.

Default for what?  -pad?  DVD mastering?

| I agree that it would be useful in growisofs. However a suitable wrapper
| script should fix it too.
| 
| > /usr/bin/growisofs: no mkisofs options are permitted with =, aborting...
| 
| Well, if that "=" is with -Z, then growisofs is told to burn an image,
| where you're already past mkisofs and therefore barfing on mkisofs
| options is a good thing as it may save you a coaster (and makes no sense
| either).

mkisofs, a mastering program, implements -pad/-padsize.  But I'm
proposing a second meaning: post-mastering padding.  Perhaps the
option name should be changed, but I think that the idea is useful.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

growisofs should have a method for padding

[D. Hugh Redelmeier]

The 2.6 kernel's CD/DVD driver has the unfortunate propensity to read
ahead past the end of a CD/DVD.  It then reports an error, even if the
actual read request was completely legitimate.  See, for example,
  

The conventional work-around is to always pad when writing a CD/DVD.
Ugly, but true.  (I agree that this isn't the correct fix, but the
problem has not been fixed in a year, so it isn't going away soon.)
See, for example,
  

growisofs can burn a pre-mastered image.  It would be nice if there was a 
way to ask it to add to this burn a specified amount of padding.

The only way I know of accomplishing it is to actually pad the image
file.  Not very elegant or convenient.  (It breaks any signature too.)

One suggestion: implement -pad and -padsize options.

When I try one of these, I get an error message:
/usr/bin/growisofs: no mkisofs options are permitted with =, aborting...
Not very clear.  Essentially, it means that some options are not
supported when growisofs is doing all the work itself.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: growisofs vs. LG GSA4040B: unable to CLOSE SESSION (5h/72h/03h):Input/output error

[D. Hugh Redelmeier]

| From: Andy Polyakov <[EMAIL PROTECTED]>

| > I was able to write a rewriteable disk, but k3b's verification failed :-(.
| > 
| > Any suggestons?
| 
| I don't know exact details about K3b verification procedure, but I know
| that verification becomes tricky if you try to rely on table of content
| to determine how much of burned data to verify. Turn to K3b people (the
| matter was discussed with them) or mount burned media and originating
| image and verify file by file, e.g. 'find . -type f -exec md5sum {} \;'.
| A.

Thanks.

I did a google on the message + k3b; the only hit was a .pot file
(message translation file).

I did a plain cmp command:
# cmp /dev/scd0 /space1/hugh/EJHR-toshiba.iso
cmp: EOF on /space1/hugh/EJHR-toshiba.iso
Although that is an error message, it is one that suggests success!

In other words, from the viewpoint of an cmp, all the bytes of the
.iso file were there.  The fact that the raw disk didn't have an EOF
at the end is neither surprising nor worrisome.

Hugh Redelmeier
[EMAIL PROTECTED]  voice: +1 416 482-8253


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: growisofs vs. LG GSA4040B: unable to CLOSE SESSION (5h/72h/03h):Input/output error

[D. Hugh Redelmeier]

| From: Andy Polyakov <[EMAIL PROTECTED]>

| > | > /dev/scd0: closing session
| > | > :-( unable to CLOSE SESSION (5h/72h/03h): Input/output error

| > Is this a forgivable flaw in the drive or is this an expected/legal
| > result on a standards-conforming drive?
| 
| Believed to be former.

Yuck.

| > If it is an expected/legal result, some part of the software ought to stop
| > scaring innocent users with drastic-sounding messages :-)
| 
| The problem is that the behaviour seem to vary from manufacturer to
| manufacturer. One tries to calm down LG user, some other might get a
| "heart attack":-) But sure, error message can [and eventually will] be
| complemented with "errors might be bogus" whenever dummy mode is
| chosen...

I wonder if we can get the manufacturer to fix this.  After all, they
do release upgraded firmware once in a while (even if the user needs
MS Windows to update the drive's firmware).

Can you point at a standard and say that this LG drive is violating it?  
If so, I (as a customer) am willing to try to report it as a bug.  Of
course it is a long way from a support person in Canada to an engineer in
Taiwan.

| > I find the undocumented growisofs -use-the-force-luke flag intriguing.
| > Is there a reason not to document it?
| 
| E.g. http://lists.debian.org/cdwrite/2003/cdwrite-200310/msg00034.html
| 
| But keep in mind that nothing is carved in stone. If enough users want
| to see it documented, then one is expected to step up and document it.
| If enough users want it to be called something else, then it will be
| called something else in next major release. But I expect these matters
| to be discussed openly. A.

Here is a bit of placeholder documentation.  Would you consider
adopting it?

I'm not confident that the description of -o is accurate.

I did find the option parsing a bit, uh, loose.
-use-the-force-luke=kitty
would be accepted as
-use-the-force-luke=tty

Hugh Redelmeier
[EMAIL PROTECTED]  voice: +1 416 482-8253

===
RCS file: RCS/growisofs.1,v
retrieving revision 1.1
diff -u -r1.1 growisofs.1
--- growisofs.1 2004/04/28 19:55:31 1.1
+++ growisofs.1 2004/04/28 21:50:50
@@ -93,6 +93,59 @@
 version 1.14, version 2.0 is required for multi-session write-once
 recordings.
 
+.SH MYSTERY OPTIONS
+Several options are so arcane or dangerous that we don't document them.
+They may be useful to crazy or brilliant users (or front-ends programs such as 
\fBk3b\fP).
+If you want to know what they do, read the source code.
+.TP
+.BI \-dry\-run
+.TP
+.BI \-prev\-session
+.TP
+.BI \-zero\-session
+.TP
+.BI \-poor\-man
+.TP
+.BI \-dvd\-compat
+.TP
+.BI \-overburn
+.TP
+.BI \-o\-
+restricted version of \fBmkisofs\fP -o
+.TP
+.BI \-dvd\-video
+.TP
+.BI \-cdrecord\-params n,m
+Same as \fBmkisofs\fP
+.BI \-C n,m
+.TP
+.BI \-#
+.TP
+.BI \-dry\-run
+.TP
+.BI \-?
+.TP
+.BI \-help
+.TP
+.BI \-version
+
+.TP
+.BI \-use\-the\-force\-luke
+.TP
+.BI \-use\-the\-force\-luke=tty
+.TP
+.BI \-use\-the\-force\-luke=dummy
+.TP
+.BI \-use\-the\-force\-luke=notray
+.TP
+.BI \-use\-the\-force\-luke=moi
+.TP
+.BI \-use\-the\-force\-luke=dao[[:|=] daosize ]
+.TP
+.BI \-use\-the\-force\-luke=tracksize[[:|=] tracksize ]
+.TP
+.BI \-use\-the\-force\-luke=seek[[:|=] next_session ]
+
 .SH EXAMPLES
 Actual device names vary from one operating system to another. We use
 \fI/dev/dvd\fP as a collective name or as symbolic link to the actual
 end 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: growisofs vs. LG GSA4040B: unable to CLOSE SESSION (5h/72h/03h):Input/output error

[D. Hugh Redelmeier]

| From: Andy Polyakov <[EMAIL PROTECTED]>

| > /dev/scd0: closing session
| > :-( unable to CLOSE SESSION (5h/72h/03h): Input/output error

| This error appears *only* in simulated mode and it does not mean that
| real recording will fail with same error. In other words failure to
| close the session is *limitation of simulated mode* and should be
| disregarded. Purpose of simulated test is rather to see if your system
| sustains the load.

Thanks for the explanation!

Is this documented anywhere?

Is this a forgivable flaw in the drive or is this an expected/legal
result on a standards-conforming drive?

If it is an expected/legal result, some part of the software ought to stop
scaring innocent users with drastic-sounding messages :-)


I find the undocumented growisofs -use-the-force-luke flag intriguing.
Is there a reason not to document it?

Hugh Redelmeier
[EMAIL PROTECTED]  voice: +1 416 482-8253


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

growisofs vs. LG GSA4040B: unable to CLOSE SESSION (5h/72h/03h): Input/output error

[D. Hugh Redelmeier]

[I hope that this message makes it to the list.  I'm not a subscriber,
even though I've asked twice to become one.]

I'm trying to burn a .iso image onto a DVD-R and not having much luck.
Probably user error: this is the second DVD I've ever tried to burn.

I created a .iso using k3b on Knoppix.  I *assume* that it is good.

I'm trying to burn it using k3b which really means grwoisofs.

I've tried simulated burns with a couple of blank DVD-Rs (two
different brands).  The result is the same:
/dev/scd0: closing session
:-( unable to CLOSE SESSION (5h/72h/03h): Input/output error

According to 
the SCSI error code means:
5  72  03   SESSION FIXATION ERROR - INCOMPLETE TRACK IN SESSION

The growisofs command that k3b uses is:

   /usr/bin/growisofs -Z /dev/scd0=/space1/hugh/EJHR-toshiba.iso \
-use-the-force-luke=notray -use-the-force-luke=tty \
-use-the-force-luke=dummy -speed=4

The "-user-the-force-luke" flag is not documented in the growisofs man
page.

Using -speed=2 did not improve the situation.

I was able to write a rewriteable disk, but k3b's verification failed :-(.

Any suggestons?

Hugh Redelmeier
[EMAIL PROTECTED]  voice: +1 416 482-8253


Environment:

- Fedora Core 1 + updates (Linux version 2.4.22-1.2174.nptl)

- k3b:
Qt: 3.1.2
KDE: 3.1.4-4 Red Hat
K3b: 0.11.9

- growisofs (used by k3b, I think):
* growisofs by <[EMAIL PROTECTED]>, version 5.13,
  front-ending to mkisofs: mkisofs 2.01a17 (i686-redhat-linux-gnu)

- LG GSA 4040B DVD writer.  hdparm says:
[EMAIL PROTECTED] hugh]# /sbin/hdparm -i /dev/hdc

/dev/hdc:

 Model=HL-DT-ST DVDRAM GSA-4040B, FwRev=A302, SerialNo=K2537C84607
 Config={ Fixed Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
 RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
 BuffType=unknown, BuffSize=0kB, MaxMultSect=0
 (maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio3 pio4
 DMA modes:  mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 *udma2
 AdvancedPM=no
 Drive conforms to: device does not report version:

 * signifies the current active mode

  There is a newer version of the firmware, but installation requires
  MS Windows.  Rude.

- CPU is Athlon XP 1700+

- the dvd+rw-tools-5.13.4.7.4-1 package that was installed did not
  include dvd+rw-mediainfo (I wonder why?) so I built it from
  dvd+rw-tools-5.19.4.9.7 and ran it on the two blank DVD-Rs.

[EMAIL PROTECTED] k3b]# ../dvd+rw-tools-5.19.4.9.7/dvd+rw-mediainfo 
/dev/scd0
INQUIRY:[HL-DT-ST][DVDRAM GSA-4040B][A302]
GET [CURRENT] CONFIGURATION:
 Mounted Media: 11h, DVD-R Sequential
 Media ID:  Yi Jhan 001
 Current Write Speed:   2.0x1385=2770KB/s
 Write Speed #0:2.0x1385=2770KB/s
GET [CURRENT] PERFORMANCE:
 Write Performance: 2.0x1385=2770KB/[EMAIL PROTECTED] -> 2298495]
 Speed Descriptor#0:  02/2298495 [EMAIL PROTECTED]/s
[EMAIL PROTECTED]/s
READ DVD STRUCTURE[#0h]:
 Media Book Type:   25h, DVD-R book [revision 5]
 Legacy lead-out at:2298496*2KB=4707319808
READ DISC INFORMATION:
 Disc status:   blank
 Number of Sessions:1
 State of Last Session: empty
 Number of Tracks:  1
READ TRACK INFORMATION[#1]:
 Track State:   invisible incremental
 Track Start Address:   0*2KB
 Next Writable Address: 0*2KB
 Free Blocks:   2297888*2KB
 Track Size:2297888*2KB

[EMAIL PROTECTED] k3b]# ../dvd+rw-tools-5.19.4.9.7/dvd+rw-mediainfo 
/dev/scd0
INQUIRY:[HL-DT-ST][DVDRAM GSA-4040B][A302]
GET [CURRENT] CONFIGURATION:
 Mounted Media: 11h, DVD-R Sequential
 Media ID:  PRINCO
 Current Write Speed:   4.0x1385=5540KB/s
 Write Speed #0:4.0x1385=5540KB/s
 Write Speed #1:2.0x1385=2770KB/s
GET [CURRENT] PERFORMANCE:
 Write Performance: 4.0x1385=5540KB/[EMAIL PROTECTED] -> 2298495]
 Speed Descriptor#0:02/2298495 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s
 Speed Descriptor#1:02/2298495 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s
READ DVD STRUCTURE[#0h]:
 Media Book Type:   25h, DVD-R book [revision 5]
 Legacy lead-out at:2298496*2KB=4707319808
READ DISC INFORMATION:
 Disc status:   blank
 Number of Sessions:1
 State of Last Session: empty
 Number of Tracks:  1
READ TRACK INFORMATION[#1]:
 Track State:   invisible incremental
 Track Start Address:   0*2KB
 Next Writable Address: 0*2KB
 Free Blocks:   2297888*2KB
 Track Size:2297888*2KB


- the size of the .iso is 2,230,036,480 bytes

growisofs vs. LG GSA4040B: unable to CLOSE SESSION (5h/72h/03h): Input/output error

[D. Hugh Redelmeier]

[I hope that this message makes it to the list.  I'm not a subscriber,
even though I've asked twice to become one.]

I'm trying to burn a .iso image onto a DVD-R and not having much luck.
Probably user error: this is the second DVD I've ever tried to burn.

I created a .iso using k3b on Knoppix.  I *assume* that it is good.

I'm trying to burn it using k3b which really means grwoisofs.

I've tried simulated burns with a couple of blank DVD-Rs (two
different brands).  The result is the same:
/dev/scd0: closing session
:-( unable to CLOSE SESSION (5h/72h/03h): Input/output error

According to 
the SCSI error code means:
5  72  03   SESSION FIXATION ERROR - INCOMPLETE TRACK IN SESSION

The growisofs command that k3b uses is:

   /usr/bin/growisofs -Z /dev/scd0=/space1/hugh/EJHR-toshiba.iso \
-use-the-force-luke=notray -use-the-force-luke=tty \
-use-the-force-luke=dummy -speed=4

The "-user-the-force-luke" flag is not documented in the growisofs man
page.

Using -speed=2 did not improve the situation.

I was able to write a rewriteable disk, but k3b's verification failed :-(.

Any suggestons?

Hugh Redelmeier
[EMAIL PROTECTED]  voice: +1 416 482-8253


Environment:

- Fedora Core 1 + updates (Linux version 2.4.22-1.2174.nptl)

- k3b:
Qt: 3.1.2
KDE: 3.1.4-4 Red Hat
K3b: 0.11.9

- growisofs (used by k3b, I think):
* growisofs by <[EMAIL PROTECTED]>, version 5.13,
  front-ending to mkisofs: mkisofs 2.01a17 (i686-redhat-linux-gnu)

- LG GSA 4040B DVD writer.  hdparm says:
[EMAIL PROTECTED] hugh]# /sbin/hdparm -i /dev/hdc

/dev/hdc:

 Model=HL-DT-ST DVDRAM GSA-4040B, FwRev=A302, SerialNo=K2537C84607
 Config={ Fixed Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
 RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
 BuffType=unknown, BuffSize=0kB, MaxMultSect=0
 (maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio3 pio4
 DMA modes:  mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 *udma2
 AdvancedPM=no
 Drive conforms to: device does not report version:

 * signifies the current active mode

  There is a newer version of the firmware, but installation requires
  MS Windows.  Rude.

- CPU is Athlon XP 1700+

- the dvd+rw-tools-5.13.4.7.4-1 package that was installed did not
  include dvd+rw-mediainfo (I wonder why?) so I built it from
  dvd+rw-tools-5.19.4.9.7 and ran it on the two blank DVD-Rs.

[EMAIL PROTECTED] k3b]# ../dvd+rw-tools-5.19.4.9.7/dvd+rw-mediainfo /dev/scd0
INQUIRY:[HL-DT-ST][DVDRAM GSA-4040B][A302]
GET [CURRENT] CONFIGURATION:
 Mounted Media: 11h, DVD-R Sequential
 Media ID:  Yi Jhan 001
 Current Write Speed:   2.0x1385=2770KB/s
 Write Speed #0:2.0x1385=2770KB/s
GET [CURRENT] PERFORMANCE:
 Write Performance: 2.0x1385=2770KB/[EMAIL PROTECTED] -> 2298495]
 Speed Descriptor#0:  02/2298495 [EMAIL PROTECTED]/s
[EMAIL PROTECTED]/s
READ DVD STRUCTURE[#0h]:
 Media Book Type:   25h, DVD-R book [revision 5]
 Legacy lead-out at:2298496*2KB=4707319808
READ DISC INFORMATION:
 Disc status:   blank
 Number of Sessions:1
 State of Last Session: empty
 Number of Tracks:  1
READ TRACK INFORMATION[#1]:
 Track State:   invisible incremental
 Track Start Address:   0*2KB
 Next Writable Address: 0*2KB
 Free Blocks:   2297888*2KB
 Track Size:2297888*2KB

[EMAIL PROTECTED] k3b]# ../dvd+rw-tools-5.19.4.9.7/dvd+rw-mediainfo /dev/scd0
INQUIRY:[HL-DT-ST][DVDRAM GSA-4040B][A302]
GET [CURRENT] CONFIGURATION:
 Mounted Media: 11h, DVD-R Sequential
 Media ID:  PRINCO
 Current Write Speed:   4.0x1385=5540KB/s
 Write Speed #0:4.0x1385=5540KB/s
 Write Speed #1:2.0x1385=2770KB/s
GET [CURRENT] PERFORMANCE:
 Write Performance: 4.0x1385=5540KB/[EMAIL PROTECTED] -> 2298495]
 Speed Descriptor#0:02/2298495 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s
 Speed Descriptor#1:02/2298495 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s
READ DVD STRUCTURE[#0h]:
 Media Book Type:   25h, DVD-R book [revision 5]
 Legacy lead-out at:2298496*2KB=4707319808
READ DISC INFORMATION:
 Disc status:   blank
 Number of Sessions:1
 State of Last Session: empty
 Number of Tracks:  1
READ TRACK INFORMATION[#1]:
 Track State:   invisible incremental
 Track Start Address:   0*2KB
 Next Writable Address: 0*2KB
 Free Blocks:   2297888*2KB
 Track Size:2297888*2KB


- the size of the .iso is 2,230,036,480 bytes


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

growisofs vs. LG GSA4040B: unable to CLOSE SESSION (5h/72h/03h): Input/output error

[D. Hugh Redelmeier]

[I hope that this message makes it to the list.  Once.  It took four tries 
to become a subscriber (the web form does not work).]

I'm trying to burn a .iso image onto a DVD-R and not having much luck.
Probably user error: this is the second DVD I've ever tried to burn.

I created a .iso using k3b on Knoppix.  I *assume* that it is good.

I'm trying to burn it using k3b which really means grwoisofs.

I've tried simulated burns with a couple of blank DVD-Rs (two
different brands).  The result is the same:
/dev/scd0: closing session
:-( unable to CLOSE SESSION (5h/72h/03h): Input/output error

According to 
the SCSI error code means:
5  72  03   SESSION FIXATION ERROR - INCOMPLETE TRACK IN SESSION

The growisofs command that k3b uses is:

   /usr/bin/growisofs -Z /dev/scd0=/space1/hugh/EJHR-toshiba.iso \
-use-the-force-luke=notray -use-the-force-luke=tty \
-use-the-force-luke=dummy -speed=4

The "-user-the-force-luke" flag is not documented in the growisofs man
page.

Using -speed=2 did not improve the situation.

I was able to write a rewriteable disk, but k3b's verification failed :-(.

Any suggestons?

Hugh Redelmeier
[EMAIL PROTECTED]  voice: +1 416 482-8253


Environment:

- Fedora Core 1 + updates (Linux version 2.4.22-1.2174.nptl)

- k3b:
Qt: 3.1.2
KDE: 3.1.4-4 Red Hat
K3b: 0.11.9

- growisofs (used by k3b, I think):
* growisofs by <[EMAIL PROTECTED]>, version 5.13,
  front-ending to mkisofs: mkisofs 2.01a17 (i686-redhat-linux-gnu)

- LG GSA 4040B DVD writer.  hdparm says:
[EMAIL PROTECTED] hugh]# /sbin/hdparm -i /dev/hdc

/dev/hdc:

 Model=HL-DT-ST DVDRAM GSA-4040B, FwRev=A302, SerialNo=K2537C84607
 Config={ Fixed Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
 RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
 BuffType=unknown, BuffSize=0kB, MaxMultSect=0
 (maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio3 pio4
 DMA modes:  mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 *udma2
 AdvancedPM=no
 Drive conforms to: device does not report version:

 * signifies the current active mode

  There is a newer version of the firmware, but installation requires
  MS Windows.  Rude.

- CPU is Athlon XP 1700+

- the dvd+rw-tools-5.13.4.7.4-1 package that was installed did not
  include dvd+rw-mediainfo (I wonder why?) so I built it from
  dvd+rw-tools-5.19.4.9.7 and ran it on the two blank DVD-Rs.

[EMAIL PROTECTED] k3b]# ../dvd+rw-tools-5.19.4.9.7/dvd+rw-mediainfo 
/dev/scd0
INQUIRY:[HL-DT-ST][DVDRAM GSA-4040B][A302]
GET [CURRENT] CONFIGURATION:
 Mounted Media: 11h, DVD-R Sequential
 Media ID:  Yi Jhan 001
 Current Write Speed:   2.0x1385=2770KB/s
 Write Speed #0:2.0x1385=2770KB/s
GET [CURRENT] PERFORMANCE:
 Write Performance: 2.0x1385=2770KB/[EMAIL PROTECTED] -> 2298495]
 Speed Descriptor#0:  02/2298495 [EMAIL PROTECTED]/s
[EMAIL PROTECTED]/s
READ DVD STRUCTURE[#0h]:
 Media Book Type:   25h, DVD-R book [revision 5]
 Legacy lead-out at:2298496*2KB=4707319808
READ DISC INFORMATION:
 Disc status:   blank
 Number of Sessions:1
 State of Last Session: empty
 Number of Tracks:  1
READ TRACK INFORMATION[#1]:
 Track State:   invisible incremental
 Track Start Address:   0*2KB
 Next Writable Address: 0*2KB
 Free Blocks:   2297888*2KB
 Track Size:2297888*2KB

[EMAIL PROTECTED] k3b]# ../dvd+rw-tools-5.19.4.9.7/dvd+rw-mediainfo 
/dev/scd0
INQUIRY:[HL-DT-ST][DVDRAM GSA-4040B][A302]
GET [CURRENT] CONFIGURATION:
 Mounted Media: 11h, DVD-R Sequential
 Media ID:  PRINCO
 Current Write Speed:   4.0x1385=5540KB/s
 Write Speed #0:4.0x1385=5540KB/s
 Write Speed #1:2.0x1385=2770KB/s
GET [CURRENT] PERFORMANCE:
 Write Performance: 4.0x1385=5540KB/[EMAIL PROTECTED] -> 2298495]
 Speed Descriptor#0:02/2298495 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s
 Speed Descriptor#1:02/2298495 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s
READ DVD STRUCTURE[#0h]:
 Media Book Type:   25h, DVD-R book [revision 5]
 Legacy lead-out at:2298496*2KB=4707319808
READ DISC INFORMATION:
 Disc status:   blank
 Number of Sessions:1
 State of Last Session: empty
 Number of Tracks:  1
READ TRACK INFORMATION[#1]:
 Track State:   invisible incremental
 Track Start Address:   0*2KB
 Next Writable Address: 0*2KB
 Free Blocks:   2297888*2KB
 Track Size:2297888*2KB


- the size of the .iso is 2,230,036,480 bytes

growisofs vs. LG GSA4040B: unable to CLOSE SESSION (5h/72h/03h): Input/output error

[D. Hugh Redelmeier]

[I hope that this message makes it to the list.  Once.  It took four tries 
to become a subscriber (the web form does not work).]

I'm trying to burn a .iso image onto a DVD-R and not having much luck.
Probably user error: this is the second DVD I've ever tried to burn.

I created a .iso using k3b on Knoppix.  I *assume* that it is good.

I'm trying to burn it using k3b which really means grwoisofs.

I've tried simulated burns with a couple of blank DVD-Rs (two
different brands).  The result is the same:
/dev/scd0: closing session
:-( unable to CLOSE SESSION (5h/72h/03h): Input/output error

According to 
the SCSI error code means:
5  72  03   SESSION FIXATION ERROR - INCOMPLETE TRACK IN SESSION

The growisofs command that k3b uses is:

   /usr/bin/growisofs -Z /dev/scd0=/space1/hugh/EJHR-toshiba.iso \
-use-the-force-luke=notray -use-the-force-luke=tty \
-use-the-force-luke=dummy -speed=4

The "-user-the-force-luke" flag is not documented in the growisofs man
page.

Using -speed=2 did not improve the situation.

I was able to write a rewriteable disk, but k3b's verification failed :-(.

Any suggestons?

Hugh Redelmeier
[EMAIL PROTECTED]  voice: +1 416 482-8253


Environment:

- Fedora Core 1 + updates (Linux version 2.4.22-1.2174.nptl)

- k3b:
Qt: 3.1.2
KDE: 3.1.4-4 Red Hat
K3b: 0.11.9

- growisofs (used by k3b, I think):
* growisofs by <[EMAIL PROTECTED]>, version 5.13,
  front-ending to mkisofs: mkisofs 2.01a17 (i686-redhat-linux-gnu)

- LG GSA 4040B DVD writer.  hdparm says:
[EMAIL PROTECTED] hugh]# /sbin/hdparm -i /dev/hdc

/dev/hdc:

 Model=HL-DT-ST DVDRAM GSA-4040B, FwRev=A302, SerialNo=K2537C84607
 Config={ Fixed Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
 RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
 BuffType=unknown, BuffSize=0kB, MaxMultSect=0
 (maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio3 pio4
 DMA modes:  mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 *udma2
 AdvancedPM=no
 Drive conforms to: device does not report version:

 * signifies the current active mode

  There is a newer version of the firmware, but installation requires
  MS Windows.  Rude.

- CPU is Athlon XP 1700+

- the dvd+rw-tools-5.13.4.7.4-1 package that was installed did not
  include dvd+rw-mediainfo (I wonder why?) so I built it from
  dvd+rw-tools-5.19.4.9.7 and ran it on the two blank DVD-Rs.

[EMAIL PROTECTED] k3b]# ../dvd+rw-tools-5.19.4.9.7/dvd+rw-mediainfo /dev/scd0
INQUIRY:[HL-DT-ST][DVDRAM GSA-4040B][A302]
GET [CURRENT] CONFIGURATION:
 Mounted Media: 11h, DVD-R Sequential
 Media ID:  Yi Jhan 001
 Current Write Speed:   2.0x1385=2770KB/s
 Write Speed #0:2.0x1385=2770KB/s
GET [CURRENT] PERFORMANCE:
 Write Performance: 2.0x1385=2770KB/[EMAIL PROTECTED] -> 2298495]
 Speed Descriptor#0:  02/2298495 [EMAIL PROTECTED]/s
[EMAIL PROTECTED]/s
READ DVD STRUCTURE[#0h]:
 Media Book Type:   25h, DVD-R book [revision 5]
 Legacy lead-out at:2298496*2KB=4707319808
READ DISC INFORMATION:
 Disc status:   blank
 Number of Sessions:1
 State of Last Session: empty
 Number of Tracks:  1
READ TRACK INFORMATION[#1]:
 Track State:   invisible incremental
 Track Start Address:   0*2KB
 Next Writable Address: 0*2KB
 Free Blocks:   2297888*2KB
 Track Size:2297888*2KB

[EMAIL PROTECTED] k3b]# ../dvd+rw-tools-5.19.4.9.7/dvd+rw-mediainfo /dev/scd0
INQUIRY:[HL-DT-ST][DVDRAM GSA-4040B][A302]
GET [CURRENT] CONFIGURATION:
 Mounted Media: 11h, DVD-R Sequential
 Media ID:  PRINCO
 Current Write Speed:   4.0x1385=5540KB/s
 Write Speed #0:4.0x1385=5540KB/s
 Write Speed #1:2.0x1385=2770KB/s
GET [CURRENT] PERFORMANCE:
 Write Performance: 4.0x1385=5540KB/[EMAIL PROTECTED] -> 2298495]
 Speed Descriptor#0:02/2298495 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s
 Speed Descriptor#1:02/2298495 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s
READ DVD STRUCTURE[#0h]:
 Media Book Type:   25h, DVD-R book [revision 5]
 Legacy lead-out at:2298496*2KB=4707319808
READ DISC INFORMATION:
 Disc status:   blank
 Number of Sessions:1
 State of Last Session: empty
 Number of Tracks:  1
READ TRACK INFORMATION[#1]:
 Track State:   invisible incremental
 Track Start Address:   0*2KB
 Next Writable Address: 0*2KB
 Free Blocks:   2297888*2KB
 Track Size:2297888*2KB


- the size of the .iso is 2,230,036,480 bytes



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]