I pretend to select a digital format for video8 archiving masters and from these make enhanced copies to show on a pc environment.
Current status
I made my previous analog video8 Pal captures with a simple workflow
D8 (tbc on) – firewire- PC WinDv ( lossy DV SD file)
The results were in general good , however I tried also a more complex workflow, that potentially could have delivered better results
D8 ( w/TBC ) – svideo- with/without Ext. TBC (AVT-8710) – ADVC-55 ( or MiniDV Cam with passthrough ) –firewire- PC – WinDv or VirtualDub – (lossy DV SD file). I used small and high quality interconnect cables to try to reduce signal losses.
However I have not identified any visible improvement and got even the impression of a slight worse results
After reading several posts and answers given to a previous related thread by myself I came to the conclusion that it was necessary to capture in a uncompressed/lossless format to retain maximum information from the analogic source and to avoid /reduce losses during the reencoding in the post processing tasks to enhance / restore .
Due to the difficulty to find a good internal capture card ( AJA, Blackmagic, etc ) to use with a new pc running windows 8/8.1 with PCIe, I decided to try an external capture card Startech usb3hdcap, that delivers un uncompressed video stream through usb3 and is DirectShow compatible . The device also support almost all type of video inputs namely composite, svideo, component, vga ,hdmi, dvi, and is compatible with most usb3 controllers. Additionally I could use Virtualdub or AmaRecTv in full without restrictions and record in any format/codec supported by these applications. Some reviews about the device were not fantastic but when it has been found that the last drivers from micomsoft for xcapture-1 were compatible and with them the device showed excellent performance, some of the reviews now recommend it.
Actual options
As a container I think Avi is a good choice as it is the reference format for Virtualdub but related to the lossless codecs I don’t know if there is issues that could favor one of them for this situation.
The lossless codecs more usual with Virtualdub are I think Huffyuv and Lagarith with the first being faster and the second achieving better compression. Institutional entities however use other formats like Jpeg2000 and FFV1 .Could Lagarith be the better for this purpose?
Video format - selecting Colour space ( RGB, YUY2, etc ) subsampling (4.4.4, 4.4.2, etc), bit depth (8, 10 ) is another point where I have difficulty choosing the best association.
Another point is upscaling , should I try to maintain the original resolution or is it useful to upscale .
Having in consideration that I’m dealing with Pal tapes can anyone suggest the best options to retain.
8-bit should be sufficient. 10-bit requires much more processing power for at best a very limited if any gain with Video 8 source material. (Some 8mm/Hi8 gear internally used 8-bit for luma and 6-bit for chroma components.)
4:2:2 is sufficient, especially if you plan to do any image processing/correction.
No surprise that the ADVC analog capture and D8 output via firewire were about the same. Both end up as a DV stream. The ADVC signal path includes additional processing stages that could have impacted the image either way.
Why would you want to upscale the image during capture? The Video 8 image was initially limited by the camcorder lens, ccd, and processing (including the analog tape format) to something akin to 320x480 at best (for NTSC), with the color information substantially less.
It may be better to process and store the image at native resolution, and leave any upscaling to the display system when played back.
After reading several posts and answers given to a previous related thread by myself I came to the conclusion that it was necessary to capture in a uncompressed/lossless format to retain maximum information from the analogic source and to avoid /reduce losses during the reencoding in the post processing tasks to enhance / restore .
Analog tape is best captured to lossless media. It need not be "uncompressed" -- huffyuv can capture to YUY2 losslessly compressed 720x576 media. Lossless compression is not like lossy encoding such as DV, MPEG, h264, etc, but is more like the lossless compression of ZIP or RAR but much faster and designed specifically for video. Huffyuv or Lagarith lossless compression reduces the file size to about 1/3 that of an uncompressed capture. Huffyuv is slightly faster than Lagarith for real time capture. Both huffyuv and Lagarith can be used in post-processing to make smaller working files before the final encode to whatever you want for final delivery format, which could include everything from DVD to standard definition BluRay/AVCHD, mp4, etc. For archive, nothing is better than lossless compression, although other lossless compressors besides huffyuv or Lagarith are available for smaller archives with no quality loss but with slower performance.
Because 720x576 is a standard frame format for many of the PAL final delivery formats mentioned, most people capture SD analog video to that frame size. It will prevent the need for resizing later and has a resolution quality similar to that you see on your TV when playing standard definition video. Video8, VHS and similar formats simply don't have the initial detail or resolution for upsizing to HD formats. HD looks the way it does because of initial resolution and other factors, not just because HD is "bigger".
While many do capture analog sources to DV, be mindful that analog sources and DV have many differences, and those differences are not very friendly to analog sources. DV interlaces poorly and imbeds analog noise and other defects as compression artifacts. These artifacts include DCT ringing, aliasing, mosquito noise, and field timing differences that make many post-processing filter operations difficult and often visibly destructive.
You mention some high-priced gear such as BlackMagic, which are not recommended for analog capture. Ther USB and PCI/PCIe devices often mentioned in this forum would be more suitable, and some of them have drivers for Windows8 that can be downloaded from this site. Unfortunately the designers of Winn8 didn't have quality video processing in mind. XP is still preferred by many. If XP isn't possible, then some concessions in the processing department have to be made, but you can still work around most of the problems.
Not being familiar with the Startech usb3hdcap, I'll have to leave further comments on that device for others.
Huiffyuv and Lagarith lossless compressors are very popular. You can use others if you wish, but if you submit samples for queries to many video forums, its users almost always have huffyuv and/or Lagarith and are averse to installing a truckload of other codecs that they never use. Many media players won't recognize every codec in the world. So as a matter of compatibility with various systems and software and players, I use huffyuv and Lagarith for work.
Capture to 10-bit if you like. However, many filters and apps that you encounter will work only with 8-bit video. Most Avisynth filters work with YV12, many work with YUY2 and RGB, and VirtualDub uses mostly RGB filters and a few for YUV. Some basic levels and color correction often require Avisynth and can be done in YUV colorspaces, while a great many popular and sophisticated color correction filters will work in RGB in VirtualDub (some will work in YUV as well, such as TMPGEnc encoders' excellent image filters, Premiere Pro, AfterEffects. ColorFinesse, Colorista, and many others). YUY2 is preferred for capture because it more closely resembles the way analog tape sources store video data. Avisynth has functions and filters for making colorspace changes properly, when needed, with several types of video.
Quote:
Originally Posted by AJAX1
Video format - selecting Colour space ( RGB, YUY2, etc ) subsampling (4.4.4, 4.4.2, etc), bit depth (8, 10 ) is another point where I have difficulty choosing the best association.
I can't answer for industrial compressors and color. If your final delivery format is DVD, BluRay, AVCHD, or most web formats, the colorspace is usually YV12 8-bit. Some encoders, however, can use higher bit depth internally but will output 8-bit video.
Quote:
Originally Posted by AJAX1
Another point is upscaling , should I try to maintain the original resolution or is it useful to upscale .
As a vast generalization, and depending on any specific piece of video, it's not a good idea. You can make SD look pretty nice and improve it a lot, but it will never look like HD. However you can gain some quality performance in big TV displays by encoding to standard definition BluRay using higher bitrates in h264 and MPEG than are available for SD-DVD.
Thanks’ Sanlyn and Dpalomaki for yours detailed answers.
However related to the lossless codecs, even if I now think that I will probably be better to stick with a format like HuffYUV (for compatibility and namely if the capture system CPU/disk is not to efficient to give additional assurance for real time capture without drop or inserted frames) or eventual Lagarith (if I´m working with a PC where performance is not an issue to get smaller files), I would like to have yours views/ comments about other possible formats like
Utvideo
MagigYUV
MSU lossless codec
I think these codecs could be more efficient in terms of compression/decompression speed and file compression results, however I have no idea of compatibility problems with players , with Virtualdub/Avisynth , encoding and with any other applications , usually used. Even if they are eventually more efficient do you think I could run in problems if I use them and it will be better to take a more conservative approach.
If I have well understood the better format /definitions I can use for capturing video8 for master archiving ( I will have also a large stock of vhs to capture afterwards ) will be
HuffYUV / Lagarith YUV2 4.2.2 8 bits at a resolution of 720x 576 ( Pal ) is that correct ?
Related to the capture device I bought this startech usb3hdcap device because it can work with any pc if they have a usb3 input and delivers uncompressed video and is compatible with Virtualdub so I could get my lossless files in any PC . However I still have a legacy XP PC with a Asus TV7134 WDM video capture card ( PCI ) that works fine with Virtualdub. I read elsewhere in this forum that this cards with Philips SAA7134 give similar results to the ones given by the ATI AIW 600/650 usually recommended and someone even says that the Philips decoder is a 9 bits decoder vs a 8 bits decoder on the ATI which could eventually give some benefits. Also that the results will be better with original Philips drivers mines for now are Asus provided. It came with Intervideo suite.
If the results from this saa7134 card are better then the ones I can get from the startech I can revitalize this XP PC ( Pentium 4 , 3.4 Ghz ) ( 2 new SSHD seagates drives( 64 GB SSD+ 2 TB ) one only for capture- ram from 1 GB to 4 GB for instance ) .
I made already some samples but don’t see significant difference related to the results I got from the startech. However I have no tools to analyze the results only my eyes and even these are not educated enough for this .I noticed that I get more bandwidth from the startech about 80 Mbits/s and about 70 Mbits/s from the Philips card with similar options HuffYUV (32 bits ) YUV2 4.2.2 .
If I eventually have better results from the startech ,do you think I could get benefit making the capture on a XP environment (as you say XP is more video quality friendly ). I can put a usb3 card ( however the speed will be limited to 1,5 Mbits/s due to PCI limitations but even so about 3x usb2 perhaps will be enough for the uncompressed stream)
HuffYUV has the advantage of broad playback compatibility. Mostly because ffmpeg and VLC support it. The newer formats really don't save much with SD video, they make more of a difference with HD. Besides, disk space is cheap.
As noted above, storage is cheap, so a few % difference in compression efficiency is not a big deal.
For archiving I would tend go with main stream formats that are likely to be well and widely supported into the future, and try to avoid those that are "hobby shop" or nitch products that are unlikely to be supported ten years from now.
Only you know what quality and capability you need for your project and the end product, and how much time you want to devote to the process of getting there vs. being there. It amounts to individual decisions as to how good is good enough. In general, the last 10% costs more to achieve than the first 90%, so you have to make your trade-offs and find your comfort point.
Well, then, this is my own take on several issues. There are many, many variations.
Quote:
Originally Posted by NJRoadfan
HuffYUV has the advantage of broad playback compatibility. Mostly because ffmpeg and VLC support it. The newer formats really don't save much with SD video, they make more of a difference with HD. Besides, disk space is cheap.
I agree, many newer compressors are better suited for HD, although I'm using Lagarith for HD work files. I use huffyuv only for YUY2 capture. System compatibility with huffyuv is not what it's made out to be because there are so many permutations of huffyuv, almost all of which have the same FourCC code. What I get from huffyuv on my capture machine is playable on everything on that machine, but the same capture transferred to another PC or a different huffyuv sample capture downloaded from a forum will play as a scrambled image. huffyuv_MT is not recognized by VLC or MPC-BE even though huffyuv_MT is installed on my PC. FFdshow doesn't help,either. Avisynth and Vurtualdub have no trouble with MT, but I recompress to Lagarith which is recognized by every player I have. huffyuv seems to install differently on every PC and seems to be affected by different capture card drivers. The huffyuv that comes with ffdshow seems to be a new version every couple of years or so. Your mileage with huffyuv might be different, but I use it only for capture.
Most huffyuv versions don't support YV12. I know that most colorspace conversions done properly aren't as damaging as some folks say, but repeated colorspace changes involve interpolation and rounding errors that eventually add up. Avisynth is often the primary tool for initial post-processing. Most of its most valued filters work only in YV12. In many cases one can use Avisynth's dither plugin to use 16-bit processing that's sometimes necessary to preserve quality: this filter works only with YV12, as do mainstay filters like QTGMC. If you want to go through the trouble of sticking with huffyuv exclusively you'll have to hassle with reconverting from YV12 back to YUY2 with every working file, which is an unecessary conversion that can be avoided by using a codec that supports YV12 when it's required. I use Avisynth's color conversion functions, which seem to make those conversions as well as or usually better than other applications. The choice is yours, but once I get a video properly into YV12 I leave it there until (and if) I have to go to something like RGB for advanced color correction or VirtualDub utilities.
Quote:
Originally Posted by AJAX1
I would like to have yours views/ comments about other possible formats like
Utvideo
MagigYUV
MSU lossless codec
I think these codecs could be more efficient in terms of compression/decompression speed and file compression results, however I have no idea of compatibility problems with players , with Virtualdub/Avisynth , encoding and with any other applications , usually used. Even if they are eventually more efficient do you think I could run in problems if I use them and it will be better to take a more conservative approach.
All of MSU's filters are disapppinting at best, and many are garbage. Don't believe MSU's hype, and don't use them.
I haven't used MagicYUV. From reading about it in posts from developers and some testers, it offers no efficiency advantage over huffyuv, Lagarith and some others, and seems to be set up better for HD. If you want to read some guru remarks about it, this is the forum thread on Doom9 where it was introduced: http://forum.doom9.org/showthread.php?t=170227
UT Video Codec supports many colorspaces and is widely used for archiving and work files. I have downloaded UT videos from forums and played them successfully in several players. I've read that it's not used that often for capture.
I agree with dpalomaki and suggest that you avoid overthinking. Standardize with mainstream compressors. Huffyuv and Lagarith are widely used for capture just about everywhere and are recognized by most media players (my exception with huffyuv noted earlier). UT has also found mainstream use. Questions about efficiency soon dissipate when you realize that they all give pretty much the same results. They are popular because they are time-proven, work well, and are reliable.
If you're getting good results with the capture gear you have now, ultimately your judgment about quality will be enhanced after you've actually got into post-processing and encoding. I'd suggest that you work with one or two source tapes rather than capture a bunch of tapes wholesale, because what you learn from the first few captures will affect the manner and equipment you use later. Most beginners eventually submit unprocessed short samples of captures for evaluation by those who've been doing it for years. They can point out the pros and cons of what you're doing.
The best way to learn about these procedures and issues is to get into it and learn to evaluate actual results. It's good that you're looking around for authoritative info on capture and digitizing, but ultimately a few short captures are worth thousands of words and months of research.
Quote:
Originally Posted by AJAX1
HuffYUV / Lagarith YUV2 4.2.2 8 bits at a resolution of 720x 576 ( Pal ) is that correct ?
Yes. I'd suggest huffyuv for capture. It's not that great a speed factor over Lagarith during capture, but at the capture stage every little bit helps. Capturing as discussed here doesn't require a super-computer.
PAL is usually captured at 720x576, losslessly compressed as YUY2 AVI, at 25fps interlaced. Audio is captured as uncompressed 48KHz PCM audio. Don't capture or do any post-processing with compressed audio, as almost all audio compression other than PCM is lossy and will dramatically lose quality with all the recompression that often occurs during post-processing. In VirtualDub observe the default audio output at PCM (.wav format). Later when you encode your final output you can compress audio to Dolby AC3. PAL audio can also be encoded as mp2 (MPEG layer 2), but it's a little obsolete and is inferior to AC3.
Unlike MPEG or h264 encoding, which is encoded in small Groups of Frames (GOP's) of mostly partial and lossy compressed images, lossless AVI is a continuous stream of fully decoded, full-sized frames. Encoded video has display aspect ratio (DAR) flags for 4:3 or 16:9 playback. Decoded AVI has no display ratio flag; its display ratio for PAL 720x576 format is 5:4 -- that is, the frame displays at its actual size, not at 4:3 and not at 16:9. Many are thrown off guard by this display, but in VirtualDub and most media players you can manually set the display for 4:3 if you wish. Most media players deinterlace during playback the same way a TV does (in VLC deinterlacing by default is disabled, but you can set VLC deinterlacing to "Auto"). NLE's and editors like VirtualDub don't deinterlace -- so don't be surprised if you see interlace effects in VirtualDub. For the time being, please carefully observe this general rule: deinterlacing is not without effects, so don't do it. Should you be forced to do it because of certain and unavoidable frame repair problems, don't do it in VirtualDub or with anything else except Avisynth. Deinterlacing and re-interlace in most NLE's, even those with "pro" in their names, is horrible.
A note on XP vs. Win7, win8, etc. Some Virtualdub filters will crash in Win7 and a few give Win8 trouble. Use 32-bit compressors and filters -- you can't mix 32-bit and 64-bit apps and filters. The major advantage to 64-bit is that it can access more memory, but with some exceptions most filters don't run "faster" in 64-bit machines. A Pentium4 XP will suffice for SD processing, but may seem a little slow with single-core CPU's. Since many filters you will use aren't multi-threaded anyway, CPU speed is the major limiting factor. You can transfer captures to Win8 for further work, but be aware that some free utilities don't have Win8 versions. People have devised workarounds for some problems, but Win8 has its limitations. The amount of free and well regarded video software available for XP is astounding. One of my capture PC's is a 10-year old dual-core 2.2GHz XP that still gives a good run for the money. There's also an old Dell P4 3GHz XP that I let run overnite for really long processing and encoding runs when the other PCs are busy.
Looking forward to a short sample capture if you have questions and want some evaluation. If you don't know how to cut a short, unprocessed, unfiltered capture sample, just ask.
I´m attaching 2 short samples one captured from my old XP PC Pentium 4 - 3,4Mhz with ATI PCIe Radeon X300/256 MB and Asus TV7134 WDM PCI video capture card ( with Philips SAA7134 chip ) and the other from the Startech usb3 external capture device: Both have been captured with VirtualDub same version, same codec HuffYUV , same options 720x576 (PAL ) YUV2 4.2.2 , 8 bits interlaced.the capture from startech device as been made on a medium sub-powered i5 laptop.
I would appreciate if you can do an evaluation of the samples as I am not sure which capture device provides better quality. The analog signal is from a video8 Pal cassette through a D8 Sony camcorder - svideo (with tbc on and dnr off ) in both cases. I have found a datasheet with the chip decoder that comes inside the startech device as it is the same as in the Micomsoft XCAPTURE-1 device I´m also attaching it.
Is there any kind of tools to analyze the output quality . If we don't have the eyes well trained and enough experience as is my case and the outputs have not a significant difference sometimes is difficult to decide the better workflow.
Not related to this conversation but with the previous one about the lossless codecs , is there a free Jpeg2000 codec for virtualdub ? Many large cultural institution are trying to use it as a new standard could it be a possibility for master archiving ?
ProRes422 and DNxHD are best for HD. I wouldn't even mess with any else. When I was doing studio work, all HD was handled on a Mac. That's just one of the tasks that it's better built for. (For SD video, it's a DV-only system, and has limited tools.)
The Canopus ADVC-55 is hardware locked as DV. So saving to Huffyuv is 4:1: (NTSC) or 4:2:0 PAL. PAL fine, NTSC not. DV was not made for conversion.
The external TBC is for the signal quality, not image quality.
Everything MSU makes is vastly overstated. They're huge BS'ers.
Forget the other codecs. Use mainstream Huffuv, and call it good.
____
I archive my own VHS home movies as 15mbps Blu-ray spec SD 720x480 MPEG-2. They look great. A version can be saved to hard drive, and a disc can be burned for myself and family member. At least one member also has me load them on hard drive, too.
Only when a video needs restoration, do I capture to Huffyuv. It's processed, then converted to 15mpbs MPEG when done.
Only a few really important segments are saved as Huffyuv, because the MPEG was not good enough. This is usually tapes with overly dark scenes (underexposed), as that sort of issue may not compress well.
To me, Huffyuv is an intermediary/working format. It's not one commonly used to archive.
I would appreciate if you can do an evaluation of the samples as I am not sure which capture device provides better quality. The analog signal is from a video8 Pal cassette through a D8 Sony camcorder - svideo (with tbc on and dnr off ) in both cases. I have found a datasheet with the chip decoder that comes inside the startech device as it is the same as in the Micomsoft XCAPTURE-1 device I´m also attaching it.
Neither capture device appears to be satisfactory. AA problem also might be caused by your playback device, which I'm not familiar with. Both captures have serious interlace problems, with the Startech problems looking worse.
The image below is interlaced frame 64 from the Philips capture. Notivce the split and broken lines on diagonal edges, easiest to see along the top of the bright building but visible in other lines and in the red characters near the bottom.
Deintrlacing and applying anti-alias filters sometimes smooths these problems, but deinterlacing in this case shows that both fields have the same problems, which can't be repaired. The image below is detail fom the top of frame 64. Top image = interlaced frame, middle-image = top field deinterlaced, bottom = bottom field deinterlaced.
Quote:
Originally Posted by AJAX1
Is there any kind of tools to analyze the output quality . If we don't have the eyes well trained and enough experience as is my case and the outputs have not a significant difference sometimes is difficult to decide the better workflow.
The eyes are the most ready tool. It doesn't take much training to see bad interlace twitter in this video, either during playback or when viewing still frames.
Another handy tool would be a histogram. The histogram of frame 64 below is typical of the both captures, showing invalid levels outside the video range of RGB 16-235. The histogram below shows luma values (white part of the graph) that are well outside the valid range for video indicated by the shaded areas on each side of the graph. The large spike at the right-hand side shows clipped brights (i.e,, bright detail destroyed during capture). You can see the effects in the bright part of the front of the building, where there is no detail at all in the structure. Lowering luma later in processing shows that there was, indeed, some detail in the woodwork and brickwork, but most of it was clipped off during capture. Invalid levels are best repaired during capture and in the original YUV colospace. After the video is translated into RGB for display, that data can't be retrieved.
The capture also shows oversaturation especially in the reds (in RGB, the red in the letters exceeds RGB 255). Both capture cards are blowing out brights, but the Startech has lowered gamma and crushed darks as well. Each card captures a different image size. The Startech captured an image that is about 704 pixels wide without the side borders, which is more usual for 4:3 PAL capture. I shoulod also mention that the Startech capture has reversed fields: the Philips capture is top field first, the Startech is bottom field first and has the worst interlacing artifacts. Video8 is usually top field first.
The original scene itself appears to have a contrast range that is beyond the limits of digital video, but contrast filters during post-processing can help with that. The levels problems can be prevented during VirtualDub capture with Levels controls, and further tweaked in YUV during post-processsing. There's no fix that I know of for improper interlacing during capture. The problem frequently occurs with playback and capture devices that are not designed primarily for analog video. Noisy interlace is also common with analog to DV capture. The attached mp4 shows the problems involved in trying to clean up bad interlace.
I'm not familiar with the other device you mentioned. Perhaps other members can advise.
Last edited by sanlyn; 05-04-2015 at 11:24 AM.
The following users thank sanlyn for this useful post:
AJAX1 (05-05-2015)
I noticed nothing in both captures and I thought even they were quite ok. , it´s why I say I´m not yet prepared to identify capture problems and actively seek for defects. I was not also aware that we need to adjust the levels for capturing based on histograms values, I let them in their default values .
As you say the levels can be corrected, the problem will be the interlace problem namely if it can´t be corrected
I have used a Sony Digital8 camcorder DCR-TRV238E PAL ( with tbc and dnr ) as I thought this type of player were preferential for playing video8 for capture purposes, but I have also a Sony Deck Hi8/8 ( without tbc I think ,however if needed I have an external tbc) . I will try it and see if the problem comes from the player or from the capture devices , but it seems strange that both capture devices have the same problem perhaps the player is the culprit.
I will see if I can get a guide to give me more insight info on how to fine –tune levels , options , etc. , needed to do a well balanced capture with virtualdub and I will try to solve this interlace problem or find other capture device if the problem are from both capture devices.
Levels during VirtualDub capture are managed using the "Levels" menu option filters, which access controls present in capture or graphics card drivers. "Brightness" usually controls blacks, "Contrast" usually controls brights. VirtualDub capture also has a histogram similar to the white luma area in the YUV histogram image posted earlier. The histogram's white graph turns to bright red at each side border when the signal exceeds safe levels. Keep in mind that during capture the histogram also sees black side borders, which will always be a "spike" it the left hand red area. Saturation, Hue, and Sharpness are also usually present, but it's advised to avoid those with analog capture because those elements of analog source are too unpredictable to control during capture. Analog tape should almost never be sharpened anyway. There is no sense in sharpening tape noise.
An outboard tbc will be helpful for undoing copy protection, but you're not likely to need that for home videos. That type of tbc is a frame-level or signal-level tbc that improves the frame-by-frame timing stream, helps ensure audio sync, and prevents dropped frames. The type of tbc that's needed most for analog tape source, however, is a line-level tbc that ensures correct line-by-line sync within each frame to reduce image distortion. Frame level tbc's have no effect on in-frame line sync. Likely an analog camcorder with play-through ability will have a built-in line tbc.
It's possible the player used is more to blame than the capture devices. You might check the player's settings, if any, to make sure that no enhancements or deinterlacing are turned on. But likely an analog player would be a better choice.
Quote:
Originally Posted by AJAX1
I noticed nothing in both captures and I thought even they were quite ok. , it´s why I say I´m not yet prepared to identify capture problems and actively seek for defects. I was not also aware that we need to adjust the levels for capturing based on histograms values, I let them in their default values .
It doesn't take long to spot signs of serious problems. Bad interlacing and line twitter are rather obvious, but they are capture-chain problems rather than something one can correct later in software. When you say you assumed "default values" for input, note that analog video and digital video are different worlds. There is no universal "default" value. Even digital video is no guarantee of consistency: all you need to do is surf through some HDTV channels to see the differences in color balance, contrast, and image noise or quality.
The usual color imbalances, excessive grain, a slightly soft image, spots, chroma shift, chroma bleed, etc., are the "standard" analog tape defects that are best repaired in post-processing. Advanced filters that repair these defects are far too slow for real-time capture. Some of the defects seen in the captures you submitted, other than interlace and levels, were chroma bleed and chroma shift, noisy red over-saturation (very common), occasional dropouts or image ripples, and a somewhat "processed" look that may have been due to image "enhancement" features present in many players.
Your submitted captures were better than the disasters we often see for early attempts. The most effective way to solve problems and successfully archive our analog memories is to make captures and work with them. It doesn't take long to learn new concepts in this endeavor.
An outboard tbc will be helpful for undoing copy protection, but you're not likely to need that for home videos.
External TBCs are for non-visual signal noise. It exists on all VHS-format and Video8-format tapes. "Copy protection" is simply an artificial video error. But the tapes still have natural errors. An external TBC is needed. Too many people assume that it's not needed because they can't "see" the improvements. Signal errors cause other capture workflow errors, especially dropped frames.
Quote:
That type of tbc is a frame-level or signal-level tbc that improves the frame-by-frame timing stream, helps ensure audio sync, and prevents dropped frames. The type of tbc that's needed most for analog tape source, however, is a line-level tbc that ensures correct line-by-line sync within each frame to reduce image distortion. Frame level tbc's have no effect on in-frame line sync.
Not just "analog tapes", but anything transmitted analog.
Quote:
Likely an analog camcorder with play-through ability will have a built-in line tbc.
Most cameras (camcorders) have no real TBC to speak of, even if the devices claims otherwise.
________
I probably need to read this thread more closely, as I'm not quite sure what's going in here. The TBC topic just jumped out at me.
Hopefully I've not taken something out of context!
Yes, lordsmurf is correct: I should more correctly say that for analog capture, one needs both tbc types. The frequent assumption is that an external frame-level tbc will do it all, but that assumption is incorrect.
"Most cameras (camcorders) have no real TBC to speak of, even if the devices claims otherwise"
If as lordsmurf says camcorders ( digital8 or not ) have dubious line-level tbc quality would it be useful to switch off the internal camcorder tbc and dnr and insert in pass-through for instance a JVC HR-DVS3 that I think as a good tbc and eventually complement with an external TBC ( avt-8710 ) or all these additional steps could degrade the signal instead of improving.
Not sure that the HR-DVS3 can be used as a tbc pass-thru device. Most combo DVD/VHS players can't be used as pass-thru. The fewer new models after 2006 have flimsy tbc's, in any event. Most users recommend Panasonic ES10/ES15 or Toshiba RD-XS** series for pass thru, with Panasonic largely favored.
My major concern is that neither of your submitted captures seem useable and have serious problems. I'm under the impression that the StartTech device encodes internally, regardless of whether or not it can output a signal that VirtualDub will recognize and capture as lossless media. The remaining card has the same problems, but worse, and seems to be designed for game capture which is usually progressive. Others might have a different take on those two capture devices or can add more information, but I haven't seen either of those capture pieces recommended for VHS or Video8 capture to lossless media. The camera you used for playback should not create the defects seen in your samples, but it's possible that it does.
The other difficulty is Windows 8. If you browse through threads here you'll find that XP-based systems are favored far more frequently than others for capture and generally for the vast amount of good-quality free and paid software available for XP and for output to a great many formats. Second in the preference list is Windows 7, in which many XP devices and software will operate. Windows 8 users seem to constantly report many problems and setbacks with that system for the operations you're trying to accomplish.
When you start mentioning high-priced equipment, it's tempting to get onto the wrong track. Price isn't everything, since a device like the Diamond MultiMedia TV Wonder USB or the ATI 600 USB are recommended here as operable in Windows XP, Vista, and Win7. These are not out of this world prices like BlackMagic (which is not recommended for what you want to do anyway, mainly because it won't work), and they are the closest equivalent to the analog performance of the old ATI All In Wonder AGP cards.
Other than those recommendations, I still can't see exactly why your captures have problems that are so obvious. Perhaps other readers can offer a precise technical explanation. I've always followed standard recommendations for hardware and software that are able to deal properly with analog sources.
For less than it would cost for you to rebuild an entire capture setup, Video8 can be captured to losslessly compressed media by a specialty shop with the correct resources. Professional members at digitalfaq offer services in the top banner of the forum window. Why not contact staff or lordsmurf and see what they offer? They are highly recommended. Once you have a proper lossless capture you can do whatever you want with it in Windows 8.
In Europe there is almost impossible to find any of the cards recommended in this forum , it´s why I was searching for alternatives .
However I was trying 2 different approaches one quite conservative, the one supported on the legacy XP PC and legacy capture card based on Philips Saaa7134 chip , both are about 10 years old. The capture cards based on this chip have in this forum and in others satisfactory/good comments. The startech approach was a completely new approach as it is a new card also.
It´s true that it´s driven to the gamers market segment , but at least for digital progressive capture it´s not a bad one ( and I was in need of one for capturing through hdmi, it´s why the risk was small). But as the miconsoft capture x1 (this one the startech is a sort of clone without pass-through ) these cards have also in mind retro gamers namely playstation 2 and similar or even olders games consoles which were analogic it´s why they includes analogic capture.
The analogic chip decoder inside is the TW 9910 which datasheet I posted some days ago and it didn´t seem to bad also. And if the results had been satisfactory it was really interesting as this capture device as almost all type of inputs and could be used in any new PC with windows 8, 7 whatever if it as a usb3 and does provides a raw video stream.
If the unsatisfactory results were only from the startech device I wouldn’t have been very much disturbed ,what disturbed me was getting similar bad results also from the other workflow that is much more conventional and tested , it´s why I think the dgital8 camcorder could have something to do with it.
I have other video8/hi8 equipment, I have used the D8 camcorder as in the forums that I consulted including this one is considered a good approach even the better one sometimes, for capturing video8.
However to try to solve this situation and if the culprit is the camcorder or not I made a small capture with a different player, a Sony deck combo HI8/8 – SVH SLV T 2000 and I’m asking if you will be so kind as to comment about this sample( tape video8 Pal ). It does seem to me as having lower artifacts then the other samples , but I´m not sure .
If the results are better, then the problem comes from the camcorder, In this case I will try after with this player and the startech to decide which capture card to use.
Deck SLV T2000 video TBC (AVT-8710) – PC CP ( Philips Saa7134 )
If the results are better, then the problem comes from the camcorder, In this case I will try after with this player and the startech to decide which capture card to use.
The results aren't better. Are you saying that you can't see the obvious interlace problem in the objects below? (image is 2x blowup of detail in the original frame 251):
You can deinterlace the video and smooth some of those defects, but when reinterlaced they will reappear because improper deinterlacing + internal lossy h264 encoding, and decompression on output and reinterlacing will bring them back. This is severe aliasing. It is caused by improper deinterlace. It won't go away.
The otehr problem is apparent lossy compression effects, which appear in many forms. The severe camera motion and hopping doesn't help anything, either. Below is detail from two different frames of the original sample. Notice what happens to the large yellow barrier in the lower right of the frame between frames 68 and frame 104:
Frame 68 original (detail):
Frame 104 original (detail):
Some of this is due to camera motion and recording, some of it is compression artifacts. Also note the chroma smear, oversaturation (especially in red), and the blue chroma"ghost" on the coil and write objects. Overall, excessive camera motion and added compression are causing many problems, some of which can't be repaired. I also note that yellow in some areas of the image is blown out to nearly white.
During interlaced playback you'll also notice jitter and ragged edges in the time stamp characters. When deinterlaced, part of the reason for this jitter is the fact the original interlaced fields are twisted or warped alternately left and right in the bottom of the image, which can be seen if you observe objects in the lower part of the frame during progressive (deinterlaced) playback.
I have seen video and discussion posts in other forums as well, concerning this capture device. Regardless how "great" others may think this card is for some purposes, it simply doesn't appear to be a proper tool for what you're trying to do. You can continue with it if you wish, but you'll have a lot of work ahead of you.
Apparently you've made an effort to control levels during capture. You should do so, but be careful doing it. Your sample is washed out despite controlling white levels to the safe area shown in the histograms. The problem here is, black borders and low-border head switching nosie were allowed to affect the histogram.
Below is a sample of VirtualDub's capture histogram with incoming values falling outside of the safe area at both sides:
Notice the left-hand "spike" at the far side of the histogram. This almost always indicates crushing of some dark values, but the leftmost spike is likely black borders. Below is an adjusted histogram with the brights lowered into the safe area, and a spike for black borders still present in the "red" area (which is where a "black" border should be located):
In the above histogram, brights and darks are in the safe area. Black borders, or otherwise unimportant black details, are spiked at the left where they should be. If you want to be more certain about dark values brought on by black borders and other border noise, you can use the Crop feature in VirtualDub capture to temporarily remove borders that would affect the image. Don't forget to set all crop values back to zero before starting the capture, or your capture will be cropped and the frame size will not be correct.
Below is an image of the original (interlaced) frame 151, which has elevated black levels and looks washed out. The black borders in this image are not black, and other dark objects are washed out. The dark objects and darkest shadows in this image don't go below RGB 60.
Here are YUV and RGB histogram for frame 151. In YUV (left image), the "black" border spike is obvious at RGB 16 or so, with nothing darker than the that spike. The brights are within the RGB 235 safe area, but notice in the RGB histogram that darker tones are washed out and brighter Red and Green colors are clipped because the video spectrum has been shifted toward the bright end.
Below, adjusted levels and chroma are shown in the YUV and RGB histograms for correction in Avisynth and VirtualDub. In YUV and RGB alike, the zero-black of border area is at the far left of the histogram, while some bright detail in Red and Green are restored in RGB.
Then image below is the adjusted frame 251 (interlaced) with new borders. Red satuation has been readjusted after being tamed in YUV, and yellow satuation was slightly lowered to help prevent some of the yellow "bloom" that indicates oversaturation:
Attached is a 50fps progressive version of the sample clip. It's the only way to avoid severe line twitter and aliasing with this video, other than destroying all fine detail trying to clean up bad deinterlace. 50fps for standard definition is not DVD or BluRay compliant. Some of the compression and deinterlace problems incurred during capture are still there, notably in loss of detail, color smearing, aliasing, and other factors.
Last edited by sanlyn; 05-11-2015 at 12:03 PM.
Reason: replace frame 251 "original" image with corect image
I've already responded to your original questions on VideoHelp, so I won't bother repeating those answers here.
I need to leave, so I've only read up to post #11 so far. I'll be back with more thoughts...
Quote:
Originally Posted by sanlyn
Neither capture device appears to be satisfactory. [...] Notivce the split and broken lines on diagonal edges, easiest to see along the top of the bright building but visible in other lines and in the red characters near the bottom.
Hmm, how do you expect a shaky horizontal pan across curved near-horizontal lines to look? This is an artifact of interlacing in general (later you used its name, "interlace twitter"). So it's just a source problem for these parts of the recording. The Startech capture is slightly longer than the Philips one, and at the end is a slight camera tilt up where the lines above the numbers look okay.
I shoulod also mention that the Startech capture has reversed fields: the Philips capture is top field first, the Startech is bottom field first and has the worst interlacing artifacts.
Since field order is arbitrary, you could say that the Philips capture has reversed fields compared to the other one. In what way does the Startech have worse interlacing artifacts?
The following users thank msgohan for this useful post:
jrm89 (06-01-2023)
