discuser

After more than a week, I finally got things sorted. But this was an extremely odd and inexplicable case / scenario where it appeared that this was caused by a system issue, seemingly to be software related, on the operating system level with Windows. The reason was unknown. I do not believe that it has to do with viruses or malware. But in summary, something was going on at the operating system level that affected data I/O on both the HDD and ODDs and these symptoms gradually worsened quickly to an alarming level over the course of a couple of days. After going into Windows recovery console via OS CD boot and running full HDD scan and repair / recovery using CHKDSK, the symptoms were improved a bit but not were entirely cleared. Fortunately, I have a full drive C image back up from less than 2 months ago and did a full restore from that and also ran CHKDSK on it. After that, everything with disk I/O on HDD and ODD returned to normal. I used the exact same BD-RE-TL disc and re-erased it fully and rewrote the entire disc with Imgburn and both write and verify phase of the process produced no Imgburn error / warning messages whatsoever. So it strongly implies that this wasn't media fault. However, I did do an indirect disc quality test on the Sony BD-RE-TL disc initially prior to rewriting it, and Opti-Drive Control reported some interesting information. Since the Pioneer drives doesn't report direct error rates using the disc quality test function on Opti-Drive Control, I opted to use the TRANSFER RATE test which would usually reveal read difficulties on a disc as indicated by drive speed slow downs. The disc was read at 4X speed in CLV mode. A problem with Opti-Drive Control that was discovered during this transfer rate test was that this utility doesn't yet support BD capacities beyond dual layer / 50 GB, so when the read test got to that limit, the graphing routine would produce invalid plottings and I suspect that the X-axis scaling is also wrong. But I think one could surmise where the (first) layer switch occurs since that could be inferred from the valley-point of the spindle speed (green plot). As you can see, the green plot data becomes invalid as it rises steeply above the 4X Y-axis level in the latter part of the read test. The first graph shows the severe and repeated errors at strangely regular intervals encountered during the initial occurance of the problem. This is clearly abnormal and concerning as far as integrity of a full 90 GB disc of data is concerned. Interestingly, when the same test is repeated with the same disc on a second identical Pioneer BD writer in the same computer system (second graph), the second drive seems to read the badly written disc much more tolerably with only one major dip in transfer speed. The third and fourth graphs posted is after the computer system was restored to normal operating state, reading another (different) full BD-RE-TL disc written to full capacity of data (90.2 GB formatted capacity) using the first and second identical model Pioneer 09 series drive both installed on the same computer system. This disc verified with no reported errors from Imgburn so any errors were within the corrective capacity of the ODD. I think the X-axis scaling of the drive spindle speed is wrong, because the valley of the green plot is at the 23 GB mark which is correct for a BD-DL disc, since BD-DL is 46 GB formatted capacity and 23 GB per layer. However, I think the program got confused on handling BD-TL media. On TL media, it's 90.2 GB formatted capacity so it's basically 30 GB per layer, and we could see that at the 30 GB point for both 3rd and 4th graph plots, there's a dip in data transfer rate and drive rotational speed, so this appears to be the normal dip in transfer rate near the L0 (deepest layer) to L1 layer (middle layer) switching point. However, it can be seen that the second and newer drive on this computer, which was manufactured a few years later compared to the first drive even though both drives are the exact same model number and firmware, performs better during the layer switch as well as handling other disc errors, at least in reading this particular type of BDRE-TL media.

So taking everything into consideration and based on my observations on the actions of the Imgburn full erase command so far on my past experience with rewritable media on CD / DVD and BD, it seems that the so-called erase command on Imgburn is really in fact issuing a format command to the ODD, and then the drive does whatever its supposed to do internally, if I understand that correctly.

That would be extremely odd if regular full erase doesn't write anything to disc. I've always had the impression that this process does write to disc because the vast majority of its lengthy time consumption is spent in a process which according to the log, says Imgburn is writing zeros to the disc. So wouldn't that be overwritting the data space and whatever previous data that was on there? I can understand if SMART ERASE writes more random data but I've always had the impression that the regular FULL ERASE writes zeros to the disc and when PROPERLY FORMATTED OPTION is enabled / ticked, then the zero writes are also verified and bad sectors are mapped out and replaced with spare sectors on BD-RE media. I'll let LUK clarify this when he comes on later.

