Guide: How to burn ISO images with PgcEdit ensuring 32k gaps between IFOs and BUPs [Archive]

LARRYB

31st January 2005, 22:52

Man, you guys must be some kinda DVD gru's. Now for the layman (me), I downloaded all the programs listed on the Pcgedit's webpage. Installed the software and WOW I'm impressed, but really confused now. I thought it was going to be a 1 click program "Wham Bam, burn it man" program.

I could probly struggle through it but reading about the program, it dosent say that it will SHRINK the program to fit a DVD-R disk. It will do lots of stuff but I could not find where it would tell me the compression percentage needed to fit on a single layer DVD.

Did I overlook something?

Do I still need DVD shrink? It also appears I will need Dycrypter also.

Larry Barnes

blutach

1st February 2005, 02:43

Larry,

PgcEdit is not a shrinking program - although it can blank out whole titlesets (eg extras) and menu VOBs (eg warnings, promos), reducing the size of the project considerably.

VobBlanker can blank and cut the movie as you like it.

But if it is still too big, you will need either:

1. A transcoding program - like DVD Shrink - to reduce it to a single DVDR; or

2. Split the disk into 2 DVDRs

PgcEdit's new burn function is designed to take a finished project, which can already fit onto a DVDR and burn it in the least risky manner.

As a final thought, yes, you should use DVD Decrypter to decrypt your DVDs and then open them in DVD Shrink using the Open Files command (Ctrl-O). DVD Shrink simply cannot decrypt the new arccos system, and since Shrink's development is over, it never will be able to.

Hope this helps.

Regards

LARRYB

1st February 2005, 06:18

I reliazed that Pgcedit was not the program that I and everyone would really like to have. A trully 1 click program from start to burn.

I have ben pulling my hair out over the past 2 weeks when using dycrypter and DVD shrink. I have intermittent problems using the DVD shrink. The probelm is I can authorize the project after I dycrypt the program to my hd, when it come time to burn full back up the program quits responding and freezes. My only option at this point is to shut down the computer, restart, remove both dycrypeter and dvd shrink from my computer, restart CPU, install both programs again and 50% of the time the DVD shrink will compress the program and burn it.

If I try to shut down the DVD shrink during a lock-up, I get program not responding "end now", "cancel".

I have closed all unneeded programs before running dycrypt and shrink.

I was sorry to read that DVD shrink will not be getting anymore attention from the author of the program.

Do you know a another shrink program on the web?

Larry Barnes

blutach

1st February 2005, 06:46

There are lots, but before ditching DVD Shrink you might want to visit their FAQs and forums.

See http://forum.digital-digest.com/showthread.php?s=&threadid=44931

Regards

techniquefreak

18th February 2005, 02:02

Hi Rolz excellent guide and thanks a lot.
Maybe I'm missing the obvious here but could I burn the image created with pgcedit and msikofs (and 32k option checked of course) with Nero if I prefer to do so? The reason I ask is I'm quite happy with Nero but would of course like to maximize compatibility with standalones on burned discs ...

Thanks in advance

r0lZ

18th February 2005, 02:14

I think so. Nero doesn't respect the 32K gaps if you burn the DVD files directly. But it should burn an ISO image without modifying it. However, I'm not sure Nero is better than DVD Decrypyer for the compatibility with standalones.

BTW, the thanks must go to blutach. He writed the guide, not me.

LARRYB

18th February 2005, 04:07

I had experienced several lock-up issues when using DVD shrink and Nero v6.0. The problem was traced back to Nero V6.0+. After removing all nero software from my computer the DVD shrink wold work just fine. Then it struck me, DVD Shrink defaults to Nero software for the burning of the DVD. After confirming that DVD shrink was working fine, I installed Nero back on my computer system. I made sure that DVD Shrink was set up to use Nero as it's default burner. First time trying it my system locked up during the DVD shrink Backup files. I then switched the Nero default swith to OFF. Again trying to backup disk files my system locked up.
My last attempt was I again uninstalled all Nero software. Launced DVD shrink and everything work great. I had the cd/dvd sotware that came with my Compaq called Sonic, record now. I was able to burn the DVD's using this software and have been for about 2 weeks now.

