What am I missing (dropped frames)

[916Area52]

Hi All,

Technically I know from fellow travelers, that dropped frames can be undesirable in/for a capture.

What am I not seeing? I just don't see it visually in the captures (please see attached).

For this example... According to VDub2 (Shift+]) the Terminator3RiseOfTheMachines.avi capture has several dropped frames between frame 66200 (0:36:48.873)[K] to frame 75724 (0:42:06.657)[D] (there are much more than that for the entire capture). Couldn't attach the entire .avi segment at 1.85GB. so an .avi snippet is attached. The attached .mp4 is the entire segment.

Also, what does "[K]" or "[D]" refer to?

Thanks in advance,
Roy

[lollo]

You do not have dropped frames, but inserted frames.

If you cut the file you loose the timebase and the indication of their position.

The references in time you gave are wrong, read the .txt file (this has been cutted as well)

Opening the capture in VirtualDub you can see the inserted frames with the menu (unfortunately they are called "dropped" in VirtualDub)

[jagabo]

In the MP4 file there are duplicates at 304-305 and 8132-8133. I didn't see any dups in the AVI file. Found with:

LWLibavVideoSource("Terminator3RiseOfTheMachines_Vhs.mp4", cache=false, prefer_hw=2) 
WriteFileIf("Dups.txt", "YDifferenceFromPrevious<0.1", "current_frame", flush=true)

[lollo]

The OP did some weird operation.

In a capture, you have the inserted frames as indicated in the report file and can be “watched” with VurtuslDub,
AviSynth support not needed to find them in this case (but a good alternative for double check, although less accurate because the threshold can generate false positive)

I ignore what manipulations OP did to the capture.

[jagabo]

AviSynth support not needed to find them in this case (but a good alternative for double check, although less accurate because the threshold can generate false positive)

It's much easier to search for possible dups within thousands of frames with AviSynth, then verify them with Virtualdub. Which is what I did.

[lordsmurf]

AviSynth support not needed to find them in this case (but a good alternative for double check, although less accurate because the threshold can generate false positive)

It's much easier to search for possible dups within thousands of frames with AviSynth, then verify them with Virtualdub. Which is what I did.

If only we had a tool to locate time gaps, odds motions.

A lot of the "it doesn't drop frames (because my software didn't tell me)" is hogwash. If I close my eyes, you can't see me!

People tell themselves all sorts of nonsense, in an effort to avoid TBCs, because they're just being cheap. Well, it doesn't work. Nice try, but denied. Analog is analog, and it doesn't care about money (or lack of money). Analog video doesn't care about your feelings either. It is what it is.

[916Area52]

@ lollo...

"You do not have dropped frames, but inserted frames."

Dropped frames/inserted frames/duplicated frames. Personally I wouldn't know that by just viewing the capture. Have I mentioned that I don't seem to have an eye for visual critiquing, but I consider myself hyper-sensitive when it comes to a/v synch. My captures look ok, to me, no matter what the AmaRecTv logs reflect. Guess in this case, my ignorance is bliss.

Without looking under the hood and just viewing this capture, what am I looking for, or what are the tell tale signs of this capture that makes it a poor capture?


Attached is an unmolested AmaRecTv report.

"The OP did some weird operation.

In a capture, you have the inserted frames as indicated in the report file and can be “watched” with VurtuslDub,
AviSynth support not needed to find them in this case (but a good alternative for double check, although less accurate because the threshold can generate false positive)

I ignore what manipulations OP did to the capture."

I've done to the original .avi capture other than Avidemux a snippet then convert to .mp4 through Vdub2.

[916Area52]

@ jagabo...

"It's much easier to search for possible dups within thousands of frames with AviSynth, then verify them with Virtualdub. Which is what I did."

I am code challenged, so AviSynth is still in the bullpen.

[916Area52]

AviSynth support not needed to find them in this case (but a good alternative for double check, although less accurate because the threshold can generate false positive)

It's much easier to search for possible dups within thousands of frames with AviSynth, then verify them with Virtualdub. Which is what I did.

If only we had a tool to locate time gaps, odds motions.

A lot of the "it doesn't drop frames (because my software didn't tell me)" is hogwash. If I close my eyes, you can't see me!