I read up on the help information on WRITE options tick box called PREFER PROPERLY FORMATTED DISCS and understand that this option is applicable to DVD+RW and BD-RE media. While I'm familiar with the implications of this setting for BD-RE discs, I was wondering if I wanted to do a full formatting pass on a virgin DVD+RW disc, whether I would do this with this tick box enabled and perform a ERASE DISC, FULL operation? Secondly, if I was writing an ISO image to a DVD+RW disc, would it matter whether I perform a proper format on the DVD+RW disc first, and what effect would it have if an ISO was written to a virgin DVD+RW disc without going through the formatting operation first? Would Imgburn still automatically including a pre-format step prior to actually writing the ISO image on a virgin DVD+RW disc? Thirdly, regarding SMART ERASE function, I read in the help documentation that it says it works for CD and DVD+/-R media to write random characters to the data space and data would therefore be impossible to recover. But I thought the regular FULL ERASE (non-smart erase) would write zeros to the data space on the disc in any case. So would that not already destroy / wipe out previously written data? Is SMART ERASE useable on BD rewritable media also? Thanks for any info / help.

Thanks for confirming that. I had suspected it was on the ODD end and not the HDD end. That group of messages is the only objectionable / exceptional messages in an otherwise normal log entry. All messages are the same other than the sector numbers on which the verify failure occured and usually it occurs every few minutes to every 10 minutes. What this tells me is that if this is a disc defect, it is not an issue of any physical contamination on the disc surface on one or multiple particular physical spot, because that should not occur every few minutes on the same layer of the disc. The timing of the multiple read errors suggest the failures are spread across all three layers at multiple spots, and I can confirm that the disc surface is ultra clean as I closely inspect the BD surface and clear all visible dust / contaminants gently with camera lens cleaning paper prior to insertion into the drive for writing. What I will try is completely re-erase / re-format this disc with spare sectors enabled on my 2nd but identical model Pioneer BD writer on the same computer system, then repeat the exact same write, and see how it verifies. If the result is the same, then I will try a new Sony BD-RE-TL. However, before I re-erase the BD, I may try to simply run a read operation on all the files and see if the same read errors occur, or whether it reads completely smoothly without re-trying at any spot on the disc. Here is the relevant section of the log below. The media is Sony BD-RE-TL type (made in Japan), which I have used very successfully to date without a hitch or error until now. Though, this was the first write on the same media since a most recent Pioneer firmware update that was released. I 04:41:27 Operation Started! I 04:41:27 Source File: -==/\/[BUILD IMAGE]\/\==- I 04:41:27 Source File Sectors: 38,359,328 (MODE1/2048) I 04:41:27 Source File Size: 78,559,903,744 bytes I 04:41:27 Source File Volume Identifier: VIDEOARC-3M I 04:41:27 Source File Volume Set Identifier: 4E22252802494843 I 04:41:27 Source File Application Identifier: ImgBurn v2.5.8.0 I 04:41:27 Source File Implementation Identifier: ImgBurn I 04:41:27 Source File File System(s): UDF (2.50) I 04:41:27 Destination Device: [2:0:0] PIONEER BD-RW BDR-S09 1.51 (T:) (ATA) I 04:41:27 Destination Media Type: BD-RE (Disc ID: SONY-ET2-002) I 04:41:27 Destination Media Supported Write Speeds: 2x I 04:41:27 Destination Media Sectors: 47,305,728 I 04:41:27 Write Mode: BD I 04:41:27 Write Type: DAO I 04:41:27 Write Speed: 2x I 04:41:27 Hardware Defect Management Active: Yes I 04:41:27 BD-RE FastWrite: No I 04:41:27 Link Size: Auto I 04:41:27 Lock Volume: Yes I 04:41:27 Test Mode: No I 04:41:27 OPC: No I 04:41:27 BURN-Proof: Disabled I 04:41:28 Write Speed Successfully Set! - Effective: 8,990 KB/s (2x) I 04:41:28 Advanced Settings - Optimal Writing Speed: No I 04:41:28 Filling Buffer... (80 MiB) I 04:41:31 Writing LeadIn... I 04:41:41 Writing Session 1 of 1... (1 Track, LBA: 0 - 38359327) I 04:41:41 Writing Track 1 of 1... (MODE1/2048, LBA: 0 - 38359327) I 10:08:09 Synchronising Cache... I 10:08:11 Operation Successfully Completed! - Duration: 05:26:44 I 10:08:11 Average Write Rate: 3,916 KiB/s (0.9x) - Maximum Write Rate: 4,358 KiB/s (1.0x) I 10:08:12 Operation Started! I 10:08:12 Source Device: [2:0:0] PIONEER BD-RW BDR-S09 1.51 (T:) (ATA) I 10:08:12 Source Media Type: BD-RE (Disc ID: SONY-ET2-002) I 10:08:12 Source Media Supported Read Speeds: 4x I 10:08:12 Source Media Supported Write Speeds: 2x I 10:08:12 Source Media Sectors: 47,305,728 I 10:08:12 Source Media Size: 96,882,130,944 bytes I 10:08:12 Image File: -==/\/[BUILD IMAGE]\/\==- I 10:08:12 Image File Sectors: 38,359,328 (MODE1/2048) I 10:08:13 Image File Size: 78,559,903,744 bytes I 10:08:13 Image File Volume Identifier: *** 11 character label REDACTED for forum post *** I 10:08:13 Image File Volume Set Identifier: 4E22252802494843 I 10:08:13 Image File Application Identifier: ImgBurn v2.5.8.0 I 10:08:13 Image File Implementation Identifier: ImgBurn I 10:08:13 Image File File System(s): UDF (2.50) I 10:08:13 Read Speed (Data/Audio): MAX / MAX I 10:08:14 Read Speed - Effective: 4x I 10:08:14 Verifying Session 1 of 1... (1 Track, LBA: 0 - 38359327) I 10:08:14 Verifying Track 1 of 1... (MODE1/2048, LBA: 0 - 38359327) W 10:13:16 Failed to Read Sectors 1317888 - 1317919 - Reason: Unknown (Internal Target Failure) (ASC: 0x44, ASCQ: 0x07) W 10:15:26 Failed to Read Sectors 1889344 - 1889375 - Reason: Unknown (Internal Target Failure) (ASC: 0x44, ASCQ: 0x07) W 10:19:05 Failed to Read Sectors 2846720 - 2846751 - Reason: Unknown (Internal Target Failure) (ASC: 0x44, ASCQ: 0x07) W 10:23:19 Failed to Read Sectors 3960096 - 3960127 - Reason: Unknown (Internal Target Failure) (ASC: 0x44, ASCQ: 0x07) W 10:23:42 Failed to Read Sectors 4061440 - 4061471 - Reason: Unknown (Internal Target Failure) (ASC: 0x44, ASCQ: 0x07) W 10:27:47 Failed to Read Sectors 5132544 - 5132575 - Reason: Unknown (Internal Target Failure) (ASC: 0x44, ASCQ: 0x07) W 10:34:08 Failed to Read Sectors 6803584 - 6803615 - Reason: Unknown (Internal Target Failure) (ASC: 0x44, ASCQ: 0x07) W 10:40:19 Failed to Read Sectors 8431520 - 8431551 - Reason: Unknown (Internal Target Failure) (ASC: 0x44, ASCQ: 0x07) W 10:41:50 Failed to Read Sectors 8826592 - 8826623 - Reason: Unknown (Internal Target Failure) (ASC: 0x44, ASCQ: 0x07) W 10:44:10 Failed to Read Sectors 9437376 - 9437407 - Reason: Unknown (Internal Target Failure) (ASC: 0x44, ASCQ: 0x07) W 10:55:21 Failed to Read Sectors 12382656 - 12382687 - Reason: Unknown (Internal Target Failure) (ASC: 0x44, ASCQ: 0x07) W 10:55:31 Failed to Read Sectors 12424192 - 12424223 - Reason: Unknown (Internal Target Failure) (ASC: 0x44, ASCQ: 0x07) W 10:56:07 Failed to Read Sectors 12577728 - 12577759 - Reason: Unknown (Internal Target Failure) (ASC: 0x44, ASCQ: 0x07) W 10:57:39 Failed to Read Sectors 12976928 - 12976959 - Reason: Unknown (Internal Target Failure) (ASC: 0x44, ASCQ: 0x07) W 11:10:53 Failed to Read Sectors 16459232 - 16459263 - Reason: Unknown (Internal Target Failure) (ASC: 0x44, ASCQ: 0x07) W 11:15:06 Failed to Read Sectors 17566304 - 17566335 - Reason: Unknown (Internal Target Failure) (ASC: 0x44, ASCQ: 0x07) W 11:15:34 Failed to Read Sectors 17683520 - 17683551 - Reason: Unknown (Internal Target Failure) (ASC: 0x44, ASCQ: 0x07) W 11:19:39 Failed to Read Sectors 18756384 - 18756415 - Reason: Unknown (Internal Target Failure) (ASC: 0x44, ASCQ: 0x07) W 11:21:22 Failed to Read Sectors 19205856 - 19205887 - Reason: Unknown (Internal Target Failure) (ASC: 0x44, ASCQ: 0x07) W 11:22:04 Failed to Read Sectors 19384832 - 19384863 - Reason: Unknown (Internal Target Failure) (ASC: 0x44, ASCQ: 0x07) W 11:25:32 Failed to Read Sectors 20296096 - 20296127 - Reason: Unknown (Internal Target Failure) (ASC: 0x44, ASCQ: 0x07) W 11:29:25 Failed to Read Sectors 21314752 - 21314783 - Reason: Unknown (Internal Target Failure) (ASC: 0x44, ASCQ: 0x07) W 11:37:22 Failed to Read Sectors 23405600 - 23405631 - Reason: Unknown (Internal Target Failure) (ASC: 0x44, ASCQ: 0x07) W 11:40:35 Failed to Read Sectors 24247872 - 24247903 - Reason: Unknown (Internal Target Failure) (ASC: 0x44, ASCQ: 0x07) W 11:41:15 Failed to Read Sectors 24423104 - 24423135 - Reason: Unknown (Internal Target Failure) (ASC: 0x44, ASCQ: 0x07) W 11:43:09 Failed to Read Sectors 24918688 - 24918719 - Reason: Unknown (Internal Target Failure) (ASC: 0x44, ASCQ: 0x07) W 11:44:35 Failed to Read Sectors 25293504 - 25293535 - Reason: Unknown (Internal Target Failure) (ASC: 0x44, ASCQ: 0x07) W 11:45:54 Failed to Read Sectors 25635424 - 25635455 - Reason: Unknown (Internal Target Failure) (ASC: 0x44, ASCQ: 0x07) W 11:48:01 Failed to Read Sectors 26191616 - 26191647 - Reason: Unknown (Internal Target Failure) (ASC: 0x44, ASCQ: 0x07) W 11:49:57 Failed to Read Sectors 26696192 - 26696223 - Reason: Unknown (Internal Target Failure) (ASC: 0x44, ASCQ: 0x07) W 11:52:35 Failed to Read Sectors 27388832 - 27388863 - Reason: Unknown (Internal Target Failure) (ASC: 0x44, ASCQ: 0x07) W 12:01:30 Failed to Read Sectors 29733984 - 29734015 - Reason: Unknown (Internal Target Failure) (ASC: 0x44, ASCQ: 0x07) W 12:08:03 Failed to Read Sectors 31458272 - 31458303 - Reason: Unknown (Internal Target Failure) (ASC: 0x44, ASCQ: 0x07) W 12:08:53 Failed to Read Sectors 31676832 - 31676863 - Reason: Unknown (Internal Target Failure) (ASC: 0x44, ASCQ: 0x07) W 12:11:07 Failed to Read Sectors 32260800 - 32260831 - Reason: Unknown (Internal Target Failure) (ASC: 0x44, ASCQ: 0x07) W 12:22:48 Failed to Read Sectors 35337568 - 35337599 - Reason: Unknown (Internal Target Failure) (ASC: 0x44, ASCQ: 0x07) W 12:24:36 Failed to Read Sectors 35808448 - 35808479 - Reason: Unknown (Internal Target Failure) (ASC: 0x44, ASCQ: 0x07) W 12:29:32 Failed to Read Sectors 37103520 - 37103551 - Reason: Unknown (Internal Target Failure) (ASC: 0x44, ASCQ: 0x07) W 12:33:01 Failed to Read Sectors 38016704 - 38016735 - Reason: Unknown (Internal Target Failure) (ASC: 0x44, ASCQ: 0x07) W 12:33:16 Failed to Read Sectors 38078240 - 38078271 - Reason: Unknown (Internal Target Failure) (ASC: 0x44, ASCQ: 0x07) W 12:34:11 Failed to Read Sectors 38320192 - 38320223 - Reason: Unknown (Internal Target Failure) (ASC: 0x44, ASCQ: 0x07) W 12:34:16 Failed to Read Sectors 38334336 - 38334367 - Reason: Unknown (Internal Target Failure) (ASC: 0x44, ASCQ: 0x07) I 12:34:29 Operation Successfully Completed! - Duration: 02:26:09 I 12:34:29 Average Verify Rate: 8,749 KiB/s (2.0x) - Maximum Verify Rate: 8,970 KiB/s (2.0x)

