Re: How to verify newly burned disc
Hi, i wrote: > > > where they [ASUS] expect us to still find M-Disc DVD+R media. Michael Lange wrote: > > 10 4.7 GB discs at 85.11 € + 7.31 € for shipping from Japan :-) > > Australia, 5 discs for "~" 21.74 € + ~ 42.97 shipping Wonders of globalization. > > the "killer" bargain: 10 Verbatims for ~ 46.11 € + free shipping! Wow. That's only 20 times the price of regular DVD-R or DVD+R media. (I see slightly cheaper offers for M-Disc BD-R 25 GB. Still 4 EUR per piece while normal BD-R cost about 50 cents.) Stefan Monnier wrote: > I wonder if "archival quality" really serves its purpose here. I mean, > I understand that flash is not reliable in the long term, but there's > also the problem of making sure you'll still have a working DVD reader > in the future. There are some reasons for hope: The specifications of media and drive behavior are publicly available. Lots of DVD and BD readers already exist. When rarely used they have a long life span. (I recently bought a Lindy USB box for a SATA drive. To my surprise it came with a SATA-IDE adapter. So i could use it for my old CD burner of 2003.) The separation of storage medium and storage device keeps the archive safer against electronics failure. Whether M-Disc is more reliable than organic dye discs has still to be proven. 1000 years is a courageous goal. At least i'd demand glass discs rather than polycarbonate. > I thought the only reliable way to archive digital data would be to > treat preservation as a *process*, where you "refresh" your archive > every N years by copying it over to a newer media (with enough > redundancy to detect and correct errors that may have crept in during > those N years). Indeed. It is important that archives get check-read regularly and that there is more than one identical copy of each medium. Optical media contain lots of error correction data. I add my own MD5s on the filesystem level. (I have a BD-RE which one drive regards as fully readable while all others and my MD5s say that a few blocks are damaged.) The most important verification run is directly after burning. During the last 20 years i never encountered a medium which later went bad without showing visible signs of physical damage. Have a nice day :) Thomas
Re: How to verify newly burned disc
> The first hit at ebay.de when searching for "m-disc dvd" shows an offer > for 10 4.7 GB discs at 85.11 € + 7.31 € for shipping from Japan :-) [...] > There is also an offer from Australia, 5 discs for "~" 21.74 € + ~ 42.97 Hmm... so that's in the order of about 1 €/GB >From a quick look at SSD and uSD prices, it seems flash memory is about an order of magnitude cheaper (and also a lot more convenient to write :-) ). I wonder if "archival quality" really serves its purpose here. I mean, I understand that flash is not reliable in the long term, but there's also the problem of making sure you'll still have a working DVD reader in the future. I thought the only reliable way to archive digital data would be to treat preservation as a *process*, where you "refresh" your archive every N years by copying it over to a newer media (with enough redundancy to detect and correct errors that may have crept in during those N years). Stefan
Re: How to verify newly burned disc
Hi, On Fri, 02 Jul 2021 21:22:00 +0200 "Thomas Schmitt" wrote: > 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 ? I did now, and it does (it took about 1 min. to read approx. 300 MB; without "pulling the brakes" it took about 1 sec.). Since I am no good with shell scripting I did not use dd though, but a simple Python function that I think does basically the same; the way I used to slow it down is quite primitive however (basically it just waits until 10 MB have been read and then sleeps for 2 sec.), which may be too simple to stop the drive from happily spinning on. > > > 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. I see, so CDs are generally slower than DVDs, and (no surprise) the DVD-RW is a bit slower here than a "real" (bought) DVD. > > > > > 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 MediaPulls > ... > Michael Lange Plextor PX-810SA 2007 DVDno > Michael Lange TSSTcorp SH-224DB 2013 DVDno > ... > > 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. Nice! This work here, too. :-) > > -- > > 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). Well, looks like this is not so hard. The first hit at ebay.de when searching for "m-disc dvd" shows an offer for 10 4.7 GB discs at 85.11 € + 7.31 € for shipping from Japan :-) They're Verbatim discs though, might be they break in the process :D There is also an offer from Australia, 5 discs for "~" 21.74 € + ~ 42.97 shipping (also Verbatim :) and a little bit further down the "killer" bargain: 10 Verbatims for ~ 46.11 € + free shipping! Buy now!! :-) Best regards Michael .-.. .. ...- . .-.. --- -. --. .- -. -.. .--. .-. --- ... .--. . .-. If some day we are defeated, well, war has its fortunes, good and bad. -- Commander Kor, "Errand of Mercy", stardate 3201.7
Re: How to verify newly burned disc
Hi, Greg Wooledge wrote: > Audio CDs do not have a file system. There's nothing to mount. There > are no ".wav files". Correct. Further the CD-DA sectors are not readable by the usual Linux block i/o. dd(1) and write(2) will throw error. Reading is done by special programs which use the SCSI command READ CD. The kernel offers this as ioctl(CDROMREADAUDIO). > 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. It's not that bad, although CD-DA is not well suitable for storing data. CDs have a structure named Table-Of-Content which records the start sectors of the tracks and of gaps between tracks. CD-DA sectors contain 2352 bytes of payload and some error correction. The main problem with reading a flawlessly recorded data stream is that the sectors do not contain a field which tells their sector number. So random addressing depends on the Q sub-channel bits which are few. This makes it somewhat tricky for the drive firmware to find exactly the sector with the given number. Nevertheless i expect a good drive with good medium to reproduce the same payload data as have been written. But the reader programs have to invent new WAVE headers for the extracted data. The original input files usually had such headers which did not get recorded on the CD. So these headers can differ. It is not totally trivial to find out the size of the WAVE/RIFF headers and the position of the audio payload 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. There are two aspects here: Read error mitigation and acoustic improvement. The former is meaningful for verifying the burn success. The latter is not. A burn should be regarded as failed or questionable if it is necessary to read sectors more than once. Richmond wrote: > Using Caja file manager I have put in the localtion bar (or rather it put > in) > cdda://sr0/ > [...] > It could be some clever stuff that caja is doing though. Possibly a gvfs feature. https://codesearch.debian.net/search?q=package%3Acaja+cdda https://codesearch.debian.net/search?q=package%3Agvfs+cdda%3A&literal=0 Possibly based on libcdio-cdda2 and libcdio-paranoia2 as actual CD-DA reader. https://packages.debian.org/unstable/gvfs-backends Have a nice day :) Thomas
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
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 MediaPulls ... Michael Lange Plextor PX-810SA 2007 DVDno Michael Lange TSSTcorp SH-224DB 2013 DVDno ... 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
Re: How to verify newly burned disc
Hi, On Fri, 02 Jul 2021 12:24:17 +0200 "Thomas Schmitt" 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
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
Re: How to verify newly burned disc
Hi, On Tue, 29 Jun 2021 12:08:13 +0200 "Thomas Schmitt" 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
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
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
