Why do VOB files sometimes report incorrect running times?

[Katie Boundary]

This has been bugging me for over a decade but I never thought to ask.

[Ghitulescu]

How did you noticed this?

[johnmeyer]

Why do VOB files sometimes report incorrect running times?Not to parse the OP too closely, but VOB files do not report anything: they are simply files that sit there on your hard drive or DVD, waiting for some program to do something with them. So, to the point, some program or media player provides the report. Therefore, to make any response to the original statement, we have to know what program you are using, and what actual time it reports.

Also, how do you know what the correct time actually might be? This isn't as simple as it may seem, and is not meant to be argumentative. The only real way to know how long the file should play is to, well, actually play it. Any other approach will, once again, rely on the media player or DVD player's time counter, or on some tool like MediaInfo. Who is to say which of these provides the correct answer? There are lots of ways these things could get screwed up, starting with the 1000/1001 NTSC color correction factor.

Finally, a little information on the VOB file(s) would be useful. As I'm sure the OP knows, VOB files are not just MPEG-2 files with a different extension, but contain an amazing array of different components. I have found hundreds of instances of VOB files that did weird things in one application, even though that application would handle other VOBs just fine. The reasons for the problems varied, but often involved subtitles, multiple angles (i.e., more than one video stream), multiple audio channels, and unusual navigation markers.

Also, many, many programs cannot string together the multiple VOB files in a title and get an uninterrupted video stream. For instance, if I drop the VOB files from a single title onto the timeline of my NLE (Vegas) I get 1-2 second gaps between the VOB files, even though when played in a media player, they play uninterrupted across the files. The fault, therefore, lies with Vegas, and not with the VOB file. You can click on almost any link from this search to learn more: "vegas vob files gap timeline (https://www.google.com/search?q=vegas+vob+files+gap+timeline&ie=utf-8&oe=utf-8)".

If I drop a single VOB file onto the Vegas timeline, sometimes it is all there, and sometimes I only get the first 30 seconds. Again, this is a problem with the NLE, not the VOB file.

So, a little more information would be helpful.

And, for reference:

