The old "war of opinion" - Capture 8mm tapes in DV or lossless?

[lollo]

@Marvolo,

I have captured hundred of tapes with a lossless HuffYUV approach under Windows 10 and with a medium-end laptop without dropping a single frame. I capture on a single SSD not even configured in "System" and "Capture" partitions.

Just be sure to disable all useless services, disable internet, antivirus, indexing, caching of I/O data, etc... and leave your PC quite. I do not even touch the mouse while capturing.

The few dropped frames I experienced were because a problem on the tape (they appear at the exact moment across multiple captures). It is not your case because the DV capture is ok. The disk bandwidth required by your uncompressed flow is high, but you should be able to substain it with adequate hardware and system optimization.

The OS is not the root cause, because the hardware is more performant nowdays than the what we had at Windows XP time.

All this to say that with modern hardware and OS you can have 0 dropped frames with your uncompressed HDMI approach as you have with the DV route (which just requires less bandwidth, but it is the same continous flow of data that must be written on the disk without interruption, so special care is needed to optimize it).

[Bwaak]

Is there a software or anything that can detect lost frames? So I could maybe feed in the DV file as reference and the software compares it with the lossless capture?

I've written such scripts, but a far better programmer, StainleSS, has written something called DropDeadGorgeous (he has a sense of humor):

Duplicity2/DropDeadGorgeous v2.13 - Dupe Tool - 17 Nov 2018

There is a lot of stuff written there, so before diving in, a quick question: often the dups are not dups, but a couple of there-back, there-back frames, which is an order of magnitude more annoying than just a dup. I don't think his script is smart enough to detect the direction?

[Sharc]

One may also try field matching, something like

AVISource("YUF-Sample_2.avi").trim(0,60)
clip=last.convertbits(8).converttoYV12(interlaced=true).assumeTFF()
matched=clip.TFM(mode=1,pp=0).subtitle("MATCHED",size=36,align=5)
return stackhorizontal(clip,matched)

[johnmeyer]

There is a lot of stuff written there, so before diving in, a quick question: often the dups are not dups, but a couple of there-back, there-back frames, which is an order of magnitude more annoying than just a dup. I don't think his script is smart enough to detect the direction?

I am not sure what you mean by "there-back" frames, but if you are talking about a frame where the motion goes backwards for one frame, that is a totally and completely different problem than drops and duplicates.

If you are instead talking about whether the dups happen after the drop (the usual case) or before the drop, I think those should be handled by his script. In most situations the drop happens first and then the capture or streaming software adds the duplicate a few frames later in order keep the audio in sync.

