Burning DL media with PgcEdit [Archive]

frank

31st May 2005, 20:15

I'm very happy, with the help of rOlZ we CAN implement the DL burning function into PgcEdit - THE BEST DVD EDITOR! :)If it is possible to add this feature in PgcEdit, I will be happy to do it.Some information about Pre-mastering LB you can find here http://www.mediachance.com/dvdlab/Helppro/layerbreak.htm
and at GEAR homepage.
Attention! The infos about DVD+R DL from mediachance and the LB calculation from GEAR are wrong.
I'm successful working with Philips DVD+R DL media.

The Rules
The file system layouter has to make sure

1. that L0 >= L1 or L0 > 1/2 the total iso sectors
L1 has a spiral track in the OPPOSITE direction of L0. (OTP = opposite track path).
This prevents the laser on L1 from acrossing the inner radius of the DVD.

Lead-out is padded (L1=L0) by the burning application for a continuous smooth read-out, so the reading laser on L0 has fully the same reflexion conditions.
DVDdecrypter makes it right!!

2. that the Layer Break (LB) aligned on cell boundary and at DVD ECC block boundary of 32KB. Every 16. block is an ECC control block.
-> LB address = cell address evenly divisible by 16.

Case 1: ic/2 <= LB <= dvd/2
ic = iso compilation size
L1 is padded by DVDD until L0 = L1.

Case 2: ic - dvd/2 <= LB <= ic/2
L0 is padded by PgcEdit to move LB lower than ic/2.
p = padding sectors

Comparing L0 with L1 we get
p + LB = ic - LB -> p = ic - 2 LB
p + LB <= dvd/2

The real Layer Break LB' in that case
LB' = L0 = p + LB = ic - LB

LB' has to be aligned according rule 2.

The procedure for PgcEdit

1. Set Layer Break Point in PGC Editor manually.
Search for a good cell with the help of preview.
Look for a chapter point.
LBcell = Entry VOBU sector > 1/2 total sectors
Note that LBcell refers to the start sector of vts title Vobs. (Fully mistake in GEAR!!! They refer to menu vob)

2. Make iso file. Launch ISObuster and look for the start LBA of the VTS title (point A) that includes the LBcell,
or PgcEdit: Calculate point A according to the ISO layout.
LB = A + LBcell

3. Calculate the file shift
Rule 2: x = LB/16

Example:
When we get x = 182543.3125, which is not an even number, then
we find that we are 0.3125 x 16 = 5 sectors past the start of an ECC block.
We have to shift the LB to the starting sector of an ECC block.
shift = 16 - 5 = 11.

4. To move the LB we need to move all of the files in the ISO by shift = 11.
But, hehePgcEdit increases the Last Sector of VMG/VTS field (at offset 0x0C in each IFO file). MKISOFS then places the data so that the next file starts at the right offset. Then PgcEdit has to fill field 0x0C of VIDEO_TS.IFO with shift added (but not in the bup, that would double the shift). Current mkisofs -dvd-video has no option to shift the starting sector of filesystem.

Create ISO.
We can test with ISObuster: All LBA starting from VIDEO_TS.VOB or VIDEO_TS.BUP have the shift added.

5. PgcEdit sets the Layer Break LB (sectors in L0) in DVDdecrypter ISO write mode.

6. For compatibility change Book Type in DVDdecrypter to DVD-ROM for DL media.

7. Burn ISO.

:)

Regards
frank

FilipeAmadeuO

31st May 2005, 21:04

That´s a nice guide.
But it would be great if PGCEdit sugested an layer break point and then created the iso file with the mds for dvddecrypter burning.
That would be a very nice feature.

r0lZ

1st June 2005, 10:56

I will see what I can do.
But I will need some other informations.

The first obscure point is the exact calculation of the alignment offset. Do I have to take into account the header added by MKISOFS? The ISO generated by MKISOFS is not the same length than images of the same DVD generated by other programs. Is it something I have to take into account?

Then PgcEdit has to fill field 0x0C of VIDEO_TS.IFO with shift added (but not in the bup, that would double the shift).I'm not sure you can put another value in the BUP file. Normally, the BUP file must be an exact copy of the IFO file. I think that his place on the disc do not matter, as the positions are probably calculated relative to the place of the IFO. Someone can confirm this point?

What is the exact capacity of a DL DVD? Is it a difference in capacity between a +R and a -R?

But it would be great if PGCEdit sugested an layer break point and then created the iso file with the mds for dvddecrypter burning.It would be great, right. :)
It should be possible to calculate the first and last cell where the LB can be placed, and also the 'best fit' one (the cell which divide the DVD in 2 almost equal parts).
I don't know the format of the MDS file for DVDD, but I suppose that it's not verry hard to generate this file automatically.

blutach

1st June 2005, 11:27

If I am not mistaken ImgTools Classic has recently come out with a new version (0.91.5) which has DL ISO making capabilities.

Certainly, DVD Decrypter can position the LB by just having the user nominate how many sectors he wants in layer 0.

Regards

FilipeAmadeuO

1st June 2005, 12:15

r0lZ

1st June 2005, 12:33

Yes, but it's not so simple.
I have still some questions.

How to deal with DVD-ROM files? Are they added at the beginning of the compilation, on L0, or at the end, on L1?

Is it possible to place the LB in a menu domain? (I suppose so.)

Reused cells might be a big problem. Is it legal to have, say, a cell on L0, if this cell is also called from another PGC, after (or before) some cells on L1?

blutach

1st June 2005, 14:51

@rolz - DVD_ROMs are definitely at the end on L1.

I think the LB can be in a menu, in fact, that might be preferable. Of course, the way most movies are organised, the LB is dead smack in the middle of the flick. But in episodic DVDs, there's no resaon, AFAIK, tat it can't be at the start of an episode.

As for re-used cells, good question! You wouldn't want the pause every time, would you?

Regards

blutach

1st June 2005, 14:53

But using ImgTools Classic for creating the ISO, the IFO file is not modified for generating the layer break in the exact point that it will be.
The way to do it it by generating an ISO file and the MDS and burning with DVD Decrypter.

It would be great is PGCEdit would do itIf you have an ISO, DVD Decrypter can generate the MDS, with the required LB info.

@r0lZ - perhaps an email to LUK! may be in order?

Regards

FilipeAmadeuO

1st June 2005, 15:36

DVD Decrypter can generate an MDS file but it do not uses the layerbreak.
It simply divides the dvd into two parts (i think is how it work)

frank

1st June 2005, 18:07

Do I have to take into account the header added by MKISOFS?Yes, but it's already included at point A. See procedure section 2:
Calculate point A according to the ISO layout, or we have to read it from a first iso creation (without the shift, as GEAR does).
LB = A + LBcell

We need the first loading address A0 of files to move, usually the LBA of VIDEO_TS.IFO. It depends from the ISO creating program and headers.
MKISOFS mostly sets A0 = 283. Because MKISOFS doesn't allow specifying that (GEAR does it, 640 + shift), we only can move files after VIDEO_TS.IFO using the tricky method.
I'm not sure you can put another value in the BUP file. Normally, the BUP file must be an exact copy of the IFO file. You are right. :thanks:
A more clean solution is to create a shifting VIDEO_TS.VOB, or blowing up an existing one by the requested shifting blocks (black frames).
The LBA of VIDEO_TS.BUP represents the start point A0, that has to be moved to
A1 = A0 + shift
Then all files after this point are moved by MKISOFS, and LB is in the right position.
LB = A + LBcell + shift
How to deal with DVD-ROM files? Are they added at the beginning of the compilation, on L0, or at the end, on L1?Ohh... I never used that. That files are used by the iso file system on a PC. Everyone who wants to backup all crappy features should use DVDdecrypter's iso read/write option, and automatic LB setting.
Is it possible to place the LB in a menu domain? (I suppose so.)Yes. Rule 2: Cell boundary... Why not a menu?
Is it legal to have, say, a cell on L0, if this cell is also called from another PGC, after (or before) some cells on L1?There is only ONE Layer Break with seamless playing at end of L0. All other laser movings through the layers produce a player stop because of head positioning. But they work.
What is the exact capacity of a DL DVD? Is it a difference in capacity between a +R and a -R?Not much.

Parameters of a DVD+R DL (shown by DVDdecrypter):
PHILIPS-CD2-00
Free sectors: 4 173 824 = 8 547 991 552 Bytes = 7.96 GBytes
Sectors in L0:2 086 912 --- 2 074 496 for DVD-R DL (GEAR)
First phys. sector of data area: 196 608
Last phys. sector in L0: 2 283 519

So we get common values for DVD+R DL and DVD-R DL.
Free sectors: 4 148 992
Sectors in L0:2 074 496

Attention! The capacity of a pressed DVD-ROM is greater than the capacity of a burned DVD+/-R DL.

r0lZ

6th June 2005, 22:10

5. PgcEdit sets the Layer Break LB (sectors in L0) in DVDdecrypter ISO write mode.
How should I do that? As you know, DVD Decrypter's site is closed, as well as the support forum. I don't find the info on how to pass the LB sector number to DVD Decrypter. Please help!

FilipeAmadeuO

6th June 2005, 22:35

It´s possible to define the layerbreak in DVD Decrypter (Settings - ISO Write mode - Layer Break).
The only thing that PGCEdit has to do is to tell in which sector is the layer break on the ISO.
About the MDS file i don´t know how is it done. Maybe someone else....

frank

8th June 2005, 17:59

DVD Decrypter's site is closed, as well as the support forum.Bad news.
I thought there are some CLI commands.
Let's google... or post in the burning forum?

BTW: I never used MDS files to burn the PgcEdit iso with DvdDecrypter.

r0lZ

8th June 2005, 18:29

I've found a description of the MDS file format here (http://developer.berlios.de/docman/display_doc.php?docid=840&group_id=2545). Unfortunately, seems it has no provision for the layer break information.

But I use now another method: the layer break value is written in the setups of DVD Decrypter directly in the registry. This way, everything is automatic, and you will be able to launch the ISO creation followed directly by the burn process from PgcEdit. (This method works only with the standalone executable, because the function to access the registry is not present in the source-only distribution of PgcEdit).

Anyway, thanks for your help.

FilipeAmadeuO

8th June 2005, 19:00

Excelent. Please post the new version, si we can try it.
Thanks for your excelent work

r0lZ

8th June 2005, 19:11

