Weird max spikes on bd-r scans?

vbimport

#1

Hear ye, hear ye!

I have now burned 3 Platinum-branded BD-R discs (RITEK BR3) [they were supposed to probably be CMCMAGBA5…]

Scans are below. Can’t use ODC - “Drive does not support this function” and Kprobe segfaults on bd-r discs… (OT: Qpxtool forum has some progress about adding bd support… Can’t wait)

First one I think it’s fine. IMO surprisingly good for the price. Second and third disc are the weird ones. Otherwise good, but there’s one spike that maxes out the LDC/BIS values. 9728/768.

TRT curve has a very slight dip on the positions of the spikes. Rescanned multiple times and the huge spike stays there.

All the discs are burned with Liteon iHBS-112 (fw PL01) using cdrskin (defect management on - default setting).

Are the spikes something to be very worried about? Can the defect management system have something to do with it? How does the defect management even work? Anyone have similar scans?


#2

Hi,

thanks for flying cdrskin. :slight_smile:

> Can the defect management system have something to do with it?
> How does the defect management even work?

If you did not format the BD-R before using it with cdrskin, then
it will not have used Defect Management.

You typically recognize it at burn time by only getting half the
nominal speed. It checkreads the written data as long as they
are still in the drive buffer. In case of error or poor quality
it will normal retry the write operation. As last resort it will
employ a replacement block from the Spare Area.
Such replacements cause a long head move at read time.
If many of them exist, the drive will clonk and moan. Not nice.

To my experience, BD works better without Defect Management.
If the medium needs it, then it will become quite unbearable
anyway. And i suspect that media fail even earlier than with
plain old writing.

BD-R can be formatted only while they are blank. E.g. by:

cdrskin -v dev=/dev/sr0 blank=format_if_needed

You can determine whether a BD-R is already formatted by:

cdrskin dev=/dev/sr0 --list_formats

Formatted ones will report a BD Spare Area:

BD Spare Area: 0 blocks consumed, 196608 blocks available

Unformatted BD-R will not show this info.

It is possible to format BD-RE to 0-sized Spare Area by choosing
the largest format that gets offered by --list_formats.

Formatted BD media can be forced to avoid Defect management
by drskin option stream_recording=on

> Anyone have similar scans?

I recently tested whether qpxtool plugin “liteon” can handle my BD-5300S
(and a user’s iHS112). It works roughly but needs solid work by a skilled
qpxtool developer.

I noticed that the final test samples of my drive always have “PIE” values
over 9700 and “PIF” value of 768. When forcing those last samples to 0,0
i got maximum values of LDC and BIS errors in the range that can be seen
on screenshots of Opti Drive Control.

This was with BD-R media. With BD-RE i saw many intermediate spikes of
"PIE"/LDC > 5000. Regrettably i do not know the theoretical maximum
for LDC and BIS. So i cannot tell whether these are real error
numbers or whether some of the numbers’ high bits are flags which
indicate a particular condition.

Have a nice day :slight_smile:

Thomas


#3

[QUOTE=scdbackup;2664255]Hi,

thanks for flying cdrskin. :slight_smile:

> Can the defect management system have something to do with it?
> How does the defect management even work?

If you did not format the BD-R before using it with cdrskin, then
it will not have used Defect Management.

You typically recognize it at burn time by only getting half the
nominal speed. It checkreads the written data as long as they
are still in the drive buffer. In case of error or poor quality
it will normal retry the write operation. As last resort it will
employ a replacement block from the Spare Area.
Such replacements cause a long head move at read time.
If many of them exist, the drive will clonk and moan. Not nice.

To my experience, BD works better without Defect Management.
If the medium needs it, then it will become quite unbearable
anyway. And i suspect that media fail even earlier than with
plain old writing.

BD-R can be formatted only while they are blank. E.g. by:

cdrskin -v dev=/dev/sr0 blank=format_if_needed

[/QUOTE]

The BD-R:s were blank, and formatted before recording (cdrskin -v blank=format_defectmgt stream_recording=off dev=/dev/sr2 XYZ.iso)

All the discs show (dvd+rw-mediainfo /dev/sr2) that some of the spare areas are in use

