BD-RE virgin disc write pre-erasure

[LIGHTNING UK!]

If the drive supports formatting with certification, I'd expect this bit to read differently once a full format (with certification) has been completed...

 

Disc Definition Structure:

Certified: No

Scanned: No

^ Is as it reads after a full erase (format) in a Pioneer 209.

 

The 'Prefer Format With Full Certification' option within ImgBurn only causes it to ask the drive to do a full format with full certification. If that fails, it asks it to do a full format with quick certification. If that fails, it asks it to do a full format with no certification.

So if that option isn't checked, it skips the full cert request and goes straight for the quick cert one.

 

Hardware defect management is activated when a disc has been formatted with spare areas. Nothing else should influence that (in terms of formatting options) and it's handled entirely by the drive.

 

It's possible to bypass defect management and the automatic write-verification that goes with it by setting the appropriate flag in every 'Write' command sent to the drive. For BD-R, that's the 'BD-R Verify Not Required' option and for BD-RE it's the 'BD-RE FastWrite' option. Generally speaking, it would be pointless to format with spare areas enabled and have either of those option enabled.

 

So assuming you've formatted with spare areas enabled and aren't trying to bypass the auto write-verification, the drive should remap bad blocks as it attempts to write to them. I doubt anything happens when you're just reading the disc and come across something unreadable.

 

The whole reason for ImgBurn performing the 'zeroing sectors' stage as part of a full format is that the format process itself doesn't appear to do it. So you can issue a 'full format with full cert' command to the drive and it'll finish after x hours with disc still containing data. Now... don't quote me on that as it could be that when I noticed that happening (it not zeroing the sectors), I was full formatting in a Pioneer and so the full cert part wasn't happening anyway. Maybe I'll test it out again and compare the results of LG drives against Pioneer ones.

[discuser]

Thanks for the additional clarifications. It gives me a pretty good sense / grasp of how to use Imgburn with those concerns. I have the same DISC DEFINITION STRUCTURE values after erasure-formatting on both the Pioneer 06 and 09 series BD writers as you mentioned.

As for Pioneer drives, they do have the industrial grade BDR-PR1M series BD-XL writers released a few years back, which they want to charge over US$300 for the drives. They were specifically designed for archival and error / defect management and does come with proprietary Pioneer disc defect management software. The C suffix drive appears to be for the purpose of defect management whereas the A suffix drive is mainly for writing. Both drives primarily designed for Mitsubishi/MKM archival grade 200 year life BD-R media. Though, if M-Disc has an archival life approaching 1000 years, I don't see the point. If you get your hands on these Pioneer ODDs, it would be interesting to know how you find the defect manangement fairs.

[discuser]

I finally completed a first-time formatting of Sony BD-XL-RE-TL 100 GB discs (MID: SONY-ET2-002) successfully and it went without a hitch on the Pioneer 09-series ODD the first time. I actually did two passes of erasure formatting because on the first pass I forgot to enable spare sectors area even though I already disabled the certification write-option. With spare sectors disabled, Imgburn erase-formatted at 2X speed and completed the disc in approximately 3 hours and 9 minutes. During the second pass to reformat the same disc with spare sectors made available, the procedure was reported in the log as having an average speed of 0.9X (with this particular ODD anyway) which required approximately 6 hours and 44 minutes to complete, actually quite a bit shorter than the 10 hours I had expected as I had read another user on the forum here found the defect managed formatting for BD-XL-RE-TL was proceeding at 0.6X speed instead. The effective available space after the formatting is about 90.23 GB for a 100 GB disc. I was wondering if L-UK or anyone else in the know could enlighten me on a few technical points:

--------------------------
1. With certification mode disabled in write-options, I only got one format-error message this time (instead of the two messages I used to get):

FormatDisc(FT: 0x30, FST: 0x03) Not Supported!

I'm not sure which function this error refers to that indicates the Pioneer drive doesn't support.

--------------------------
2. In the device details, it says that:

Layer Information:
Layer 0 Sectors: 242,783,376 (513.2%)
Layer 1 Sectors: 655,660,176 (1386%)
Layer 2 Sectors: 3,443,829,472 (7280%)

I wanted to learn and understand what this sector count reported for each layer meant. I thought on a BD-RE-TL or BD-R-TL disc that each layer was 33 GB capacity so I'm unsure why layers 0 to 2 has such a different sector count from each other, and what the percentage value included means, and whether these figures hint of anything regarding quality / defects as discovered by the erasure-formatting process with spare sectors made available.

