ImgBurn 2 shortcoming with sector correction in IFO

[fordman]

This not really a bug, so I've posted it here in support. Both IFOEdit and PGCEdit are capable of parsing the sector addresses and sizes on VIDEO_TS.IFO and will correct sector addresses that do not match the file size. PGCEdit does this silently while IFOEdit returns an warning message. However both reduce the file size (all that I've seen) of VIDEO_TS.IFO (and VIDEO_TS.BUP of course).

 

I built an image with ImgBurn 2.0.0.0 last night that I did NOT use PGCEdit on first, as there were no PUOs that I needed to turn off, nor any other adjustments to be made. ImgBurn happily made the image, which I mounted with Daemon Tools and then used QuickSFV to create CRC signatures, which I subsequently compared against the source files. All compared except for VIDEO_TS.IFO and VIDEO_TS.BUP. I noticed that Imgburn was changing a sector address, and as it apparently does so on the fly without altering the source files, the miscompare was not expected.

 

However, out of curiosity, I decided to run the source files through PGCEdit and noticed that the VIDEO_TS.IFO and VIDEO_TS.BUP were shortened from 16K to 12K. I restored the original files and performed a "Get VTS Sectors" in IFOEdit. I received the following warning, which I've seen before, and from my research is likely the result of re-authoring and once corrected is nothing to worry about:

 

"There's something wrong!

The IFO Endsector does not match the file size."

 

The resulting VIDEO_TS.BUP and VIDEO_TS.IFO are again 12K, as with PGCEdit, though the CRCs are different between the two programs, but likely due to the 32K option being turned on in PGCEdit. Meanwhile ImgBurn ignored the fact that the sectors were not consistent with the file size.

 

Anyway, I realize that PGCEdit has undergone extensive development, and ImgBurn's image creation engine is in its infancy, and may not be intended to do all the things that these other utilities do to "fix" the source files. However, I saw mention by some that PGCEdit would no longer been needed with the advent of the ImgBurn build mode. My recommendation would be for the short term, at least, to continue running your source files through PGCEdit until/if this feature is included in ImgBurn. Of course PGCEdit also has the handy "fix streams" function that gets rid of the bogus extra audio and subtitle streams produced by some reauthoring packages, most notably CloneDVD from Elby.

 

Ford Man

[LIGHTNING UK!]

I think this is the same problem mentioned in the 'bugs' forum.

 

Namely, incorrect (or in my case, very weird!) calcualtion of IFO size, as then written to offset 0x1C in VIDEO_TS.IFO / BUP.

 

It wouldn't matter if you had run the files through PgcEdit. If the 32k padding comes into play, ImgBurn would change stuff and put the wrong value in the IFO.

[blutach]

Hi fordman

 

Can you explain why the IFOs would be reduced in size please? If you turn 32k gaps on, the only thing that changes in VIDEO_TS.IFO is a few pointers in VMG_PTT_SRPT

 

I have seen this IfoEdit error message before in badly authored and ARccOS DVDs (bogus VTSs).

 

But, I really wonder how VIDEO_TS.IFO can shrink so much.

 

Furthemore, if some of the IFO was being "chopped off", I seriously doubt the DVD would play.

 

All my tests on build (and I have tested a few of them) look and perform perfectly.

 

Maybe I am not understanding you correctly. But, we will get to the bottom of this, as it is very important.

 

Regards

[LIGHTNING UK!]

I know we posted at the same time blu but this is one of the bugs fixed in the betas you're now using.

[blutach]

@LUK - Why is there a need to change that offset?

 

EDIT: LOL - OK. Will pay special attention to this.

 

Regards

[LIGHTNING UK!]

It's all part of the fix vts sectors bit of code.

 

I have to update 0x0C offset for end of BUP, I then just updated this one too for good measure - the two seem to go hand in hand.

 

I made a mistake and calculated it all wrong. Silly me! I guess I am only human after all

[blutach]

I think that was the error (not the human bit - I see your edit!!). Last sector of VMGI (0x1c) should be the exact size (in sectors) of the VIDEO_TS.IFO (-1 of course as things start at 0).

 