I have upgraded the Nero software using the Nero's downloadable upgrades so I should have the latest and greates Nero version. Some reason there is somethink that it dosent like about my Compaq system running Windows XP, home.

I hope this helps other having troubles with Nero.

Larry Barnes

blutach

18th February 2005, 05:16

@techniquefreak

Even Nero can burn an ISO without screwing it up.

But why bother? PgcEdit/mkisofs/DVD Decrypter is a one-click, set and forget solution and is costless.

Nero causes more trouble than it's worth.

Regards

r0lZ

18th February 2005, 10:27

BTW, Sonic's Record Now should be able to burn the DVD files directly and respect the 32K gaps. I have tested Stopm's Record Now Max, and it works fine.

techniquefreak

18th February 2005, 20:53

OK thanks anyway for your replies. Will try and follow the recordnow route for now.

@r0lZ - allright I realize now that it's blutach who wrote the guide but then thanks for a great program then ;)

@LARRYB have you tried emailing Nero support for further problem-solving - it might help - was thinking of doing the same think about the 32k issue in burning DVD-video files ...

Kind regards

Hansen

blueboyec

18th February 2005, 21:36

I beleive if you have Nero and recordnow both installed they conflick with each other?

2COOL

18th February 2005, 21:42

Originally posted by blueboyec
I beleive if you have Nero and recordnow both installed they conflick with each other? I confidentially assume that r0lZ has both on the same PC and he reported no errors. This could throw that theory out.

r0lZ

19th February 2005, 01:12

I have Stomp's Record Now Max trial and Nero. I have not tested Sonic's RecordNow.

robot1

19th February 2005, 11:43

Originally posted by r0lZ
BTW, Sonic's Record Now should be able to burn the DVD files directly and respect the 32K gaps. I have tested Stopm's Record Now Max, and it works fine. Thanks for the option in PGCEdit and for the guide.
Is there a simple way to check the correctness of the output of other burning programs?

r0lZ

19th February 2005, 12:04

It's not really easy.
The simplest way I've found is to create a verry small DVD, without VIDEO_TS.VOB. (For example, a DVD with only one title with one still frame.)
Then, use the burner to create an ISO.
Open the ISO image in an hexadecimal editor, and search for "DVDVIDEO-VMG". Note the address of the first occurence. Search again, and note the address of the second occurence.
The difference between the two addresses must be 32K (32768 bytes) plus the actual size of the VIDEO_TS.IFO file.
If it's less, then your burner doesn't respect the 32K gaps.