I was recently writing a BD-RE-TL and I had enabled my BD writer to verify during write. The write phase did not produce any error messages in Imgburn's log and appeared to proceed normally. However, after write completion and the verify phase began, comparing the source files on the hard disc to the optical disc, I had multiple messages which read: Failed to Read Sectors XXXXXXX - XXXXXXX - Reason: Unknown (Internal Target Failure) (ASC: 0x44, ASCQ: 0x07) I wanted to confirm that this is indicating a read issue on the ODD side and not the HDD side. Is that correct? Seems odd that the write with verify phase did not pick up any read errors (or would have reallocated bad sectors with spare sectors), yet during verify only phase, the disc had read problems. I had already re-erased the disc (which had previously been written on once) with spare sectors enabled prior to completely re-writing the contents of the disc. Thanks for any clarification.

Thanks for the clarification. I did already successfully write one CD-RW in red-book audio format with the WRITE MODE in CD and WRITE TYPE in DAO/SAO, and the outcome was normal, though I couldn't be absolutely sure that the disc was closed though I assumed that it was more likely than not that it would have been closed / finalized. The original reason why I set WRITE MODE to CD was that I was looking for that one control in Imgburn which would tell the program that I was writing a CD-Audio disc rather than a CD-ROM disc which had a group of WAV files but I'm fine with setting it back to AUTO mode since it was always on that mode and the program had no problems recognizing various BD-RE media I have used very successfully with it so far.. I later on found out that I apparently need to use a new CUE file in Imgburn inserted with WAV files to be written in red-book audio to produce a CD-Audio disc. Otherwise, if I used the DISC LAYOUT EDITOR, I would just end up with a CD-ROM with WAV files and not red-book audio, right? I'm going to rewrite that CD-RW a second time. I think it's probably time to replace the media because checking the error rates after writing with Opti-Dirve Control showed a rather high C1 error rate though no C2 errors. But I'm going to experiment with OPC on to see if that makes a difference with C1 error rates on an older CD-RW disc. It's all part of the experimentation / learning process for me with Imgburn.

