Hi. I've just bought a DVD of a singer's TV appearances over the years. There's a mixture of progressive and interlaced clips. I wish to edit as well as convert so, say I wanted 3 songs, 2 prog and 1 inter, is this the correct way to proceed:
+ Reply to Thread
Results 1 to 15 of 15
That won't really work with splices like that, because they will have different framerates. You would need to use a common base framerate using avisynth like that, or make a VFR video
For example if you had "25i" (or 50i, same thing, different naming convention) , and used QTGMC, you would get 50p . If you had 25p sections as well to join, you'd normally have to make those 50p as well . A common method is duplicating frames for those sections (e.g. changefps(50) )
Hi. Song edits - there are 40 performances on the DVD but I don't want them all. So would this be what you're suggesting:
Well I'm making some assumptions, such as this is a "PAL" DVD , and the mixture is 25p and 25i . (There can be other patterns, or content running at different actual rates) . Preview it and see if it looks right
Personally, I would always explicitly include which clip trim() is actually referring to , instead of implied "last" . If you don't keep things in order or have other operations and forget what "last" was, you can get mixed up
You're assumptions are correct. Could I ask you to clarify your second para, please? I'm not entirely sure of the meaning of 'last'.
I've just thought of another possible problem: with a straightforward QTGMC project I'd get my frame numbers from the preview of a script containing the command QTGMC(). With this DVD I'm thinking I'd need to get frame numbers from a script without QTGMC() but wouldn't that give me inaccurate cuts of the interlaced songs? It's all very confusing...
trim(100,200) really means trim(clip,100,200)
But which "clip" does clip refer to ? When you leave it out, it uses implied last, or the last preceding reference ie. trim(last,100,200)
When you have multiple clip references, or are doing other operations, a more complex script, it can be easy to get that wrong (it's easy to get "last" wrong). So I make it a habit to explicitly label everything
If the trim() comes before the QTGMC call, then the framenumbers refer to the original interlaced state. If trim() comes after the QTGMC, the framenumbers refer to the bobbed state (twice the frames)
On poorly edited DVD releases, the danger of editing while still interlaced is you might get a mixed frame with a field from one scene, and a field from another. SO you should always check your edit points. If you're editing while progressive, then you edit on frame boundaries without worries. It's even worse with NTSC DVD's because you can interrupt cadence patterns. For those you should almost always remove pulldown before editing (or cut on cadence boundaries if editing interlaced) .
The simple solution is to just use QTMGC() on the entire video (the parts you plan to keep) and encode at 50 fps.
QTGMC doesn't foul up a progressive video then?
Generally, no. It will just produce two nearly identical frames (whereas ChangeFPS() will produce exact duplicate frames). You may occasionally find a shot where it screws up. Typically on shots with alternating thin horizontal lines -- like horizontal blinds in a window, horizontal stripes on a skyscraper in the distance, etc.
OK, thanks. Change of plan anyway - I'm making one clip comprising the progressive material. Having properly assessed the rest, it's not truly interlaced so I'm going to need TFM or something else. The last DVD I worked on, Field Deinterlace was the only thing I found that did a decent job. If you're interested, here's a sample of a non-progressive bit.
Update: I've just done a song using 'tfm(order=-1)#.tdecimate()' and it looks fine.
Last edited by pooksahib; 15th Dec 2016 at 11:02. Reason: Successful test
sample.mpg is fully interlaced video -- 50 different fields per second. If you reduce it to 25 progressive frames per second you will lose half the temporal resolution and up to half the spacial resolution.
Scheisse... My testing method is this:
- watch frame-by-frame a section of the video
- if there is no combing then it is progressive
- if there is combing then it is either interlaced or telecined
- to see if it is interlaced or telecined watch frame-by-frame using "SeparateFields()"
- if there is motion every field, it is interlaced, so you deinterlace using QTGMC
- if there is motion every two fields, it is telecined, so you IVTC using TFM. If it is PAL, that's all.
To my eyes, separatefields was giving me motion every two fields. Plus, it was a very 'wavy' image, not as sharp as a 'normal' interlaced picture. I'll try again with QTGMC. Later, though, have to go now. And thanks.
There is obvious motion at every field. A "wavy" picture may indicate you did something wrong.
How are you opening the file? Maybe your source filter messed up. The method you explained seems correct.
Aha, I think I know what's going on. I use MeGUI and, after running File Indexer, I've been putting separatefields() into the script and then just reloading the preview. This gives the wavy image where it's difficult to determine motion. But by saving the script and re-opening MeGUI I'm getting a proper result. Which means I'm now going to make an mpg with all the interlaced songs, make a script with QTGMC() and then make a cup of tea. Thanks guys.