If you really wants it, here it is (http://www.videohelp.com/~r0lZ/pgcedit/beta/PgcEdit_winexe_0.6.0beta2.zip) . But take care. This beta has not been tested carefully. Don't blame me if you burn a coaster...

FilipeAmadeuO

8th June 2005, 21:27

How can it be done ? I´m trying Burn DVD/Create ISO options and it gives an error. Do PGCedit sugests and ideal layer break position or does change the IFO automaticaly ?

r0lZ

8th June 2005, 21:45

How can it be done ? I´m trying Burn DVD/Create ISO options and it gives an error. Do PGCedit sugests and ideal layer break position or does change the IFO automaticaly ?
What error did you got? Please report it here. It's important for me!

PgcEdit display all the cells that are within the layer break position range. It hilites in green the PGCs that are good candidates for the layer break. Dark green: Cell 1 of the PGC - it's the best choice. Light green: Cells that have already a non-seamless flag - It's probably the position of the original LB. You may preview the cells. You have to select the cell you want.

Then, the seamless flag is removed on the selected cell, and the DVD is saved, with an offset to store the VOB files so that the selected cell begins at an error correction bloc boundary. The layer break sector number is communicated to DVDD by the registry (if the option to burn the DVD with DVDD is ON), and, optionally, you have the option to copy this number in the clipboard.

Finally, the ISO is created, and the burn process is started.

FilipeAmadeuO

8th June 2005, 22:11

r0lZ

8th June 2005, 22:20

Strange. I have changed nothing in this part of the burn function.
This error comes from a safety check I do before generating the ISO. I ask mkisofs to report the size of the DVD. If it finds an error, it should say what's wrong. But in this case (SIGABRT), it crashes. Maybe there is something illegal in your DVD, or maybe you've found a bug in MKISOFS. I really don't know. Anyway, this error is not related to DL burning, since everything related to DL comes after this part.

Please try to burn another DVD, and let me know.

r0lZ

9th June 2005, 02:00

Beta 3 is here (http://www.videohelp.com/~r0lZ/pgcedit/beta/PgcEdit_winexe_0.6.0beta3.zip).

Fixes a bug in the calculation of the minimum valid sector for the layer break.

@FilipeAmadeuO: Still no idea for your problem with mkisofs.

r0lZ

9th June 2005, 10:31

"C:\DVD Copy\PGCEdit\bin\mkisofs.exe"I see now that you have moved mkisofs.exe in the bin subfolder of PgcEdit. OK. But you must also copy cygwin1.dll in the same folder, or mkisofs will not work. Perhaps it's the problem ?

blutach

9th June 2005, 12:52

Here is my log message :

mkisofs log for DVD "TEAM_AMERICA"
From: "C:\TEAM_AMERICA"
DVD-TEXT General Name: ""
Provider ID: ""
Number of VTS: 7
Output file: "C:\TEAM_AMERICA.ISO"
Volume label: "TEAM_AMERICA"

Error creating ISO:
child killed: SIGABRT

Test command was:

"C:\DVD Copy\PGCEdit\bin\mkisofs.exe" -dvd-video -print-size -V "TEAM_AMERICA" -p "PgcEdit" -m "PgcEdit_backup*" -m "MenuShrinkBackup*" -m "VobBlanker_backup*" -m "Copy of *" "C:\TEAM_AMERICA"@r0lZ - this error seems similar to the one I emailed you about a week ago. The rountine doesn't even start. I did not get that child killed Sigabrt message though.

@filipe - try moving all the subfolders (PgcEdit_backup, VobBlanker_backup etc) out of the project folder and try again. Make sure you have also installed cygwin.dll

Regards

FilipeAmadeuO

9th June 2005, 14:12

I havent copied the cygwin.dll so it can be the problem. Gonna try tonight

frank

9th June 2005, 18:30

:D :D :D :thanks: to rOlZ
I'll test tonight.

FilipeAmadeuO

9th June 2005, 20:27

The creating of ISO works OK when i copied the cygwin.dll
Now i have to try to copy to a DVD+R DL.
Thank you very much.

frank

9th June 2005, 22:37

r0lZ

10th June 2005, 11:53

There is really an error in the minimum valid sector of beta 3.
But Layer Break calculation is OK. :)

I created an ISO and viewed with ISObuster the LBAs.

The total number of sectors in my ISO is 3 625 963, PgcEdit shows 3 626 104.
The difference = 141 sectors, but we are on the sure side, ok.The total numbers of sectors displayed in the GUI is the compilation size, ie. the number of sectors without the padding sectors added to align the layer break cell. It should be the reason of the difference. I will verify that point.

[EDIT:] Obviously, I am wrong, since the size displayed by PgcEdit is greater than the actual size of the ISO. Strange...
Did you checked the 32K gap option before burning?

Then the min LB sector in ISO must be 3 626 104 / 2 = 1 813 052, PgcEdit shows 1 551 616.

That is too low.
You'll get a coaster because the returning laser on L1 acrosses the inner radius of the DVD! See rule 1.Well, your method was used in beta 2, but seems it's wrong.
It is theorically possible to fill the whole DVD-9, right? So, if you want, you can have L1 = whole disc size / 2, and L0 = compilation size - (whole disc size / 2), plus the padding sectors. In your case, this is:
L1 = 4 148 992 / 2 = 2 074 496
L0 = 3 626 104 - 2 074 496 = 1 551 608
Since 1 551 608 is not divisible by 16, the first valid sector is 1 551 616.

The gap is added just after VIDEO_TS.VOB (or between VIDEO_TS.IFO and VIDEO_TS.BUP if there is no VMGM VOB), and is therefore always on L0. The requirement of L0 >= L1 is therefore respected.

For example, if you select a cell that starts at original sector 1 551 616, the layer sizes are finally:
L1 = 2 074 496
L0 = 1 551 616 + 522 880 gap = 2 074 496
Both layers are equal.

Am I right?

jinjin_jp

10th June 2005, 16:29

Hello. I'm at first in this forum.

There is a information which is the method on the same concept(if could correct IFO before DVDDecrypter writing).
*ttp://yaki2fan.hp.infoseek.co.jp/dec_dl.html (Japanese)

The point is to correct ifo which controls the start sector of some file by IfoEdit ,for make appropriate blank sectors between appropriate some files.
(In this case, End sector of 3.Cell of VTS_02, is 2,074,138. and we want this value to 2,074,144.
correct IFO: VIDEO_TS.IFO,VMG_PTT_SRPT,Title_1:Title set starting sector +6. and the same Title_2,3,4...
So made 6 blank sectors after VIDEO_TS.BUP.)

flow of the method,
1.create ISO file by ImgToolClassic
2.mount by DaemonTools
3.examin LBA(sector) of each file by DVDDecrypter
4.asuume which VOB file has LayerBreakPoint
...in this case,
....LBA(sector) of the first file(VIDEO_TS.IFO) is 287(*1) to 290
....total file size is 8,252,915,712 bites, so 8,252,915,712/2,048 = 4,029,744(*2) sectors
....the sector of LayerBreakPoint would be over 2,015,015(*3)(=(287(*1)-1+4,029,744(*2))/2)
....LayerBreakPoint would be in VTS_02_1.VOB , because it's LBA(sector) is 1,912,532(*4) to 2,436,818
5.examin the end sector of each Cell of VTS_02_*.VOB by IfoEdit(VTS_C_ADT) or PgcEdit(Edit PGC)
6.asuume which Cell should the last of layer 0
...in this case,
....the start sector of VTS_02_1.VOB is 1,912,532(*4)
....the end sector of assumed Cell should be over 102,483(*5)(=2,015,015(*3)-1,912,532(*4))
....the last cell of layer 0 would be Cell 3 , because the end sector(VTS_C_ADT) of Cell 3 is 161,605(*6) (>102,483(*5))
7.correct Cell type for LayerBreaPoint by IfoEdit(VTS_PGCITI) or PgcEdit(Edit PGC)
...in this case,
....correct Cell type of Cell 4(=3+1) , 8 to 0 , or 10 to 2
8.calculate the value setted for DVDDecrypter(Sectors in L0)
...in this case,
....the end sector of Cell 3 of VTS_02_1.VOB is 2,074,138(*6)(=1,912,532(*4)+(161,605(*6)+1)
....sectors in L0(DVDDecrypter) must be over 2,074,138(*6) ,and divisible by 16
....so sectors in L0(DVDDecrypter) is 2,074,144(*7)(=129,634 x 16)
9.correct IFO for adjust the end sector of Cell 3 of VTS_02_1.VOB is 2,074,144(*7) ,by IfoEdit
...in this case,
....2,074,144(*7) - 2,074,138(*6) =6 sectors ,so make 6 blank sectors after VIDEO_TS.BUP
....correct IFO (VIDEO_TS.IFO,VMG_PTT_SRPT,Title_1:Title set starting sector) add 6 ,and the same Title_2,3,4...
10.confirm blank sectors by DVDDecrypter
...in this case,
....LBA(sector) of VIDEO_TS.BUP is 291 to 294
....LBA(sector) of VTS_01_0.IFO is 301 to 303 ,so created 6 blank sectors(295 to 300)
11.create ISO file by ImgToolClassic
12.write ISO file by DVDDecrypter(ISO Write Mode)

I hope if automatically calculated and corrected IFO like this.
But the problem is unknown the start sector of VIDEO_TS.IFO before create ISO at first.

I'm sorry not good at English.

frank

10th June 2005, 18:49

Did you checked the 32K gap option before burning?It was off.
BTW: What about to increase the 10k dummy VOBs in PgcEdit to 32k? Then we can forget this option, and any burning program does it right.
The gap is added just after VIDEO_TS.VOB (or between VIDEO_TS.IFO and VIDEO_TS.VOB if there is no VMGM VOB), and is therefore always on L0 :cool: That's our very cool way out!
I've read last year a request to MKISOFS (cdrtools) developer to add that loading sector shift option but he didn't, he had to release his rc without newer options. Maybe this option comes in the next time.
It is theorically possible to fill the whole DVD-9, right? So, if you want, you can have L1 = whole disc size / 2, and L0 = compilation size - (whole disc size / 2), plus the padding sectors.Oh no. That's not the way how DVDD writes DL media![deleted, see rOlZ below] L0 is the first layer that the laser writes towards the outer area. Usually DVD-VIDEO media have OTP tracks. At LB the laser breaks into L1 and RETURNS to the inner radius. Logical sector adresses (LBA) are linear counted until LB and then continue on L1 until max LBA is reached near the INNER radius! I think the LBA management is in that first physical data sectors of layers that we can't access. The iso file is written by DVDD without a gap. Imagine it's folded on LB. Padding sectors are added automaticly by DVDD to the Lead-out (on L1), so L0 = L1.
In beta 3 you would produce really L1 > L0 --> coaster.[deleted, see rOlZ below]
If you want filling up L0 then you can select the LB near L0max = 2 074 496. But what follows? L1 is much shorter and DVDD has to write more padding sectors until the laser reaches track 0 (begin) of DVD. Not to be recommended. Data errors are greater on the end of disk and a waste of time caused by padding.

Understand me?

r0lZ

10th June 2005, 20:24

In beta 3 you would produce really L1 > L0 --> coaster. No, since PgcEdit adds the padding sectors in the ISO, after VIDEO_TS.VOB, in L0.
The user must have the largest choice of cells to place the LB. If he choose the first sector in the list, the pad after VIDEO_TS.VOB will be huge, and L0 and L1 will be equal. OK, it's not recommended to write near the outer edge of the media, but it can be done, and PgcEdit must support that.

With this method, if the user selects a cell before <total compilation size> / 2, the two layers will be exactly equals in the ISO. Why could it not work?

Of course, if the cell is after <total compilation size> / 2, your method is used, and DVDD will pad L1 so that it is the same length than L0. Anyway, if he choose the last cell, the end of L0 (and therefore also the start of L1) will also be near the outer edge.

Note that I have changed the calculation method of the first valid sector when I saw an unmodified DVD with the original layer break position largely before the first valid sector. It was impossible to place it at the original location! (Thanks to Blutach for pointing me in this direction.)

frank

10th June 2005, 20:28

Ok, will test again. But I remember that I had no big gap after the TS.VOB.

I only generate the iso and view it. I must burn separately because of Book Type changing.

r0lZ

10th June 2005, 20:29

@jinjin_jp: Thanks for your help, and welcome to the forum.

I will try your method, but IMHO, it is equivalent to the method I have implemented, although the padding is placed elsewhere.

r0lZ

10th June 2005, 20:31

Ok, will test again. But I remember that I had no big gap after the TS.VOB.

I only generate the iso and view it. I must burn separately because of Book Type changing.I have to verify that also. Maybe the pad is wrong.

Burning the ISO separately should not be a problem.

frank

10th June 2005, 20:51

Hehe, you are right! Where was my math brain... :rolleyes:
I see, we can shift the LB < total compilation size / 2 by filling up L0.

I didn't select such lower cell but will test tonight.
Now I need a beer.

frank

10th June 2005, 23:06

:( Sorry, padding doesn't work in beta 3 for cell < <total compilation size> / 2

total compilation size 3 626 104 + 10 = 3 626 114
LB = L0 = 1 787 136

L1 = 1 838 978
DVDD outputs error L1 > L0!

Only shift pad = 10 is done.
No padding after VIDEO_TS.VOB, the total compilation size has NOT been increased.

The gap is added just after VIDEO_TS.VOB (or between VIDEO_TS.IFO and VIDEO_TS.VOB if there is no VMGM VOB)You mean between VIDEO_TS.IFO and VIDEO_TS.BUP, right?

FilipeAmadeuO

11th June 2005, 00:56

jinjin_jp

11th June 2005, 03:01

@jinjin_jp: Thanks for your help, and welcome to the forum.

I will try your method, but IMHO, it is equivalent to the method I have implemented, although the padding is placed elsewhere.

Thanks for comment to my post, and I'm very glad for receive reply from author of PgcEdit directly, I frecuently use PgcEdit very useful.

In above my post, the example is about create blank sectors between VIDEO_TS.BUP and VTS_01_0.IFO.
And there is another method which is about create blank sectors between VIDEO_TS.VOB and VIDEO_TS.BUP like PgcEdit, at '*ttp://yaki2fan.hp.infoseek.co.jp/dec_dl.html'.
...(a)correct IFO : VIDEO_TS.IFO , VMG_PTT_SRPT , Title_1:Title set starting sector and the same Title_2,3,4... , +6.
...(b)and add correct IFO :VIDEO_TS.IFO , VMGM_MAT . Last Sector of VMG , +6.
So made 6 blank sectors after VIDEO_TS.VOB.

I think the meaning of each IFO correction.
(a)the start sector of VTS_01_0.IFO ,when the start sector of VIDEO_TS.IFO is 0.
(b)the end sector of VIDEO_TS.BUP ,when the start sector of VIDEO_TS.IFO is 0.

And more,we will be able to create after another file by correct IFO.(but I've not confirmed actually)
(1)VIDEO_TS.IFO , VMGM_MAT . Last Sector of VMG ,
.....which means the last sector of VIDEO_TS.BUP ,when the start sector of VIDEO_TS.IFO is 0.
(2)VIDEO_TS.IFO , VMGM_MAT . Last Sector of VMGI ,
.....which means the last sector of VIDEO_TS.IFO ,when the start sector of VIDEO_TS.IFO is 0.
(3)VIDEO_TS.IFO , VMG_PTT_SRPT , Title_*:Title set starting sector (VTS_** icludes Title_*) ,
.....which means the start sector of VTS_**_0.IFO ,when the start sector of VIDEO_TS.IFO is 0.
(4)VTS_**_0.IFO , VTSI_MAT , Last Sector of VTS ,
.....which means the last sector of VTS_**_0.BUP ,when the start sector of VTS_**_0.IFO is 0.
(5)VTS_**_0.IFO , VTSI_MAT , Last Sector of VTSI ,
.....which means the last sector of VTS_**_0.IFO ,when the start sector of VTS_**_0.IFO is 0.
(6)VTS_**_0.IFO , VTSI_MAT , Start of VTSM_VOBS ,
.....which means the start sector of VTS_**_0.VOB ,when the start sector of VTS_**_0.IFO is 0.
(7)VTS_**_0.IFO , VTSI_MAT , Start of VTSTT_VOBS ,
.....which means the start sector of VTS_**_1.VOB ,when the start sector of VTS_**_0.IFO is 0.

But I wonder one thing about (6).
In the case the size of VTS_**_0.VOB is 0KB ,the value(6) of original IFO(for example Matrix 1, Time Machine, A.I.) is 0.
After GetVTS by IfoEdit ,this value change to the size(sector) of VTS_**_0.IFO (I remenber the same about PgcEdit).
the other hand after CorrectDVDsectors by DVDFab(=DVDToolbox),this value doesn't change and same as original .
Is which right? Does anyone have information about this?

I'm sorry not good at English.

r0lZ

11th June 2005, 03:27

:( Sorry, padding doesn't work in beta 3 for cell < <total compilation size> / 2

total compilation size 3 626 104 + 10 = 3 626 114
LB = L0 = 1 787 136

L1 = 1 838 978
DVDD outputs error L1 > L0!

Only shift pad = 10 is done.
No padding after VIDEO_TS.VOB, the total compilation size has NOT been increased.

You mean between VIDEO_TS.IFO and VIDEO_TS.BUP, right?I know. I am currently working on this bug. But it's late, here, ane next beta will be for tomorrow.

And, yes, I mean VIDEO_TS.BUP. (error fixed in previous post)

r0lZ

11th June 2005, 03:41

Has anyone tried RecordNow 7.3 ?
It inserts the layerbreak automaticaly and it inserts Padding sectors automaticly to the end of DVD on L1, so L0 = L1.
Also i think the best way is to sugest the ideal layerbreak place, so LO is bigger and very close to L1.The good point for PgcEdit is that it will NOT insert the LB automatically: you have the choice of where to put it, with preview.

The layer break should effectively be placed near the middle of the compilation, but there are cases where a better place can be found.
In beta 4, PgcEdit sets the default layer break like this:
- If a cell 1 of any PGC exists in the valid range, it is selected as it's the best choice, since the LB will not be noticed.
- Else, if there is already a non-seamless flag on a cell, it is selected, as it's probably the original layer break location, or the one that has been set previously by the user.
- Else, if the VOB ID change once (and only once), then the first cell with the new VOB ID is selected, as a change in VOB ID often indicate the location of the original layer break.
- Else, the cell that is near the middle of the compilation is selected. Note that this cell do not need to be after the middle, as explained above.

In fact, it's a little bit more complicated, because a good cell can be reused in another PGC, and not be a good one in that PGC. But it's the idea.

r0lZ

11th June 2005, 03:55

@jinjin_jp: Sorry, I don't understand.
Do you mean that the value of Start of VTSM_VOBS in VTSI_MAT is wrong if the VOB file is empty? I don't think so.

jinjin_jp

11th June 2005, 06:05

@jinjin_jp: Sorry, I don't understand.
Do you mean that the value of Start of VTSM_VOBS in VTSI_MAT is wrong if the VOB file is empty? I don't think so.

Sorry, I can't judge wrong or not.
But I suppose it's wrong from my experience following.

2 or 3 years ago, I found some of DVD can't play normally by PC player after getVTS by IfoEdit0.95, but no problem before getVTS.
Common point is to have 0KB VTS_**_0.VOB.(these DVD are Matrix 1, Time Machine, A.I.)
..Matrix 1(VTS_01 and 03), Time Machine(VTS_01), A.I.(VTS_01 and 03) are 0KB.
And about Matrix 1,main menu and main movie in VTS_02 can played normally, but when jump from menu to extras in VTS_01 or 03,display is disappeared.
The other hand, getVTS(CorrectDVDsectors) by DVDFab(=DVDToolbox) has no problem,
and when delete 0KB VTS_**_0.VOB, there is no problem, too.
Compare IFO, DVDFab(CorrectDVDsectors) is same as original, and getVTS(IfoEdit) is changed.

But now I am cofused.
Bcause when IfoEdit0.96 is released, I tried the same test.
Result was, IFO is changed, but no problem play by PC player.
So reinstall IfoEdit0.95 and tested, and results was no problem play by PC player.
Different from previous test results, I think somethig change except for IFO in my PC, but I can't find out.

Sorry not for usefull informetion.

FilipeAmadeuO

11th June 2005, 10:16

jinjin_jp - That problem is a weel known bug of Ifoedit. The best way is to delete the 0Kb file and do Get VTS sectors again.

Rolz - Please do not forget that some VTS´s use repeated PGC´s. Sometime ago i backup Alien 3 - special edition and record now only created the layerbreak in the longest PGC. But there is another PGC in seamless brenching that uses a major part of the vob id´s. Please insert the layerbreak in every PGC with the select VOB ID and CELL ID.

jinjin_jp

11th June 2005, 10:28

jinjin_jp - That problem is a weel known bug of Ifoedit. The best way is to delete the 0Kb file and do Get VTS sectors again.

Thanks for the information.
I understand.

r0lZ

11th June 2005, 10:53

Rolz - Please do not forget that some VTS´s use repeated PGC´s. Sometime ago i backup Alien 3 - special edition and record now only created the layerbreak in the longest PGC. But there is another PGC in seamless brenching that uses a major part of the vob id´s. Please insert the layerbreak in every PGC with the select VOB ID and CELL ID.
That's correct, and PgcEdit handles this situation. I do most of the tests with Shrek 2, which has main movies cells reused in 2 or 3 PGCs. To test, you can also create a new Play All title, or clone the PGC. You will see that the seamless flag is cleared in all PGCs.

But take care. The current version do not remove the old layer break(s). When burning, if the original layer break is still present, it will (probably) be selected by default, but if you select another one, you will end up with two pauses instead of one.

r0lZ

11th June 2005, 10:57

@jinjin_jp: 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.

FilipeAmadeuO

11th June 2005, 11:02

Rolz - Why PGCEdit don´t remove the old layer break ? Can you include in the layerbreak screen an option to remove old layerbreaks ?

jinjin_jp

11th June 2005, 11:24

@r01Z: It's good method and feature, thanks.
and also when transcording in full disc mode ,0KB VTS_**0.VOB files are deleted.(I tested about DVD2one and DVDShrink)

But there is a information about InterVideoDVDCopyPlatinum,it newly creates 0KB VTS_**0.VOB files .in spite of original doesn't have.
*ttp://www.geocities.jp/dvd_freedom/jikkenshitsu/page010.html
(bottom figure of the page)

frank

11th June 2005, 11:35

The good point for PgcEdit is that it will NOT insert the LB automatically: you have the choice of where to put it, with preview.Agree!!! And you can shift the LB to lower LBAs than other pay ware because PgcEdit can insert padding sectors in L0 before the LB. The features beat all known burning programs. :cool:
I can show you the damned coasters produced by Nero!

I'm not sure what iso creating program jinjin_jp used.
AFAIK there was a bug in earlier versions of MKISOFS in DVD-VIDEO iso with unused 0 byte menu vobs. MKISOFS created by Jörg Schilling is used in his CdrTools and in ImgToolClassic. Latest stable release of CdrTools is v2.01.

jinjin_jp

11th June 2005, 13:02

I'm not sure what iso creating program jinjin_jp used.
AFAIK there was a bug in earlier versions of MKISOFS in DVD-VIDEO iso with unused 0 byte menu vobs. MKISOFS created by Jörg Schilling is used in his CdrTools and in ImgToolClassic. Latest stable release of CdrTools is v2.01.

We can use ImgToolClassic to create ISO file which has blank sector according to IFO corrected.
(old version of ImgTool(Classic?) didn't create blank sectors ,in spite of IFO describe blank sectors.
I happened to find this change of feature in version 0.91.4 last summer.)

About unused 0 byte menu vobs, I've never tested with ImgToolClassic, but I think to avoid the problem by delete these files.

r0lZ

11th June 2005, 13: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, 16: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, 01: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, 11: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, 11: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, 11:17

Not always. See here (http://forum.doom9.org/showthread.php?p=666960#post666960).

FilipeAmadeuO

12th June 2005, 11:22

Ok. Thats another possible way :)
Thanks for your good job.

r0lZ

12th June 2005, 17: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, 23: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, 23: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

13th June 2005, 00: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

13th June 2005, 00: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, 01: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, 03: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, 03: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, 06: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, 11: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, 11: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, 13: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, 16: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, 16: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, 16: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, 16: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, 16: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, 16: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, 16: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, 16:54

I suspected as much. OK I do more testing on B5 tomorrow, but for now g'night. :)

Regards

jinjin_jp

13th June 2005, 17: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, 18: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, 19: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, 20: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, 21: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, 05: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, 07:41

blutach

14th June 2005, 09:13

@r0lZ

My tests show a 318 sector problem - see your email

Regards

r0lZ

14th June 2005, 12: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, 12: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, 14: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, 15: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, 15:46

frank

14th June 2005, 15: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, 16: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, 16: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, 16:08

@rOlZ
Do you really want to make an option for every dvd manufacturer?
Happy coding! :) ...and support...

r0lZ

14th June 2005, 16: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, 16: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, 16: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, 16:39

frank

14th June 2005, 16: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, 16: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

frank

14th June 2005, 17:00

I've got little differences in total sector size. IsoBuster reported a lower size than PgcEdit has computed.
L0 = LB setting is ok.

r0lZ

14th June 2005, 22:35

I see that. The size reported by PgcEdit is the size of the ISO file. The size reported by ISO Buster is the size of the Session 1. The difference is 1 sector. I'm not sure why there is a difference, but I think it doesn't matter.

Anyway, the ISO size seems right.

blutach

15th June 2005, 01:20

I did things a different way - r0lZ -perhaps you'd like to pass the emails that I sent to you onto frank. 1 sector was also the offset difference when I used the same LB cell. Doubt it's gunna be a problem, but the 318 sectors surely are.

Regards

frank

15th June 2005, 12:25

PgcEdit 0.6.0 beta 4

The difference is greater.
There is only one VTS with menu in my example.

Burn Dual layer DVD: Select Layer Break
tot sec 3626104 max 4148992
Lbmin 1551616 max 2074496 opt LB 1813052
LB =L0 1838992 offs 51866 L0 is equal to my manual calculations!
burn 3677984 iso 3677970For calculations of iso length we must include the padding sectors in L0. Setting to 2 * L0 = 3677984 is useless.

IsoBuster 1.7:
Name LBA
VIDEO_TS.IFO 285
VIDEO_TS.VOB 291
VIDEO_TS.BUP 52177
VTS_01_0.IFO 52183
VTS_01_0.VOB 52230
VTS_01_1.VOB 52508
...
VTS_01_0.BUP 3677772The iso length is calculated by adding the size of VTS_01_0.BUP = 47
Isobuster iso = 3677819 to burn.
[edit]
difference = 3677970 - 367819 = 151 sectors
The difference is equal to the Footer constant in procedure burn.tcl. Something is mismatched, I will look.

jinjin_jp

15th June 2005, 15:51

I found the interesting things about the case that LayerBreakCell is first cell of VTSM.
There is the informaion in the site
*ttp://yaki2fan.hp.infoseek.co.jp/606/606_1.htm

In the case that PgcEdit recommend 'VTSM_2,Cell_1' ,select and process it,
Layer Break Point is between VTS_02_0.IFO and VTS_02_0.VOB.(Figure 3 and 4)

On the other hand, in the case of process by RecordNow automatically(because it can't sellect cell) about the same DVD-Video,
Layer Break Point is between VTS_01_4.VOB and VTS_01_0.BUP.(Figure 1 and 2)

----------------------------------------------------------------------------
Another information
The following is the excellence of PgcEdit compare with RecordNow.
PgcEdit can select LayerBreak LBA which is less and more than T(total LBA of original)/2.
But RecordNow seems to have the restriction that LayerBreak LBA must be more than T/2,
so can't precess and indicate 'Error' if appropriate cell LBA is only less than T/2.

mpucoder

15th June 2005, 16:20

According to what I've read about where the layerbreak must go, RecordNow is correct, L0 MUST be larger than L1.

jinjin_jp

15th June 2005, 16:50

According to what I've read about where the layerbreak must go, RecordNow is correct, L0 MUST be larger than L1.
Sorry,what I want say is like followings,

If total sectors is 10,000. and permitted maxmum is 12,000,
(Ideal layer Break is 5,000 from start sector.)
and cell end sector is 4,500 and 5,500.
(1)The case selecting cell end sector is 4,500 :
By padding 1,000 sectors in L0, L0=4,500+1,000=5,500,L1=5,500, so L0=>L1.
(2)The case selecting cell end sector is 5,500 :
L0=5,500,L1=4,500, so L0=>L1, too.
(where ignore must be 16 multiple)
Both case are no problem(L0=>L1).

PgcEdit permits be (1) or (2).
RecordNow permits only (2), so if cell end sector is only 4,500 ,it can't process.

Sorry if target outskirt.

blutach

15th June 2005, 16:54

I must admit that my original view was the same as that of mpucoder. Even though it is highly unlikely to ever come to this, it might be prudent to program the rule as L0 > L1, not >=

Now, onto my 2nd set of tests.

The enclosed spreadsheet (image) shows, in all instances, the PgcEdit reported sectors in L0 is universally 307 sectors (this time) higher than the sum of the sectors in L0. This, I must put down to the mkisofs overhead. The difference between frank and I could be that I am using the latest mkisofs as obtained from coujo's site. Are you, frank, possibly using the version that came with ITC 0.91.4 (mine is 0.91.5), as this would explain the major descrepency (I also understand that a sector is allocated per file, so that could be why it was 318 yesterday and 307 today)?

http://img166.echo.cx/img166/4163/zzzzzzzzzzzzzzzz3vl.th.png (http://img166.echo.cx/my.php?image=zzzzzzzzzzzzzzzz3vl.png)

Regards

blutach

15th June 2005, 17:01

@jinjin_jp

Yes, you are right, with the proviso that you pad 1,001 now.

Do not be afraid to link to websites you think we will find useful and interesting - you can post http:// and not *ttp:// OK?

Regards

jinjin_jp

15th June 2005, 17:05

About sectors it seems to be different between LBA of and each file and ISO.

For example (which I tested)

Pgc Edit shows,
Total number of sectors in compilation : 3,956,511

DVDDecrypter(FileMode) shows LBA of each file.
First file : VIDEO_TS.IFO 323-333
Last file : VTS_10_0.BUP 3,956,351-3,956,359
So Total number of sectors : (3,956,359-323+1=)3,956,037 ::: not same as PgcEdit

DVDDecrypter(ISOMode) shows
Sectors : 3,956,511 ::: same as PgcEdit
Size : 8,102,934,528 (/2,48=3,956,511) ::: same as PgcEdit
First Physical Sectors of Data Area : 196,608
Last Physical Sectors of Data Area : 4,153,118
So Total number of sectors : (4,153,118-196,608+1=)3,956,511::: same as PgcEdit

jinjin_jp

15th June 2005, 17:16

@jinjin_jp
Do not be afraid to link to websites you think we will find useful and interesting - you can post http:// and not *ttp:// OK?

Thanks. I will do so from next time.

(In Japanese site that I often visit, it seems to be considered the manner not to link direct,because sometimes causes troubles.)

blutach

15th June 2005, 17:20

Understood. And thank you. Bedtime for us, I fear :) 1:20 am here.

Good night :)

Regards

blutach

15th June 2005, 17:40

r0lZ

15th June 2005, 19:45

According to what I've read about where the layerbreak must go, RecordNow is correct, L0 MUST be larger than L1.Do you mean that L0 cannot be equal to L1?

mpucoder

15th June 2005, 19:55

I'm trying to find (wish I had bookmarked) the site with the capacities and densities of various DVD. But what it comes down to is L1 is recorded at a lower density (larger pits). Also L0 of a DL DVD has less capacity than a DVD-5. This is why a dual layer has less capacity than a dual sided.

r0lZ

15th June 2005, 20:53

But what it comes down to is L1 is recorded at a lower density (larger pits).This means that L0 must be largely greather than L1, right? Ennoying. For now, I assume that both layers are the same size. I hope you will find the site...

BTW, I just changed my code to ensure that L0 is at least one sector greather than L1. But it may be not enough.

mpucoder

15th June 2005, 20:55

OK, didn't find that site, but I did find this (http://www.t10.org/ftp/t10/document.05/05-130r0.pdf) which gives the sector addressing. According to it each layer has a maximum of 2176768 sectors - the same.

And Now I get to contradict myself, sort of. L0 should be shorter or the same as L1. BUT this is the physical sectors we are talking about, not the space that DVD-Video uses. Prior to any data there are 1 or 2 file systems, directories, pointer, lead in, etc. You've got to account for that (as in the above example there are 196608 sectors before VIDEO_TS.IFO) when choosing the layer break, which means L0 ends up shorter.

r0lZ

15th June 2005, 23:33

If I understand correctly, this means that the video sectors on L0 must be > video sectors on L1, but physical sectors on L0 must be < physical sectors on L1. Seems strange, as this doesn't leave many sectors to place the layer break.

So, may I safely assume that if L0 > L1, the burning program (DVD Decrypter) will pad L1 with blank sectors? It is what I have assumed so far, and, apparently, it works fine.

FilipeAmadeuO

16th June 2005, 00:52

So, may I safely assume that if L0 > L1, the burning program (DVD Decrypter) will pad L1 with blank sectors? It is what I have assumed so far, and, apparently, it works fine.

I think is exactly like this.

jinjin_jp

16th June 2005, 14:11

@r01Z
If possible, I'd like to request the feature in future.
The feature is to show the LBA of start and last of each file, like the function of DVDDecrypter(FileMode ,Properties), extending the function to show the sector of layer break cell.

I've been usually enjoyed to test various software in various way than backup itself.
Above DVDDecrypter's method need to the process of createing ISO file. Especially I spent much time when tested of comfirming LBA and correcting IFO variously.

r0lZ

16th June 2005, 23:31

Difficult to do, because this function requires a new interface, for a small advantage. And don't forget that most of the starting sectors will change after the selection of the layer break point. Currently, PgcEdit computes the starting sector of the files only before opening the GUI, to be able to display the valid cells. I don't want to add the code to calculate them again.
Anyway, to test, it is easy to read the starting sector of the VOB in DVD Decrypter or ISO Buster, and add the starting VOBU sector of the cell. The result should be equal to the LB sector number.

jinjin_jp

16th June 2005, 23:59

Thanks. I understood its difficulty isn't balanced for its effect.

r0lZ

17th June 2005, 09:12

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).
You mean 2,086,912 * 2 = 4,173,824 for a DL, right?

So, according to you:

A DVD-5+R is 2,295,104 sectors, 4,482.625 Mb (it is what I use in PgcEdit)
A DVD-5-R is 2,297,888 sectors, 4,488.0625 Mb

A DVD-9+R is 4,173,824 sectors, 8,152 Mb
A DVD-9-R is 4,148,992 sectors, 8,103.5 Mb (it is what I use in PgcEdit)

Seems strange: the DVD-5-R is larger than +R, but the DVD-9-R is shorter than -R ! Also, I was almost sure that the DL size hardcoded in PgcEdit was the size for a +R, since the -R format was not available until now.

Unless I can have a somewhat official confirmation of these sizes, I will not change the sizes hardcoded in PgcEdit. For now, the sizes used are the smallest ones. I think it's better, for safety. And anyway, the difference is too small to justify a more complex interface.

[EDIT:] I have found this site (http://www.osta.org/technology/dvdqa/dvdqa6.htm) which gives 2,294,922 sectors for DVD-5-R, which is less than the size of a +R ! But it says that the number of sectors available on a -R is not specified by the standard, at the difference of the +R format. Another good reason to use the +R size only.

r0lZ

17th June 2005, 12:46

I changed my mind. I have added two editable fields in the Burn Setup dialog to enter the number of sectors of a single-layer DVD and a DL DVD. After all, the best way to know for sure how many sectors are available is to look at the DVD Decrypter's infos in ISO mode.

BTW, someone know if it is possible to burn mini-DVD-VIDEOs (ie DVD-Video files on a CD-R) with DVD Decrypter?

blutach

17th June 2005, 13:39

It is strange there is not one uniform info on disk sizes! :)

Regards

r0lZ

17th June 2005, 16:36

From the site (http://www.osta.org/technology/dvdqa/dvdqa6.htm) cited above:
DVD+R, DVD+RW and DVD-RAM specify the number of sectors available for user information (1.46 GB DVD+R/+RW 714,544 sectors, 4.7 GB DVD+R/+RW 2,295,104 sectors, 1.46 GB DVD-RAM 714,480 sectors, 2.6 GB DVD-RAM 1,218,960 sectors, 4.7 GB DVD-RAM 2,295,072 sectors) so disc capacity can be calculated by multiplying the user data area size by the number of disc sectors. For example, a 4.7 GB DVD+R disc: 2,048 bytes/sector x 2,295,104 sectors = 4,700,372,992 bytes. This rounds to roughly 4.7 GB (decimal notation).

DVD-R and DVD-RW, on the other hand, do not stipulate the number of sectors that are dedicated to user information but simply that a minimum capacity must be available on the disc. In the case of DVD-R (version 1.0) this is 3.95 (12 cm) and 1.23 (8 cm) billion bytes and for DVD-R (Authoring), DVD-R (General) and DVD-RW 4.7 (12 cm) and 1.46 (8 cm) billion bytes. Consequently, real world capacity can vary slightly among discs from different media manufacturers although many have informally settled on 2,298,496 sectors (4,707,319,808 bytes) for a DVD-R (General) 4.7 GB disc.Yet another superiority of + over - !

frank

17th June 2005, 18:56

Right done rOlZ!
Originally posted by blutach:
My understanding is that DVD+R DL is 2,086,912 sectors, which is about 12,500 sectors more than a DVD-R DL[Edit]
The ECMA currently released the +R DL specs ECMA-364.
Data Zone is specified to 2 x 2086912 sectors max.
= 8 547 991 552 Bytes max.

-R specifies the minimum capacity and tolerances, not sectors.
Example: DVD-5-R Data Zone has a defined physical start address (030000H = 196608) but the end is defined by r9 = 57.5-58 mm and min 4.7 billion bytes. No number of data sectors.
DVD-5-R has (4.7 billion / 2048) mod 16 sectors min.
= 2 294 928 sectors min. = 4 700 012 544 Bytes min.

I think in the the real world the worst case capacity is sufficient. Remember my posting about read errors above.

And for the last bit backup fans: The capacity of a pressed DVD-ROM is greater than any of DVD+/-R DL. You must strip out something if you want to use the last percent of media.

blutach

18th June 2005, 02:37

I think, this is getting to the point where the user must pop his blank in DVD Decrypter in ISO mode and see what it says about capacity and enter it in PgcEdit.

The only thing that seems set is the DVD+R SL.

Regards

jinjin_jp

19th June 2005, 04:19

I could get some information about sectors of blank media, which was examined by requesting the companion who is always communicating by the BBS in Japan to cooperate.

Its method is actually examinin the sectors shown by various software when insert blank media.
Now there is not +R/SL, but it may be possible to obtain,because requesting another companion.
[Later could Add about +R/SL, like below.]

The information of the results is below :
*common condition of almost test
(1)software :
......(s-1)DVD Decrypter, shown as Free sectors on ISO-Read.
......(s-2)DVDIdentifier,shown as Blank Disc Capacity.
......(s-3)RecordNow(7.31), shown as Disc Infomation?(actually in Japanese)
......(s-4)Nero CD-DVD Speed, shown as Disc Info.
......(s-5)B'z GOLD(5.55), shown as Disc Infomation?(actually in Japanese)
(3)media :
......(m-1)as -R/DL : Mitsubishi Chemical, 4x
......(m-2)as +R/DL : Mitsubishi Chemical, 2.4x
......(m-3)as -R/SL : Hitachi Maxell, 4x
......(m-4)as +R/SL : Mitsubishi Chemical, 8x
(2)Drive
......(d-1)Pioneer DVR-109
......(d-2)Pioneer A08 (when +R/SL, and part of -R/SL)

*Results
(1)-R/DL
......(s-1)4,171,712sectors
......(s-2)4,171,712sectors
......(s-3)4,171,712sectors
......(s-4)4,171,713sectors (=8,543,668,224byte, shown by byte not sector)
......(s-5)not corresponding
(2)+R/DL
......(s-1)4,173,824sectors
......(s-2)4,173,824sectors
......(s-3)4,173,824sectors
......(s-4)4,173,825sectors (=8,547,993,600byte, shown by byte not sector)
......(s-5)4,173,824sectors
(3)-R/SL
......(s-1)2,298,496sectors
......(s-2)2,298,496sectors
......(s-3)2,298,496sectors
......(s-4)2,297,889sectors(=4,706,076,672byte, shown by byte not sector)
......(s-5)2,298,496sectors
(4)+R/SL
......(s-1)2,295,104sectors
......(s-2)2,295,104sectors
......(s-3)2,295,104sectors
......(s-4)2,295,105sectors(=4,700,375,040byte, shown by byte not sector)
......(s-5)Not tested

Consider and compare with
each sectors of PgcEdit's setting data
(1)-R/DL : 4,148,992sectors (approx)
(2)+R/DL : 4,173,824sectors
(3)-R/SL : 2,297,888sectors (approx)
(4)+R/SL : 2,295,104sectors

(a)shown value of each media is same except for by Nero.
(b)value of +R/DL is same as PgcEdit's (except for by Nero). [4,173,824sectors]
(c)value of -R/DL is bigger than PgcEdit's. [4,171,712>4,148,992sectors]
(d)value of -R/SL is bigger than PgcEdit's. [2,298,496>2,297,888sectors]
...(d.2)specifically the value by Nero is almost same, difference is only +1. [2,297,889sectors]
...(d.3)and more another information exists. the value by DVD Decrypter(s-1) is completely same as PgcEdit's[2,297,888sectors], when drive is pioneer A08 and HL-DT-ST GMA-4020B.　There seems to be difference depending on drive.
(e)value of +R/SL is same as PgcEdit's (except for by Nero). [2,295,104sectors]
...(e.2)specifically the value by Nero is almost same, difference is only +1. [2,295,105sectors]. Its differences(+1) of each media are same except for -R/SL.

I hope to become help a little.

jinjin_jp

19th June 2005, 05:38

@r01Z
Thanks for great program and its improvement.

I tried beta 6 and 7, and confirmed that multiangle-cell aren't shown in the selection list of LayerBreakCell.
And I'd like to know what about interleave-cells because I think interleave is similar to multiangle, and tested using Matrix which involves interleave-cells in PGC of the game(white rabbit appears).
The result was these cells have been shown in the list.

Is whether correct interleave-cells to be 'shown' or 'not shown' in the list?
(I think 'shown' means there is no problem if selected.)

blutach

19th June 2005, 10:16

@jinjin_jp

Thank you for this great info - I would not trust the Nero CD Speed. Maybe Nero Info Tool, but this seems wrong because it is not a multiple of 16.

Regards

r0lZ

19th June 2005, 11:53

@jinjin_jp: Thanks for the info.
I am sure that the numbers of sectors on DVD-R are NOT constant. They depends on the DVD manufacturer. So, I will keep the actual numbers of sectors hardcoded in PgcEdit. Seems safer to use the minimal number of sectors. And, thrust me, there are some DVD-R that are even smaller (notably Commodore).

About interleaved cells: I will try Matrix, and remove the interleaved cells from the list as well. Thanks!

jinjin_jp

19th June 2005, 12:40

About interleaved cells: I will try Matrix, and remove the interleaved cells from the list as well.
Thanks.
When trying, it is necessary to change the DVD sectors for the purpose of the test, if not, interleaved cells are in the appropriate range of LayerBreak.

I am sure that the numbers of sectors on DVD-R are NOT constant. They depends on the DVD manufacturer. So, I will keep the actual numbers of sectors hardcoded in PgcEdit. Seems safer to use the minimal number of sectors. And, thrust me, there are some DVD-R that are even smaller (notably Commodore).
I think better to be safer, too.

And I've got the information about -R/DL burning from companion who is always communicating by the BBS in Japan.
It is in here (http://yaki2fan.hp.infoseek.co.jp/-r_dl/-r_dl.html).
Where are tried in three ways of -R/DL burning, and examined SectorSize of ISO-total/L0/L1, StartSector of FirstFile, FileSize(sector) of L0/L1.
And more, LayerBreak is between original cell or newly in the one, description of LayerBreak is or not. The temporary stop during replaying.

Common of three ways seems to
(1)L0 is 2,092,896 sectors.
(2)There seems not to be blank cells between files, but StartSector of the file is adjusted.

Different feature in each way seems to
(1)Record now : Burned　considering that file size of L0 and L1 is almost same and LayerBreak is between cell and cell. And the description of LayerBreak is appropriately added in IFO.　（And if not removed LayerBreak from original, LayerBreakCell is same as original.)
(2)Nero : Burned from approximately the first sector ignoring cell. So worst, LayerBreak is in the halfway position of cell and the description of LayerBreak could not be added in IFO appropriately.
(3)rest : Burned from the most first sector considering cell(LayerBreak is between cell and cell). And description of LayerBreak is appropriately added in IFO.
....And sector size of L1 is different between 3 ways.

[Sorry, blue letter is part later edited.]

r0lZ

19th June 2005, 13:03

I have verified my code, and it's true that the Interleaved flag was not checked. It is now. The interleaved cells of Matrix are not shown in the list anymore.

If you want to try: beta 9 (http://www.videohelp.com/~r0lZ/pgcedit/beta/PgcEdit_winexe_0.6.0beta9.zip).

frank

19th June 2005, 13:05

@rOlZ
I've found the difference of iso calculations PgcEdit - IsoBuster, and updated the values in my posting (#104 page before).
It seems there is an issue with the footer constant in procedure burn.tcl.
The values differ exactly by that 151 sectors.

How can I switch PgcEdit to config debug mode?
I want to see some more informations only showed in this mode.

jinjin_jp

19th June 2005, 13:12

r0lZ

19th June 2005, 19:20

@Frank: Right, PgcEdit assumes that the footer added by mkisofs is always 151 sectors long. This footer needs to be added to the compilation size.

How can I switch PgcEdit to config debug mode?
I want to see some more informations only showed in this mode.Control-Middle-Double-Click (!) on the PGC Selector drop-down menubutton (the one labelled "PGC") to open the console, and type set ::config(debug) 1The debug mode is saved with your options, so, to turn it off, you must set it back to 0. Leaving it on may slow down some routines.

Note that I have removed some of the infos availables in debug mode, but most of them are now visible in the GUI. I will remove all the infos in the final version, to be released soon. So, if you think there is still a problem, please check it and report it here as soon as possible. Thanks.

frank

19th June 2005, 20:53

Thanks for your hints, rOlZ :)

I never realized the added footage but now I look at my burned DVD and see the session size = 3677984 sectors (+151)! That's exactly what PgcEdit calculated as to burn (modulo 16).

I think the session size includes the Lead-out Zone (~150 sectors) that has to be written by the application. Since leadout does not count as data there is no need to add it. The Lead-out Zone has a reserved area on dvd (0.5...1 mm after Data Zone).
Now I haven't the specs here but I will look.

r0lZ

19th June 2005, 21:13

I'm not sure the 151 sectors are the lead-out, since when the burn is finished, DVD Decrypter adds a message about writing the lead-out.
However, I don't know for sure if the footer must be included in the compilation size, but I prefer to do so, to be safe. Anyway, loosing 151 sectors is not much.

frank

19th June 2005, 22:19

mkisofs doesn't know what burning program used. This lead-out footage increases the read out stability, and doesn't matter.
I looked into the 151 appended sectors: There are zeroes with a sector counter. After that dvd access is denied.

r0lZ

19th June 2005, 22:51

OK. But these sectors are in the ISO. It's a fact.
If I don't count them, and the user selects a LB that is before or just at the middle of the ISO, then, after the padding of L0, the second half (including the 151 sectors) will be larger than the first one. What will be the behaviour of DVDD in this case?

I think it's safer to count them. If DVDD is smart enough to disgard them, it will simply add 151 additional padding sectors in L1.

Of course, if you are sure that DVDD will drop the footer anyway, I may safely remove the 151 sectors from the count. In some rare cases, that may be sufficient to include one additional valid cell in the list. But are you really sure?

Also, the user may want to burn the ISO with another burner. And it's difficult to know how every burner will handle this case.

frank

19th June 2005, 23:22

Yes, yes you did it right! I see.

I now found it in mkisofs doc.
OPTION -pad
Pad the end of the whole image by 150 sectors (300 kB).
...
The padding is needed as many operating systems (e.g. Linux) implement read ahead bugs in their file system I/O. These bugs result in read errors on one or more files that are located at the end of a track. They are usually present when the CD is written in Track at Once mode or when the disk is written as mixed mode CD where an audio track follows the data track.

To avoid problems with I/O error on the last file on the file system, the -pad option has been made the default.You can switch off it with option -no-pad. I would do so.
Since DVD-ROMs don't have such footage, DVDD writes in SAO (side at once), and hardware players don't use a ISO file system.
[Edit]

r0lZ

19th June 2005, 23:37

Oh, yes, I remember this part of the mkisofs doc.
But I don't think I will remove the padding sectors, because I will probably implement the Burn DVD function under Linux and Mac as well (although it will probably be limited to the ISO creation.)
And remember is is possible to include DVD-ROM files in the compilation.
And there are some standalone players (able to show DivX movies) that are based on Linux Embedded. I have an old KISS player running Linux.

Also, I think that hardware players do use the UDF filesystem.

frank

20th June 2005, 19:24

Also, I think that hardware players do use the UDF filesystem. Sorry, a typo. :rolleyes: I know, hw players don't use ISO system, they use a subset of UDF 1.02. And mkisofs generates the UDF bridge format.

mkisofs is part of Linux cdrtools by Jörg Schilling. As you can see the options refer to CD (ISO 9660) not DVD, isn't it? VIDEO DVDs are not burned as TAO, or as mixed mode CD...
The 150 sectors prevent read errors on such (ISO) CDs on Linux.
But how does Linux refer to DVDs? I think Linux uses UDF drivers.
So the 150 sectors have no meaning in our case, pressed DVD-ROM also don't have such appendix.
I never heard that Linux freaks had problems with DVD playing on last file.

But you can let it be as it is, it doesn't matter.

blutach

21st June 2005, 00:07

Better leave what's workig and be safe IMHO.

And yes, (compliant) players always use 1.02 UDF. ISO could be used on older window$ based systems that have no native UDF reader - eg W98. So need that too. I haven't seen anyone who knows about these things, argue against the UDF1.02/ISO bridge (here they come now I bet :))

Regards

r0lZ

21st June 2005, 10:05

In beta 10 (http://www.videohelp.com/~r0lZ/pgcedit/beta/PgcEdit_winexe_0.6.0beta10.zip), I have removed the padding sectors. Seems some older versions of mkisofs don't have this option by default, and also, in v 2.01, the description of the -pad option differ when you type mkisofs -help: -pad Pad output to a multiple of 32k (default)
-no-pad Do not pad output to a multiple of 32kObviously, this is an old message. I think therefore that it is better to avoid this option.

Note that there is still one padding sector added at the end of the ISO. (Seems logical: the -pad option adds 150 sectors. But with this option ON, there are 151 padding sectors effectively added. So, with the -no-pad option, there is 1 remaining sector.)

BTW, in Beta 10, the creation of the ISO is supported under Linux, apparently without problem. But I cannot find a recent version of mkisofs for Mac OSX. V1.15a36 seems to be the last version available for Mac. But this version do not handle the gaps properly. Pitty. If somebody has a newer version of mkisofs for mac, please let me know.

I will add the mkisofs version number in the log, and specify that v2.01 or more must be used.

blutach

21st June 2005, 13:32

I think this version is available on coujo's site under ImgToolsClassic 0.91.5

Regards

r0lZ

21st June 2005, 14:16

Yes. It is the version that is downloaded if you click on the Download ImgTool Classic button in the Burn DVD Setup dialog.
But this version doesn't exists under Mac OSX yet.

r0lZ

21st June 2005, 14:23

Beta 11 (http://www.videohelp.com/~r0lZ/pgcedit/beta/PgcEdit_winexe_0.6.0beta11.zip) is available.

The main change is the Create ISO function, now available also under Linux. See this thread (http://forum.doom9.org/showthread.php?t=96194).

If you want to check beta 11 under Windows, download this version: PgcEdit_winexe_0.6.0beta11.zip (http://www.videohelp.com/~r0lZ/pgcedit/beta/PgcEdit_winexe_0.6.0beta11.zip).
Not much has changed under Windows, except that I have removed the 150 padding sectors added by default by mkisofs, and I have added a button to check the mkisofs version number in the Burn Setup dialog.

Tobii

21st June 2005, 20:04

r0lZ

I always get an applications error in the Burn DVD dialog.
The applications error comes in the Burn DVD dialog, if I click on OK.
I use the mkisofs.exe from the ImgToolsClassic 0.91.5
No applications error at beta 9 or 10.

http://img41.echo.cx/img41/7074/errorinpgcedit5gw.th.png (http://img41.echo.cx/my.php?image=errorinpgcedit5gw.png)

goonix

21st June 2005, 23:59

I don't get this error message, but mkisofs will be not started.
And I have to use the task manager to cancel pgcEdit.

goonix

jinjin_jp

22nd June 2005, 01:10

@r01Z
I had the same error.
When click 'ok' button in GUI"PgcEdit: Burn DVD", error message is shown which is same as post from Tobbi.
After click 'ok' button of error message, when click again 'ok' button in GUI"PgcEdit: Burn DVD", error message isn't shown anymore like post of goonix.
These aren't when previous version.

I use ImgToolClassic 0.91.5, and version check dialog shows below.
mkisofs 2.01x (i686-pc-cygwin)
You need v2.01 or more.

r0lZ

22nd June 2005, 08:10

OK. Thanks. Will fix that. Probably a stupid error.

r0lZ

22nd June 2005, 11:54

OK. Beta 12 is available.
The bug is fixed, and, thanks to Pucklock, the Create ISO function is now implemented also under Mac OSX.

Download PgcEdit_winexe_0.6.0beta12.zip (http://www.videohelp.com/~r0lZ/pgcedit/beta/PgcEdit_winexe_0.6.0beta12.zip).

Mac and Linux users: please see this thread (http://forum.doom9.org/showthread.php?t=96194). The download links are in the same thread.

@goonix: the problem you experienced is the same bug, but if you launch the burn via the toolbar icon, the error message is not displayed.

zacoz

22nd June 2005, 12:55

@r0lZ: I know that you get prompted for the location of DVD Decrypter, mkisofs etc the first time you use the create ISO / burn function in PgcEdit, however is there a way to bring up this dialog at a later date - ie if I wish to move the location of the relative applications ?

I encountered this previously and had to edit the registry (or was it an ini :confused: ) directly, as I couldn't find the option anywhere. Menu item to enable changes would be good.

Tobii

22nd June 2005, 13:11

@ zacoz

In the GUI of Burn DVD, there is "Setup" right above on the left.
You can call Burn DVD Setup for it any time with that and carrying out changes.

@ r0lZ

Thanks for new beta, now it works.

zacoz

22nd June 2005, 13:46

@Tobii: doh.....Maybe I need to get my contacts prescription checked. :thanks:

jinjin_jp

22nd June 2005, 14:11

@r01Z
Thanks. The error is fixed.

blutach

25th June 2005, 10:58

Results on beta 12 - physical test with a Verbatim DL on a 4163B.

100% perfect. Time for the release :)

@r0lZ - I hope I shall have more time next week to update the help file and the burning guide on the PgcEdit homepage. :) Again, congratulations!

Regards

frank

25th June 2005, 14:57

:) Same here.
It's a pleasure to see how things go on.

BTW FreeWrap 6.0 has been released. (UPX built in for 40% shorter exe)
Wrapping works, but in XP the PgcEdit main window gets only the FreeWrap icon.

r0lZ

25th June 2005, 15:13

About freeWrap: I know there is a version 6.0, but I have many problems with this release. The icon is not important, but there are other bugs. I will still use v5.61, until a better release comes out...

r0lZ

25th June 2005, 15:29

Beta 13 (http://www.videohelp.com/~r0lZ/pgcedit/beta/PgcEdit_winexe_0.6.0beta13.zip) is out.
Nothing important for the DL Burn function under Windows, but this beta fixes an important problem under Mac: The Finder stores ".DS_Store" hidden files in each folder that is opened interactively. These files are now removed from the compilation. In beta 12, these files were not excluded, thus messing up the VTS sectors, and the layer break position!

Also, I have just burned a DL, but I got a read error in the verify phase, just at the layer break position. The DVD hangs on all my players at that position. Probably a problem with the burner or the disc (Maxell), though. But I will wait some times before releasing the final version, to be sure...

frank

25th June 2005, 16:38

Seems that the 2nd layer doesn't work, because there is much less reflectivity.
Then the media in combination with the burner caused the coaster.
I don't know the quality of Maxell.

At this time DL media is an adventure :scared:

r0lZ

25th June 2005, 17:04

Right, but even the burner cannot read a few sectors after the LB. And one of my standalones is able to read L1, starting at chapter 10. But chapter 9 is not accessible. (The LB is at the beginning of chapter 9.) Strange!

blutach

26th June 2005, 07:20

Maybe try again with Verbatims r0lZ. They are seen to be the best right now. And slow the burn to 2.4x if you are not at this already.

Another test from me - this time with re-used cells. No problem in any titles. :)

I definitely like the ability to place the LB where I want to, given the way the video and audio are at the cell points.

This is a great leap forward r0lZ. Thanks a million to you and also to everyone here who contributed to its development, notably frank as well as jinjin_jp.

Regards

r0lZ

26th June 2005, 10:51

r0lZ

26th June 2005, 11:00

FilipeAmadeuO

26th June 2005, 11:52

Seems DVDD checks the ISO before burning it. As this operation takes some time for DL DVDs, I suppose that DVDD read the ISO to find the beginning of the LB cell, to be sure the LB sector is correct, and that the cell begins at the start of an ECC bloc. Someone can confirm that?
Also, what is the behaviour of DVDD is something is wrong with the LB sector or cell?

I think this happens because there is no MDS file. In the SL DVDS this file is not needed so DVDD do not check the ISO, thats because it´s so fast.
If we only can use the MDS file .....
No ones knows the information how to build it ?

blutach

26th June 2005, 13:12

Thanks.

Unfortunately, I can't find verbatim DL media here...

BTW, have you burned a DVD with a LB cell that was originaly before the middle of the compilation (i.e. a cell that needs a large amount of padding sectors in L0) ?Gee, that's unusual - they are the biggies in DL media.

I did one that needed 400,000 sectors, so I guess that's qualifies. Worked well.

Regards

blutach

26th June 2005, 13:15

I think this happens because there is no MDS file. In the SL DVDS this file is not needed so DVDD do not check the ISO, thats because it´s so fast.
If we only can use the MDS file .....
No ones knows the information how to build it ?I can confirm the MDS is definitely not needed.

PgcEdit's routine works by writing the LB sector manually in DVD Decrypter. When DVD Decrypter opens and before you start the burn, go to Tools - Settings - ISO write and see the Options (User Speficied). The correct number will already be there.

Regards

blutach

26th June 2005, 13:16

Seems DVDD checks the ISO before burning it. As this operation takes some time for DL DVDs, I suppose that DVDD read the ISO to find the beginning of the LB cell, to be sure the LB sector is correct, and that the cell begins at the start of an ECC bloc. Someone can confirm that?
Also, what is the behaviour of DVDD is something is wrong with the LB sector or cell?This is not what I have seen. It writes the lead in and gets on with the image. At the LB (user specified), it refocuses (you can't even tell this is happening) and writes L1.

It's a good idea to verify afterwards, too.

Regards

r0lZ

26th June 2005, 15:01

If we only can use the MDS file .....
No ones knows the information how to build it ?I've found this (partial) explanation (http://developer.berlios.de/docman/display_doc.php?docid=840&group_id=2545). But I can't see infos on how to specify the LB sector. Anyway, seems too complicated to implement MDS in PgcEdit. As blutach said, I've found a workaround: I write the LB sector number directly in the registry before launching DVDD.

jinjin_jp

26th June 2005, 15:25

@r01Z
I think another method may be necessary for -R/DL.
Because, like this test (http://yaki2fan.hp.infoseek.co.jp/-r_dl/-r_dl.html), L0 is 2,092,896 sectors and common in three ways of buning (Utility of Pioneer recorder, RecordNow, and Nero).
If it is legal and if want to set LayerBreak as this value, it is necessary to correct IFO and create ISO file manually like this way (http://yaki2fan.hp.infoseek.co.jp/-r_dl/dec_-dl.html).
How think about ?

r0lZ

26th June 2005, 15:54

I don't understand why another method should be needed for -R DL.
2,092,896 sectors is the maximum number of sectors in L0, right? But it should be possible to burn less sectors as well, as far as the ECC bloc boundary is respected.

I don't know japanese! So, I don't understand the method explained in the page pointed to by your link. But I'm pretty sure this method will NOT work if you have checked the 32K gap option in PgcEdit's options, because the offset in L0 is computed AFTER the 32K offset. So, the real offset is not the one imdicated in the GUI (it's the pad offset listed by mkisofs in his log.)

Could you try to explain why my method is not good, and why there is a different method for DL DVD+R and -R?

jinjin_jp

26th June 2005, 16:44

@r01Z
Sorry not to explain well, I'd like to try to explain for understanding easily, please wait for a while.

r0lZ

26th June 2005, 16:59

OK, seems I understand.
The sizes of L0 and L1 are not equal on DL DVD-Rs! Damn! :angry: I hate -Rs!
I will have to modify a lot of things in the method (and in the Setup GUI).

So, if L0 and L1 are not equal, I suppose that the computation of the valid cells and LB position is not based on the amount of data in L0 and L1, but instead must be based on the length of the track in physical distance from the beginning.
I need to know by which factor the data on L1 must be scaled so that I may know the amount of data to burn on both layers. So, if L0 = 2,092,896 sectors and L1 = 2,062,464 sectors, then one sector in L0 takes the same size than 2,092,896 / 2,062,464 = 1.0147551... sector in L1. Is it right? Seems so strange!

jinjin_jp

27th June 2005, 00:11

@r01Z
Now I noticed strange thing about calculation of sectors, so questions and confirms to the person who made that explanetion site.
Please wait for.

frank

27th June 2005, 11:21

Originally postet by rOlZ:
but even the burner cannot read a few sectors after the LB. And one of my standalones is able to read L1, starting at chapter 10. But chapter 9 is not accessible. (The LB is at the beginning of chapter 9.) Strange!
Yes, that's exactly the behaviour of bad media. See my test, burned with LG Electronics GSA-4163B:
http://img189.echo.cx/img189/7095/dvdrphilips4xagent9pp.png (http://www.imageshack.us)
The standard says that PI errors must not higher than 280, and PIF not higher than 32! The picture shows too much errors over a big area, but my old standalone plays it (yet...).
The outer radius around LB (in the middle) has the lowest quality and after LB is less reflectivity on L1 (chapter 9).

The KProbe2 test is no certified method but results are quite reliable. Reading at 4x has about 30 % higher values but saves time.

Originally posted by blutach:
I can confirm the MDS is definitely not needed.

PgcEdit's routine works by writing the LB sector manually in DVD Decrypter. When DVD Decrypter opens and before you start the burn, go to Tools - Settings - ISO write and see the Options (User Specified)
Right! Very important!
PgcEdit writes the DVDD settings to the Registry:
ProgramMode = 3 - ISO write
ISOWRITE_LayerBreakMethod = 1 - LB user specified

frank

27th June 2005, 12:30

Originally postet by rOlZ:
The sizes of L0 and L1 are not equal on DL DVD-Rs! Damn! I hate -Rs!
I will have to modify a lot of things in the method (and in the Setup GUI).

So, if L0 and L1 are not equal, I suppose that the computation of the valid cells and LB position is not based on the amount of data in L0 and L1, but instead must be based on the length of the track in physical distance from the beginning.Oh my god!! Let it be! All things are ok with DL. :eek:
As you can see at GEAR home page there is no difference in LB calculation between +/-R. We have not to care about physical sector layout! Only logical sectors of Data Zone count.

The rule is L0 >= L1 not L0 = L1.
L0 = L1 improves the laser reading quality of L0 because it has over the whole area the same reflectivity features. This does the burning software automatically by writing Lead-out. In early days Nero did not write the Lead-out to achieve L0 = L1 (or have they learned and patched the issue?).

The standard ECMA-267 says:
In DL disks in OTP mode, there is only one Information Zone extending over two layers...(Lead-in Zone,.., Data Zone with Middle Zone over two layers, Lead-out Zone)
The Lead-out Zone allows for a continuous smooth read-out.
..
The ECMA Standard does not specify the number of physical sectors in the Lead-out Zone.

r0lZ

27th June 2005, 12:52

OK, I trust you, and I prefer that!
But in this case, do you understand the post of jinjin_jp, and what's the japanese guide is talking about?

Also, thanks for your explanation on my problem with the burn. BTW, the manufacturer of the Maxell DVD is Ricoh. ID: RICOHJPN-D00-01

Here is the result of the KProbe test:
http://img34.echo.cx/img34/4071/testdl3av.png
Not very good!
But you will notice that the bad sectors are not in the middle of the disc. I don't understand!

r0lZ

27th June 2005, 13:32

As you can see at GEAR home page there is no difference in LB calculation between +/-R.Where did you saw that?
In the How To Set the Layer Break Point for DVD-Video Titles (http://www.gearsoftware.com/support/documentation/dvdvideobreakpoint.cfm) guide on Gear's homepage, there are no references to +R or -R. Are you sure they are talking about the new DL DVD-Rs as well?

frank

27th June 2005, 13:52

I bet that the LB is about 209000h = 2 134 016 where the PIF errors arise.
Check the burned LB with DVDD.
The errors are out of all specs. Do not burn higher than 2.4x.
And you have got 24 uncorrectable errors, that's very bad.
Further I suggest you to look for a newer burner BIOS. What burner is ist? I can't identify.
Seems you must spent another dvd :(

do you understand the post of jinjin_jp, and what's the japanese guide is talking about?No, I don't know, I prefer the known forums and standards.

frank

27th June 2005, 14:08

Hm, did I mismatch DVD+R DL with dual-layer DVD-R?
I have tested GEARS dvdse package and looked at the manual. But it is similiar to that article. Since they had a L0 sector count lower than Philips I thougt it was DVD-R. I can't remember now.

BTW I sent some mails asking for Book Type setting to GEAR but they didn't understand.
GEAR burning software is definitely not able to change the Book Type! But DVDD :D

I think all dual layer DVD+/-R +/-RW media must be compliant to the DVD-9 (DVD-VIDEO) standard! Only the capacity is different.
That's why we don't worry about it.
I have burned about 10 DL DVDs with Book Type DVD-ROM. All players eat them! :D:D

Originally posted by rOlZ:
Damn! I hate -Rs!The -R studio mafia which divided the world into 6 parts, and a CSS decrypted by a 15 years old boy! Never use it.

r0lZ

27th June 2005, 15:15

PgcEdit has set the LB at sector 2,065,664 (1F8500h). Confirmed by DVDD:Layer Information:
Layer 0 Sectors: 2,065,664 (52.18%)
Layer 1 Sectors: 1,893,184 (47.82%)
I have a NEC ND-3520A, running the latest firmware v3.04. According to what I've read on the net before buying it, it's one of the best burner on the market.

BTW, unfortunately, NEC doesn't support bitsettings for single layer DVDs. But you can change it to DVD-ROM for DL DVDs. And, of course, there are patched firmwares around.

Did you tried to burn a DL DVD-R with PgcEdit? Or someone else?

frank

27th June 2005, 16:43

PgcEdit has set the LB at sector 2,065,664 (1F8500h). Confirmed by DVDDSeems I'm right. The k.o. comes from PIF, it is much much higher than 32. Don't trust the media!

In the Media Markt and Pro Markt I only saw DVD+R DL, so I cannot test -R DL. And my LG burner doesn't burn -R DL.

The +R technology has simpler pits and lands structure (no Land Pre-Pits), and is therefore better to control. The tests of the leading german magazine c't show it.

First DL were +R/+RW.
I don't believe that DVD-R DL media is better because of using the older -R technologie, to see in lower capacity. But the communtiy of DVD-R player owners also wants DL media.

Tobii

27th June 2005, 19:51

BTW, unfortunately, NEC doesn't support bitsettings for single layer DVDs. But you can change it to DVD-ROM for DL DVDs. And, of course, there are patched firmwares around.
Look at this page (http://www.micheldeboer.nl/firmware/3520.html) . The firmware of Liggy and Dee (LD3520_1UG) should be interesting for you.

If you would like to know with which medium which firmware harmonizes well... rummaging perhaps here (http://technik.movie2digital.de/board.php?boardid=115) ?

Did you tried to burn a DL DVD-R with PgcEdit? Or someone else?
Cost me 7.90€, but I will try it at the Weekend. Whether this then runs into a player?
Without Booktype DVD-ROM, probably not.

My LG 4120B burns the Ricohs very well... :D
http://img238.echo.cx/img238/4320/ricohdvdrdl2606054pa.th.png (http://img238.echo.cx/my.php?image=ricohdvdrdl2606054pa.png)

blutach

28th June 2005, 13:25

@frank - re book type: Yes, if it is set and the burn and media are good, the player must accept the disk. :)

r0lZ - you got some very bad burns there. Do try to find some Verbatims and burn them at 2.4x. I am having great results with my LG4163B on +R verbates (and PgcEdit!).

Re PI/PIF standards - a small clarification: AFAIK, ECMA stipulates a maximum total of 280 PI errors within any 8 consecutive blocks. And no single block should have more than 4 PIFs.

Regards

r0lZ

28th June 2005, 17:04

Thanks for the help, guys. I have found a shop here that sells DL Verbatims... not in stock now! But I will try soon.

frank

28th June 2005, 20:09

DVD+R DL specs ECMA-364 currently released! (2005/06)
The Data Zone is specified to 2 x 2086912 = 4 173 824 sectors max.
= 8 547 991 552 Bytes max.
L0 max = 2086912 sectors

PgcEdit already uses it. :cool: :D:D

Dual-Layer DVD-R specs currently not completed!
-R/-RW (DVD Forum) specifys the minimum capacity and tolerances, not sectors.
The minimum Data Zone of Dual-Layer DVD-R is set to 8.5 billion bytes.
So we calculate
(8.5 billion / 2048) mod 32 sectors
= 4 150 400 sectors min -- 4 171 712 (Verbatim/Mitsubishi Chemical)
= 8 500 019 200 Bytes
L0 = 2075200 sectors min

PgcEdit 0.6.0b15 uses 4 148 992 sectors. Better using 4 150 400 sectors as worst case. This is the manufacturer's minimum. Their values can differ until +1 % (Data Zone tolerances).

I've found a very interesting article Building and Burning Dual-Layer DVD (http://www.emedialive.com/Articles/PrintArticle.aspx?ArticleID=8421). From the last section Pioneering Dual-Layer DVD-R:
Pioneer, the prime mover of all things DVD-R, announced on October 3 of last year (2003) that it had an 8.5GB dual-layer recordable DVD specification in the works, and demo'd its dual-layer technology at CES. In a white paper on the subject, also released in October, Pioneer published a point-by-point comparison of the physical characteristics of dual-layer DVD-R and dual-layer pressed DVD, indicating perfect matches in capacity, track pitch, channel bit length, reflectivity, and reference scanning velocity.As I said, the dual-layer DVD-R media must be compliant to DVD-9 (DVD-VIDEO). I'm wondering what the Japanese discuss there.
Originally posted by jinjin_jp:
...if want to set LayerBreak as this value, it is necessary to correct IFO and create ISO file manually like this way (http://yaki2fan.hp.infoseek.co.jp/-r_dl/dec_-dl.html). All I can see is that they want to shift the LB to L0max by padding L0. But dual-layer DVD-R media cannot be the reason. Seems, they didn't understand the dual layer stuff.

r0lZ

29th June 2005, 02:11

Thanks, Frank, for this very valuable information. I will change the default size for DVD-R DL to 4,150,400.
I am now committed that the method to burn +R and -R is the same (except of course for the capacity of the discs.) I will probably not change anything more in the DL burning code.

blutach

29th June 2005, 10:40

I really think it useful to insert a warning in the setup for DL that people check free sectors of their media before using PgcEdit. They can do this easily with DVD Decrypter.

Others thoughts?

Regards

jinjin_jp

29th June 2005, 12:33

@r01Z
Sorry not to explain well, I'd like to try to explain for understanding easily, please wait for a while.

Sorry to be late for replying.
I felt it is difficult for me to explain clearly in English, sorry.
I tried to show the list in English as much as possible, please see "DL_test_results".
http://img153.echo.cx/img153/6642/dltestresults8ip.jpg (http://www.imageshack.us)

This is not the specification, nor theoretical information about -R/DL, but this is just the results which are actually burned to -R/DL using three kind of method.
In this, I wanted to report most the part of red-colour that LO (shown in DVDDectypter ISO-Read Mode) is 2,092,896sectors in all three method.
I don't know whether this result is by chance or has the reason. It may be by chance and not necessary, but I thought it rather better to be possible to set the value of L0 by PgcEdit as option.

Thanks.

jinjin_jp

29th June 2005, 12:56

I found the example which is L0=L1.
It is DVD-ROM "ULTRAMAN Vol.1"

Sown like below in DVDDecrypter ISO-Read
--------------------------------------------
Disc Information:
Status: Complete
Erasable: No
Sessions: 1
Sectors: 3,962,048
Size: 8,114,274,304 bytes
Time: 880:29:23 (MM:SS:FF)

Physical Format Information (Last Recorded):
Book Type: DVD-ROM
Part Version: 1
Disc Size: 120mm
Maximum Read Rate: 10.08Mbps
Number of Layers: 2
Track Path: Opposite Track Path (OTP)
Linear Density: 0.293 um/bit
Track Density: 0.74 um/track
First Physical Sector of Data Area: 196,608
Last Physical Sector of Data Area: 16,580,607
Last Physical Sector in Layer 0: 2,177,631

Layer Information:
Layer 0 Sectors: 1,981,024 (50%)
Layer 1 Sectors: 1,981,024 (50%)

frank

29th June 2005, 13:11

@blutach
When you start PgcEdit then you first want to edit and not to burn.
I mostly use PgcEdit to remove unwanted content before shrinking to DVD-5.
It is the job of the burning application to inform you when media not empty or not suitable. You only insert a media when you start burning.

To make things easy, stable and compliant PgcEdit must use standard sizes of DVD +R/-R/DL. They are implemented.
Changing values to use some more sectors (..0.5 %!!), because the currently used dvd media includes them, is not visible in results and dangerous.
Imagine, you have backuped a DL ISO for such media, and you want to burn it again - but to another dual-layer dvd type with less capacity (but standard). What happens? :eek:

The more I think about it the more I tend to use only the 8.5 GB values for both DVD+R DL and dual-layer DVD-R.

blutach

29th June 2005, 13:20

@frank

I am very successfully using the default values because these are exactly what my media is! I'm just wondering for folks who have -R DLs (and they will increase in time), if it is not worthwhile to lead them to inputting the size of their media so problems do not occur.

Regards

frank

29th June 2005, 13:34

@blutach
No mercy to users that use media without completed standards ;)
The DVD Forum is guilty.
But I'm sure, with the values I described above, PgcEdit handles the dual-layer DVD-R in the right manner.

@jinjin_jp
Read the link in my post above Building and Burning Dual-Layer DVD (http://www.emedialive.com/Articles/PrintArticle.aspx?ArticleID=8421)
Dual-layer DVD-R is fully compliant to DVD-9!

The test shows the used burners and applications. L0 = 2 092 896 sectors is 0.85 % greater than the min, but which media from which manufacturer is used? And always the same?
What is the full capacity? There are very different numbers, I dont' trust them.
If we trust the printed capacity then L0>L1 - very strange. I don't believe that the -R standard differs in that manner from DVD-9!

Your example L0=L1 is compliant, but L0=L1 is not a MUST! There are no new problems! :rolleyes:

r0lZ

29th June 2005, 14:20

Too late! I have already added a message in the Burn Setup dialog, with a button to open automatically DVDD in ISO Write mode.
Anyway, it may be important to check at least the -R single layer size, or you will be forced to use a DL DVD if your compilation is just too big to fit on the default -R size even if your -R SL media is large enough.

But I agree: it's better to use only +R media. No bad surprises!

If you want to try the last beta, here is beta 16 (http://www.videohelp.com/~r0lZ/pgcedit/beta/PgcEdit_winexe_0.6.0beta16.zip).

There is also a new function I like very much (not related to the burn): the ability to check the whole DVD for Jump, Call and Link commands, and PrevPGCN, NextPGCN, GoUpPGCN links referencing non-existing PGCs or Titles. The Calls Cross References listing now includes them as well.

r0lZ

29th June 2005, 14:24

please see the file"DL_test_results". Please upload your image at ImageShack (http://www.imageshack.us/), and post the link here. Uploading images directly to the forum requires some time before it is approved by a moderator.

frank

29th June 2005, 14:49

rOlZ, Speedy Gonzales is nothing against you! :D

jinjin_jp

29th June 2005, 15:19

Please upload your image at ImageShack (http://www.imageshack.us/), and post the link here. Uploading images directly to the forum requires some time before it is approved by a moderator.
Thanks, Now uploaded and linked image.

jinjin_jp

29th June 2005, 15:41

@jinjin_jp
Read the link in my post above Building and Burning Dual-Layer DVD (http://www.emedialive.com/Articles/PrintArticle.aspx?ArticleID=8421)
Dual-layer DVD-R is fully compliant to DVD-9!
Is it mean not necessary to set L0=2,092,896sectors for -R/DL?

Your example L0=L1 is standard compliant, but L0=L1 is not a MUST! There are no new problems! :rolleyes:
Please understand I don't mean L0=L1 is MUST. Almost which I have seen were L0>L1. I want to report this example(L0=L1) as rare one.

frank

29th June 2005, 16:04

Is it mean not necessary to set L0=2,092,896sectors for -R/DL?No, that is the maximum on L0 of this media. As you can see in your second example, when the user data < 8.5 GB then the L0 sectors are decreased.

But it is much simpler.
Use PgcEdit, and look at the shown values before and after burning!

blutach

29th June 2005, 16:09

If you want to try the last beta, here is beta 16.A beta a day keeps the doctor away.

Regards

jinjin_jp

29th June 2005, 17:18

No, that is the maximum on L0 of this media. As you can see in your second example, when the user data < 8.5 GB then the L0 sectors are decreased.

But it is much simpler.
Use PgcEdit, and look at the shown values before and after burning!
Sorry, I can't understand so well.
In my first, second, and third example, I think all are L0=2,092,896sectors, and L0 sectors aren't decreased in second example.
I think this L0(shown in DVDDecryoter) doesn't mean the maximum on L0, and means to where burned on L0, so this value differs each DVD.
I think what is decreased is sectors from VIDEO_TS.IFO.

[add]the Image I have is like below.
http://img251.echo.cx/img251/4929/dltestresults21ba.jpg (http://www.imageshack.us)

r0lZ

29th June 2005, 17:59

Well, I really don't understand why this value of 2,092,896 sectors should have something magic. Seems it's aproximatively the size of a -R layer. But I don't think it's a good idea to push the data to the outer edge of the disc, as this part is more often subject to errors.
Also, I agree with frank. All informations available on the net are the same: it is not needed to fill L0 completely.
If it is really needed to do strange things like that to burn a DVD-R DL, I think I will not support -Rs anymore! I don't want to encourage people to use the -R technology while the +R is available, and is obviously superior.
Of course, I may change my mind later, when -R DLs will be available here to test both methods.

Anyway, jinjin_jp, thanks for your investigations, and for your translations in english!

nwg

29th June 2005, 19:02

From what I have read. DVD-R DL is less supported than DVD+R DL (Verbatim in the test). It was in the review of my Pioneer 109 writer. IT was found that not mnay players or even drives could read the discs. Even, my LG 4040 which doesn't support reading and writing of a DL+R or DL-R can read a DVD ROM DL+R.

Even though my Pioneer 109 supports -R DL. I won't be using it. I went from DVD+ to DVD- with single layer discs but will stick with DVD+R DL.

Tobii

29th June 2005, 20:13

short question at the beta 16...

In the Burn DVD dialog -> Cell list window (setting the LB), the preview doesn't work for a non-seamless cell any more.
With me, the preview works only at the seamless cells.
Changes the non-seamless cell into a seamless cell, the preview doesn't work either.

Something was changed here or does anybody have an idea?

r0lZ

29th June 2005, 21:04

No, Tobi. Nothing has changed since beta 15, except the default number of sectors in DVD-R DL. Obviously, it's not the problem.
Have you tried to launch the preview on the same cell from the PGC Editor's cell list? Do you have the same problem with another DVD?

Tobii

29th June 2005, 22:29

I have tried four different DVDs now. I have the problem at everybody.

Under Preview Menu -> Automatically start Preview Playback...is switched on.
The preview for the cell in question, doesn't work in the PGC Editor -> cell list.

The preview works for any cell, which has a seamless flag(8).
I start the preview for cell 19 (cell type flag=2 and LB), preview window opens -> no preview playback here and the functions above are inactive. (look at the snapshot)

http://img76.echo.cx/img76/8053/previewfenster2hm.th.png (http://img76.echo.cx/my.php?image=previewfenster2hm.png)

In the Burn DVD dialog, it is just the same. Preview window opens -> no preview playback here and the functions above are inactive.

I go backward tomorrow ... beta 15 -> beta14->beta13 etc.. and then wanting to test.

r0lZ

30th June 2005, 11:30

Hum, strange.

I've just found a similar problem with Matrix (Z2 Fr), but an error message appear: "Couldn't locate sector 1343176 !".
But note that my original rip of Matrix has some realloc problems with Nero, even if I remove the empty VOBs.

Note that the problem CANNOT come from a modification in one of the 0.6.0 betas. The PgcEditPreview.exe has not been modified, nor the method to launch it, at least from the PGC Editor's cells list.
Maybe it's something you have installed recently that cause the problem?

r0lZ

30th June 2005, 11:51

Well, I have mock stripped Matrix. Same problem.
Seems it is exactly the same problem as yours (the error message appear only when running PgcEdit in debug mode.)
I have emailed jeanl to let him know. It's probably a bug in PgcEditPreview.exe.

r0lZ

30th June 2005, 12:21

The preview works for any cell, which has a seamless flag(8).
I start the preview for cell 19 (cell type flag=2 and LB), preview window opens -> no preview playback here and the functions above are inactive.Matrix has a STC Discontinuity on the layer break's cell. When there is no STC discontinuity in the VOB, seems there is no problem with the Preview. So, the STC discontinuity could be the problem. Tobi, can you test if this flag is present in the DVDs you have tested so far? And try to find one without this flag and report if it works?
(Note that removing the STC falg in the IFO is not a solution: the Preview exe don't use the IFOs at all.)

frank

30th June 2005, 13:05

r0lZ

30th June 2005, 14:01

1) I've tested a backup with 6 titles.
In every title set the first cell has STC discontinuity but no seamless flag.
No problem with preview!

May be PgcEditPreview.exe has an issue.
If Jeanl used DVD2AVI as source then I remember there is a GOP bug that produces frame lost. It's better to change to DGIndex. Neuron2 can help when some CLI changes needed. More in the DGIndex f.a.q.OK, but the problem may be caused by the STC discontinuity inside the VOB, and not when the first cell of the VOB is played. I'm not sure, though.

2) PgcEdit blocks the Burn DVD Menu when you test a DVD from drive and not from HD backup.
Usually comes the message that it can't create the backup folder, ok.

When you start the Burn DVD / Create ISO menu you'll get an application error:

http://img299.imageshack.us/img299/1781/err7om.jpg ([URL=http://www.imageshack.us)

Tested DVD (PCgo 4/2005) also has some DVD-ROM content. Strange.OK, the error message comes from a bug in the routine that calculates the size of DVD-ROM subdirs, with empty directories, and is not related to the fact that you opened the DVD from your drive. Fixed now.

What do you mean exactly with "PgcEdit blocks the Burn DVD Menu"? Is it the same problem as the error message? I have just tried to launch the Burn function from a DVD drive, and it worked, although slowly. The Layer Break selection dialog opened successfully.
Anyway, you cannot burn directly from a read-only filesystem, since PgcEdit needs to write the new VTS sector pointers in the IFOs before launching mkisofs. So, if you accept the dialogs, you will have an error message, and the burn process will stop.

frank

30th June 2005, 16:23

It was the same problem. The File -> Burn DVD / Create ISO windows didn't start, only the error message was shown.
The DVD with "Message in a Bottle" comes from a computer magazine and has much DVD-ROM directories. I never had this error. Does the DVD-ROM content disturb the routine dvd_rom_size_subdir? I'm waiting for your update, or post the corrected line.

I thought Tobii tested his 4 DVDs from drive, because there may be strange behaviour like that problem. I will test other DVDs with STC in VOB at home.

Yes, I know that we cannot burn from a read-only system.
But for searching of original LB settings it is very useful to read from drive. :)

Tobii

30th June 2005, 17:20

I have changed nothing in my system. I use the original files, without any changes. I just don't try out of a disk drive.

The STC flag, is in the VOB at the DVDs in question.
Unfortunately, I haven't found any DVD without STC flag yet.

Sorry, r0lZ...
I haven't tested matrix. Till now, I also haven't noticed the problem.

Waiting what jeanl says to it.

jeanl

30th June 2005, 18:43

mmm I don't have much to say unfortunately! I can't replicate that problem, I would need a short test DVD to do that, then I'll figure out what the problem is. I'm not sure about the STC discontinuity, as far as I can tell, DVD2AVI does not seem to use the STC, but maybe I'm wrong (I haven't looked that hard). Tobii or r0lZ, could you possibly prepare a small version of the DVD and send it to me via www.yousendit.com? Make it as small as possible, just to let me see the problem.
About using DGIndex instead of DVD2AVI, it would have been a good idea when I started, but unfortunately, I didn't do it. Now I've added enough stuff to DVD2AVI that it would be quite a bit of work to replicate all these changes in DGIndex. Besides, I'm not sure how neuron2 would feel about having someone adding stuff to the code he now maintains....

jeanl

r0lZ

30th June 2005, 19:11

I'm waiting for your update, or post the corrected line.In both dvd_rom_size and dvd_rom_size_subdir, you have to change the first "return 0" to "return [list 0 0]":
proc dvd_rom_size {rootdir} {
if {[catch {set allfiles [glob -tails -directory $rootdir *]}]} {
return [list 0 0] ;# BUG fixed; was: return 0
}
...Let me know if it works...

r0lZ

30th June 2005, 19:16

Tobii or r0lZ, could you possibly prepare a small version of the DVD and send it to me via www.yousendit.com? Make it as small as possible, just to let me see the problem.Unfortunately, if I keep only the problematic cell with VobBlanker, the problem dissapear. Will try another method, but I'm not sure I will be able to give you a good example.

frank

30th June 2005, 20:05

@rOlZ
Bug fixed. Compiled and works! :D

What Tcl editor you are using?

Tobii

30th June 2005, 21:41

@ jeanl

Difficult, I can solve out the cell with VobBlanker or PgcDemux. The size of the cell is 36 MB (Nevertheless sending?)
But, I am of the same opinion like r0lZ. No good example. I search after another solution.

BTW, if the preview is going on in the trace, the problematic cell is skipped directly.
I start the preview alone for the cell 19, the preview hangs and I see a picture from the cell 24. :confused:

jeanl

30th June 2005, 23:22

Tobii, can you tell me which DVDs this happens with, maybe I have one of them. Which region are you in (I'm R1)? Also, you can sent up to 1GB with yousendit.com.
Try to find a DVD where this happens for a cell that in the first file of the VTS, for example, VTS_01_1.VOB or VTS_02_1.VOB etc. THen cut anything after the cell that causes the problem with cutfile (one of jsoto's tools here (http://jsoto.posunplugged.com/others.htm)). Don't modify the IFOs, make sure the problem occurs and send me all the IFOs, and that vob using yousendit.com (use my address: jeanldvd at free dot fr). I should then be able to reproduce the problem.
jeanl

r0lZ

1st July 2005, 00:10

Also interesting to note: the Layer Break cell on Matrix is just at the beginning of a VOB file. Is it the same for your DVDs, Tobi?

Tobii

1st July 2005, 06:44

The DVD is Constantine(R2).
I am not sure whether the cell is at the beginning of a VOB. I noticed the same problem also at Blade Trinity (R2).
I will send the files in question (tonight).

r0lZ

1st July 2005, 09:25

You can check if the cell is at the beginning of the VOB with VobEdit.
If the first pack is a nav pack, look at the value of "this->lba" at offset 002d or 040b.
If this LBA number is the Entry VOBU Sector of the cell, then the VOB begins with your cell.

frank

1st July 2005, 10:04

Loading the VOB into DVD2AVI is much easier. ;)

TITANIC (PAL RC2)
Layer Break at the beginning of VTS_01_5.VOB: VOB/CELL ID 5/1.
STC discontinuity, timer restarts with 0.

IfoEdit cell preview freezes, showing a grey window!
PgcEdit freezes (PGC Editor preview), showing a still from 0:19:56 in VOB/ID 5/3. If you change the cell type flags the behaviour doesn't change.
A full copy (CloneDVD) without any stripping sorted the VOBs new (there were some < 1 GB). Now the LB is not at beginning of VOB - and all things work perfectly!

The Burn Dual Layer window of PgcEdit works well in both cases, just the preview has the bug.

There must be something wrong in preview for ages. Bug in nav pack analyzing stuff...
Strange.

frank

1st July 2005, 12:14

@rOlZ
I recommend to rename Burn Dual Layer into Burn Double Layer (= DL)!
Dual Layer is the reserved -R name of DVD Forum.
And we like +R! :D :D

r0lZ

1st July 2005, 12:43

OK! Sure! I'll do it asap!

r0lZ

1st July 2005, 12:50

Seems I have understood the problem with the LB cell and the preview. There is a wrong calculation of the relative LBA offset in the VOB when a cell starts at the beginning of a VOB.
So, when a cell starts at sector 0 of a VOB, the sector is still assumed to be at the end of the previous cell, and the relative LBA number is wrong: it should be 0, but is computed from the start sector of the previous VOB.

Tobi, can you confirm that the bugged cells are all at the beginning of a VOB?

frank

1st July 2005, 14:55

Yeah, confirmed!! You are right rOlZ!

In TITANIC VTS_01_4.VOB has 884016 KB = 84.3 % of 1048576 kB.
That distance added to the begin of VTS_01_5.VOB gives the shown still (~10s difference because of VBR).

The preview doesn't notice that the VOB before LB can be < 1 GB!!
Then the end is crossed and playing stops.

jinjin_jp

1st July 2005, 14:58

These two have the same problem.
(1)Matrix(RC2,NTSC)
.....VTS_02_1.VOB 1,048,574KB
.....VTS_02_2.VOB 1,048,574KB
.....VTS_02_3.VOB 910,276KB
.....VTS_02_4.VOB 1,048,574KB===>FirstCell(V/C-ID=16/1) is LayerBreakCell
.....VTS_02_5.VOB 1,048,574KB
.....VTS_02_6.VOB 956,676KB
(2)Animatrix(RC2,NTSC)
.....VTS_01_1.VOB 1,048,574KB
.....VTS_01_2.VOB 1,048,574KB
.....VTS_01_3.VOB 1,048,574KB
.....VTS_01_4.VOB 633,396KB
.....VTS_01_5.VOB 1,048,574KB===>FirstCell(V/C-ID=15/1) is LayerBreakCell
.....VTS_01_6.VOB 27,822KB

Only above two cell "play" button of preview is inactive(gray out).
In example(2) there are many cells of type 2, but only this is inactive, but others are not.

I think these example have characteristic which previous VOB file is smaller than about 1GB inspite of last VOB of VTS_?? .

jinjin_jp

1st July 2005, 16:31

I found one more example.
(3)Ocean's 12(RC2,NTSC)
.....VTS_01_1.VOB 1,048,574KB
.....VTS_01_2.VOB 1,048,574KB
.....VTS_01_3.VOB 1,048,574KB
.....VTS_01_4.VOB 61,798KB
.....VTS_01_5.VOB 1,048,574KB===>FirstCell(V/C-ID=3/1) is LayerBreakCell
.....VTS_01_6.VOB 1,048,574KB
.....VTS_01_7.VOB 900,072KB

r0lZ

1st July 2005, 16:36

Seems this way of authoring the LB at the beginning of a VOB is present on all Warner Bros DVDs. Jeanl, you should find an example easily. Now, it's up to you!

blutach

1st July 2005, 16:57

Yes, I have seen that all the time on Warner - they start a new VOBID at the LB. Pretty convenient too if you ask me cos the audio buffer will have run down. Natural non-seamless position.

Regards

frank

1st July 2005, 19:27

I believe Nero makes the same at the LB. They split a VOB automaticly when needed.
All my tests with Nero produced coasters. :devil:

r0lZ

1st July 2005, 19:55

...except when doing a 1:1 direct copy. In this case, Nero works well.

You should try RecordNow or GEAR... if you want an alternative to PgcEdit/DVD Decrypter.

frank

1st July 2005, 20:27

Hey, since PgcEdit can burn DL I'm happy with it! :D

Some ideas to clean up menus:
The Burn DVD Setup menu should be moved to Options-Install as submenu.
The Preview Options and Virtual Player Setup should be moved to Options-Install as submenus.

Start in Trace mode works only if Launch Open DVD.. ist activated.
Why not start without conditions?

Suggestion: submenus
Launch Open DVD dialog?
DVD Start...
-Trace
-BOV Finder
-Create Backup at first time
Preview...
Virtual Player...

jeanl

1st July 2005, 20:30

OK guys, I found a small bug in DVD2AVI which was the cause of all the problems you've seen, when trying to go straight to the first LBA of a middle VOB (i.e. vts_02_3.vob). The problem was not related to the fact that the previous VOB was not 1GB. It was related to the fact that the cell started exactly at the first lba of a middle vob, which is normally exceedingly rare, except when it's done on purpose!!!
Anyway. The problem is now fixed, and r0lZ has the new versions. I suspect he'll soon post a new beta...
jeanl
P.S. I will let neuron2 know.

frank

1st July 2005, 20:38

Then IfoEdit's VOB cell preview apparently has the same bug. [edit]
:thanks:

jeanl

1st July 2005, 20:41

That's surprising, from what I gather, IFOEdit uses the direct-show engine to play dvds. It must be another problem...
jeanl

r0lZ

1st July 2005, 20:48

frank

1st July 2005, 21:08

@jeanl
I mean the VOB preview of IfoEdit, starting when you click on a cell in the main window. In the buggy case the window is grey and no preview starts.

jinjin_jp

1st July 2005, 22:43

Well, I don't make a new PgcEdit beta, because I have not changed the code today (except renaming Dual Layer to Double Layer).
If you want to test the new Preview, just download it (http://www.videohelp.com/~r0lZ/pgcedit/beta/PgcEditPreview20.zip) and copy the executable in the PgcEdit's install dir\bin subdirectory.
Seems all known bugs are now fixed. Thanks jeanl!

I comfirmed "PgcEditPreview20" fixed the problem that "play" button of preview is inactive(gray out) in example
(1)Matrix(RC2,NTSC)
(2)Animatrix(RC2,NTSC)
(3)Ocean's 12(RC2,NTSC)
Thanks jeanl.

jeanl

2nd July 2005, 01:39

@jeanl
I mean the VOB preview of IfoEdit, starting when you click on a cell in the main window. In the buggy case the window is grey and no preview starts.
That also uses direct-show (I asked derrow if I remember correctly). It's somewhat surprising that errors crop up on the same files in the two apps! But I really think there's no real link between the two...
jeanl

jinjin_jp

3rd July 2005, 03:15

More information about burning -R/DL was added in the bottom comparison table here (http://yaki2fan.hp.infoseek.co.jp/-r_dl/-r_dl.html).
And below is the table I tried to English.

In the table the value "L0" of burned -R/DL is always 2,092,896sectors and LayerBreakCell is diffent from original by ISO-Writing(1)&(2) of DVDDecrypter.
(1)Using MDS file which is output when ISO-Reading from original.
(2)Setting "sectors in L0" of "User Specified" as same as original.
===>Both Layer Break information seems to be ignored about -R/DL.
http://img210.imageshack.us/img210/8905/image05070310fl.jpg (http://www.imageshack.us)

Considering about above things, here (http://yaki2fan.hp.infoseek.co.jp/-r_dl/dec_-dl.html) is explained the process for padding necessary Sectors and adjusting Layer Break Position.
It is comlicated,but this process is equivalent to the process of PgcEdit like below Figure quoted,
1. set A(Final position layer break) to 2,092,896.
2. set B(Offset in L0) to the corresponding to A.
.....in this case
.........2,092,896(new A)-1,791,232(old A)+12(old B)=301,676(new B)
http://img210.imageshack.us/img210/6664/image05070328ah.jpg (http://www.imageshack.us)

r0lZ

3rd July 2005, 11:36

jinjin_jp

3rd July 2005, 13:25

Well, there is still something I don't unserstand.

If a DVD-R DL is minimum 4,150,400 sectors long, it means that a single layer is 2,075,200 sectors minimum.
In this case, it is NOT possible to force the layer break at sector 2,092,896, which is higher than the number of sectors per layer!
So, I imagine that the total size of the discs used in the tests is 2 x 2,092,896 = 4,185,792 sectors. As the DVD-R specs are not precise on the size of the DVD, I cannot assume this number is the right one.
I think strange, too.　"4,185,792 sectors" is too big comared with the information.

Also, why is it needed to fill the entire disc with padding sectors? Does it mean that the -R technology is not compatible with the DVD-Video specs? In this case, you should not be able to do a 1:1 copy.
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.

Anyway, I will make a special beta version (for the jap market ;)), with a field to input the layer break sector, to be able to force it at this position instead of the optimal position computed by PgcEdit.
Thanks very very much.

Of course, the best solution is to avoid -Rs, and use only the good technology: +R!

Jinjin_jp, can you confirm that the DVD-R used in the tests are 4,185,792 sectors long?
Sorry I don't have the condition of -R/DL tests, so now I requested to a companion who made the sites I've been introdeced.