--------------------------
3. In the BD disc information listed for each layer, there are a few parameters:
BCA Present: Yes
First PAA of Data Zone: 2,702,409,216
Last PAA of Data Zone: 48,391,268

I was interested to know what BCA and PAA stood for. If you think this would be explained better in any of the BDA's BD general white paper (which is currently on its 5th edition released in 2018.01), I would be happy to read up on it there if you have any pointers or referrals to any sections in the white paper.

--------------------------

I would be great to get a better grasp on these details, it helps me to feel more conversant with Imgburn and its advanced functions / features and a better usage experience to be more informed. Thanks.
 

[LIGHTNING UK!]

1. Quick certification.

 

You disabled (made it skip) full certification, so as per a previous reply, it’s requesting quick cert before falling back to no cert.

 

2. That looks like a bug to me. TL media barely existed back in 2013, and I’m pretty sure I’ve never looked at BDRE TL media at all.

 

3. Burst Cutting Area

Physical ADIP Address

[discuser]

1. Quick certification. You disabled (made it skip) full certification, so as per a previous reply, it’s requesting quick cert before falling back to no cert.

2. That looks like a bug to me. TL media barely existed back in 2013, and I’m pretty sure I’ve never looked at BDRE TL media at all.

3. I’ll have to look it up when I’m at my pc.

Regarding:

 

1. OK, so previously one format error message was failure to perform full certification, and the other format error message was failure to perform quick certification. Got it.

 

2. Interesting to know. Hopefully it's not an "overflow" type of bug that caused meaningless numbers like this. I have no idea what happens within Imgburn, just visualizing what could be going on. Please keep us informed if you uncover the cause. So are you saying that the percentage value displayed for each layer should be say, 100% for a defect free layer (i.e. all clusters available) and less than 100% for a layer that has defects (provided that spare sectors are made available during format)?

 

Sony BD-RE-TL media is quite cheap now, though the only available inventory are all designated as domestic Japanese inventory, though Verbatim does have BD-XL-R-TL write once media now sold globally. I'll be continuing the Sony BD-RE-TL media formatting as I have a stack of these virgin discs to go through and due to the nearly 7 hours format / verify time required, I will usually try start formatting very late night and by early morning, the process will be completed for one disc.

 

3. Thanks for the acronym explanations. I'll look them up further.

 

Edited April 13, 2018 by discuser

[discuser]

2. That looks like a bug to me. TL media barely existed back in 2013, and I’m pretty sure I’ve never looked at BDRE TL media at all.

I've reviewed the DEVICE INFO pane data again and am posting the full details here as it appears there are also other odd looking numbers which may be related to suspected bugs of Imgburn 2.58 handling triple layer media. I've compared it to a BD-RE-DL and I noticed that the DISC INFO section's percentage value is the percentage of the entire disc and not just the layer in question, so presumably it should read around 33.33% for all 3 layers if I understand its intention correctly? Also, under the DISC DEFINITION STRUCTURE section, shouldn't CLUSTORS be spelt CLUSTERS instead?

 

 

Current Profile: BD-RE

 

Disc Information:

Status: Complete

State of Last Session: Complete

Erasable: Yes

Sessions: 1

Sectors: 47,305,728

Size: 96,882,130,944 bytes

Time: 10512:25:03 (MM:SS:FF)

MID: SONY-ET2-002

Supported Write Speeds: 2x

 

TOC Information:

Session 1... (LBA: 0)

-> Track 01  (Mode 1, LBA: 0 - 47305727)

-> LeadOut  (LBA: 47305728)

 

Disc Definition Structure:

ISA0 Size: 8,192 clustors - Full: No

OSA0 Size: 8,192 clustors - Full: No

ISA1 Size: 8,192 clustors - Full: No

OSA1 Size: 8,192 clustors - Full: No

Certified: No

Scanned: No

 

BD Disc Information (L0):

Disc ID: SONY-ET2-002

Disc Type: BD-RE

Disc Size: 120 mm

Disc Class: 1

Disc Version: 3

Number of Layers: 3

Layer Type: Rewritable

DVD Layer Present: No

CD Layer Present: No

Channel Bit Length: 55.87 nm (33 GB Per Layer)

BCA Present: Yes

Maximum Transfer Rate: Not Specified

First PAA of Data Zone: 554,925,568

Last PAA of Data Zone: 48,402,576

 

BD Disc Information (L1):

Disc ID: SONY-ET2-002

Disc Type: BD-RE

