First -- I have learned a ton from this site. This site and videohelp have had 100% influence on the hardware I've purchased.
This is the issue I'm running into.
I have two machines, each with solid state drives and at least 4 cores (one has 6). I first purchased an ati tv wonder 650 pcie. When running it in machine 2 (the one with problems) I had frame drops. I assumed it was because at the time I had a single hard drive and it wasn't able to capture fast enough.
Fast forward -- I got a solid state drive and a nice nvidia video card and then a pci ati 600 (cheap motherboard with only one pcie slot), after getting those installed, I still had frame drops on the problem machine.
My workflow is DCR-TRV330 (TBC ON Noise Filter off) >> DPS 220 (full frame TBC with proc amp) >> composite >> ati 600.
I would also like to mention that the quality difference between this capture method and using the built in firewire is night and day. The DV quality is horrible in comparison to the captures I successfully completed in computer 1. I hope to post samples, but I hope to get some more of this project done as I've just been doing testing for best quality so far.
I'm still up in the air for s-video with no DPS 220 or composite with 220. I also have a great deal to learn about color levels.
I found a settings in virtualdub for "drop frames when frames are too close together" When I un-check that box, no frames are dropped, but i'm concerend it may be causing other issues. Does anyone know why this would happen? I Capture at 29.97 fps.
Many here may not agree with this advice, but have you tried to capture these tapes by using the camera's firewire port? While not optimal (DV compression, 4:1:1 colorspace), its a heck of a lot less hassle when working with analog Hi-8 tapes in a Digital-8 camcorder.
Completely understand. Yes, I did try that method however; I was not happy with the result. I owe the community some result clips, the conversions just lost priority over the last couple months. The tapes are of decent quality but not great. Additionally, I'm not really worried about it being easy. I actually really enjoy learning about this stuff. I'm not stressed on time, and I find all aspects of video extremely interesting. Right now I'm trying to get the workflow to an optimal point then I plan on delving into histograms, for properly adjusting color and black levels. I know there's much more to it than that and really look forward to learning it. Once I can get them captured I've done some research on video restoration and can't wait to see what kind of results I can get and learn even more.
There's a myth about harddrives not being fast enough and dropping frames, that's way out of date. People still lose frames, and it's because of a problem with the API in windows and unstable sources, even drivers.
I've found dropped frames even when it reports no dropped frames.
Thanks! Followed the link and I'll try his update
"
Update: I found the solution to the original problem; VirtualDub drops frames by default (and my last 5 years of captures are all ruined). Only the following should be checked:
correct timing
auto disable sync
"
I'll try those and additionally install the plugin if results are not as expected.
Thank you again, I tried to find information regarding those settings via google, but was very unsuccessful.
And it usually is an I/O reason (hard drive speed).
But when it's not, it can be pretty much anything. Windows drivers and unstable sources are surely potential issues.
What I'd like to know is what frames may be dropped using only s-video, with the composite TBC?
Thanks, I've extensively read the prevent dropped frames topics. I wasn't able to find anything pertaining to what I'm seeing.
I made the changes outlined in the previous post and it has resolved the issue (at least I think it has) in that I now have no dropped frames and quality remains very good on playback. There are some stuttering issues in the preview pane though which make me wonder. Anecdotally it seems to capture 100 frames or so fine, then drop 6 then capture 100 or so. Not sure if that even makes sense, but when the issue is happening that's what I see in virtualdub.
Do you mean, camcorder > s-video > converter > dps-220 > converter > svideo > ati 600? Or camcorder > composite > dps-220 > converter > svideo > ati 600?
Drop the converters. Just run composite cables straight through. I've had weird frame drops with VirtualDub, but in my case it was the capture driver not passing the frames properly to the program. VirtualDub was adding frames instead of logging dropped frames!
I've been very much considering getting rid of the dps-220 in my workflow. I could then use s-video directly into my ati 600. I'll need to do more capturing to test since with the tbc in line the video has been extremely stable, I would want to make sure that without it that just the line-tbc in the sony would be sufficient to remove errors.
The other reason I'm very interested in keeping the 220 in line is because it comes with some basic proc-amp controls. I do not have a color calibrated monitor though so it's hard for me to justify using them. I'll post some video's in a new thread once I get everything setup so people can see the differences in different capture methodologies.
I re-read the post jmac linked to, and I would like to try to see if there are glitches being introduced by the system. I'll need to do some work to get that setup as I haven't quite delved into avisynth yet.
How were you able to determine that virtualdub was adding frames?
Jmac.. just realized those are your posts....... I'll put on my dense hat...
hehe, yep, that was my post, and yes changing those settings in Virtualdub solves the problem, which is obviously not related to file i/o. And yes Virtualdub will add frames. The reason is a bit in depth, but basically you have to tell the Windows API what framerate to capture at, and it assumes a steady rate. With unstable sources, this isn't true, so Virtualdub tries to measure and update, and re-open the stream dynamically with new rates. This works for a long term rate trend, but not for short-term changes. That's why I think it drops frames.
There's other issues too. The audio and video streams have different clocks, and you have to pick one to be master. It should be the video. This means audio gets resampled.
I don't feel like going in depth now, but the whole problem is computers being designed to try to create a steady frame rate from a variable frame rate source. I think this is completely wrong. The preview display should hiccup and studder, but the recorded file should be the true variable frame rate, but rewritten to playback at a steady speed.
Interesting. Yes, I see in the recorded file everything is fine, and the audio re-sample makes sense' People are much less apt to notice a slight pitch change in audio that they are to notice a visual drop.
This makes complete sense, it's the drop and re-open of the API that causes me to see the 6 or so frames per hundred. Which means virtualdub can see that the framerate is different and tries to fix it.
I'm slightly lost on the variable frame rate though. We'll.. lost in that I don't understand why i'm having the issue, the issue itself and virtualdub's solution makes sense. I'm using a TBC which I thought was designed to give a constant upstream frame rate (hence resolving timing issues) I have noticed that there is a switch to adjust timing and wonder if I should spend some time fiddling with that, but before I do i want to test the quality without it. It's an aging piece of hardware I ended up purchasing on ebay because it was dirt cheap and to be honest I didn't think I had a chance of winning the auction. It might just be too much man in the middle.
Ah, well again it's the same issues. The TBC tries to create a constant frame rate from a variable frame rate. I have actually corrected issues in this forum where I could prove that it was the TBC causing drops or dupes (I can tell by the amount of noise in the frame; a dupe created by the TBC has a little noise, but a dupe created by the capture software on the PC creates a perfect digital dupe).
So yes, same thing, the TBC outputs whatever frame is most recent at a steady rate, and if the incoming signal can't keep up, you get either the appearance of a dupe or a drop.
So having a TBC has in fact, compounded the problem, as far as dropped frames go. There is one way around this, but you won't like it - make two recordings of the same tape, I can make a script in software to detect the dropped frames in one copy and inserted that frame from the other copy, in other words both copies together have all the frames and you have to sort them together in order.
Fortunately, the problem is greatly reduced compared to the issue of wrong settings in Virtualdub.
Also, the steady rate of the TBC and the steady rate of the PC are both very close, but are never exact.
Will I need to go to that depth? It makes sense that if there's a microsecond issue between the tbc in the camcorder, and the external tbc I would see issues like this. But if I eliminate the secondary (not necessarily useful) tbc there should be a good chance that virtualdub would now have a consistant rate and not need to drop / recall... right?
Either way, i'll do some testing tonight. I think I might have done too many variable changes at the same time when I was playing around before and the issue might just be centered in the dps-220 or my lack of knowledge regarding setting its' timing.
Thank you again for your advice, and good luck with the software TBC. Makes complete sense, and I'd be willing to do some testing if you want to test viability on any of the hardware I have.
Analog NTSC is, for example, 29.969, 29.971, 29.972, etc. It's almost never a perfect 29.970000000~ like a computer wants. Same for the clock sync between audio and video -- it waivers a bit (all less than 1% values, mind you). Remember: that's 30 frames per second. In the process of syncing it to perfection in the TBC, and in the process of latching onto frames to digitize by the capture hardware (and software), there are rounding errors, which present as duped and dropped frames. Duped frames are fine. Dropped frames are generally not. It's going to happen. Fighting it is futile. The goal is to minimize it to an nth degree of 1% of the signal.
So be cautious of getting into a mindset that a TBC causes sync/frame problems.
The DPS-220 isn't a bad box. Being composite isn't super duper great, but the worst issue there will be chroma noise (crosstalk) and dot crawl.
This is the origional, with camcorder with tbc on >> dps-220 >> ati-600 >> virtualdub (with timing as specified in previous post) I don't see any dropped or duped frames. Wanted to upload this to see if it's OK quality or if I should be shooting for better. Additionaly i'll upload the same clip with just s-video to ati-600.
Should I start another post for enhancments? I'd be curious as to suggestions for proc amp controls as well as virtualdub filters for de-noise or really just general advice as I start down the enhancing path.
Here is with no dps-220. What's really interesting to me is that 7z compression did a better job at the first file than this one. This tells me that the video must be more stable, or that it contains dupes, not sure which yet.
here's a single frame. Before is with dps-220. I can't tell which one I like more, but I do think it looks like i'm losing video detail without the 220
If I might ask, are you able to audio preview during your capture?
I am basically able to capture flawlessly with my USB based ATI 600, but I cannot do so while listening to the audio (which is a must for my workflow).
Previewing audio causes a great deal of dropped frames.
(fortunately the usb 600 device captures video and audio so I beleive I will not have AV sync issues).
It is very very dependent on your hardware. Usually not. If you need to preview audio while capturing, then you will need some more advanced hardware like the ATI AIW card. We use ATI AIW cards in our machines that preview audio during capture, and on some we use a loop back solution that splits the audio before the capture. Turtle Beach and Creative Soundblaster are two very good audio cards to use for this. Another option for loop back is a program called Virtual Audio Cable that can accomplish this as well.
All is not lost and we can help you with your workflow.
-JMP
- Did my advice help you? Then become a Premium Member and support this site.
- Check out my latest Editorial.