I'm using an Asus P4C-800-E Deluxe, P4 2.8, 4GB PC3200.
Does SATA(1.5 GBps) provide enough bandwidth for lossless VHS capture using the ATI All in wonder 9800 pro AGP 8x? Although AGP 8x provides 2.1 GBps would the card ever reach that during capture? Or should I consider a board with both true AGP and SATA II?
I have several fast SATA HDDs but am willing to invest in SSD. Perhaps SSD isn't required for lossless?
I'm I best served by purchasing a new capture device based on PCI-E or USB? If so, any suggestions.
I assume I'm best served to capture lossless on the old 478 P4 2.8 and encode using my i7 to lossless-ish format. Willing to upgrade to P4 3.4EE if that would be enough to skip the transfer and conversion and capture direct to lossless-ish.
Aside from a Grex Advanced digital video stabilizer is there any other hardware that should be used?
Which ATI/AMD driver revision provides the best platform for VHS capture? I've noticed a difference between versions when it comes to Macrovision.
Should I run the OS and VirtualDub from one drive and capture to a second drive? OS on IDE, capture on SATA for example. What is the ideal drive configuration.
Should I capture audio using the ATI S-video/RCA dongle or PCI sound card?
+ Reply to Thread
Results 1 to 8 of 8
HuffYUV should get the bandwidth requirement down enough for the drive.
[QUOTE=AmigaFanBoy;2565193]Should I run the OS and VirtualDub from one drive and capture to a second drive?[QUOTE]
OS and capture on different drives.
The AIW has no audio capture capability. If you plug RCA audio into the purple box, you then route a 3.5mm cable from the AIW to a sound card (or use an internal cable).
Would a JVC HR S4800U be suitable as a S-VHS player?
The TBC in a VCR is not like the Full Frame TBC you can insert in between a VCR and a Capture device.
The TBC in a VCR "specializes" in compensating for mechanical defects in the video reproduction introduced by the VCR itself. Its customized for the VCR, and it takes place before the signal begins its journey outside the VCR and through the cables to the capture device. That journey can further degrade or worsen the defects even before they get to an external "Full Frame TBC".
In overly simplified terms the VCR TBC corrects for horizontal or side to side motion and flagging (or tearing) that looks like a piece of paper being ripped from a tablet at the top of the screen. It trims or expands the lines so they are all even from top to bottom. The external Full Frame TBC fixes up and down motion or "jitter" or "bounce" from vertical sync problems usually introduced by long or poor cables. You can't get both things fixed inside one VCR or external box.. they are separate and independent effects.
In early days with very good signals, or when capturing direct from broadcast tuners the signal quality was so good.. you didn't always need these things. But once the video was captured to VHS tape.. and then degraded over time.. and reproduced by video heads.. many things happened to the signal until today.. you almost always have to have both a VCR with TBC and an External Full Frame TBC to fix both problems.
Cable problems can also introduce brightness, contrast, hue and saturation problems that only an external Processing Amplifier (Proc-Amp) can correct.. or bring into the range that a video capture device can have the best chance of using its toolkit to correctly capture.
Using a DVR as a "fix all" or substitute for a VCR TBC, external Full Frame TBC and external Proc-amp.. is "possible" and a step in the right direction.. its more than nothing.. but only a few DVRs are capable of being used this way.. many others are not worth the trouble. You just have to realize its a measured "mitigation" attempt, not a guarantee of success.. nothing really is.. VHS tapes and playback vary so much.. each attempt is a gamble by itself.. even with the same tape.
Audio capture for internal capture cards was almost universally avoided by the better cards. First they specialized in demodulating the RF signal into video and audio components, and focused on the video, while shunting the audio to an external port on the back plane of the video capture card which could be connected to the Input of a sound card.. or they had a "Sound Blaster" internal header pin set on the capture card which made it easier to jumper the video capture card to the AUX or CD internal Input jumper on the sound card.
Most Windows systems already had a Sound card and device drivers setup and blended with the Windows Sound Mixer.. so the Video capture software simply cooperated with the existing Mixer as the sound source and captured video frames and interwove those with sound sample captures to make Audio Video Interleave files (AVI) files. While compressing the video frames and sound samples at the same time as capture was "theoretically" possible.. it was almost never done unless the video capture card had a special chip for compressing the video without taking up precious CPU time. Sound was almost never compressed at the same time because most sound cards did not have hardware compression onboard to do the job.
After the AVI file was created a second pass could be done to compress the file into MPEG or some other format when time to capture to disk was not as critical.
Later when web-streaming or Personal Video Recording became a thing.. more and more video capture cards came with hardware compression built-into their tuner and video capture cards and did not offer "any" Uncompressed AVI capture "at all" by that time it was considered a "Plus" and those were very expensive cards. Today those are considered "inferior" video capture cards because pretty much after Sandy Bridge CPUs systems got fast enough that we could afford the higher bandwidth and "better looking" picture an Uncompressed capture makes.. so those cheap cards turned around and became "sought after". A budget card like the ATI All In Wonder became much more valuable.
But until the AVI is on the disk.. you still have to play by the rules of engagement dictated by the hardware and operating system that must run the device drivers.. so an optimal system captures Uncompressed AVI on a second hard disk separate from the operating system and running Windows XP SP2.
Historically, video capture buses went ISA then PCI then AGP then USB then PCIexpress.
XP SP2 was at its prime when using AGP, that is its device drivers were most stable and least problematic. USB2.0 was required for Uncompressed capture speeds but USB 2.0 support was "added on" to XP after that operating system was launched and device drivers went through some instability periods, both for the USB Host controllers OHCI and UHCI and the devices that attached to those Host controllers. When Vista and 64 bit system like Vista and Windows 7, Windows 10 came along the device driver models were re-invented and many companies did not update or offer 64 bit versions of their device drivers.
They also chose not to certify or sign many of their driver releases and Microsoft slowly but firmly stopped loading them on 64 bit systems, choking USB2.0 device driver support for those capture devices off. There are only a very few USB2.0 video capture devices that work on Windows 7 and Windows 10 without issues.
When AGP was dropped by hardware manufacturers for PCI express, the video capture devices were transitioning away from Uncompressed video capture towards hardware compressed (only) video capture cards. At the same time ATI was in decline and about to undergo being bought out by AMD. Also the PCI express specification was very unstable and subject to motherboard maker "interpretation" the BIOS for managing Interrupt lines on the new PCI express bus often "collided" or put too many things on the same Interrupt lines and caused recurrent latency problems for both sound and video capture devices. It was a mess.. the few video capture cards that could do Uncompressed video capture on PCI express during that time are very few and depended upon the grace of the motherboard manufacturer and the stability of their BIOS and pure luck.. not to have issues.
When AMD finished acquiring ATI they released a one last dual AGP and PCI express card set, the x800 XL and x800 XT and quit AGP. All AMD/ATI cards after that were PCI express only.. with inherent motherboard compatibility issues. The ATI X1300, X1800 and X1900 were the last of the ATI T200 capture cards. All AMD cards after that relied on hardware compression chips so uncompressed capture was no longer an option.. and they had various reported issues with their gain control, or further PCI express and USB issues.
Macrovision comes in many forms, but an early form simulated a problem which external Full Frame TBC corrects, so using an external Full Frame TBC effectively makes the early form a non-issue. Macrovision morphed into digital forms once video began being transmitted in compressed digital form, but those do not apply to SD video capture.
A DVR used as substitute for an external Full Frame TBC can detect true and false Macrovision signals and shutdown its signal output.. so they are more vulnerable to Macrovision due to their design being made to pay attention and shutdown when it thinks it detects a Macrovision signal. That is a reason to "not use" a DVR as a replacement or substitute for an external Full Frame TBC. It is a consideration that is not in the DVR pass-through favor.
Last edited by jwillis84; 14th Nov 2019 at 00:08.
Is a Grex Advanced digital video stabilizer no longer required if I were to use a S-VHS deck with line-TBC or ES10/ES15? Or should Grex also be used?
You will still need the Grex to remove Macrovision.