I was wondering about writing CD red-book audio with Imgburn. Usually, I would normally use DAO disc-at-once mode to write a single CD-audio session, after which the disc is closed / finalized. I didn't see any options in Imgburn WRITE SETTINGS for closing the disc after write. However, I did set the WRITE MODE to CD and WRITE TYPE to DAO/SAO. Do these manual settings force DAO with disc finalization / closure for red-book audio? Secondly, when I insert a writeable CD which previously had red-book audio recorded on it, which part of the DEVICE tab information CONFIRMS that it was written with DISC AT ONCE or TRACK AT ONCE, and also which part of the device information details confirms that the disc is FINALIZED / CLOSED or that it is still open for more session writes? I noticed that the DEVICE details says: Status: Complete State of Last Session: Complete Does STATUS: COMPLETE confirm disc closure / finalization and that the CD-RW can no longer be written without erasure? Regarding the PERFORM OPC BEFORE WRITE tick box, would it be more advantageous or not to enable optimum power calibration on the ODD normally, than to disable OPC? What scenarios would OPC disable be desireable with CD and DVD media? OPC is only applicable to CD and DVD media and not BD media, yes? Thanks for any clarifications.

They don't have any internal slim ODDs. Sony-Optiarc had one or more such products up until nearly shutting down operations, but that option is gone too.

