View Full Version : Capture process - sync issues - crop issues
Yaka2manD
24th June 2003, 17:36
Hi all,
I'm about to capture old VHS tapes and convert them onto DVD. I've been reading most of the recent topics about capturing video here, and here is the process (simplified here) I'm preparing to apply:
1. Capturing with Virtualdub_Sync or Virtualdub_VCR (768*576 (PAL); Huffyuv; 48kHz) under Win98SE and with a DC10+ card.
2. Process video in TmpgEnc+ with Noise Reduction (High Quality mode)
3. Process audio in Soundforge for noise reduction, then encode it in ac3 with SoftEnc
4. Mux A/V in TmpgEnc+
5. Create menu and burn
1. Here is my first question: I do not ask if this is the best way to do (just to respect the rules ;)), but I would like to know if anything seems to be wrong with this process (specially with capturing)?
2. Then, it seems Virtualdub_Sync and Virtualdub_VCR have two different methods for Audio to be synchronized with Video. The first one resamples Audio whereas the second one drops or adds video frames to stick to Audio (coorect me if I'm wrong).
Since I will put everything on DVD, the final settings will be constant (25 fps and 48 kHz). Does it mean that the A/V synchronization performed by these softwares won't be keeped once encoded in mpeg 2 (with DVD settings)?
3. Finally, once I've captured my 768x576 video, I'll have to resize and/or crop with TmpgEnc+ to fit 720*576, which is the DVD resolution (proposed by TmpgEnc). So what do you suggest? Cropping with TmpgEnc and then asking for 720x576 (cropping and resizing in fact) or just resizing and loose the correct aspect?
Thanks in advance for your answers
Yaka
----------------------------------------
Athlon XP 1600+
Iwill KK266+
640 Mb RAM
Ati Radeon VE
DC10+ used for Video capture
Soundblaster Player 5.1 used for Audio capture
205 Gb HD 7200 RPM (120+40+45)
Win98SE
---
France (PAL)
---
Lord of the Discs
25th June 2003, 15:30
Capturing VHS_video in full PAL would be wasting HD-space and also
wasting time when you process it afterwards (I do this in half PAL
and get just wery little quality loss, after capturing I filter and
resize to DVD-PAL in one go) but this is my subjective opinion.
I guess itīs best that you try capturing a few seconds in both
resolutions and decide for yourself.
LotD
Swan
25th June 2003, 17:49
Capturing in full PAL resolution (720 x 576) from VHS is not a waste at all, in my view. On the contrary, unless your final format is VCD and you don't care one bit about quality, then it's not advisable to use anything other than a vertical resolution below 576 lines.
On VHS, video is stored interlaced. When you capture at half resolution (352 x 288) you are not getting interlaced video any more.
And this will affect quality big time!
Plus, it's always better to capture full resolution and let a good resizer do the job of downsizing afterwards (Avisynth, TMPGEnc's rezizer, etc), than to let the hardware or the capturing software downsample the resolution.
Yaka2manD I can't see anything wrong with your method, but perhaps your question # 3. regarding the resizing.
I saw a thread here not too long ago about how to resize the
768 x 576 video from a DC10 without messing up the AR.
Do a search in this forum for "DC10" and I'm sure you'll find it (and other tips).
Yaka2manD
26th June 2003, 10:54
Thanks to both of you for answering my questions so fast.
I have made the research Swan is talking about, and I have found 2 threads about it.
http://forum.doom9.org/showthread.php?s=&threadid=54882
http://forum.doom9.org/showthread.php?s=&threadid=54398
I had already read the first one, which was IMO left unanswered. But for people looking for an explanation, just read the second one: Kika is explaining the A/R problem better there.
Ok, seems like I've got my answers for Q1 & Q3
Any idea for Q2? :)
Swan
26th June 2003, 11:49
Any idea for Q2?
I don't use VirtualDub for capturing, but I believe VirtualDub VCR is the "regular" VirtualDub, with a timer-function, for scheduled recordings. It does not have a built-in "resample audio on the fly" function, as far as I know.
VirtualDubSync does, that's its main purpose.
When you capture video with VirtualDub or other VFW software, like Avi-IO, what these apps does to try to achieve correct sync is to drop frames.
From VirtualDub's documentation (www.virtualdub.org):
The audio isn't in sync in the capture file.
It's what we get for putting audio and video capture on separate clocks.
If you are running VirtualDub 1.4c or earlier, check the Knowledge Base for a possible workaround if your sound card isn't very accurate. (This problem will be fixed in V1.4d.) Also, if you're using compatibility mode, to capture, don't -- for VirtualDub to resync the audio during capture, you must not be using compatibility mode, and timing correction must also be active (it's in the capture menu).
The "lock video stream to audio stream" option in settings only works for compatibility mode; it sets the frame rate of the video stream so that it's the same length in time as the audio one. This is a nasty way to get audio in sync, because it will make editing harder -- to coerce the clips to a single frame rate for rendering, frames will have to be dropped or duplicated. It also doesn't work well if the timing relationship between audio and video drifts over the course of the capture.
and (edited)
Why am I dropping frames?
Perhaps one of:
Timing correction necessary to keep the audio synchronized. Most sound cards will deviate a small fraction from the video capture device, requiring that a few frames be dropped to keep the audio in sync. Another possibility is that the source is outputting a slightly slow or fast frame rate; old videotape can do this, as well as game consoles.
Yaka2manD
26th June 2003, 15:28
Ok, so according to VirtualDub's documentation, "lock video stream to audio stream" from VirtualDub VCR is to avoid if you want to encode to DVD, since it changes the video frame rate.
Now, my problem is not to have A/V synchronized on my captured file, but to keep this synchronization once the avi is encoded to a final mpg.
If you choose the drop frame method, does it means you won't have a truly 25fps, but something like 24.9fps? If true, how will TmpgEnc+ behave during encoding (with DVD-compliant parameters)? Will he be able to keep synchronization or not?
Same problem with VirtualDubSync: will the "resample audio on the fly" function give a variable frequence for audio or will it be 48kHz?
Actually, all these questions can be sumarized in one single question:
What capture method (and what SW) is to be used with DC10+ if you want to keep the A/V synchronization from your VHS to your future DVD?
Swan
26th June 2003, 19:28
Yaka2manD, doesn't the DC10+ have an audio input?
Do you have to capture the audio via your audio card?
I have never seen a DC10+, but from what I understand it is pretty pricey and so, I figure it has the audio and video clocks synchronized. If so, forget about sync issues. You won't have any.
If you choose the drop frame method, does it means you won't have a truly 25fps, but something like 24.9fps?
Yes. As I recall when I experimented with this, I got files that did not have a steady 25 fps.
Look at what Avi_Io's author writes (http://www.inetlan.com/avi_io/):
Note, if needed AVI_IO insert's frames to keep synchronization between audio and video, while all other capture tools known to us don't. Such capture tools (as a consequence) may not report any drop's BUT audio and video shifts in such cases if you capture over long periods. We feel that inserting frames (and reporting them as drops) is better than letting audio and video shift, because such shifts are soon noticeable especially if you capture talking people. The reason for such shift's (if they happen at all) is caused by the sound card and/or video capture card used. If one (or both) of these devices do not keep exactly the frequency requested by you (i.e. 29.97 fps 44100Hz or whatever) audio and video will shift if you capture using a different capture tool. AVI_IO corrects this behavior only if needed giving perfect lip synchronized captures over hours using even unstable (cheap) hardware!!! - The drawback are some reported drops which however should not be noticed during playback.
Now, forget the sales pitch talk above, I got bad synch with this software too. :)
Same problem with VirtualDubSync: will the "resample audio on the fly" function give a variable frequence for audio or will it be 48kHz?
This is what the author writes (http://www-user.rhrk.uni-kl.de/~dittrich/sync/):
Problem:
When capturing video with your TV-card and audio with your soundcard simultaneously, after some time audio becomes desyncronized with video. This is because the clock of the soundcard is not syncronized or locked to the framerate of the incoming TV-Signal. Thus the number of audio-samples per frame will change slowly in time. Ok, when adding some timestamps while recording, or using some data framing techniques and e.g. bit stuffing mechanisms, this is no problem anymore, when using these information for playback.
For short sequence capturing, that does not matter because this effect becomes visible only when recording some longer periods (depends on the quality of the soundcard-oscillator and on the oscillator(s) in the tv-broadcast-station or in your VCR).
In order to syncronize audio and video, all capture programs we know (Virtualdub, AVI_IO, etc.) throw away or duplicate frames when audio is behind or in front of video.
Solution:
In order to syncronize audio and video we apply a realtime sample rate conversion to the audio signal and do not throw frames away, anymore. That is, we have some means to permanently measure the time delay between audio and video during the capturing process and e.g. if there are too much audio samples per frame we reduce the number of audio samples in such a way, that there is no audible degradation (in the professional music domain, sample rate conversion is applied when mixing digital audio of different sources, but in a hardware-circuit like the AD1896 from Analog Devices). In order to avoid additional jitter, the measured time delay is feed into a servo loop with a high time constant.
So even when capturing many hours, the number of samples is as specified (e.g. PAL with 25frames per second and 44.1kHz audio sampling frequency, there have to be exactly 44100/25 = 1764 samples per frame).
I can tell you that I never dropped any frames and still got bad sync. I did some measurements and I could see that my audio card did not keep the sample rate I requested (48.000 Hz).
The sample rate fluctuated, so of course, I got bad sync, it started to show after 15 minutes, after 30 audio was more than a second off. Unfortunately, VirtulDub sync didn't do the trick for me either, and I didn't like the idea of resampling the audio.
But as I understand what the auhtor writes, the whole purpose of resampling the audio is to combat deviations from the requested sample rate of for example 48 kHz or 44.1 Khz, so TMPGEnc should have no reason to complain.
On a side note, I admire those who can get this to work; having audio and video not locked on to each other, still getting sync.
I've never experienced it and I got tired of trying to solve it instead of capturing and encoding which is what I like (not endless problem solving). I bought an ADVC-100 which has locked audio (normally only used in proffessional equipment). No more sync problems.
Yaka2manD, I'm rambling now. :)
But don't be afraid to experiment! Capture 30 minutes, see if you get any frame drops. Encode this, etc. Testing things is the only way to finding a method that works for *you*.
No one here can tell you *exactly* what to do.
What capture method (and what SW) is to be used with DC10+ if you want to keep the A/V synchronization from your VHS to your future DVD?
If the card has synchronized clocks, any software basically.
If not, VirtualDub Sync and other software that resamples the audio.
Yaka2manD
26th June 2003, 21:18
Thx a lot for all the time you've spent to answer. I got a pretty good idea of what to do now! ==> Tests!!
By the way, the DC10+ has only video input. DC30+ is DC10+ model plus audio input. ;)
vBulletin® v3.8.5, Copyright ©2000-2012, Jelsoft Enterprises Ltd.