In this case, it is also useful to verify the VTS Sectors pointers with IfoEdit. If they are equal to thoses in the original files, then the burner is really bad: it writes files not compatible with standalones. If the pointers are equel to the values saved by PgcEdit with the 32K Gap option off (or with IfoEdit's Get VTS Sectors), then the burner removes properly the 32K gaps.
The VTS Sector to verify is in the VMGM_MAT, at offset 0x0000000c (Last Sector of VMG). There are also changes in the TT_SRPTI tables (all TTUs starting bytes).
Another way to test is to burn a RW, and check it on your standalone.

linx05

3rd April 2005, 17:53

So, the steps you could take to decrypt a dvd then burn it to a dvd is as follows:

Decrypt it using DVD Decryptor
Leave at least 32k of space between IFO and BUP
Burn to DVD

Is the 32k step necessary? Should it be added to the steps you should take to rip a dvd? Are there any cons to doing it?

Thankyou

- Aaron

blutach

4th April 2005, 02:11

Hi linx5

Generally, if you are not going to process the DVD at all (e.g. decrypt then write to DL), then the DVD will usually have enough junk on it to make every VTS as well as VMG large enough to have at least a 32k space between the IFO and the BUP.

You will often see those Spruce Technologies menus (or just blank ones), for example, that are never accessed. This not only is a nice advertisement for the authoring house but also "fills the gaps".

Now, if you blank titlesets, unreferenced menus or both, or "reauthor" a DVD with any of the popular transcoders, these 32k gaps will not be there anymore.

So the final thing to do with PgcEdit it to put them back again. PgcEdit does this with its own Get VTS Sectors routine, after which you can conveniently burn from the PgcEdit interface, while honouring the new sectors (most other burning progs will do a Get VTS Sectors again, negating PgcEdit's routine).

Hope this helps.

Regards

erdoke

4th April 2005, 23:01

I did a search for my problem and was surprised that this thread is fresh but nobody has similar issues.

PGCEdit 0.5.1
ImgTool Classic 0.91.4
DVD Decrypter 3.5.4.0 (for burning the image)

A couple of days ago I checked this 32k gap option in PGCEdit and since then all the movies I've burned don't play in my SONY standalone. I went back to the standard method, movie plays fine.
Any reasons that only I have such an issue?
To correct this is it enough to rip the movie and Save it in PGCEdit to perform a standard Get VTS Sectors?

r0lZ

5th April 2005, 00:09

Strange! My old Sony DVP-S725D plays these DVDs with gaps fine!

To perform a 'standard' Get VTS Sectors, you must turn off the option "When saving, leave at least 32K of space between IFO and BUP", and save the DVD.

I am interested to know if a DVD burned with PgcEdit but with the 32K gap option off will play fine on your Sony. Is it the 'standard method' you use now? Please let me know. Thanks.

erdoke

5th April 2005, 00:43

Yes I turned it off when I realized that my movies won't play on my standalone.
Ripped a non-working movie with DVD Decrypter in File mode, opened and saved it in PGCEdit (standard method), converted to ISO with ImgTool Classic, burned with DVD Decrypter and now it plays fine.
No more investigations with 32k gaps. ;)

r0lZ

5th April 2005, 01:13

OK. Thanks.

Note that burning the DVD directly with PgcEdit does exactly the same thing, with the 32K gap option OFF. It's just easier to do: the backup files are excluded automatically, the VIDEO_TS folder is created if needed, junk files in VIDEO_TS are not accepted, the DVD label is automatically derived from the DVD-TEXT General Name, or from the folder name...

ImgTools Classic is also a GUI frontend over mkisofs and DVDDecrypter, but it doesn't handle the backups and the 'alien' files, and you have to browse to your DVD folder, and enter the label manually.

blutach

5th April 2005, 03:03

This is strange erdoke. My SONY also plays them OK. But they are not all created equal. For you then the best choice is probably to ensure that you don't blank those "advertsing" menu files and so make sure that each VTS is 32k minimum.

Regards

erdoke

5th April 2005, 08:14

Originally posted by blutach
This is strange erdoke. My SONY also plays them OK. But they are not all created equal. For you then the best choice is probably to ensure that you don't blank those "advertsing" menu files and so make sure that each VTS is 32k minimum.

These were mainly movie only backups, so only one VTS and VMG.
I've never had problems with this setting OFF, it was just a try.
My SONY behaved like when a missed Get VTS sector disc was inserted. But in only one case I got a "Disc is dirty" error message. :confused:

erdoke

5th April 2005, 09:23

Originally posted by r0lZ
Note that burning the DVD directly with PgcEdit does exactly the same thing, with the 32K gap option OFF. It's just easier to do: the backup files are excluded automatically, the VIDEO_TS folder is created if needed, junk files in VIDEO_TS are not accepted, the DVD label is automatically derived from the DVD-TEXT General Name, or from the folder name...

ImgTools Classic is also a GUI frontend over mkisofs and DVDDecrypter, but it doesn't handle the backups and the 'alien' files, and you have to browse to your DVD folder, and enter the label manually.

I know that but it simply doesn't work for me. I get an error message when starting to build the image:

http://erdoke.uw.hu/Pix/PGCEditmkisofsError.png

All the file paths are shown at the Settings panel, same files that I use for everyday burning.

r0lZ

5th April 2005, 10:28

That's also strange!
Is your DVD located in "P:\Working" (ie, you should have a folder "P:\Working\VIDEO_TS") ?

erdoke

5th April 2005, 11:09

Exactly, I show P:\Working to ImgTool Classic and it makes the ISO without any problems. In PGCEdit the same mkisofs.exe is selected from ImgTool Classic folder so I also don't understand it.

blutach

5th April 2005, 11:33

@erdoke

Does not PgcEdit give you are warning if you don't have your stuff in a VIDEO_TS folder and offer to make them for you?

Regards

r0lZ

5th April 2005, 11:57

The error message "The system cannot find the path specified" means that a program is probably not installed correctly in PgcEdit's burn setup. Also, note that mkisofs.exe needs cygwin1.dll in the same directory to operate properly.

erdoke

5th April 2005, 13:11

Originally posted by blutach
Does not PgcEdit give you are warning if you don't have your stuff in a VIDEO_TS folder and offer to make them for you?

No, because it is in a VIDEO_TS folder already. WinDVD plays it only if it is in a VIDEO_TS folder so I keep all my movies that way on HD.

erdoke

5th April 2005, 13:12

Originally posted by r0lZ
The error message "The system cannot find the path specified" means that a program is probably not installed correctly in PgcEdit's burn setup. Also, note that mkisofs.exe needs cygwin1.dll in the same directory to operate properly.

No matter if a I point to the files again. Same error message. The mentioned dll is with mkisofs in the same folder.

r0lZ

6th April 2005, 10:10

Well, I've found a small problem in the PgcEdit's code that may cause the error. I'm not sure though.
What I do is to launch mkisofs first with the option to calculate the size of the final ISO. I use that to verify that the right files are burned, and that the mkisofs command line is coherent. Then, when that command returns, I launch it again without the size option, to create the ISO.
The error was in the first command line (missing quotes in a filename). This first command is probably not issued by ImgTool, so this may be why PgcEdit fails while ImgTools doesn't.
Please try v0.5.2, that will be available in a couple of days, and report here if the problem is solved. Thanks.

erdoke

8th April 2005, 22:44

Tried it with PgcEdit 0.5.2 b2 and indeed the error message changed:

http://erdoke.uw.hu/Pix/PgcEditISOcreationError052b2.png

r0lZ

8th April 2005, 22:53

Well. It's a little bit better. We know that it's a problem with the command line.
Still strange. I use also ImgTools Classic 0.91.4, without problem.
I will have a look again...

r0lZ

9th April 2005, 11:20

OK. erdoke found the problem.
ImgTool Classic was installed in a folder with non-standard characters in the name (a + sign).
This caused the call to the external executable mkisofs.exe to fail.

erdoke

9th April 2005, 11:36

Originally posted by r0lZ
OK. erdoke found the problem.
ImgTool Classic was installed in a folder with non-standard characters in the name (a + sign).
This caused the call to the external executable mkisofs.exe to fail.

In fact it was not a + sign, it was an "ó" converted to it by sg. :)
Thanks for the help again.

