Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #236382 > unrolled thread

Fatal error while burning CD

Back to article view | Back to linux.debian.user

Contents

  Fatal error while burning CD Michael Lange <klappnase@freenet.de> - 2021-06-23 19:40 +0200
    Re: Fatal error while burning CD "Thomas Schmitt" <scdbackup@gmx.net> - 2021-06-23 21:00 +0200
      Re: Fatal error while burning CD Michael Lange <klappnase@freenet.de> - 2021-06-23 23:40 +0200
        Re: Fatal error while burning CD "Thomas Schmitt" <scdbackup@gmx.net> - 2021-06-24 09:20 +0200
          Re: Fatal error while burning CD Michael Lange <klappnase@freenet.de> - 2021-06-24 11:30 +0200
            Re: Fatal error while burning CD "Thomas Schmitt" <scdbackup@gmx.net> - 2021-06-24 12:20 +0200
              Re: Fatal error while burning CD "Thomas Schmitt" <scdbackup@gmx.net> - 2021-06-24 14:20 +0200
                Re: Fatal error while burning CD Michael Lange <klappnase@freenet.de> - 2021-06-25 00:50 +0200
                  Re: Fatal error while burning CD "Thomas Schmitt" <scdbackup@gmx.net> - 2021-06-25 08:50 +0200
                    Re: Fatal error while burning CD Michael Lange <klappnase@freenet.de> - 2021-06-25 10:30 +0200
                  Re: Fatal error while burning CD "Thomas Schmitt" <scdbackup@gmx.net> - 2021-06-25 11:50 +0200
                    Re: Fatal error while burning CD mcgarrett <dmcgarrett@optonline.net> - 2021-06-26 04:00 +0200
          How to verify newly burned disc [Was: Fatal error while burning CD] Michael Lange <klappnase@freenet.de> - 2021-06-29 10:30 +0200
            Re: How to verify newly burned disc [Was: Fatal error while burning          CD] Linux-Fan <Ma_Sys.ma@web.de> - 2021-06-29 10:40 +0200
              Re: How to verify newly burned disc [Was: Fatal error while burning  CD] Michael Lange <klappnase@freenet.de> - 2021-06-29 11:10 +0200
            Re: How to verify newly burned disc "Thomas Schmitt" <scdbackup@gmx.net> - 2021-06-29 12:10 +0200
              Re: How to verify newly burned disc Michael Lange <klappnase@freenet.de> - 2021-07-02 09:10 +0200
            Re: How to verify newly burned disc "Thomas Schmitt" <scdbackup@gmx.net> - 2021-07-02 12:30 +0200
              Re: How to verify newly burned disc Michael Lange <klappnase@freenet.de> - 2021-07-02 20:00 +0200
                Re: How to verify newly burned disc "Thomas Schmitt" <scdbackup@gmx.net> - 2021-07-02 21:30 +0200
                  Re: How to verify newly burned disc Michael Lange <klappnase@freenet.de> - 2021-07-03 01:00 +0200
                    Re: How to verify newly burned disc Stefan Monnier <monnier@iro.umontreal.ca> - 2021-07-03 04:50 +0200
                      Re: How to verify newly burned disc "Thomas Schmitt" <scdbackup@gmx.net> - 2021-07-03 10:50 +0200
            Re: How to verify newly burned disc [Was: Fatal error while burning CD] Richmond <richmond@criptext.com> - 2021-07-02 22:20 +0200
              Re: How to verify newly burned disc [Was: Fatal error while burning  CD] Greg Wooledge <greg@wooledge.org> - 2021-07-02 22:40 +0200
                Re: How to verify newly burned disc [Was: Fatal error while burning  CD] Richmond <richmond@criptext.com> - 2021-07-02 23:30 +0200
                  Re: How to verify newly burned disc [Was: Fatal error while burning  CD] Greg Wooledge <greg@wooledge.org> - 2021-07-02 23:40 +0200
                  Re: How to verify newly burned disc "Thomas Schmitt" <scdbackup@gmx.net> - 2021-07-03 00:00 +0200

Page 1 of 2  [1] 2  Next page →

#236382 — Fatal error while burning CD

Hi,

I have recently been encountering errors while trying to burn CDDA discs;
I had previously used cdrdao for ages for this task, which (at least it
looks like that to me) hasn't really been maintained for well over 10
years, so I thought it *might* be a software bug with cdrdao.

Too bad, now I got a similar looking error from cdrskin:

1.1x.cdrskin: FATAL : SCSI error on write(442,13): See MMC specs: Sense Key 5 "Illegal request", ASC A8 ASCQ 04

I couldn't find anything enlightening about this in the web. 
Does anyone know, if this error points in a specific direction
(drive? cable? media?) or if it is rather unspecific and I will have to 
go by try-and-error?

Thanks in advance

Michael


.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

Power is danger.
		-- The Centurion, "Balance of Terror", stardate 1709.2

[toc] | [next] | [standalone]

#236384

Hi,

Michael Lange wrote:
> cdrskin: FATAL : SCSI error on write(442,13): See MMC specs: Sense Key
> 5 "Illegal request", ASC A8 ASCQ 04

The hex number triple (5, A8, 04) is the reply of the drive to command
WRITE(10) after 34 such commands succeeded. (34 = 442 / 13. 13 is the
smallest multiple of 2352 bytes below 32 KiB.)

ASC A8 is not in the list of MMC errors. Actually there is none above 73.
Insofar your drive's firmware is creative.
The sense key 5 means that the drive accuses the burn program of doing it
wrong.

What were your exact cdrskin arguments ?
Inhowfar do they differ from those of the previously successful run ?


What does this run report about cdrskin and your drive when a blank CD-R[W]
is inserted:

  cdrskin dev=/dev/sr0 -minfo 2>&1 | tee -i /tmp/cdrskin_minfo

The line
  Drive id       : '...'
will contain the serial number of your drive. It is of no interest for our
case, so you may delete it before posting the output of about 40 lines.