VOB Files (https://en.wikipedia.org/wiki/VOB)

[LoRd_MuldeR]

VOB files are just MPEG-PS files with some additional restrictions/extensions.

And MPEG-PS files – unlike MP4 or AVI files – do not have a "global" index table (or the like) that allows for accurate seeking. Instead they are more or less just a "loose" sequence of individual packets. You'd have to scan through the entire file and build your own index, if you want to implement accurate seeking, or if you want to precisely determine the total playback time. Some applications that need accurate seeking, e.g. DGMPGDec/DGIndex, do exactly this! But pure playback applications usually do not – because otherwise it would take a whole lot of time to "open" the file. Instead, they simply start playback at the beginning of the file. And they "guesstimate" the total duration and the seek points...

[Katie Boundary]

to make any response to the original statement, we have to know what program you are using, and what actual time it reports.

Also, how do you know what the correct time actually might be?

Assume that I'm using VLC media player, and that a 45-minute episode of "Bones" is reporting a runtime of about 18 minutes. Also assume that I know it's supposed to be in the neighborhood of 45 minutes because that is the correct running time of an episode of "Bones". Or Andromeda, or Babylon 5, or Battlestar Galactica, or Birds of Prey, or The Blacklist, or Buffy the Vampire Slayer...

MPEG-PS files – unlike MP4 or AVI files – do not have a "global" index table (or the like) that allows for accurate seeking. Instead they are more or less just a "loose" sequence of individual packets.

Well that was a stupid design decision... thanks for the info.

[johnmeyer]

Assume that I'm using VLC media player, and that a 45-minute episode of "Bones" is reporting a runtime of about 18 minutes. Also assume that I know it's supposed to be in the neighborhood of 45 minutes because that is the correct running time of an episode of "Bones". Or Andromeda, or Babylon 5, or Battlestar Galactica, or Birds of Prey, or The Blacklist, or Buffy the Vampire Slayer...Wow, that is a huge discrepancy. I had no idea you were talking about such a big time difference.

Here are a few things I would try in order to get to the bottom of the problem.

Do you have any other media players installed that will play these same VOBs, and do they do the same thing? Were these VOBs created by DVD Decrypter, DVD Fab, or something else? Have they been altered in any way whatsoever since they were ripped onto your hard drive? Do you get the same problem if you play the DVD directly, assuming you have a DVD drive on the computer?

Here's a really important question: are you trying to play the VOB files directly, or did you rip ALL the files from the DVD, including the IFO and other navigation files? If you are simply playing the VOB files directly, then all bets are off because even VLC cannot know what to do with them. You can find hundreds of posts about this issue:

VOB Time Error (https://www.google.com/search?q=vob+time+error&ie=utf-8&oe=utf-8)

The net of all those posts is that if you want to be able to play the entire DVD, with correct timecodes, searching ability, etc., then you must have ALL of the ancillary files on your hard drive, and you must open it as a DVD (Ctrl-D on VLC) rather than simply dropping the VOB (or multiple VOBs) onto VLC.

Finally, what version of VLC are you using? It is a great program, but the last few versions, starting about two years ago are, IMHO, not very good anymore. You could try an earlier version.

[hello_hello]

I have the same problem with MPC-HC. For the DVDs I'm encoding at the moment I'm using VLC to check the title numbers, because for some reason MPC-HC keeps getting stuck at the menu. Navigating is sometimes challenging too, and I don't split the vob files when I re-author. I use DVDShrink for re-authoring and don't have a problem indexing and encoding, but a long time ago I realised one way (maybe the easiest) to determine the correct length of a vob file is to remux it as an MKV and check the MKV's duration.

Or if the DVDs been re-authored so each episode is a set of vob files, open the corresponding ifo file instead. That's generally more successful.

[Groucho2004]

Maybe I'm missing something here but usually VOBs are part of a DVD title set and all relevant info can be retrieved from the corresponding IFO file.

If there are just VOBs for some reason, DGIndex is the safest way to parse them (which conveniently can be automated through its command line interface).

In order to get the correct length by multiplexing to MKV requires the correct frame rate to be specified.

[manolito]

A very old trick (was even used in the ancient DVD2SVCD software) is to use the audio track(s) of the VOB in question to determine the correct length.


Cheers
manolito

[johnmeyer]

To add to the last few posts, if you want to play the VOBs without using the other DVD navigation files, then you can use any of a dozen different utilities to convert the multiple VOBs to a standard MPEG-2 file. I do that all the time and have several different workflows, depending on what I need. For instance, I have applied digital restoration to dozens of old sports film DVDs, and the first step is to get each titleset into it's own MPEG-2 file so I can then put it on my NLE timeline, and from there, apply various restoration steps. There is no way I can do anything if I just try to deal directly with the VOBs.

[18fps]

In my experience this happens mostly with hardware-created DVDs. Often, but not always, just remuxing with muxman (I'm not interested in keeping the automatically generated menus) solves the problem. Of course there are other ways to find the DVDs running time, but most programs use mediainfo, which reports the wrong time.

[manono]

In my experience this happens mostly with hardware-created DVDs.
Like DVDs created by DVD recorders? I believe she works with retail DVDs. And, unless I'm mistaken, she's also writing about playing individual VOB files, as opposed to playing a DVD. And, as already mentioned, all bets are off unless you play the DVD. VOBs aren't really meant to be used independently.

[wonkey_monkey]

Assume that I'm using VLC media player, and that a 45-minute episode of "Bones" is reporting a runtime of about 18 minutes.

VOBs on DVD have a filesize limit of 1gb, so each episode will span multiple files. If 18 minutes is the length of one file, that suggest each episode is about 2.5gb and so there would be 3 or 4 of them on a DVD, which usually what you get.

So it sounds to me like VLC might be showing the length of the VOB, not the length of the episode.

Of course, if I wasn't blocked by Katie, this would be where I'd be berated for being some kind of moron because I couldn't accurately foresee that Katie had already decided (rightly or wrongly) that this is not the case.

Also don't tell us to "assume" like that. It sounds rather patronis... oh, what's the point.

Well that was a stupid design decision... thanks for the info.

Just because something is inconvient for you does not make it a stupid decision. c.f. interlacing.

[foxyshadis]

Well that was a stupid design decision... thanks for the info.

You think VOBs are bad, wait until you see TS/m2ts. They make PS/VOB look positively amazing; the overhead is enormous and the parsing is a bear, with the exact same problem.

For stream formats like those, most tools just seek back a few kilobytes from the end and look for the last packet's timestamp. Sometimes that works, sometimes they're out of order and it fails. Stream formats on a random access medium suck, no way to fix it.