r0lZ

26th April 2005, 16:54

Originally posted by forkart
why don't you try magiciso. I use it to burn DVD. It's not free! And, IMHO, $29.95 for a frontend over another burner program, it's extremely expensive. If I understand correctly the homepage, it does exactly the same job as ImgTools, or the built-in burn function of PgcEdit, which are free.
Furthermore, it won't save you the job of the ISO creation process, and must write it to HD, too.

erdoke

26th April 2005, 19:25

Originally posted by forkart
[B]why don't you try magiciso. I use it to burn DVD.

I've tried MagicISO and came to a conclusion that it wasn't designed with DVD-Video in mind.

linx05

7th June 2005, 15:20

blutach

9th June 2005, 12:48

MenuShrink leaves VTSs that are bigger than 32k. VobBlanker and PgcEdit oftentimes don't. The PgcEdit routine takes about 1 second to do. You just turn on the option and hit save.

Regards

Fairhope

13th June 2005, 16:32

I hesitate asking this question. I'm sure it is right in front of me, but I've been unable to find it.

I did the one time set up to allow PGCEdit to create the .iso and then burn with DVDDecrypter. I have since moved some of the files it uses - IMGTools and DVDDecrypter and changed out my burner.

Now I need to do the one time set up again, but can't find a way to access that portion. PGCEdit is giving me a warning that my burner drive is not recognized.

Can someone tell me how I can get back to the one time setup option in PGCEdit's burn function?

Thanks, Ty

r0lZ

13th June 2005, 16:43

It's a menu in the main Burn dialog, at the upper left corner of the window.

The warning may indicate that the drive letter of your burner has changed.

Fairhope

13th June 2005, 17:08

Thanks for your help.

Ty

blutach

25th April 2006, 09:32

