Question RE: PGCEdit Dual Layer Guide

[ron spencer]

this feature of PGCEdit has come up at the DVDLab forum...one of the people there who does dvds for a living posted

"Ah, OK. I see that PGCEdit somehow pads the VMG's VOB file so that the BUP file starts at the correct offset for the layer break. That method is only applicable to burned DLs and would possibly cause problems were the same methodology applied to pressed media.

A better method is to ensure that all files are written at the correct offsets and there is no padding between them: this is the method GEAR recommends"

link is:

http://www.mmbforums.com/phpbb/viewtopic.php?t=12227


does this mean that there could be issues with some dvd players and the PGCEdit method of making a dual layer dvd?

[r0lZ]

I have replied in the thread at MMBForums.

[ron spencer]

ok I will check there...this is an interesting issue.

for the benefit of others, Gear uses this method to calculate the layer break:

http://www.gearsoftware.com/support/documentation/dvdvideobreakpoint.cfm

this was posted there as well

[r0lZ]

Oh, yes, I've read it before I started working on the burn function. This is a tedious method! I hate it! But it should work.

[ron spencer]

sure it is tedious!!!! yours is much easier....but as I see from the DVDLab forum yours is a different method. This is an excellent discussion....hopefully LUK! will have an opinion. Somebody on this board (or DVDLab board) must have a dvd verifier around somewhere

[LIGHTNING UK!]

I'm not a member of that forum but can I just comment on something Markham said...

ImgBurn DOES position the layer break on an ECC boundary - end of story.

The problem here is that on images where it's not possible to match a Cell boundary with that LBA, the LB LBA may well be in the middle of a cell.

That's not the image burning programs fault, it's the fault of whatever made the image.

Basically, in order of preference:

1. LBA from MDS
2. LBA calculated from IFO / Cell / ECC
3. LBA calculated from VOBU / ECC
4. LBA calculated from ECC (image split down the middle but rounded up to be a multiple of 16)


To rebuild the ISO on the fly when burning, padding and correcting the filesystem as it goes, is a little bit OTT for a simple burning program! Looking at Markham's wording, that's what he's expecting to happen :o

[r0lZ]

I'm not a member of that forum but can I just comment on something Markham said...

ImgBurn DOES position the layer break on an ECC boundary - end of story.We know that! Markham not!

The problem here is that on images where it's not possible to match a Cell boundary with that LBA, the LB LBA may well be in the middle of a cell.

That's not the image burning programs fault, it's the fault of whatever made the image.

Basically, in order of preference:

1. LBA from MDS... or from the user specified write setting, or the CLI /LAYERBREAK option. Right?
But what if the specified LB is not correctly placed on an ECC? Is it an error message, or do you open the GUI?


2. LBA calculated from IFO / Cell / ECC
3. LBA calculated from VOBU / ECC
4. LBA calculated from ECC (image split down the middle but rounded up to be a multiple of 16)Could you elaborate on points 3 and 4? I think it is illegal to put the LB on the middle of a cell, and furthermore in the middle of a VOBU. In these cases, do you issue a warning?

To rebuild the ISO on the fly when burning, padding and correcting the filesystem as it goes, is a little bit OTT for a simple burning program! Looking at Markham's wording, that's what he's expecting to happen :oBut that's what PgcEdit and MKISOFS are able to do! :)

BTW, I know many ppl don't like to use DVDD/ImgBurn because an intermediate ISO must be writen on HDD. Do you have plans to accept an ISO on the fly, from stdin? I know you want to verify the integrity of the ISO, and the location of the LB, but of course, the sender program (ie PgcEdit and MkISOFS) is responsible if an image is burned on the fly, not ImgBurn. If you add this option, the PgcEdit/MkISOFS/ImgBurn combo will beat all burner apps availables today! ;)


(PS. I will post a link to your reply in the MMB thread.)

[ron spencer]

thanks

[ron spencer]

looks like jberry in DVDLab got the ball rolling in the Gear forums....

Tom Vaughn, a person who writes Gear says:

"jberry,
You are looking at 2 different descriptions for doing the same thing. In both cases, the VOB is moved by the appropriate number of sectors in order to align the chosen layer break point with the start of a new ECC Block.

You have to use GEAR's method when you use GEAR."

so I guess all is ok for both methods....this has been great learning here I think.

see:

http://www.mmbforums.com/phpbb/viewtopic.php?t=12227

[ron spencer]

this is interesting

http://www.mmbforums.com/phpbb/viewtopic.php?t=12227&postdays=0&postorder=asc&start=15

[frank]

Seems, professional programmers now start to learn how to set LB properly! :D :D :D
But PgcEdit has it since a long time! And with preview! Thanks to the international community.
Originally Posted by LIGHTNING UK!:
ImgBurn DOES position the layer break on an ECC boundary - end of story.
Right! There are data DL DVDs too. And they don't have any IFOs, CELLs or VOBUs, they only know the ISO/UDF system. These elements are introduced by DVD-VIDEO. That's why the burning app must NOT be responsible for the LB setting on DVD-VIDEO as first. This is the part of the VIDEO authoring program.

Hardware players don't know a file management like Windows!!! They know UDF but not ISO. The VOB access is very simple through the chained pointers in the IFO (Video Manager Information). This is the reason for the VOB order and the Get VTS sectors function in IfoEdit (useless for PC). By adjusting pointers in the IFOs, PgcEdit doesn't break any rule. It is the responsibility of the DVD burning app to take the pointers into account.

[r0lZ]

