Is the delay value in the IFO and where?
+ Reply to Thread
Results 1 to 21 of 21
The first Vob file in a title set has no delay...
Thanks, I normally use PGCedit, but I have 2 DVDs that show no audio tracks when I hear audio and AutoGK converts it OK. The only problem is DGIndex gets the delay wrong when I pre-trim the DVD before converting.
I've looked at the VOBs with MediaInfo and the delay value AutoGK gets is the same, so I guess DGIndex gets the value from the VOB.
PGCedit gets it from the IFO and it's always right. I looked through with IFOEdit, but couldn't find anything. I'm going to try with PGCDemux.
Edit: Doh! I meant "I normally use PGCDemux..." not PGCedit.
Depending on what the final output is to be (you didn't say), just figure out the delay and correct it.
Also, if this is a newer DVD with newer copy protection, decrypting and preparing the VOBs correctly can also get rid of the problem.
I like my movies to start right away without all the production logos and other crap, so I trim it off the DVD video.
When I converted my Babylon AD DVD to AVI for my media player, I ended up trimming 21.4 sec off the beginning. The first VOB has that as delay, according to Mediainfo and DGIndex reported it as well. Obviously that's not going to work. I estimated it should be closer to 300 msec, but it's just a guess. This is where PGCDemux comes in handy; it finds the correct delay in the IFO.
I think I understand what you're saying, I should do my trimming in DGIndex. That makes sense, I was trimming with DVDShrink. I just never stopped to think about the way AutoGK works.
I never had problems before, the only difference was the OS on the machine I did those 2 movies on. From now on I'll edit in DGIndex and fix the problem by not creating one. Thanks!
First, I apologize. You clearly said earlier that you were using AutoGK and I missed it. Second, if you trim in DGIndex, you won't get back a VOB, which you'll need for AutoGK. Otherwise no audio. So, I gave bad advice based on a mistaken assumption. Did you say that after making the trim and reauthoring in Shrink you got the full 21+ seconds delay? Then I might suggest a different way of trimming out the Intro. If you don't need subtitles (?), I might suggest the old MPEG2Cut. It's easy to use and will give you a delay of less than the 300ms you mentioned. I prefer the old version as it's not as complicated to use as is the newer version called MPEG2Cut2. Then just open the resulting VOB in AutoGK:
It works, but it's not worth the trouble for people converting the audio to MP3.
After saving the D2V, I got a new trimmed AC3 track, then I had to convert it to MP3 with Besweet. I used the same parameters that were set in AutoGK just in case it would affect the timing. If you keep the original audio, then the only extra step is to rename the new files to match the old ones and place them in the same folder as the old ones; otherwise the script won't work.
On the bright side, after trimming with DGindex it gave me a new delay value that was more in line with what I expected; I figured 300ms and it gave 367ms. I'd still like to know where I can find that value in the IFO, but at least I have a workaround now. Thanks.
Just to follow up on using DGindex and AutoGK this way. It's a good method for damaged DVDs that DVDDecrypter can only rip partially. I have a Sarah Brightman like that, it's not scratched, but it won't play to the end.
I ripped it as far as DVDDecrypter would go, when it was only making errors I aborted it. Then I opened the VOBs in DGindex and saved each songs as a separate project with the audio set to demux. This creates a D2V and an AC3 file; I just used numbers for filenames and kept everything in the same folder.
Since I use MP3 audio in my AVIs, I converted the AC3s with Besweet. I only enabled AZID and LAME. In AZID, I enabled normalization and set the output to stereo. For 5.1 tracks you can find out the settings to use for downmix when you run AutoGK, just open the DOS windows that run in the background. I setup LAME with the same values as AutoGK.
Then I ran AutoGK on the IFO of the ripped DVD and let it work until it started VDubmod. At that point I clicked the abort button in AutoGK. All that's left to do is copy the D2V and MP3 files to the agk_tmp folder. Then edit the last number on the setinterleave line in LASTJOB.VCF to match the delay in the first MP3 filename. Rename the first D2V and MP3 to match the filename AutoGK created. Start VDubmod, click FILE, RUN SCRIPT find LASTJOB.VCF and wait. When it's done rename the AVI and start over with the second set of files.
Since you were working with a music DVD, you might try this sometime. This assumes you got most but not all of it. It'll also work on whole DVDs already decrypted to the hard drive.
Open the IFO from the DVD in PGCDemux. Set the Mode to "Single Cell". Check the "Create a PGC Vob" box. And in the drop-down box choose the cell (chapter) you want. You can open the resulting VOB in AutoGK and it should handle it OK.
Interesting, I have another bad disc to try this on.
I'm creating a test dvd with a white flashframe and a tone blip to measure audio-to-video-delays in an entertainment system. I want to measure the delay, that occurs on the way of the signal from the source medium (my dvd) to the display/speakers.
Therefore, I need to know if the audio and video on my dvd are already out of sync, and if so, the exact value of the delay, so I can subtract it from my measurement result.
I found this thread and want to use some of the mentioned programs to check the delay.
So when I open my DVD with VirtualDubMod, I have the files
When I try to open the first two of the files and want to see the file information, a program failure appears.
When I open VTS_01_1.VOB skew is -80ms.
- VTS_01_2.VOB: -317 ms
- VTS_01_3.VOB: -552 ms
- VTS_01_4.VOB: -243 ms
I could understand if the delay would be within the range of one frame, i.e. 20ms with PAL, but why does it measure between 80ms and 552ms? and why does it vary so much?
The audio must be placed before the video frame in the file, so that the player can read it and place it in the audio buffers to play it when the video frame is displayed. The exact synchronisation is controlled with time codes in the audio and video frames.
Due to technical reasons, the DVD-Video standard prohibits files greater or equal to 1GB. So, VTS_01_1.TOB to VTS_01_4.VOB must be considered as a single file, split into 4 parts at (almost) arbitrary points. (VTS_01_0.VOB is the menu VOB and is independent.) The delay you see at the split points is therefore not significant, and vary depending on where the split occurs in the file. Only the delay of the first file is significant. It can theoretically be between -100 and +100 ms, but it is usually 0 with properly muxed VOB files. Anyway, even if the delay is not 0, that doesn't mean that the audio and video are out of sync. The delay means only that the audio stream starts a few ms before or after the video stream. It's just an offset used to place the streams at the right position during the muxing operation, so that the parts of the audio and video files that must be played at the same time can be accessed when the player needs them, without having to seek at a different point in the VOB file. The real synchronisation between the two streams is archived by the player, with the help of the time codes.
You can check the delay of the first VOB with PgcDemux, but again, the value it returns will not help you. I don't think there is a tool to check precisely if a specific part of the audio file is in sync with a specific video frame.
Note that my explanation above is somewhat simplified. In fact, a new delay is computed for each VOB into the VOB file. A VOB is a Video OBject, and it has a different VOB ID. (Unfortunately, the .VOB file extension leads to confusion: a VOB, stricto sensu, is not related to the VOB files, and the fact that there are several VOB files doesn't mean that there are several VOBs, and vice-versa.) Each VOB is independent, and the time codes are reset when a new VOB begins. A new delay may therefore be defined when a new VOB begins.
Thank you for your answer, r0lZ. Very good explanation
The only thing I don't understand is, why can the delay be theoretically between -100 and +100 ms?
In your opinion, what would be the perfect settings for a DVD to keep audio and video in sync?
I need one PAL DVD and one NTSC DVD. A 2-hour-video should fit on it.
Is it better if I use CBR (4 MBit/s) instead of VBR?
I would also like to have one audio stream as stereo PCM and one 5.1 Dolby Digital.
I have double-layer DVDs so I don't have to use too much compression.
And one last but very important question:
In my test-video, i use sequences of black and white frames, 3 seconds of black and 3 seconds of white. During the white sequences there's a 1kHz-Sine. So, wouldn't it the best setting if the I-Frames of my video would be exactly at the transition from black to white (= transition from no sound to sine)? I use these transitions to trigger with my oscilloscope and measure the delay.
In Premiere Pro I can set the M-Frames to 2, 3 or 8 and the N-Frames to 9, 12 or 15. What would be the best setting to have the I-Frames at the correct position?
DelayCut to fix it.)
But you should author your PAL and NTSC videos on different DVDs, as it is theoretically forbidden to mix them, although most modern players accept the hybrid DVDs without problems.
Also, note that determining a correct frame sequence for the NTSC standard might be a nightmare, because you cannot easily predict where will be the drop frames. (I can't help on that subject: I live in PAL land, and I have never understood exactly how NTSC works and why it is so bad and complicated.)
VBR is the standard for DVD-Video, and the presence of the time codes is sufficient to ensure a precise synchronisation.
Do you know a good source that explains the frame synchronisation on dvds? Not that I don't trust you but I need to verify my source file
DGIndex and run the Preview and have a look at how the bitrate fluctuates. Or open a VOB in Tecoltd's Bitrate-Viewer which will tell you right off if it's VBR or CBR. Only the poorest quality retail DVDs from the worst DVD production companies use CBR encoding.
And did I understand you right, that the time codes only exist if I use VBR for both audio and video?
I should have said that VBR is the "de facto" standard.
There are good explanations on how the video frames are encoded in the MPEG stream, and how they are kept in sync with the audio, but I don't remember where I've read that. Sorry.