People tell themselves all sorts of nonsense, in an effort to avoid TBCs, because they're just being cheap. Well, it doesn't work. Nice try, but denied. Analog is analog, and it doesn't care about money (or lack of money). Analog video doesn't care about your feelings either. It is what it is.

Don't know what I'm supposed take from this? "It is what it is"?

[davexnet]

There didn't seem to be any issue with your original avi, but the original mp4 you posted had two duplicates.
(as jagabo mentioned)
But the mp4 and avi were different clips, it's hard to tell why the mp4 is like that without the matching source.

To encode to mp4 in Virtualdub, perhaps use the IVTC filter to revert to the native 24 fps
and set the correct 4x3 aspect ratio

The capture quality looks pretty good to me

[poisondeathray]

Also , 8144-8145 are duplicates in the mp4

Did you verify that the AVI also had the same duplicates as the MP4? You uploaded different sections so you cannot compare directly. It's possible that the error was from the way you cut or processed the MP4 . For example the AVI is 30000/1001 fps , but the MP4 is 29970/1000 fps.

[lollo]

It's much easier to search for possible dups within thousands of frames with AviSynth, then verify them with Virtualdub. Which is what I did.

There is no need to search. Capturing with AmarecTV provides a detailed report file, where all the inserted or dropped frames are listed in time.

An inserted frame is not a real frame, it is only a few byte instruction telling to repeat the previous frame.

The VirtualDub display is used only "for fun", to "see" the inserted frame: it reads that "few bye instruction" and goes back and forward to that point in time (unfortunaly the inserted frames are named dropped frames in the menus, which add confusion).
A dropped frame is not recognized by VirtualDub, obviously.

If you need a list of fropped/insert frames for further processing, you can extract them from the AmarecTV report, without any prior AviSynth processing (that's what I do normally).

If only we had a tool to locate time gaps, odds motions.

For inserted and dropped frames happening at capture software level we do have a tool, namely AmarecTV and its reporting. It is absolutely correct in reporting, as I checked across many captures and comparison with the original programs for which I have a clear reference in therm of frame contents.

For something happening outside the influence of the capture software (in the player, or in the signal path prior to the capture card, for instance pseudo TBCs, TBCs, ProcAmps and so on, or in some circuitery of the capture card where the software has no control) this is not possible, and of course the problem can only be dropping frames.
Only a comparison with a reference or a close visual inspection frame by frame (very difficult) can determine where the drop is; however we have a synthom for that, i.e. audio/video asynch.

A lot of the "it doesn't drop frames (because my software didn't tell me)" is hogwash. If I close my eyes, you can't see me!

For what happens at capture level, AmarecTV is absolutely accurate in reporting. VirtualDub has some issues according to its parameters setting, because it was built to face different kind of problems (i.e. a/v synch across different capture cards for video and audio). Old story, verified many times.

People tell themselves all sorts of nonsense, in an effort to avoid TBCs, because they're just being cheap. Well, it doesn't work. Nice try, but denied. Analog is analog, and it doesn't care about money (or lack of money). Analog video doesn't care about your feelings either. It is what it is.

There is no non-sense in what we are discussing here, i.e. inserted and dropped frames at capture level. Moreover, no feelings brought up as an argument, just facts.
Everybody agrees on the need of a time base corrected signal for capturing (we disagree if an external TBC is always required), your repetition here is out of contest.

Did you verify that the AVI also had the same duplicates as the MP4? You uploaded different sections so you cannot compare directly. It's possible that the error was from the way you cut or processed the MP4 . For example the AVI is 30000/1001 fps , but the MP4 is 29970/1000 fps.

OP post-processed the original capture (trimming, cut, compression) and that removes all the embedded informations about the inserted frames (that famous few byte instruction) and now only an AviSynth script (see jagabo) or your analysis can find them (or a difficult visal inspection).
For this kind of analysis and consideration one must work on the raw capture.

[916Area52]

First, I'd like to thank you all that has takin the time to respond.

I am aware of, and can see that, there are inserted frames/duplicated frames for this capture by viewing the AmaRecTV report. My question was/is...

OP... Post #1,

"Technically I know from fellow travelers, that dropped frames can be undesirable in/for a capture.

What am I not seeing? I just don't see it visually in the captures (please see attached).

For this example... According to VDub2 (Shift+]) the Terminator3RiseOfTheMachines.avi capture has several dropped frames between frame 66200 (0:36:48.873)[K] to frame 75724 (0:42:06.657)[D] (there are much more than that for the entire capture). Couldn't attach the entire .avi segment at 1.85GB. so an .avi snippet is attached. The attached .mp4 is the entire segment.