The scripts I wrote made no assumption about whether the dup or drop came first, and also no assumption about how many normal frames happened between the two related anomalies. However, I did not spend as much time as did StainlesSS perfecting my script so I assumed his might work better (I've never actually used his, however).

[Cornucopia]

Sounds to me like the OP used improper tools for ripping & decoding of DVDs, BDs with Bframes (whose PTS -presentation timestamp -can be different from their DTS -decoding timestamp).


Scott

[Marvolo]

Sounds to me like the OP used improper tools for ripping & decoding of DVDs, BDs with Bframes (whose PTS -presentation timestamp -can be different from their DTS -decoding timestamp).


Scott

He used VirtualDub using the Direct Stream Copy method for the most recent samples uploaded here - just as has been suggested to him by a couple posts.

@Sharc
Does this code you provided compare two samples (say, the DV sample and the lossless sample) and then checks if the number of frames in both samples are identical? Maybe that's just what I'd need.

@all
I deleted / formatted my system drive disc and reinstalled Win10. This time, I only installed the necessary drivers for the hardware and the Blackmagic Capture card. Nothing more. No additional drivers, no software other than the Blackmagic one and I kept it from going online so that it won't download and install stuff in the background via Windows Update.

I then captured a tape again, hoping this time it won't have created missing frames. I'd still need a reliable way to check for that though. Surely, I can't go through a 90 mins capture and compare every single frame manually by comparing it to the DV reference.

Then again, if there was a way to directly capture in Huffyuf or Lagarith instead of uncompressed like I have to do at the moment, maybe this would also help in preventing missing frames. However, I still haven't found out why VirtuaDub won't recognize my BM card. It just keeps showing a black screen with the BM WDM driver selected.

[Sharc]

@Sharc
Does this code you provided compare two samples (say, the DV sample and the lossless sample) and then checks if the number of frames in both samples are identical? Maybe that's just what I'd need.

It's a side-by-side comparison. On the left is your interlaced file 'YUF-Sample_2.avi' which you uploaded earlier (post#160). It has hickups early at the beginning. See around frames 3.....7 when you step through the frames (or fields).
On the right I applied TFM() for fileldmatching. It re-groups pairs of fields which belong together to constitute a frame. Usually this function is used as a part of of IVTC (inverse telecine) package, or to fix field-shifted progressive video. It is described here: http://avisynth.nl/index.php/TIVTC
Step through the frames to see its effect on frame 4 and 5. I didn't analyze the glitches in your file in detail, I just threw TFM() on it.
Anyway, forget it, it's not a method to discover dropped/repeated frames, and rather than trying to fix something it is definitely better to avoid glitches and drops/inserts right from the beginning, i.e. during capturing.

[DB83]

Take a look at this topic:

https://forum.videohelp.com/threads/402135-virtualdub-and-BM-intensity-pro-4k

[Alwyn]

However, I still haven't found out why VirtuaDub won't recognize my BM card. It just keeps showing a black screen with the BM WDM driver selected.

TLDR; try AmarecTV; I have a guide on my website.

[Marvolo]

https://forum.videohelp.com/threads/402135-virtualdub-and-BM-intensity-pro-4k

@dellsam34 wrote in that thread - a little ironical to a certain degree, given my present situation :

Try BlackMagic Media Express app, it should work perfectly with your card. It's lightweight it doesn't take CPU resources like vdub does, You can capture with audio preview with no problem.

[DB83]

Well I only mention the thread in the context of the reply from jwillis84 >> I thought you mentioned there is also a 'Decklink' selection.

Then he mentions a 'Control Panel applet'.


Now I previously stated that vdub expects an analogue source. Not strictly true since vdub is capable of 'capturing' a DV source.


I believe jwillis84 is still an active member (last seen some 3 weeks ago). Maybe worth looking him up - send a PM etc.

[Marvolo]

Regarding the detection of dropped frames:

I may have found an easy way but maybe I'm wrong:

In VirtualDub I loaded the DV reference file, chose a scene with the in and out marker (arrow left and right) just like I would do when direct stream copying it, and then VirtualDub shows me the beginning frame and the end frame of the marked (in blue) area.

I then just substracted the beginning frame from the end frame and thus got the total number of frames of a certain scene from beginning to end.

Then I loaded the uncompressed file, chose the same scene with exactly the same in and out markers and substracted them from each other. If then the total amount of frames is identical with the DV reference file, I assumed that no frames were lost in the uncompressed file.

Most of my scenes were identical according to this route. 2 scenes, however, were short of 2 frames in the uncompressed file.

I did it scene-wise and not for the entire tape / capturing file at once. Because I want to export it scene-wise anyways not as a whole. For example: Christmas as a scene, Easter as a scene, birthdays as a scene and so on.

Is this a reliable way to detect missing frames?

[poisondeathray]

Is this a reliable way to detect missing frames?

Maybe; it depends on what else is going on. A dropped field can have an inserted "placeholder" duplicate field later - the field count (and thus framecount) is the same for that scene if you're just counting total fields . Theoretically, you could still have drops in those scenes you thought were "good". You're also making the assumption that DV is perfect (it's probably a decent assumption, but ...something about Murphy's Law)


There are avs scripts that can compare videos (a,b) and print to a text file the frame number (field number if working in fields) if it differs by a certain threshold. This will only show you the initial "bump", because all the fields after the dropped frame will no longer be aligned. Other methods are PNSR plots (same thing, it will drop after each bump, but you're looking for a large drop)

Potential issues - there are differences between the 2 already - DV noise, saturation, field order (the same set of scan lines is going to be shifted by 1, spatial misalignment), cropping/borders (right side). The closer you can maniplulate the 2 videos to begin with, the fewer false positive detections will be flagged, and the more accurate the analysis

In a NLE, you can do what you were already doing, align them at the start, but make sure you are working in fields, or deinterlaced to 50p timeline (so you can see the fields interpolated to frames) . Set the transfer mode to "difference" or "subtract" or similar. It should be "black" where frames match, the 1st glitch should pop out showing larger differences. But it's the same issue - after the 1st "bump", all the other fields should show larger differences (assuming there is motion), because they are no longer aligned temporally, the more drops you have, the more offset, the more differences.



Single video analysis isn't necessarily great either; they usually work by detecting large jumps (corresponding to the inserted field from a previous time; reverse motion), and/or duplicates. One benefit is you no longer factor in the innate differences between 2 videos (dv compression, alignment, saturation etc...)

But you can have "normal" duplicates during low motion scenes, and you can have large jumps for other reasons (shaky hands, whip pan, etc..). Large potential for false positives

[johnmeyer]

I then just substracted the beginning frame from the end frame and thus got the total number of frames of a certain scene from beginning to end.

Poisondeathray correctly points out that this will not work because all capture and streaming systems insert a duplicate every time there is a drop in order to keep the audio in sync. You have never mentioned audio sync problems so it is clear that your capture system is doing exactly this.

Is this a reliable way to detect missing frames?

I already pointed you to a script. It doesn't sound like you have used it. As an alternative, you'll find one of my scripts in the first post in this thread I started several years ago: Need help "perfecting" script to delete drops and dups

My drop detection (which is what you are asking for) actually works quite well. The problem I had in "perfecting" the script was to match the drops and the dups. The problem is that the capture system doesn't add the duplicate at a fixed number of frames after the drop. A similar problem is that the algorithm has to look at groups of frames (i.e., it cannot look at all frames in a two hour capture and then analyze that massive data set), and if the drop/dup pair happens at the boundary between one group and the next, the algorithm has a tough time with that.

It still works pretty well, and will make your video look a lot better, but it won't be perfect. I think one of my ideas was to run it twice, using two different Cycles (the size of the group).

[Marvolo]

Thanks John! Much appreciated.

Having never worked with script / code / Avisynth before, however, I'll need some time delving into all of this. I have only ever worked with fully graphical software before, such as NLEs or AfterEffects for VFX.

Maybe for the time being and for simplicity, I'll probably do it the old-fashioned way, that is, aligning the DV file and the uncompressed capture file in my NLE and see if and where they drift apart.

Suprisinlgy and interestingly, DV files, no matter how many times I re-capture them with different cams, never drift apart from the original 2008 DV reference files. It almost feels like capturing actual DV tapes. You should think that using different cams and such, the analogue tapes might not be completely identical after each playback. Especially if 15 years between the first capture have gone by.

[johnmeyer]

Suprisinlgy and interestingly, DV files, no matter how many times I re-capture them with different cams, never drift apart from the original 2008 DV reference files. It almost feels like capturing actual DV tapes. You should think that using different cams and such, the analogue tapes might not be completely identical after each playback. Especially if 15 years between the first capture have gone by.

I wish I could quote that in all the discussions where people denigrate DV captures. I always talk about the difficulty many (not all) people have with capture chains that should provide a little better quality, only to find problems with levels, color shifts and, as you are finding out, dropped frames.

This thread is long, so if you can point me to the longest lossless (i.e., non-DV) capture you have posted, I'll run my script on it and see what happens. That way you can see if it is worth taking the time to get AVISynth running. Even though I have a programming background, I too was intimidated by installing and learning AVISynth many years ago. Having gone through that, the toughest part is figuring out which version to install, because there are so many variants. I think AVISynth+ is the one you should use. You then start with a one-line script that simply opens the file, and then open that script (it is just a text file you create in Notepad and save with the extension .AVS instead of .TXT) in VirtualDub. If you see your video, you've got it installed.

The next hurdle is making sure you have the right filters installed. This is where it gets tricky because not all scripts (mine included) document the entire list of filters you need. However, you can usually work through that in 10-15 minutes because when you try to use someone else's script, AVISynth will throw an error message saying "missing XYZ DLL." You download that, repeat, and eventually will not get an error message.

[Sharc]

@Marvolo
Next question is: What are you going to to when you (or your tool) discover one or several dropped/inserted frames in your lossless captures?
- Re-capture again (increasing the wear of the tape, revisiting your capture setup etc.) in the hope that it doesn't happen again? Possibly finding a new glitch along the timeline?
- Trying to fix the capture by replacing the drops/duplicates with interpolated frames? (quite laborious!)
- Decide to carry on with the robust DV method (quality is pretty good for PAL as you have noticed) and concentrate on other "quality" issues which matter a well?
- ......

(And how do you know that the 2008 DV variant is a valid and flawless reference to which you should compare?)

[lordsmurf]

Next question is: What are you going to to when you (or your tool) discover one or several dropped/inserted frames in your lossless captures?
- Re-capture again (increasing the wear of the tape, revisiting your capture setup etc.) in the hope that it doesn't happen again?

This is what should be done. However...

Possibly finding a new glitch along the timeline?

Only recapture segments needed. You should never capture fully unattended, and should have some idea of where the drop happened. Then merge captures. That would prevent "new" issues (rarer anyway), and not harm the tape more than is needed. Noting that everything tends to harm tapes, sometimes you run into one-and-done tapes (no re-capture possible), therefore should strive to do it properly the first time.

- Decide to carry on with the robust DV method

I would never call it "robust", as it's not. It has farts that stink, too!

The mainboard is from 2009 and it was one of the last boards that still got XP drivers.

There are Gigabyte boards from 2017 that have XP drivers.

Dropped frames is why I always recommend DV.

Better is to resolve the reason for dropped frames. Because DV can, and does, drop as well.

As capture guy, I swear only on original huffyuv 2.1.1; no MT patch, no CCE patch.

MT is bad.
I don't see a difference between CCE patched and non. So, for that reason, I want the original. Which reminds me, I need to contact that installer, and get him to also create a package with the original version.

[Marvolo]

@John

Thanks for the offer. I will try and find a longer sequence of lossless capture for you to analyze. Will get back to this later.

@Shark
Very true and justified questions. Believing that dropped frames are the result of a bottleneck in the system, I have already set up the boot up drive anew. I have several HDD drives and one of them is only for booting / system drive, which means I can easily install a fresh Windows version without losing personal data, which I keep on the other drives.

Even though my system is from 2009, I believe it might still be strong enough for analogue capture. I mean, people used to capture analogue video well before 2009. And my system was one of the most sophisticated at the time. Intel i7 quadcore CPU, 3,0 Ghz, 12 GB RAM, Gigabyte GA-EX58-UD5 mainboard.

But yeah, maybe re-capturing with an even faster system might help? But then again, you're right: I already begin to worry about wearing the tapes down by playing them repeatedly.

Keep in mind that I had played them all just for re-capturing them in DV. That was before I bought the set-up for analogue / lossless capture. So they have all been through one cycle of capturing already.

How do I know if the 2008-DV files are flawless? Good question. Since some tapes don't play well with my cams but in the 2008 capture they all play perfectly well, I believe that the guy doing the captures in 2008 must have done it professionally, or in other words: they knew what they were doing. Even if it was "only" a DV capture. Some of my tapes show clear signs of misalignment issues - meaning they won't play well in "foreign" cams and only play well in the very cam they were recorded in. That cam no longer exists though.

I don't know what they did in 2008 or what tools they had at hand, but they managed to play the faulty tapes, that other companies and capture-services couldn't play and they eventually referred us to go to that "professional" who specialized (among other things) in misalignment problems.

In the German forum, there once was the claim that misalignment problems aren't a thing for video8 / 8mm tapes, rather for VHS. But here is a video of a British guy explaining how you can tweak / adjust your playback heads with a screwdriver to meet the misaligned tapes. I'd never dare do that to my cams though.

[lollo]

I wish I could quote that in all the discussions where people denigrate DV captures. I always talk about the difficulty many (not all) people have with capture chains that should provide a little better quality, only to find problems with levels, color shifts and, as you are finding out, dropped frames.

And you should not. The lossless approach is somehow more difficult to implement, but it is not significantly worse than DV for dropped frames. Sure, 25mbps DV is lower bandiwdth than uncompressed/lossless, but modern hardware and system optimization substain that high rate for sure.

And, once more, we are discussing about uncompressed HDMI capture, the classic lossless flow concerns a lossless codec, which redeuces the bandwidth and use more the CPU for coding operation.

I experienced more dropped frames while transferring a mini DV tape via firewire with Scenalyzer (not an analog conversion) than with a lossless analog capturing. Concerning the Analog capture via DV route, with my old Canon I did not experienced dropped frames in my experiments (as the OP), but that was 15 years ago, and I never joined this workflow.

all capture and streaming systems insert a duplicate every time there is a drop in order to keep the audio in sync.

This is not true. Have you ever captured with the lossless approach? I suspect not.
You may have dopped frames without an inserted frame later. The capture software behaves inserting a duplicate of the previous frames to keep a/v synch, or if a frame does not arrives in time. But it can also drop a frame and do nothing more.

There is no need to have a special AviSynth script to detect an inserted frames in the lossless approach, because capturing with AmarecTV or VirtualDub, the inserted frame is just a repetition of the previous frames and as such is indicated in the data stream, so it is easy to detect it. Just reload in VirtualDub the captured file (with AmarecTV or VirtualDub itself) and you can jump to the inserted frame with a command in the menu.

The dropped frames are also reported by the capture software in the log file (AmarecTV) or while capturing (VirtualDub). They can be easily found and identified during capturing, but not at a second analysis like for inserted frames, unfortunately.

For many of my analog captures, I have a dvb-s dump of the same program, so I can compare frame-by-frame, field-by-field and check the field/frame architecture.

Unfortunately OP is using BM software, so many of these options are not accessible.

[Marvolo]

@John

How long does the sample have to be for you to run your frame-drop-detection tool?

[johnmeyer]

If a capture system drops a frame and doesn't eventually insert a duplicate frame, the audio will get out of sync. That didn't happen with the OP's video, so it clearly has dups=drops.

As for what the OP should do, the only thing I would recommend he not do is recapture. That will be a nightmare. How do you decide how to splice those two captures together?? You'll still need some tool to find the drops AND the dups.

No, you've got to fix the capture so you don't get drops, fix the result with my script (which synthesizes a frame where there is a drop, and deletes the nearby dup), or live with the 2008 captures which, I think, the OP said are just fine. Get on with life and do something else! Capturing again in 2023 with DV will probably just give you pretty close to the same thing you already have.

Having said that, not all DV A/D converters are the same. There is a difference not only in the A/D converter, but also in the actual DCT compression. For software DV codecs, for instance, it was well known that the DV codec built into Windows was absolutely awful, whereas professional DV codecs, like the one sold by the Germain company Mainconcept, were exceptionally good. I've often suspected that those who dump on DV never used the Mainconcept, Canoupus, or Sonic Foundry DV codecs. Yes, they all used DCT compression so they are all going to be subject to macroblocks, but there was a huge difference in how they processed the A/D incoming data.

[lollo]

For software DV codecs, for instance, it was well known that the DV codec built into Windows was absolutely awful, whereas professional DV codecs, like the one sold by the Germain company Mainconcept, were exceptionally good. I've often suspected that those who dump on DV never used the Mainconcept, Canoupus, or Sonic Foundry DV codecs.

Contradictory statement, John. While capturing you have no access to the DV codec, because it is implemented in the device. On reading, or decoding for further processing, and eventually encode back to DV, I also experiemented all available DV codecs available at that time. And found Canopus and Sony to be the best, not Mainconcept (personal opinion). But this has no relation to the original question: better DV or lossless approach?

[Sharc]

There is no need to have a special AviSynth script to detect an inserted frames in the lossless approach, because capturing with AmarecTV or VirtualDub, the inserted frame is just a repetition of the previous frames and as such is indicated in the data stream, so it is easy to detect it. Just reload in VirtualDub the captured file (with AmarecTV or VirtualDub itself) and you can jump to the inserted frame with a command in the menu.

The dropped frames are also reported by the capture software in the log file (AmarecTV) or while capturing (VirtualDub). They can be easily found and identified during capturing, but not at a second analysis like for inserted frames, unfortunately.

Yes, unfortunately the capture SW detects only the drops which are caused by the process during capturing which is under control of the capture SW (like AmarecTV or Vdub etc). It does not report drops or inserts of frames which were not properly served, means the capture SW did never "see", like drops/repetitions which have their origin in the external ADC or passthrough device (TBC, DVD recorder). Hence neither AmarecTV nor Vdub meet the OP's request for post-analysis. Take the OP's file YUV-Sample2.avi. When you try to jump to the 'next dropped frame' Vdub reports 'no next dropped frame found' although there is a duplicate (inserted frame) shortly after the beginning.

[lordsmurf]

How do you decide how to splice those two captures together?? You'll still need some tool to find the drops AND the dups.

You should monitor captures. Look at the logging. You should know if the capture was fine at 1:00 (one hour), but you saw dropped frames when you came back at 1:10. Stop capture, start again from just before 1:00.

No, you've got to fix the capture so you don't get drops,

Ideally, yes. But sometimes drops happen even when you did everything correct, all the hardware was good.

fix the result with my script

No. Re-capture.

Capturing again in 2023 with DV will probably just give you pretty close to the same thing you already have.

No. Color changes, color loss.

I've often suspected that those who dump on DV never used

No. It's inherent to the format, even with perfect codecs.

[Bwaak]

often the dups are not dups, but a couple of there-back, there-back frames, which is an order of magnitude more annoying than just a dup. I don't think his script is smart enough to detect the direction?

I am not sure what you mean by "there-back" frames, but if you are talking about a frame where the motion goes backwards for one frame, that is a totally and completely different problem than drops and duplicates.

Yes, this is what I meant. I guess, it is a replaced field instead of a dropped one, top for top, bottom for bottom, which is why it looks like a backward move.

[Marvolo]

You should monitor captures. Look at the logging. You should know if the capture was fine at 1:00 (one hour), but you saw dropped frames when you came back at 1:10. Stop capture, start again from just before 1:00.

How do you recognize dropped frames just by monitoring the capture? Whenever I capture I constantly watch the preview monitor and everything seems to look fine and flawless.

[Marvolo]

@JohnMeyer

As promised, here is a sequence of our ski holiday trip in 1996 in Austria. It's about 1 minute long. I captured - as usual - uncompressed then converted it using VDub into FFMPG Huffyuf 4:2:2, no RGB.
Like I said in my prior post - watching the capture in my preview monitor I can never see any abnormalties such as dropped frames or anything else.

PS: since the file size exceeded the maximum file size of the forum by only 5 mb, I uploaded it on WeTransfer: https://we.tl/t-XGcTx2ulOl

[Sharc]

You should monitor captures. Look at the logging. You should know if the capture was fine at 1:00 (one hour), but you saw dropped frames when you came back at 1:10. Stop capture, start again from just before 1:00.

How do you recognize dropped frames just by monitoring the capture? Whenever I capture I constantly watch the preview monitor and everything seems to look fine and flawless.

Drops/inserts (repetitions) produced by external devices such as TBC, DVD recorder used as ADC or in passthrough mode will normally not be reported by the capturing SW. The external device may supply a "clean" or "corrected" signal (like a duplicate of the previous frame in case of a tape glitch) which is just ok for the capturing SW. So depending on the root cause and place of origin of a glitch it may or may not be reported by the capturing SW.

[Marvolo]

@Sharc

Then it seems as if I have - currently - no other way of knowing if there has been drops other than to align them in my NLE and see if and where they drift apart (As of now, I am not familiar with Avisynth coding / script to do it that way).

But as you said, that would be taking the DV file from 2008 as a "flawless" reference file. For some reason, I always assumed that apart from the compression / makroblocks and the other flaws of DV encoding, those files were the reference until I have created even "purer" reference files by going the lossless route...