Yes, I do normally insert blank formatted media first before using the disc layout editor. But as L-UK says, the disc layout editor (DLE) calculation is only an approximation even with inserted media, whereas the information panel calculation is the exact correct value. So if I'm using the DLE then I still have to flip back to the information tab to get the exact updated result. I don't always have the information tab AUTO box ticked because the auto calculation can generates one or more prompts depending on the files added to the DLE. So I'm currently using the information tab calculator only manually. As for my reply above, I was asking L-UK about the AUTO box in the DLE (to the right of the disc consumption bar).

Thanks for confirmation of program behaviour. Your description confirms my suspicion, that the disc layout editor is just using a generic media capacity value based on the currently selected media type on the pull down menu to the right of the disc space consumption bar. I was hoping the disc consumption calculation in the disc layout editor would reflect the actual remaining free space based on media inserted, as this would now mean that when I try to pack a disc as close to maximum capacity as possible, I will have to go into the layout editor, play with adding or deleting a number of files and each time changing the file layout slightly, to go back outside to the calculator panel on the information tab to recalculate. But at least I know for sure this is the expected behaviour of the software at this time. Otherwise, my very long write and verify session to the BD-RE-TL media worked normally and in general Imgburn works very well with this media even though this BD-RE capacity wasn't readily available for testing back at the time this version of the software was released. The write-with-verify session took about 6 3/4 hours and the separate verify against source file portion took around 2 1/2 to 3 hours, which means a full 90 GB (formatted capacity with spare sectors enabled) packed BD-RE-TL disc can take nearly 10 hours to fully complete write and verification. I noticed there's an AUTOMATIC TARGET MEDIA tick box next to the layout editor's disc space consumption bar's media type menu. When that box is ticked, does this mean that the software will detect the type of disc inserted and at least select the correct media type, even if not taking into account the actual effective available space on the particular media inserted? Or does this just mean the media type required to accommodate the disc space consumption will be automatically adjusted by the software so to inform the user what media type / capacity to use?

