He wants to have the smallest video, perhaps it could be good to filter a little. What do you think ? It's not mandatory, but can be helpfull.

Using LRemoveDust should help. I wouldn't use the MA script because it will surely get all confused with the amount of motion workout videos tend to have.

Maybe this script:
TDeint, RemoveGrain, Repair and SSETools are needed. I don't have the URLs for them so you'll have to try finding them yourself. There are probably links to them buried somewhere in the kvcd.net forums.

I don't want to steal this thread but I have noticed that my LRemoveDust script looks slightly different from Boulder's.
Here's mine:
Could somebody explain me the differencies or which one is most accurate/up to date?
BTW I just noticed something strange in mine, the crop 0,0,-0,-0.
What's with that line? :?
Thanks in advance guys.
Cheers

The crop line is to avoid the infamous misalignment "bug" (it's not actually a bug) which can make the filter crawl at a very slow speed.

The only difference is that the function I posted includes TemporalRepair. You can read more about it at the official RemoveGrain page. I'm not sure if it's absolutely necessary when using mode 17 with a rather low limit but it provides some extra artifact protection.

Thanks Boulder :).

I am so sorry for the really late response (not a lot of spare time) so is this script correct
LoadPlugin("C:\Filters25\MPEG2Dec3.dll")
LoadPlugin("C:\Filters25\TDeint.dll")
LoadPlugin("C:\Filters25\RemoveGrain.dll")
LoadPlugin("C:\Filters25\Repair.dll")
LoadPlugin("C:\Filters25\SSETools.dll")


MPEG2Source("C:\20_MINUTE_WORKOUT\VIDEO_TS\20mwo.d 2v",cpu=4,idct=7)
TDeint(mode=1)
LRemoveDust(17,1)
Limiter()
AssumeTFF()
SeparateFields()
SelectEvery(4,0,3)
Weave()

function LRemoveDust(clip input, int clmode, int "limit")
{
limit=default(limit,2)
clmode=default(clmode,17)
repmode = 2
clensed = Clense(input)
rep = Repair(clensed, input, mode=repmode)
rg = RemoveGrain(rep, mode=clmode)
rd = TemporalRepair(rg, rep)
return LimitChange(rd, input, limit, limitU=255)
}

Yes it is.

:D whoo hooo thanks boulder for the response and :D i dont know i am so happy. thanks again

one more thing i did what the first page of the topic said how to determain if it is a top field first or bottem field first and both seam a little jerkie(guessing it is the framerate)and cant tell the difference whitch ones smother

:oops: sorry double posted

Try opening this script in VDub or a media player and see what it says about the field order:
I learnt recently that MPEG2Source always returns the correct field order (if it is set correctly in the source file).

If you can't work it out, post a small sample (a couple of frames should do) of the unprocessed source. I would also upgrade to the latest DGIndex/DGDecode.dll instead of using the obsolete MPEG2Dec3.dll.

vdub says" parity : assuming top field first" and how can i upgrade to the latest DGIndex/DGDecode.dll?

Top field first parity means the script should be correct. I can't say anything about the jerkiness unless I see a sample myself. When you open the VOB file in VirtualDubMod, does it show a pattern of 3 non-combed frames followed by 2 combed frames or are all frames combed?

To upgrade to DGIndex, download the latest DGMPGDec package (v1.4.8) from http://neuron2.net/dgmpgdec/dgmpgdec.html. Use DGIndex for creating the d2v file and load dgdecode.dll in your script instead of mpeg2dec3.dll.

Pretty simple actually.
Download it here http://neuron2.net/dgmpgdec/dgmpgdec.html .
Extract it to a folder near your other video-related tools.
Copy dedecode.dll into avisynth's plugin folder.
Since D2V projects made with dvd2avi are not compatible with dgindex you will have to rebuild them with dgindex, a tool which is actually very similar to dvd2avi since they both share the same base code.
Now if you plan to keep dvd2avi installed (just in case) and also keep mpeg2dec3.dll in avisynth's plugin folder then all your newly dgindex projects will have to be opened with a dgdecode_mpeg2source("c:\...") in your scripts.
And that's all there is to know.
Cheers

PS:damn, boulder beat me to it :lol:.

thanks :D boulder and rds_correia i understand exactly what to do now
and its a little jerkiness but i can live with it i am just very observant (by the way thanks so much for the script boulder :D looks great) what happens if i encoed with bff instead of tff :oops: i have not tried to open the VOB file in VirtualDubMod but when i do i will keep you posted
thanks again guys
p.s. whats the difference between DGDecode.dll and MPEG2Dec3.dll.

If you use an incorrect field order, it's highly likely that it'll be very jerky, going back and forth. You can't miss it.

Yep, MPEG2Dec3 was known to have a little bug that would end up in a smaller video than the sound thus making room for audio desync in some rare occasions.
Nothing too big to worry about but nevertheless better keep it on the safe side, right? :lol:

