BD-RE virgin disc write pre-erasure

[discuser]

Considering it's been 6 years or whatever since the 2.5.8.0 release, there have been very few verified bugs reported / things fixed. The changelog for the beta (non public) version only contains 7. Your one (within the bd disc info text) is purely cosmetic and would very easily go unnoticed if you don't scroll right through the disc info text / understand what you're looking at.

 

I did stumble across another consistently reproducible bug earlier which I haven't reported yet because I'm presently a bit tied up with doing lots of BD-RE writing recently. The bug in question pertains to the disc layout editor. If your current verified bug list doesn't contain any reports on the disc layout editor, this problem I discovered may be a new one for your list. But I need to re-create those conditions first and then write up a description for you. Would you prefer that to be posted as a forum message or sent to you as PM for further investigation?

[LIGHTNING UK!]

Nope, no DLE editor stuff. Half of it is a 3rd party component though (the 'Explorer' side of things), so it may not be something for me to fix.

 

In the 'Bugs' forum is just fine. Thanks.

[discuser]

Nope, no DLE editor stuff. Half of it is a 3rd party component though (the 'Explorer' side of things), so it may not be something for me to fix. In the 'Bugs' forum is just fine. Thanks.

If by half of the DLE disc layout editor on the EXPLORER side you mean the top half of the DLE, then possibly it could be a bug you might have control over. It occurs when items are dragged from the Explorer side top half and dropped into to the bottom half of the DLE. I'll post the details in the BUGS section once I get around to it.

Edited May 23, 2018 by discuser

[discuser]

Yes, that’s just what happens when the drive burns and defect management is enabled (spare areas are present). The drive verifies as it goes.

I've erase-formatted a Verbatim BD-RE disc that I know has some errors during formatting (it will be retired) around the end of layer 0 of this dual layer disc, the Imgburn log reported about 60 incidences of this error in close succession for this particular disc:

 

Failed to Zero Sectors XXXXXXXX - XXXXXXXXXX - Reason: No Additional Sense Information

Retrying (1 of 20)...

 

After these incidences passed, the erasure-formatting continued for the remainder of the disc space without incident.

 

I'm assuming this would trigger the spare sector usage for each incident that occured though I don't think that the spare sectors pool would have been used up. But what in your opinion does this error during full erasure-formatting mean on a BD-RE when spare sectors are enabled? I've erase-formatted many BD-RE-DL and BD-RE-TL discs so far and the vast majority of them do not have errors and most discs format cleanly in their entirety.

 

The reason why I'm retiring this particular BD-RE disc is because although the format completed with errors which were presumably replaced by spare sectors successfully, during a previous data write after formatting, the verify phase (which occured after write-with-hardware-on-the-fly-verify), it encountered an unrecoverable read error, which I thought was odd with defect management presumably enabled.

Edited May 23, 2018 by discuser

[LIGHTNING UK!]

As mentioned in a previous post, I wouldn't have expected the drive to return any sort of failure/error if it's reallocating bad sectors as it goes - assuming that part itself goes ok. It should all be handled behind the scenes and software wouldn't know about it.

 

The drive is claiming a write operation failed, but it's not returning any sort of reason for the failure (hence the 'no additional sense information' return code).

 

So basically, I have no clue what's going on here.

[discuser]

As mentioned in a previous post, I wouldn't have expected the drive to return any sort of failure/error if it's reallocating bad sectors as it goes - assuming that part itself goes ok. It should all be handled behind the scenes and software wouldn't know about it.

 

The drive is claiming a write operation failed, but it's not returning any sort of reason for the failure (hence the 'no additional sense information' return code). So basically, I have no clue what's going on here.

 

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.

[LIGHTNING UK!]

The file system (udf etc) has nothing to do with any of this. An erased disc has no file system.

 

No additional sense information doesn’t mean anything in its own right. When an I/O command fails and the sense area is blank (no additional sense information), it’s the equivalent of just saying ‘no’ and then giving no reason.

 

Correct, in terms of bad sector reallocation, the zeroing phase is no different to a normal Write operation.

[discuser]

The file system (udf etc) has nothing to do with any of this. An erased disc has no file system. No additional sense information doesn’t mean anything in its own right. When an I/O command fails and the sense area is blank (no additional sense information), it’s the equivalent of just saying ‘no’ and then giving no reason. Correct, in terms of bad sector reallocation, the zeroing phase is no different to a normal Write operation.

 

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?

 

[dbminter]

BTW, does Pioneer make an internal slim SATA BD burner?  Or are they all either USB or half height internal SATA's?

[discuser]

BTW, does Pioneer make an internal slim SATA BD burner?  Or are they all either USB or half height internal SATA's?

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.

Edited June 16, 2018 by discuser