I very recently attempted to prepare a disc layout for a BD-RE-TL 100GB disc and was attempting to squeeze as many files as possible into the available formatted free space of approximately 94 GB (which may vary up or down slightly depending on whether spare sector areas are enabled and what size spare sectors were specified during disc formatting). It was noticed that there are discrepancies reported in different areas of Imgburn under varying conditions, as follows: 1. When there was NO formatted BD-RE media inserted, and the disc layout editor was used to produce a draft disc layout and the disc space consumption bar was monitored (disc type next to disc space consumption bar was manually set to BD-RE-TL in this case in the disc layout editor) when files were dropped into the layout, I added files so that it was within 1% to 2% of maximum disc space, i.e. disc consumption was 98% to 99%. After closing disc layout editor, and returning to the INFORMATION tab of Imgburn, clicking the CALCULATOR button resulted in a disc consumption result of 99% (which was correctly rounded up from 98%+ shown in the disc layout editor). 2. However, when the BD-RE-TL media was inserted into the BD writer and the relevant BD writer drive was selected in Imgburn, and the INFORMATION tab CALCULATOR button was clicked again, the INFORMATION tab now showed that the disc space consumption was BEYOND actual available free disc space on the blank but formatted media (with spare sectors enabled in preferred mode) and the information tab showed the consumption at 102% and free disc space was NEGATIVE 2 GB, both figures highlighted in red. At first I thought these discrepancies might be a bug, but then realized that the probable reason this occured is that after formatted blank media with enabled spare sectors was inserted, the effective free disc space was reduced from the initial calculation due to disc space reservation / consumption by spare sectors areas. Is this what is happening? This is the only immediately obvious logical explanation I could surmise. If this is correct, then I would need to remove some files from the disc layout to meet the reduced free space available on disc. If this is not the reason for the reduction in available free disc space calculation, then this may be a bug or due to other factors. If the reason for the available disc space discrepancy is as surmised, then I would suggest that the disc layout editor's DISC SPACE CONSUMPTION BAR PERCENTAGE also take into account the same factors that affect available free disc space. Because currently, I have observed that while the INFORMATION tab calculation takes into account actual available disc space after formatted media is inserted, the disc layout editor available free space percentage does not re-adjust to reflect this and thus there's a major discrepancy between the free space percentage reported in the disc space editor and the information tab calculation, by as much as 4%. In the above example, the disc layout editor's disc space consumption bar is a little over 98% but the information tab reports it as 102%. Thus a free disc space discrepancy of nearly 4% in this particular example. I also noticed that when the AUTO box is ticked in the INFORMATION tab, and another ODD is selected which may not have any media inserted, the disc space consumption is not updated to reflect this, even though I do understand that the AUTO box is for auto updates of disc space consumption after disc layout editor is closed rather than when the selected ODD drive is changed, but this may be a point of enhancement worth considering for a future release to maintain constantly correct calculation relative to the currently selected drive and whether it has writable media inserted where the effective available free disc space could be determined by Imgburn that could be used to update disc space consumption / free space available values.

Interestingly, that BD-RE which caused problems with the NO SENSE INFORMATION error I encountered earlier on the Pioneer 06-series drive, I re-ran the erasure-formatting on the Pioneer 09-series drive again with the exact same disc and at around the same percentage location of the disc, I could hear the drive's pick up carriage seek noise ticking back and forth and the drive activity light blinking irregularly. Yet, there is no activity entry on the Imgburn log when these disc errors were encountered. This would appear to suggest that the 09-series drive is indeed handling the defect management correctly and has hidden these events behind the hardware as you described. So this would imply the older 06-series drive choked on the errors instead. It may not have performed sector reallocation correctly and/or did not handle the spare sector areas correctly. I will use the newer drive to perform erasure-formatting from now on. A bit of brain fog again on my part about the file system on an erased disc. I guess what I should have said is that an erased disc (provided that spare sectors are made available) resets the inner and outer spare areas on each disc player to full availability again, as well as clearing the defect list which should then contain no entries - until the disc's user data area is written by a BD drive which then starts to add any necessary defect entries and sector relocation as necessary / detected. I hope I got that right. If so, having understood this now, it would mean that in fact a full erasure with zero writes across the entire disc space would be beneficial as a bad sector pre-detection pass to pre-populate the defect list with any possible entries. Then the BD-RE would then be written with user data on a second write session which will respect the populated defect list from the zeroing pass and possibly add additional defect list entries if new ones are detected during the user data writing pass (such as if some sectors were marginal and escaped detection during the zeroing pass initially). From what I understand in reading up about BD defect management, the spare sector areas and defect list are cumulative as long as the BD-RE isn't re-erased / re-formatted, so the defect list should continue to accumulate and past defect entries should persist in the defect list. However, having gotten used to DAO writing with CD / DVD write-once and rewritable media, is it possible with BD-RE having already written a DAO session, to record additional sessions without full erasure? And since BD-RE is random access format, if the answer to that question is yes, then it is possible that the next write to the disc could start at any spot within the remaining free space and not necessarily immediately following the end of the last writing location? If so, what write mode should be used? DAO or something else?