If your cdrskin version is 1.5.0, can you confirm that you have installed
cdrskin_1.5.0-1+deb10u1 of 2019 and not the older 1.5.0-1 of 2018 ?


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#236392

Hi,

thanks for the quick responese!

On Wed, 23 Jun 2021 20:58:17 +0200
"Thomas Schmitt" <scdbackup@gmx.net> wrote:

> Hi,
> 
> Michael Lange wrote:
> > cdrskin: FATAL : SCSI error on write(442,13): See MMC specs: Sense Key
> > 5 "Illegal request", ASC A8 ASCQ 04
> 
> The hex number triple (5, A8, 04) is the reply of the drive to command
> WRITE(10) after 34 such commands succeeded. (34 = 442 / 13. 13 is the
> smallest multiple of 2352 bytes below 32 KiB.)
> 
> ASC A8 is not in the list of MMC errors. Actually there is none above
> 73. Insofar your drive's firmware is creative.

Ok, that explains why I couldn't find it anywhere :-)

> The sense key 5 means that the drive accuses the burn program of doing
> it wrong.
> 
> What were your exact cdrskin arguments ?
> Inhowfar do they differ from those of the previously successful run ?

The exact command was (without slashes and line breaks of course):

cdrskin -v -dummy -eject dev=/dev/sr0 -sao speed=10 '04 Pujeva.wav' \
	sao_pregap=75 '05 New Pulse.wav' sao_pregap=225 '07 Rocket \
	Keronian.wav' '10 Dodo.wav'

I repeated the exact same command immediately afterwards with the same
disc, and the second time it finished without errors.

> 
> 
> What does this run report about cdrskin and your drive when a blank
> CD-R[W] is inserted:
> 
>   cdrskin dev=/dev/sr0 -minfo 2>&1 | tee -i /tmp/cdrskin_minfo

Ok, I inserted a blank disc from the same package as the one I had the
error with and got this:

$ cdrskin dev=/dev/sr0 -minfo 2>&1 | tee -i /tmp/cdrskin_minfo
cdrskin 1.5.0 : limited cdrecord compatibility wrapper for libburn
cdrskin: NOTE : greying out all drives besides given dev='/dev/sr0'
cdrskin: scanning for devices ...
cdrskin: ... scanning for devices done
scsidev: '/dev/sr0'
cdrskin: pseudo-atip on drive 0
cdrskin: status 1 burn_disc_blank "The drive holds a blank disc"
Device type    : Removable CD-ROM
Vendor_info    : 'PLEXTOR'
Identifikation : 'DVDR PX-810SA'
Revision       : '1.01'
Driver flags   : BURNFREE
Supported modes: TAO SAO
cdrskin: burn_drive_get_write_speed = 5645  (32.0x)
ATIP info from disk:
  Is not erasable
  ATIP start of lead in:  -12508 (97:15/17)
  ATIP start of lead out: 359845 (79:59/70)
  1T speed low:  4 1T speed high: 32
Product Id:    97m15s17f/79m59s70f
Producer:      Ritek Corp

Mounted media class:      CD
Mounted media type:       CD-R
Disk Is not erasable
disk status:              empty
session status:           empty
first track:              1
number of sessions:       1
first track in last sess: 1
last track in last sess:  1
Disk Is not unrestricted
Disk type: undefined

Track  Sess Type   Start Addr End Addr   Size
==============================================
    1     1 Blank  0          359842     359843    

Next writable address:              0         
Remaining writable size:            359843    


> 
> The line
>   Drive id       : '...'
> will contain the serial number of your drive. It is of no interest for
> our case, so you may delete it before posting the output of about 40
> lines.
> 
> If your cdrskin version is 1.5.0, can you confirm that you have
> installed cdrskin_1.5.0-1+deb10u1 of 2019 and not the older 1.5.0-1 of
> 2018 ?

Yes, 1.5.0-1+deb10u1 is installed.

Maybe I should add that this or similar errors (I at least
clearly remember the "Sense key 5") occured with cdrdao with
blanks of different manufacturers. Once I tried to let cdrdao just finish
without interrupting it and to my utter surprise it produced a CD that
when inserted into the CD-player was recognized and reported with the
expected track count and duration. I was even able to start playback,
only that instead of music some real nasty constant noise came through
the speakers :)

Thanks, and best regards

Michael



.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

Vulcans never bluff.
		-- Spock, "The Doomsday Machine", stardate 4202.1

[toc] | [prev] | [next] | [standalone]

#236397

Hi,

i wrote:
> > What were your exact cdrskin arguments ?

Michael Lange wrote:
> cdrskin -v -dummy -eject dev=/dev/sr0 -sao speed=10 '04 Pujeva.wav' \
>        sao_pregap=75 '05 New Pulse.wav' sao_pregap=225 '07 Rocket \
>        Keronian.wav' '10 Dodo.wav'

Looks quite unsuspicious. The sao_pregap= options might be rarely used.
Option -dummy might bring the drive into a state where it pretends that
the medium is written and has a non-empty table-of-content. But this
illusion should end after ejection of the medium.


> I repeated the exact same command immediately afterwards with the same
> disc, and the second time it finished without errors.

I am quite sure that cdrskin acts deterministically. So if the same
preconditions yield a different outcome then i would blame it on the drive.
Given that -dummy was used, i expect not much influence by the actual
quality of the medium. (The error key 5 "Illegal Request" indicates a
problem between firmware and burn program, anyway.)

The fact that it accepted 34 WRITE(10) commands before it complains about
the 35th makes me think that the error occurs when the drive actually
begins to write. But error key 5 does not really match this occasion.
It stays a riddle.


> $ cdrskin dev=/dev/sr0 -minfo 2>&1 | tee -i /tmp/cdrskin_minfo
> ...
> Vendor_info    : 'PLEXTOR'
> Identifikation : 'DVDR PX-810SA'
> Revision       : '1.01'

According to Google this drive iseems to have appeared around 2006.
How old is yours ?


> Maybe I should add that this or similar errors (I at least
> clearly remember the "Sense key 5") occured with cdrdao with
> blanks of different manufacturers.

I'd expect cdrdao to act deterministically, too.