“BD SPARE AREA INFORMATION:
Spare Area: 291328/393216=74.1% free”

All the 3 discs have something like 70-80% free spare areas, so that can’t be the culprit for the maxed out spike?

[QUOTE=scdbackup;2664255]
I recently tested whether qpxtool plugin “liteon” can handle my BD-5300S
(and a user’s iHS112). It works roughly but needs solid work by a skilled
qpxtool developer.

I noticed that the final test samples of my drive always have “PIE” values
over 9700 and “PIF” value of 768. When forcing those last samples to 0,0
i got maximum values of LDC and BIS errors in the range that can be seen
on screenshots of Opti Drive Control.

This was with BD-R media. With BD-RE i saw many intermediate spikes of
"PIE"/LDC > 5000. Regrettably i do not know the theoretical maximum
for LDC and BIS. So i cannot tell whether these are real error
numbers or whether some of the numbers’ high bits are flags which
indicate a particular condition.

Have a nice day :slight_smile:

Thomas
[/QUOTE]

Just hope that the qpxtool devs will rise to occasion… the latest version is over two years old.


#4

Hi,

> All the 3 discs have something like 70-80% free spare areas,
> so that can’t be the culprit for the maxed out spike?

Might well be. I suspect that the reply from vendor-specific
SCSI command F3 contains more information with BD-R than it
does with DVD. Since that would sit in the same 4-byte words,
an unaware program would misinterpret it as part of the error
count number. 9728 is 0x2600 in hex. Any theories anybody ?

Or maybe that sample contains no error number at all.
But why then is the returned block address larger than the one
of the previous test sample ? Riddles, riddles …

Problem is that i only got some unrelated NEC specs (thanks Liggy).
They mention the same command F3 but with other further bytes.
cdrskin (actually libburn) restricts itself to commands which are
specified by the published SCSI standard in its parts SPC, SBC,
and MMC.

> Just hope that the qpxtool devs will rise to occasion…

I share this hope. It is an interesting project to cooperate with.
The borderline between libburn and qpxtool is clear and natural
(although i saw in qpxtools CD SAO burning which i claim for my
own realm :)).

Have a nice day :slight_smile:

Thomas


#5

Hi,

> All the 3 discs have something like 70-80% free spare areas,

I forgot to answer to your original question in the light
of this information:

A lot of consumed blocks in the Spare Area of the BD are of
course a sign of quality problems with the combination of
drive and medium.
Better do not buy these media again unless you can identify
the drive as culprit by doing poorly on other media products
too. (My Riteks usually die around session number 300.
Others went unreadable during a year on the shelf.
Sony 2x did best in my qscan runs and when i burned to them
once per day during nearly a year.)

If you still have blanks of those, then you can now get an own
impression of the value of Defect Management.
Burn your next BD unformatted and check it afterwards.
Do the spikes appear ? (I got the final one with both states.
But did not notice intermediate ones in the number flood.)

Have a nice day :slight_smile:

Thomas


#6

[QUOTE=Mastus;2664225]Hear ye, hear ye!

I have now burned 3 Platinum-branded BD-R discs (RITEK BR3) [they were supposed to probably be CMCMAGBA5…]

Scans are below. Can’t use ODC - “Drive does not support this function” and Kprobe segfaults on bd-r discs… (OT: Qpxtool forum has some progress about adding bd support… Can’t wait)

First one I think it’s fine. IMO surprisingly good for the price. Second and third disc are the weird ones. Otherwise good, but there’s one spike that maxes out the LDC/BIS values. 9728/768.

TRT curve has a very slight dip on the positions of the spikes. Rescanned multiple times and the huge spike stays there.

All the discs are burned with Liteon iHBS-112 (fw PL01) using cdrskin (defect management on - default setting).

Are the spikes something to be very worried about? Can the defect management system have something to do with it? How does the defect management even work? Anyone have similar scans?[/QUOTE]
Since the TRT shows that those error spikes are real, I would be worried about those burns degrading to unreadable sooner than those of a smooth burn. I am interested to see your results without format and defect management. It is unfortunate that you ended up with notoriously variable Riteks. If you look for a BD-R that has been proven to yield higher quality results with that 112, Panasonic 4x should be a good choice.