I've done some internet searches on the subject of NO SENSE INFORMATION in terms of ODD writing and also found some past threads on this forum from users with similar errors. I think it amounts to some spots of unreadable disc areas, possibly on a low level in terms of tracking logical blocks or sectors or something to that effect, but essentially means that disc area is inaccessible / unuseable. Tell me if I'm understanding this correctly now, after having used Imgburn for a while now lately. I'm seeing that the erase-formatting procedure in the program defines the use of defect management or not merely when the "directory" or "header" area is of the UDF is initially (re-)written during formatting. Beyond that, the zeroing of the entire disc area during the full erasure procedure is operationally exactly the same as the user writing their own data, with the difference being only in the data written to the disc where the former is just the ODD software sending data-zeros to the hardware (with no separate verify phase later performed after zeroing completion) and the latter sending user data from a source. But on the drive / hardware level, functionally there is no difference in the write operation between zeroing the disc space or writing user data, and that the drive would handle defect management and bad sector relocation as an operation completely shielded from the ODD software (Imgburn) itself, provided the initial formatting of the file system enables spare sectors. So I think this would make sense to me why disc space zeroing over detected disc defects should not result in an activity log event (per your explanation) provided spare sectors aren't fully depleted.

Don't really have use for U-HD playback on the computer myself, so since Pioneer is charging almost twice for the 11-series at the moment, I just ordered another premium S09 drive, whose inventory is nearly all depleted now but was available almost at the same price I bought the first one four years ago when 09-series was first released. 09 series has had a good four year run. At some point I might consider the S11-J-X ultra-high end version but that's just nice to have, not a must have. I hope I never have to deal with DVD-RW/+RW media again.

Yes, but BDR-2XXDBK is not the same drive as BDR-2XXM. They did use the M suffix in the first generation of products that supported BDXL, namely the 07-series, but the M suffix is no longer used since 08-series, even if M is used internally to reference whether a drive supports BDXL or not. They are using geographical suffixes nowadays. So you could say that BDR-2XXM could refer to BDR-2XXJBK/UBK/EBK.

09-series is officially a discontinued product. Only the new 11-series is current, even though Pioneer USA web site still lists 09-series products.

BDR-209DBK has no BDXL media support and has deleted (D) support for DVD-RAM media (hence the D suffix). BDR-209UBK has BDXL media support and is for North American region (USA / Canada). BDR-209EBK is for European region, BDR-209JBK is for Japan domestic region. All drives are OEM versions with no software bundling, no retail packaging and plain drive bezel. BDXL media support has been present since 07-series. BK suffix is just simply black bezel, because in Japan, previously there was a choice of W white bezel and KR which is another dark colour close to black that is no longer available since 09-series.

Not all BDR-209 BD writers don't support BDXL media. There are 4 sub-versions of BDR-209. North America gets the worse version of course, which is the BDR-209DBK and that is the only sub-version of BDR-209 that doesn't support BDXL and DVD-RAM media. Without specifying the drive model suffix, it's not possible to determine the exact drive specs.

With BD-RE media I get up to around 5X to 6X or thereabouts at maximum speed. It's clear to me that the drive is under CAV mode during BD-RE reading. When I said 09-series, I'm just referring to the drive generation, which started with 02 series - BDR-202. It went from 02 to 11 at present day. 09 is the previous just discontinued series. The official current series is the 11-series which has U-BD/U-HD playback capability with lots of very specific system requirements. Mechanically, performance wise each series is basically identical amongst variations with some minor differences from enhancements. Pioneer BDR-209xBK, where X may be one of three possible suffixes, is the OEM version with no software bundle, basic embossed drive bezel and no retail packaging. The BDR-2209 is a product version for North America (USA / Canada) distribution with licensed bundled software in English language. If the user doesn't want bundled software they can choose the OEM version. In general, both are essentially the same drive and performance with minor differences. But the 09-series product has 9 sub-versions for different geographical regions and each sub-version has difference enhancements (some significant and some minor) even though the basic drive is the same in performance.