> Once I tried to let cdrdao just finish
> without interrupting it and to my utter surprise it produced a CD that
> when inserted into the CD-player was recognized and reported with the
> expected track count and duration.

Looks like the table-of-content was sucessfully written. With SAO this
happens before data writing begins.


So yes, you should consider to get a new drive.
DVD drives are cheap nowadays. Last time i got one, i had to send it back
because of being unreliable with reading what it wrote. The replacement
works well. (I suspect that the bad one was sent to the next customer.
Nobody was interested in my problem report.)

Personally, i'd rather get a BD drive for about 5 times the price.
But if you are mainly into audio CD burning, this would be overdone.
In any case, test it with all your intended use cases, as soon as it
arrives.


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#236398

Hi,

On Thu, 24 Jun 2021 09:19:43 +0200
"Thomas Schmitt" <scdbackup@gmx.net> wrote:

(...)
> > $ cdrskin dev=/dev/sr0 -minfo 2>&1 | tee -i /tmp/cdrskin_minfo
> > ...
> > Vendor_info    : 'PLEXTOR'
> > Identifikation : 'DVDR PX-810SA'
> > Revision       : '1.01'
> 
> According to Google this drive iseems to have appeared around 2006.
> How old is yours ?

I'm not sure, but it's certainly not much younger.

> 
> 
> > Maybe I should add that this or similar errors (I at least
> > clearly remember the "Sense key 5") occured with cdrdao with
> > blanks of different manufacturers.
> 
> I'd expect cdrdao to act deterministically, too.
> 
> 
> > Once I tried to let cdrdao just finish
> > without interrupting it and to my utter surprise it produced a CD that
> > when inserted into the CD-player was recognized and reported with the
> > expected track count and duration.
> 
> Looks like the table-of-content was sucessfully written. With SAO this
> happens before data writing begins.
> 
> 
> So yes, you should consider to get a new drive.

I thought so, maybe the drive is just dying slowly.

> DVD drives are cheap nowadays. Last time i got one, i had to send it
> back because of being unreliable with reading what it wrote. The
> replacement works well. (I suspect that the bad one was sent to the
> next customer. Nobody was interested in my problem report.)

:-)

> 
> Personally, i'd rather get a BD drive for about 5 times the price.
> But if you are mainly into audio CD burning, this would be overdone.
> In any case, test it with all your intended use cases, as soon as it
> arrives.

I've been thinking about buying a BD device, not sure about it yet (maybe
I'll throw a coin :) 
Testing the new drive thoroughly immediately after buying definitely
sounds like good advice.

Thanks again for the help, and have a nice day :-)

Michael


.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

Oh, that sound of male ego.  You travel halfway across the galaxy and
it's still the same song.
		-- Eve McHuron, "Mudd's Women", stardate 1330.1

[toc] | [prev] | [next] | [standalone]

#236399

Hi,

i am making theories how the drive firmware could perceive any illegal
request while WRITE(10) commands come in. (Senile dementia is not among
the usual signs of drive ageing. Rather they go blind or suffer stroke.)

I would be interesting to see the SCSI log of a failed dummy burn. I.e. with
option -V and redirection of text output to file cdrskin_scsi_log.

  cdrskin -V ...your.options... 2>&1 | tee -i /tmp/cdrskin_scsi_log

If the failure happens, then the log will not be as large as with a
successful run, but nevertheless have a few hundred lines. So if you take
the plight on you to provoke the failure, then send the file to me in
private.

--------------------------------------------------------------------------
Vague theory i have:

The potential mistake of a burn program during data writing is that the
Logical Block Address of the WRITE(10) command does not match the data
stream count of the drive. Since libburn normally has no problem to compute
the apropriate LBA during data transmission, there would have to be a
misunderstanding about the number of accepted data blocks.

A drive is allowed to reply to WRITE(10) by ASC 04 "Logical unit not ready"
with some ASCQ number which indicates that the drive promises to become
ready without external intervention. The burn program is then supposed to
send again a WRITE(10) command with the same LBA and the same data payload.
This repetition is permissible only if the drive really did not count the
blocks of the previous WRITE(10) command.

Not many drives emit "not ready" when their buffer becomes full. Among mine
it's only the Optiarc BD-5300S.
The others simply wait with their reply to WRITE(10) until enough room is
in their buffer to take the next chunk of data.

The SCSI log of a failed run would show the LBAs of the WRITE(10) commands
and the possible "not ready" replies by the drive. Maybe i can learn how
libburn and drive came out of sync.


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#236405

Hi,

i got an SCSI log of a failed burn run from Michael Lange.

No artsy dance between drive and libburn is to see, which could explain
a misunderstanding between both.
The drive buffer becomes full, after 17 seconds some few sectors seem to
have been actually written, and then the second next WRITE(10) fails with
the "illegal request" error.
Its data would not fit into the buffer, but the drive does not wait until
there is room.

So it has something to do with a full drive buffer.

-------------------------------------------------------------------------

cdrskin can avoid to fill the buffer by an old workaround from the bad old
days of parallel ATA controllers when the CD burner blocked the hard disk
on the same controller while a WRITE(10) was waiting for buffer space in
the burner.

I wonder whether this workaround can avoid the drive's error reply.

If you are curious enough, add to your cdrskin runs this non-cdrecord option

   modesty_on_drive=1:min_percent=75:max_percent=80

It will pause sending of data when the drive buffer is in danger to become
more than 80 percent full. Sending data is resumed when it is below 75
percent full.
(Ye olde cdrecord option -immed is in cdrskin implemented as
   modesty_on_drive=1:min_percent=75:max_percent=95
but for this experiment we should give more free room than 5 percent.)

-------------------------------------------------------------------------
Long story of the SCSI log:

The reported drive buffer capacity is not 2 MiB but 1,179,648 bytes.

All looks well until LBA 416 is written. The most recent buffer inquiry
showed 98304 bytes free. Three more WRITE(10) succeeded which added
91728. So the buffer might be full up to 6576 free bytes. The WRITE(10)
to LBA 416 brings 30576 more bytes.

