Log in

View Full Version : Burning DL media with PgcEdit


Pages : 1 [2] 3 4 5 6 7

r0lZ
11th June 2005, 12:17
AFAIK there was a bug in earlier versions of MKISOFS in DVD-VIDEO iso with unused 0 byte menu vobs.What is this bug exactly? Do I have to do something special to avoid it when creating the ISO with PgcEdit?

frank
11th June 2005, 15:08
Maybe I have something mismatched. You can read about problems with unused vobs in the cdwrite mailing list at debian.org.
mkisofs -dvd-video: caveat lector by Andy Polyakov (http://lists.debian.org/cdwrite/2004/07/msg00128.html)
From this point you have nothing to change in PgcEdit.

Currently I use MKISOFS in ImgTool Classic v0.91.5 and have no problems.

If you search the list you can find very interesting things about burning.
Layer Break positioning in DL DVD-Video recordings by Andy Polyakov (http://lists.debian.org/cdwrite/2004/07/msg00102.html)

jinjin_jp
12th June 2005, 00:15
I tested PgcEdit0.6.0beta3 until create ISO file, and would like to report.
The result was almost very good.

-------------------------------------------------------------------------------------------------------------
At first I create ISO file by simply only ImgToolClassic0.91.5 from original DVD, and compared with the result of PgcEdit

about LBA and IFO.
When prcedure of PgcEdit,
green cell was cell_80 of title_12(this cell is same as LayerBreakCell of original,and CellTypeFlags is 2),
and indicated 'Number of sectors in first layer (L0) : 1992992",
and 'The pad was 5 for file VIDEO_TS.VOB' in log.

About created blank sectors,
VIDEO_TS.IFO LBA is 323-333 (same as original)
VIDEO_TS.VOB LBA is 334-86919 (same as original)
VIDEO_TS.BUP LBA is 86925-86935 changes from 86920-86930
...so created 5 blank sectors(56920-86924),
and it's consistent with IFO,
VIDEO_TS.IFO , VMGM_MAT . Last Sector of VMG is 86612 changes from 86607 (+5)
VIDEO_TS.IFO,VMG_PTT_SRPT,Title_1:Title set starting sector is 86613 changes from 86608 (+5)

About 'first layer (L0)'
VTS_09_1.VOB LBA is 396084-920301
the end sector of cell_79 is 1596907 (when the start sector of cell_1 is 0)
...so the end sector of cell_79 is 1992992(=396084+1596907+1), and equal to 'first layer (L0)' indicated in PgcEdit.

This is very good result.
---------------------------------------------------------------------------------------------------------------
Next, I corrected the CellTypeFlags of cell_80 (to 10 from 2), before create ISO file by simply only ImgToolClassic0.91.5,

and tested like above.
When prcedure of PgcEdit,
green cell was cell_74 of title_12,13, and 14 (the cell is reused in these 3 titles),and I chose cell_74 of title_12,
and indicated 'Number of sectors in first layer (L0) : 1948016",
and 'The pad was 4 for file VIDEO_TS.VOB' in log.

About created blank sectors,
VIDEO_TS.IFO LBA is 323-333 (same as original)
VIDEO_TS.VOB LBA is 334-86919 (same as original)
VIDEO_TS.BUP LBA is 86924-86934 changes from 86920-86930
...so created 4 blank sectors(56920-86923),
and it's consistent with IFO,
VIDEO_TS.IFO , VMGM_MAT . Last Sector of VMG is 86611 changes from 86607 (+4)
VIDEO_TS.IFO,VMG_PTT_SRPT,Title_1:Title set starting sector is 86612 changes from 86608 (+4)

About 'first layer (L0)',
VTS_09_1.VOB LBA is 396083-920300
the end sector of cell_73 is 1551932 (when the start sector of cell_1 is 0)
...so the end sector of cell_73 is 1948016(=396083+1551932+1), and equal to 'first layer (L0)' indicated in PgcEdit.

About CellTypeFlags,
cell_74 of title_12,13, and 14 were cerrected to 2 from 10, and checked in LayerBreak.

This is almost good result.
But 'first layer (L0)' < 'second layer (L1)' .

I think the minimum value of the Layer Break must be 1978180(>=3956359/2), because about original LBA,
...the end sector of the last file is 3956359 (from VTS_10_0.BUP LBA is 3956351-3956359),
On the other hand, when choose the Cell of LayerBreak, indicated like following in PgcEdit
...Total number of ISO image : 3956511 of maximum 4148992.
...The Layer Break must be between ISO sector : 1882016 and sector 2074496.
But we can take measures because we can choose another cell as LayerBreak.

And I wonder if we may choose any CellTypeFlags as LayerBreak,because I've never seen the sell of multiangle as LayerBreak.
Now there are any CellTypeFlags in LayerBreakCell list of of Pgc Edit (for example 93,95,221,223).

r0lZ
12th June 2005, 10:08
This is almost good result.
But 'first layer (L0)' < 'second layer (L1)' .I know. There is a bug in beta 3 when the selected cell begins before the middle of the compilation. Will be fixed in beta 4.

And I wonder if we may choose any CellTypeFlags as LayerBreak,because I've never seen the sell of multiangle as LayerBreak.
Now there are any CellTypeFlags in LayerBreakCell list of of Pgc Edit (for example 93,95,221,223).That's a good question. I suppose it is legal to set the layer break on an angle cell, but probably only on the first angle, and I suppose that the seamless flag must be cleared on all subsequent angle cells. Currently, PgcEdit do not handle this case.

FilipeAmadeuO
12th June 2005, 10:12
I think it would be good if PGCEdit sugested the best layerbreak location.
It should be the first cell id/vob id in which L0>L1.
In this way the recorded dvd will be the most space efficient.

r0lZ
12th June 2005, 10:17
Not always. See here (http://forum.doom9.org/showthread.php?p=666960#post666960).

FilipeAmadeuO
12th June 2005, 10:22
Ok. Thats another possible way :)
Thanks for your good job.

r0lZ
12th June 2005, 16:34
Beta 4 is available here (http://www.videohelp.com/~r0lZ/pgcedit/beta/PgcEdit_winexe_0.6.0beta4.zip).
As far as I know, everything works fine now.

Tobii
12th June 2005, 22:08
Even if no-one would make it...

If the DVD is too big and one nevertheless pushes "OK", an error message comes:


syntax error in expression "+": premature end of expression
syntax error in expression "+": premature end of expression
while executing
"expr $origabsvobstart+$origcellstart"
(procedure "compute_dloffset" line 5)
invoked from within
"compute_dloffset $w2.mf.c"
(procedure "::burn::burn" line 801)
invoked from within
"::burn::burn"
(menu invoke)


No more reaction of PgcEdit and here helps only...kill in the task manager.

I will make an ISO and tomorrow then carrying on.
BTW,thanks for the new Shortcut to launch the PGC Preview.

CoNS
12th June 2005, 22:43
Furthermore, PgcEdit now detect when a VOB is present but empty, and offer to delete it. It's the safest way to handle this problem.Yes, and this eliminates some of the reallocation errors in Nero, too. Thanks.

However, other reallocation errors in Nero are caused by a menu domain in either VMG or a VTS being all dummy PGCs, while the .VOB is larger than 0 KB. In these cases, I have to close Nero, re-open PgcEdit, locate the menu domain in question and perform a "Blank out all menu PGCs" to safely remove the .VOB file, and go to Nero again for burning.

r0lZ, could you maybe add an auto-check for this situation, too, and start the "Blank out all menu PGCs" macro for the menu domain(s) in question for the user to answer yes or no? This way, PgcEdit would take care of all of the situations where Nero's reallocation error pops up...

r0lZ
12th June 2005, 23:33
If the DVD is too big and one nevertheless pushes "OK", an error message comesIn which situation exactly? When the compilation is > DVD-9 size?
Did you got this error when the DL-burn dialog opens, or when you selected a line in the listbox?

r0lZ
12th June 2005, 23:35
However, other reallocation errors in Nero are caused by a menu domain in either VMG or a VTS being all dummy PGCs, while the .VOB is larger than 0 KB. In these cases, I have to close Nero, re-open PgcEdit, locate the menu domain in question and perform a "Blank out all menu PGCs" to safely remove the .VOB file, and go to Nero again for burning.

r0lZ, could you maybe add an auto-check for this situation, too, and start the "Blank out all menu PGCs" macro for the menu domain(s) in question for the user to answer yes or no? This way, PgcEdit would take care of all of the situations where Nero's reallocation error pops up...Hum... Not really easy to do when the DVD is opened. Will see what I can do...

frank
13th June 2005, 00:07
Why not post the damned Nero issues to Ahead?! We burn with freeware!
I only can warn everyone using Nero to burn DL media. It sorts the files new and gaps are lost.

Beta 4
If you double-click a line in the Select Layer Break window you'll get an Application Error. In beta 3 the cell preview started.wrong # args: should be "::burn:: preview_cell w mode"
wrong # args: should be "::burn:: preview_cell w mode"
while executing
"::burn:: preview_cell .burndl.mf.c"
(command bound to event)The LB setting is ok. :D

r0lZ
13th June 2005, 02:04
Why not post the damned Nero issues to Ahead?! We burn with freeware!
I only can warn everyone using Nero to burn DL media. It sorts the files new and gaps are lost.Right. I have tried to do something for this Nero problem with non-empty unreferenced menu VOB files, but it's too much work for such a small advantage. Sorry. Burn with PgcEdit, or generate the ISO with PgcEdit and burn it with RecordNow, if you really want to pay to burn.

Beta 4
If you double-click a line in the Select Layer Break window you'll get an Application Error. In beta 3 the cell preview started.Right again. Forgot a last minute change. Bug fixed now. Thanks.

The LB setting is ok. :D :)

r0lZ
13th June 2005, 02:13
Beta 5 (http://www.videohelp.com/~r0lZ/pgcedit/beta/PgcEdit_winexe_0.6.0beta5.zip)

Just one addition: a "Seamless cell" button in the DL-Burn GUI to remove a layer break flag left after a previous burn.
And double-click to call the preview bug fixed.

I still need to work a bit on some minor things, not related to the DL-Burn, and will release v0.6.0 final.

Tobii
13th June 2005, 05:54
In which situation exactly? When the compilation is > DVD-9 size?
yep...the error comes, when the compilation is > DVD-9 size.
The list box doesn't open, only the error comes.

r0lZ
13th June 2005, 10:02
yep...the error comes, when the compilation is > DVD-9 size.
The list box doesn't open, only the error comes.
OK. I will add a check to avoid this situation.

frank
13th June 2005, 10:41
Congratulations rOlZ!
It has been much work to add the DL burning feature to PgcEdit. It overcomes NERO and others. :thanks: When do you sleep??

I have edited and burnt my 3 hours DVD Video on DL. DVDD does the burning job very fine. No coaster, fully success!

r0lZ
13th June 2005, 12:06
:thanks: Thanks for this report, and for your original idea.

However, note that there is still a bug in beta 5: if the user selects an angle cell, the seamless flag is cleared on that cell, but not on the other angle cells.
In the current version, I remove all angle cells from the cells list. Although this solution is not perfect, it's better than nothing.

Also, I have to check the burn function when some DVD-ROM files are present. But I think it's OK.

I have also fixed the bug reported by Tobi, occuring when the compilation size > DVD-9 size. Now, you will not be allowed to burn in this situation.

blutach
13th June 2005, 15:02
B5 looks good. Haven't done all my tests yet (busy week and weekend - sorry). I would suggest not allowing LB on angle cells at this stage, and reused cells where previous cell is on different layer may be a bit suspect as well.

I am with Filipe in that I thought L0 had to be > L1, even if its just by 32k. I was always under the impression that L0 had to be greater than L1 - even if it achieved this by having lots of padding.

One thing I have noticed is that middle click is bringing up the Pgc Editor and not the menu editor? Is anybody else seeing this?

Regards

r0lZ
13th June 2005, 15:22
B5 looks good. Haven't done all my tests yet (busy week and weekend - sorry). I would suggest not allowing LB on angle cells at this stage, and reused cells where previous cell is on different layer may be a bit suspect as well.In beta 6, angle cells are removed from the list.
Reused cells should not be a problem, since if the previous cell is not contiguous, the seamless flag should be off anyway.

I am with Filipe in that I thought L0 had to be > L1, even if its just by 32k. I was always under the impression that L0 had to be greater than L1 - even if it achieved this by having lots of padding.Why? The requirement is that the same amount of data must be written on both layers. If L0 > L1, padding sectors are added, and if L0 == L1, then everything should be fine.

One thing I have noticed is that middle click is bringing up the Pgc Editor and not the menu editor? Is anybody else seeing this?Strange. Have you tried Control-Left click?

blutach
13th June 2005, 15:29
1. DELETED - SEE NEXT POST

2. Now that Preview is Ctrl-P, ~ can be liberated for call menu editor peut-etre?

3. Re LB - I just read somewhere that L0 was supposed to be > L1. But maybe it is >= Getting old, you know and memory playing tricks :)

Regards

blutach
13th June 2005, 15:38
Forget about the middle clicking - it has to do with the name of the file - If I change it to PgcEdit (I had Beta PgcEdit) and delete the bin and re-open I am OK.

Regards

r0lZ
13th June 2005, 15:40
I have not changed the hotkeys since 0.5.7 (excepted the addition of Control-P).
The config file is not related to shortcuts.

No, I keep ~` for the preview, as it is used more often than the menu viewer. To call the menu viewer, you can use Control-M, or, -normally- the middle mouse button, or Control-left-click. I think it's enough.

blutach
13th June 2005, 15:41
Am I wrong but Ctrl-P and ~ are the same are they not?

By the way, I like the preview has buttons showing now. :)

Regards

r0lZ
13th June 2005, 15:45
Am I wrong but Ctrl-P and ~ are the same are they not?Yes, I have added Control-P for people using non-US keyboards. In this case, the ` key may not be easily available.

Buttons showing in preview: it's another great idea and work of jeanl.

blutach
13th June 2005, 15:54
I suspected as much. OK I do more testing on B5 tomorrow, but for now g'night. :)

Regards

jinjin_jp
13th June 2005, 16:24
I've tested beta 4 and 5.

I know. There is a bug in beta 3 when the selected cell begins before the middle of the compilation. Will be fixed in beta 4..
The result was very good.
Beta 4 and 5 created 60,500 blank sectors, beta 3 created 4 blank sectors.
So 'first layer (L0)' > 'second layer (L1)'.
And I think many infomation about sector is very useful.

In beta 6, angle cells are removed from the list.
I think it's good, impossible to select the cell which should not be selected is very helpful.

I have two question, please help me.
(1)I think the yellow cell means V/c-ID=?/1(Cell-ID=1).
But the first cell of list is not yellow, in spite of Cell-ID=1.
(2)Does the yellow cell means to be recommended to select ?
But in some of original LayerBreakCell is Cell-ID=2.

r0lZ
13th June 2005, 17:40
The yellow cells are those PGCs coming just after a VOB ID change. But I highlight them ONLY if there is one and only one VOB ID change.
Although not required, the VOB ID change at the layer break with several authoring programs. Therefore, if there is only one change, it's a good indication that the original layer break was at this position. But, unfortunately, it's not certain. The Cell ID doesn't matter.

Cells highlighted in blue are cells with a seamless discontinuity. If the layer break was not automatically removed when you ripped the DVD, a blue cell will likely indicate the original position of the layer break.
Also, if you want to burn the DVD more than once, the cell you have selected the first time will be highlighted in blue.

The first cell of a PGC is always highlighted in green, as it is the best candidate for the layer break, since you will not notice the delay. But most of the time, the first cell of the main title is outside the valid range.

Note that the first cell of a PGC should also have the seamless flag off, and may also be at a VOB ID change, but I can't highlight the same cell in green, blue and yellow. Green has precedence over blue, and blue has precedence over yellow.

Tobii
13th June 2005, 18:50
Beta 5...

In the Burn DVD window, the burning speed: 2.4x is twice availably.
Look on the snapshot, please. Can you confirm it?

http://img73.echo.cx/img73/7205/dlburndialog1rz.th.png (http://img73.echo.cx/my.php?image=dlburndialog1rz.png)

r0lZ
13th June 2005, 19:19
In the Burn DVD window, the burning speed: 2.4x is twice availably.
Look on the snapshot, please. Can you confirm it?
Yes, it's because DVD Decrypter needs 2.4 or 2,4, depending on your regional and language options (in Windows control panel). If your decimal symbol option is set to the coma and the digit grouping symbol to the dot (like for french), you need to select 2,4x, else you need 2.4x. I don't know how to check these options from Tcl/Tk, so the two numbers are present.

Tobii
13th June 2005, 20:23
Thanks for the fast response, is no actual problem. Have the DL DVD burned and runs.
Don't think far about it.
I have made another test to the beta 5 and I have found a problem.
I send a mail, with more details.

blutach
14th June 2005, 04:51
See attached. Original LB was cell 16. I selected 13 (the first one possible). Seamless flag changed in 13 but not 16. Am I missing something?

http://img113.echo.cx/img113/3605/untitled8zf.png (http://www.imageshack.us)


EDIT: I guess I need to click seamless cell on the original LB. I think this should be done automatically.

Regards

blutach
14th June 2005, 06:41
Suggestion:

Have a button in the burn dialog that says DVD+R/DVD-R and adjust sectors accordingly. At the moment, you are using the -R maximum sectors, whereas most folks would, at this time be using +Rs. Give them the choice, yes? (I know it's only 25k per layer). This could also be used in burning DVD-5s.

Regards

blutach
14th June 2005, 08:13
@r0lZ

My tests show a 318 sector problem - see your email

Regards

r0lZ
14th June 2005, 11:04
EDIT: I guess I need to click seamless cell on the original LB. I think this should be done automatically. I don't want to do that automatically, because there are many reasons to have a seamless discontunuity in some cells, and it's very difficult to check them all. Also, searching for all occurences of a possible layer break is not an easy work, but I have a macro to do that in my todo list...

r0lZ
14th June 2005, 11:08
Suggestion:

Have a button in the burn dialog that says DVD+R/DVD-R and adjust sectors accordingly. At the moment, you are using the -R maximum sectors, whereas most folks would, at this time be using +Rs. Give them the choice, yes? (I know it's only 25k per layer). This could also be used in burning DVD-5s.

RegardsDo you know exactly how many sectors are supposed to be in a DVD5-R and DVD5+R?
Unfortunately, it depends of the manufacturer. I've even found Commodore DVD-Rs that were largely smaller than the size I use in PgcEdit!

frank
14th June 2005, 13:56
What are a few MByte more related to 8000??! Burning errors increase to the outer radius of dvd!
Look at my test of DVD+R DL media type PHILIPS-CD2-00.
Burned with LG Electronics GSA-4163B DVD+R/+R DL/+RW/-R/-RW/-RAM 16/4/8/16/6/5x.
http://img28.echo.cx/img28/7959/dvdrphilips4x8tt.png (http://www.imageshack.us)
The highest measured errors are around the Layer Break on L0 and L1 (in the middle). And they are much higher than the manufacturers say. That's the truth.
PI (Parity Inner): No larger areas on the disc should exceed 280 PI errors.
PO (Parity Outer): No larger areas on the disc should exceed 32 PO (actually PI uncorrectable, PIF) errors.

It's not recommended to use the maximum capacity!

blutach
14th June 2005, 14:17
@frank - I know they do, but still the good media (e.g Verbatim) can be burned. But those graphs do indicate a burn which is well out of ECMA spec. I wonder whether better media exists?

I guess with a DL, where space is not a real constraint, you could leave 10 Mb or so, but you also need to be able to preserve the original LB which may very well be set right at the edge (it is technically possible, yes?)

@r0lZ - I am talking about DL media too, not just DVD-5. My understanding is that DVD+R DL is 2,086,912 sectors, which is about 12,500 sectors more than a DVD-R DL (which is what is programmed in to PgcEdit Beta5). Am I incorrect?

And for DVD-5, a -R is supposed to be 4,488.0625Mb while a +R is supposed to be 4482.625Mb (and I can confirm that my Riteks +R03 have burned right up to this).

Regards

jinjin_jp
14th June 2005, 14:46
The yellow cells are those PGCs coming just after a VOB ID change. But I highlight them ONLY if there is one and only one VOB ID change.
Although not required, the VOB ID change at the layer break with several authoring programs. Therefore, if there is only one change, it's a good indication that the original layer break was at this position. But, unfortunately, it's not certain. The Cell ID doesn't matter.

C:\DVD_Program\image.jpg...<EDIT>sorry, I can't use this well.
I think that the CELL which changes VOB-ID has CELL-ID=1,
(like blow, V/C-ID=61,62,63,64,65,66,67/1)
and CELL-ID=over1(like blow, V/C-ID=61,66,67/1) not highlighted yullow.
Is it misunderstanding?

And I think first three cells of the below list which V/C-ID=61/1 are <EDIT>yellow highlighted, because CELL-ID=1.
Is it misunderstanding?

frank
14th June 2005, 14:54
..but you also need to be able to preserve the original LB..No. I never had a problem on setting new Layer Breaks (if they are in right position)!
When using PgcEdit you stripped out unwanted content. The iso size is much lower than the original, and the LB is going to lower values. It's ok.

Much more problems caused by STC discontinuities (most visible on changed VOB IDs)! At this point the timer is starting new with 0, and that disturbes the hardware buffers. Usually that cell is marked as non-seamless = LB. The last I've seen was in Braveheart.
If you don't remux that stream then the STC discontinuity stays, the player remains stuttering regardless of LB or not LB.

r0lZ
14th June 2005, 15:01
@Frank: You're right. Whenever possible, it's better to avoid burning near the outer edge. But, as explained by blutach, it's not a reason to prohibit it! Anyway, it is for that reason that I have added the Optimal LB Position value in the GUI.

@blutach: I am not an expert on DVD sizes. I thought that DVD-R DL were still not available!
Anyway, I can add an option in the Burn setup to select DVD-R or DVD+R. Are you sure of the sizes?

r0lZ
14th June 2005, 15:07
I think that the CELL which changes VOB-ID has CELL-ID=1Normally, it's the case. But sometimes, it is not. I've seen some DVDs with the VOB/Cell IDs not sorted in incremental order. (It was the case after a processing with VobBlanker v1.)

And I think first three cells of the below list which V/C-ID=61/1 are green highlighted.
Is it misunderstanding?I can't see the image, but remember that green cells are used only for the first PGC cell. The PGC cell is not directly related to the VOB/Cell ID.

frank
14th June 2005, 15:08
@rOlZ
Do you really want to make an option for every dvd manufacturer?
Happy coding! :) ...and support...

r0lZ
14th June 2005, 15:14
No. I never had a problem on setting new Layer Breaks (if they are in right position)!
When using PgcEdit you stripped out unwanted content. The iso size is much lower than the original, and the LB is going to lower values. It's ok.Of course, you can. But most of the time, you will keep the original LB, because it is usualy at a place where you don't notice it too much (ie, on an almost still image, without too many sound.)

Much more problems caused by STC discontinuities (most visible on changed VOB IDs)! At this point the timer is starting new with 0, and that disturbes the hardware buffers. Usually that cell is marked as non-seamless = LB. The last I've seen was in Braveheart.
If you don't remux that stream then the STC discontinuity stays, the player remains stuttering regardless of LB or not LB.I don't think a STC discontinuity must be flagged as non seamless. But when the VOB ID change, the cell must theorically have the STC discontinuity flag. And I think you may set the layer break on any cell, if it is non-seamless. The STC discontinuity is therefore another problem, not directly related to the layer break.

r0lZ
14th June 2005, 15:17
@rOlZ
Do you really want to make an option for every dvd manufacturer?
Happy coding! :)No!!! Just a toggle DVD-R/DVD+R. It's ennoying if PgcEdit forces the user to burn a DL when a single layer DVD+R is sufficient.

jinjin_jp
14th June 2005, 15:25
Normally, it's the case. But sometimes, it is not. I've seen some DVDs with the VOB/Cell IDs not sorted in incremental order. (It was the case after a processing with VobBlanker v1.)
I understand, I've surely seen DVD which is not incremental order.

I can't see the image, but remember that green cells are used only for the first PGC cell. The PGC cell is not directly related to the VOB/Cell ID.
I'm sorry to misspell yellow to green.
But I understand to not yellow by above comment , because previous V/C-ID is unkown.

Thanks very much.

blutach
14th June 2005, 15:39
@Frank: You're right. Whenever possible, it's better to avoid burning near the outer edge. But, as explained by blutach, it's not a reason to prohibit it! Anyway, it is for that reason that I have added the Optimal LB Position value in the GUI.

@blutach: I am not an expert on DVD sizes. I thought that DVD-R DL were still not available!
Anyway, I can add an option in the Burn setup to select DVD-R or DVD+R. Are you sure of the sizes?I am dead set sure on the sizes of the DVD-5s r0lZ. As for the 9s, someone else can confirm please? -Rs have only just become available (like last 2 weeks or so).

Regards

frank
14th June 2005, 15:43
But most of the time, you will keep the original LB, because it is usually at a place where you don't notice it too much It's a pity that there are no DL RW media for testing.
Believe me, all my players read the sectors continuous around the LB. You don't notice anything! The only problem was STC discontinuity.
I don't think a STC discontinuity must be flagged as non seamless.Right! And right, it is another problem, not related to the layer break. But since STC disc. often includes the LB as in Braveheart many users believe the LB caused the problem.

blutach
14th June 2005, 15:50
@frank and others - OAM: Did you get a 318 sector difference between what PgcEdit reported and the total sector sizes on layer 0? r0lZ thinks this might be due to the mkisofs overhead. If not, then there are times when L0 may be less than L1 (bad!) Also, when you had the LB at the same position (with no change in the disk), was the offset the same as in the original (not that it needs to be, but mine were not)?

It is late here, but I will do more tests tomorrow.

Regards