Re: How to verify newly burned disc [Was: Fatal error while burning CD]
On Fri, Jul 02, 2021 at 10:04:04PM +0100, Richmond wrote: > Greg Wooledge writes: > > Audio CDs do not have a file system. There's nothing to mount. There > > are no ".wav files". > Using Caja file manager I have put in the localtion bar (or rather it put in) > > cdda://sr0/ > > This shows me each of the wave files on the disk as track1.wav, > track2.wav etc. The disk is a pre-recorded one I bought in a shop. It > could be some clever stuff that caja is doing though. It is. If you select one of those and try to open it, a ripper program will be launched which will try to rip the CD-DA from the disc and convert it into a .wav file.
Re: How to verify newly burned disc [Was: Fatal error while burning CD]
Greg Wooledge writes: > On Fri, Jul 02, 2021 at 08:51:54PM +0100, Richmond wrote: >> Michael Lange writes: >> >> > So, does anyone know about a way to verify the integrity of burned >> > audio-CDs? >> > >> >> This is a bit speculative because I cannot test it, but: >> >> k3b and brasero have options to verify written cd. >> >> I think you could verify using diff, i.e. diff /dev/cdrom file.iso >> >> Or you could mount the cd image via the loopback device, mount the cd, >> and then compare the .wav files individually to find which one the error >> is in. > > Audio CDs do not have a file system. There's nothing to mount. There > are no ".wav files". > > To the best of my knowledge, there is no way to verify every bit of > audio on an audio CD. They're simply not structured in a way that makes > it possible to retrieve a stream of digital audio data. Programs that > "rip" CD audio to files use heuristics and multiple tries and fancy > stuff like that, trying to get a good approximation of the original data > back from the disc. > > One thing I suppose you could do is generate the CDDB "disc ID" which is > based on the CD's metadata (track lengths), and compare it to the expected > value. This will at least tell you whether you've got the right number > of audio tracks and the correct lengths. Using Caja file manager I have put in the localtion bar (or rather it put in) cdda://sr0/ This shows me each of the wave files on the disk as track1.wav, track2.wav etc. The disk is a pre-recorded one I bought in a shop. It could be some clever stuff that caja is doing though.
Re: How to verify newly burned disc [Was: Fatal error while burning CD]
On Fri, Jul 02, 2021 at 08:51:54PM +0100, Richmond wrote: > Michael Lange writes: > > > So, does anyone know about a way to verify the integrity of burned > > audio-CDs? > > > > This is a bit speculative because I cannot test it, but: > > k3b and brasero have options to verify written cd. > > I think you could verify using diff, i.e. diff /dev/cdrom file.iso > > Or you could mount the cd image via the loopback device, mount the cd, > and then compare the .wav files individually to find which one the error > is in. Audio CDs do not have a file system. There's nothing to mount. There are no ".wav files". To the best of my knowledge, there is no way to verify every bit of audio on an audio CD. They're simply not structured in a way that makes it possible to retrieve a stream of digital audio data. Programs that "rip" CD audio to files use heuristics and multiple tries and fancy stuff like that, trying to get a good approximation of the original data back from the disc. One thing I suppose you could do is generate the CDDB "disc ID" which is based on the CD's metadata (track lengths), and compare it to the expected value. This will at least tell you whether you've got the right number of audio tracks and the correct lengths.
Re: How to verify newly burned disc [Was: Fatal error while burning CD]
Michael Lange writes: > So, does anyone know about a way to verify the integrity of burned > audio-CDs? > This is a bit speculative because I cannot test it, but: k3b and brasero have options to verify written cd. I think you could verify using diff, i.e. diff /dev/cdrom file.iso Or you could mount the cd image via the loopback device, mount the cd, and then compare the .wav files individually to find which one the error is in.
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 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
Re: How to verify newly burned disc [Was: Fatal error while burning CD]
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 ΓΆΓΆ pgpPPQlh6zJ8m.pgp Description: PGP signature
How to verify newly burned disc [Was: Fatal error while burning CD]
Hi, On Thu, 24 Jun 2021 09:19:43 +0200 "Thomas Schmitt" 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
Re: Fatal error while burning CD
> On June 25, 2021 at 5:49 AM Thomas Schmitt 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
Re: Fatal error while burning CD
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
Re: Fatal error while burning CD
Hi,
On Fri, 25 Jun 2021 08:44:58 +0200
"Thomas Schmitt" 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 0x12 = 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
Re: Fatal error while burning CD
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 0x12 = 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
Re: Fatal error while burning CD
Hi, On Thu, 24 Jun 2021 14:18:08 +0200 "Thomas Schmitt" 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
Re: Fatal error while burning CD
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
Re: Fatal error while burning CD
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
Re: Fatal error while burning CD
Hi, On Thu, 24 Jun 2021 09:19:43 +0200 "Thomas Schmitt" 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
Re: Fatal error while burning CD
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
Re: Fatal error while burning CD
Hi, thanks for the quick responese! On Wed, 23 Jun 2021 20:58:17 +0200 "Thomas Schmitt" 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
Re: Fatal error while burning CD
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
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