Now happens nothing for 17 seconds.
Then the pending WRITE(10) command gets a "no problem" reply. The
subsequent WRITE(10) command for LBA 429 ends swiftly without error reply.
Inquiry of the drive buffer reveils 10240 free bytes.

The next WRITE(10) goes to LBA 442 and gets an immediate error reply of
Key 5, ASC A8, ASCQ 04. (As said, ASC A8 is not listed in my copies of SCSI
specifications.)

libburn takes this as fatal error and brings the burn run to an emergency
halt.
The drive needs 110 seconds until it replies success to a TEST UNIT READY
command. That would suffice for the whole 168 MB of payload at the chosen
speed of 10x (= 750 sectors/second).
During that time, the TEST UNIT READYs got replied Key 2, ASC 04, ASCQ 07
which means "Logical unit not ready, operation in progress".

4 seconds later, the CD is ejected and the cdrskin run ends.

-------------------------------------------------------------------------

Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#236431

Hi,

On Thu, 24 Jun 2021 14:18:08 +0200
"Thomas Schmitt" <scdbackup@gmx.net> wrote:

> Hi,
> 
> i got an SCSI log of a failed burn run from Michael Lange.
> 
> No artsy dance between drive and libburn is to see, which could explain
> a misunderstanding between both.
> The drive buffer becomes full, after 17 seconds some few sectors seem to
> have been actually written, and then the second next WRITE(10) fails
> with the "illegal request" error.
> Its data would not fit into the buffer, but the drive does not wait
> until there is room.
> 
> So it has something to do with a full drive buffer.
> 
> -------------------------------------------------------------------------
> 
> cdrskin can avoid to fill the buffer by an old workaround from the bad
> old days of parallel ATA controllers when the CD burner blocked the
> hard disk on the same controller while a WRITE(10) was waiting for
> buffer space in the burner.
> 
> I wonder whether this workaround can avoid the drive's error reply.
> 
> If you are curious enough, add to your cdrskin runs this non-cdrecord
> option
> 
>    modesty_on_drive=1:min_percent=75:max_percent=80

burning failed with this option, too (two out of three runs).
Both of these failures seemed to occur at the same stage of the process
with the message

cdrskin: FATAL : SCSI error on write(299,13): See MMC \
	specs: Sense Key 5 "Illegal request", ASC A8 ASCQ 04.

I think this means that it failed even a bit earlier than without this
option when it was "SCSI error on write(442,13)"?

Before it fails there is a real lot of log entries (about 3000 lines) like

READ BUFFER CAPACITY
5c 00 00 00 00 00 00 00 0c 00 
>From drive: 12b
00 0a 00 00 00 12 00 00 00 04 10 00 
      342 us     [ 26803073 ]

But maybe this is to be expected when cdrskin runs with the
modesty_on_drive=... option?


Best regards

Michael

[toc] | [prev] | [next] | [standalone]

#236433

Hi,

i wrote:
> >    modesty_on_drive=1:min_percent=75:max_percent=80

Michael Lange wrote:
> burning failed with this option, too (two out of three runs).

Looks like you really need a new drive.


> cdrskin: FATAL : SCSI error on write(299,13): See MMC \
>         specs: Sense Key 5 "Illegal request", ASC A8 ASCQ 04.
>
> I think this means that it failed even a bit earlier than without this
> option when it was "SCSI error on write(442,13)"?
> Before it fails there is a real lot of log entries (about 3000 lines) like
>
> READ BUFFER CAPACITY
> 5c 00 00 00 00 00 00 00 0c 00
> From drive: 12b
> 00 0a 00 00 00 12 00 00 00 04 10 00
>      342 us     [ 26803073 ]
>
> But maybe this is to be expected when cdrskin runs with the
> modesty_on_drive=... option?

Yes. That option causes frequent inquiry of the drive's buffer status.
At the time of above READ BUFFER CAPACITY command the free buffer capacity
was 0x041000 = 266240 bytes. That's about 77.5 percent fill of the
0x120000 = 1,179,648 buffer bytes.

So the buffer really does not get filled completely. In the log which you
sent me, the error ocured after 28.8 seconds of libburn run time. At the
time of above command, libburn was running for 26.803073 seconds.
(What number is to see in the microsecond timestamp []-brackets of the
failed WRITE(10) command ? Is it around 28 million ?)


So it looks more like the actual burn start brings the drive firmware to
reporting its self-invented (or "vendor specific") error code.
I would next point to the power supply situation, if it was an external
drive which gets its power via the USB cable. In that case the theory
would be that the laser beam uses too much electricty so that the firmware
processor gets a hick-up.

But as it appears now, the drive is just mad and unreliable.
I'm crossing fingers that your next one will have a long and happy life.


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#236435

Hi,

On Fri, 25 Jun 2021 08:44:58 +0200
"Thomas Schmitt" <scdbackup@gmx.net> wrote:

(...)
> > But maybe this is to be expected when cdrskin runs with the
> > modesty_on_drive=... option?
> 
> Yes. That option causes frequent inquiry of the drive's buffer status.
> At the time of above READ BUFFER CAPACITY command the free buffer
> capacity was 0x041000 = 266240 bytes. That's about 77.5 percent fill of
> the 0x120000 = 1,179,648 buffer bytes.
> 
> So the buffer really does not get filled completely. In the log which
> you sent me, the error ocured after 28.8 seconds of libburn run time.
> At the time of above command, libburn was running for 26.803073 seconds.
> (What number is to see in the microsecond timestamp []-brackets of the
> failed WRITE(10) command ? Is it around 28 million ?)

looking through my collection of log files these timestamps range from
[ 25381890 ] to [ 29665146 ], with or without modesty_on_drive=... does
not seem to make much of a difference. Maybe the time it takes for the
drive to become ready after closing the tray can account for this 4
seconds.

> 
> 
> So it looks more like the actual burn start brings the drive firmware to
> reporting its self-invented (or "vendor specific") error code.
> I would next point to the power supply situation, if it was an external
> drive which gets its power via the USB cable. In that case the theory
> would be that the laser beam uses too much electricty so that the
> firmware processor gets a hick-up.

