GUI for dvdauthor error message - Inconsistent Timecodes!

[AMalsher]

Hi, I'm using GUI for DVDAuthor (GFD) to create DVD images from TV programs output from VideoReDo as .VOB files.
GFD requires these files be renamed as .MPG files.
I generally put three or four programs on one DVD, with a very simple menu of titles.
GFD meets my simple requirements perfectly, except that sometimes (once in 20 or so times) GFD gives a message like:
Inconsistent Timecodes! SCR=0.00 sec. GOP=6137.36 sec. ChapEditGFD will probably not work properly. GFD willuse SCR for duration..."
If I continue GFD displays the file as MpegType=1, MuxOK=yes, but then goes into an infinite loop. The BatchRun Log repeats:
"WARN: Skipping sector, waiting for first VOBU..."
The GUIAuthor.log contains only these lines:

Start CaptureConsole
Capture console running; Next command: cmd /k batchrun0.bat
Capture console running; Next command: cmd /k MMBrun1.bat
Capture console running; Next command: cmd /k MMBrun2.bat
Capture console running; Next command: cmd /k TS1Brun1.bat
Capture console running; Next command: cmd /k TS1Brun2.bat
Capture console running; Next command: cmd /k author.bat

I've search the forum, but can't see anyone else having this problem.
What am I doing wrong? Or is VideoReDo at fault?

Thanks for any suggestions
Alan

[guns1inger]

Repeat after me VOBS ARE NOT MPEG FILES

If you need mpeg files, why not output mpeg files from VideoReDo. VOBs contain more than just mpeg video, and simply changing the file extension doesn't make them so, any more than me calling you a horse will make you win the Kentucky Derby.

If you must output VOBs, use VOB2mpeg to demux them, then load them up and see if it helps. If it doesn't, use something other than VideoRoDO for a while.

[borax]

@guns1inger
You are right, VOB <> MPG. But the VOB file from VideoReDo are no vob files, but mpeg files with empty navigation packs as they are necessary for dvdauthor. There was some discussion about this topic in the VideoReDo forum i.e. naming this type of output mpg or vob, and finally (unfortunately) 'vob' was used).

@AMalsher
Sometimes VideoReDo seems to fail correct remultiplexing. In this case the SCR is reset to 0 (which is allowed BTW, but not supported by dvdauthor). The workaround is: Set up VideoReDo to output elementary streams (separate video and audio files) and use these in GFD. Mplex will then do the multiplexing (hopefully) correct.

[guns1inger]

When is a VOB not a VOB ? When it's output by VideoReDo.

Can they be fixed with ReStream or demuxed with ReJig to get something workable ?

[borax]

AFAIK it is possible to output demuxed (elementary) streams with VideoReDo itself. That't the most easy approach, as no other software is involved (no need to deal with these 'strange' VOB files )

[Lester Burnham]

@guns1inger
You are right, VOB <> MPG. But the VOB file from VideoReDo are no vob files, but mpeg files with empty navigation packs as they are necessary for dvdauthor. There was some discussion about this topic in the VideoReDo forum i.e. naming this type of output mpg or vob, and finally (unfortunately) 'vob' was used).

Indeed - I did "campaign" against that nomenclature at the time, and since.

[Lester Burnham]

When is a VOB not a VOB ? When it's output by VideoReDo.

In fairness, they don't actually claim it to be a true VOB file - the functionality is specifically for the dvdauthor based authoring packages - and in fairness, was done to support their community of users that use such packages.

What that "save as" type functionality does, is save a mpeg with a specific header type, and blank NAV packets in. Using VOB is confusing to people who aren't au fait with why VideoReDo includes this functionality - the anomaly is in the terminology, really - both the "save as" description and the file extension used. But accepting that, for a minute, VideoReDo aren't claiming it's something it's not - it's just the semantics of how they've implemented this can mislead people who aren't aware of why they do it.

As a company they were trying to help and enhance for their user community. Perhaps the terminology used hasn't been ideal - and I've not been shy about pointing that out, but their intention was never to mislead or abuse standards.

[Lester Burnham]

AFAIK it is possible to output demuxed (elementary) streams with VideoReDo itself. That't the most easy approach, as no other software is involved (no need to deal with these 'strange' VOB files )

In complete an utter fairness, I've never had this problem. I use VideoReDo and specifically use this functionality, and also use your GUI_for_dvdauthor. I've authored many DVDs like this, and never had any problem.

Perhaps VideoReDo didn't use the best label for this functionality, but their intent was in the right place for their user audience. And I've never had any problems with the output files being 'strange', and I've done so many times.

[guns1inger]

My issue is more with the number of times I have seen newbies told to simply rename VOBs to mpeg to allow them to be processed, even when the VOBs come from commercial discs. Whether this advice has come about from laziness, or miss-understanding the nature of VideoReDo's VOBs, I don't know. I understand now the position they took, although like you I don't believe it was necessarily the right or clearest path.

[AMalsher]