i encoded with AssumeTFF() and AssumeBFF() in my scripts and it does not change in tmpgenc. in fact bottom field first seems to be default and does not change with the .avs script unless i change it manualy ( setting \ advance tab \ field order : bottom field first(field B) ) and made sure that ( setting \ advance tab \ video source type : interlace ) and still dont see a noticable difference between the two with it changed in the .avs script or changed manualy in tmpgenc. and the slight jerkieness looks like it is at 16 frames per second. i really dont care about the sight jerkieness but is there any problems or does it really matter if i encode with top field first or bottom field first and dvd2avi1.77.4 says it 4:3,29.97fps,interlaced
so whats my problem and dose this affect me playing on my tv?

I'm certainly not an expert when it comes to interlaced sources but I have had 29.97fps sources and believe me when I say that it really mattered if I was using TFF or BFF.
Load your avs script in VirtualDubMod and watch it frame by frame in TFF and in BFF.
If the jerkyness disappears then you know what was wrong ;).
Cheers

it says this with VirtualDubMod info "fieldbase (separated) video : no " could this be the problem and i loaded me avs script in VirtualDubMod and watch it frame by frame in TFF and in BFF and still did not see any difference

so should i change it manualy in tmpgenc to ( setting \ advance tab \ field order : top field first(field a) ) after i load every thing and right before i start encoding?

all frames combed

Yes, do not trust what TMPGEnc says. If you know that the field order is TFF (which it is 99% of the time when dealing with DVDs, DV is always BFF), set TMPGEnc to encode as TFF. As all the frames are combed, you have a pure interlaced source.

if i encoded with it saying bff (didn't know) in my avs script but changed it manualy in TMPGEnc does it encode at bff or tff?

IIRC most "source settings" in tmpgenc don't matter much unless we're feeding it with the real source.
Which in this case we ain't: we're feeding it with a script.
Thus I feel pretty much confident when I say that if you left the field order set wrong in your script then most surely you will end up with a jerky KDVD.
But I'm not an expert in interlaced sources and my memories of tmpgenc are starting to fade away gradually...

You must use the correct field order in both the script and encoder to avoid problems.

thanks guys for your help it turned out pretty good . I managed to get 6 movies rangeing from 19min to 53min . thanks again

Good for you :D.
We always love hearing good reviews on KDVD/KVCD.
Cheers

A small update
 

Here's YADIF, which is a very good and rather fast smart bobber:

http://avisynth.org.ru/yadif/yadif.html

Do not place the plugin in your Avisynth plugins folder! You must place it elsewhere and load it in your script by using Load_Stdcall_Plugin("path\yadif.dll").

Then simply use:
Encode as interlaced, setting the field order to whatever it is in your source. Most likely it is TFF.

Load_stdcall_plugin is a new "feature" of avisynth 2.7 to fix memory leak (or alignement) problem, isn't it ? 2.7 has some problems and I removed it atm.

Nope, it's just an alias for LoadCPlugin, which sometimes gets overridden by the old LoadCPlugin from avisynth_c.dll. Load_Stdcall_Plugin was included in v2.5.6 I think.

Ok, thanks ! (the new aviynth.org with is wiki documentation is a pain in the a... when looking for information :-().

Hi guys,
Long time no seeing.
Hope everybody is doing fine, Karl, Phil, Andrej, Boulder, etc.
I'm not doing bad myself but I can't say I have been encoding much in the last 12 months mainly due to too many things in hands.
Anyway, remember my last posts in this thread?
They were about a DVB-S capture that I got from a friend of Guns N' Roses Welcome to the Videos and it was interlaced in a way that I couldn't figure what to do, even Boulder found it weird.
This time I decided to buy the DVD from an online store thinking that it would be a much better source.
Wrong! I payed $14.00 plus shipping and I got a very bad 720x480 interlaced / 4:3 NTSC @ 29.97fps.
The picture quality is so bad that I almost can't tell the difference between the DVB-S that I still have and the actual DVD.
Only this one is top field first with a constant 3 frames good + 2 combed frames.
I then created a DGIndex project with field operation set to Force Film to retrieve a 23.97fps.
I loaded it into Andrej's PARanoia and I set it up just to resize to 704x480 and to output a avs script.
Then I opened the script with VDub 1.7.8 along with the MPEG2 plugin and I watched it just to realize that in every scene change I still had 1 or 2 combed frames.
So I added LeakKernelDeint(order=1,sharp=true) to my script just below the resizing parameters.
Note: Boulder's recommendation, Yadif, simply didn't decomb the frames and that's why I tried LeakKernelDeint.
Now it looks like a...progressive source but @ 23.97.
I'll be using Hank's excellent HC encoder.
So, at this point what should I do? What options should I select in the encoder since I want to deinterlace the source?
Should I try to a) keep it at 23.97 or b) should I use the 3:2 pulldown in HC?
I have tried both options in advance and a) comes out fine but then Muxman doesn't like the m2v when I try to author it, and b) makes the encode go back to 29.97fps with 3 good frames and 2 combed. Weird, shouldn't it be the opposite?
I really don't seem to understand interlaced sources and the approach to encode them.
Maybe I should try to keep it at 23.97 and maybe use DVDPatcher or maybe DGPulldown to trick Muxman, I don't know...
All I know is that watching the original DVD with my SAP on my plain old widescreen 32" CRT TV I can see the combed frames a lot (should I?) and I hate it.
Unfortunately the WTTV doesn't seem to have been edited in PAL so there's no progressive 25fps version of this title.
At least, not that I'm aware of.
Sorry for such a verbose post, you know me and my big mouth :lol:.
Cheers