It's an internal drive, so the power supply seems to me like an unlikely
candidate.

> 
> But as it appears now, the drive is just mad and unreliable.
> I'm crossing fingers that your next one will have a long and happy life.

Thanks :-)
And maybe the firmware programmers of the next drive were less
creative :-)

If someone here can report about experience (good or bad) with specific
make and models (still not sure whether the next drive will be a DVD- or
BD-writer), it would be welcome...

Thanks again, and have a nice day :)

Michael


.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

When dreams become more important than reality, you give up travel,
building, creating; you even forget how to repair the machines left
behind by your ancestors.  You just sit living and reliving other lives
left behind in the thought records.
		-- Vina, "The Menagerie" ("The Cage"), stardate unknown

[toc] | [prev] | [next] | [standalone]

#236436

Hi,

Michael Lange wrote:
> If someone here can report about experience (good or bad) with specific
> make and models (still not sure whether the next drive will be a DVD- or
> BD-writer), it would be welcome...

In general i'd buy any brand of full height drives.
I currently run 3 LGs, 2 ASUS, 1 Samsung, 1 Optiarc, 1 PIONEER.

It's more a matter of the individual drive than of the manufacturer or
model. Not so good during the last 5 years were:
- The flaky new DVD burner which i had to send back was a LITEON
  iHAS124F. But i know of other iHASen which work well.
- An LG GH24NSC0 became unreliable after only two years.
  The LITEON was planned as replacement. In the end the job went to a
  ASUS DRW-24D5MT.
(Both did cost about 15 EUR. So any testing at the factory would eat up
the manufacturer's profit.)

I always refrained from slim drives. User reports suggest that they are
a bit less reliable. But your mileage may vary ...

--------------------------------------------------------------------------
A little warning about PIONEER BDR-S09 might be appropriate:

Mine reads BD-RW with such a high (and not adjustable) speed and has such
a strong grip on the medium, that two newer "Verbatim" BD-RW media
developed a radial crack from the inner hole towards the writable area.
With one of the media the crack reached the writable area and made the
medium unreadable.
This happened during stress tests after about 10 times of reading. The
media bear the manufacturer id "CMCMAG/CN2/0". Older Verbatim BD-RW
(VERBAT/IM0/0) or those from "Intenso", "Primeon" and "Maxcell"
(all RITEK/BW1/1) did not suffer such a damage in 20 read runs at about
10x BD speed.
The drive itself survived the intensive testing without problems.

I addressed the PIONEER BDR-S09's unwillingness to read with slower speed
by special parameters of xorriso command -read_speed, which curb the drive
speed by simply not taking more data per second than the desired speed
would deliver. I.e. xorriso waits with new READ(10) commands until enough
time has eleapsed since the last one. This causes the drive to make less
noise and to let the "CMCMAG/CN2/0" media survive 20 read runs without
visible damage:

  xorriso -for_backup -indev /dev/sr1 \
          -read_speed soft_force:4xBD \
          -check_media --

(The Linux kernel offers no such curb mechanism, i fear.)

In general i only feed the PIONEER with the RITEKs of which i have enough.
I now refrain from buying new "Verbatim" BD-RW, although it might be that
their plastic body became more sturdy meanwhile.


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#236467

> On June 25, 2021 at 5:49 AM Thomas Schmitt <scdbackup@gmx.net> wrote:
> 
> 
> Hi,
> 
> Michael Lange wrote:
> > If someone here can report about experience (good or bad) with specific
> > make and models (still not sure whether the next drive will be a DVD- or
> > BD-writer), it would be welcome...
> 
> In general i'd buy any brand of full height drives.
> I currently run 3 LGs, 2 ASUS, 1 Samsung, 1 Optiarc, 1 PIONEER.
> 
> It's more a matter of the individual drive than of the manufacturer or
> model. Not so good during the last 5 years were:
> - The flaky new DVD burner which i had to send back was a LITEON
>   iHAS124F. But i know of other iHASen which work well.
> - An LG GH24NSC0 became unreliable after only two years.
>   The LITEON was planned as replacement. In the end the job went to a
>   ASUS DRW-24D5MT.
> (Both did cost about 15 EUR. So any testing at the factory would eat up
> the manufacturer's profit.)
> 
> I always refrained from slim drives. User reports suggest that they are
> a bit less reliable. But your mileage may vary ...
> 
> --------------------------------------------------------------------------
> A little warning about PIONEER BDR-S09 might be appropriate:
> 
> Mine reads BD-RW with such a high (and not adjustable) speed and has such
> a strong grip on the medium, that two newer "Verbatim" BD-RW media
> developed a radial crack from the inner hole towards the writable area.
> With one of the media the crack reached the writable area and made the
> medium unreadable.
> This happened during stress tests after about 10 times of reading. The
> media bear the manufacturer id "CMCMAG/CN2/0". Older Verbatim BD-RW
> (VERBAT/IM0/0) or those from "Intenso", "Primeon" and "Maxcell"
> (all RITEK/BW1/1) did not suffer such a damage in 20 read runs at about
> 10x BD speed.
> The drive itself survived the intensive testing without problems.
> 
> I addressed the PIONEER BDR-S09's unwillingness to read with slower speed
> by special parameters of xorriso command -read_speed, which curb the drive
> speed by simply not taking more data per second than the desired speed
> would deliver. I.e. xorriso waits with new READ(10) commands until enough
> time has eleapsed since the last one. This causes the drive to make less
> noise and to let the "CMCMAG/CN2/0" media survive 20 read runs without
> visible damage:
> 
>   xorriso -for_backup -indev /dev/sr1 \
>           -read_speed soft_force:4xBD \
>           -check_media --
> 
> (The Linux kernel offers no such curb mechanism, i fear.)
> 
> In general i only feed the PIONEER with the RITEKs of which i have enough.
> I now refrain from buying new "Verbatim" BD-RW, although it might be that
> their plastic body became more sturdy meanwhile.
> 
> 
> Have a nice day :)
> 
> Thomas
>
I've had an LG GP08LU11, ROM version X01 "Super Multi DVD Rewriter" for several years,
and while it has not seen heavy use, it has always worked reliably, and now with a new
drive-less computer, I've had to use it more frequently. It has been reliable, and it
also will burn Lite-Scribe disk info into those disks, which many full-size built in
drives won't. Neither will the drive in a Dell laptop. As usual, YMMV.  --doug

[toc] | [prev] | [next] | [standalone]

#236593 — How to verify newly burned disc [Was: Fatal error while burning CD]

Hi,

On Thu, 24 Jun 2021 09:19:43 +0200
"Thomas Schmitt" <scdbackup@gmx.net> wrote:

(...)
> In any case, test it with all your intended use cases, as soon as it
> arrives.

Thanks, that definitely sounds like good advice (I had no idea that these
drives are so cheap these days, no wonder that they leave testing to the
customer :) .So for now I guess I'll have to consider myself beta-tester
for Asus (I finally picked no. 1 of 2 of these Asus DRW-24D5MTs from the
shelf, I hope that was the right choice :) (btw, thanks also to mcgarrett
for the feedback!).

I discovered then that, unless I missed something, that verifying the
success of the burning procedure appears to be surprisingly (to me at
least) non-trivial. For data-discs I finally found a recipe that seems to
work in the archives of debianforum.de :

$ cat whatever.iso | md5sum
50ab1d0cba4c1cedb61a6f22f55e75b7  -
$ wc -c whatever.iso
8237400064 whatever.iso
$ dd if=/dev/sr0 | head -c 8237400064 | md5sum
50ab1d0cba4c1cedb61a6f22f55e75b7  -

At least this gave me matches with the first two burned DVDs, so I
suppose that this is the way to go (or did I miss something more
obvious?). Unfortunately there is apparently no way to control the reading
speed here, so maybe one should be careful with these Pioneer drives :)