Thanks for all the responses on this. I didn't realise quite what a discussion i was starting!
I understand that renaming .VOBs to .MPGs is a bit of a cop out, but I've found that my process of recording TV using a Freecom DVB-T USB stick, using VideoReDo to top and tail and remove ads, renaming the output .VOBs to .MPG, then using GUI-for-DVDAuthor followed by ImgBurn is the most reliable combination of products...
... with the notable exception of the Inconsistent Timecodes! message.
From your discussion, it would appear that there is a possible problem with VRD output, and i will take that up with VRD support (who are generally extremely helpful) and can nearly match Borax' response times! I'm very impressed.
I am interested to hear that Lester also used VRD, rename and GFD process and hasn't experienced the timecodes problem. I notice that the problem most frequently occurs with smaller files (either short duration or lower bit rate).

I'll post here what I hear from VideoReDo support.
Alan

[Nelson37]

I have not had the timecodes msg, but I have had the "skipping sector, waiting for first VOBU" msg. Authoring always fails.

This consistently happens when I capture using MMC 9.03 with the IVTC turned on, capture to VCR format (for subtitles), then convert to MPG, audio to 48 and then to AC3. It seems to be the IVTC, as leaving that out results in an accepted file. Other difference from SD capture mentioned below is that Aspect Ratio is changed to 16:9.

The captured files are S-Video feed from HD channels, this did not seem to happen using same settings from an SD channel, though I have not tested this in detail.

I do not consider this as any kind of defect in the excellent GuiforDVDAuthor prog, as many editors choke on these files, with a variety of issues.

I am curious as to what exactly this error means. Current workaround is to author in Sonic MyDVD and/or ReJig, as I need to change aspect ratio to 16:9.

[Lester Burnham]

I have not had the timecodes msg, but I have had the "skipping sector, waiting for first VOBU" msg.

That message means that the input file doesn't have NAV packets.

I do not consider this as any kind of defect in the excellent GuiforDVDAuthor prog

That would be good, because it isn't. It's a constraint of the underlying authoring tool - the linux-evolved command-line utility dvdauthor.

I am curious as to what exactly this error means.

See above.

As a workaround, assuming you need no further editing (as VideoReDo has a save format that would fix this), demux your file (using, for example, pvastrumento) then remux using this command-line with the mplex command-line tool:-

mplex -f 8 -o <output filename pattern> <demuxed input mpeg video> <demuxed input audio>

If you haven't already got mplex or pvastrumento, videohelp has a download link for pvastrumento, and mplex is included with GUI_for_dvdauthor.

I'm guessing that GUI_for_dvdauthor would actually use mplex to remux the files like this anyways, so once demuxed, you could just use them as input to GUI_for_dvdauthor.

The advantage of VideoReDo's output mode, being that if you're going to edit with VideoReDo anyway, it saves you the extra manual step of demuxing - and you can keep your source mpeg as one file (of course you can always save demuxed streams from VideoReDo).

[Lester Burnham]

My issue is more with the number of times I have seen newbies told to simply rename VOBs to mpeg to allow them to be processed, even when the VOBs come from commercial discs. Whether this advice has come about from laziness, or miss-understanding the nature of VideoReDo's VOBs, I don't know.

I'm with you - I'm always advocating that people use IFO parsers to generate editable mpegs from VOBs / DVDs - even for non-encrypted domestically recorded ones - I've always believed it provides you with a consistent, sequential file to process.

Some people would prefer the quicker route of simply copying, concatenating, then amending the file extension - and only really want to bother with a more robust approach, when following the easy option causes a problem.

I understand now the position they took, although like you I don't believe it was necessarily the right or clearest path.

In fairness, the functionality was only to help their customer / user base - and they are extremely good and attentive at that.

My only issue has been the terminology is clearly confusing to people new to this, and either by merit (that you hint of) of people being lazy, or not properly understanding, this use of nomenclature causes mucho confusion.

[AMalsher]

I'll post here what I hear from VideoReDo support.
Alan

Well it turns out that my problem was that the input to and output from VideoReDo were MPEG1 files. I'm not sure how/why my capture hardware (Freecom DVB-T USB Stick) did that; most times the captured files are MPEG2. Does anyone know what determines the file format?
As always, it seems, VRD is blameless.
Alan Malsher

[Lester Burnham]

Thanks for all the responses on this. I didn't realise quite what a discussion i was starting!
I understand that renaming .VOBs to .MPGs is a bit of a cop out,

So don't do it then! ('cept when using the "VOB" output from VideoReDo - because that's not the same thing - files saved from VideoReDo as type VOB aren't VOBs - they are simply program stream mpegs with a certain header type, and blank NAV packets).

From your discussion, it would appear that there is a possible problem with VRD output,

I remain unconvinced of that - I've been using VideoReDo, and using the output in GUI_for_dvdauthor for quite some time, and (apart from an odd minor issue with a specific beta of VideoReDo) don't have any problems. I've edited source mpeg and created countless DVDs like this.

I am interested to hear that Lester also used VRD, rename and GFD process and hasn't experienced the timecodes problem. I notice that the problem most frequently occurs with smaller files (either short duration or lower bit rate).