Only 29.970 is allowed on DVD so, as your source is 23.976 now, then you must use the 3:2 pulldown.

The point is that your source is not interlacec anymore, and that was your purpose using leakkerneldeint, isn't it ?

3:2 pulldown in HC is just like using DGpulldown afterwards: simply adding flags in the mpeg stream. You don't encore really in interlaced mode.

Not normal. You should not have more combed frames than with any other of your sources. That means that this one is not correctly deinterlaced.

Hi Phil,
Thanks for your reply.
You see, my source looks normal.
That is, it looks like 3 normal 2 combed 3 normal 2 combed, all the way through until the GOP ends.
But in every scene change I get between 1 and 3 combed frames and sometimes they are not consecutive.
I mean, at least this time there is a pattern.
Anyway, with my tv+sap I can clearly see the combing especially in the scene changes.
So from a backup point of view what do you suggest?
DGIndex set up for Forced Film or should I create a 29.97 d2v project and deal with the combing in Avisynth?
Either way, how do I setup HC to deal with both options, 23.97 and 29.97?
Cheers

PS: Boy, I'm such a noob when it comes to interlaced that I didn't even know that DVD only accepts 29.97...

I think your source is not film, nor video (=interlaced) but hybrid !
Thus you should configure DGIndex on "honor pulldown flags" and then use this in your script :
If I'm not wrong, this should give you a 23.976 result, that you will encode as any other progressive source.

Nevertheless, can you post a snapshot of these scene changes ?

Great tips Phil.
By snapshots you mean pictures?
I guess a small avi done with vdub is ok with you?
Here's the link http://www.j3v.woeps.com/kvcd/wttv.avi
Remember this avi was encoded from the source vob.
All goes well from frame 0 till frame 13 on a 3+2,3+2,3+1 because at this point there is a scene change.
Now look how frame 14 is decombed although fuzzy followed by 15 combed, 16 decombed (fuzzy again look at Axl's shoulder), 17 decombed, 18 combed, 19 decombed+fuzzy, etc.
The worst parts are the black and white.
They only last a few seconds now and then because most of the time it is a 3+2, 3+2, 3+2, etc.
Should I try with your tivtc suggestions?
What about in the encoder?
Do I choose 3:2 pulldown or do I encode as if it was not interlaced?
Cheers :)

Your avi has been encoded using what setting in DGIndex ? Honor pulldown ?

Yes, you should. Even if there is no real magic :x
It seems you still didn't understand that you have no other choice than using the 3:2 pulldown when the source is 23.976 (=progressive) ;).

Hi Phil,
The avi that I posted has nothing to do with DGIndex.
I loaded the source vts into VDub and there I encoded to avi.
So it's from the real source, not from a DGIndex project.
And I really don't know if my source is really 23.97.
When I create a DGIndex project using Honor pulldown flag I get a 29.97 project whereas when I use Force Film I get a 23.97 project.
So, which is it, 29.97 or 23.97? :lol:
Man interlaced sources are a big pain in the a... :lol:
Cheers mate

That is normal. If you look at the doc of DGIndex you will see that :
- honor pulldown follows exactly the source spécification, and as I said on DVD all sources are 29.970.

- discard pulldown does not take care of pulldown flags in the stream and so, if the source is correctly 3:2 pulleddown, that means that it really follows the 3+2 patttern, then the resulting video should be 23.976. But it clearly seem that your source does not follow this pattern ! My guess is that "discard pulddown" will give you something not 23.976 (nor 29.970). These are known as "hybrid videos".

- force film is to discard pulldown AND force 23.976.

None of them ;).
AS I said, the best for you is to use "honor pulldown" in DGIndex and let TDecimate to try to combine the correct frames and generate a correctly decombed 23.976 stream.
(don't hesitate to look the pluginn doc, there are several other settings than "hybrid=1" than can help).

Issue is that your source is not interlaced. Else it will be easy to simply split the fields and encode in interleaved mode. Here you have a "not academic" pulled down source.