Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by discuser

  1. Great to know. It's no loss anyway, because if the results don't work out I'll just do a full erase on the BD-RE-DL disc. No coasters and no harm done. It's one of the reasons why I prefer not to have to write to a DVD+/-R-DL disc.
  2. I was wondering if it would be possible to create a bootable BD on BD-RE-DL media (or any capacity BD media for that matter) from a bootable-DVD ISO image, simply by using the desired BD media and directing Image Burn to that bootable DVD ISO? The image's size normally requires DVD+/-R-DL media and since I have more BD-RE-DL media at hand I would rather not have to buy a stack of blank DVD+/-R-DL discs for very infrequent use. The only concern I could think of is whether modern UEFI based Windows hardware will be able to read a bootable BD (assuming that's possible to create from Image Burn) since BD would require at least UDF 2.5 or later support by the motherboard firmware, whereas DVD reading would only require UDF 1.02 support. Thanks for any input / advice.
  3. Yes, I do normally want all subfolders within a folder I drag to the layout I'm creating, to be added, so in this case I do want RECURSE SUBDIRECTORIES ticked. It was just that it somehow became unticked and it didn't hit me immediately that this could be the reason why the FOLDERS SKIPPED log message occured. As for why that tick box isn't persistent across Imgburn sessions, I think may have something to do with me selecting different ODDs, e.g. between my DVD writer and my BD writer, and perhaps Imgburn stored different values for that tick box. So when I flipped between different ODDs, that box status changed. But I still notice it not sticking all the time and I'll be verifying the state of that tick box closely from now on. Strangely, I don't think I had that box ticked the whole time I was doing BD writes, yet all the files I dragged into the disc layout editor were accepted and no log messages appeared during layout creation. I also check all folder and files count closely comparing the layout folders / file count versus the HDD's source folder / files count. After writing to disc, I re-check the written disc's folders / files count to confirm it is exactly the same as the HDD source folder / files count. Only after that do I delete the HDD source folders to free up disc space after archival to optical disc.
  4. Yes, I always had the impression tick boxes like RECURSE DIRECTORIES could be assumed to be persistent across Imgburn sessions, which is why I didn't think of that being an issue and hadn't looked there for a potential problem. I didn't load any saved projects either and have lately mostly used Imgburn with the settings it last saved. I always do only open one instance of Imgburn, never more than one. I would think that would be asking for trouble what with drive locking, etc so I definitely haven't had multiple instances of the program running as I didn't want to risk any drive access conflicts. The FOLDER SKIPPED log messages remain a mystery, but at least now I was able to write out the DVD image to the DVD+RW disc and get on with what I needed that for. I just tested Imgburn again. No disc inserted in the ODD this time. But unticking the RECUSE DIRECTORIES box and then trying to create the exact same layout in the disc layout editor, reliably reproduces the same problem with the SKIPPED FOLDERS messages. So for whatever reason Imgburn logic decides to do that, I'm not sure. I surmised originally that it was warning me that I'm losing folders in the layout even though I dragged it to the layout in the editor (when RECURSE box is unticked).
  5. Thanks for the follow up. After a few more failures just now trying to successfully create the disc layout for the DVD+RW write, it turns out the problem is due to the RECURSE SUBDIRECTORIES tick box being disabled. I'm glad it was something simple. Yet strangely, only the long path folders generated the SKIPPED FOLDERS log message but other folders with much shallower folder nesting did not (and also appeared to be added to the disc layout successfully despite recurse option disabled). I also noticed that the RECURSE SUBDIRECTORIES tick box for some reason sometimes does not persist across Imgburn sessions. This means I have to check the status of that box each time I start up Imgburn. As far as UDF 2.50 support for BD reading, I'm aware that actually UDF 2.50 was supported beginning with Windows Vista. Win-XP can support BD reading via UDF 2.50 if a 3rd party UDF driver supporting UDF 2.X is installed, such as the Nero UDF driver for In-CD packet writing, and that works fine reading BDs written in UDF 2.50 also. Also, just to be sure, if I choose only UDF as the file system, then under the ADVANCED - RESTRICTIONS tab, is it correct to assume that the any file system not used, in this case ISO9660 and JOLIET, that their tabs' settings are completely irrelevant regardless of what they may be set to, since I've selected only UDF as the file system? I was wondering if the on-line Imgburn guides / settings reference have ever been made into a downloadable PDF?
  6. As far as BD media goes, just now I had accidentally used SMART ERASE (while actually intended to use FULL ERASE) on BD-RE media to do a full erase and Imgburn popped up a dialogue box saying that smart erase cannot be used on BD media, so that answers that question.
  7. I'm trying to archive a number of folders and files onto a single layer DVD+RW disc which has already been properly formatted by Imgburn using the full erase function with the PROPERLY FORMATTED option enabled. There are several concerns / problems arising from building the image with the disc layout editor: I've already read up on the Imgburn guides before posting this. 1. I am still unclear about which file system needs to be used for a DVD-ROM format write - should only UDF 1.02 be selected, or should ISO9960 + UDF 1.02 be selected? I assume MODE-1/2048 data type is selection to be used. Since this isn't intended to be a DVD-Video format, I'm unsure if UDF should even be included as part of the file system selection. 2. If I use more than one file system, is it necessary for more than one volume label to be entered into all the file systems' volume label fields in order for the same volume label to appear under all file systems used in the write? 3. I have a folder on the source disk (HDD) that has more than 8 levels of folder nesting. I'm not sure how I did it the first time, but after using the disc layout editor, I go back to the INFORMATION tab and then click the CALCULATOR button to determine disc space consumption and only on the very first time I did this, the log reported that the long file paths file names were somehow altered (presumably because file path length was too long). Altered to what I'm not sure for starters, but now on a second session of Imgburn I tried to repeat the same process and the disc layout editor simply completely IGNORES the long pathed folders and they are now OMITTED from the layout completely. So I'm not sure which options I did or didn't tick the second time around that caused the file layout editor to ignore folders that had long paths. These tick boxes that I'm not sure about includes: FOLDER FILE NAME LENGTH - I selected LEVEL-2, 31 characters, and also ticked the boxes for ALLOW MORE THAN 8 DIRECTORY LEVELS and also ALLOW MORE THAN 255 CHARACTERS IN PATH. But no matter what I do, the disc layout editor continues to ignore long path folders from the layout I create even though I do drag the folders into the layout. It would seem to me that I may need to ZIP the long path folders into a ZIP file for optical disc write if the folder nesting is too deep. But I'd like to know which tick boxes I mentioned above should be enabled or not. I knew there was some deep nesting in some folders and had expected this sort of problem to arise during layout creation.
  8. I actually have my suspicions about what the cause is, likely due to a software update in a particular installed program due to the timing of the symptoms' occurance, but didn't want to go into it at length and keep the subject matter on topic related to ODD observations. As for back up, it's a practice for safe computing which goes without saying.
  9. Yes, except this isn't just some random problem with Windows. It was a very specific and never before encountered disk I/O issue that even looked like a hardware problem at first. its symptoms appeared even well before the pre-desktop loading phase finished in Windows, it was something fundamental on the lowest level of OS services. Could have been some type of damage to the installation somehow or it was altered during updating of my anti-virus software. I've been using both DOS and Windows for decades, and have never encountered something like this on a highly stabilized, tightened and lean running OS installation that's been running stably for a very long time. Best just to restore from image than to spend time hunting and fixing the problem. Though ultimately, it was interesting to see the disc tests afterwards in the graphs I posted.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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)
  15. 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.
  16. 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.
  17. 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.
  18. 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.
  19. 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).
  20. 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?
  21. 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.
  22. 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?
  23. 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.
  24. 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.
  25. 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.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.