Which of these two different ways of capturing analogue video is best?

[Marvolo]

Download and install the huffyuv lossless codec and download Amarectv as the capture program installing that codec.

When I open AmaRecTV for the first time on WinXP, I am greeted with the following two "error messages":


[Attachment 76671 - Click to enlarge]

[Attachment 76672 - Click to enlarge]

After clicking them away, the program seems to open up, but not sure if I can just ignore these messages?

[DB83]

I would say that you can ignore them.

Taken on face value they refer to deinterlacing which you should not do at capture level and doubling frame rae which is also related to deinterlacing.


But not seen these msgs when I installed/ran the program

[Marvolo]

Something about the origin of these error messages is posted here, albeit I don't quite understand what to do. Apparently, it's got to do with geography / Europe's way of expressing decimals.

https://forum.speeddemosarchive.com/post/amarectv_colour_problem.html

[Sharc]

I think member Alwyn has written a guide how to setup AmarecTV. Search the forum.

[johnmeyer]

Never thought that capturing non-DV would be that complicated.

This is why (much to the consternation of several people in this forum) I constantly post that most people are better off capturing with DV and living with its restricted color space and DCT compression artifacts. Those are both really minor when you are feeding it video from VHS or 8mm analog tapes (which are so lousy to begin with that the DV artifacts almost get lost), but more important, the DV "capture" process is pretty much bulletproof for the simple reason that it is not a "capture" but instead is a simple file transfer of the bits from the DV tape or chip (in the case of analog passthrough). The only problem people had with DV transfers was back in the really early days (late 1990s) when the DV codec built into Windows sucked (people who used Pinnacle Studio found out about this), or when the computer didn't have DMA enabled or had too many background processes running.

Once we had Windows XP, DV became essentially bulletproof.

[lollo]

capturing with DV and living with its restricted color space and DCT compression artifacts.

Which are almost invisible in this use case looking to the 2 captures, I agree with you and poisondeathray.

[Marvolo]

Alas,
one last attempt, this time using AmaRecTV. It mentioned 0 drops during capturing, also the text file mentioned 0 drops.
Captured right into HuffYuf.

As usual, please compare the two files with regard to picture (noise, artefacts, colours, details, brightness, sharpness etc).
One is the 2008 DV capture, the other I just captured myself like I mentioned above. If there are drops / errors / faults again, then I really don't know what else to do.

[oln]

[tangent]

Something about the origin of these error messages is posted here, albeit I don't quite understand what to do. Apparently, it's got to do with geography / Europe's way of expressing decimals.

https://forum.speeddemosarchive.com/post/amarectv_colour_problem.html

Ah that explains why I also get these errors. Many European countries use "," as a decimal point instead of "." , and some text/number conversion functionality, like some functions in the C and C++ programming languages take the system locale settings into account which people often are not aware of so they end up being used in a way they shouldn't be.

So e.g the program will correctly interpret e.g "2.2" from a text file on a English-language system but on say a system set to use Norwegian locale the it expects a decimal number to be formatted as "2,2" instead and the code to read the text file into numbers in the program fails in a way the developer would not have expected.