I could not find any way to verify the success after burning
audio-CDs though, except of course of carefully listening (the first one
burned with the new drive seems to sound ok at first glance, I haven't
found the time and leisure yet to listen attentively to 75 min. of
weird Japanese jazz-music though :)
So, does anyone know about a way to verify the integrity of burned
audio-CDs?

Best regards

Michael


.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

No one can guarantee the actions of another.
		-- Spock, "Day of the Dove", stardate unknown

[toc] | [prev] | [next] | [standalone]

#236594 — Re: How to verify newly burned disc [Was: Fatal error while burning CD]

[Multipart message — attachments visible in raw view] — view raw

Michael Lange writes:

[...]

> I discovered then that, unless I missed something, that verifying the
> success of the burning procedure appears to be surprisingly (to me at
> least) non-trivial. For data-discs I finally found a recipe that seems to
> work in the archives of debianforum.de :
>
> $ cat whatever.iso | md5sum
> 50ab1d0cba4c1cedb61a6f22f55e75b7  -
> $ wc -c whatever.iso
> 8237400064 whatever.iso
> $ dd if=/dev/sr0 | head -c 8237400064 | md5sum
> 50ab1d0cba4c1cedb61a6f22f55e75b7  -

I usually go for this kind of command:

	cmp whatever.iso /dev/sr0

If it reports "EOF on whatever.iso" its fine :)

This method does not, however, check the speed or any soft errors that the  
firmware and driver were able to correct. You could run a `dmesg -w` in  
parallel to find out about them in a qualitative way (if there are many  
"buffer IO errors" the burn quality could be bad?).

[...]

> I could not find any way to verify the success after burning
> audio-CDs though, except of course of carefully listening (the first one
> burned with the new drive seems to sound ok at first glance, I haven't
> found the time and leisure yet to listen attentively to 75 min. of
> weird Japanese jazz-music though :)
> So, does anyone know about a way to verify the integrity of burned
> audio-CDs?

[...]

Can you mount it and view the individual tracks as files?
Did you supply the .wav files exactly as they were going to be burnt unto  
the disc?

If both is yes, might it make sense to compare the individual track files  
against your supplied sources?

I have not tried to verify audio discs this way, though.

HTH and YMMV
Linux-Fan

öö

[toc] | [prev] | [next] | [standalone]

#236597 — Re: How to verify newly burned disc [Was: Fatal error while burning CD]

Hi,

On Tue, 29 Jun 2021 10:32:04 +0200
Linux-Fan <Ma_Sys.ma@web.de> wrote:

(...)
> I usually go for this kind of command:
> 
> 	cmp whatever.iso /dev/sr0
> 
> If it reports "EOF on whatever.iso" its fine :)

I think this is similar to that recipe from the debianforum, only that
the latter seems to be a little more refined. I guess I could wrap those
three commands in a little script, so I can do something like:

$ check-disc whatever.iso
Checksums match, thumbs up

resp.

$ check-disc whatever.iso
Checksums mismatch, thumbs down
 
(...)
> > So, does anyone know about a way to verify the integrity of burned
> > audio-CDs?
> 
> [...]
> 
> Can you mount it and view the individual tracks as files?

I don't think audio-CDs can be mounted.

> Did you supply the .wav files exactly as they were going to be burnt
> unto the disc?
> 
> If both is yes, might it make sense to compare the individual track
> files against your supplied sources?

The problem here might be that if the original .wav files' duration did
not match that 2352 bytes sector size (or whatever this is called :) of
the CDDA format and thus had to be padded with zeroes there will be a
difference even though the actual PCM data may be perfectly the same. Or
at least that is as I understand it :)

Thanks for the feedback, and best regards

Michael

.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

Uncontrolled power will turn even saints into savages.  And we can all
be counted on to live down to our lowest impulses.
		-- Parmen, "Plato's Stepchildren", stardate 5784.3

[toc] | [prev] | [next] | [standalone]

#236602 — Re: How to verify newly burned disc

Hi,

Michael Lange wrote:
> I discovered then that, unless I missed something, that verifying the
> success of the burning procedure appears to be surprisingly (to me at
> least) non-trivial.