Last sector of VMG (0x0c) is the number in 0x1c times 2, plus 1, plus size of VMG VOBS plus padding (if any).

 

But, I am sure you know this.

 

Regards

[LIGHTNING UK!]

Yeah that's how it is now.

 

value at 0x0c is just last lba in bup - first lba of ifo. I believe that was was already ok.

 

For Last Sector of VMGI, I'd taken sectors in IFO (-1) and added amount of padding (in sectors) applied to BUP. I honestly have no idea why! lol

 

As it's normally 0 unless there's no VOBs or a small VOB, it's not a problem that occurs every time you build.

 

Oh and I don't always remember everything - again I'm only human - when that happens I just look on mpucoders site!

[fordman]

I think this is the same problem mentioned in the 'bugs' forum.

 

Namely, incorrect (or in my case, very weird!) calcualtion of IFO size, as then written to offset 0x1C in VIDEO_TS.IFO / BUP.

 

It wouldn't matter if you had run the files through PgcEdit. If the 32k padding comes into play, ImgBurn would change stuff and put the wrong value in the IFO.

 

LUK and blutach:

 

[LUK] I believe you are referring to the following post in the bug form:

 

http://forum.imgburn.com/index.php?showtop...amp;#entry21926

 

Does the currently mirrored 2.0.0.0 version have this fix included?

 

However, I looked back at the source files and all VTSs have 100K or more of VOBs associated with them, so the 32K padding never came into effect. Both PGCEdit and IFOEdit are apparenly only performing the correction that LUK mentions, but apparently these programs do the opposite - adjust the IFO file size to match the size written in offset 0x1C? Since 32K padding is not in play, I'm unsure why there is a difference between the .IFO/.BUP files written by PGCEdit and IFOEdit. In the past if 32K was not needed (or if I turned off the option in PGCEdit), then repaired files from both utilities would match exactly. Is there any utility that will provide a side by side comparision of IFOs in a format similar to IFOEdit's display? Binary comparison wouldn't help me much.

 

I found a detailed explanation of this almost a year ago and can't seem to locate it again. Though I did find the following, excerpt from the IFOEdit author:

 

"If the error: "There's something wrong...with end sector" apears,

then go into the table 'VTSI_MAT', and adjust some of the table-start offsets, and try to resave the IFO file.

This error happens, because if you strip something away, and the IFO tables gets corrected with IfoEdit, then it might happen that the new table is much smaller then the old one, what changes the start-offset for it."

 

at: http://forum.doom9.org/archive/index.php/t-13084.html

 