Since the developer wasn't aware this behaviour it you end up with the program randomly failing on some people's systems. (I don't know if this specific failure was because of the C/C++ function as I think in that case it only happens on Linux and Macos and not on windows but not sure.)

[/tangent]

[Marvolo]

[tangent]

So e.g the program will correctly interpret e.g "2.2" from a text file on a English-language system but on say a system set to use Norwegian locale the it expects a decimal number to be formatted as "2,2" instead and the code to read the text file into numbers in the program fails in a way the developer would not have expected.

In Germany, we use the comma-system as well for decimals, probably that's why I'm getting the error messages. No idea how to fix this in the program though. It seemed to have captured nevertheless.

[lollo]

Alas,
one last attempt, this time using AmaRecTV. It mentioned 0 drops during capturing, also the text file mentioned 0 drops.
Captured right into HuffYuf.

Now the DV and the HufYUV captured are aligned, same number of frames (after trimming the DV to remove the first 26).

Frame number 74 is corrupted, and many present the "noisy white lines" pattern:



Looking the fine details the lossless (HuffYUV) this time is slightly slightly more defined (objects in the sand) but they are quite close:



with image slider: https://imgsli.com/MjM3MDg1

I think you found your way! (but we told you since the beginning: 4:2:2 YUV interlaced lossless 8-bit AmarecTV)

[Marvolo]

with image slider: https://imgsli.com/MjM3MDg1

I think you found your way! (but we told you since the beginning: 4:2:2 YUV interlaced lossless 8-bit AmarecTV)

Hallelujah!! Quite a relief.

That image slider option is awesome for comparison. I seem to be noticing that the HuffYUV image is a tad more colorful than DV? Especially the sand appears more yellow than DV. Is anybody else seeing this?

So no drops, no faulty frames? If so, then I might take on the task of re-capturing all those tapes. Not in order to delete the DV ones, but simply to have another (more pristine) backup and a backup to work with in order to do restauration and enhancement tasks.

I do hope that my camcorder will live through the task of playing back those 15 tapes. What I DID notice during capture is that sometimes white sparks that last only one or two frames appear in the image that aren't there in the DV capture.

I really hope that's not an early sign of the video heads dying. I clean them with leather stripes and cleaning-spray after every capture. Very carefully with little pressure, of course.

[lollo]

That image slider option is awesome for comparison.

keep in mind that the site add compression, so the source images are better.

Not in order to delete the DV ones, but simply to have another (more pristine) backup and a backup to work with in order to do restauration and enhancement tasks.

I agree.

I really hope that's not an early sign of the video heads dying. I clean them with leather stripes and cleaning-spray after every capture. Very carefully with little pressure, of course.

Do not know what to say. Eventually you can use an AviSynth script to detect the bad frames and replace it with an interpolated one. An example here:

[Marvolo]

I have yet a long way to go with regard to knowing and being able to handle AviSynth. Have never used it before. I was going to photoshop faulty frames or even replace them with the respective ones from the DV source. I mean, it would only be a frame or two. Probably no-one would notice if it was copied from the DV source. (I know that in this case, both sources were faulty, DV as well).

But seeing what Avisynth can do (especially getting rid of those horizontal lines), it's probably worth delving into the matter.

[lollo]

Well, AviSynth is not doing magic, just creating a non-existing frame by interpolation of previous and next and replacing it to the faulty one.
The failure is on the DV capture also (a gltch in the tape) and you can't use it as replacement.
Photoshop is a good complement to AviSynth for defects not easily fixable

[Bogilein]

Now the DV and the HufYUV captured are aligned, same number of frames (after trimming the DV to remove the first 26).

Frame number 74 is corrupted, and many present the "noisy white lines" pattern:

I did the same as Lollo, aligned the two files and then compared the two files using the difference filter.

Do you see a difference between the two files yourself?

(Frame50,74..........)

or are you relying on the experts? I don't see any magic in Amarec TV capture compared to Virtual Dub Capture.

Perhaps use a different player, external "TBC" or capture card.

[Marvolo]

Do you see a difference between the two files yourself?

The difference I see is that the colours are a bit more stronger in my capture compared to the 2008 DV capture.

[johnmeyer]

The difference I see is that the colours are a bit more stronger in my capture compared to the 2008 DV capture.

The color difference means nothing: it can easily be corrected in post. There is, however, a significant differences in midtone levels which you will see if you zoom in and then move the slider between the elbow and the kid's face. I am not sure which is correct or which is "better," but they most definitely are different. It is the only difference in that one sample that is worth talking about.

Again, you are not getting any big "Wow!" factor with your more complicated captures. If you could show any sort of detail that wasn't there before, or a major reduction in artifacts, or something similar, I would be jumping up and down encouraging you to go through the agony and effort of recapturing all your tapes.

[Marvolo]

It's not at all an agony and effort for me. Now that everything is set up properly, it's merley playing back those tapes and hitting record on the computer.

If, as you say, there's a "significant difference in midtone levels" then that's enough for me to create a more pristine backup by re-capturing them all. That, and the fact that the new capture won't come with DV compression/artefacts, as small and barely noticible they may be.

[lollo]

Bogilein,

Marvolo called Seq1_amarec what in fact is the DV capture not the Vdub2 capture. Seq1_amarec (DV) and Seq2_amarec (HuffYUV), differ but really on a fixed frame analysis or on a metric measument:



In term of "quality" of the capture, there is no difference if you use AmarecTV or VDub2 or VirtualVCR or a customized Graph, all rest being equal. But, apparently, Marvolo had dropped frames with the second and not the first, which is something else. HOwever is difficult to generalize judging oly two short sequences.

Overall, as johnmeyer properly said, only a real quality-obsessed user would recapture the tapes (I am one of them, especially if a post-processing is planned, but that does not matter)

edit: the difference at frames 50, 84, 184 between DV and lossless is because the lossless capture has a shift of the even and the odd fields, not present in DV capture. Even this defect can be fixed with a simple AviSynth script:


[Attachment 76701 - Click to enlarge]

[themaster1]

4.2.2 vs 4.2.0 (assuming Pal) that's what,s happening full chroma pixels Versus shared chroma pixels. And for the purists an 4.4.4 upscale will make a bigger difference once again. (See avisynth plugins). If you're archiving maybe it's worth the try. The key thing about captring / making a master copy is to make it as pristine as possible for later exploitation. My point being do it right the first time.

[Sharc]

To add my 2 cents to the nitpicking:
The huffy variant is slightly brighter (midtones) and clips the brights at about Y=245, whereas the DV goes up to Y=255.
So both violate the 16 ....235 luma range. Not critcal though because it's not severe and partially just caused by noise and artifacts. Just keep in mind that after conversion to full range 8 bit RGB (for viewing) the out-of-bound luma and clipping may result in loss of details in the brights and slight color distortions.

[johnmeyer]

Here's one more thing to think about.

I mentioned this in passing but it bears repeating: how many people will watch these tapes and, as a corollary, how many people will watch all of the tapes, and how many will watch them more than once?

Starting in the late 1990s, I spent countless (several thousand) hours transferring, scanning, archiving, and improving my own movie films, still photos, audio recordings and videotapes.

If I knew then what I know now would I have spent that time obsessing about every last artifact?

Absolutely not.

My children and relatives will likely throw everything out when I'm gone in a few years and never watch any of it (or at most will watch a few minutes from each movie or tape). Also, even I haven't watch most of the media all the way through.

What has been useful is to have the material available when I need to furnish someone a short clip, pull out a photo from the 30,000 family photos, or provide an audio clip. Therefore, the work that I did organizing, identifying, and editing this material was worth 100 times the work I did obsessing over minor, barely observable defects in the capture, scan, or transfer.

Spend your time on that organization and editing, not on nitpicking defects that will last 1/50 of a second and then be gone.

There is one exception. Nine years ago Sony Pictures wanted to use some of my film clips under the opening credits for the Will Smith movie "Concussion." Referring to what I said above, I realized that these would be seen by millions of people, and many would view them more than once. The director wanted several 4-5 second clips, and I spent several days restoring those frame-by-frame. I then reassembled them into a ProRes file before sending them off to their post house.

So, in that case, getting every pixel in the right place was worth it.

[Marvolo]

There is one exception. Nine years ago Sony Pictures wanted to use some of my film clips under the opening credits for the Will Smith movie "Concussion." Referring to what I said above, I realized that these would be seen by millions of people, and many would view them more than once. The director wanted several 4-5 second clips, and I spent several days restoring those frame-by-frame. I then reassembled them into a ProRes file before sending them off to their post house.

So, in that case, getting every pixel in the right place was worth it.

This sounds interesting. What kind of clips were they and how come Sony Pictures knew of them / wanted them? Did you film professionally and made it accessible to the public?

[Sharc]

Here's one more thing to think about.

I mentioned this in passing but it bears repeating: how many people will watch these tapes and, as a corollary, how many people will watch all of the tapes, and how many will watch them more than once?

Starting in the late 1990s, I spent countless (several thousand) hours transferring, scanning, archiving, and improving my own movie films, still photos, audio recordings and videotapes.

If I knew then what I know now would I have spent that time obsessing about every last artifact?

Absolutely not.

My children and relatives will likely throw everything out when I'm gone in a few years and never watch any of it (or at most will watch a few minutes from each movie or tape). Also, even I haven't watch most of the media all the way through.

John,
I widely agree with what you wrote about the value of technical perfection of tons of digital heritage of family memories.
But as the OP wanted to strive for the "better" I added my comparison in post#51 with a grain of salt as another discouragement against routinely re-capturing his stuff, possibly just trading in the faint DCT artifacts of his existing DV to slightly crushed superbrights and superblacks. Or just be aware of it.

[Marvolo]

The huffy variant is slightly brighter (midtones) and clips the brights at about Y=245, whereas the DV goes up to Y=255.
So both violate the 16 ....235 luma range.

So both the DV as well as my own capture have this "flaw"? And there's no way to correct this after capture during post? The only way would be to adjust brightness levels DURING capturing, right?

[Sharc]

The huffy variant is slightly brighter (midtones) and clips the brights at about Y=245, whereas the DV goes up to Y=255.
So both violate the 16 ....235 luma range.

So both the DV as well as my own capture have this "flaw"? And there's no way to correct this after capture during post? The only way would be to adjust brightness levels DURING capturing, right?

Putting it simple:
- You can always make adjustments in post, as long as you stay within 16....235 for the luma (8 bit YUV color space, limited aka TV range). Rule of thumb for a safe harbour.
- You can also bring superwhites (Y>235) and superblacks (Y<16) back into the 16...235 range by tweaking the levels (e.g. by fiddling with "brightness" and "contrast"). Occasional superwhites and superblacks in captures are ok as long as they are not badly clipped.
- You can not recover anything from clipped signals. What is lost is lost. Shifting clipped luma up or down does not bring any data (details) back. Basically, one should avoid clipping at capture time by using an appropriate setup.

Here an excellent tutorial by jagabo:
https://forum.videohelp.com/threads/340804-colorspace-conversation-elaboration#post2121505

[lollo]

So both the DV as well as my own capture have this "flaw"? And there's no way to correct this after capture during post? The only way would be to adjust brightness levels DURING capturing, right?

As complement to what Sharc explained:

Always capture to stay inside the range allowed by your capture card (4-250, 16-252, XX-YYY, whatever), to avoid to crush/clip the levels. User here the procamp of your card.

In post processing, if needed because the usage of a filter working in RGB color space, shrink the levels of the capture to 16-235, to avoid illegals (thus removed) RGB levels. No need if you stay in YUV colorspace.

For dispaly purposes (i.e. TV versus PC), you may also need to shrink the levels to 16-235, to avoid illegals (thus removed) RGB levels.

[Marvolo]

User here the procamp of your card.

I've looked, but haven't so far found any settings for the Blackmagic Intensity Pro card where I could adjust brightness / contrast and such during capture. Even with Blackmagic's own Media Express capturing software the settings are pretty limited. Seems to be merely for capturing and that's it.

Is it maybe because I'm feeding a HDMI stream right into the BM capture card? I've found video levels for "analog video-in" and "video-out", but they're both greyed out, probably because I'm not using analog video in and out on the card, but HDMI-in, coming right from the Panasonic player.

[lollo]

Yes, no control then, the "digitizer" is the Panasonic. Some "HDMI stream right into the BM capture card" user may chime in to support you...

[Marvolo]

Yes, no control then. Some "HDMI stream right into the BM capture card" user may chime in to support you...

That would either be @Bogilein or @Skiller as they're the authors of this capture method.