Updated guide - http://www.digital-digest.com/~blutach/pgcedit_guide/burning_with_pgcedit/burning_with_pgcedit_v2.htm

Regards

jamos

25th April 2006, 15:03

Updated guide - http://www.digital-digest.com/~blutach/pgcedit_guide/burning_with_pgcedit/burning_with_pgcedit_v2.htm

Regards
Thanks Blue!

windtrader

19th May 2006, 20:45

@blutach

Should I be worried??

I've been burning DVD for a number of years and never heard of the 32K burning problem until seeing the reference in pgcedit. It seems you are not a big fan of Nero but I have been using the burn DVD-Video files function and never seem to have problems. I'd sure hate to think that nearly 1000 backed up discs are bad.

Is there any way to check the backuped media to see if the gap exists?

setarip_old

19th May 2006, 21:04

@windtrader

Hi!

There is a BIG difference between a POTENTIAL "problem" and a "problem".

I have a burned backup collection of the same magnitude as yours - and have never encountered a playback problem for lack of specific 32k gaps.

From what's previously been posted by the truly knowledgable programmers, such as "jsoto" and "r0lZ", if and only if a DVD gets physically damaged at the point of an .IFO, creating a 32k gap between the .IFO and its companion .BUP file will minimize the possibility of BOTH of these files being unreadable (thereby rendering the DVD unplayable)...

windtrader

19th May 2006, 23:59

No wonder I've not noticed the problem as it is a very low probability occurence. I always thought the IFO and its BUP were physically written apart to maximize the ability to read one or the other in case of read problems. And even with a 32k gap, I'm not so sure it helps very much if there was damage to the IFO.

setarip_old

20th May 2006, 02:11

I always thought the IFO and its BUP were physically written apart to maximize the ability to read one or the other in case of read problems.Yes, as I understand it, that IS the logic (physical damage is probably the primary reason for read problems). The bigger question is, how often, if at all, have you heard of this occurring in real life? I've personally never heard of it (Although I've been taken to task, by one or more of the knowledgable programmers, when I stated this in the past ;>} ). Based on my experience, I'm not inclined to worry about this...

blutach

20th May 2006, 04:07

Should you be worried? Perhaps not. But iut doesn't hurt - and takes no real time - to increase the space between your files.

Furthermore, buring with PgcEdit (http://www.videohelp.com/~r0lZ/pgcedit/index.html) and ImgBurn (www.imgburn.com) is the safest way to make a DL burn.

Have fun.

Regards

mpucoder

20th May 2006, 05:34

And the reason for the 32k gap is the error detection and correction mechanism of DVD. Although the sector size is 2K there is a larger block of data, called an ECC block, protected by 2 arrays of Reed-Solomon codes which is 32K in size. If damaged enough to render the error correction useless all data within the block is lost. Having at least 32k between the end of the ifo and the start of the bup ensures that the two files are in seperate ECC blocks.

LIGHTNING UK!

20th May 2006, 11:55

r0lZ

20th May 2006, 12:14

The bigger question is, how often, if at all, have you heard of this occurring in real life? I've personally never heard of it...
Of course, if the IFO is damaged and the BUP is OK, your player will use the BUP silently. It will not warn you! And if both files are damaged, the player will probably stop with a cryptic error code, or a message like "no disc". Therefore, it is virtually impossible to know for sure when the 32K gaps are really useful.
Anyway, the 32K gap method is only a safety net. You don't need it if you handle your DVDs with care, and if you use good media. But, as blutach said, it doesn't hurt and doesn't cost anything.

@LUK!: You're right. Since I don't know exactly how many sectors are used by mkisofs for the ISO header and the file system, it is easier for me to use always at least 16 sectors. But if you build the ISO yourself, you should know exactly the sector number, and you can align the BUP file so that it starts at the beginning of the next ECC block.
Note that, if the DVD is not full, it is even better to use larger gaps. I've seen many commercial DVDs with huge gaps.

frank

20th May 2006, 12:29

The microchip/firmware in the dvd drive ONLY reads ECC blocks in it's buffer.

Therefore the 32k gap is a good thing.

mpucoder

20th May 2006, 13:56

Surely you just need to ensure there is an LBA between the two that's divisible by 16 though... it doesn't have to be exactly 32k.

Or at least I hope that's good enough because that's why I've implemented in my own building util!
Yes, but authoring programs do not know what the disk layout is, ie where the data for the folder VIDEO_TS starts - is that always on an ECC boundary? Also the compilation of each vts (while rare to have so little content as to require a gap) is independant and takes place before the compilation of vmg files, making it complicated to know the lba's until the very end. So ensuring 32k between ifo and bup is the simplest solution to ensure they are in different ECC blocks.

LIGHTNING UK!

20th May 2006, 15:47

r0lZ,

I would think they pad out that much so that any DL disc has equal amounts of data on each layer - even if 30% of it is just padding! They're much more compatible that way.

Whilst a drive would probably pad the remainder on the 2nd layer itself anyway, I'm not sure if it's 'AS' good as doing it with real data.

I guess speed could also be a factor here, with it reading data faster the nearer it gets to the outer edge. In theory if they can slow the spindle rpm down and still achieve the minimum transfer rate, it'll be quieter in operation and keep people who don't like player noise happy!

mpucoder,

Yeah you're right, of course! I was just kinda thinking the ones that also build the ISO for you might edit the IFO files or something as it builds the image so the correct info is in there - should it need tweaking or what not. That would of course be making life harder for themselves, which would be a bit silly! I'll just shut up now and get back to my work ;)

