IFO editing when re-encoding and producing an extra VOB

[Inspector.Gadget]

Hi all,

I have what may be a simple problem here. I'm re-authoring a DVD here that totals about 3.6 gigabytes; because I am re-encoding the main movie anyway, I'm increasing the video bitrate to take advantage of the additional space on a DVD-R. This leaves me with a new VOB (VTS_01_5.VOB) because of the .99 G VOB filesize limit - in other words, the titleset (and its only PGC) are now spread across VTS_01_1.VOB thru VTS_01_5.VOB instead of VTS_01_1.VOB thru VTS_01_4.VOB. How do I account for this when retaining the original menus, etc. using IFO files modified by IFOEdit?

So far what I'm doing in IFOEdit is getting the VTS sectors, setting the playback dimensions for Title 1 to 16:9 rather than 4:3 in VIDEO_TS.IFO and VTS_01_0.IFO, killing playback of FBI warnings, modifying the subpicture status of the main movie to make each subpicture capable of display in a letterboxed situation, etc. Is there a simple switch or method to remap the Title and PGC playback to occur across 5 VOBs instead of 4?

Many thanks in advance.

[r0lZ]

The number of VOB files is not written in the IFOs. Only the overall size of the domain matters (for the VTS sector pointers). Of course, there are many tables in the IFOs with pointers inside the VOBs, but all pointers are always relative to the start of VTS_XX_1.VOB (for the title domains), or to VIDEO_TS.VOB or VTS_XX_0.VOB (for the menus). That means, for example, that the cut point between VTS_01_1.VOB and VTS_01_2.VOB can be everywhere (as long as it is at the beginning of a sector and preferably of a VOBU and that no VOB file is larger or equal to 1GB). You can even divide the video file into 9 smaller VOB files if you wish, without having to modify the IFOs.

But you haven't explained exactly how you did the reauthoring. The IFO files MUST be created by the authoring program. You cannot simply replace the VOB files by the reauthored ones in the original DVD, as the pointers within the VOBs will be wrong. The VTS sectors computed by IfoEdit are the pointers to the beginning of each domain, but IfoEdit cannot recompute the pointers to the cells and VOBUs inside the domains. If you want to import a single title domain into an existing DVD, use PgcEdit's Import VTST Titles function. It takes care of everything automatically, but you need to have an IFO with your reauthored VOBs.

[Inspector.Gadget]

Thanks, rolZ, that makes sense. If I use the method in PGCEdit that you describe, will that break the (subtitles and chapters) menu contained in VTS_01_0.VOB?

[r0lZ]

No, if your reauthored title has exactly the same number of cells than the original. In that case, PgcEdit offers to keep the original structure unmodified. (It fixes only the pointers to take the new VOBs into account.) But if the number of cells is different, PgcEdit cannot guess what chapter corresponds to what cell, and it takes the chapters, the cell commands, still times etc... from the reauthored IFO. Usually, there is one chapter per cell in the new IFO, and that might not be the same thing in the original DVD.

So, to be on the safe side, be sure to create the same number of cells cells than in the original DVD. That's easy with most encoding/authoring programs, if you can import the "Celltimes.txt" file to specify the chapter points. You can generate that file with PgcEdit too (from the PGC Editor).

Similarly, the subtitles and audio menus will continue to work normally if you reauthor the new title with the same number of subpic and audio streams, in the same order.

[EDIT] I realize now that I have made a mistake in my previous post. The function to use is not Import VTST Titles (which creates a new VTS) but Replace VTST Titles (which replace the titles of an existing VTS by the reauthored versions of the same titles).

[Inspector.Gadget]

Ah, perfect, that answers my question. I will import the Celltimes when encoding in HCEnc and when initially authoring that title in IFOEdit before I use it for your method. Thanks very much for your help.

[Ghitulescu]

I think that you simply waste your time, unless you're doing this for learning purposes.

Increasing the bitrate of an already existing DVD (as well as any editing upon it) would do nothing more than decrease its quality due to repeated decoding/encoding steps. You may have a bad DVD, which needs eg colour balance, in this case you can do a reencoding. Also, extending the DVD size to fill in the whole DVD has a secondary negative side effect, ie the more data on a DVDR, the higher the possibility of having bad burns at the edge.

Or you may combine two DVDs on a DVDR DL (eg 3.6GB + 4.4GB)

[r0lZ]

I agree totally, but Inspector said "... because I am re-encoding the main movie anyway", and "... setting the playback dimensions for Title 1 to 16:9 rather than 4:3". I suppose his goal is to convert the main movie to wide screen format, and that's a good reason to re-encode it IMO. OK, the resolution lost during the original encoding in letterboxed format cannot be magically recovered, but it might be more pleasant to watch the movie in true 16:9 than to have to zoom in the letterboxed image, and the resize performed by avisynth is probably better than the hardware zoom of the TV.

Anyway, as you said, learning how to replace a title by a re-encoded one is a good thing. I do it often, for various reasons.

[Inspector.Gadget]

Thanks guys. I am mostly doing this for learning purposes, but also to fix a particularly silly commercial DVD. The NTSC R1 DVD of "Kids" 1995 is a ~16:9 film image matted into a 4:3 frame and has not only ugly top and bottom borders but soft, uneven left and right borders. The end result is that displays (be they 4:3 TVs or 16:10 HDTVs) without some sort of advanced zoom function end up with a tiny image. So I'm cropping all that junk out and sizing the remaining image from the 640xX 1:1 PAR image to the appropriate 720xX width (realizing that this is actually ~853) and height and then padding the height out to 480 with AddBorders(). The film transfer was pretty low-quality to begin with and the visual quality difference is negligible except for the fact that you can now see everything properly on all types of displays