Thanks, Frank!
However, maybe there is something true with the problem of pressed DVDs. It's a domain I haven't investigated at all. But why should it ignore the rules?

[ron spencer]

well we should not make fun of anyone here (well maybe!!) but this dual layer thing is an interesting and important topic....hopefully members of doom9 and dvdlab can get a compendium set on this as other than Gear and ImgBurn there are no constantly reliable dual layer burning programs.

I do agree though that it is ironic that a thousand dollar geat mastering program has no layer break preview while pgcedit does ;-)

[r0lZ]

Don't forget RecordNow. It's also a good burning app, which respects the IFOs.

[LIGHTNING UK!]

We know that! Markham not!

... or from the user specified write setting, or the CLI /LAYERBREAK option. Right?
But what if the specified LB is not correctly placed on an ECC? Is it an error message, or do you open the GUI?

If it's specified in the GUI or via CLI, yes you'll get an error message saying it's not a multiple of 16.

Could you elaborate on points 3 and 4? I think it is illegal to put the LB on the middle of a cell, and furthermore in the middle of a VOBU. In these cases, do you issue a warning?


If it's done via CLI or GUI, tough luck! It'll put the LB where it's told - no questions asked (apart from if the LBA is out of allowable ranges or not % 16).

Only when left on the 'Auto detect' setting and no nice ifo/cell/ecc match is found will it resort to mearly going with a vobu/ecc and failing that, just ecc (just ecc is of course used for data dvds or discs where the middle point of the image isn't within a vob file). Yes this may not be perfect but it works ok for lots of people ;) That's all DVD Decrypter ever did anyway!

You will probably get a warning or something in the log - and of course you're always told how the LB LBA was calculated.

BTW, I know many ppl don't like to use DVDD/ImgBurn because an intermediate ISO must be writen on HDD. Do you have plans to accept an ISO on the fly, from stdin? I know you want to verify the integrity of the ISO, and the location of the LB, but of course, the sender program (ie PgcEdit and MkISOFS) is responsible if an image is burned on the fly, not ImgBurn. If you add this option, the PgcEdit/MkISOFS/ImgBurn combo will beat all burner apps availables today! ;)

No immediate plans for that, no. If people are playing with dvds, tell them to get a big enough hdd (or better still, a second one) - lol !!
Creating the ISO then only takes a couple of minutes :p

[blutach]

All this sounds like a wonderful reason to keep using PgcEdit for making perfectly compliant ISOs.

Regards

[goonix]

Is that (http://forum.doom9.org/showthread.php?p=720550#post720550) related to this thread?
- Changed the default value for 32k padding to "off". Also removed the setting from the ISO Options form. While the format is compliant with DVD standards, there are too many 3rd party packages that have trouble reading ISO images with padding. I've decided the benefits are outweighed by the disadvantages.goonix

[r0lZ]

Well, yes and no. The PgcEdit's 32K gap option is described by Blutach in this guide (http://www.videohelp.com/~r0lZ/pgcedit/third_party/blutach/Burning%20With%20PgcEdit.htm) and discussed in this thread (http://forum.doom9.org/showthread.php?s=&threadid=88606). But a similar method is used to align the layer break with an ECC block boundary.

I know there are (unfortunately) many burning applications having trouble with this option, This is why there is a warning message when you turn it on. However, if you use the right software (ie MkISOFS to create the ISO and ImgBurn/DVD Decrypter or RecordNow to burn it) this option is really invaluable. Therefore, I disagree with jdobbs. It's not because there are bad burning programs around (notably Nero, and probably Gear) that this option must be abandonned. There are even DVD burning programs that are totally unable to create compliant DVDs (for example, they put the BUP file between the IFO and the first VOB!) This doesn't mean that we cannot burn DVD-Videos anymore! We have to use the right software to do the right thing.

PgcEdit will continue to support the 32k gap option, and use the gap method to set the layer break properly.

[voo_doo99]

...
I know there are (unfortunately) many burning applications having trouble with this option, This is why there is a warning message when you turn it on. However, if you use the right software (ie MkISOFS to create the ISO and ImgBurn/DVD Decrypter or RecordNow to burn it) this option is really invaluable.
...
PgcEdit will continue to support the 32k gap option, and use the gap method to set the layer break properly.

I used this method to back up "THE PIANIST" in dual-layer with the 32K gap option. The burn was successful but compatibility suffered. My standalone Panasonic, Sony, Pioneer, Apex, Audiovox froze either after the main menu or at the layer-break. Supprisingly, my Toshiba DVR played the backup smoothly :confused:

I suspect my older players could not handle the gap and got lost? [there was a lot of searching going on]. But if I understand correctly, the 32K gap was implemented thru IFO pointers only and thus needed the ISO format. My question here is if the gap could be created as extra blank cells in PgcEdit and in VobBlanker after blanking?. Maybe with real cells the backup can use any burning program, does this sound right?

[r0lZ]

Again, some burning apps will fail. For example, Nero (again!) will probably reject a VOB file if it is not referenced. Also, a tiny cell is about 10KB long. We can use 4 of them to fill in the 32K gaps, but it's not suficiently accurate to deal with the layer break.

Honestly, I think the problem with your players comes from another issue (media, burner?) Many commercial DVDs use the gap method, without problem. (See here (http://www.mmbforums.com/phpbb/viewtopic.php?t=12227&postdays=0&postorder=asc&start=26).)

The 32K gap method is implemented thru IFO pointers, right. But the filesystems (UDF and ISO) are also holding the start of each files in the directories. So, any read method should be able to find the start of the file.