r0lZ

20th May 2006, 19:02

Yes, LUK!, I thought at that also. But writing null sectors at the end of the ISO should give the same result, no? But it doesn't help reduce the noice, though. Anyway, the noise is normally not a problem with a standalone player.

windtrader

20th May 2006, 23:33

I've been doing a fair amount of research into this somewhat esoteric topic and found the most relevant technical information in a document titled "ECMA Technical Report /TR71 dated February 1998. It is very detailed and has data field descriptions and specifications to the BIT level. I also went down the mkisofs hole but it dead-ended since I could not find any information about how it internally handles reading the DVD disc. There are DVD disc reading procedures in the previous document.

TR/71 section - ECMA-119 Directory Structure ad Path Table 3.7
This section shows the DVD physical file structure. Annex B describes the logic to read the DVD. It appears there are only three specific sector addresses where data is expected:
Primary Volume Descriptor, logical sector numbers 0-15,
Volume Recognition at sector 16 and
Anchor point at sector 256.

Everything beyond appears as vector based structures (FIB and ICB seems to be the key vector tables to the actual file data) so it might be possible to physically layout the files in any order as I did not see a specific reference stating the files must be written in a certain order. However, all examples (UDF FIle Structure - ref table 21, figure 7) show the following order:

VIDEO_TS.IFO VIDEO_TS.VOB VIDEO_TS.BUP VIDEO_TS_01_0.IFO VIDEO_TS_01_0.VOB VIDEO_TS_01_0.BUP
etc. etc. etc.

I'm sure with all the various DVD formats it's possible some DVD Player software make certain assumptions / interpretations that cause the player to fail to read some of the formats like this one.

Having a better apprecation for all the CRITICAL control data stacked at the front of the disc, it is also fairly obvious to me the condition of media that gets a nick in this area - *COASTER*.

As stated in other replies, the menu VOB of a DVD provides the IFO and BUP physical separation. The larger it is, the better chance the player is able to use one of them to keep navigating the disc. But many backed up discs are strpped of their menu, resulting in the IFO and BUP being physically adjacent and if one is bad, so is the other. Thus the rational behind the 32k fix.

So, how much physical separation is there really in a 32k gap? I'd argue that it is so small it basically provides no practical improvment in integrity of the VMG structure. I'm no physicist but it must be so small it is not visible to the naked eye, especially being at the inner ring . Maybe making the buffer large enough to create some reasonable physical separation would make this fix work on a practical level.

I did not come across any reference to any back up strategy for the first three critical DVD data structures; thus, I'd argue the whole concept of BUP backups of the VMG are of no practical value. With unreadable area at the front of the disc, it seems practically the chance of any of the disc being readable and useable is very low. However, I can see the potential benefit that the main movie vobs ifos and and bups would help the player keep going if encountering a bad IFO or BUP.

