Quality differences within same blu-ray tile

[geohei]

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.

Edited August 18, 2023 by geohei

[dbminter]

Well, I don't know what you mean by Blu-Ray "tile," however when you get to the outer edges of media, there's always the higher possibility of write failures.  This is generally down to the firmware needing an update.

[geohei]

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).

[dbminter]

Generally, there are little variations between discs in the same stack.

 

It could depend on how close to the edge you get.  The edge is always one of the iffiest parts to write to, going all the way back to CD-R.

 

It's generally down to the quality of the drive and how well the firmware writes.  What BD burner are you using?

[geohei]

The drive: ASUS BW-16D1HT 3.00 (SATA)

The media: Primeon BD-RDL50 GB 2x-8x

[dbminter]

Never heard of Primeon, so I can't comment on their quality.

 

I know that ASUS model has had various quality issues since its release.  Upon release, it destroyed DVD+RW and BD-RE discs.  The last time I tried one, it didn't write properly to DVD+R DL.

[geohei]

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.

[dbminter]

Well, a well made product won't have a problem.  If the firmware is correct for the writing strategy to the media, it won't matter.  However, I do know that the ASUS has had issues since it was released, and I don't use them because they don't write properly to DVD+R DL.  They haven't updated the firmware in 4 years, and only a firmware update will fix the issue.

 

I took a look at that link.  I took 3 years of high school German but I'm not that good.  Yet, I did manage to navigate to the item.    I've never seen those before.  You could try the Verbatim BD-R DL if you can find them on Amazon.de.

 

Another problem is the issue of BD-R DL media itself.  These seem to have had problems from the release.  The WH16NS40 from LG never did write properly to BD-RE DL, so I would guess BD-R DL had the same problem.  Then again, I've only ever used Verbatim BD-RE DL media in the NS60.

[geohei]

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.

[dbminter]

I have no direct experience with BD-R DL.  Just with BD-RE DL.  My experience with BD-RE DL is I'd sometimes write to them for the first time and try to write to them again a year later and they'd fail.  And I've seen several issues reported with BD-R DL on these forums.  So, I have no empirical evidence to go by, but the circumstantial seems quite damning.

[geohei]

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.
...

 

[dbminter]

My recommendation still stands.  Try to find Verbatim BD-R DL with the VERBAT-IM Disc ID.  If those fail, try a different BD burner.  I've never used Verbatim BD-R DL but I've used Verbatim BD-R for years.  And my BD-RE DL were all Verbatim, but those didn't have a high long term lifespan.

[geohei]

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).

Edited August 26, 2023 by geohei

[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.

Edited August 28, 2023 by geohei

[dbminter]

Ritek, depending on where you are in the world, can either be good 2nd tier media (North America) or pretty bad (Europe).  However, I've never used Ritek BD-R DL before, or even Ritek BD-R SL.  99.99% of all the BD-R I've ever burned are Verbatim VERBAT-IM media.  I've burned 2 Sony BD-R and 50% of them failed.  I burned 2 to 4 other non Verbatim media only because they were given to me with some DVD-R's I bought from a friend who had a supply he no longer needed.