Is DVD audio always two frames ahead of DVD video?

[wonkey_monkey]

This goes back to something I noticed years ago on the Star Wars DVDs. It seems to me that whenever I rip a DVD, the audio is always two frames ahead of the video.

I've just checked a couple of DVD rips against the BBC iPlayer versions, by loading both into VirtualDub and turning on the audio display. On the DVD rip (a DVDDecrypter vob file dragged straight onto VirtualDub2, and also a MakeMKV mkv as a double-check) the audio is two frames early compared to the iPlayer version.

I've also played the rips/DVDs back on the computer (MPC-HC, either from the rip or direct from the DVD) and also on my TV/DVD player and video-recorded the screen - in that situation, the audio comes earlier on MPC-HC than it does when viewing the DVD on my TV. So I guess it's part of the DVD spec somehow and the DVD player knows about it?

Is this a known thing about DVDs? I also have a vague memory of seeing an extra 2 frames on some DVD rips depending on how it was loaded into VirtualDub - two B frames, possibly corrupted, before the first I frame. Could that be related?

[huhn]

how about you check the audio delay in the source and see if it is preserved.

depending on the source filter and container some like to delete a couple of frames like directshowsource.

[wonkey_monkey]

MediaInfo reports 0 delay on the MakeMKV rips but 287ms delay on the DVDDecrypter rips. But that's too long, more than 7 frames. And when I demux the DVDDecrypter vob with DGIndex, it names the file "...DELAY 0ms"

¯\_(ツ)_/¯

[hello_hello]

I don't know the answer to your initial question, but for MKVs at least, MediaInfo will report a video delay as a negative audio delay, and if both have a delay, it reports the difference.

gMKVExtractGUI also writes the difference between delays when it extracts the audio from an MKV (under the assumption the video will be re-encoded and it's delay lost as a result) but when you open an MKV, it's GUI will display the actual delay for each stream (if any). There's an example below. MediaInfo reports an audio delay of 18ms. Not that it'll necessarily be the same as the vob file, as there's no such thing as a negative delay for MKV, so if there's a video delay removed by MakeMKV, it should crop the beginning of the audio to the closest audio frame to compensate, and if it's more than the video delay was, apply a new delay to the audio stream to maintain sync.

I don't really know how it works for DVDDecrypter/DGindex, or what MediaInfo reports for vob files.

I do recall a thread on this subject quite a while ago (maybe it was yours) and I checked a few DVDs at the time. The audio did seem to be consistently out of sync. From memory by a couple of video frames, but I can't remember in which direction. 40ms (or whatever two frames is) isn't really enough to notice, so at the time I decided to pretend I'd never read the thread or checked any DVDs. :)

https://i.postimg.cc/c1tjdg4x/Clipboard01.jpg

[Katie Boundary]

This was a bug with DVD2AVI and the original MPEG2dec3. More precisely, the older tools decimated the first two frames of both audio and video; one decimated video because it was stupidly programmed, and the other decimated the first 83 ms of audio in order to maintain sync. This issue was fixed in DGindex and Donald Graft's version of MPEG2dec3. If you have a 20-year-old version of MPEG2dec3.dll that you're using with DGindex, then it can cause desynchronization by two frames.

[videoh]

one decimated video because it was stupidly programmed That's unfair. It was a design decision to skip leading B frames, and 2 frames were chosen because that is what was seen on DVDs of the era for open GOPs. Call it stupid if you like but jackei's DVD2AVI was an innovative powerhouse app for its time. Hindsight is 20-20. jackei and trbarry live on in the pantheon of desktop multimedia heroes. You could hope to do as well.

[wonkey_monkey]

I've gone back to the original source that was giving me grief over this many years ago, which is the Star Wars DVDs. I seem to remember proving to myself years ago that the music should start at the same frame as the logo first appears by video-recording my TV during DVD playback (I can't repeat this now, though, because I can't trust the audio sync on my phone camera. Might try another later). With that in mind...

I ripped the first few minutes to a single vob with SmartRipper. I indexed with DGIndex and demuxed all audio tracks (all said delay 0ms in the filename). Then using mpeg2source and nicac3source to merge video and audio, I get a 2757 frame video (logo appears on frame 689), and the VirtualDub audio display shows that the music starts 2 frames before.

Using LSmashSource instead, I get a 2758 frame video (logo still appears on frame 689) and the audio is only 1 frame early.

Next I tried ffmpegsource, but it can't be trusted with vobs so I remuxed to .ts. Result: 2757 frame video, logo appears on frame 689, audio is 1 frame early.

I tried dragging the vob directly onto VirtualDub2 but it got thoroughly confused and skipped over the receeding logo entirely, possibly something to do with the angles used to change the language of the crawl (though I only selected Angle 1 in SmartRipper).

[huhn]

instead of a ts remux can you try mkv?

pretty wide shoot but timecode files are powerful.