Jump to content


  • Posts

  • Joined

  • Last visited

Profile Information

  • Gender

discuser's Achievements

ISF Member

ISF Member (2/5)

  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.
  • Create New...

Important Information

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