Re: Announcing cdrskin-0.4.4
On Tue, Apr 15, 2008 at 3:51 PM, Thomas Schmitt [EMAIL PROTECTED] wrote: i made some changes to the WRITE12 streaming commands. With DVD-RAM the last buffer of a write session is padded up to its full size. With BD-RE the buffer size is set to 64 KiB Now it works with both DVD-RAM and BD-RE! md5sums match. For the BD-RE, i reformatted it with ssa=default INQUIRY:[HL-DT-ST][BD-RE BE06LU10 ][YE03] GET [CURRENT] CONFIGURATION: Mounted Media: 43h, BD-RE Media ID: LGEBRE/S01 Current Write Speed: 2.0x4495=8992KB/s Write Speed #0:2.0x4495=8992KB/s GET [CURRENT] PERFORMANCE: Write Performance: 2.0x4495=8992KB/[EMAIL PROTECTED] - 11826175] Speed Descriptor#0:02/11826175 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s BD SPARE AREA INFORMATION: Spare Area:393216/393216=100.0% free = stream on $ time cdrskin --allow_setuid --allow_untested_media -v -sao -data dev=$cddev dr iveropts=burnfree padsize=512s stream_recording=on data.iso cdrskin 0.4.5 : limited cdrecord compatibility wrapper for libburn cdrskin: verbosity level : 1 cdrskin: NOTE : greying out all drives besides given dev='/dev/sg1' cdrskin: scanning for devices ... cdrskin: ... scanning for devices done cdrskin: beginning to burn disc cdrskin: status 1 burn_disc_blank The drive holds a blank disc Current: BD-RE Track 01: data 5259 MB padsize: 1024 KB Total size: 5260 MB (598:33.37) = 2693353 sectors Lout start: 5260 MB (598:35/37) = 2693353 sectors Starting to write CD/DVD at speed MAX in real SAO mode for single session. Last chance to quit, starting real write in 0 seconds. Operation starts. Waiting for reader process to fill input buffer ... input buffer ready. Starting new track at sector: 0 Track 01: 5260 of 5260 MB written (fifo 100%) [buf 100%] 2.4x. cdrskin: thank you for being patient since 535 seconds Track 01: Total bytes read/written: 5514938368/5516034048 (2693376 sectors). Writing time: 535.182s Cdrskin: fifo had 2692841 puts and 2692841 gets. Cdrskin: fifo was 0 times empty and 232624 times full, min fill was 99%. Min drive buffer fill was 16% cdrskin: burning done real8m55.722s user0m9.150s sys 0m34.500s = stream off $ time cdrskin --allow_setuid --allow_untested_media -v -sao -data dev=$cddev dr iveropts=burnfree padsize=512s data.iso cdrskin 0.4.5 : limited cdrecord compatibility wrapper for libburn cdrskin: verbosity level : 1 cdrskin: NOTE : greying out all drives besides given dev='/dev/sg1' cdrskin: scanning for devices ... cdrskin: ... scanning for devices done cdrskin: beginning to burn disc cdrskin: status 1 burn_disc_blank The drive holds a blank disc Current: BD-RE Track 01: data 5259 MB padsize: 1024 KB Total size: 5260 MB (598:33.37) = 2693353 sectors Lout start: 5260 MB (598:35/37) = 2693353 sectors Starting to write CD/DVD at speed MAX in real SAO mode for single session. Last chance to quit, starting real write in 0 seconds. Operation starts. Waiting for reader process to fill input buffer ... input buffer ready. Starting new track at sector: 0 Track 01: 5260 of 5260 MB written (fifo 100%) [buf 95%] 1.8x. cdrskin: thank you for being patient since 1269 seconds Track 01: Total bytes read/written: 5514938368/5515986944 (2693353 sectors). Writing time: 1269.126s Cdrskin: fifo had 2692841 puts and 2692841 gets. Cdrskin: fifo was 0 times empty and 310341 times full, min fill was 99%. Min drive buffer fill was 23% cdrskin: burning done real21m9.857s user0m9.010s sys 0m34.030s DVD-RAM with stream on: Current: DVD-RAM Track 01: data 100 MB padsize: 1024 KB Total size: 101 MB (11:33.90) = 51893 sectors Lout start: 101 MB (11:35/90) = 51893 sectors Starting to write CD/DVD at speed MAX in real SAO mode for single session. Last chance to quit, starting real write in 0 seconds. Operation starts. Waiting for reader process to fill input buffer ... input buffer ready. Starting new track at sector: 0 Track 01: 101 of 101 MB written (fifo 100%) [buf 100%] 2.1x. cdrskin: thank you for being patient since 41 seconds Track 01: Total bytes read/written: 105228288/106299392 (51904 sectors). Writing time: 41.108s Cdrskin: fifo had 51381 puts and 51381 gets. Cdrskin: fifo was 0 times empty and 4945 times full, min fill was 99%. Min drive buffer fill was 92% cdrskin: burning done DVD-RAM with stream off: Current: DVD-RAM Track 01: data 100 MB padsize: 1024 KB Total size: 101 MB (11:33.90) = 51893 sectors Lout start: 101 MB (11:35/90) = 51893 sectors Starting to write CD/DVD at speed MAX in real SAO mode for single session. Last chance to quit, starting real write in 0 seconds. Operation starts. Waiting for reader process to fill input buffer ... input buffer ready. Starting new track at sector: 0 Track 01: 101 of 101 MB written (fifo 100%) [buf 100%] 1.0x. cdrskin:
Re: Announcing cdrskin-0.4.4
Hi, i made some changes to the WRITE12 streaming commands. Now it works with both DVD-RAM and BD-RE! md5sums match. I'm good in guessing :)) Now it works for your one BD-RE drive, your DVD-RAM drive and my DVD-RAM drives. At least it gives hope that a substantial fraction of other drives would work like intended, too. One problem with the general validity is the fact that WRITE12 is obviously not intended for media with defect management. Each implementer of drive firmware has the freedom to impose own constraints or even to refuse on this combination. So, basically, using streaming i/o will compensate for free (I mean you get exactly the same result on disc as not using streaming) the slow down caused by defect management? It depends on the number and pattern of bad spots on the media. No bad spots will make stream_recording=on the winner. A few bad spots with fast defect repair will make stream_recording=off better, because you do not have to repeat the burn run and your verification. Many bad spots or slow defect repair will make defect management uneconomic. In that situation it would probably be better to have a quick failure and to retry with better media. With my Philips DVD-RAM drive it is clear that defect management is only helpful if i have to write a small amount of important data. In case of several defects it is unbearably slow. So if i were struck with DVD-RAM i would trash those which have bad spots and use the others with stream_recording=on. But i got my DVD-RAM only for testing purposes. For the same reason i got that whimpy Philips drive. It produces more problems than any other of my drives. Today it declared a DVD+R closed which two other drives see as appendable. Shrug. With BD-RE and their high capacity and price, one may well decide to keep faulty ones and operate them without stream_recording. Important advise: You should make a full scale write test with your media and 25 GB of data. I myself will have to learn more about formatting of DVD-RAM and BD-RE now. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcing cdrskin-0.4.4
Thomas Schmitt wrote: Hi, i wrote: Like: 1 hour 40 minutes is too long for a backup window. Rob Bogus wrote: That I can accept, I was going to post something similar. This all would be no issue if there was an alternative to BD-RE media like there are alternatives to DVD-RAM. I tested DVD-RAM, said blargh, and decided to use DVD+RW. With re-writeable BD one has to craft BD+RW from BD-RE. Even then it lasts nearly an hour to fill a BD disc. (Reminds me of my first 2x Yamaha CD-RW burner.) Or: The media are perfect and never ever show any bad spot. That sounds like a fairy tale. If the media would be as good as DVD+RW on my various drives then it would be ok for backup purposes. A severe problem is the larger size of BD media. Assumed similar probability of write failures per MB, you have to expect at least 5 times more misburns than with DVD+RW. That would be indeed unbearable. Ideally a copy of the backup would be held for byte-by-byte verify, and bad spots (only bad spots) would be rewritten. That assumes that they CAN be written successfully eventually. All solutions are ugly. I recommend multi-copy backups for long term archiving. I.e. identical images on several media all covered by the same list of block checksums (64 kB blocks). But that needs buffer storage on hard disk in order to truely get identical copies. Buffer storage for 25 GB is not appealing. Especially since i recently got rid of buffer storage for oversized files. Having a large buffer for large backups may be the only practical solution. I do use dvdisaster software for critical backups, it occasionally really saves the day, although it is slow when calculating the ECC codes to burn. Combined with dual layer DVD to reduce the number of media changes I can do practical backups. My usage scenario for a full speed BD-RE run would be short term backups which are allowed to fail from time to time. Not too often. If BD-RE with defect management is as ill as DVD-RAM on my Philips drive, then it is no real solution either. Imagine the backup operator sitting in front of a gnawing drive since hours. Pondering whether to finally abort the backup or whether to hope for the normal lame speed to come back. DVD-RAM is nearly unusable for me. If BD-RE is as bad, then i'll need to buy a tape drive for the next generation of backup media. My disk is 500 GB and my backup media are less than 5 GB. One can do a lot with multi-volume and incremental. But finally the backup data need to get onto media in a reasonable time. I don't know what external drives cost in Europe, they are about $130 for 500GB in the US. That makes verified backups pretty cheap for 500GB. The cost effective solution for too much cheap disk may be more cheap disk. The cost of BD media is coming down slowly, but that is still far less cost per GB than the disk drive. I burn most critical data on DVD for off-site backup, but daily still goes on those USB drives. So if it is possible to run BD-RE at 9.5 MB/s without too many misburns, then it is better than nothing. Still not good, i confess. I hope Giulio will tell us about his experiences. -- Bill Davidsen [EMAIL PROTECTED] Woe unto the statesman who makes war without a reason that will still be valid when the war is over... Otto von Bismark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcing cdrskin-0.4.4
Hi, The cost effective solution for too much cheap disk may be more cheap disk. Indeed. Having enough disk buffer for the whole backup can solve most of the problems caused by the disproportion of size and speed with BD-RE. One could direct the backup to external disk on the first hand and thus get a small backup time window. The result could then be copied onto BD-RE. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcing cdrskin-0.4.4
Hi, AFAIK stream i/o will not disable defect repair, so this protection will still be active I doubt it does checkread for badly written blocks. The increased speed indicates we successfully disabled normal defect management. If the drive encounters a perceivable error during write then it may or may not issue a write error code. But the extra checking and the replacing is most probably disabled by stream_recording=on . So, if firmware/media accept stream i/o, what would be a good reason not to use it? Bad spots. :)) We explore an unusual region of the MMC landscape. Whether it is harmless or not, whether it is usable or not, has still to be found out. You are the test pilot. Congrats. :)) We know meanwhile two ways to get the drive to full nominal media speed. One permanent and with any burn program that accepts BD-RE. One run-by-run via cdrskin stream_recording=on which allows you to stay with normally formatted BD-RE media. We do not know what happens if the write operation to a 64 K cluster goes bad. Neither with half speed nor with one of our two full-speed tricks. With full speed you will possibly learn from unusual long writing time and from some failed MD5. With half speed ... well i have no idea how good it does on bad spots. If the first time a bad spot sabotages a burn run, then it would be interesting to see whether it vanishes by a full certification re-format. This is where i see the most advantage of stream recording over no-spare formatting. But first it would be interesting to study the behavior and consequences of a bad spot. Does it vanish if one writes to it in normal half-speed mode for once ? I guess you are not in a hurry with encountering bad spots. But if one pops up, then please report. What's the difference between fast defect repair and slow defect repair? Strictly heuristic classification. These are not terms of the technical specs but just the grade of perceived suffering while watching the (non-)progress of the burn run. The slow one is like my DVD-RAM which seems to waste a lot of time with unsuccessful write retries and then finally uses spare blocks. This lengthens the write time of 125 MB from about 120 seconds without defect to 2025 seconds with defects. At most 2 percent of the first 125 MB of the media are bad. The fast one would be swift and not slow down a burn by several hundred percent if it encounters a few bad spots. It would be the one which i expect when paying substantial money for drive and media. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcing cdrskin-0.4.4
Hi, i made some changes to the WRITE12 streaming commands. With DVD-RAM the last buffer of a write session is padded up to its full size. With BD-RE the buffer size is set to 64 KiB which seems to be the natural size for a BD transaction. The last buffer gets padded, too. To Giulio Orsero: Please get http://scdbackup.sourceforge.net/cdrskin-0.4.5.tar.gz Version timestamp : 2008.04.15.094545 (or later) and try whether stream_recording=on now works with your DVD-RAM and yields satisfying speed. Next time you have a BD-RE which is formatted for defect management (i.e. slow), please test whether the new output buffer size made work stream_recording=on . Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcing cdrskin-0.4.4
Hi, i wrote: Like: 1 hour 40 minutes is too long for a backup window. Rob Bogus wrote: That I can accept, I was going to post something similar. This all would be no issue if there was an alternative to BD-RE media like there are alternatives to DVD-RAM. I tested DVD-RAM, said blargh, and decided to use DVD+RW. With re-writeable BD one has to craft BD+RW from BD-RE. Even then it lasts nearly an hour to fill a BD disc. (Reminds me of my first 2x Yamaha CD-RW burner.) Or: The media are perfect and never ever show any bad spot. That sounds like a fairy tale. If the media would be as good as DVD+RW on my various drives then it would be ok for backup purposes. A severe problem is the larger size of BD media. Assumed similar probability of write failures per MB, you have to expect at least 5 times more misburns than with DVD+RW. That would be indeed unbearable. Ideally a copy of the backup would be held for byte-by-byte verify, and bad spots (only bad spots) would be rewritten. That assumes that they CAN be written successfully eventually. All solutions are ugly. I recommend multi-copy backups for long term archiving. I.e. identical images on several media all covered by the same list of block checksums (64 kB blocks). But that needs buffer storage on hard disk in order to truely get identical copies. Buffer storage for 25 GB is not appealing. Especially since i recently got rid of buffer storage for oversized files. My usage scenario for a full speed BD-RE run would be short term backups which are allowed to fail from time to time. Not too often. If BD-RE with defect management is as ill as DVD-RAM on my Philips drive, then it is no real solution either. Imagine the backup operator sitting in front of a gnawing drive since hours. Pondering whether to finally abort the backup or whether to hope for the normal lame speed to come back. DVD-RAM is nearly unusable for me. If BD-RE is as bad, then i'll need to buy a tape drive for the next generation of backup media. My disk is 500 GB and my backup media are less than 5 GB. One can do a lot with multi-volume and incremental. But finally the backup data need to get onto media in a reasonable time. So if it is possible to run BD-RE at 9.5 MB/s without too many misburns, then it is better than nothing. Still not good, i confess. I hope Giulio will tell us about his experiences. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcing cdrskin-0.4.4
On Sat, Apr 12, 2008 at 8:00 PM, Thomas Schmitt [EMAIL PROTECTED] wrote: Next time you have a BD-RE formatted with spare area please try a write run with these options: $ cdrskin stream_recording=on --allow_untested_media BD-RE formatted with ssa=default == BD-RE, USB burner (2.4 usb/scsi), stream_recording=on == FAILS: does not even start writing Current: BD-RE Track 01: data 100 MB padsize: 1024 KB Total size: 101 MB (11:33.90) = 51893 sectors Lout start: 101 MB (11:35/90) = 51893 sectors Starting to write CD/DVD at speed MAX in real SAO mode for single session. Last chance to quit, starting real write in 0 seconds. Operation starts. Waiting for reader process to fill input buffer ... input buffer ready. Starting new track at sector: 0 cdrskin: FATAL : SCSI error on write(0,16): key=5 asc=24h ascq=00h Track 01: Total bytes read/written: 32768/0 (0 sectors). Writing time: 0.228s Cdrskin: fifo had 2065 puts and 17 gets. Cdrskin: fifo was 0 times empty and 0 times full, min fill was 100%. Min drive buffer fill was 50% cdrskin: burning failed cdrskin: FATAL : burning failed. == == DVD-RAM, IDE burner (2.4 ide-scsi), stream_recording=on == FAILS at the end: md5sums do not match (average speed 2x) Current: DVD-RAM Track 01: data 100 MB padsize: 1024 KB Total size: 101 MB (11:33.90) = 51893 sectors Lout start: 101 MB (11:35/90) = 51893 sectors Starting to write CD/DVD at speed MAX in real SAO mode for single session. Last chance to quit, starting real write in 0 seconds. Operation starts. Waiting for reader process to fill input buffer ... input buffer ready. Starting new track at sector: 0 Track 01: 101 of 101 MB written (fifo 100%) [buf 100%] 2.1x. cdrskin: FATAL : SCSI error on write(51888,5): key=5 asc=24h ascq=00h cdrskin: thank you for being patient since 38 seconds Track 01: Total bytes read/written: 105228288/106266624 (51888 sectors). Writing time: 38.438s Cdrskin: fifo had 51381 puts and 51381 gets. Cdrskin: fifo was 0 times empty and 4930 times full, min fill was 99%. Min drive buffer fill was 96% cdrskin: burning failed cdrskin: FATAL : burning failed. == == DVD-RAM, IDE burner (2.4 ide-scsi), NO stream_recording == SUCCESS: md5sums do match (average speed 1x) Current: DVD-RAM Track 01: data 100 MB padsize: 1024 KB Total size: 101 MB (11:33.90) = 51893 sectors Lout start: 101 MB (11:35/90) = 51893 sectors Starting to write CD/DVD at speed MAX in real SAO mode for single session. Last chance to quit, starting real write in 0 seconds. Operation starts. Waiting for reader process to fill input buffer ... input buffer ready. Starting new track at sector: 0 Track 01: 101 of 101 MB written (fifo 100%) [buf 96%] 1.0x. cdrskin: thank you for being patient since 86 seconds Track 01: Total bytes read/written: 105228288/106276864 (51893 sectors). Writing time: 87.131s Cdrskin: fifo had 51381 puts and 51381 gets. Cdrskin: fifo was 0 times empty and 9575 times full, min fill was 99%. Min drive buffer fill was 73% cdrskin: burning done == -- [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcing cdrskin-0.4.4
On Sat, Apr 12, 2008 at 9:25 PM, Thomas Schmitt [EMAIL PROTECTED] wrote: $ dvd+rw-format -format=full /dev/cdrom * BD/DVD±RW/-RAM format utility by [EMAIL PROTECTED], version 7.1. * 25.0GB BD media detected. * formatting 0.0|:-[ FORMAT UNIT failed with SK=5h/INVALID FIELD IN PARAMETER LIST]: Input/output error $ If you want to go back to a smaller format you will probably need to give an explicit -ssa=size. I read in dvd+rw-format.cpp : -ssa=default After reformatting with -ssa=default I was able to complete a -format=full, it took 80mins. -- [EMAIL PROTECTED]
Re: Announcing cdrskin-0.4.4
On Sat, Apr 12, 2008 at 10:05 PM, Andy Polyakov [EMAIL PROTECTED] wrote: What is it with desire to bypass defect management? I mean I can perfectly understand Thomas's curiosity, but why would end-user such as Giulio want it off? So you say my time is so precious that I must have faster write at any cost, ... so I can have time to verify afterwards? But why not let drive do it during recording then? The time would be the same. Unfortunately, as of now, time is not the same. Example with ISO if 5259 MB defect management engaged: writing takes 21min defect management disengaged: writing takes 9min w/o defect management I save 12min In any case (w/ or w/o defect management) I do an md5sum at the end (it takes 9min). I only use re-writable media. -- [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcing cdrskin-0.4.4
Hi, Giulio Orsero wrote: == BD-RE, USB burner (2.4 usb/scsi), stream_recording=on cdrskin: FATAL : SCSI error on write(0,16): key=5 asc=24h ascq=00h 5 24 00 INVALID FIELD IN CDB The drive does not like the first WRITE12 command. == DVD-RAM, IDE burner (2.4 ide-scsi), stream_recording=on Total size: 101 MB (11:33.90) = 51893 sectors cdrskin: FATAL : SCSI error on write(51888,5): key=5 asc=24h ascq=00h The drive does not like the last WRITE12 command. 3243 previous WRITE12 commands succeeded. The drive has no clue that this shall be the last of the WRITE12 commands. So it looks like the drive wants full 32 KB transfers rather than this final 10 KB write. My own USB attached DVD-RAM drive can stand odd numbers of blocks. E.g. 19583. The transfer size might also be the reason for the failure with BD-RE. Maybe it needs 64 kB. I'll have to read the specs for hints. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcing cdrskin-0.4.4
Hi, i tested WRITE12 and Streaming bit on DVD-RAM. Up to the first bad spot on my test media writing runs with nearly nominal speed: Effective 1.8x with nominal 2x DVD-RAM. Without Streaming bit, WRITE12 and WRITE10 both perform at 0.8x effective speed. - To Giulio: Please get the newest cdrskin-0.4.5 development tarball http://scdbackup.sourceforge.net/cdrskin-0.4.5.tar.gz $ cdrskin -version ... Version timestamp : 2008.04.12.164930 or later timestamp. Next time you have a BD-RE formatted with spare area please try a write run with these options: $ cdrskin stream_recording=on --allow_untested_media - Observations with DVD-RAM: Interesting with normal writing is that the drive buffer bounces between 5% and 99% fill. One could well misinterpret this as a lack of i/o bandwidth. With Streaming bit, the drive buffer is always 99% full. The first reproducible bad spot (after 75 MB) makes both write variants quite unbearable. The drive gnaws a while, plonks, and does that again several times before going on with writing. If this happened with Streaming bit then the media produces lots of media error entries in /var/log/messages when trying to read sequentially over the bad address. With WRITE10 the same image and media are readable and verificable afterwards. But writing of 125 MB needed more than half an hour. This readability is not a statistically founded observation. I also had MD5 verification failures on DVD-RAM in the past. With two bad spots (one around 75 MB and one at 117 MB) it lasts 383 seconds to write 125 MB by WRITE12 Streaming. It lasts 2024 seconds with WRITE10. So the drive (Philips SPD3300L) and the media (Panasonic 2x DVD-RAM) together are not really recommendable. I will try to heal it by re-formatting in the next days. - Standards consideration: WRITE12 is not associated with the features comprising the profiles of DVD-RAM and BD-RE. So i cannot conclude from the presence and writeability of a DVD-RAM or BD-RE to the availability of WRITE12. It belongs to all other DVD+/- features, though. On my drive it obviously has an effect on DVD-RAM writing. Feature 107h belongs to DVD-RAM and BD-RE. It can indicate a Stream Writing bit which promises the Stream recording operation. That operation seems to be associated with WRITE12. Another method to find out about WRITE12 would be a test write to the start address before payload writing begins at the same address. I will have to think more about WRITE12. For now it is heavily experimental. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcing cdrskin-0.4.4
Hi, [dvd+rw-format] -format=full I think my kernel is too old, it exit after just 1 second: $ dvd+rw-format -format=full /dev/cdrom * BD/DVD±RW/-RAM format utility by [EMAIL PROTECTED], version 7.1. * 25.0GB BD media detected. * formatting 0.0|:-[ FORMAT UNIT failed with SK=5h/INVALID FIELD IN PARAMETER LIST]: Input/output error $ This looks rather like dvd+rw-format and your drive do not agree on what is a proper FORMAT UNIT command. The kernel has only the role of transporting command and answer. This it seems to do fine. The problem could be about this line in dvd+rw-format.cpp: if ((formats[4+4]3)==2)// same capacity for already formatted Since the -ssa=none format 31h is the largest of all, you cannot get a 30h format of the same size. That capacity wish would be the invalid filed in the command. If you want to go back to a smaller format you will probably need to give an explicit -ssa=size. I read in dvd+rw-format.cpp : -ssa=default Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcing cdrskin-0.4.4
(i.e. no spare area) by dvd+rw-format option -ssa=none It might also be worth to check the impact of certification on write error detection. I.e.: -format=full I would propose to try both. It would be most economic to do -ssa=none first, because i would expect it to be the most likely to omit error detection on traditional WRITE10 (SCSI command 2Ah). With -format=full i would possibly expect that WRITE12 (command AAh) is needed. What is it with desire to bypass defect management? I mean I can perfectly understand Thomas's curiosity, but why would end-user such as Giulio want it off? So you say my time is so precious that I must have faster write at any cost, ... so I can have time to verify afterwards? But why not let drive do it during recording then? The time would be the same. The drive is in position to do better job and it makes perfect sense to let it. Indeed, if result of your checksum test fail, what options do you have? Try recording once again spending double your precious time? In BD-R case even discard media, which is pretty expensive, isn't it? So if your time is so precious to you, defect management is actually *saving* it for you. Not to mention money and *data* itself. The only reason to bypass defect management would be real-time recordings, but then it's likely to be a video recording when it's more important to keep recording, then to miss a second. For any kind of *storage* application, i.e. kind of applications we discuss here, bypassing defect management makes *no sense* *whatsoever*. There seems to be a WRITE12 experiment ready in dvd+rw-tools-7.1/growisofs_mmc.cpp Maybe Andy Polykov already knows more about that topic. Yes, commented out WRITE12 code in growisofs_mmc.cpp was used in a defect management bypass experiment in DVD-RAM. Its purpose was to satisfy curiosity, such as what would it take for *another* kind of application. Kind of application that would also have to handle so called enhanced defect management codes. It's not in production and I have no intention to put into production for reasons discussed above. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcing cdrskin-0.4.4
Hi, What is it with desire to bypass defect management? I mean I can perfectly understand Thomas's curiosity, but why would end-user such as Giulio want it off? I can squeeze some scenarios out of my phantasy. Like: 1 hour 40 minutes is too long for a backup window. Or: The media are perfect and never ever show any bad spot. But i agree that disabling defect management needs good reasons and skilled handling of the consequences. So you say my time is so precious that I must have faster write at any cost, ... so I can have time to verify afterwards? Wearing my scdbackup hat, i object the equivalence of hardware defect management and a verification which uses the same means as a future restore run. It's nice to know that the drive cares for error detection and spare block management. But it is not overly trustworthy. I evaluated DVD-RAM a few years ago and found them less reliable than DVD+RW (with my old LG drive). I used growisofs-6.0 and the original formatting which still is: formatted: 2236704*2048=4580769792 00h(800): 2236704*2048=4580769792 00h(800): 2295072*2048=4700307456 01h(800): 2226976*2048=4560846848 01h(800): 2217248*2048=4540923904 This obviously includes defect management reserves. At least it ran at 0.7x DVD speed. Today defect management worked, although terribly slow, where plain writing yielded a bad burn. Maybe it's also a matter of drive and firmware. But as backup programmer i need my own test or i cannot lean back and smile. So the argument that one cannot save time by disabling defect management depends on the use case. Your opinion wins in many of those cases, i confess. such as what would it take for *another* kind of application. I begin to ponder how i can convince the libisofs developers of having a defect list in the ISO formatter. Possibly they will call me insane. Good. I have a reputation to defend. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcing cdrskin-0.4.4
Thomas Schmitt wrote: Hi, What is it with desire to bypass defect management? I mean I can perfectly understand Thomas's curiosity, but why would end-user such as Giulio want it off? I can squeeze some scenarios out of my phantasy. Like: 1 hour 40 minutes is too long for a backup window. That I can accept, I was going to post something similar. Or: The media are perfect and never ever show any bad spot. That sounds like a fairy tale. But i agree that disabling defect management needs good reasons and skilled handling of the consequences. So you say my time is so precious that I must have faster write at any cost, ... so I can have time to verify afterwards? Wearing my scdbackup hat, i object the equivalence of hardware defect management and a verification which uses the same means as a future restore run. Agree, if you want trust you are going to verify the backup anyway. It's nice to know that the drive cares for error detection and spare block management. But it is not overly trustworthy. I evaluated DVD-RAM a few years ago and found them less reliable than DVD+RW (with my old LG drive). I used growisofs-6.0 and the original formatting which still is: formatted: 2236704*2048=4580769792 00h(800): 2236704*2048=4580769792 00h(800): 2295072*2048=4700307456 01h(800): 2226976*2048=4560846848 01h(800): 2217248*2048=4540923904 This obviously includes defect management reserves. At least it ran at 0.7x DVD speed. Today defect management worked, although terribly slow, where plain writing yielded a bad burn. Maybe it's also a matter of drive and firmware. I would say that the drives have been designed to make writing work, without adding cost to make them work *well*. The only obvious way to get the speed up is a full read after write head, which introduces several cost factors. These drives are being used out of their intended use pattern, and show it. The user has a choice of solutions, none really satisfactory. But as backup programmer i need my own test or i cannot lean back and smile. So the argument that one cannot save time by disabling defect management depends on the use case. Ideally a copy of the backup would be held for byte-by-byte verify, and bad spots (only bad spots) would be rewritten. That assumes that they CAN be written successfully eventually. All solutions are ugly. Your opinion wins in many of those cases, i confess. such as what would it take for *another* kind of application. I begin to ponder how i can convince the libisofs developers of having a defect list in the ISO formatter. Possibly they will call me insane. Good. I have a reputation to defend. Have a nice day :) Thomas -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcing cdrskin-0.4.4
On Thu, Apr 10, 2008 at 10:53 PM, Thomas Schmitt [EMAIL PROTECTED] wrote: Your operating system seems to be a kernel 2.4. 2.4.33 kernel.org On modern 2.6 it is supposed that one can write to the formatted area of BD-RE via the plain block device. dd if=test.iso of=/dev/sr0 bs=32K On kernel 2.4 this would work with DVD-RAM. No idea whether your kernel will accept BD-RE. On BD-RE it fails with $ dd if=/dev/zero of=/dev/scd0 bs=32k dd: opening `/dev/scd0': Read-only file system $ it works ok on DVD-RAM media. -- [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcing cdrskin-0.4.4
On Thu, Apr 10, 2008 at 11:42 PM, Thomas Schmitt [EMAIL PROTECTED] wrote: http://scdbackup.sourceforge.net/cdrskin-0.4.5.tar.gz MD5: 2ae5d8f06d4847f5436bb99441dfc5cd After compilation and install it should report on $ cdrskin -version Version timestamp : 2008.04.10.211529 $ cdrskin -version cdrskin 0.4.5 : limited cdrecord compatibility wrapper for libburn Cdrecord 2.01-Emulation Copyright (C) 2006-2008, see libburnia-project.org libburn interface : 0.4.5 libburn in use: 0.4.5 cdrskin version : 0.4.5 Version timestamp : 2008.04.10.211926 Build timestamp : -none-given- it now works ok cdrskin 0.4.5 : limited cdrecord compatibility wrapper for libburn cdrskin: verbosity level : 1 cdrskin: NOTE : greying out all drives besides given dev='/dev/sg1' cdrskin: scanning for devices ... cdrskin: ... scanning for devices done cdrskin: beginning to burn disc cdrskin: status 1 burn_disc_blank The drive holds a blank disc Current: BD-RE Track 01: data 5259 MB padsize: 1024 KB Total size: 5260 MB (598:33.38) = 2693354 sectors Lout start: 5260 MB (598:35/38) = 2693354 sectors Starting to write CD/DVD at speed MAX in real SAO mode for single session. Last chance to quit, starting real write in 0 seconds. Operation starts. Waiting for reader process to fill input buffer ... input buffer ready. cdrskin: thank you for being patient since 1 seconds Starting new track at sector: 0 ... ... cdrskin: thank you for being patient since 1278 seconds Track 01: Total bytes read/written: 5514940416/5515988992 (2693354 sectors). Writing time: 1278.935s Cdrskin: fifo had 2692842 puts and 2692842 gets. Cdrskin: fifo was 0 times empty and 323524 times full, min fill was 99%. Min drive buffer fill was 20% cdrskin: burning done Speed is the same as with cdrecord and growisofs, 1x instead of 2x, I think this is due to verification/defect detection. -- [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcing cdrskin-0.4.4
Hi, i wrote: Your operating system seems to be a kernel 2.4. Giulio Orsero wrote: 2.4.33 kernel.org $ dd if=/dev/zero of=/dev/scd0 bs=32k dd: opening `/dev/scd0': Read-only file system It works ok on DVD-RAM media. I think it is less intrusive to work with a burn program than to upgrade the kernel which probably regards BD-RE as fat data CD-ROM. So let's see whether we can get cdrskin-0.4.5 to success. I read MMC-5 for disabling write error detection in order to get full speed. That topic is scattered all over the document. Two possible paths of exploration appear for now: - Format the media with certification and use WRITE12 with streaming bit. This would give the drive chances to skip the error detection reading and it would give it a hint that speed is critical. - Format the media with no spare area. This would take away the chance to correct errors and maybe disable the costly detection of errors. That would be format 31h. Did you already post the format capacities section from the output of dvd+rw-mediainfo ? With a DVD-RAM that looks like: READ FORMAT CAPACITIES: formatted: 2236704*2048=4580769792 00h(800): 2236704*2048=4580769792 00h(800): 2295072*2048=4700307456 01h(800): 2226976*2048=4560846848 01h(800): 2217248*2048=4540923904 I would be interested in the availability of formats 30h(...) and 31h(...) The path with streaming bit on certified media can possibly be explored with DVD-RAM. Formatting without spare area is not described for DVD-RAM but might hide behind this format descriptor 00h(800): 2295072*2048=4700307456 which offers a suspiciously large payload capacity. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcing cdrskin-0.4.4
Hi, Giulio Orsero: I formatted the media using dvd+rw-format with default/standard options (ie: didn't use any command line option) Did you have technical indications that freshly purchased media need to be formatted prior to first usage ? I.e. did you ever test to write them out of the box ? Did that fail ? (DVD-RAM are sold formatted. They work immediately.) READ FORMAT CAPACITIES: formatted: 11826176*2048=24220008448 00h(3000): 11826176*2048=24220008448 30h(3000): 11826176*2048=24220008448 30h(5000): 11564032*2048=23683137536 30h(1000): 12088320*2048=24756879360 31h(800): 12219392*2048=25025314816 This gives room for both my ideas. it [cdrskin] now works ok Great. This gives the foundation for more experiments. Speed is the same as with cdrecord and growisofs, 1x instead of 2x, I think this is due to verification/defect detection. 4314915 bytes per second. With 24220008448 bytes this would make more than one and a half hour. :( I'll begin with an experiment on WRITE12 and streaming bit. Later we can explore formatting stunts. I'll test with my DVD-RAM first and will inform you when a development tarball is uploaded. To Andy and Joerg: Do you have any other ideas how to circumvent the hardware error detection with DVD-RAM and BD-RE ? Or do you have any other theory what makes both types so slow ? Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcing cdrskin-0.4.4
On Fri, Apr 11, 2008 at 11:50 AM, Thomas Schmitt [EMAIL PROTECTED] wrote: Did you already post the format capacities section from the output of dvd+rw-mediainfo ? I formatted the media using dvd+rw-format with default/standard options (ie: didn't use any command line option) INQUIRY:[HL-DT-ST][BD-RE BE06LU10 ][YE03] GET [CURRENT] CONFIGURATION: Mounted Media: 43h, BD-RE Media ID: LGEBRE/S01 Current Write Speed: 2.0x4495=8992KB/s Write Speed #0:2.0x4495=8992KB/s GET [CURRENT] PERFORMANCE: Write Performance: 2.0x4495=8992KB/[EMAIL PROTECTED] - 11826175] Speed Descriptor#0:02/11826175 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s BD SPARE AREA INFORMATION: Spare Area:393216/393216=100.0% free READ DISC INFORMATION: Disc status: complete Number of Sessions:1 State of Last Session: complete Number of Tracks: 1 READ FORMAT CAPACITIES: formatted: 11826176*2048=24220008448 00h(3000): 11826176*2048=24220008448 30h(3000): 11826176*2048=24220008448 30h(5000): 11564032*2048=23683137536 30h(1000): 12088320*2048=24756879360 31h(800): 12219392*2048=25025314816 READ TRACK INFORMATION[#1]: Track State: complete Track Start Address: 0*2KB Free Blocks: 0*2KB Track Size:11826176*2KB FABRICATED TOC: Track#1 : [EMAIL PROTECTED] Track#AA : [EMAIL PROTECTED] Multi-session Info:[EMAIL PROTECTED] READ CAPACITY: 11826176*2048=24220008448 -- [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcing cdrskin-0.4.4
On Fri, Apr 11, 2008 at 1:07 PM, Thomas Schmitt [EMAIL PROTECTED] wrote: Hi, Giulio Orsero: I formatted the media using dvd+rw-format with default/standard options (ie: didn't use any command line option) Did you have technical indications that freshly purchased media need to be formatted prior to first usage ? I.e. did you ever test to write them out of the box ? Did that fail ? I tried using cdrecord and it basically errored out sayng this need to be formatted. I'm going to do it but then it failed (on the list I read cdrecord will be updated to be able to format BD-RE media soon). So I formatted with dvd+rw-format and then cdrecord started writing to it. dvd+rw-format formatted it without complaining, if I retry now it says it's already formatted and I need to use lengthly complete formatting using -format=full (which I didn't use the 1st time) The media is the one included with the burner; I will receive different media in a few days. This is the diff between output of dvd+rw-mediainfo with new media and after I formatted it: --- dvd+mediainfo.blank 2008-03-31 18:18:43.0 +0200 +++ dvd+mediainfo.formattato2008-04-01 15:48:55.0 +0200 @@ -5,23 +5,29 @@ Current Write Speed: 2.0x4495=8992KB/s Write Speed #0:2.0x4495=8992KB/s GET [CURRENT] PERFORMANCE: - Write Performance: 2.0x4495=8992KB/[EMAIL PROTECTED] - 12219391] - Speed Descriptor#0:02/12219391 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s + Write Performance: 2.0x4495=8992KB/[EMAIL PROTECTED] - 11826175] + Speed Descriptor#0:02/11826175 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s +BD SPARE AREA INFORMATION: + Spare Area:393216/393216=100.0% free READ DISC INFORMATION: - Disc status: blank + Disc status: complete Number of Sessions:1 - State of Last Session: empty - Next Track: 1 + State of Last Session: complete Number of Tracks: 1 READ FORMAT CAPACITIES: - unformatted: 12219392*2048=25025314816 + formatted:11826176*2048=24220008448 00h(3000):11826176*2048=24220008448 30h(3000):11826176*2048=24220008448 30h(5000):11564032*2048=23683137536 30h(1000):12088320*2048=24756879360 31h(800): 12219392*2048=25025314816 READ TRACK INFORMATION[#1]: - Track State: blank + Track State: complete Track Start Address: 0*2KB Free Blocks: 0*2KB - Track Size:0*2KB + Track Size:11826176*2KB +FABRICATED TOC: + Track#1 : [EMAIL PROTECTED] + Track#AA : [EMAIL PROTECTED] + Multi-session Info:[EMAIL PROTECTED] +READ CAPACITY: 11826176*2048=24220008448 --- cdrecord.minfo.blank2008-03-31 18:17:59.0 +0200 +++ cdrecord.minfo.formattato 2008-04-01 15:49:37.0 +0200 @@ -35,17 +35,36 @@ Supported modes: PACKET SAO LAYER_JUMP Drive buf size : 2359296 = 2304 KB Drive pbuf size: 3932160 = 3840 KB -Drive DMA Speed: 13496 kB/s 76x CD 9x DVD 3x BD -Current Secsize: 0 +Drive DMA Speed: 13059 kB/s 74x CD 9x DVD 2x BD +Current Secsize: 2048 Disk type: 'BDW' (BD-RE) Disk class: 02 Manufacturer: 'LGEBRE' Media type: 'S01' Disk: is not in cartridge Media cartrige: write protect is off +Free Spare Blocks: 393216 +Alloc Spare Blocks: 393216 +rzone size: 40 +rzone number: 1 +border number: 1 +ljrs: 0 +track mode: 4 copy: 0 +damage: 0 +reserved track: 0 blank: 0 incremental: 0 fp: 0 +data mode: 1 +lra valid: 0 +nwa valid: 0 +rzone start:0 +next wr addr: 0 +free blocks:0 +blocking factor:32 +rzone size: 11826176 +last recorded addr: 0 +read compat lba:0 Capacity Blklen/Sparesz. Format-type Type -1221939220480 0x00 Unformated or Blank Media +1182617612288 0x00 Formatted Media 1182617612288 0x00 Reserved (0) 1182617612288 0x30 Reserved (0) 1156403220480 0x30 Reserved (0) @@ -55,8 +74,8 @@ Mounted media type: BD-RE Disk Is erasable data type:standard -disk status: empty -session status: empty +disk status: complete +session status: complete BG format status: none first track: 1 number of sessions: 1 @@ -67,5 +86,7 @@ Track Sess Type Start Addr End Addr Size == -1 1 Blank 0 -1 0 -1 +1 1 Data 0 11826175 11826176 -1 +Last session start address: 0 +Last session leadout start address: 11826176 -- [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcing cdrskin-0.4.4
Hi, READ FORMAT CAPACITIES: - unformatted: 12219392*2048=25025314816 + formatted:11826176*2048=24220008448 Ahum. Looks really like initial formatting is needed. I had a look into dvd+rw-format.cpp. fprintf (stderr,- you have the option to re-run %s with:\n -format=full to perform (lengthy) Full Certification;\n -ssa[=none|default|max|XXX[GM]]\n to eliminate or adjust Spare Area.\n, argv[0]); It seems you could make an experiment with format 31h (i.e. no spare area) by dvd+rw-format option -ssa=none It might also be worth to check the impact of certification on write error detection. I.e.: -format=full I understand from MMC specs that certification is a read process which evaluates the quality of data recording and eventually records bad spots in a list. It is unclear to me whether this list resides permanently on media. But if we are lucky, the drive trusts the certified blocks and refrains from reading them after write. If we are a bit less lucky, then we need command WRITE12 rather than the usual WRITE10. Hopefully the formatting will not damage the only media you have. :) I would propose to try both. It would be most economic to do -ssa=none first, because i would expect it to be the most likely to omit error detection on traditional WRITE10 (SCSI command 2Ah). With -format=full i would possibly expect that WRITE12 (command AAh) is needed. There seems to be a WRITE12 experiment ready in dvd+rw-tools-7.1/growisofs_mmc.cpp Maybe Andy Polykov already knows more about that topic. Andy ? Are you reading this ? Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcing cdrskin-0.4.4
On Fri, Apr 11, 2008 at 3:28 PM, Thomas Schmitt [EMAIL PROTECTED] wrote: It seems you could make an experiment with format 31h (i.e. no spare area) by dvd+rw-format option -ssa=none It took under a minute: --- dvd+mediainfo.formattato2008-04-01 15:48:55.0 +0200 +++ dvd+mediainfo.ssa=none 2008-04-11 14:54:06.0 +0200 @@ -5,17 +5,15 @@ Current Write Speed: 2.0x4495=8992KB/s Write Speed #0:2.0x4495=8992KB/s GET [CURRENT] PERFORMANCE: - Write Performance: 2.0x4495=8992KB/[EMAIL PROTECTED] - 11826175] - Speed Descriptor#0:02/11826175 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s -BD SPARE AREA INFORMATION: - Spare Area:393216/393216=100.0% free + Write Performance: 2.0x4495=8992KB/[EMAIL PROTECTED] - 12219391] + Speed Descriptor#0:02/12219391 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s READ DISC INFORMATION: Disc status: complete Number of Sessions:1 State of Last Session: complete Number of Tracks: 1 READ FORMAT CAPACITIES: - formatted:11826176*2048=24220008448 + formatted:12219392*2048=25025314816 00h(3000):11826176*2048=24220008448 30h(3000):11826176*2048=24220008448 30h(5000):11564032*2048=23683137536 @@ -25,9 +23,9 @@ Track State: complete Track Start Address: 0*2KB Free Blocks: 0*2KB - Track Size:11826176*2KB + Track Size:12219392*2KB FABRICATED TOC: Track#1 : [EMAIL PROTECTED] - Track#AA : [EMAIL PROTECTED] + Track#AA : [EMAIL PROTECTED] Multi-session Info:[EMAIL PROTECTED] -READ CAPACITY: 11826176*2048=24220008448 +READ CAPACITY: 12219392*2048=25025314816 And now I can write at 2x! Thanks, I didn't think about that (ssa=none) cdrskin 0.4.5 : limited cdrecord compatibility wrapper for libburn cdrskin: verbosity level : 1 cdrskin: NOTE : greying out all drives besides given dev='/dev/sg1' cdrskin: scanning for devices ... cdrskin: ... scanning for devices done cdrskin: beginning to burn disc cdrskin: status 1 burn_disc_blank The drive holds a blank disc Current: BD-RE Track 01: data 5259 MB padsize: 1024 KB Total size: 5260 MB (598:33.37) = 2693353 sectors Lout start: 5260 MB (598:35/37) = 2693353 sectors Starting to write CD/DVD at speed MAX in real SAO mode for single session. Last chance to quit, starting real write in 0 seconds. Operation starts. Waiting for reader process to fill input buffer ... input buffer ready. ... Track 01: 5260 of 5260 MB written (fifo 100%) [buf 98%] 2.3x. ^Mcdrskin: thank you for being patient since 548 seconds Track 01: Total bytes read/written: 5514938368/5515986944 (2693353 sectors). Writing time: 548.333s Cdrskin: fifo had 2692841 puts and 2692841 gets. Cdrskin: fifo was 0 times empty and 270236 times full, min fill was 99%. Min drive buffer fill was 43% cdrskin: burning done 9.5 MB/sec ! It might also be worth to check the impact of certification on write error detection. I.e.: -format=full I think my kernel is too old, it exit after just 1 second: $ dvd+rw-format -format=full /dev/cdrom * BD/DVD±RW/-RAM format utility by [EMAIL PROTECTED], version 7.1. * 25.0GB BD media detected. * formatting 0.0|:-[ FORMAT UNIT failed with SK=5h/INVALID FIELD IN PARAMETER LI ST]: Input/output error $ -- [EMAIL PROTECTED]
Re: Announcing cdrskin-0.4.4
Hi, i wrote: (i.e. no spare area) by dvd+rw-format option -ssa=none Giulio Orsero wrote: It took under a minute: And now I can write at 2x! Thanks, I didn't think about that (ssa=none) Thanks to dvd+rw-format and 04h FORMAT UNIT Format Type 31h. This downgrades a BD-RE to kindof DVD+RW with 25 GB. You lose defect management. I understand that it is considered necessary because 25 GB media have a high risk to contain a bad spot somewhere. So it might be appealing to explore the ways with certifying formatting. If we can talk that into running at full speed by help of AAh WRITE12 then this would give us the opportunity to repair bad spots by re-formatting. I understand dvd+rw-format -format=full will apply 04h FORMAT UNIT Format Type 30h Sub Type 10b: Full Certification: The entire data area shall be certified. The defect tables shall be initialized with defects discovered during the certification process. I hope to have opportunity to check your BD-RE results over the weekend with DVD-RAM. Maybe i can make more proposals then. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcing cdrskin-0.4.4
On Thu, Apr 10, 2008 at 12:29 PM, Thomas Schmitt [EMAIL PROTECTED] wrote: be invited to try the new version 0.4.4 of my program cdrskin, System requirements: Linux with kernel 2.4 or 2.6. * Experimental code for BD-RE with --allow_untested_media I tested BD-RE media, issues with -sao: $ cdrskin -toc --allow_untested_media --allow_setuid cdrskin 0.4.4 : limited cdrecord compatibility wrapper for libburn cdrskin: scanning for devices ... cdrskin: ... scanning for devices done cdrskin: pseudo-atip on drive 0 cdrskin: status 1 burn_disc_blank The drive holds a blank disc scsidev: '1,0,0' Device type: Removable CD-ROM Vendor_info: 'HL-DT-ST' Identifikation : 'BD-RE BE06LU10' Revision : 'YE03' Driver flags : BURNFREE Supported modes: TAO SAO RAW/RAW96R= SAO is OK cdrskin: burn_drive_get_write_speed = 8992 (51.0x) ATIP info from disk: Is not erasable 1T speed low: 51 1T speed high: 51 cdrecord_emulation: Cannot read TOC header cdrecord_emulation: Cannot read TOC/PMA $ cdrskin --allow_untested_media --allow_setuid dev=1,0,0 -sao driveropts=burnfree test.iso cdrskin 0.4.4 : limited cdrecord compatibility wrapper for libburn cdrskin: NOTE : greying out all drives besides given dev='/dev/sg1' cdrskin: scanning for devices ... cdrskin: ... scanning for devices done cdrskin: beginning to burn disc cdrskin: SORRY : Write job parameters are unsuitable cdrskin: Reason: SAO: no SAO offered by drive and media, = SAO not OK cdrskin: Media : blank BD-RE cdrskin: FATAL : burning failed. $ cdrskin --allow_untested_media --allow_setuid dev=1,0,0 driveropts=burnfree test.iso cdrskin 0.4.4 : limited cdrecord compatibility wrapper for libburn cdrskin: NOTE : greying out all drives besides given dev='/dev/sg1' cdrskin: scanning for devices ... cdrskin: ... scanning for devices done cdrskin: beginning to burn disc cdrskin: SORRY : Drive offers no suitable write mode with this job cdrskin: Reason: SAO: no SAO offered by drive and media, TAO: no TAO offered by drive and media, cdrskin: Media : blank BD-RE cdrskin: FATAL : burning failed. BD-RE is formatted and contains data. -- [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcing cdrskin-0.4.4
Hi, Giulio Orsero wrote: I tested BD-RE media, issues with -sao: Thanks for testing. I will have to look into the various bugs which show up. To my excuse: i have to do any BD-RE blindly without having a drive at hand. The idea was to treat a BD-RE mostly like a DVD-RAM. Supported modes: TAO SAO RAW/RAW96R= SAO is OK It should not have promised that. At least not RAW. The supposed answer would rather be TAO SAO. cdrecord_emulation: Cannot read TOC header cdrecord_emulation: Cannot read TOC/PMA cdrskin: Media : blank BD-RE All overwriteable media are considered blank because one can only deduce from the content where and how much data is stored on them. cdrskin: burn_drive_get_write_speed = 8992 (51.0x) This looks like the media gets partly mistaken for a CD. cdrskin: SORRY : Drive offers no suitable write mode with this job cdrskin: Reason: SAO: no SAO offered by drive and media, TAO: no TAO offered by drive and media, Obviously the program steps on its own feet here. I will try to simulate a BD-RE by disguising a DVD-RAM. Maybe i can find out where the program gets deviated from the intended processing path. As soon as i have a remedy for the found bugs, i will ask you to test a development tarball. Thanks again for testing, and sorry for the failure. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcing cdrskin-0.4.4
On Thu, Apr 10, 2008 at 8:45 PM, Thomas Schmitt [EMAIL PROTECTED] wrote: Supported modes: TAO SAO RAW/RAW96R= SAO is OK It should not have promised that. At least not RAW. The supposed answer would rather be TAO SAO. cdrecord -atip says Supported modes: PACKET SAO LAYER_JUMP -- [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcing cdrskin-0.4.4
Hi, cdrecord -atip says Supported modes: PACKET SAO LAYER_JUMP A precise answer would be not applicable or OVERWRITEABLE. We try to squeeze those media into our CD inspired media models. The MMC specs clearly state that a BD-RE is random access overwriteable. Like DVD-RAM or like a SCSI hard disk. So there is no write mode as with CD. One writes. Period. cdrskin: NOTE : greying out all drives besides given dev='/dev/sg1' Your operating system seems to be a kernel 2.4. (Else cdrskin should use a /dev/sr* address rather than /dev/sg* ) On modern 2.6 it is supposed that one can write to the formatted area of BD-RE via the plain block device. dd if=test.iso of=/dev/sr0 bs=32K On kernel 2.4 this would work with DVD-RAM. No idea whether your kernel will accept BD-RE. If this works, cdrskin should be able to use this drive address and declare the media a stdio-drive: cdrskin --allow_emulated_drives dev=stdio:/dev/sr0 ... - My interest as burn programmer with BD-RE is about completeness iof the media zoo and later the finer stunts, like disabling the slow verification process and defect handling. For that i need to learn how to handle it by MMC commands directly. (The stdio: drive uses POSIX calls to talk to the block device driver which then issues MMC commands. I would have to guess ioctls to do stunts.) I'm still testing whether i understand the reason for today's failure and hope to have found a remedy. For now it looks like a small negligence in predicting the pseudo-capabilities of the media. The false speed factor and the false RAW mode have turned out to be mere display bugs with no further consequences. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcing cdrskin-0.4.4
Giulio Orsero [EMAIL PROTECTED] wrote: On Thu, Apr 10, 2008 at 8:45 PM, Thomas Schmitt [EMAIL PROTECTED] wrote: Supported modes: TAO SAO RAW/RAW96R= SAO is OK It should not have promised that. At least not RAW. The supposed answer would rather be TAO SAO. cdrecord -atip says Supported modes: PACKET SAO LAYER_JUMP This is correct ;-) Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcing cdrskin-0.4.4
Hi, i uploaded a new development snapshot which should be able to write to BD-RE or at least show new errors. http://scdbackup.sourceforge.net/cdrskin-0.4.5.tar.gz MD5: 2ae5d8f06d4847f5436bb99441dfc5cd After compilation and install it should report on $ cdrskin -version ... Version timestamp : 2008.04.10.211529 ... If this turns out to work i would next try to learn about formatting and possible disabling of the verification mode. (I remember to have read such for DVD-RAM.) Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
