geohei

To complete ... I found the following for my "Primeon" media in the log: I 17:09:33 Source Media Type: BD-R (Disc ID: RITEK-DR2-000) Also, I now managed to write successfully 49.947.934.720 and 49.511.464.960 (highest so far) bytes.

I'll give those a try once I finished my Primeon media. Thanks. Just for info ... the media advertises that 50.050.629.632 bytes can be written. However 49.990.926.336 fails, but 49.918.443.520 worked. I will check if this applies for all media (of the remaining Primeon stack).

To make the thread complete. Here the log ... ... I 20:05:17 Writing LeadIn... I 20:05:18 Writing Session 1 of 1... (1 Track, LBA: 0 - 24427359) I 20:05:18 Writing Track 1 of 1... (MODE1/2048, LBA: 0 - 24427359) I 20:05:18 Writing Layer 0... (LBA: 0 - 12219391) W 20:25:58 Failed to Write Sectors 10885696 - 10885727 - Reason: Invalid Field in CDB W 20:25:58 Retrying (1 of 20)... W 20:25:58 Retry Failed - Reason: Invalid Field in CDB W 20:25:58 Retrying (2 of 20)... W 20:25:58 Retry Failed - Reason: Invalid Field in CDB W 20:25:58 Retrying (3 of 20)... W 20:25:58 Retry Failed - Reason: Invalid Field in CDB W 20:25:58 Retrying (4 of 20)... W 20:25:58 Retry Failed - Reason: Invalid Field in CDB W 20:25:58 Retrying (5 of 20)... W 20:25:58 Retry Failed - Reason: Invalid Field in CDB W 20:25:58 Retrying (6 of 20)... W 20:25:58 Retry Failed - Reason: Invalid Field in CDB W 20:25:58 Retrying (7 of 20)... W 20:25:58 Retry Failed - Reason: Invalid Field in CDB W 20:25:58 Retrying (8 of 20)... W 20:25:58 Retry Failed - Reason: Invalid Field in CDB W 20:25:58 Retrying (9 of 20)... W 20:25:58 Retry Failed - Reason: Invalid Field in CDB W 20:25:58 Retrying (10 of 20)... W 20:25:58 Retry Failed - Reason: Invalid Field in CDB W 20:25:58 Retrying (11 of 20)... W 20:25:58 Retry Failed - Reason: Invalid Field in CDB W 20:25:58 Retrying (12 of 20)... W 20:25:58 Retry Failed - Reason: Invalid Field in CDB W 20:25:58 Retrying (13 of 20)... W 20:25:58 Retry Failed - Reason: Invalid Field in CDB W 20:25:58 Retrying (14 of 20)... W 20:25:58 Retry Failed - Reason: Invalid Field in CDB W 20:25:58 Retrying (15 of 20)... W 20:25:58 Retry Failed - Reason: Invalid Field in CDB W 20:25:58 Retrying (16 of 20)... W 20:25:58 Retry Failed - Reason: Invalid Field in CDB W 20:25:58 Retrying (17 of 20)... W 20:25:58 Retry Failed - Reason: Invalid Field in CDB W 20:25:58 Retrying (18 of 20)... W 20:25:58 Retry Failed - Reason: Invalid Field in CDB W 20:25:58 Retrying (19 of 20)... W 20:25:58 Retry Failed - Reason: Invalid Field in CDB W 20:25:58 Retrying (20 of 20)... W 20:25:58 Retry Failed - Reason: Invalid Field in CDB E 20:46:05 Failed to Write Sectors 10885696 - 10885727 - Reason: Invalid Field in CDB I 20:46:05 Synchronising Cache... W 20:46:05 Synchronise Cache Failed! - Reason: Invalid Field in CDB E 20:46:08 Synchronise Cache Failed! - Reason: Invalid Field in CDB W 20:46:13 User opted to skip the 'Close Track/Session/Disc' functions. ...

Thanks for the reply. Sorry for the German Amazon link. So basically, you say that BD-R DL media have problems by itself (in general), my particular brand (Primeon) might have issues and the drive (ASUS) could be the culprit. So it could be anything.

https://www.amazon.de/gp/product/B00ULAO50U/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&th=1 If I get it right, you say the culprit should be the drive, not the media, right? Nevertheless, I'm surprised that the drive might fail to write at the edge, while the rest of the media is written properly. I would have have expected that drive/media combination either writing correctly or mot at all, but not that there is a tolerance (in the drive) which only shows at the edges.

The drive: ASUS BW-16D1HT 3.00 (SATA) The media: Primeon BD-RDL50 GB 2x-8x

Sorry ... replace "tile" with "stack". So the boundary layer is at the outer edge of the media? Is there a difference in production quality within the same media stack? I believe it's strange that one fails an the boundary layer, and the next one work (while trying to write exactly the same data).

