Inserted frames not being reported? (VirtualDub)

[lollo2]

Quote:

Lollo, could you check this please?

Quote:

It seems that the second number "(+)73" is inserted frames and the last is dropped frames.

Yes, there is a mistake in my previous post. Obviously the number close to "+" sign refers to inserted frames, while the number close to the "-" sign refers to dropped frames. Sorry for that!

Quote:

I ran a test with my other capture box, a Startech USB3HDCAP and VDub reported 2 dropped and 32 inserted. Amarec reported Zero of both, even though there were obvious freezes and jumps in the video.

Yes, I found that is more the pair capture software / capture card in cause than the software itself. In your specific case, it is also possible that the signal delivered to the capture card is freezing and jumping itself, because apparently is a not so stable tape needing a lineTBC correction (your VCR does not have lineTBC IIRC); it may have happened in a test and not in the other, i do not know.

Because you are familiar with GraphEditNext (I remember some discussion on VH forums), you could also experiment to capture the same segment with it and compare. In this case you build "your own" capture software, rather than using VirtualDub or AmarecTV, and only rely on the correctness of the report of the Microsoft filter AVI Mux, which is quite accurate.

With my Hauppauge USB Live-2 I build a graph like this when I do not display the incoming video on the PC and use a TV connect to the VCR to see the video:
capture.jpg

or like this if I only use the PC (no audio preview while capturing):

You must be logged in to view this content; either login or register for the forum. The attached screen shots, before/after images, photos and graphics are created/posted for the benefit of site members. And you are invited to join our digital media community.

- replace the Hauppauge DS Filters with the Video filters of your capture card, and eventually the rendering display art according to your PC

-configure AVI Mux for INTERLEAVE_CAPTURE https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx

- when you stop capture, do not close the GraphEditNext window, but click on properties of the AVI Mux filter to read dropped frames (the capture "software" so built is not able to insert frames, so it just drops frames (or better, AVI MUx drops frames) when the incoming flow of audio and video packets is not perfectly stable.

Just for doc purposes, these are the graphs used by VirtualDub and AmarecTV (yes, they also use a graph internally ).

VIrtualDub:
capture_display.jpg

AmarecTV:

You must be logged in to view this content; either login or register for the forum. The attached screen shots, before/after images, photos and graphics are created/posted for the benefit of site members. And you are invited to join our digital media community.

[Hushpower]

Quote:

Yes, I found that is more the pair capture software / capture card in cause than the software itself. In your specific case, it is also possible that the signal delivered to the capture card is freezing and jumping itself, because apparently is a not so stable tape needing a lineTBC correction (your VCR does not have lineTBC IIRC); it may have happened in a test and not in the other, i do not know.

Yes, it's just a cheapo VCR, but the tape is appalling. Nice and "steady" though through the ES15.

Thanks very much for the info on the graphs. I will look into that later (I only use Graphstudio these days to control the Proc Amp on my capture cards).

[hodgey]

Quote:

Originally Posted by thestarswitcher

In the PAL capture, you can see an inserted frame from #96-#97. The head switching noise at the bottom remains the same, so it's not a fault of the master dubbed to this particular cassette.

Is that JVC SVHS with TBC on? That looks a lot like the effect you get when the tbc in the JVC VCRs is acting up, which at least in my experience on PAL they are pretty prone to if there are issues in the non-visible area like dropouts or on e.g unstable camcorder recordings but YMMV. When the VCR TBC does this I've noted one tends to get inserted or weird blended frames depending in setup, and even if not there will be vertical jitter, even with my datavideo TBC. I find using a panasonic dvdr and TBC off is better in such cases but as noted even that can give drops. Haven't noticed the TBC in the Panasonic NV-HS1000 acting in this sort of way (though it can do this left-right wavy thing instead in some cases), don't know when it comes to the later panasonics - in either case the in-vcr tbcs don't work well on very bad tapes, nthg gen tapes etc.

[lollo2]

Hodgey, that behaviour is not unusual with the lineTBC of JVC VCRs. Rarely the even or the odd fields are shifted by a certain number of scanlines (I experimented 1 to 4, 5 in just few cases).

In the posted sample, for example, the frame 100 is corrupted, because the even field is shifted up 1 line by the lineTBC. It can be easily seen moving frame-by-frame in VirtualDub . It can be corrected with a simple AviSynth script:

# shift fields: shift even or odd fields by a given number of field scanlines

video_dir=".\"
video_file="PAL_InsertedFrame.avi"

video_org=AviSource(video_dir+video_file)

# separate fields tff
video_org_sep_tff=video_org.AssumeTFF().separateFields()

# separate fields tff even
video_org_sep_tff_even=video_org_sep_tff.SelectEven()

# separate fields tff odd
video_org_sep_tff_odd=video_org_sep_tff.SelectOdd()

# shift field 100 even
field100even_shifted=video_org_sep_tff_even.trim(100,100).crop(0,0,0,-1).addborders(0,1,0,0)

# repair separate fields tff even
video_org_sep_tff_even_rep=video_org_sep_tff_even.trim(0,99)++field100even_shifted++video_org_sep_tff_even.trim(101,0)

# repaired video
video_org_rep=interleave(video_org_sep_tff_even_rep,video_org_sep_tff_odd).Weave()

/*
	# display frames and display fields separately
stackhorizontal(\
subtitle(video_org_rep,"video_org_rep",size=28,align=2),\
stackvertical(\
subtitle(video_org_sep_tff_even_rep,"video_org_sep_tff_even_rep",size=28,align=2),\
subtitle(video_org_sep_tff_odd,"video_org_sep_tff_odd",size=28,align=2)\
)\
)
*/

stackhorizontal(\
subtitle(video_org,"video_org",size=28,align=2),\
subtitle(video_org_rep,"video_org_rep",size=28,align=2)\
)

#return(video_org_rep)

field_even_shift.jpg


edit: frame 2, 23, 26-30, 34 and many others are also affected

[Bogilein]

Quote:

Originally Posted by msgohan

My NTSC DMR-ES15 and DMR-ES25 always drop/insert frames internally with VHS input; a few per hour. At one point I owned two DMR-ES15s and I captured the same VCR signal from both simultaneously. They inserted frames at different spots. I also confirmed that the DMR-ES25's inserted frames appear on its DVDR disc recording, in the same spots as the passthrough output (my ES-15s have broken drives).

It doesn't happen when they're fed a signal from a DVD player.

Quote:

Originally Posted by msgohan

Correct. (Using a test tape I recorded with burned-in frame counter.)

Isn't that how dvd recorders work? They have to insert or drop frames to keep audio and video in sync no matter how bad the input signal is.

Is it possible to upload a short example of your test video with the burn in frame counter so I can create one for myself.

Quote:

Originally Posted by lollo2

Hodgey, that behaviour is not unusual with the lineTBC of JVC VCRs. Rarely the even or the odd fields are shifted by a certain number of scanlines (I experimented 1 to 4, 5 in just few cases).

edit: frame 2, 23, 26-30, 34 and many others are also affected

I also noticed the field shifts. Had the case before as well.
I would first turn off the autotracking, if that doesn't help try a Sony/Pioneer DVD recorder (Sony 680,870,205...Pioneer 630,640,560...) or best another player.

It seems that the VCR is not the right player for this cassette. That's why many have several players to choose the best one for each cassette.

There is no such thing as the perfect VCR, perfect TBC, perfect capture card, there were too many different VCRs, VHS tapes that recorded to VHS. That is why it was often recommended to use the VCR that recorded the tape. Only these devices rarely have an S-Video output, line TBC.
Whether you should follow this recommendation depends on your capture hardware and the condition of the cassette and the content. Line-TBC is not necessary if you want to use a DVD recorder as passthrough.

[lollo2]

Quote:

I also noticed the field shifts. Had the case before as well.

The field shift is not a problem at all, and can be easily fixed; few lines of an AviSynth script will rebuild the correct frame without artifacts or side effects.

The problem is that I experienced the shift happening 1 time over >10.000 frames, while in the sample of thestarswitcher it happens too often. His capture can be fixed to its original quality as well, but it requires hours or days to find and fix individual errors. BTW, I use an automatic script to find the vertical shift that was developed to recognize generic bad fields https://forum.doom9.org/showthread.php?t=183582

As you properly stated, in the case of the OP, the best will be to change player (switch to a Panasonic VCR) or to disable JVC lineTBC and use an ES-10 or ES-15 instead. I am always reticent to use my ES-15 because the loss of details in bright areas, but in the case of the OP is the only choice if he does not want to spend a lot of time in fixing his capture.

[lordsmurf]

Quote:

Originally Posted by Bogilein

Isn't that how dvd recorders work? They have to insert or drop frames to keep audio and video in sync no matter how bad the input signal is.

Yes and no. Any ingest device has to drop/insert in order to maintain the ingest rate. If something is untimed, it has to make the decision to drop/insert to maintain. The obvious fix is to time the source, though some uneducated users blame the ingest process/device. Noting that some bad devices exist, but it's more about bad drop/insert decision-making, sometimes bad external forces like drivers.

But it really has nothing to do with audio. Video is here, audio is there. They should meet, but don't have to. And that's the problem of analog ingest, of course. It is what it is.

DVD recorders can lose sync, too. It depends on how the recorder is programmed, chips used, etc. So yes, it can drop/insert, and yet maintain sync. But it's not really to maintain sync. That's a byproduct.

Remember, DVD recorders were not made to transfer tapes. These were PVR devices, record from antenna or cable. Videotape capturing was an edge case use, in terms of the overall market using DVD recorders.

Quote:

It seems that the VCR is not the right player for this cassette. That's why many have several players to choose the best one for each cassette.

Yep.

Quote:

There is no such thing as the perfect VCR, perfect TBC, perfect capture card, there were too many different VCRs, VHS tapes that recorded to VHS.

Yes and no. There is no "one VCR to rule them all", but there are VCRs that are usually best. General rules exist for a reason. JVC S-VHS decks usually best, followed by Panasonic S-VHS decks (more quirks), and then the list quickly dips off to non-recommended VCRs.

Quote:

That is why it was often recommended to use the VCR that recorded the tape.

No. This advice was based on fallacy. The "original recorder" is almost never the correct player, unless it happens to be a recommended player. Even when a tape is misaligned, you can misalign a better player to match (VHS/S-VHS only, not Video8/Hi8).

Quote:

Whether you should follow this recommendation depends on your capture hardware and the condition of the cassette and the content.

Tape condition only goes so far. Consumer format analog videotapes (VHS, etc) have intrinsic flaws of the format. So even a "good" VHS tape will have the flaws. Those flaws cause later issues at capture, and with quality in general. Those flaws need to be adjusted with TBCs, both line/field and frame.

Quote:

Line-TBC is not necessary if you want to use a DVD recorder as passthrough.

False. Line TBC is redundant with some DVD recorders. Not any random DVD recorder. You know this, I know this, but readers may not. We must choose words carefully sometimes.

[RobustReviews]

Quote:

Originally Posted by lollo2

edit: frame 2, 23, 26-30, 34 and many others are also affected

Slightly off topic, but is that Tugs? Not sure about international versions but it was a UK production (TVS, when their stock was high in the late 80s) and had an uncredited Patrick 'Voice of the Apocalypse' Allen on VO duty? It used fair chunks of the know-how and team from the original Thomas The Tank Engine series. Not thought about Tugs for years.

Mr Allen had the famous for the job of being probably the last voice Brits' would have heard should the Cold War have turned 'hot'. Like this lovely little thing about how to bury a fatally irradiated loved one in the garden.

[lollo2]

Quote:

Slightly off topic, but is that Tugs?

Better ask to thestarswitcher about his captures

[RobustReviews]

Quote:

Originally Posted by lollo2

Better ask to thestarswitcher about his captures

Ah, yeah, with a forum handle like that, it's going to be Tugs. It was the Star fleet (recourse to Wikipedia) and a switcher is a small tug aparently.

Back on topic!

[lordsmurf]

Quote:

Originally Posted by hodgey

the in-vcr tbcs don't work well on very bad tapes, nthg gen tapes etc.

Not entirely accurate. The JVC line TBC behaves differently than the Panasonic field TBC (multi-line). The advantage here is this...

Quote:

Originally Posted by lollo2

the lineTBC of JVC VCRs. ... even or the odd fields are shifted by a certain number of scanlines (

The single-frame/field line TBC doesn't have the advantage of the multi-line field TBC, which can look back and ahead. So missing, truncated, and damaged lines are simply null inserted. The JVC doesn't understand missing/incomplete/damaged lines, so you get jitter. This is a flaws of JVC, more than line itself. But it affects other line TBCs. Panasonic line TBC in ES10/15 doesn't usually suffer here.

This is usually only nth gen tapes, but not always. It's actually most common with cheaply made contact retail tapes. I've also seen it on SP VHS tapes made in cheap Panasonic VCRs.

This is a reason I got my first Panasonic AG-1980, way back when.

[lollo2]

Quote:

The single-frame/field line TBC doesn't have the advantage of the multi-line field TBC, which can look back and ahead. So missing, truncated, and damaged lines are simply null inserted.

Correct, but this is not the problem here. The whole field is shifted up, because a stability problem in the incoming signal that the lineTBC of the JVC VCR (but it also happens on lineTBC of the Camcorders) is not able to fix aligning to previous field. But, as I said, the whole integrity of the shifted field is preserved, and can be restored back.

The only case where I found a potential problem is when the shift counts 5 scanlines; you may miss then the first scanline of the rebuilt frame if the black border of the captured frame is not big enough to hide it; but that's something that is not visible if you do not slowly move frame-by-frame inside the video.

[Bogilein]

Quote:

Originally Posted by lollo2

The field shift is not a problem at all, and can be easily fixed; few lines of an AviSynth script will rebuild the correct frame without artifacts or side effects.

The problem is that I experienced the shift happening 1 time over >10.000 frames, while in the sample of thestarswitcher it happens too often. His capture can be fixed to its original quality as well, but it requires hours or days to find and fix individual errors.
.

When I look at the sample, the insertet frames are the lesser evil than the shifts. You can correct a lot of things in post-processing, including a non-constant audio delay caused by dropped frames if you invest enough time. Is that worth the effort, if by adapting the hardware to his tapes the problem can probably also be solved.

Quote:

Yes and no. There is no "one VCR to rule them all", but there are VCRs that are usually best. General rules exist for a reason. JVC S-VHS decks usually best, followed by Panasonic S-VHS decks (more quirks), and then the list quickly dips off to non-recommended VCRs.

My experience is different. I don't like the picture from the JVC players. If I were to follow your recommendations (JVC+Datavideo) I would invest a few thousand dollars/euros in hardware that doesn't match my tapes recorded on Sanyo & Siemens VCRs and that's 100+ tapes.

Quote:

Even when a tape is misaligned, you can misalign a better player to match (VHS/S-VHS only, not Video8/Hi8).

How many user would adjust the alignment of their recorder to fit a video cassette? In order to set it back correctly, you need more experience and hardware in dealing with video recorders.

Quote:

False. Line TBC is redundant with some DVD recorders. Not any random DVD recorder. You know this, I know this, but readers may not. We must choose words carefully sometimes

Well, since here in the forum only the Panasonics ES10 & 15 are recommended anyway, a video recorder with line TBC is not necessary. Because then you can not use the special capabilities of these devices.
Also one of the reasons why I don't understand the recommendation for JVC's SVHS recorders with tbc, if the users want to use an ES-10 for jitter correction. You pay for functions of a video recorder that you then do not use at all for recording.
It's not so simple. This may be for users who have no experience with other devices but if you are a little or even a little more concerned with the matter, there are alternatives to the recommendations.

I can only repeat myself, which hardware to use depends on the cassette and its contents.

[lollo2]

Quote:

Is that worth the effort, if by adapting the hardware to his tapes the problem can probably also be solved.

I do not understand your reply. Why asking that? I wrote "(changing/adding hardware) ... in the case of the OP is the only choice if he does not want to spend a lot of time in fixing his capture", so we agree there

[Bogilein]

I just wanted to confirm your statement that it is possible to correct this in post-processing but it is not worth the effort, which is what you said.
Not that anyone else comes to the thought that this is the recommended way and makes false hopes.


Bear with me lollo2, I read in English and write in German with the help of an online translator due to time constraints.

[lollo2]

No problem at all, Bogilein, there is no need to apologize. We all appreciate and understand your post even if you use online translator

[thestarswitcher]

Gonna be replying out of order;

Quote:

Originally Posted by RobustReviews

Slightly off topic, but is that Tugs?

You better believe it . I'm convinced it's one of the most beautiful pieces ever put on television, and it needs to be preserved (the film elements got accidentally junked)!! I run a page all about preserving the show, mainly highlighting behind-the-scenes materials from crew members- if you wanna check it out!

Quote:

Originally Posted by lollo2

In the posted sample, for example, the frame 100 is corrupted, because the even field is shifted up 1 line by the lineTBC. It can be easily seen moving frame-by-frame in VirtualDub . It can be corrected with a simple AviSynth script:

Really appreciate the script here! For field shifting, I use Telecide() but I'm under the impression this one is more precise, in the means of actually repairing the individual frames opposed to the whole.

As far as Tugs is concerned, I have so many different tapes loaned here from friends and collectors to combine the absolute best elements from each, to an eventual full-scale series restoration. Of course if one tape is jittery, we can rectify it by using other copies. That being said, for other videos, if this field-shift is a quick turnaround, I'm sure it would be extremely useful for my projects!

I do want a (PAL/NTSC) Panny's, but I really need to run into a tape that will truly justify the cost.