Disc Size: 120 mm

Disc Class: 1

Disc Version: 3

Number of Layers: 3

Layer Type: Rewritable

DVD Layer Present: No

CD Layer Present: No

Channel Bit Length: 55.87 nm (33 GB Per Layer)

BCA Present: Yes

Maximum Transfer Rate: Not Specified

First PAA of Data Zone: 2,113,928,704

Last PAA of Data Zone: 48,402,576

 

BD Disc Information (L2):

Disc ID: SONY-ET2-002

Disc Type: BD-RE

Disc Size: 120 mm

Disc Class: 1

Disc Version: 3

Number of Layers: 3

Layer Type: Rewritable

DVD Layer Present: No

CD Layer Present: No

Channel Bit Length: 55.87 nm (33 GB Per Layer)

BCA Present: Yes

Maximum Transfer Rate: Not Specified

First PAA of Data Zone: 2,702,409,216

Last PAA of Data Zone: 48,391,268

 

Layer Information:

Layer 0 Sectors: 242,783,376 (513.2%)

Layer 1 Sectors: 655,660,176 (1386%)

Layer 2 Sectors: 3,443,829,472 (7280%)

 

Format Capacities:

DT: 0x02 - NB: 47305728 (0x02D1D400) - TDP: 49152

FT: 0x00 - NB: 47305728 (0x02D1D400) - TDP: 49152

FT: 0x30 - NB: 47305728 (0x02D1D400) - TDP: 49152

FT: 0x30 - NB: 46781440 (0x02C9D400) - TDP: 65536

FT: 0x30 - NB: 48854016 (0x02E97400) - TDP: 768

FT: 0x31 - NB: 48878592 (0x02E9D400) - TDP: 2048

 

Performance (Write Speed):

Descriptor 1...

-> B0: 0x00, B1: 0x00, B2: 0x00, B3: 0x00

-> EL: 47305727 (0x02D1D3FF)

-> RS: 8,990 KB/s (2x) - WS: 8,990 KB/s (2x)

 

[LIGHTNING UK!]

I assume you're talking about the PAA numbers?

 

They're a straight dump of what's recorded in those bytes within the DI Unit.

 

The 'Layer Information' is calculated from those values, but because they don't remotely match up with what's recorded for SL/DL media (and I only have the specs for those), it's garbage.

 

There will be no fix for that until I can find out the specs of the DI Unit used on the TL/QL BD-XL media. I've been unable to get anything back from a Google search.

 

Don't worry though, they aren't something the software has to use.

 

Yes, clustor(s) should of course be cluster(s). I've corrected the 2 instances where it was spelt incorrectly.

[discuser]

I assume you're talking about the PAA numbers? They're a straight dump of what's recorded in those bytes within the DI Unit.

 

The 'Layer Information' is calculated from those values, but because they don't remotely match up with what's recorded for SL/DL media (and I only have the specs for those), it's garbage. There will be no fix for that until I can find out the specs of the DI Unit used on the TL/QL BD-XL media. I've been unable to get anything back from a Google search. Don't worry though, they aren't something the software has to use. Yes, clustor(s) should of course be cluster(s). I've corrected the 2 instances where it was spelt incorrectly.

Yes, I was referring to the odd looking PAA values. But as long as they don't affect the actual disc formatting / defect management and user data writing / verification, I won't worry too much about it. Just thought I would point it out in case it would help you uncover a few more possible bugs if so.

 

About the spare sectors reservation / allocation (if that option is set to make spare sectors so available):

 

1. Is that part of the original BD-R/RE spec or it is something allocated through some sort of determination by Imgburn?

 

2. What percentage or capacity of an entire BD-RE disc is allocated to spare sectors and if so, is the logical capacity of the spare sectors indicated anywhere in the disc information that Imgburn displays in the DEVICE pane?

 

3. Are spare sectors allocated separately for each individual LAYER on a multi-layer disc (DL/TL/QL), i.e. each layer has its own individual spare sector area, or is the spare sector area reserved in a single area that might depend entirely on the integrity of the particular disc layer it resides on? (Or perhaps this is dictated by BD specs) Some removeable media can be checked for remaining available spare sectors / clusters reported either in capacity / clusters / sectors or in percentage of remaining spare area. I'm not sure if BD-R/RE media (formatted by Imgburn) can be checked that way or reported by any ODD software.

 

 