Hi. Is it possible, that the same manufacturer/tile of blu-ray BD-R DL (#50 GB) media, has such production tolerances/differences, that only approx. 49.5xx.xxx.xxx bytes (i.s.o 50.050.629.632 bytes) can be written? On top I noticed that one BD-R DL media fails at the layer change (#25 GB) while the next one succeeds (same tile!). Also, Test Mode always runs successfully, while real writes might fail afterwards. Is all of the above "normal"? If yes, I have to leave about 3% free space in the future in order to be safe. Many thanks.

Yes, the drive went stuck forever. I can't recall if it was still spinning or not. I had to stop ImgBurn via Task Manager (End Task). Even after that, the drive was flashing and I could not eject the disc. I had to restart the system. After restart of the system, I checked the disc and it looked like all data was on. Since all data had md5 checksums, I ran them. All data was correct! Nevertheless I didn't "trust" this disc, reduced the volume from 50.045... to 50.043... and this time the write operation succeeded!

Just to make it clear. If the disc reports a capacity to ImgBurn, and ImgBurn knows how much data to write, does this mean that all data (including structures, overhead, ...) fit the disc and will be written successfully? In other words, could it be that the 50.045.xxx.xxx Bytes were too much for the disc and ImgBurn would not complain prioir write, but the drive would eventually just fail to write (like in my case)?

Yes, it is at the very end of the disc. Nevertheless it shouldn't do so. I did many sessions with similar payload (99% full) and never had this issue before.

I 06:24:32 ImgBurn Version 2.5.8.0 started! I 06:24:32 Microsoft Windows 7 Ultimate x64 Edition (6.1, Build 7601 : Service Pack 1) I 06:24:32 Total Physical Memory: 16.664.720 KiB - Available: 11.269.268 KiB W 06:24:32 Drive X:\ (FAT32) does not support single files > 4 GiB in size. I 06:24:32 Initialising SPTI... I 06:24:32 Searching for SCSI / ATAPI devices... I 06:24:32 -> Drive 1 - Info: ASUS BW-16D1HT 3.00 (K:) (SATA) I 06:24:32 -> Drive 2 - Info: ATAPI iHBS312 2 PL17 (L:) (SATA) I 06:24:32 Found 2 BD-ROM/HD DVD-ROMs, 1 BD-RE and 1 BD-RE XL! I 06:24:44 Project Successfully Loaded! I 06:24:44 File Name: E:\Application Data\ImgBurn\Project Files\Doc_647.ibb I 06:24:49 Operation Started! I 06:24:49 Building Image Tree... I 06:24:49 Calculating Totals... I 06:24:49 Preparing Image... I 06:24:49 Contents: 40 Files, 0 Folders I 06:24:49 Content Type: Data I 06:24:49 Data Type: MODE1/2048 I 06:24:49 File System(s): UDF (2.50) I 06:24:49 Volume Label: Documentary_647 I 06:24:49 Size: 50.045.882.694 bytes I 06:24:49 Sectors: 24.436.485 I 06:24:49 Image Size: 50.046.959.616 bytes I 06:24:49 Image Sectors: 24.436.992 I 06:24:58 Operation Successfully Completed! - Duration: 00:00:08 I 06:24:58 Operation Started! I 06:24:58 Source File: -==/\/[BUILD IMAGE]\/\==- I 06:24:58 Source File Sectors: 24.436.992 (MODE1/2048) I 06:24:58 Source File Size: 50.046.959.616 bytes I 06:24:58 Source File Volume Identifier: Documentary_647 I 06:24:58 Source File Volume Set Identifier: 565033180174E085 I 06:24:58 Source File Application Identifier: ImgBurn v2.5.8.0 I 06:24:58 Source File Implementation Identifier: ImgBurn I 06:24:58 Source File File System(s): UDF (2.50) I 06:24:58 Destination Device: [5:0:0] ASUS BW-16D1HT 3.00 (K:) (SATA) I 06:24:58 Destination Media Type: BD-R (Disc ID: RITEK-DR2-000) I 06:24:58 Destination Media Supported Write Speeds: 2x; 4x I 06:24:58 Destination Media Sectors: 24.438.784 I 06:24:58 Write Mode: BD I 06:24:58 Write Type: DAO I 06:24:58 Write Speed: 4x I 06:24:58 Hardware Defect Management Active: No I 06:24:58 BD-R Verify Not Required: Yes I 06:24:58 Link Size: Auto I 06:24:58 Lock Volume: Yes I 06:24:58 Test Mode: No I 06:24:58 OPC: No I 06:24:58 BURN-Proof: Enabled I 06:24:58 Write Speed Successfully Set! - Effective: 17.984 KB/s (4x) I 06:25:24 Filling Buffer... (80 MiB) I 06:25:24 Writing LeadIn... I 06:25:25 Writing Session 1 of 1... (1 Track, LBA: 0 - 24436991) I 06:25:25 Writing Track 1 of 1... (MODE1/2048, LBA: 0 - 24436991) I 06:25:25 Writing Layer 0... (LBA: 0 - 12219391) I 06:54:33 Writing Layer 1... (LBA: 12219392 - 24436991) I 07:17:48 Synchronising Cache...

Hi. First time this happened. I wasted already three BR 50 GB on this. No clue why this happens. I have 50.045.xxx.xxx bytes of data to be written. All goes fine until the very end where ImgBurn 2.5.8.0 is stuck w/ the message "Synchronizing Cache..." (in Log). No error messages, also not in Log. Any ideas why? Thanks

That answers my question! Many thanks!

I checked ... the drive writes DVDs and CDs without any problem. Only the BD-Rs create problems. Is this possible? Besides this ... does a burn speed reduction also affect the calibration, or only the burn process itself? Thanks,