In part because of the hardware properties of the various media types
and the associated drive firmware behavior.

In part because of a flaw in the specification of the SCSI command
READ CAPACITY with TAO CDs, which led to two decades of workarounds
by the burn programs - mostly based on a false theory about the cause
of the Linux i/o errors at the end of the media.
(It can be fixed in Linux for single session CDs. But multi-session CDs
will never play nice with the ahead-reading block device i/o of
Linux.)

In part because the specifications for DVD+R media might have led me
as developer of libburn to a wrong assumption about alignment needs of
this media type.
(I would have to waste a spindle of DVD+R in order to learn about the
real behavior of my drives if i omit aligment to 32 KiB.)


> For data-discs I finally found a recipe that seems to
> work in the archives of debianforum.de :
> $ wc -c whatever.iso
> 8237400064 whatever.iso
> $ dd if=/dev/sr0 | head -c 8237400064 | md5sum

Yes. See also the FAQ about Debian ISO images:
  https://www.debian.org/CD/faq/#verify

The trick is to curb the reader to the size of the ISO image for which
you know the checksum.
The ISO images themselves contain a data field with their filesystem
size. This may or may not be the size of the ISO image file.
So it is better to record both, image size and checksum for the purpose
of later verification.


> Unfortunately there is apparently no way to control the reading
> speed here, so maybe one should be careful with these Pioneer drives :)

You would need a filter program which takes care not to read more than
~ 20 MB/s. Then the drive slows down automatically.

(It is not decided who is at fault with the BD-RE cracks: Pioneer or
Verbatim or both ...)


> So, does anyone know about a way to verify the integrity of burned
> audio-CDs?

Success is normally judged by playing the CD on the intended player
device, which in most cases is not the CD burner.


Difficulties are to be expected if you want to verify the burn success
by audio data comparison:

There are programs like cdda2wav, readcd, or readom which read audio
data from CD media.
You may also use cdrskin to extract the tracks and compare them with the
original track data.

  mkdir /home/me/my_cd
  cdrskin -v dev=/dev/sr0 \
          extract_audio_to=/home/me/my_cd \
          cdtext_to_v07t=/home/me/my_cd/cdtext.v07t

This produces track files (NN = track number) and a CD-TEXT file

  /home/me/my_cd/NN.wav
  /home/me/my_cd/cdtext.v07t

The audio sectors lack the self-address field of data sectors, which
make the Logical Block Address an exact way of addressing data.
So it depends on the firmware's capability to exactly find the start
of each track.

Each extracted file gets from cdrskin a WAVE header of 44 bytes. This
could differ from the WAVE header of the original track input file.
The original header might even be larger.
Further the size of the extracted file will always be a multiple of
2352 bytes. The audio payload of the track input might be up to 2351
bytes less than that.
So you will have to extract the audio payload from the track input file
and from the extracted file. If you are lucky, the data start in the
track input file at byte offset 44 and reach up to the end of the file.


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#236735 — Re: How to verify newly burned disc

Hi,

On Tue, 29 Jun 2021 12:08:13 +0200
"Thomas Schmitt" <scdbackup@gmx.net> wrote:

(...)
> 
> > For data-discs I finally found a recipe that seems to
> > work in the archives of debianforum.de :
> > $ wc -c whatever.iso
> > 8237400064 whatever.iso
> > $ dd if=/dev/sr0 | head -c 8237400064 | md5sum
> 
> Yes. See also the FAQ about Debian ISO images:
>   https://www.debian.org/CD/faq/#verify
> 
> The trick is to curb the reader to the size of the ISO image for which
> you know the checksum.
> The ISO images themselves contain a data field with their filesystem
> size. This may or may not be the size of the ISO image file.
> So it is better to record both, image size and checksum for the purpose
> of later verification.

thanks for the detailed explanation. 
I managed to wrap these commands in a little script, so now I can do this
with a single command, I think this wil do the trick for my purpose.

> > Unfortunately there is apparently no way to control the reading
> > speed here, so maybe one should be careful with these Pioneer
> > drives :)
> 
> You would need a filter program which takes care not to read more than
> ~ 20 MB/s. Then the drive slows down automatically.
> 
> (It is not decided who is at fault with the BD-RE cracks: Pioneer or
> Verbatim or both ...)

I see, that does not sound trivial, at least to me :)
Fortunately there seems to be no danger with the Asus drive here, it does
not sound like it is spinning unreasonably fast when when using dd, so I
think it should be save just to skip this step.
 
> > So, does anyone know about a way to verify the integrity of burned
> > audio-CDs?
> 
> Success is normally judged by playing the CD on the intended player
> device, which in most cases is not the CD burner.
> 
> 
> Difficulties are to be expected if you want to verify the burn success
> by audio data comparison:
> 
(...)

