Jump to content

Quality differences within same blu-ray tile


geohei

Recommended Posts

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 by geohei
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by geohei
Link to comment
Share on other sites

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 by geohei
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

×
×
  • Create New...

Important Information

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