Jump to content

ImgBurn Support Forum uses cookies. Read the Privacy Policy for more info. To remove this message, please click the button to the right:    I accept the use of cookies

Photo

BD-RE virgin disc write pre-erasure


Forum Rules

Read the Guides forum if you don't know how to do something. :readbook:
If you have a question or a problem, check the FAQ and use the Search to see if you can find the answer for yourself. :lightbulb:
If you're having trouble burning double layer media, read Here.
Still stuck? Create a new thread and describe your issue in detail.
Make sure you include a copy of the program's log in your post. No log = :chair:


  • Please log in to reply
57 replies to this topic

#41 discuser

discuser

    ISF Newbie

  • Members
  • Pip
  • 43 posts
  • Gender:Male

Posted 17 May 2018 - 02:58 AM

I've had a chance to write to some BD-REs (DL and TL capacities) on my Pioneer 06 and 09 series BD writers after they have been erase-formatted with spare sectors on. I noticed that when performing erase-formatting with spare sectors option enabled, the Imgburn activity log reports the effective speed is around 0.9X. Interestingly, for BD-RE discs erase-formatted this way, the write speed is also around 0.9X to 1.0X even though the selected write speed is 2X, when used with Verbatim BD-RE-DL and Sony BD-RE-TL discs.

I'm wondering whether the effective write speed being around half (0.9X) of the selected write speed (2X) is due to some type of immediate read after write verification procedure when writing, or what factors are at play here that results in this halved write speed? I noticed that during the verification process, the read speed reverts to 2X speed but only the write phase on a BD-RE pre-formatted with spare sectors enabled results in a 0.9X effective write speed. Other than the halved write speed, the written disc works perfectly fine and verifies fully without errors. Perhaps L-UK has some idea what is at play here to shed some light on this halved write speed.

 



#42 LIGHTNING UK!

LIGHTNING UK!

    Author of ImgBurn

  • Admin
  • PipPipPipPipPip
  • 29,571 posts
  • Gender:Male
  • Location:United Kingdom

Posted 17 May 2018 - 06:23 AM

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.
Please don't PM me with questions that should be posted in the forum. I won't reply - Especially if you have post count of 0!!!

Replies to posts belong in the forum where everyone can read them. Please don't PM them.

In fact, don't PM me at all unless it's something I've asked to be told about!

Before asking questions, search the forum to see if someone else already has.

Use the FAQ and Guides forums to your advantage. I don't want to have to tell you to read them!

#43 discuser

discuser

    ISF Newbie

  • Members
  • Pip
  • 43 posts
  • Gender:Male

Posted 18 May 2018 - 01:04 AM

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.

Thanks for confirming this. Since the drive already verifies piece meal, interleaved with the write process, then when defect management is enabled / spare sectors enabled, would there still be any point to tick the VERIFY box for Imgburn to reverify at 2X speed after the combined write-verify phase at 0.9X is over? It would seem that I might be able to save a couple of hours for a separate after-write verify process.


Edited by discuser, 18 May 2018 - 01:05 AM.


#44 LIGHTNING UK!

LIGHTNING UK!

    Author of ImgBurn

  • Admin
  • PipPipPipPipPip
  • 29,571 posts
  • Gender:Male
  • Location:United Kingdom

Posted 18 May 2018 - 04:52 AM

The program’s verification process would pick up data corruption issues... which is something the drive’s internal one can’t do.

It’s up to you really.
Please don't PM me with questions that should be posted in the forum. I won't reply - Especially if you have post count of 0!!!

Replies to posts belong in the forum where everyone can read them. Please don't PM them.

In fact, don't PM me at all unless it's something I've asked to be told about!

Before asking questions, search the forum to see if someone else already has.

Use the FAQ and Guides forums to your advantage. I don't want to have to tell you to read them!

#45 dbminter

dbminter

    ISF God

  • Beta Team Members
  • PipPipPipPipPip
  • 5,871 posts
  • Gender:Male

Posted 19 May 2018 - 09:17 PM

One point though, I noticed you called them "full" height drives, but in fact they are actually HALF height. All drives are half height today because they are half the height of the original full height 180 KB / 360KB floppy drives and hard discs in the old days.

 

 

BTW, what are slim drives called?  Quarter height drives?  Are they half the size of the half height drives?



#46 discuser

discuser

    ISF Newbie

  • Members
  • Pip
  • 43 posts
  • Gender:Male

Posted 20 May 2018 - 08:32 PM

 

BTW, what are slim drives called?  Quarter height drives?  Are they half the size of the half height drives?

 

As far as I know they are simply called slim or slim line drives. Rarely anyone calls drives half height anymore because full height drives haven't been around for decades and everything is assumed to be half height form factor unless otherwise specified.



#47 discuser

discuser

    ISF Newbie

  • Members
  • Pip
  • 43 posts
  • Gender:Male