Interestingly, a fully formatted BDXL-RE-TL disc, when loaded into the Pioneer 09-series ODD, was actually correctly detected in capacity by an older version of Nero which was released well before triple and quad layer BD media specs was announced or designed. Perhaps the ODD is simply reporting logical capacity. But I haven't tried writing to triple layer media with that older version of Nero to see if it does it successfully, and don't see the need to test that at this time.

 

[LIGHTNING UK!]

The size of the spare area gets set when you issue the format command... and the available sizes come from what's reported in the 'Format Capacities' section of the disc info.

 

So basically, you query the drive to get a list of sizes and then pick from the list.

 

Looking at the info posted above, you've got 3 options.

 

FT: 0x30 - NB: 47305728 (0x02D1D400) - TDP: 49152

FT: 0x30 - NB: 46781440 (0x02C9D400) - TDP: 65536

FT: 0x30 - NB: 48854016 (0x02E97400) - TDP: 768

So your disc is left with 46781440, 47305728 or 48854016 usable sectors. The size of the spare area of course decreases as usable sectors increases.

 

Your disc is currently formatted with the middle one and would be considered the 'normal' one to go for if you want spare areas.

 

Sectors: 47,305,728

You can expand the spare area region(s), but that's not something ImgBurn allows for.

 

The ISA / OSA values in the 'Disc Definition Structure' are to do with spare areas. They correspond to the number of clusters that have been allocated for spare areas in those regions.

 

8192 clusters = 8192 * 32 sectors = 8192 * 32 * 2048 = 536,870,912 bytes = 512 MiB

 

Spare areas are per layer. There's an inner area and an outer area, per layer. (Hence ISA and OSA. The user data sectors are in the middle)

 

I expect there would also be a value available for ISA2, ISA3 etc on your TL/QL discs, but again, that's not covered by the specs I have.

 

I cannot tell you how much of each has been used, there's only a flag set when it's full. This is already displayed.

 

Yes, ODD software works at quite a high level really. Larger disc sizes etc shouldn't cause much of an issue, if any issue at all. It's only a problem when the format of a certain structure changes that you'll come unstuck. Luckily, that would mainly cause cosmetic issues.

 

You issue a 'READ CAPACITY' command to the drive and it returns the size. It's as simple as that.

[discuser]

Thanks. Very useful information to understand the spare sector areas. So if I understand your calculation correctly, the minimum allocation unit which is one cluster, consumes 64 KiB (i.e. 32 sectors * 2048 bytes per sector) on the optical disc. If so, I can see how a large number of small files (each 64 KiB or smaller) can quickly hog large amounts of disc space.

Based on your explanation, it seems that the allocation to each of the inner and outer spare areas is 0.5 GB and therefore the total allocation is 1 GB per layer (and is the available disc space per layer that would have been gained had spare sectors been disabled via Imgburn WRITE options), though as you say, spare area information isn't displayed beyond the second layer (Layer-1) in the DEVICE pane details of Imgburn. But - in fact, these spare area allocations are still occuring during erasure-format for Layer-2 (third layer) and higher, yes?

It's safer to have spare sectors available for each individual layer since in some cases an entire layer may be unuseable / inaccessible due to various physical reasons such as manufacturing defects. So I'm glad to hear that spare areas are a per-layer arrangement. There's a lot of data on a multi-layered disc and it gives me a feel of how much protection against relatively minor disc defects the user gets as I start moving into higher BD capacities.

As far as I'm aware, BDXL-QL media isn't really currently available standalone and I'm not aware of any current BD-XL drive's media ROM-table support BDXL-QL media. The only way I'm aware that one could obtain BDXL-R-QL discs is to disassemble a Sony archival disc cartridge which internally houses a stack of write-once discs. But even then, I'm not sure how even a premium grade BDXL drive like a Pioneer would handle QL discs. I don't expect BDXL-RE media to be available beyond triple layer. It seems that BD-RE technology will pretty much be limited to 2X speed (which in BD data rates is transferring at a decent speed nearly 9 MB per second) and triple layer capacity.
 

 

The ISA / OSA values in the 'Disc Definition Structure' are to do with spare areas. They correspond to the number of clusters that have been allocated for spare areas in those regions.

8192 clusters = 8192 * 32 sectors = 8192 * 32 * 2048 = 536,870,912 bytes = 512 MiB

Spare areas are per layer. There's an inner area and an outer area, per layer. (Hence ISA and OSA. The user data sectors are in the middle)

I expect there would also be a value available for ISA2, ISA3 etc on your TL/QL discs, but again, that's not covered by the specs I have.

[dbminter]