@scdbackup: Thank you very much for your support and ongoing efforts to bring BD-R scanning to this platform :flower:


#7

Hi,

> @scdbackup: Thank you very much for your support and ongoing
> efforts to bring BD-R scanning to this platform

Thanks for your kind words. :slight_smile:

But i have to emphasize that i do not plan to work on qpxtools
myself. I am optimistic to understand its aspects related to SPC
and MMC. But there is still the unknown field of vendor-specific
drive commands, for which i have no specs. Not to forget the Qt
aspects, and the need to grok the overall program architecture.

I could at best be annoying to ShultZ, who seems to be in charge
there. In worst case i would make a fool of myself by frying
somebody’s drive.

Nevertheless i can offer my advise about what i know and my
BD-5300 for testing without GUI. As long as we stay with the
commands used by the current liteon plugin, the drive seems to
be out of danger.

Have a nice day :slight_smile:

Thomas


#8

OK, here goes.

This time with the defect management off.
(cdrskin -v blank=format_defectmgt_cert_off stream_recording=on dev=/dev/sr2 ABC.iso)

Result is not too bad (I think), hope they won’t degrade in a blink of an eye…

One odd thing, dvd+rw-mediainfo /dev/sr2 shows this:
“BD SPARE AREA INFORMATION:
Spare Area: 294912/393216=75.0% free”

The disk was in blank state before burning.



#9

Hi,

> cdrskin -v blank=format_defectmgt_cert_off stream_recording=on
> dev=/dev/sr2 ABC.iso
> Spare Area: 294912/393216=75.0% free"

Well, you did format it by blank=format_defectmgt_cert_off which
causes an abbreviated formatting procedure. So it is plausible
that there is a Spare Area.
I meant to omit any blank=… option when writing to a blank BD-R.
This would leave it unformatted and would add the 400 MB of
Spare Area to the normal payload capacity.

But you disabled the checkreading for the burn run by
stream_recording=on. So it is not plausible that 25% of the
Spare Area should be consumed.
How was burning speed ? Did it vary (as would be typical for
activated Defect Management) ?
What do you get from
cdrskin dev=/dev/sr2 --list_formats

Have a nice day :slight_smile:

Thomas


#10

[QUOTE=scdbackup;2664500]Hi,

> cdrskin -v blank=format_defectmgt_cert_off stream_recording=on
> dev=/dev/sr2 ABC.iso
> Spare Area: 294912/393216=75.0% free"

Well, you did format it by blank=format_defectmgt_cert_off which
causes an abbreviated formatting procedure. So it is plausible
that there is a Spare Area.
I meant to omit any blank=… option when writing to a blank BD-R.
This would leave it unformatted and would add the 400 MB of
Spare Area to the normal payload capacity.

But you disabled the checkreading for the burn run by
stream_recording=on. So it is not plausible that 25% of the
Spare Area should be consumed.
How was burning speed ? Did it vary (as would be typical for
activated Defect Management) ?
What do you get from
cdrskin dev=/dev/sr2 --list_formats

Have a nice day :slight_smile:

Thomas[/QUOTE]

Yes, the burning speed varied. I reckon that the defect management was in effect after all.

But this time no weird spikes. This may be a media related problem?

I’ll try to burn another disc in few days, let’s see what happens then.
And btw, thank you very very much for your program and your helpful input about this matter. :bow:


#11

OK.

And this time no formatting or defect management
(cdrskin -v stream_recording=on speed=0 dev=/dev/sr2 XYZ.iso)

Burning was almost twice as fast, completing in about 20 minutes (~4x). dvd+rw-mediainfo shows no spare areas. And result is OK (me thinks) for a RitekBR3.



#12

Hi,

this graph looks as good as the very first one.
One will have to gain more experience before one can judge
whether the result indicates good media.

If the spiking is a media quality problem, then a very varying one.

Well, it would be nice if you could use unformatted BD-R
for the next few tries, check them, and report if anything
remarkable happens.
(E.g. spikes again, or even a real read error …)

Have a nice day :slight_smile:

Thomas