Video DVD: Link identical vob-files to same data

[Michael Butscher]

Hi,

 

I want to copy a DVD which was created by a DVD/HD-recorder which sometimes creates multiple titlesets which point to the same data (e.g. "VTS_01_1.VOB" is the same as "VTS_02_1.VOB"). It does that when recordings with different qualities (more exactly different resolutions like full PAL and half PAL) are on the same disk, one TS per resolution.

 

Unfortunately the direct copying by reading in the DVD as ISO file, then burning it doesn't work (other DVD-players read the copy without problems, but the recorder does not). Burning a new Video-DVD with the data of the old one does work (with some restrictions), but of course not with such double- or triple-titlesets which make a normal 4,7 GB DVD look as if it contains 9 or 13 GB.

 

I know that ImgBurn can create such hard-links for data DVDs with identical files, but for Video-DVDs it seems not to work.

 

Any hints what I can do?

 

 

Thanks!

 

Michael

[dontasciime]

try dvdshrink reauthor mode and a program called fixvts

[LIGHTNING UK!]

Unfortunately the direct copying by reading in the DVD as ISO file, then burning it doesn't work (other DVD-players read the copy without problems, but the recorder does not).

 

That's a little weird, it should do!

 

I had to force the detect duplicate files code off when building DVD Video because of the whole IFO/BUP thing.

[blutach]

This is a function of really crappy basic authoring programs built into recorders/cameras. They often have redundant data. So don't expect them to be professionally authored like a commercial DVD which uses Scenarist or the like.

 

Now if the data is the same in VTS_02_1.VOB as VTS_03_1.VOB, they are in 2 different titlesets. There's nothing that can be done other than reauthoring the redundant data out. You can't point the files at different data - this will screw up the structure of the DVD. And, as you have observed, the video might be the same, but one VTS might be full D1 (720x576 for PAL), the other half D1 (352x576). This is not the same data! (although it may appear to be so). And each VTS can only have one resolution and aspect ratio.

 

So, right now, your choices are:

 

1. Author out redundant data (blanking unwanted titlesets) - VobBlanker can help you. If you decide to do this, ensure you know which data is the one you don't want. A trace in PgcEdit can help here.

2. Just burn what you have.

 

Regards

[Michael Butscher]

Thank you for your hints!

 

Fixvts + dvdshrink did not work, dvdshrink refuses to read the data despite of fixvts preparation, but VobBlanker did the trick.

 

As blutach described it, it removes the unused data from the titlesets resulting in DVD data of similar size (even a bit smaller) than the original hardlinked DVD. It is not even necessary to select any titles or cells to blank out, VobBlanker knows which cells are used by which titleset and removes the rest.

 

If somebody with the same problem reads this:

Differently from the default settings in VobBlanker

- check "Fix always VOB SYNCI/SRI pointers in Titles" and "Fix ... in menus" in the "VOB internal pointers" section.

- uncheck "Update STC discontinuity flag according VOB" in the "VOB layout" section.

 

With the default settings I had a problem with the very first cell of the first title, it had a wrong length information.

 

 

Michael

[dontasciime]

I have no probs using shrink + fix normally but can remember 1 issue whereby I also had to use vobblanker.

 

good news you got what you needed.

[blutach]

- uncheck "Update STC discontinuity flag according VOB" in the "VOB layout" section.

Why? The VOB's mastering should point to whether this flag should be set.

 

Regards

[Michael Butscher]

- uncheck "Update STC discontinuity flag according VOB" in the "VOB layout" section.

Why? The VOB's mastering should point to whether this flag should be set.

 

 

In the meantime I found out that the main problem was that I made a full scan of the VOBs before processing them, somehow this confuses VobBlanker a bit. Probably the switches aren't so important, sorry.

 

 

Michael