I did not write this to devalue any of the good work or intentions of the 32k patch since I know the spirit of it is to better the world for us DVD backupers. I'm just stating my analysis leads me to an opinion that the amount of real world, practical improvement of this specific patch is nonmeasureable or at least very unlikely to be actually useful.

blutach

21st May 2006, 04:11

I have some sympathy for what you are saying windtrader. Oftentimes we find an unplayed menu file of 358k and others of 38k (weird sizes), including a (sometimes) unreferenced VIDEO_TS.VOB of these sizes - all designed to give maximum chance of at least one of an IFO or a BUP being able to be read.

But, no doubt, a badly damaged DVD will have troubles irrespective of gaps - we've all had problems with these.

Regards

r0lZ

21st May 2006, 10:40

I agree.

Perhaps I could modify the 32K gap method to use a larger gap whenever possible. But I don't want to push the real data too far to the outer edge, because this part of the DVD is more subject to defects and damage.

dirio49

21st May 2006, 18:18

maybe give the user a choice to how much they want to seperate them?:D

windtrader

22nd May 2006, 03:59

I did some more thinking about how large a buffer should be placed between the VIDEO_TS.IFO and it's BUP if there is no menu VOB.

The sizes we deal with DVD is really amazingly minute and it is a wonder any of this works at all. As you know the binary on/off is implemented by "burning pits" into the media. The track pitch (width) is 74 microns; 1,351 fit in one mm. A tiny visible spec/defect would span many tracks. The placement of the main IFO/BUP is separated by the main VOB. Since there are only a handful of these VOBs there is quite a physical distance between them and it is easy to understand how effective this can be.

The problem with the VIDEO_TS IFO and BUP is that you really can't create a big enough buffer to be effective, like the main vobs. Since you won't make a large buffer that would create the physical separation along track pitch, another option would be to try to place the IFO and the BUP 180 degrees away from each other; in other words, place them directly across the disc from each other.

I did some calculations, that are not exact, but pretty close, as I cross referenced them to a few sources and they seemed to be in the ballbark. Based on these calcs, I determined that the target buffer size should be about 29,158 bytes.

Note: I found a late reference that states the location of the lead-in is at 45mm. I based my calcs on 48mm, so the size may be a little smaller, closer to 27,070 bytes.

Kind of funny after doing all that work, it is pretty damn close to the 32k that is used but based on an entirely different rationale.

cheers!

