PDA

View Full Version : Burning DL media with PgcEdit


Pages : 1 [2]

r0lZ
3rd July 2005, 13:06
About this, I think it may not be the problem of -R technology, but the defect of drive or burning-software because of the early stage step.
Actually RecordNow4.0 was not be able to burn DVD-Video files appropriately in the case that order of titles isn't order of VTS. (I can't explain well, it means that title1(in VTS_02),title2(in_VTS_01).)
This bug was fixed version 4.61.If it's the case, I don't think it's my job to provide a workaround. Just use a good burning software (DVD Decrypter) and a good drive, or update the firmware.

Also, I see in your table above that the hardware used for the tests are Pioneer drives. I don't like these drives. I have had many problems with an old DVD reader, and with a Pioneer writer as well. But I haven't tried to burn DL DVDs with a Pioneer drive yet.

Note that the order of the Titles in the titlesets doesn't matter if you burn an ISO. RecordNow doesn't need to know what is on the ISO. It must just burn the ISO and place the layer break where requested. So, I suppose the tests are done with a totally different method.

r0lZ
3rd July 2005, 13:08
@jinjin_jp
Please don't post things from hearing and rumors! :devil:

Things are complicated enough. Why you don't test yourself with PgcEdit?
Trust PgcEdit. Test Dual Layer -R without manipulating and you will see.

I repeat again: There are no new problems.
There are many professions which published reports about dual layer DVD-R technics on the web. I have posted the links above.I agree, but I really want to go to the bottom of this problem. Maybe there is something we don't understand somewhere, although I don't think so.

frank
3rd July 2005, 13:24
@Tobii
DVDD shows you some layer information in ISO Read Mode. Please post it.

There is only Verbatims's DL DVD-R with 4171712 sectors we know.
The Layer Break then should be <= 2085856

But the capacity is ok, standard says min. 4150400 sectors = 8.5 billion byte.

Maybe drives cannot handle the new Book Type properly. Standard is not published. Not new...

frank
3rd July 2005, 13:51
@rOlZ
Here some bugfixes to the DL burn section.

The PgcEdit: Burn DVD window shows in Compilation - Used size a wrong value. It differs from total sector size in DL Layer dialog.
Bugfix in write.tcl / proc DVD_sectors, line 686
incr sectorsize 6 ;# room for VIDEO_TS and AUDIO_TS directory entries
incr sectorsize [llength [glob -tails -directory "$::dvddir" "V*TS*"]] ;# room for file entries
incr sectorsize 266 ;# room for DVD and filesystem headersThe total number of sectors calculated by PgcEdit is +1 greater than burned. With IsoBuster you can check it too.
Bugfix in burn.tcl / proc burn, line 800:
# Compute total ISO size, and valid range for Layer Break
set ::burn::isototalsize [expr $dvdvideostart+$videosectorsize+$dvdromsecs] # +1 deleted

jinjin_jp
3rd July 2005, 14:20
@jinjin_jp
Please don't post things from hearing and rumors! :devil:
Things are complicated enough. Why you don't test yourself with PgcEdit?
Trust PgcEdit. Test Dual Layer -R without manipulating and you will see.

OK. I stop to post about DL burning, because it seems to be rather prohibited to post things exept for what I test and see by myself. Sorry to know about this forum because I started to post about three weeks ago.
But please forgive to post about the thing r01Z said(the test of 2 x 2,092,896 sectors). I will make it the last post about DL burning.
And I'd like to be understood that I don't posted things which I easily just found or hear or rumor,I've been known the person each other from long before, and communicated the information for details as much as possible.
Thanks.

blutach
3rd July 2005, 15:38
Speaking personally, I would hope we see plenty more of you jinjin_jp. Please do not be afraid to air your views and concerns.

Regards

r0lZ
3rd July 2005, 15:53
@rOlZ
Here some bugfixes to the DL burn section.

The PgcEdit: Burn DVD window shows in Compilation - Used size a wrong value. It differs from total sector size in DL Layer dialog.
Bugfix in write.tcl / proc DVD_sectors, line 686
incr sectorsize 6 ;# room for VIDEO_TS and AUDIO_TS directory entries
incr sectorsize [llength [glob -tails -directory "$::dvddir" "V*TS*"]] ;# room for file entries
incr sectorsize 266 ;# room for DVD and filesystem headersWell, the number of sectors shown in the topmost part of the Burn GUI is only an aproximation, because it is extremely difficult to compute it. Seems it depends of the number of DVD-ROM files and also of the length of the filenames of these files!
But I'm pretty sure the size of 417 sectors I add in the original code is correct. Do a test with a very small DVD, and search for DVDVIDEO-VMG. You will see that my computation is correct, at least in this simple case.
Anyway, when burning a DL disk, the correct size is not computed: a dummy burn is started, and the output of mkisofs is analyzed, until a DVDVIDEO-VMG string is found at the beginning of a sector. It may be a little difference between the two methods. But a difference of 151 sectors is very big. How did you computed the 266 used in your code?
Of course, I may be wrong. I will do some more tests...

The total number of sectors calculated by PgcEdit is +1 greater than burned. With IsoBuster you can check it too.
Bugfix in burn.tcl / proc burn, line 800:
# Compute total ISO size, and valid range for Layer Break
set ::burn::isototalsize [expr $dvdvideostart+$videosectorsize+$dvdromsecs] # +1 deletedNo, there is one padding, blank sector added by mkisofs at the end of the compilation. Remember: before removing the padding sectors with the -no-gap option, there were 257 padding sectors added. Now, with this option, the 256 sectors are removed, but there is still one. Look at the size of the ISO. IsoBuster lists only the last real sector, but don't count the padding sectors.

r0lZ
3rd July 2005, 16:06
Hum, no, seems you're right: the -no-pad option removes 150 padding sectors, not 256. But I forgot to change this number in my code: the original value of 417 must therefore be decreased by 150, giving 167, which is the correct value, including the remaining padding sector.

So, the bugfix is:incr sectorsize 267andset ::burn::isototalsize [expr $dvdvideostart+$videosectorsize+$dvdromsecs] +1 ;# was correct