On my all my Pioneer BD writers all BD-RE media verifies only at constant 2X speed. Could never figure out why as I wish it would go faster. I suppose the up side of it is that when it reads at a low speed of 2X and the data can be read error free, it means that in the worse case it could read slowly and the data is error free. It only happens during the verify phase of ODD software, but during normal reads it does read up to 6X depending on data position as I have also confirmed this performance characteristic with with Opti-Drive Control. I have a Pioneer 09 series drive as well.

I've erase-formatted a Verbatim BD-RE disc that I know has some errors during formatting (it will be retired) around the end of layer 0 of this dual layer disc, the Imgburn log reported about 60 incidences of this error in close succession for this particular disc: Failed to Zero Sectors XXXXXXXX - XXXXXXXXXX - Reason: No Additional Sense Information Retrying (1 of 20)... After these incidences passed, the erasure-formatting continued for the remainder of the disc space without incident. I'm assuming this would trigger the spare sector usage for each incident that occured though I don't think that the spare sectors pool would have been used up. But what in your opinion does this error during full erasure-formatting mean on a BD-RE when spare sectors are enabled? I've erase-formatted many BD-RE-DL and BD-RE-TL discs so far and the vast majority of them do not have errors and most discs format cleanly in their entirety. The reason why I'm retiring this particular BD-RE disc is because although the format completed with errors which were presumably replaced by spare sectors successfully, during a previous data write after formatting, the verify phase (which occured after write-with-hardware-on-the-fly-verify), it encountered an unrecoverable read error, which I thought was odd with defect management presumably enabled.

If by half of the DLE disc layout editor on the EXPLORER side you mean the top half of the DLE, then possibly it could be a bug you might have control over. It occurs when items are dragged from the Explorer side top half and dropped into to the bottom half of the DLE. I'll post the details in the BUGS section once I get around to it.

The verify read speed will depend on the optical disc drive and media type used in the writing session. For example, I found that with BD-RE media, all of which are limited to a maximum write speed of 2X, can verify throughout the entire disc space at a constant 2X only, even if the drive may normally read 2X or higher with BD-RE media. I've never fully understood the reason for the verify phase linear read speed across the entire disc, as it seems to be a separate read mode compared to the ODD's normal read mode under operating system access which would have varying speed depending on the read position on the disc. Perhaps L-UK might be able to shed some light on why this is the case (I noticed this with Pioneer BD writers and on multiple ODD writing software, including Imgburn). With BD-R write once media, the verify speed behaviour maybe different. It will also depend on whether the ODD will use CAV or CLV modes at the maximum read speed set for the ODD. BD quad layer media is not currently available standalone, certainly not as far as I'm aware outside of Japan and I've not see it available for the Japan domestic market either. The only way to have access to BDXL-QL media is if you're going to buy an expensive Sony or Panasonic ODA Optical Disc Archival professional-use cartridge, disassemble it and use the BD media (taken out of the cartridge), which is only available as write once for quad layer 128 GB capacity. Most BDXL drives, though in theory should be compatible with BDXL-QL media, do not have internal media tables with any BDXL-QL media either, as far as I know. The realistic capacity supported at this point for BDXL-R and BDXL-RE is up to triple layer 100 GB discs, which have layers numbered layer 0 to layer 2. For a BD drive that reads in CAV constant angular velocity mode, the data transfer rate will rise from the start of layer 0, then peak between the crossover point of layers 0 and 1 after which it drops again to a minimum between the crossover point between layers 1 and 2, and peaks again at the end of layer 2 if a triple layer disc is used. In practice, if you want the highest data integrity and defect management for BD-RE media, the realistic practical effective WRITE speed will be somewhere around 0.8X to 1.0X if you have selected 2X write speed and have enabled spare sectors on the disc during formatting of the disc beforehand.

I did stumble across another consistently reproducible bug earlier which I haven't reported yet because I'm presently a bit tied up with doing lots of BD-RE writing recently. The bug in question pertains to the disc layout editor. If your current verified bug list doesn't contain any reports on the disc layout editor, this problem I discovered may be a new one for your list. But I need to re-create those conditions first and then write up a description for you. Would you prefer that to be posted as a forum message or sent to you as PM for further investigation?