Rivergate Software Inc. - makers of DVDAfterEdit

I've emailed them that i want the stamper house to re-do the eclipse test without aborting early. We will see what the COMPLETE log files are saying.

moreover I've sent safety copies with, which they haven't tested at all after the failure of the first ones.

this morning I've looked through the whole final dvd I got from the german replicator again. There is nothing missing or any other technical error. The masters for usa were created exactly the same way.
So how could that VOBU lenght error happen? What leads to it? And more importantly, how can i make sure to fix it before multiplexing again for new masters that are going out for testing and on DLT finally if the new eclipse test go wrong as well.

thanks,
sincerely,
silvio

man, this is a great board ! :) thanks so far

ok lets see... some more details on this case:

- the screens were originally named .....(2) and .....(3), so there is at least one more sheet they havn't sent me

- the second screen you are seeing is the dvd5 master i think. (can't exactly check right now cuz I'm still at work... but it should be the dvd5)

- also the first screen shows only "layer0" ... so the protokol for the layer1 is missing.

- So you said that the "ddp on disc detected..." isn't an error. But they marked it as an error and its labeled "f" (stands for failure ??) it seams that the person stopped the testing cause of that like Ian said.

- and how Ian pointed out even before ... maybe they are tried to directly read from the dvd-drive instead of copying the data to harddisc. Can you see that from the screens ???

- like danny said, I've overwritten two assets (5 and 3 mins length) (dvdsp was closed and i first encoded the m2v and ac3 onto another directory but then deleted the actual files linked as the asset and copied the new ones into the directory). then it refreshed it once i reopended dvdsp. (excact same length and size!)
I also had to do this on the masters before multiplexing that went to the german replicator. And it didn't caused a problem there.
Moreover on the masters for the usa the multiplexing go through without an error message as well of course and then burning a test dl-dvd worked just fine.
I've also even reunited the layer0 and layer1 of the ddp masters to get out the _TS folders and burned it again on dl-dvd. worked fine again!
That leads me to doubt that there can be a multiplexing error somehow.
Couldn't it be like Ian said, that that error message was created because the user terminated the job before completed ?

- I did not use the reuse funktion. Made a clean new multiplexing and then formating to harddisc. Also turned off the buffer underun while burning the masters ^^

- I've fixed some minor stuff with mydvdedit like the region code and opened the project with dvdafteredit demo to test whats possible with the demo version (which is really great btw. I definitely need to buy it for further projects!!!) found no errors there as well...

- The masters were sent out to danny for testing with dvdafteredit. He checked everything trough and found no mistakes. Then I realized two mistakes in crediting onscreen and had to multiplexed again (thats the 2 assets i had to change) this masters were sent to germany. the final products are working! ... turned out I somehow took one of the asset from the old directory in the hurry and now still have the one spelling mistake on the german dvds (lol)
That's why I had to multiplex again for the usa masters to correct that. I did everything excatly the same (with all possible testing and whatnot) damn, the masters just have to be fine... it doesn't make sense.

the replicator in germany uses an other testing system. I forgot the name because it sounds a bit strange i think.

I'm sorry for the long text guys ;) thats probably all details about everything...

whould you think the masters are ok and the eclipse user did something wrong cuz of the details i just written down???

I have to email them what I want them to do now...
Should they test the masters again (I've also sent safety copies and as it seams they didn't used them at all after the errors...) they would have to send them out again to the glass stamper house...
Making completely new masters and get them tested and exported onto dlt tape by danny would take way longer of course, but may be the only way in the end. (but whos gonna pay for that? we or the replicator?)

thanks so much. we really appriciate your help right here!
sincerely,
silvio

First, there is definitely a muxing error. The operator can't affect that.

The second log is actually just page 2 of the first log. Too bad it such a poor scan of the paper, instead of the actual log. Perhaps it was the second layer of a DVD-9. Or the result of canceling, since it seems to be almost completely lacking in information.

You also said there were two DVD's - where's the report on the second? And, as Ian said, what version of Eclipse are the German replicators using? Have they turned off VOBU length checking? All of this is in the log files, which replicators should be required to send to the customer when there is a problem. It's just a tiny text file, and there is an Eclipse option to name and save it before starting an operation. However many replicators run bare-bones operations, where the operator doesn't have a clue when something goes wrong, and they would have to save the log on a floppy and go to another computer to email it.

Even the other replicator is on Eclipse 4.0, instead of 4.1, which is where checking for a non-seamless layer break was added.

Larry

Hi Silvio,

A VOBUs is a Nav Pack sector and all the sectors that follow until the next Nav Pack, and contains about 1/2 second of video and audio. The first log is telling you that the Nav Pack thought there should be 283 sectors of data in the VOBU, and there were only 88 sectors. So the other sectors were probably thrown away by the muxing program.

We recently encountered a case where many shipping Universal Studio DVD's in Benelux suffer from this problem, but it is harmless because the offending VUBU is never played. The bad VOBUs were logos and warnings, and not part of the main video. They were obviously improperly copied between DVD's. In each case, there were two cells in the PGC and a cell command after the first cell to return to the post commands, so the bad second cell was never played.

I believe this error was first added in Eclipse 4.0, and those DVD's were probably made by an earlier version.

It's too bad the replicator didn't finish the test in case there was only one problem, or many. The second log shows no error at all. If you could have them rerun the test and send you the log file, I can load the log in Eclipse and examine the report in great detail.

I sent a bad VOB from one of the Benelux DVD's to Ian, and he was able to repair the offending video with his demuxing tools, rebuild the VOB, and send it back to me. Then I replaced it, redid the DDP with DVDAE, and it verified without errors in Eclipse.

Many replicators have not updated their Eclipse software, so there will be great differences in which errors they detect. They can also change the rules to allow certain errors to pass. The logs above were made with Eclipse 4.0 Image Copy. They could run Image Analysis (so it didn't bother to write to hard disc) and allow it to finish the entire log, which can even be read by TextEdit, though it is much easier to read in Eclipse. I am running Eclipse 5.0 and 6.0 HD beta.

You are welcome to send me DDP's on data DVD-R's, and I can examine them for you.

We are adding more checks, including the VOBU length validation, to HDAfterEdit.

Regards,

Larry

Hi Silvio,

Perhaps the replicator doesn't realize that they must copy the DDP folders from the DVD-R's to their hard drive first before Eclipse will see them. This is because Eclipse only uses DVD drives for mounting images, and does not use them as ordinary data drives, like Windows or Finder would.

If they are not using Eclipse, forget it.

Regards,

Larry