(Also, note that if you put a comment at the end of a line of code, you MUST add a semicolon before the #. In Tcl, a comment is a command, and must be properly separated from the rest of the line. A string beginning with # is interpreted as a color code!)

r0lZ
3rd July 2005, 16:16
Speaking personally, I would hope we see plenty more of you jinjin_jp. Please do not be afraid to air your views and concerns.I agree. I'm not sure the method explained by jinjin_jp is correct, but there is obviously a real problem in some cases. I want to understand why the japaneses do that this way before assuming that my method is correct for -Rs. Unfortunately, it is still difficult to buy -Rs here, but seems they are already widely used in Japan (maybe because the -R technology has been developed in Japan.)

BTW, jinjin, is it possible to contact directly the author of the guide? Maybe if I can speak directly with him (in english), I will be able to understand better... If you can, please email me his email address.

Tobii
3rd July 2005, 16:28
BTW, have you already burned these DVDs with PgcEdit? What is the result?
OK, since you really want to know it..here the result, what isn't so bad.


Burned with NEC 3520, Standard Preset in PgcEdit used for DVD-R DL.
BTW, don't change the Preset for DVD-R DL.

DVD-Burner:
NEC 3520 - no problems
LG 4120B - don't recognize the disc

DVD-ROM:
AOPEN DVD 1648/AAP - need for a long time to read the disc, but then play it
LiteON HD166S - don't recognize the disc

DVD-Player:
Sony NS-DVP 900 - need for a long long time to read the disc, but then, play it without problems
Denon 3910 - no problems
My old Philips - Illegal disc :D

I make a scan of the DVD later, if my computer is ready with the re-encoding.
Despite the not so bad results, I stay with DVD+9 DL. Booktype DVD-ROM is more compatible. :cool:


r0lZ, there is the possibility adapting the guides for the final release?

r0lZ
3rd July 2005, 16:42
Thanks, Tobi.

When you said "no problems", can I assume that the player switched to the second layer without problem, or just that it can recognize the DVD?

Blutach did already a new guide on burning DL-DVDs with PgcEdit. I will add the links to it when I will release v0.6.0 final, probably thursday. If you want, you can already read it here (http://www.videohelp.com/~r0lZ/pgcedit/third_party/blutach/dl_burning_with_pgcedit.htm).

Tobii
3rd July 2005, 17:46
My Sony needs for a long time to read the disc and it is a long delay, if you switch on the second layer.
My Denon, has no problems with the disc. Read the disc without problems and switch over to the second layer without delay.

I can confirm only the results with this Verbatim. As far as I know, there are differences or great tolerances at the production.
I cannot burn the second -R DL, has a fault on the outer rings. :mad: I personally don't like the DVD-R DL (too unsafe).

Somebody can also burn a -R DL?



If you want, you can already read it here (http://www.videohelp.com/~r0lZ/pgcedit/third_party/blutach/dl_burning_with_pgcedit.htm)
No, I had already written one anyway and sent them.
I wanted to know only the day, when the final version appear.
Thursday is good, from the point of view of time I make it. :)

r0lZ
3rd July 2005, 18:32
@jinjin_jp: OK, I have uploaded beta 19 (http://www.videohelp.com/~r0lZ/pgcedit/beta/PgcEdit_winexe_0.6.0beta19.zip), which has an option to force the layer break to a specific sector number.
However, I have not added this option in the GUI. I may add this option later, but I still need to be sure it's needed, and I don't want to confuse the user.

For now, here is what you need to do:
1. Go to Burn Setup GUI, and Save the setups (with the new version of PgcEdit, of course). Quit PgcEdit. This will add a line in the burn.cfg file. You need to do that only once, to create the new line.
2. Edit the file "<your home>/Application data/PgcEdit/burn.cfg" with a text editor, and change the definition of the ::burn::layer_break_sector variable to the sector number you want to place the layer break at. For example:set ::burn::layer_break_sector 2092896
When this variable is set to 0, the standard method is used.

Note that there are no tests to ensure that the sector number is valid. If you set it to a sector number > DVD-R DL size / 2, or if it is not divisible by 16, you will certainly burn a coaster!

Also, I don't have much time to test. So, use it at your own risk. And, please, let me know if it is what you want. Thanks.

@frank: Don't worry. If this variable is not edited, the old method is not changed at all.
But I have fixed the size bug. :)

@Tobi: Thanks also to you. So, seems that the method works fine for a DL DVD-R. However, maybe in some case (like perhaps burning with a Pioneer) the layer break sector needs to be specified explicitely. Now, it's possible, although I am committed that it's not necessary.

frank
3rd July 2005, 19:06
@rOlZ
Seems I must analyze burned disk sectors on DVD.

@Tobii
What says DVDD to L0? Lass dir doch mal mit DVDDecrypter die Größe von L0 von der fertig gebrannten DVD-R anzeigen!
As I said, all things with PgcEdit are ok, there are only new problems with the Book Type and the new media.

blutach
3rd July 2005, 23:44
All I say is that beta 13 or so burned +Rs perfectly. If there are any changes in sector numbers made in the code, I do hope these alterations do not make coasters!

@frank - I can not understand German!

Regards

frank
4th July 2005, 09:01
Don't worry, there are no changes to the math. One bug is based on wrong display value and the second one calculates the totalisosize +1 than burned size. The new values are identical to the real burned data on dvd showing by ISObuster. Tested with new compiled sources.
But I must additionally do some testing with a disk sector editor, because rOlZ said, MKISOFS is appending one sector to the iso.

I asked Tobii to look at the L0 sector number after burning his dual layer DVD-R. It must be decreased as on DL DVD+Rs (to confirm the behaviour of DVD-R).

blutach :thanks: for the nice DL burning guide (http://www.videohelp.com/~r0lZ/pgcedit/third_party/blutach/dl_burning_with_pgcedit.htm). :D

frank
4th July 2005, 11:00
I have moved the informations in the Burn DL window. Note that the numbers of sectors to burn has been deleted. It is just the double of the L0 sectors and misleads the user.

http://img195.imageshack.us/img195/149/burndl3hs.jpg (http://www.imageshack.us)

Source code burn.tcl, line 926:
wm title $w2 "Burn Double Layer DVD: Select Layer Break"

# infos
frame $w2.f -borderwidth 2 -relief groove -padx 4 -pady 4
pack $w2.f -padx 4 -pady 4 -fill x
label $w2.f.l00 -text "Total number of sectors"
entry $w2.f.e01 -textvariable ::burn::isototalsize -state readonly \
-disabledforeground black -width 7 -justify right
label $w2.f.l02 -text "of maximum"
entry $w2.f.e03 -textvariable ::burn::dldisksize -state readonly \
-disabledforeground black -width 7 -justify right

frame $w2.f.pad1 -bd 1

label $w2.f.l10 -text "Layer Break must be between sector"
entry $w2.f.e11 -textvariable ::burn::lb_min -state readonly -disabledforeground black -width 7 -justify right
label $w2.f.l12 -text "and"
entry $w2.f.e13 -textvariable ::burn::lb_max -state readonly \
-disabledforeground black -width 7 -justify right
label $w2.f.l14 -text " optimal at"
entry $w2.f.e15 -textvariable ::burn::lb_opt -state readonly \
-disabledforeground black -width 7 -justify right


frame $w2.f.pad2 -bd 1

label $w2.f.l20 -text "Final position of Layer Break"
entry $w2.f.e21 -textvariable ::burn::l0sectors -state readonly -disabledforeground black -width 7 -justify right
label $w2.f.l22 -text "Offset in L0"
entry $w2.f.e23 -textvariable ::burn::absoffset -state readonly \
-disabledforeground black -width 7 -justify right

frame $w2.f.pad3 -bd 1

label $w2.f.l30 -text "ISO sectors to burn"
entry $w2.f.e31 -textvariable ::burn::isosize -state readonly \
-disabledforeground black -width 7 -justify right
grid $w2.f.l00 -row 0 -column 0 -sticky e
grid $w2.f.e01 -row 0 -column 1 -sticky ew
grid $w2.f.l02 -row 0 -column 2 -sticky e
grid $w2.f.e03 -row 0 -column 3 -sticky ew
grid $w2.f.pad1 -row 1 -column 0 -ipady 1
grid $w2.f.l10 -row 2 -column 0 -sticky e
grid $w2.f.e11 -row 2 -column 1 -sticky ew
grid $w2.f.l12 -row 2 -column 2 -sticky e
grid $w2.f.e13 -row 2 -column 3 -sticky ew
grid $w2.f.l14 -row 2 -column 4 -sticky e
grid $w2.f.e15 -row 2 -column 5 -sticky ew
grid $w2.f.pad2 -row 3 -column 0 -ipady 2
grid $w2.f.l20 -row 4 -column 0 -sticky e
grid $w2.f.e21 -row 4 -column 1 -sticky ew
grid $w2.f.l22 -row 4 -column 2 -sticky e
grid $w2.f.e23 -row 4 -column 3 -sticky ew
grid $w2.f.pad3 -row 5 -column 0 -ipady 1
grid $w2.f.l30 -row 6 -column 0 -sticky e
grid $w2.f.e31 -row 6 -column 1 -sticky ew

r0lZ
4th July 2005, 11:12
@rOlZ
I have compiled with my bugfix, made many tests and verified with a burned DVD, not only with ISO file. Believe me
incr sectorsize 266and
set ::burn::isototalsize [expr $dvdvideostart+$videosectorsize+$dvdromsecs]without the +1 are correct!
266 == $dvdvideostart is the lowest start sector of MKISOFS data. In every case (shure for Windows).
Remember, sector numbers count from 0. If no content then the iso header needs $dvdvideostart = 266 sectors => 0...265.
Regardless of what you do - the burned DVD+R has the size = isototalsize like in my bugfixed code. It is really minus 1 sector than you have calculated. And it works fine on all my players.
I disagree.

Test with a small DVD:
Used Size displayed by PgcEdit: 76403
Number of extens written (in mkisofs log): 76403
Size of ISO file (windows explorer): 160,569,344 bytes / 2048 = 76403 sectors.

Test with a DL DVD:
Used Size: 3717636
Total number os sectors in compilation: 3717636
Offset in L0: 352474
ISO Size: 4070110
Number of extens written: 4070110
Size of ISO file: 4070110
ISO Size - Offset = 4070110 - 352474 = 3717636 = Total number of sectors in compilation!

Everything is right with my current method.

It's true that the ISO size is actually one sector more than the number of sectors really used, because there is still one padding sector added by mkisofs at the end of the compilation. But since this sector is written to the disc by DVDD, it must be counted. Of course, as this sector is a dummy sector, it doesn't appear in the filesystem. So, if you analyze or extract the sectors of the burned DVD, it will be probably dropped.
But, imagine what will happend if I use your method, and the user selects a layer break exactly at the middle of the compilation: there will be one additional sector in L1, and therefore L0 will be < L1. That's not acceptable!
Anyway, it is safer to count one sector too much than one sector less.

Conclusion: I will not change the current computation.

r0lZ
4th July 2005, 11:25
I think the number of sectors to burn is a good information, since it is NOT equal to the number of sectors in the ISO file. It is right that it's just the number of sectors in L0 * 2 (ie, the layer break value * 2), so it is easy to compute, but it is still easier to read it!
And this number is the real number of sectors to be written to the DVD, with the padding sectors to ensure that L1 is the same size as L0, and may give a good idea of the time the burn operation will last.

Your way to display the total number of sectors in the ISO as the ISO sectors to burn is misleading, as it's not the number of sectors to burn really.

r0lZ
4th July 2005, 11:27
I asked Tobii to look at the L0 sector number after burning his dual layer DVD-R. It must be decreased as on DL DVD+Rs (to confirm the behaviour of DVD-R).What do you mean by "it must be decreased"?

frank
4th July 2005, 11:43
When you look at the empty DL media then DVDD in iso read mode shows the max sectors in L0.

After burning DL DVD the sector number of L0 (LB) is written into the information zone of the media (TOC). DVDD shows the Layer Information: Layer 0 sectors and Layer 1 sectors (move down the slider). Layer 0 sectors (LB) is set lower than maximum according to the Layer Break.

r0lZ
4th July 2005, 11:50
I have compiled with my bugfix, ...Note that since v0.6.0, you don't need to compile every time you want to test.
I have added some code to load 'plugins' at startup. In fact, the plugins are not really plugins. They are simply Tcl files placed in a 'plugins' sub-directory in the PgcEdit's install folder. The files with a .tcl extensions found in that directory are automatically sourced (in alphabetical order) after the main code is launched (and the DVD opened, if you use the Open DVD at startup option).
In Tcl, if you define twice the same procedure, the first one is dropped, and replaced by the new one. So, to debug something in, say, burn.tcl, you can simply copy the original burn.tcl file in the plugins directory, modify it, and launch PgcEdit.exe. Your modifications will be used.
Note that this trick doesn't work with all files, because in some cases, some initialization is done when the file is loaded, and an error will occur if you try to execute this code twice. But most of the time, this trick works.

I use also the 'plugins' directory to develop new code, without the need to include it in the executable.

In the future, I may also distribute some macros as plugins, to keep the main executable as small as possible.

As an example, you may be interested by this file (http://www.videohelp.com/~r0lZ/pgcedit/beta/debug.tcl), which adds some debugging options in the Plugins menu.
(Note that the Plugins menu is created automatically if at least one tcl file is found in the plugins directory, so that the plugin will be able to add entries to this menu, if needed.)

r0lZ
4th July 2005, 11:53
When you look at the empty DL media then DVDD in iso read mode shows the max sectors in L0.

After burning DL DVD the sector number of L0 (LB) is written into the information zone of the media. DVDD shows the Layer Information: Layer 0 sectors and Layer 1 sectors (move down the slider). Layer 0 sectors (LB) is set lower then maximum according to the Layer Break.Ah, OK, I understand. You mean that the number of sectors in L0 is less than the total size of L0 when the DVD has been burned. That's sure for +Rs, but still needs to be verified for -Rs. Right?

blutach
4th July 2005, 12:03
@frank - you're welcome. Just awaiting the release now then I will update the help files.

Regards

frank
4th July 2005, 12:03
@rOlZ
Be sure, I fully understood the problem with all consequences to LB. I only did not see that dummy data sector of MKISOFS. I never had problems with data (UDF + ISO) shown by ISObuster, anyway I will check it carefully with a disk editor.

Ah, OK, I understand. You mean that the number of sectors in L0 is less than the total size of L0 when the DVD has been burned. That's sure for +Rs, but still needs to be verified for -Rs. Right?Yes.
And I'm sure the -R must have the same behaviour, because they want to be compliant.

jinjin_jp
4th July 2005, 13:49
BTW, jinjin, is it possible to contact directly the author of the guide? Maybe if I can speak directly with him (in english), I will be able to understand better... If you can, please email me his email address.
OK. I will soon inform his email adress. His answear was possitively "Yes" when I asked.

Thanks for beta19. I confirmed it works as desired.
And about the test of 2 x 2,092,896 sectors, please wait for a while.

Speaking personally, I would hope we see plenty more of you jinjin_jp. Please do not be afraid to air your views and concerns.
Thanks very much for saying so. I 'd continue to post without changing,but considering advice from others.

frank
4th July 2005, 15:00
@rolz
Your way to display the total number of sectors in the ISO as the ISO sectors to burn is misleading, as it's not the number of sectors to burn really. :confused: We are in the burning section. I saw it from the view of burning program that doesn't care about system layout, only sector numbers count. The same sectors whose the LB layout has to track in account. To burn on DVD are the sectors from ISO file including all UDF/ISO stuff (write iso mode), isn't it?

r0lZ
4th July 2005, 15:30
Yes, but the burning program must continue to write data on L1 after the last sector of the ISO, to fill the layer upto the inner sector. This is required. Therefore, the number of sectors to write is two times the size of L0. This part of the job is probably done by DVDD when the status bar shows "Finalizing Disc..."

jinjin_jp
4th July 2005, 15:40
@r01Z

I received the result of the test of 2 x 2,092,896 sectors.
It is as follows,
<Preparing>
1.Prepare ISO file of which size is 4,185,792 sectors.
....(The method is create appropriate blank sectors between files by correcting several IFO descriptions)
<Result>
2.Message is shown like below
"There doesn't appear to be enough space on the disc to burn this image.
Image size : 4,185,792 Sectors
Disc size : 4,171,712 Sectors
Would you like to continue anyway? "
3.Click "Yes"
4.Error message "I/O Error!" is shown, so impossible to burn.

About this result, comparing the contents of post before,
(1)Maximum burning size of -R/DL is seems to be 4,171,712 Sectors. This value is the same as this post's (http://forum.doom9.org/showpost.php?p=674722&postcount=129).
(2)Nero seems to burn all Sectors even after the last file with dummy, like another post's (http://forum.doom9.org/showpost.php?p=679715&postcount=192). (But Nero has problem which LayerBreakPoint is among cell, not between cells.)

[The addition test]
Preparing ISO file of which size is 4,171,713 sectors, and tested.
The results was same as above.

r0lZ
4th July 2005, 16:11
Of course, if your DVD-R is 4,171,712 sectors long, you will not able to force the layer break at sector 2,092,896, since 2,092,896 * 2 = 4,185,792. The error message is normal.

In the table here (http://forum.doom9.org/showpost.php?p=679715&postcount=192), you said that L0 Sectors = 2,092,896. It is obviously impossible to burn such a disc on a -R with only 4,171,712 sectors.

So, I still don't understand from where this number comes from, and why you need to use it as the layer break position.

Anyway, thanks for the address of the author of the guide. I will ask him some explanations.

frank
4th July 2005, 17:28
@ rOlZ
...burning program must continue to write data on L1 after the last sector of the ISO, to fill the layer upto the inner sector. This is required. Therefore, the number of sectors to write is two times the size of L0.Yes, and No. Let me explain something. The Data Zone includes user data but not the Lead Out. The specs say:ECMA-364 section 16.1
In the moment of finalization not the full capacity of the disk has been used, the remainder of the Data Zone on Layer 1 is designated as Lead-out Zone.
For the host/application the Data Zone on Layer 0 and the Data Zone on Layer 1 shall be treated as one contiguous Data Zone.In other words: You never have to care about Lead-out, that's a background job of the burning program. Did you ever count the Lead-out sectors of a Data CD?? I think no. DVDD finalizes the DVD by writing Lead-out Zone automatically. There are optical/physical reasons. You cannot access to such physical sectors.
After burning you can look at DVDD Layer Information: Layer 0 sectors, Layer 1 sectors - here are user data sectors counted. That information is written into the TOC, a section of the Inner Drive Area 0. If you add the shown L0 + L1 sectors you'll get exactly the totalisosize = Data Zone. :cool:

http://img287.imageshack.us/img287/10/datazone2rf.jpg (http://www.imageshack.us)

If you think there are only 2*L0 sectors to be written then you are wrong. There are Lead-In, Middle Zones, and Inner Drive Areas too. :)
The technics is much more complicated, especially interesting is the point, when the Layer jump is occurring, but I don't want to say more. DVDD does it well.

If you study more details from DVD-ROM, DL DVD+R, CD, you will see that the system is the same, and Dual Layer DVD-R cannot break out.

r0lZ
4th July 2005, 19:17
I know that. But is is still needed to write (or call if 'format' if you want) this part of the disc after the last sector of L1, and before the minimal lead out zone. Calling it lead out don't change the fact that it must be written. So, it takes longer to burn the same amount of data if the layer break is after the middle of the compilation.
But I understand your objection: the info may be wrong if you consider that a sector is necessarily a data sector.
The correct label should therefore be "total number of sectors to burn, including the number of additional lead out sectors"... But it's too long to fit on the GUI. Maybe I will change that to display, for example, the number of data sectors on L1.

Anyway, thanks for your explanation.

r0lZ
4th July 2005, 19:32
I have received an answer from the japanese author of the guide pointed to by jinjin_jp. Seems that, when burning a DVD-R with DVDD, the number of sectors on L0 are always 2,092,896, as you can see on this image (http://yaki2fan.hp.infoseek.co.jp/-r_dl/001.gif).

But, in this case, I don't understand how it is possible to place the LB at sector 2,092,896 when a DVD-R is only 4,171,712 sectors long.

I will continue to investigate. Maybe it's a bug in DVDD?

Tobi, can you post the L0 and L1 sectors displayed by DVDD after the burn of your test DVD-R? Thanks.

Tobii
4th July 2005, 21:34
Sorry, I also have to take care of a different one.

Layer 0: 2,092,896
Layer 1: 1,974,052

2,092,896*2= 4,185,792 --> ???


And don't ask me now, why it is so.

blutach
4th July 2005, 21:43
@r0lZ

Re: Potential DVD Decrypter bug. Remember DVD Decrypter's development never proceeded to the stage of -R DLs appearing. It quite possibly can't handle this strange beast.

Nevertheless, -R DLs do appear to obey the basic rules: L0 > L1 and L0 evenly divisble by 16.

Question: Is it absolutely necessary to burn all the sectors on L0? I wouldn't think so. You could figure out how many sectors there were on L1, multiply by 2 and that would be your maximum burn size.

In Tobii's recent case, 1,974,052 per layer and then of course, observing the break at cell boundary (which seems to be the problem with some burning software).

Regards

blutach
4th July 2005, 21:48
I know that. But is is still needed to write (or call if 'format' if you want) this part of the disc after the last sector of L1, and before the minimal lead out zone. Calling it lead out don't change the fact that it must be written. So, it takes longer to burn the same amount of data if the layer break is after the middle of the compilation.
But I understand your objection: the info may be wrong if you consider that a sector is necessarily a data sector.
The correct label should therefore be "total number of sectors to burn, including the number of additional lead out sectors"... But it's too long to fit on the GUI. Maybe I will change that to display, for example, the number of data sectors on L1.

Anyway, thanks for your explanation.The guide to burning DL disks with PgcEdit does spell this out:

The number of sectors to burn will be twice the layer break sector (and will always be higher than the ISO size), since DVD Decrypter pads out the remainder of layer 1.Regards

Tobii
4th July 2005, 22:26
In Tobii's recent case, 1,974,052 per layer and then of course, observing the break at cell boundary (which seems to be the problem with some burning software).

A problem is well between the DVDDecrypter + NEC 3520 + Verbatim DVD-R DL.
If I look at the writeable side, one sees rings strange discolourations on the outer one. :angry:
The disc isn't readable and this was the third test now. I make no more tests to -R DL.


Goodbye

r0lZ
4th July 2005, 22:44
OK, Thanks guys! Tobi's post confirm that there is really a problem with DVD-Rs!
I'm not sure it's a DVDD bug, since, according to what I've read in japanese ;), the 'magic' number 2,092,896 is always present, even if you burn or read the number of sectors in L0 with another program. Seems it's a DVD-R bug! I really really hate -Rs! :angry:

Anyway, here is beta 20 (http://www.videohelp.com/~r0lZ/pgcedit/beta/PgcEdit_winexe_0.6.0beta20.zip).

I have changed the informations displayed in the Layer Break window.
Note that the Total Number of Sectors in Compilation is now computed without the last padding sector, although I continue to use the value incremented by 1 internally.
Let me know if it's OK for you, Frank.

Jinjin_jp, I have also changed the way I handle the DVD-R bug. Now, the offset used in the IFOs when the ::burn::layer_break_sector value > 0 in burn.cfg, is:
Offset used in IFOs = ::burn::layer_break_sector value - original LB position + original offset
This new offset is also displayed in the GUI if the ::burn::layer_break_sector value > 0.
I hope that, this time, it's what you want.
But, please, cry in japanese, very loud: Never burn a DL DVD-R!

r0lZ
4th July 2005, 22:48
Question: Is it absolutely necessary to burn all the sectors on L0? I wouldn't think so. You could figure out how many sectors there were on L1, multiply by 2 and that would be your maximum burn size.No! I have never said that!
Seems the japanese method to avoid the -R bug is to burn all sectors, but I still doesn't understand why the number of sectors in L0 displayed by DVDD is always 2,092,896, which is obviously not the DVD-R capacity / 2!!! :confused: :confused: :confused:

blutach
4th July 2005, 22:57
Also confused here. I was just suggesting that whoever is silly enough to use -R DLs burn L0 to a maximum equal to the same size as L1. The question then becomes what to do with the remaining sectors on L0? Leave them blank. Hopefully, that will work. Burn them with 0s? Makes no sense. You just want the break to occur at the cell boundary and hop over to L1, don't you?

Regards

r0lZ
4th July 2005, 23:03
There are no remaining sectors in L0, since the offset is changed in the IFO files. The padding sectors are added by mkisofs between VIDEO_TS.VOB and VIDEO_TS.BUP.
Of course, whatever method you use, the last sector of the cell just before the LB cell must be at the end of the burned part of L0, and the first sector of the layer break cell must be at the same place in L1. That's the rule, and the method I use to burn DVD+Rs and DVD-Rs (standard and bugfix methods) is coherent with this obligation.

r0lZ
4th July 2005, 23:10
I wonder if the -R bug could be caused by a wrong method to write the number of sectors in L0 in the TOC. In this case, the DVD player expects to find the layer break at sector 2,092,896. Since this sector doesn't exists (at least in the data zone), it is forced to change to L1 to read the remaining sectors. But if you don't fill L0 with datas, it will try to read data on an unformated part of L0, and will most likely crash.

jinjin_jp
5th July 2005, 14:27
Anyway, here is beta 20 (http://www.videohelp.com/~r0lZ/pgcedit/beta/PgcEdit_winexe_0.6.0beta20.zip).

Jinjin_jp, I have also changed the way I handle the DVD-R bug. Now, the offset used in the IFOs when the ::burn::layer_break_sector value > 0 in burn.cfg, is:
Offset used in IFOs = ::burn::layer_break_sector value - original LB position + original offset
This new offset is also displayed in the GUI if the ::burn::layer_break_sector value > 0.
I hope that, this time, it's what you want.
But, please, cry in japanese, very loud: Never burn a DL DVD-R!
I tried beta20. Thanks.


I have changed the informations displayed in the Layer Break window.
Note that the Total Number of Sectors in Compilation is now computed without the last padding sector, although I continue to use the value incremented by 1 internally.
[Below is about not only DL burning but common with SL burning and DVD-ROM(DL/SL).]
Is it to be said about "ISO file size (including the final padding sectors)" ?
I think shown value of previous version is right.
It seems to already include final pading sector.
For example
shown in beta17 as ISO file size : 3956366 (A)
ISO file size : 3956366 (A) >>>can see DVDDecrypter ISO-Read Mode
actual ISO filesize output : 3956366 (A) >>>can see Explorer property
End sector(LBA) of last file : 3956364 (B) >>>can see DVDDecrypter File Mode property
...above three kind of (A) is same value.

It means that
(B) is LBA, so start from "0", so the number of sectors to End sector of last file is (B)+1.
From above, final padding = (A)-((B)+1) ="1" is already included in (A).

I examined DVD-ROM(DL/SL) and DVD-R/SL which I burned, and found that
(1)When DVD-ROM, DVD-R of ISO writing and DVD of Data writing closed by 'DISC at once', the number of padding sector is "1".
(2) When DVD-R of Data writing closed by 'Track at once(impossible add)', the number of padding sector is "5001".
***(writing software is Record Now, and 'DISC at once' can't be selected by it's usual Data writing after ver4.6, but by wizard mode of Data writing can be selected.)

r0lZ
5th July 2005, 14:56
I have changed only the number of sectors in the compilation (the value in the top left corner of the info frame). This value is computed from the length of the files + the header and file system sectors + the 32K gap padding sectors (added only if this option is ON). Previously, an additional sector was added to compensate for the last padding sector added by MKISOFS.
I don't know why MKISOFS add this sector at the end if the ISO, but it's a fact, and it doesn't hurt.

I don't know how many sectors are added by various softwares, but keep in mind that you are supposed to burn the ISO with DVD Decrypter. Also, it doesn't make sense to write a DVD-Video in track at once mode, since a DVD-Video is only one track long. I suppose that the 5000 sectors (5001 - the sector added by MKISOFS) added by RecordNow in track at once mode are needed to allow the user to add another track later.

Anyway, I am (almost) sure that there are no errors in the method I use to compute the number of sectors. The internal logic has not changed at all in beta 20, only the display of some values.
Of course, if the ::burn::layer_break_sector value is greater than 0 in burn.cfg, another offset is computed, but that's another story. Please let me know if this new method works well with DVD-Rs in Japan.

frank
5th July 2005, 15:04
Originally posted by rOlZ:
I wonder if the -R bug could be caused by a wrong method to write the number of sectors in L0 in the TOC. In this case, the DVD player expects to find the layer break at sector 2,092,896.

Originally posted by blutach:
Potential DVD Decrypter bug. Remember DVD Decrypter's development never proceeded to the stage of -R DLs appearing. It quite possibly can't handle this strange beast.That suspicion I have a long time!
The changed L0 sectors MUST be written into TOC!! If not - coaster. :angry:
The dual -R have a new Book Type setting, that the old player firmware doesn't know, and the specs are not published.
Maybe DVDD cannot write the TOC of dual layer DVD-R properly. Did anybody ask Lightning UK?
At the moment manufacturers wasting our money and time.

@Tobii
DL DVD-R
Layer 0: 2,092,896
Layer 1: 1,974,052
What number of disk sectors is burned?

Maybe the L0 entry failed but L1 is right.
Please start iso creation again and post what PgcEdit displays.
Isototalsize? (>1,0974052*2) Final LB?

Perhaps L1 is right, then DVDD caused the -R bug in TOC.

frank
5th July 2005, 15:36
@rOlZ
I confirmed the +1 sector appended by MKISOFS. It's an empty data sector with pointers.
Right, we must count it to the isototalsize.

jinjin_jp
5th July 2005, 15:43
The dual -R have a new Book Type setting, that the old player firmware doesn't know, and the specs are not published.
About Book Type of -R/DL, Pioneer member concernd development says in this site page(3) (http://www.itmedia.co.jp/lifestyle/articles/0501/28/news089_3.html) (sorry, it is Japanese) like below,
"It plans to make a book type DVD-R for now.
Only, a replay compatibility is decided by how to be implemented for the player to recognize media in 2 layers actually.
As for writing by the present, the DVD-Video mode, it recognizes that the replay compatibility at the DVD player is from 80 % to nearly 90 %."

And there is one more interesting thing "Layer Jump Recording" of which image is Figure of this site page(2) (http://www.itmedia.co.jp/lifestyle/articles/0501/28/news089_2.html).
In this new method, not to make up for layer 1 simply from layer 0, and to record while moving layer 0 and layer 1 alternately is a maximum characteristic.
However, this is not in the relation with the burning DVD-Video.
There is said it has the big merit at the realtime record device which isn't beforehand decided, i.e. the device where to do fainalize in the optional timing is looked for, such as DVD recorder and the cam coda.

frank
5th July 2005, 17:30
Layer Jump Recording needs another disk format: PTP (Parallel Track Path).
Good for data backups. Never seen here. Jumping between video layers can cause stuttering...

PgcEdit DL DVD burning routines need OTP (Opposite Track Path) formatted DVDs.
Standard for DVD-VIDEO.

r0lZ
5th July 2005, 18:07
@rOlZ
I confirmed the +1 sector appended by MKISOFS. It's an empty data sector with pointers.
Right, we must count it to the isototalsize.So, do you think it should be counted as well in the Total Number of Sectors in Compilation value ? I may easily add it again, as it was in beta 19.

Also, do you know what is the utility of this sector. Pointers? But pointers to what? Is it required by the DVD-Video standard?

r0lZ
5th July 2005, 18:17
... it recognizes that the replay compatibility at the DVD player is from 80 % to nearly 90 %.IMHO, as far as the LB problem discussed here exists, the compatibility is around 0 % ... unless you burn your DVD-R DL with PgcEdit, and you enable the trick with the ::burn::layer_break_sector value in burn.cfg. In this case, you will not burn a coaster, but the resulting DVD will still be abnormally full (therefore increasing the risk of read errors.)

BTW, I received a confirmation from the author of the japanese guide: beta 20 implements exactly the method they wanted. So, I will add a field in the burn setup dialog to enter this number easily, and also a word of caution about burning DVD-R DL.
Sorry to the authors of the PgcEdit manuals and guides! You will have to explain something I don't understand very well myself!

r0lZ
5th July 2005, 19:25
Beta 21 (http://www.videohelp.com/~r0lZ/pgcedit/beta/PgcEdit_winexe_0.6.0beta21.zip) is out.
It should be the last beta (I hope! :scared: )

The value displayed in the "Total Number of Sectors in Compilation" field is now again the total number of sectors in the ISO before the shift for the layer break position (ie the additional sector added by MKISOFS is included), like in beta 19.

I have added the field to input the forced LB sector to avoid the DVD-R bug in the burn setup GUI.

I have also added an option menu item to open the burn setup directly from the main window.

As far as I know, everything in now correct. I will probably release 0.6.0 final in one or two days, unless someone has still something to say before...

Sorry again for the last minute changes in the GUI, blutach and Tobi!

Thanks to everybody who helped me implement this unique DL DVD burning function! :thanks:

Tobii
5th July 2005, 19:53
Sorry again for the last minute changes in the GUI, blutach and Tobi!
Grrrrrrr... :D , I had updated my straight one.
Still give blutach and me the possibility at least of adapting it.

Then send her tomorrow evening? Please... :thanks:


only cosmetic --> In the Burn DVD setup:

Force Layer breal at sector (for DL DVD-R)

nwg
5th July 2005, 20:27
Can I make a strange request.

Can you make the green layer change line look more green . I am actually red/green colour blind and it looks too like blue to me. If a DVD has blue line I may have problems telling the difference with the green one. :)

r0lZ
5th July 2005, 23:02
OK. I have fixed the typo, and changed the light green lines to pure green.

Also, I have removed the text "(including the final padding sector)" near the IFO file size field, because it doesn't make sense anymore now that the final sector is included also in the Total number of sectors in compilation value. And this text was wrong, since this sector is (probably) not a padding sector.
Sorry for that change, too. But don't worry, Tobi. You don't need to update your PDFs for a so small change.

nwg
5th July 2005, 23:07
changed the light green lines to pure green.


Thanks a lot. :)

r0lZ
6th July 2005, 15:09
Here is another DL burn test I've made, but this time using a Philips DL-RVD+R (Manufacturer=Mitsubishi MKM-001-00, 2.4x and 4x), burned with my NEC ND-3520A at 4x speed.
The layer break is at sector 2065664 (1F8500h).

http://img200.imageshack.us/img200/4761/kproberesult5zk.png

Seems the PI and PIF are better now, but there are still 95 unrecoverable errors! But my NEC drive doesn't support the KProbe tests, so, I've made the test with my old JMLS DVD-R drive.
Unfortunately, I can notice the read errors when playing the DVD on my old Sony standalone. Strangely enough, they are all located in the fiew last minutes of L0! Just before the layer break, and on L1, there are no problems at all!

Anyway, the most important is the layer break: it is played almost seamlessly by my Sony. I can notice only a one second pause, which is a little bit less than when I play a commercial DVD! Unbeliveable! :)

frank
6th July 2005, 17:59
:D :D Anyway, it's a good result! The 95 errors show that the correction electronics of your drive is not the best.
Look at mine, PI go up to 1400 :( but playing.

For the 1 sec pause: Is there a STC discontinuity on LB?
In my case I remuxed the stream without timer discontinuity and my player played it seamless.

I have also added an option menu item to open the burn setup directly from the main window.Thanks, now it is in the (logical) right place. :D


To the -R community:
Has anybody burned a dual layer DVD-R with Nero?

r0lZ
6th July 2005, 18:22
Of course, there is a STC discontinuity flag on LB, and it's suficient to stop my Sony player for some time, even if there is no real discontinuity in the VOB. I've made the test: forcimg the flag on, say, cell 2 cause the player to stop for a second or so, even without a real discontinuity. When jumping from L0 to L1, it takes usually around 1.5 to 2 secs... but not with a DL DVD+R!

[EDIT:] I have played the DVD with my KISS DP-450, which uses a PC drive, and I can't notice the read errors at the end of L0. And the LB is even less noticeable! My conclusion is that my JMLS PC drive and my Sony standalone are a little bit tired.

[EDIT2] I have also tested the DVD with DvdInfoPro, which is able to test the NEC drives. The results on both the JMLS DVD-R and the NEC DVD-RW drives are a lot better, and it doesn't find any read error at all! Strange!

frank
7th July 2005, 16:03
Originally posted by rOlZ:
Also, do you know what is the utility of this sector. Pointers? But pointers to what? Is it required by the DVD-Video standard?I's a pad sector with same volume pointers like that 150 pads. Not linked to any file in the system, really an issue of MKISOFS.

That +1 iso size doesn't matter if you burn single layer media, the chances are very low, 1:2,295,104 on DVD+R, that it causes an error. But on DL media with "folded" content it can break the rule L0 >= L1, and crash. PgcEdit does it handle right.

Maybe I have the time to contact the author of MKISOFS later
but now 0.6.0 is out and I go on holidays :D :D :D

jamos
4th April 2006, 15:07
Here is another DL burn test I've made, but this time using a Philips DL-RVD+R (Manufacturer=Mitsubishi MKM-001-00, 2.4x and 4x), burned with my NEC ND-3520A at 4x speed.
The layer break is at sector 2065664 (1F8500h).

http://img200.imageshack.us/img200/4761/kproberesult5zk.png

Seems the PI and PIF are better now, but there are still 95 unrecoverable errors! But my NEC drive doesn't support the KProbe tests, so, I've made the test with my old JMLS DVD-R drive.

Rolz you need a better dual layer burner :p The best for the MKM dl disks are the Plextors or Benqs. My Plex 716 burns those disks at 6x very well. Any PIF over 4 is considered out of standard, but as you stated you are using a dvd-rom drive to run kprobe which is not the best drive to scan with as you cannot control the read speed. Both the Plextor 716 and any of the newer Benq drives support PIE/PIF testing as well as Jitter.

jamos
4th April 2006, 15:15
:D :D Anyway, it's a good result! The 95 errors show that the correction electronics of your drive is not the best.
Look at mine, PI go up to 1400 :( but playing.

For the 1 sec pause: Is there a STC discontinuity on LB?
In my case I remuxed the stream without timer discontinuity and my player played it seamless.

Thanks, now it is in the (logical) right place. :D


To the -R community:
Has anybody burned a dual layer DVD-R with Nero?
PI (or PIE) are correctable errors, usually a fairly good dvd player will not have issues with these. PIFs (uncorrected errors) are more important, Rolz's 95 is very high and I would expect skipping, jumping, or freezing at those levels. Standards are <= 280 for PIE 8ecc blocks, <=4 for PIFs at 1ecc blocks, at 1x speed, POFs <=0.

more info here if anyone is interested http://club.cdfreaks.com/showthread.php?t=80545

r0lZ
4th April 2006, 15:54
Thanks for the info!

Not sure the Plextor drives are so good, though. When I bought my Nec, I've read several reviews, and it was considered as one of the best burner on the market, while Plextor got very bad reviews, mainly because this brand is particularly overpriced for its real quality. Anyway, now, I use exclusively Verbatim media for the rare DL discs I burn, with great success. This Philips test was made at the time I was developing the DL burn function, and Verbatim DLs were very hard to find in Belgium.

Also, though Kprobe doesn't work with my drive, DVDInfoPro works flawlessly!

jamos
4th April 2006, 16:09
Thanks for the info!

Not sure the Plextor drives are so good, though. When I bought my Nec, I've read several reviews, and it was considered as one of the best burner on the market, while Plextor got very bad reviews, mainly because this brand is particularly overpriced for its real quality. Anyway, now, I use exclusively Verbatim media for the rare DL discs I burn, with great success. This Philips test was made at the time I was developing the DL burn function, and Verbatim DLs were very hard to find in Belgium.

Also, though Kprobe doesn't work with my drive, DVDInfoPro works flawlessly!
Hehe I only mentioned the plextor 716 and it was not that good to begin with but the later Firmwares are excellent, the 712 is good too..the rest are overpriced. The 716 does really well, I like it also for its full Plextoools support. Those are the only plex drives I would recommend.

Benq does well too and it has scanning capabilities with DVDspeed(Eriks) or Dvdinfopro (yes I know Nic ;) ).

But there is nothing wrong with NEC drives, I use my 4550 with Liggy and Dees Bitsetting Firmware (so you can bitset DVD+R, DVD+RW as well as DVD+DL). Link for your drive and other necs is here
http://liggydee.cdfreaks.com/page/

and if your really daring and want to change some of your media codes to get better burns with problomatic media you can get this tool here
http://club.cdfreaks.com/showthread.php?t=139455

ALso I beleive CDSpeed supports NEC drives now also http://www.cdspeed2000.com/

frank
4th April 2006, 16:11
And I mismatched the 95 unrecoverable errrors with PI errors. :(

jamos
4th April 2006, 16:24
And I mismatched the 95 unrecoverable errrors with PI errors. :(
Actually I misread the 95 number, that is the number of PO errors. They are major failures and one or more will cause any drive to skip or fail when it hits one. His PIFs reached 11 (which is most likely where his PO's (POE) occured). Single PIF spikes above 4 is usually not a big deal and should be ignored (due to scanning inconsistencies) but large blocks of PIF errors above 4 is usually going to cause PO errors. Even if you get no PO errors but your PIF levels are high (sometimes PIE (PI) too) you can get skipping, pausing, etc. (usually mainly on older settop dvd players)

jamos
12th April 2006, 12:13
this is what a good dl burn should look like. burned at 8x on a NEC 4550 with bitsetting fw by herrie and dee..note pifs well below 4.
:)

r0lZ
12th April 2006, 12:40
Please use ImageShack (http://imageshack.us/index.php) to post images here at Doom9. The attachments approval requires usually a very long time!

jamos
12th April 2006, 15:04
Please use ImageShack (http://imageshack.us/index.php) to post images here at Doom9. The attachments approval requires usually a very long time!
Thanks for the Tip Rolz, this is the first forum I have been on that does this image approval..:(

I have my own site I can link to as well..

r0lZ
12th April 2006, 17:06
Nice graph indeed.
Under which brand is sold this MKM001 medium? Is it the Philips DL-RVD+R?

jamos
12th April 2006, 19:35
Nice graph indeed.
Under which brand is sold this MKM001 medium? Is it the Philips DL-RVD+R?
Not Phillips.

IT is Verbatim Dual layer media MKM001, it is about the best dual layer media available.:cool:

Here is a link to it (of course this is only good for US and Canada)
http://www.newegg.com/Product/Product.asp?Item=N82E16817131163

r0lZ
13th April 2006, 10:48
OK. I'll remember: Verbatim +R DL, 6x. Will try to find an equivalent here in Belgium. Thanks!

frank
13th April 2006, 17:42
MKM001 is not the 8x media!

jamos
13th April 2006, 23:03
MKM001 is not the 8x media!
Yes it is advertised as 2.4x but some burners (ie nec 4550 etc.) can burn this media at 8x no problem (see scan above).

It says up to 6x on the package.

frank
18th April 2006, 13:01
The new Verbatim 8x DL medias are labeled as MKM003.

mikeathome
18th April 2006, 21:15
Hi,

Q: Is PGCEdit transfering the number of sectors on L0 layer automatically to the latest ImgBurn versions or do I still need to enter them manually into ImgBurn write-option dialog? Is it possible at all?

It does avoid the fully automatic process.

mike

[Tobi]
18th April 2006, 22:19
PgcEdit passes the number of the sectors on Layer 0 automatically to ImgBurn with CLI.
It runs automatically and you must not enter the sectors manually into ImgBurn write-option dialog.

mikeathome
19th April 2006, 13:16
']PgcEdit passes the number of the sectors on Layer 0 automatically to ImgBurn with CLI.
It runs automatically and you must not enter the sectors manually into ImgBurn write-option dialog.

Thanks, have a nice day...

mike

jamos
19th April 2006, 21:00
The new Verbatim 8x DL medias are labeled as MKM003.
Yes those will overspeed to 10x on plextor 760s!:D