So, LUK - instead of the PGCEdit/IFOEdit approach of changing the file size to match the end sector (if that is indeed what it's doing), you will change the end sector to match the IFO file size?

 

Since my DVD didn't require 32K padding after all, this seems more likely due to poor authoring versus anything that ImgBurn was doing, so your beta that is in blutach's hands likely wouldn't fix this, correct?

 

Tonight I plan to restore the source files, run them through PGCEdit to perform the fix, and re-build the ISO with ImgBurn. Since the 32K padding is not in play, then this should work OK with my 3rd release ImgBurn 2.0.0.0, right?

 

I suppose it's best to continue using PGCEdit/MKISOFS to build DL images that required 32K padding until the beta with the fix is released?

 

Thanks,

Ford Man

[LIGHTNING UK!]

No v2.0.0.0 has this fix, it's only in the betas.

 

Well if the problem is not what blu and I have been talking about, it's not something ImgBurn would/should really fix.

 

If your input files are wrong, they're wrong! You'd have to blame that on whatever made them in the first place. I could implement some basic checking but then it could easily get out of control and I'd soon find myself attempting to do the same job pgcedit does - which of course is not the idea of ImgBurn.

 

Yes you should stick with PgcEdit until I release the fix if you're doing images that require padding.

 

 

Oh and about changing size to match other sizes... I'd change the data in the IFO to match the physical size of the file. Your IFO processing tools are probably correct in the way they change the size to match the ifo data. We're just attacking problems from different angles.

[fordman]

Hi fordman

 

Can you explain why the IFOs would be reduced in size please? If you turn 32k gaps on, the only thing that changes in VIDEO_TS.IFO is a few pointers in VMG_PTT_SRPT

 

I have seen this IfoEdit error message before in badly authored and ARccOS DVDs (bogus VTSs).

 

But, I really wonder how VIDEO_TS.IFO can shrink so much.

 

Furthemore, if some of the IFO was being "chopped off", I seriously doubt the DVD would play.

 

All my tests on build (and I have tested a few of them) look and perform perfectly.

 

Maybe I am not understanding you correctly. But, we will get to the bottom of this, as it is very important.

 

Regards

 

Hi blutach,

 

Your guide about authoring with 32K gaps is what got me started on that, back when I was only doing single layer burns with Imgtool Classic - thanks so much for that!

 

As this discussion progressed, it seems LUK and I agree that this has nothing to do with the 32K bug in ImgBurn, as my DVD didn't need it.

 

Instead, this seems to be related to the type of issue that I've seen periodically. I believe that I have encountered it most often on single layer images. This makes sense since Derrow, the IFOEdit author states that this error is usually due to a package that is used to strip content (like trailers, DVD extras, etc.) in an effort to get it to fit on a single layer DVD recordable. Apparently it strips the content, without updating the sector sizes in the VIDEO_TS.IFO file? So, the re-authoring package is only paritally doing its job, and either IFOEdit and PGCEdit finishes the job, by deleting the references to the now missing content in VIDEO_TS.IFO, and correcting the ending sector information accordingly. Thus the VIDEO_TS.IFO/BUP files also shrink as a result of the deleted information. Despite the seemingly large reduction in size (25%), this has never been a problem, and all DVD features play fine (unless they were stripped, of course).

 

Anyway, that's my understanding from the Google searching and reading I've done. So, it's not due to the 32K padding ImgBurn bug. It's simply that ImgBurn doesn't update the IFOs to "finish the job" of accounting for the information that was stripped from the DVD.

 

Ford Man

[LIGHTNING UK!]

If it's just empty space at the end of the ifo anyway, I can't see as it's all that important.

 

So long as the real size matches what the IFO's say (i.e. if it's 32k, the ifo says it's 16 sectors), that should be all that matters.

 

It looks to me as though the IFO tools are just wiping out the empty space at the end.

[fordman]

If it's just empty space at the end of the ifo anyway, I can't see as it's all that important.

 

So long as the real size matches what the IFO's say (i.e. if it's 32k, the ifo says it's 16 sectors), that should be all that matters.

 

It looks to me as though the IFO tools are just wiping out the empty space at the end.

 

I suppose it's the IF that I'm not sure about. Is it really empty space, or is it the remnants of VTS info from titles that no longer exist? If it's the latter, it seems that it should be deleted to be consistent with the actual VOB content. The discussions I've read seem to indicate that's what PGCEdit and IFOEdit are doing. From a DVD structure standpoint, I'm sure you're probably correct that having that phantom info in there isn't a problem as long as it's never referenced.

 

I've tried comparing two such IFOs side by side in IFOEdit (for ex, a 16K original, and a 12K processed one) and couldn't find where the 4K went. It seems like the same "volume" of information was in each file. That's why it would be handy to be able to dump all that to a text file or otherwise do a side by side comparison.

 

The PGCEdit author seems to frequent your forums pretty often. Perhaps he could shed some light on his methodology?

[blutach]

Have a look at the IFO in a sector viewer. I saw a DVD the other day with an IFO was was 108K that had 58K of 00s at the end of it (in other words the tables ended at 50K but they decided to pad the IFO)! Very weird, but AFAIK, not illegal.

 

Regards

[r0lZ]

The PGCEdit author seems to frequent your forums pretty often. Perhaps he could shed some light on his methodology?

PgcEdit maintains each table separately in memory.

 

When the IFO is loaded, it is split into tables. The end-of-table pointer is used to remove the padding null bytes at the end of the table. (Recently, I have added some basic checks to ensure that the end-of-table pointer is coherent, since it is now necessary to cope with ARccOS and RipGuard crap.)

PgcEdit removes also completely the tables that are present but have 0 entries (for example VTSM_VOBU_ADMAP and VTSM_C_ADT when the menu has no video.)

When the DVD is saved back, the tables are padded and concatenated again (in the "standard" order defined by the pointers in VMGM/VTSI_MAT) to recreate the IFO. Unnecessary padding is never added at the end of the file.

This method implies that each table can be shorter than before. Therefore, all subsequent tables are shifted accordingly, and the final size of the IFO is decreased. Of course, the null padding sectors not included in a specific table are stripped also.

 

I'm not sure IfoEdit does the same thing. It is known to have very big bugs when a table grows too much, because it doesn't allocate a new sector. Another table is simply overwritten! I suppose it cannot shorten a table neither.

Anyway, with both programs, the additional padding sectors at the end of the IFO are stripped out.

 

Of course, each time a DVD is saved, PgcEdit recomputes the VTS sector pointers (with respect for the 32K gap option, and eventually for the layer break position.)

 

Note: It is theoretically possible to pad the IFO and BUP files to align the layer break with an ECC bloc, but of course, it's not suitable for the 32K gaps. Maybe it's a method used on some commercial DVDs?

[fordman]

Have a look at the IFO in a sector viewer. I saw a DVD the other day with an IFO was was 108K that had 58K of 00s at the end of it (in other words the tables ended at 50K but they decided to pad the IFO)! Very weird, but AFAIK, not illegal.

 

Regards

 

blutach - you are indeed correct.

 

I went and looked at both the 16K (pre-PGCEdit/IFOEdit or Post IMGBurn 2) and compared it to the 12K VIDEO_TS.IFO (post-PGCEdit/IFOEdit), and there are indeed all zeros at the end of the files.

 

For the 16K one, there are approximately 5K of zeros at the end, and for the 12K one, there are approximately 1K of zeros at the end. So the PGCEdit and IFOEdit tools are shortening the IFOs by deleting the unneeded zeros to the closest sector that does not contain all zeros, it appears.

 

So, it appears that LUK is correct that he could leave the files padded at 16K, and the PGCEdit/IFOEdit method is equally as valid, as long as the ending sector address is updated in the IFO.

 

However, in light of what r0lZ wrote in this thread about using the end-of-table pointer to delete the null bytes while working around protection schemes, I wonder if the ImgBurn method of leaving the padding will work in all instances? Perhapse the PGCEdit approach of shortening the IFO is the best if the DVD files happened to be from a formerly protected DVD?

 

Thanks for prompting me to look!

Edited August 10, 2006 by fordman

[blutach]

Padding at the end of the IFO can not do too much damage, I wouldn't think, even if it started off as a protected DVD.

 

Of course, they can be placed anywhere in the IFO, but if they are "in order" the final table will be the VOBU address map. Which is defined to end after a number of entries. Anything after that can be random bits of fluff as far as the player is concerned, if I am correct. Just so long as the file length is reported correctly.

 

Take off the padding vs keep it there - I really don't think it matters all that much.

 

But, except to the extent that this was a burning problem (and it started off that way), this forum is not to talk about IFO structures. We can do that elsewhere, without risking getting LUK! into trouble

 

Regards

[fordman]

But, except to the extent that this was a burning problem (and it started off that way), this forum is not to talk about IFO structures. We can do that elsewhere, without risking getting LUK! into trouble

 

Regards

 

Understood. However, I think we were talking about IFOs affected by stripped content. Surely that is relavent to homemade DVDs also? No risk I would think.

 

[r0lZ]

Padding at the end of the IFO can not do too much damage, ...

I'm not so sure. The BUP file is supposed to be an exact copy of the IFO. So, if you pad the IFO, you must pad also the BUP, or you will produce a non compliant DVD.

Padding also the BUP is not really a problem, but it will be impossible to add an odd number of sectors this way. Therefore, this method is not (always) suitable to align the layer break.

[blutach]

I'm not so sure. The BUP file is supposed to be an exact copy of the IFO. So, if you pad the IFO, you must pad also the BUP,

Sorry, I should have made myself more clear. You are obviously correct and in the padded IFOs I have seen, all the BUPs were also padded.

 

No risk I would think.

It's not your risk fordman, and I for one am not prepared to discuss IFO manipulation on this forum (and I don't think you are suggesting we do that either). Most people know where I hang out (doom9 and digital digest) and you can talk freely with me and other more knowledgable people there. I look forward to it.

 