Also, what does "[K]" or "[D]" refer to?"

OP... Post #7

"Dropped frames/inserted frames/duplicated frames. Personally I wouldn't know that by just viewing the capture. Have I mentioned that I don't seem to have an eye for visual critiquing, but I consider myself hyper-sensitive when it comes to a/v synch. My captures look ok, to me, no matter what the AmaRecTv logs reflect. Guess in this case, my ignorance is bliss.

Without looking under the hood and just viewing this capture, what am I looking for, or what are the tell tale signs of this capture that makes it a poor capture?"

Thanks in advance,
Roy

[aramkolt]

I have yet to try it, but the other way I think you can tell if frames were dropped or duplicated (even by a TBC which doesn't report such statistics) would be to use a timecode generator like the Horta TG50. Basically it'll burn in a unique visible timecode onto each frame and also make LTC audio. The idea is that if you were to capture both the LTC audio and timecode is burnt in right as the video exits the VCR, any devices or capture cards down the line will have missing or duplicated timecode frames. When paired with the LTC audio capture and dropping into a nonlinear timeline, the distance between the LTC audio and the burnt in timecode should be the same throughout the capture, so if you start to see the LTC audio time get ahead by more than usual, you can scroll back until you see where the audio is back in sync to identify where frame drops happened. Alternatively, you could just look at the total play time length and ignore the LTC audio to see if at any point the displayed timecode gets further ahead than the time that the file has been playing.

You obviously don't want to do real captures with the timecode burnt in, but it'd be a way to determine if your setup is prone to dropouts in general. It'd be harder to track down frame by frame if something was dropped if the capture program is appropriately inserting null frames though since then the timecode wouldn't drift over time and you'd have to directly visualize the numbers pausing or skipping on screen during playback.

[Alwyn]

Without looking under the hood and just viewing this capture, what am I looking for, or what are the tell tale signs of this capture that makes it a poor capture?"

You probably won't be able to. The experts will probably spot it; hard to tell though as the first thing anybody does when someone posts a file here is dissect it AVISynth and all it's foibles will be laid bare. But practically?

Beware the perfectionists. One duplicated frame in 30 frames per second (if you de-telecine it, 1 frame in 24 per second). Did you see it?

You've got the AmarecTV readout of where the dupes are. Open your AVI file in VDub, go to a frame that's duped, and then play that section. Do you see it? If you don't, then press on and ignore. My IR headphones occasionally hiccup when I'm using them to watch a movie. Does it annoy me enough to work out why, or spend money to fix it? Nope. You may find an occasional duped frame will be the same for you.

If you do notice it and it annoys you, then you need to get some sort of stabilisation. There are some/one here who demands a multi-thousand dollar TBC and $1000+ VCR. But normally a much cheaper option is a DVD recorder such as the Panasonic range (ES-10, ES-15 and various later models depending on whether you're in PAL or NTSC land) will in most cases do the trick.

Also, not sure I saw an answer: have you tried another tape to see if you have dupes and if so, were they as much/bad as this tape?

[916Area52]

@ Alwyn...

"You probably won't be able to. The experts will probably spot it; hard to tell though as the first thing anybody does when someone post a file here is dissect it AVISynth and all it's foibles will be laid bare. But practically?

Beware the perfectionists. One duplicated frame in 30 frames per second (if you de-telecine it, 1 frame in 24 per second). Did you see it?

You've got the AmarecTV readout of where the dupes are. Open your AVI file in VDub, go to a frame that's duped, and then play that section. Do you see it? If you don't, then press on and ignore. My IR headphones occasionally hiccup when I'm using them to watch a movie. Does it annoy me enough to work out why, or spend money to fix it? Nope. You may find an occasional duped frame will be the same for you.

If you do notice it and it annoys you, then you need to get some sort of stabilisation. There are some/one here who demands a multi-thousand dollar TBC and $1000+ VCR. But normally a much cheaper option is a DVD recorder such as the Panasonic range (ES-10, ES-15 and various later models depending on whether you're in PAL or NTSC land) will in most cases do the trick."

Thank You.

Also, I can and do appreciate the perfectionists and their insight. This sight is has a wealth of knowledgeable participants that don't mind sharing and lending a hand. Might have to call up AVISynth from the bull pen

As far as stabilization? I've been using JVC 7800s with the TBC dis-engaged. I found the TBC to be a PIA most of the time. Mostly because of tearing/noise at the top of the capture frame. Macrovision maybe, I don't know. This was before I started paying attention to AmaRecTv reports, spurred on by a error 00000087 situation/run down. I'll redo Terminator3 with the TBC engaged to see if the AmaRecTv report improves, have no doubt it will.

"Also, not sure I saw an answer: have you tried another tape to see if you have dupes and if so, were they as much/bad as this tape?"

I do, Terminator3 is a middle of the road tape when it comes to inserted/duplicated frames. A few of the tapes have +300, just chalked it up to well loved tapes .

[lollo]

As far as stabilization? I've been using JVC 7800s with the TBC dis-engaged. I found the TBC to be a PIA most of the time. Mostly because of tearing/noise at the top of the capture frame. Macrovision maybe, I don't know.

That's not normal, the TBC inside the VCR is there to clean the frame. Macrovision is another story.

This was before I started paying attention to AmaRecTv reports, spurred on by a error 00000087 situation/run down. I'll redo Terminator3 with the TBC engaged to see if the AmaRecTv report improves, have no doubt it will.

The TBC inside the VCR will not help (or only marginally) with inserted/dropped frame. If your signal is not clean you need an external TBC (as minumum but not that effective, a specific DVD Recorder in passthrough mode).

[poisondeathray]

A dropped frame looks like jump in motion. A duplicate frame looks like a slight pause or stutter (you have this in the MP4 post IVTC as well) - is that what you're asking clarification on ?

It's easy to miss problems in normal viewing (if you blink you can miss them). Easier to detect if the defect is in a section with steady movement. Some people notice these issues, some people don't, and some people don't care. If you can't see the problems, go frame by frame , and also field by field, because you also have dropped fields in the MP4

You sample is a progressive content film source that has been telecined. Field drops will break the telecine cadence, causing potential problems for inverse telecine (IVTC). Assuming the MP4 is representative of the capture (that the problems were not introduced by the manipulation afterwards to make the MP4), there are field drops. A progressive content frame, that is missing it's "partner" field will be lower in quality (since it has half the scan lines, or half the data), resulting in jaggy aliasing artifacts . Depending on the IVTC algorithm, some will post process with deinterlacing +/- other manipulations if combing is detected. Eitherway a progressive content frame that has a missing field will be about 1/2 quality because you're missing 1/2 the information - the problems might not be as visible depending on source characteristics (sometimes blurry low quality source, or lossy compression artifacts can obscure the problems) and/or post processing algorithms used can hide or reduce the artifacts.

eg. If you examine the fields, or double rate deinterlace (each field becomes a frame) , fields 340,341,342 belong to the same film frame, part of the 1st frame of the new scene as part of the normal "3" in the 3:2 cadence. However, there are 2 unique/different fields next, instead of the expected same 2 fields (the "2" in 3:2) . ie. the next field is missing it's field "partner" - that is a dropped field

If you IVTC this to return the film frames - you will see the degredation in quality of that frame compared to the frame before/after which are full frames (that have both fields). IVTCed frame numbers 136,137,138. 137 is the "bad" frame, because field 344 is missing. Here is an animated PNG , slowed down to illustrate.



Sometimes the cadence breaks are part of the source , not a capture issue (e.g. post telecine edits, this can occur with TV edited broadcasts) - That is not the case in that example, because the start 3 fields in that scene are complete. Post telecine edit problems would affect the 1st frame before or 1st frame of the scene change.




Inserted duplicates are not benign - they are usually accompanied by drops. The inserted duplicate is usually the compensatory "placeholder" for the drop, otherwise there would be AV desync. Sometimes the insert is some distance away from the actual location of the drop

Assume you only had inserted frames, but no drops. Each inserted NTSC Telecined frame would add ~33.37ms duration; each IVTCed inserted frame ~41.7ms. There would be desync unless you stretched the audio to match the duration

Whenever you have inserted duplicates in a capture scenario , also look for drops, because mathematically speaking - there has to be complimentary dropped fields or frames for each inserted field or frame in order to have AV sync

If that log file is accurate, look around those locations

[916Area52]

As far as stabilization? I've been using JVC 7800s with the TBC dis-engaged. I found the TBC to be a PIA most of the time. Mostly because of tearing/noise at the top of the capture frame. Macrovision maybe, I don't know.

That's not normal, the TBC inside the VCR is there to clean the frame. Macrovision is another story.

This was before I started paying attention to AmaRecTv reports, spurred on by a error 00000087 situation/run down. I'll redo Terminator3 with the TBC engaged to see if the AmaRecTv report improves, have no doubt it will.

The TBC inside the VCR will not help (or only marginally) with inserted/dropped frame. If your signal is not clean you need an external TBC (as minumum but not that effective, a specific DVD Recorder in passthrough mode).

This definitely concerns me, as I have a several 7800s (one from LS), all have the same characteristics. Just for kicks and grins, I did another capture of Terminator3 using the same work station and 7800 with the TBC engaged. There was no tearing/noise in the capture frame. However, the AmaRecTv report indicated three times the number of inserted/duplicated frames as the above attached AmaRecTv report, of which the TBC was dis-engaged. Will be doing a capture in the near future with a Panasonic DMR-ES15 DVD Recorder included in the work flow.

[916Area52]

A dropped frame looks like jump in motion. A duplicate frame looks like a slight pause or stutter (you have this in the MP4 post IVTC as well) - is that what you're asking clarification on ?

It's easy to miss problems in normal viewing (if you blink you can miss them). Easier to detect if the defect is in a section with steady movement. Some people notice these issues, some people don't, and some people don't care. If you can't see the problems, go frame by frame , and also field by field, because you also have dropped fields in the MP4

You sample is a progressive content film source that has been telecined. Field drops will break the telecine cadence, causing potential problems for inverse telecine (IVTC). Assuming the MP4 is representative of the capture (that the problems were not introduced by the manipulation afterwards to make the MP4), there are field drops. A progressive content frame, that is missing it's "partner" field will be lower in quality (since it has half the scan lines, or half the data), resulting in jaggy aliasing artifacts . Depending on the IVTC algorithm, some will post process with deinterlacing +/- other manipulations if combing is detected. Eitherway a progressive content frame that has a missing field will be about 1/2 quality because you're missing 1/2 the information - the problems might not be as visible depending on source characteristics (sometimes blurry low quality source, or lossy compression artifacts can obscure the problems) and/or post processing algorithms used can hide or reduce the artifacts.

eg. If you examine the fields, or double rate deinterlace (each field becomes a frame) , fields 340,341,342 belong to the same film frame, part of the 1st frame of the new scene as part of the normal "3" in the 3:2 cadence. However, there are 2 unique/different fields next, instead of the expected same 2 fields (the "2" in 3:2) . ie. the next field is missing it's field "partner" - that is a dropped field

If you IVTC this to return the film frames - you will see the degredation in quality of that frame compared to the frame before/after which are full frames (that have both fields). IVTCed frame numbers 136,137,138. 137 is the "bad" frame, because field 344 is missing. Here is an animated PNG , slowed down to illustrate.



Sometimes the cadence breaks are part of the source , not a capture issue (e.g. post telecine edits, this can occur with TV edited broadcasts) - That is not the case in that example, because the start 3 fields in that scene are complete. Post telecine edit problems would affect the 1st frame before or 1st frame of the scene change.




Inserted duplicates are not benign - they are usually accompanied by drops. The inserted duplicate is usually the compensatory "placeholder" for the drop, otherwise there would be AV desync. Sometimes the insert is some distance away from the actual location of the drop

Assume you only had inserted frames, but no drops. Each inserted NTSC Telecined frame would add ~33.37ms duration; each IVTCed inserted frame ~41.7ms. There would be desync unless you stretched the audio to match the duration

Whenever you have inserted duplicates in a capture scenario , also look for drops, because mathematically speaking - there has to be complimentary dropped fields or frames for each inserted field or frame in order to have AV sync

If that log file is accurate, look around those locations

You definitely have clarified my query. You also shared a lot of information that will take me some time to digest.

[916Area52]

Good morning,

My eyes have now been opened wide (r), and are beginning to see what had not been seen before, by me.
The last few days I’ve been doing a bit of testing… For my piece of mind mostly, such as it is, . Keeping the settings the same in AmaRecTv as the above OP. The workflow included two different JVC VCRs (HR-S7800U), I-O Data GV-USB2 and with a Panasonic DMR-ES15, w/wo as indicated.
The reports that AmaRecTv gave between the two VCRs were the same with the various settings as indicated below.

VCR w/TBC engaged, USB default, wo/Pana = (+) 118 duplicated frames (avi)
VCR w/TBC dis-engaged, stabilizer dis-engaged, USB sharp dis-engaged, w/Pana = (+) 15 duplicated frames (avi)
VCR w/TBC dis-engaged wo/stabilizer engaged, USB at default, w/Pana = (+) 10 duplicated frames (avi)

Then, all of above was then trimmed/Avidemux (ed), then, compressed/Vdub2 (ed) using the crop filter to clean up the sides and bottom of frame, along with the IVTC filter as poisondeathray kindly suggested.

The attached mp4 clip is my offering of, “VCR w/TBC dis-engaged, stabilizer dis-engaged, USB sharp dis-engaged, w/Pana = (+) 15 duplicated frames (avi)” for your critiquing and viewing pleasure/dis-pleasure, .

Side note… Must be missing something. Is there a place/site with ALL of Vdub2 filters explained? I’ve explored the “Help” drop down in Vdub2 and found this https://documentation.help/VirtualDub/video-filters.html.

Thank you All,
Roy

[poisondeathray]

"FirstNight_NoTbcNoStable_UsbNoSharp_Pana_Vhs. mp4" -

Some serious problems with frequent drops, dupes, combed frames (looks like IVTC wasn't applied correctly) , chroma issues (the 422=>420 sampling was done incorrectly similarly to the earlier example in the MP4) . Possibly some issues with capturing but definitely some post processing errors. AR needs correction as well, but you need to address the possible capture issues first, before addressing any post processing issues

If you want farther help, you need to post the original capture

[916Area52]

@ poisondeathray...

I'll most certainly take you up on the offer, thank you.

[poisondeathray]

For vdub's IVTC - don't use field mode: "single field only"; use "autodetect"

[916Area52]

@poisondeathray...

As requested

[lollo]

poisondeathray asked: "If you want farther help, you need to post the original capture", which should be a lossless video prior to any processing. Or are you applying filtering on the fly???

[916Area52]

poisondeathray asked: "If you want farther help, you need to post the original capture", which should be a lossless video prior to any processing. Or are you applying filtering on the fly???

I've only "trimmed/Avidemux (ed)", so it can be attached, no other processing has been done to the original avi capture.

[916Area52]

poisondeathray asked: "If you want farther help, you need to post the original capture", which should be a lossless video prior to any processing. Or are you applying filtering on the fly???

I've only "trimmed/Avidemux (ed)", so it can be attached, no other processing has been done to the original avi capture.

Maybe I'm not understanding? The original un-AvideMux (ed) capture is a 97GB + file. How could I make it available?

[Alwyn]

poisondeathray asked: "If you want farther help, you need to post the original capture", which should be a lossless video prior to any processing.

They have, the AVI snip is in post #23.

[poisondeathray]

Much better and about what you expect post IVTC for that capture

There is an orphaned field in the source at a scene change around 12 sec (field 731 in the source), causing vdub's IVTC to place a combed frame . Unclear if that dropped field was in the source (eg. could have been from post telecine edit), or a capture issue, because it's right at the scene change

Other housekeeping issue is to set the AR in the encode, instead of "square pixels" . The other option is to resize to a square pixel format

The capture uses lagarith, but I think the bundled one with vdub2. The bundled one is a bit buggy and returns RGB in some programs, including vdub2 itself when using the AVI driver (if you have lagarith installed). If you open the AVI directly, video => decode format it shows RGB32 (at least for me) ; or video => filters => enable checkbox on the left hand bottom "show image formats" , then add a "null transform" filter, it also shows RGB32. If you use the caching input driver, or ffmpeg input driver, it should return 422. If you use AVISource in avisynth , it also returns RGB32. There have been other issues with the bundled implementation. I would stick with official lagarith if using lagarith, or use something else like huffyuv or ut video