Ok, I thought so. Checking success by listening to the CD playing on my
stereo will be good enough, I guess. And I`ll just assume that if data
discs are ok the same will be true for audio-CDs.
So far the Asus managed to pass all tests, so probably I should just be
grateful to all the transcendental authorities that guided my hand when I
picked that carton from the shelf :)

Thanks again for your patience, and have a nice day :-)

Michael

.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

Compassion -- that's the one things no machine ever had.  Maybe it's
the one thing that keeps men ahead of them.
		-- McCoy, "The Ultimate Computer", stardate 4731.3

[toc] | [prev] | [next] | [standalone]

#236739 — Re: How to verify newly burned disc

Hi,

i wrote:
> > You would need a filter program which takes care not to read more than
> > ~ 20 MB/s. Then the [Pioneer BDR-S09] drive slows down automatically.

Michael Lange wrote:
> I see, that does not sound trivial, at least to me :)

It would be a nice first exercise in about any programming language.
The first time i implemented such a thing was for a QIC tape drive
which overheated when running at full speed.


At the begin of this thread:
> > > [...] I finally picked no. 1 of 2 of these Asus DRW-24D5MTs [...]

> So far the Asus managed to pass all tests, so probably I should just be
> grateful to all the transcendental authorities that guided my hand when I
> picked that carton from the shelf :)

Does yours pull in the tray automatically after 200 seconds of standing
out ?

I made a little poll here about this behavior, 1.5 years ago:
  https://lists.debian.org/debian-user/2020/01/msg00421.html
Overview of result:
  https://lists.debian.org/debian-user/2020/02/msg00758.html

I wonder whether this is related to this obscure description on
  https://www.asus.com/Motherboards-Components/Optical-Drives/Internal-DVD-Drive/DRW-24D5MT/

  "E-Green technology auto-closes drive application when not in use,
   saving over 50% power consumption for users"

(What might be meant by "drive application" ?)


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#236774 — Re: How to verify newly burned disc

Hi,

On Fri, 02 Jul 2021 12:24:17 +0200
"Thomas Schmitt" <scdbackup@gmx.net> wrote:

> Hi,
> 
> i wrote:
> > > You would need a filter program which takes care not to read more
> > > than ~ 20 MB/s. Then the [Pioneer BDR-S09] drive slows down
> > > automatically.
> 
> Michael Lange wrote:
> > I see, that does not sound trivial, at least to me :)
> 
> It would be a nice first exercise in about any programming language.
> The first time i implemented such a thing was for a QIC tape drive
> which overheated when running at full speed.

I tried that, but as it seems without any effect on the drive's speed.
Maybe my efforts were not sufficient :)
Or maybe it is because the drive does not seem to spin as fast as the
Pioneer. It looks like when reading a DVD-RW it takes about 1.2 seconds
to read 10 MB of data; when I insert the Asus-CD, the drive spins
audibly faster, but surprisingly takes about 3 seconds to read 10 MB.

> 
> 
> At the begin of this thread:
> > > > [...] I finally picked no. 1 of 2 of these Asus DRW-24D5MTs [...]
> 
> > So far the Asus managed to pass all tests, so probably I should just
> > be grateful to all the transcendental authorities that guided my hand
> > when I picked that carton from the shelf :)
> 
> Does yours pull in the tray automatically after 200 seconds of standing
> out ?

Yes, it actually does.

> 
> I made a little poll here about this behavior, 1.5 years ago:
>   https://lists.debian.org/debian-user/2020/01/msg00421.html
> Overview of result:
>   https://lists.debian.org/debian-user/2020/02/msg00758.html

I remember that :)
Actually I thought I had participated, but that appears to be a false
memory.
For the record: afair the Plextor PX-810SA did nothing of that sort, Nor
does the 'TSSTcorp'  'CDDVDW SH-224DB' in the other machine.

> 
> I wonder whether this is related to this obscure description on
>   https://www.asus.com/Motherboards-Components/Optical-Drives/Internal-DVD-Drive/DRW-24D5MT/
> 
>   "E-Green technology auto-closes drive application when not in use,
>    saving over 50% power consumption for users"
> 
> (What might be meant by "drive application" ?)

I thought they just mean that it spins down after a few minutes, but who
knows? On the disc that came with the drive there is a "ASUS
E-Green.exe", so maybe we would need to install this first to fully enjoy
the Wonders of "E-Green"? :)

Best regards

Michael

.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

The joys of love made her human and the agonies of love destroyed her.
		-- Spock, "Requiem for Methuselah", stardate 5842.8

[toc] | [prev] | [next] | [standalone]

#236781 — Re: How to verify newly burned disc

Hi,

i wrote:
> ... > You would need a filter program which takes care not to read more
> ... > than ~ 20 MB/s.

Michael Lange wrote:
> I tried that, but as it seems without any effect on the drive's speed.
> Maybe my efforts were not sufficient :)

Did you test it with a superfast input like /dev/zero ?

  time dd if=/dev/zero bs=1M count=1024 | your_filter >/dev/null

Does it curb that stream and need the due time ?


> It looks like when reading a DVD-RW it takes about 1.2 seconds
> to read 10 MB of data; when I insert the Asus-CD, the drive spins
> audibly faster, but surprisingly takes about 3 seconds to read 10 MB.

A rough estimation yields a linear density increase from CD to DVD by
a factor of 2.5 (= sqrt(4480MB/700MB)). Multiplied by 1.2 this yields
roughly 3, but does not explain the extra noise.
You would need to read larger parts of the media to get an estimation
of noise/speed ratio.


> > Does yours pull in the tray automatically after 200 seconds of standing
> > out ?

> Yes, it actually does.

At least it is not a random feature of individual drives.


> > I made a little poll here about this behavior, 1.5 years ago:

> I remember that :)
> Actually I thought I had participated, but that appears to be a false
> memory.

It's my memory which goes dim. I have you on the result list with

Reporter              Drive                  Since  Media    Pulls
...
Michael Lange         Plextor PX-810SA       2007   DVD        no
Michael Lange         TSSTcorp SH-224DB      2013   DVD        no
...

I now added you with a 2021 ASUS DRW-24D5MT which pulls.


> > I wonder whether this is related to this obscure description
> >   "E-Green technology auto-closes drive application when not in use,
> >    saving over 50% power consumption for users"

> I thought they just mean that it spins down after a few minutes, but who
> knows?

The drives themselves have internal power management with timers for
partially shutting down the drive. The states are named "Active", "Idle",
and "Standby". The timer thresholds can be set by the computer. Further
the states can be ordered immediately by the computer.


> On the disc that came with the drive there is a "ASUS
> E-Green.exe", so maybe we would need to install this first to fully enjoy
> the Wonders of "E-Green"? :)

  https://www.techwalla.com/articles/what-is-the-asus-e-green-utility
could mean that the .exe agressively strives for "Standby" by setting low
timer thresholds. It seems also to be capable to count the time in that
state and to brag with its power savings.

If my /dev/sr0 is annoyingly excited after Linux block i/o i run

  xorriso -outdev /dev/sr0

which ends by a drive calming START/STOP UNIT command.

------------------------------------------------------------------

Another thing which makes me wonder about ASUS' description of the drive
is where they expect us to still find M-Disc DVD+R media. Last time i
looked i found only M-Disc BD-R (and some "currenlty unavailable" DVD
offers).


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web