I'll post here what I hear from VideoReDo support.
Alan

Timecode issues normally get resolved within VideoReDo by doing a quickstream fix. I always believed that saving the file from VideoReDo achieves the same thing, but I have had instances where I've needed to do a qsf, before editing, then saving, then authoring with VideoReDo.

So if you do have issues - do a QSF in VideoReDo first, then edit.

[borax]

Does anyone know what determines the file format?

No, normally DVB-T software will just save what's coming from the broadcast station. In Germany I don't know any broadcast station which sends MPEG1, but this may be different in UK. I don't believe that the software transcodes mpeg2 to mpeg1.
BTW: MPEG1 should work with GfD also, but elementary streams are probably necessary. Try demuxing your mpeg1 streams with pvastrumento or projectx or even TMPGEnc MPEG Tools if VRD should fail...

[Nelson37]

When I get the error, the output is not from VideoRedo. Valid DVD vobs, created as I mentioned, demuxed to MPG files. Aspect Ratio changed with Restream. Other author programs will use files correctly. Same procedure on files without embedded pulldown or aspect ratio change work fine.

Not a major issue for me, but just wanted to point out that this "VOBU" error msg is not just caused by VideoRedo.

[Lester Burnham]

When I get the error, the output is not from VideoRedo. Valid DVD vobs, created as I mentioned, demuxed to MPG files. Aspect Ratio changed with Restream. Other author programs will use files correctly. Same procedure on files without embedded pulldown or aspect ratio change work fine.

Not a major issue for me, but just wanted to point out that this "VOBU" error msg is not just caused by VideoRedo.

Of course it isn't - as my message further up. It's produced when the input mpegs to dvdauthor, don't have blank nav packets.

When you get this error message, you have two choices - also as above - demux and input as ES, or demux and remux with the options specified above.

The latter option, gives you input that will work with dvdauthor based packages, plus being able to save the file as is for posterity (if that's important to you).

[Nelson37]

I guess I am not clear on NAV packets but indication is these are part of a muxed MPG stream, and are NOT present in a seperate M2V and AC3 file? This is what I feed GuiForDVDAuthor when I get the error. I did not make this clear in my original explanation.

[borax]

You could try the new GfD development version and use MuxMan as authoring engine for such (elementary) streams.

[Nelson37]

Well, I have discovered another way to get this error not related to muxing.

If you specify an intro movie, delete the file, and do not remove the setting for the next project, that will cause this error even though the main movie is valid. Remove the Intro movie setting and all is well.

Have made some recent changes in capture methods as detailed earlier, do not currently have any new sources to test. But I am reasonably certain that I had gotten this error on similar projects with elementary, unmuxed video and audio with no intro specified. I had scrolled the log before and do not recall the intro movie being listed, which was immediately obvious on my last test and easily corrected. This particular movie did NOT have the IVTC and 16:9 aspect of the previous attempts when I got the error.

Soon as I cap some new sources with the IVTC and 16:9, I will re-test this to nail it down and report back. I can verify that this has worked at least once. Captured Revenge of the Sith with IVTC, 16:9, subtitles, intro movie, motion menu. It is a beautiful thing. GFD right up there with VDUB as my favorite video program.

[borax]

If you specify an intro movie, delete the file, and do not remove the setting for the next project, that will cause this error even though the main movie is valid. Remove the Intro movie setting and all is well.

Ok, that's for sure... If dvdauthor cannot open a specified stream, some error has to be there. But this is something I should consider for a check (if not file_exists(intro) => ERROR).

Soon as I cap some new sources...

I'm curious about the results!

[Nelson37]

I may be a week or two as I am currently experiencing a temporary interruption of my Satellite Service. But I will definitely report back on this thread with results.

It may have been that intro on all the failures I had, as I was testing a number of different methods to get these files accepted and was getting kind of frustrated.

[Nelson37]

Verified the intro movie was the only issue. Have authored 3 videos with subtitles, chapters, 16:9, progressive framerate, no issues whatsoever.

It was this thread which prompted me to double-check and find the issue with the intro movie. This is excellent as GFD gives me options I was unable to get with any other single program, namely chapter creation plus support for subtitles, as well as 16:9.

There is one minor issue. When using files with a 23.976 framerate, and creating chapters, the chapter list seems to stop well before the end of the movie. These files have imbedded pulldown flag but it may be done in a non-standard way (ATI MMC capture files). example, a one hour 45 minute file, chapters every 5 minutes, last chapter at one hour 30 minutes. These values are approximate. Next cap I will note these exactly and report back. This is not a huge issue for me, just one more step on the seek to perfection.

[AlanHK]

example, a one hour 45 minute file, chapters every 5 minutes, last chapter at one hour 30 minutes. These values are approximate. Next cap I will note these exactly and report back. This is not a huge issue for me, just one more step on the seek to perfection.

As a work-around, try "X equally spaced" rather than "every X minutes".
For 1h45m, 21 chapters should be about right.

You should also be able to edit the chapter times after doing an autocreate, I generally do to add one at the end of the opening credits.