Regards

[fordman]

No risk I would think.

It's not your risk fordman, and I for one am not prepared to discuss IFO manipulation on this forum (and I don't think you are suggesting we do that either). Most people know where I hang out (doom9 and digital digest) and you can talk freely with me and other more knowledgable people there. I look forward to it.

 

Regards[/color]

 

Sounds good. The risk I was referring to is the one you brought up, not any risk to me. This thread was merely pointing out that it would be nice if ImgBurn's build mode could fix the "damage" done to IFOs when content is stripped from a DVD (for instance one I author), like PGCEdit and IFOEdit currently do. I'm definitely not advocating any other purpose.

 

It appears that r0lZ has pointed out an instance where the padding may not always be the best approach for the .BUP files, so perhaps stripping the padding is truly the best...

 

I'll look forward to further discussions at the other forums!

 

Thanks

Ford Man

Edited August 10, 2006 by fordman

[ron spencer]

if 32k padding is off this is not an issue right?

[fordman]

if 32k padding is off this is not an issue right?

 

There are two issues that were covered in this thread:

 

1. My observation that ImgBurn does not strip the padding from IFO/BUP files and update the end sector in the IFO/BUP in the manner that PGCEdit/IFOEdit do.

 

2. There is a confirmed bug with updates to the IFO/BUP when ImgBurn requires padding to conform to the 32K minimum gap between files.

 