Posted 22 May 2018 - 05:58 AM

The program’s verification process would pick up data corruption issues... which is something the drive’s internal one can’t do. It’s up to you really.


Since we're on the subject of data integrity, I would be interested in hearing your opinion regarding the pros and cons on setting the VERIFY configuration page's READ ERROR handling parameters. I have already read the Imgburn guide sections relevant to these parameters. So far, in some cases of BD-RE, I have encountered 2 types of verify errors when there are occasional bad spots encountered on the media (particularly with used quality BD-RE media that I am re-using even though they have been very carefully handled):

1. During erasure-formatting with spare sectors enabled, Imgburn reports the data error / media failure in the activity log and presumably marks the area as unuseable and then relocates the bad sector(s). Does subsequent user data writes follow the logged bad sectors during the erasure-formatting or does each data write with a spare sector enabled disc result in a different re-allocation of bad sectors depending on the actual write result?

2. During user data writing (after the disc was erasure-formatted with spare sectors enabled), the write-verify phase (effective recording speed about 0.8X to 1.0X when target speed is set to 2.0X) during data recording detected a write problem, reports it in the log and I assume that the bad sector is relocated to a spare sector. However, after data recording, during Imgburn's verify-only process (read speed 2X), when a verify error is encountered, Imgburn stops and then awaits user input to a prompt whether to retry, continue with ignore or abort the verify process completely.

My questions would be:

1. If the SOFTWARE RETRIES configuration parameter was set to other than ZERO (the default value), would Imgburn attempt up to a maximum of the retry value configured, and then continue the retry WITHOUT prompting the user? Or is it necessary to tick the box IGNORE READ ERRORS before the prompt will be suppressed? If the prompt is suppressed, would data errors still be logged in the activity log nevertheless?

2. Does the erasure-formatting retry attempts (when spare sectors are enabled) respect the SOFTWARE RETRIES configuration values before moving to relocate bad sectors with spare sectors? From my observation, it appears to be. But I surmise that increasing the retry count attempts may reduce data integrity in the end because it would mean the process is more tolerant of marginally readable sectors that read successfully with multiple retries but may fail later after extended storage, so it seems to me that higher retry count would lower potential data integrity of the resulting disc written, ultimately.

 


Edited by discuser, 22 May 2018 - 05:59 AM.


#48 LIGHTNING UK!

LIGHTNING UK!

    Author of ImgBurn

  • Admin
  • PipPipPipPipPip
  • 29,571 posts
  • Gender:Male
  • Location:United Kingdom

Posted 22 May 2018 - 07:56 AM

1. Reallocation of bad sectors isn't ImgBurn's job, it's handled by the drive.

2. Due to the above, you should in theory never get a 'Write Error' when the drive's 'Defect Management' feature is enabled - and it's enabled when a disc formatted with spare areas is put in it. You might get an error if it's unable to reallocate the sectors (spare areas full) or if there's some other sort of issue with the drive/disc.

Questions

1. I doubt software retries during the verify phase are going to make a difference to the data on the disc. Adjusting the retries value make the program make that many attempts before then prompting the user. You get rid of the prompt by using the 'ignore read errors' option - it'll still perform X retries before ignoring though, as per the retries value.

2. No... but then what you've said doesn't really apply as the software isn't doing the reallocating of bad sectors. The drive will reallocate bad sectors if defect management is active and it feels it needs to.
Please don't PM me with questions that should be posted in the forum. I won't reply - Especially if you have post count of 0!!!

Replies to posts belong in the forum where everyone can read them. Please don't PM them.

In fact, don't PM me at all unless it's something I've asked to be told about!

Before asking questions, search the forum to see if someone else already has.

Use the FAQ and Guides forums to your advantage. I don't want to have to tell you to read them!

#49 discuser

discuser

    ISF Newbie

  • Members
  • Pip
  • 43 posts
  • Gender:Male

Posted 22 May 2018 - 10:19 AM

2. Due to the above, you should in theory never get a 'Write Error' when the drive's 'Defect Management' feature is enabled - and it's enabled when a disc formatted with spare areas is put in it. You might get an error if it's unable to reallocate the sectors (spare areas full) or if there's some other sort of issue with the drive/disc.


Thanks for that clarification which does help in determining what is happening at what level (software or drive hardware) when exception conditions occur. I wrote to a Verbatim BD-RE-DL disc earlier (the original Verbatim production runs that were truly made in Japan) which was erase-formatted with spare sectors enabled, but during the full-erase-format process, did not yield any errors at all. Coming out of that I assumed the disc formatted flaw free and proceeded to write data to it and it was during the write-with-verify phase that the Pioneer 09-drive reported a single write error, which I thought was strange but assumed it would be taken care of by spare sector replacement. So a single error would not have caused a spare sectors fully depleted condition. I let the write phase complete and when it got to the verify only phase (reading at 2X), it got to approximately the same spot in the data (I am guessing based on the percentage reading of how far through the entire length of the data), the verify error prompt popped up and repeated retries did not resolve the problem. So I aborted the verify retry and abandoned the disc.