Yeah, the optical disc market is pretty much dying.  So, I also doubt we'll ever see a development of BD-RE discs so they write faster than 2x.  It's been like 10 years since the introduction of recordable BD, and we're still only at 2x for BD-RE.  But, it does beat 1x. 

 

 

Man, I can remember the days of DVD writing at 1x back in 2002.  You'd spend 59 minutes of your 1 hour write time, only to get a buffer underrun error at the very end and lose all that time and a disc.  Buffer underrun protection was one of the best technologies ever put into optical burners.

[LIGHTNING UK!]

I found a TL disc and managed to figure out the format of the newer DI Unit used on BD-XL media, so the first and last PAA values / layer stuff should be ok now.

 

PIONEER BD-RW   BDR-209M 1.50 (ATAPI)
Current Profile: BD-RE

Disc Information:
Status: Complete
State of Last Session: Complete
Erasable: Yes
Sessions: 1
Sectors: 47,305,728
Size: 96,882,130,944 bytes
Time: 10512:25:03 (MM:SS:FF)
MID: PAN-EC2-001
Supported Write Speeds: 2x

TOC Information:
Session 1... (LBA: 0)
-> Track 01  (Mode 1, LBA: 0 - 47305727)
-> LeadOut  (LBA: 47305728)

Disc Definition Structure:
ISA0 Size: 8,192 clusters - Full: No
OSA0 Size: 8,192 clusters - Full: No
ISA1 Size: 8,192 clusters - Full: No
OSA1 Size: 8,192 clusters - Full: No
Certified: No
Scanned: No

BD Disc Information (L0):
DI Format Number: 5
Disc ID: PAN-EC2-001
Disc Type: BD-RE
Disc Size: 120 mm
Disc Class: 1
Disc Version: 3
Disc Time Stamp: 06/2010
Number of Layers: 3
Layer Type: Rewritable
DVD Layer Present: No
CD Layer Present: No
Channel Bit Length: 55.87 nm (33 GB Per Layer)
BCA Present: Yes
Maximum Transfer Rate: Not Specified
First PAA of Data Zone: 131,072 (0x00020000)
Last PAA of Data Zone: 2,167,678 (0x0021137E)

BD Disc Information (L1):
DI Format Number: 5
Disc ID: PAN-EC2-001
Disc Type: BD-RE
Disc Size: 120 mm
Disc Class: 1
Disc Version: 3
Disc Time Stamp: 06/2010
Number of Layers: 3
Layer Type: Rewritable
DVD Layer Present: No
CD Layer Present: No
Channel Bit Length: 55.87 nm (33 GB Per Layer)
BCA Present: Yes
Maximum Transfer Rate: Not Specified
First PAA of Data Zone: 6,220,928 (0x005EEC80)
Last PAA of Data Zone: 8,257,534 (0x007DFFFE)

BD Disc Information (L2):
DI Format Number: 5
Disc ID: PAN-EC2-001
Disc Type: BD-RE
Disc Size: 120 mm
Disc Class: 1
Disc Version: 3
Disc Time Stamp: 06/2010
Number of Layers: 3
Layer Type: Rewritable
DVD Layer Present: No
CD Layer Present: No
Channel Bit Length: 55.87 nm (33 GB Per Layer)
BCA Present: Yes
Maximum Transfer Rate: Not Specified
First PAA of Data Zone: 8,519,680 (0x00820000)
Last PAA of Data Zone: 10,556,286 (0x00A1137E)

Layer Information:
Layer 0 Sectors: 16,292,864 (34.44%)
Layer 1 Sectors: 16,292,864 (34.44%)
Layer 2 Sectors: 14,720,000 (31.12%)

Format Capacities:
DT: 0x02 - NB: 47305728 (0x02D1D400) - TDP: 49152
FT: 0x00 - NB: 47305728 (0x02D1D400) - TDP: 49152
FT: 0x30 - NB: 47305728 (0x02D1D400) - TDP: 49152
FT: 0x30 - NB: 46781440 (0x02C9D400) - TDP: 65536
FT: 0x30 - NB: 48854016 (0x02E97400) - TDP: 768
FT: 0x31 - NB: 48878592 (0x02E9D400) - TDP: 2048

Performance (Write Speed):
Descriptor 1...
-> B0: 0x00, B1: 0x00, B2: 0x00, B3: 0x00
-> EL: 47305727 (0x02D1D3FF)
-> RS: 8,990 KB/s (2x) - WS: 8,990 KB/s (2x)