So, as long as you can observe that your files won't require 32K padding, or you have the option turned off regardless, then number 2 should not be an issue for you. I believe LUK is releasing a fix for this on the weekend. I've successfully burned two ImgBurn created dual layer images, and both were seen by AnyDVD as valid video DVDs, but neither one needed 32K padding (though I do have the option on).

 

On the 3rd image, I did some experimentation and observed the behavior in number 1. At first it was assumed (by me and then LUK) that this was related to the 32K problem. However, on re-exmination, that image didn't require 32K padding either. Instead, I was observing that PGCEdit and IFOEdit recognized that the end sector didn't match the IFO size and fixed it. Meanwhile ImgBurn ignores that mismatch and adds the IFO/BUP to the image untouched. Running this through PGCEdit first to fix the mismatch, and then making an ImgBurn image ended up doing the trick. Since I'd like to use Imgburn primarily for the nice time/date stamping of files in the created image, I'll continue processing the files in PGCEdit (open and then save) and then create the image with ImgBurn...

 

In conclusion, you will not experience 2 if you have the 32K option turned off, but you may experience the behavior described in number 1. This thread went on to debate whether that is a problem or not. However, since both PGCEdit and IFOEdit found that the existing end sector specified in the IFO did not match the IFO size, but ImgBurn retained both the specified end sector and the IFO size, there seems to be an issue, though it may be the same issue with updating the end sector that causes the 32K bug.

Edited August 10, 2006 by fordman

[LIGHTNING UK!]

Even if PgcEdit / IfoEdit do point out that the file is padded, I don't think there is anything 'wrong' with it.

 

The player is only going to read what it needs to so who cares if there's 4k of slack space at the end of it?

 

IMHO, there's no need to 'fix' the IFO files just because of a little slack space.

 

Of course if you have other bits wrong with your IFO files, that's down to whatever killed them in the first place.

 

When building an ISO, you generally assume the files were already ok for burning. I can't see an authoring program producing a VIDEO_TS set that just simply wouldn't play, that would be crap! (and I'm sure people would moan so they fix it).