I'm going to use a different Verbatim BD-RE-DL and repeat the entire erase-formatting with spare sectors enabled and then rewrite the data to it. This time I will try using the Pioneer 06-drive instead to see if it makes any difference. So it would seem based on what you describe the expected behaviour would be, the write error is an anomaly of unknown reason. Unfortunately, the Imgburn log has been overwritten, or I would have posted the relevant section here. If it happens again I'll make sure I do so.

In general, my experience so far with erasure-formatting with spare sectors enabled and then subsequent data writes have been very stable under Imgburn. Overall, results have been generally excellent, and I'm pleased to see that I was able to use Sony BD-RE-TL completely normally right off the bat, though I am rewriting many of my existing BD-RE-DL discs because they previously were not formatted correctly (via Nero) and I am redoing all of them with spare sectors enabled to increase data integrity.

 

I hope there will be a release of a much needed update of Imgburn in the near future to address all the various known bugs in the current 2.58 release from 2013, especially with higher capacity media now in use.



#50 LIGHTNING UK!

LIGHTNING UK!

    Author of ImgBurn

  • Admin
  • PipPipPipPipPip
  • 29,571 posts
  • Gender:Male
  • Location:United Kingdom

Posted 22 May 2018 - 10:59 AM

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.
Please don't PM me with questions that should be posted in the forum. I won't reply - Especially if you have post count of 0!!!

Replies to posts belong in the forum where everyone can read them. Please don't PM them.

In fact, don't PM me at all unless it's something I've asked to be told about!

Before asking questions, search the forum to see if someone else already has.

Use the FAQ and Guides forums to your advantage. I don't want to have to tell you to read them!

#51 discuser

discuser

    ISF Newbie

  • Members
  • Pip
  • 43 posts
  • Gender:Male

Posted 22 May 2018 - 07:16 PM

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?



#52 LIGHTNING UK!

LIGHTNING UK!

    Author of ImgBurn

  • Admin
  • PipPipPipPipPip
  • 29,571 posts
  • Gender:Male
  • Location:United Kingdom

Posted 22 May 2018 - 09:42 PM

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.
Please don't PM me with questions that should be posted in the forum. I won't reply - Especially if you have post count of 0!!!

Replies to posts belong in the forum where everyone can read them. Please don't PM them.

In fact, don't PM me at all unless it's something I've asked to be told about!

Before asking questions, search the forum to see if someone else already has.

Use the FAQ and Guides forums to your advantage. I don't want to have to tell you to read them!

#53 discuser

discuser

    ISF Newbie

  • Members
  • Pip
  • 43 posts
  • Gender:Male

Posted 23 May 2018 - 05:42 AM

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 by discuser, 23 May 2018 - 05:43 AM.


#54 discuser

discuser

    ISF Newbie

  • Members
  • Pip
  • 43 posts
  • Gender:Male

Posted 23 May 2018 - 08:11 AM

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 by discuser, 23 May 2018 - 08:13 AM.


#55 LIGHTNING UK!

LIGHTNING UK!

    Author of ImgBurn

  • Admin
  • PipPipPipPipPip
  • 29,571 posts
  • Gender:Male
  • Location:United Kingdom

Posted 23 May 2018 - 08:19 AM

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.
Please don't PM me with questions that should be posted in the forum. I won't reply - Especially if you have post count of 0!!!

Replies to posts belong in the forum where everyone can read them. Please don't PM them.

In fact, don't PM me at all unless it's something I've asked to be told about!

Before asking questions, search the forum to see if someone else already has.

Use the FAQ and Guides forums to your advantage. I don't want to have to tell you to read them!

#56 discuser

discuser

    ISF Newbie

  • Members
  • Pip
  • 43 posts
  • Gender:Male

Posted 24 May 2018 - 11:47 AM

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.



#57 LIGHTNING UK!

LIGHTNING UK!

    Author of ImgBurn

  • Admin
  • PipPipPipPipPip
  • 29,571 posts
  • Gender:Male
  • Location:United Kingdom

Posted 24 May 2018 - 12:04 PM

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.
Please don't PM me with questions that should be posted in the forum. I won't reply - Especially if you have post count of 0!!!

Replies to posts belong in the forum where everyone can read them. Please don't PM them.

In fact, don't PM me at all unless it's something I've asked to be told about!

Before asking questions, search the forum to see if someone else already has.

Use the FAQ and Guides forums to your advantage. I don't want to have to tell you to read them!

#58 discuser

discuser

    ISF Newbie

  • Members
  • Pip
  • 43 posts
  • Gender:Male

Posted 24 May 2018 - 01:08 PM

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?

 






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users