[discuser]

Yeah, the optical disc market is pretty much dying.  So, I also doubt we'll ever see a development of BD-RE discs so they write faster than 2x.  It's been like 10 years since the introduction of recordable BD, and we're still only at 2x for BD-RE.  But, it does beat 1x. 

 

 

Man, I can remember the days of DVD writing at 1x back in 2002.  You'd spend 59 minutes of your 1 hour write time, only to get a buffer underrun error at the very end and lose all that time and a disc.  Buffer underrun protection was one of the best technologies ever put into optical burners.

 

Yes, but I think that people focus on the SPEED MULTIPLE value too much. BD at 2X or DVD at 4X doesn't sound like much, until you look further into the actual data transfer rate. For example, CD at 52X read/write speed is about 7.8 MB/sec but BD at 2X is about 8.5 MB/sec (due to the much higher native (1X) data rate of the BD format), about similar to DVD at 4X speed which I recall is also around 8 to 9 MB per second or thereabouts. So most users / consumers looking at the multiple value will get a deceiving value of the actual data transfer rate. I'm more concerned with actual data transfer rate, because that tells me how quickly I'm writing data to the media and how long that could take to write and verify, and also how much demand it places on the hard disc head-seek / thrashing while I might be doing other low demand tasks on the computer during ODD writing that could potentially cause a drop in both the ODD software or the ODD's write-buffer level.

 

So I think BD-RE at 2X is tolerable. Not great, but tolerable. I wouldn't mind BD-RE at 4X but even at 2X it is tolerable to use triple layer media during an overnight format with verify, or write with verify job.

 

If I'm not in a rush, I still prefer to write to quality CD-R media at 4X though I have gone as high as 16X with quality CD-R media and have found no real increase in C1 and C2 error rates. CD-RW was basically stuck at 4X write speed until CD-RW-High-Speed media was launched, but CD at 4X took about 15 minutes of write time. Same thing for DVD at 4X, though verification for CD and DVD will usually read much faster than 4X so verification read time is somewhat reduced.

 

As for optical discs being disused, the relatively new M-Disc development ensures that there's no other medium including flash drives, SSD and hard discs could possibly come close to the archival life of the newer BD-M-Discs. The great thing about optical discs is that there are no electronics it it whatsoever, which is the whole point of increasing data safety and archival life. All other alternative storage formats, other than tape cartridge (a more fragile medium) involves on-board electronics with the medium.

 

[discuser]

I found a TL disc and managed to figure out the format of the newer DI Unit used on BD-XL media, so the first and last PAA values / layer stuff should be ok now.

Thanks, that's great to hear and I look forward to the updated Imgburn release following the current 2.58, whenever that is slated to be. In the disc information you posted for the Panasonic BDXL-RE-TL disc, a few other points I noticed:

 

1. The DISC DEFINITION STRUCTURE section seems to list only layer 0 and 1 for ISA and OSA only. So would this list be expanded in the newer Imgburn version to include layers beyond layer-1?

 

ISA0 Size: 8,192 clusters - Full: No

OSA0 Size: 8,192 clusters - Full: No

ISA1 Size: 8,192 clusters - Full: No

OSA1 Size: 8,192 clusters - Full: No

 

 

2. A rather huge value gap between the Layer-0 LAST PAA value and the Layer-1 FIRST PAA value. This gap is much larger than the value gap between Layer-1 LAST PAA and Layer-2 FIRST PAA.

 

3. Why is the layer-2 sector count lower than layers 0 and 1? Would that be due to reserved sectors or other system-use sectors allocation?

 

Layer 0 Sectors: 16,292,864 (34.44%)

Layer 1 Sectors: 16,292,864 (34.44%)

Layer 2 Sectors: 14,720,000 (31.12%)

 

Edited April 13, 2018 by discuser

[LIGHTNING UK!]

1. Only if I can find the right info on the BD-XL format discs. I looked at what the drive returns for the Disc Definition Structure when a BD-XL disc is present and nothing jumped out at me as being values for ISA2/OSA2.

 

2. That must just be due to how the discs are designed and manufactured.

 

3. As above.

[discuser]

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.
 

[LIGHTNING UK!]

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.

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

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 May 18, 2018 by discuser

[LIGHTNING UK!]

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.

[dbminter]

 

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?

[discuser]

 

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.

[discuser]

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 May 22, 2018 by discuser

[LIGHTNING UK!]

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.

[discuser]

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.

[LIGHTNING UK!]

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.