DVD (120mm) Capacity
total bytes 4,700,000,000
Mbytes 4,700
Mbits 37,600
max read rate (mbits/sec) 10.8
max read rate (mbytes/sec 1.35
seconds of stream 3,481
minutes of stream 58

rev/
recording location limit(mm) circum(mm) RPM sec
outer 116 364 1,389 9.57
middle 82 258
inner 48 151 574 23.15

recording width - mm 34
microns per mm 1,000
track pitch - micron 0.74
track density / mm 1,351
total tracks 45,946

travel (mm) / sec 3,491
bits /mm @10.8mbs 3,094
bytes/mm 387
semi-circle dist @ inner 75
bytes in 1/2 circ.@ inner 29,158

* lead in is at 45mm, lead-out at 117mm

r0lZ

22nd May 2006, 11:07

OK, so the actual 32K gap is just fine! Therefore, I will not change the current method.

However, note that the gap before VIDEO_TS.BUP is increased (sometimes by a very large amount of sectors) when a DL-DVD is used. It's needed to align the LB cell properly, and to put at least the same amount of data on L0 than on L1. In this case, of course, I can't choose the size of the gap freely.

Thanks for your investigations!

frank

22nd May 2006, 11:39

Originally posted by mpucoder:
So ensuring 32k between ifo and bup is the simplest solution to ensure they are in different ECC blocks.Yes! That's it, no more.
Originally posted by rOlZ:
OK, so the actual 32K gap is just fine! Therefore, I will not change the current method.:goodpost:

BigCondor

21st November 2006, 12:33

I have a problem of burning with PgcEdit.
Recently I tried to burn dl disc and I decided to follow the guide and I did succeeded burning a dl disc after failing one time.
Now this time I tried to burn another one. After loading the movie (6.1G), I checked the 32k gap option I press the burn logo, it asked me to save the project and then did not do anything else. Then I checked the burn DVD setup, everything seemed ok but still there was no action. Then I brought up the ImgBurn to check the disc and when I press save, at times an error message would show as follows:

invalid command name ".burn.opts.burn"
invalid command name ".burn.opts.burn"
while executing
"$w.opts.burn configure -state normal"
(procedure "validate_burn" line 18)
invoked from within
"validate_burn"
(procedure "::burn::setup" line 248)
invoked from within
"::burn::setup ."
(menu invoke)

and afterwards that the program will stop to function and stopped there after the error, refusing to return to the main program.

So, what could probably wrong? I had reinstalled ImgBurn and even installed another window but with no luck. I had also tried two versions of mkisof.exe.

r0lZ

21st November 2006, 15:16

It's probably a bug in PgcEdit. I'll try to fix it. Thanks for the report.
BTW, are you running Windows XP?

In the meantime, you can burn your DVD-Video files with ImgBurn v2, as it has all the features present in the burn function of PgcEdit. You can even burn your files directly, without having to write the ISO on HDD first. PgcEdit is not necessary any more to burn a DL DVD.

BigCondor

21st November 2006, 16:10

Thanks for the prompt reply, I'm running XP.
I'll try to burn it with ImgBurn later.

canuckerfan

21st November 2006, 22:58

if an iso image is crated of a dvd using the guide on the first page, does it matter which burning software is used to burn the image? or is imgburn still preferred?

r0lZ

21st November 2006, 23:15

If it's a DL, you MUST use ImgBurn. For a single layer, you may use whichever program you have, even Ner0 if you really want so.

wraithdu

12th December 2006, 06:47

After reading through several threads on this topic, I have a few questions. I'll try to separate them out as best I can.

1a. Regarding ImgBurn v2. It was stated above that it has all the burning capabilities of PgcEdit. Does this mean I can burn single layer dvd files directly (without creating an ISO first), and ImgBurn will create the 32K gaps?

1b. If the answer to 1a is no, will ImgBurn v2 create the 32K gaps for me if I create an ISO first? Or is PgcEdit still required to create the 32K gaps, then ImgBurn to burn?

2a. I've been using CloneDVD2+AnyDVD for quite some time now. Does anyone know if CloneDVD2 writes the 32K gaps? This program can be used to write existing DVD files (IFO+BUP+VOB), so this would be useful knowledge.

2b. Is the a way to verify the 32K gaps have been written to a DVD? I know a hex editor can be used to verify this in an ISO, but what about a finished burned DVD?

Thanks for all the info. I swear I learn something new every day around here...

blutach

12th December 2006, 07:14

1a. Yes
1b. N/A
2a. Don't think so - could be wrong.
2b. Read the DVD in DVD Decrypter in ISO Read mode. Then use ISOBuster. But ImgBurn (www.imgburn.com) certainly does.
3. If you are at all worried about gaps not being written, then use VobBlanker (http://jsoto.posunplugged.com/vobblanker.htm) - latest beta to create "smart gaps".
4. Welcome to Doom9!

Regards

r0lZ

12th December 2006, 10:08

2b. You can also verify the start LBAs of all DVD-Video files with DVD Decrypter. They are reported in the log in debug mode. To enter Debug Mode, press the F6 key. Then, you have to eject and reload the DVD, to force DVDD to update the log.
If the 32K gaps are used, the IFO and BUP must be separated by at least 16 sectors.

wraithdu

12th December 2006, 22:04

Thanks so much for the quick replies. Being the type of guy that likes to see things for himself, I made some test burns today, and here are the results.

I did a quick re-author in shrink so I had a DVD that would exhibit the problem, ie no video_ts.vob file. I burned the files with ImgBurn v2, Nero 6.6.1.4, and CloneDVD2 2.9.0.1. I then viewed the burned DVDs using DVD Decrypter's debug mode (a very handy feature).

ImgBurn, as stated above, burned correctly, inserting a 16 sector gap in between the video_ts.ifo and .bup. Nero 6 and CloneDVD2 both failed this test. Both of those programs burn the files contiguously.

So there we go. Looks like I'll be switching to ImgBurn for all my burning needs. Thanks again!