Capture Guide Suggestions

[BaronVlad]

Hi,

the Analogue Capture Guide is online now:

http://www.doom9.org/capture/start.html

First I want to thank killingspree for the translation and Donald Graft for proofreading it.

I also want to thank all the guys that sent me screenies about the power management setup and the settings regarding NTSC, this will be updated soon.

As the "source" is a German guide there may be more special country related settings (i.e. PAL not NTSC...) We need your help. If something is not correct for your country, you know something we should add or any other comment please use this thread to give us detailed information

Thanks

BTW: The FAQ will also be updated asap. (Mijo, please drop me a few lines...)

[^^-+I4004+-^^]

>If something is not correct for your country, you know something we should add or any other comment please use this thread to give us detailed information

well,vlad,it's good that you saw the need
for such thread (otherwise i would initiate one...
hmmm probably soon...hehe...today was busy capturing
day....)
guide is already pretty good,but i think
we might make it even better........
today i reviewed few pages and have few
suggestions (to make things clearer) tomorrow i'll
do'em all and try to tell what bothered me....
hopefully,soon this will be THE capturing guide
(to keep the elitist place this web already
probably has)
we'll make it good!

cheerio (till tomorrow)

/ivo

[Wilbert]

Nice! However I missed a lot of important things in your guide. To summarize a few:

1) deinterlacing: how?

2) resizing: why (why not just scaling) and how?

3) smoothing: why and how?

4) adjusting colors: why and how?

5) why does it matter whether you encode to Xvid or SVCD?

Last week I also started with a guide, located at www.avisynth.org, which is supposed to explain the considerations of the points above. Have a look here here. As you can see it is not ready yet.

[BaronVlad]

Hi

@ivo: I am looking forward to see your detailed suggestions, you are right, this guide has to be the capture guide in the future as it is hosted here

@Wilbert:

Originally posted by Wilbert

1) deinterlacing: how?

2) resizing: why (why not just scaling) and how?

You are right...thats strange, I dont know if you know the German guide: http://212.223.15.244/extern_guides/...de/Inhalt.html

Deinterlacing and Resizing is explained. I actually dont know why it is not in the English version. Think we have to look for the missing parts...

Originally posted by Wilbert

3) smoothing: why and how?

4) adjusting colors: why and how?

We should add it, as well as the thing with "Save processing settings"

Originally posted by Wilbert

5) why does it matter whether you encode to Xvid or SVCD?

I think we have it in the guide:

Desired Final Format

What format should you choose? This depends especially on where the video is intended to be played back. If you just want to play it on your computer, I'd suggest you go with DivX. This codec enables you to save the video in very high quality in a relatively small amount of space (CD or hard drive). But if you want to play your videos on your standalone player, DivX will not help you, because the standalone cannot playback mpeg4 (DivX). Your standalone is only able to do mpeg1 (VCD) and mpeg2 (SVCD) playback. Still, some players do not even support SVCD, so you might check this before starting. (A new generation of players is just emerging that play DivX.)

( http://www.doom9.org/capture/preface.html )

Originally posted by Wilbert
Last week I also started with a guide, located at www.avisynth.org, which is supposed to explain the considerations of the points above. Have a look here here. As you can see it is not ready yet.

I like your work Wilbert, cause of your Avisynth and Filter Knowledge I am able to use the Deinterlace MAP in Avisynth scripts !!!

If you like, we could "join" our thoughts and add your knowledge about avisynth which is highly recommended for capturing to the doom9 guide ?

Thanks

[Wilbert]

You are right...thats strange, I dont know if you know the German guide: http://212.223.15.244/extern_guides...ide/Inhalt.html

I think I've read it once. But my german is not that good, I only understand half of it

Deinterlacing and Resizing is explained. I actually dont know why it is not in the English version. Think we have to look for the missing parts...

Deinterlacing: I only see deinterlacing for PAL I also don't see a discussion of what kind of deinterlacing problems you could have (only shifted fields, trully interlaced, messed up NTSC2PAL conversions, etc.), and what to do in those cases.

Resizing: I missed the part (or reference) of why you should resize to 4:3. Note that if you captured at 704x576 it will not exactly be 4:3, but that's a detail. Another detail, regarding analog captures I wouldn't use Lanczos. That makes only sense if you have a clean source, and you are encoding to DivX.

Regarding (5):

I think we have it in the guide:

Sorry, I missed that.

I like your work Wilbert, cause of your Avisynth and Filter Knowledge I am able to use the Deinterlace MAP in Avisynth scripts !!!

Just curious, since I never used Deinterlace MAP. When is it advisible to use this deinterlacer. Only if your (parts of the) source is trully interlaced, or also in the case of shifted fields? How does it compare to decomb?

If you like, we could "join" our thoughts and add your knowledge about avisynth which is highly recommended for capturing to the doom9 guide ?

I like that, it would be very nice if I can help! I will sent you a PM. The advantages of using AviSynth is the speed, the presence of spatio-temporal filters, but also that you can deinterlace in the color format of the source itself.

[killingspree]

Originally posted by Wilbert

Deinterlacing: I only see deinterlacing for PAL I also don't see a discussion of what kind of deinterlacing problems you could have (only shifted fields, trully interlaced, messed up NTSC2PAL conversions, etc.), and what to do in those cases.

well you have to consider that this was a guide on the german doom9 page thus of course not dealing with ntsc captures as it is not used in germany. but yes i think going more into detail there would be very nice... i also believe we should update the divx encoding section or just link it somehow to an existing doom9 guide... i've already done this with the audio section...

perhaps we can also work out a new guide where you are just using vdub for capture and then load the capture into an avisynth script and do the rest, at least for divx stuff with gknot or similar... of course any other encoding tool would be fine too. i think doing all these calculations etc manually might just be a little outdated...
(of course just the opinion of a tiny translator :-P)

oh and at this point i also want to thank all the people that mailed me a screenshot of the english "energy management", got quite a few of them :-P

regards
steVe

[Wilbert]

perhaps we can also work out a new guide where you are just using vdub for capture and then load the capture into an avisynth script and do the rest, at least for divx stuff with gknot or similar... of course any other encoding tool would be fine too. i think doing all these calculations etc manually might just be a little outdated... (of course just the opinion of a tiny translator :-P)

I PMed BaronVlad about this. I think best is to work out another guide when using AviSynth. If I have a proposal I will sent it to you.

edit: good discussion about deinterlacing/color corrections can be found in Luke's guides. I also think that the emphasis should not be on the encoding proces itself, because that is the least important.

[Ookami]

Originally posted by BaronVlad
BTW: The FAQ will also be updated asap. (Mijo, please drop me a few lines...)

Just send you an mail asking if we should update the FAQ, now .
We will sort out the details via mail...

As for deinterlacing etc., there will be a new update of the IVTC page by Manono et al, so it will explain many things. It would be enough if the guide would link to it. No need to do the same work twice.

-resizing

I think it depends more on the end bitrate/res if you capture at full resolution and convert to a HQ end format (no 1 CD backup, please) it should make quite a difference (in my experience it does), especially if you capture directly from a tuner (relatively clean picture). But, even Avery Lee said that he sees no difference to bicubic . And if you have a natural blur filter like myself (bad sight), you must sharpen the picture a bit more .

Cheers,

Mijo.

[killingspree]

Originally posted by Wilbert
I PMed BaronVlad about this. I think best is to work out another guide when using AviSynth. If I have a proposal I will sent it to you.

thanks

edit: good discussion about deinterlacing/color corrections can be found in Luke's guides. I also think that the emphasis should not be on the encoding proces itself, because that is the least important.

well of course it is true that the main point of the guide should be to capture in the best quality possible, but speaking from my experience encoding captured content is fairly different from dvd2divx/mpg encoding , especially filter usage... i mean perhaps we could focus more on filter usage etc and regard the actual encoding process as something people should already know when reading the guide...

regards
steVe

[^^-+I4004+-^^]

ok,here we go,i have opened round 18 pages and
have them before me,but for a start i would
opt for a opinion where the capture
guide and post-process guide should be completely
separated;no mixing between these two....
(in any good capturing these two steps are
separated anyhow..all postprocessing should
be done afterwards...denoising especially (heh).....
so if the deinterlacing guide is already existant,
in my mind it should be tweaked a bit for the
analog purposes [noise is there,and that
makes deint. harder,should we denoise first with separated
fields,or deinterlace first....you know what i mean..hehe]

now,let's see;
[preface]
>The source will be a PAL system and you should end up with a DivX .avi file muxed with a cbr-mp3 audio, in your preferred filesize. For the more advanced users, who prefer vbr-mp3 or ogg-vorbis, I include a small excursion into high quality sound

i think many would argue on the benefits/disadvantages of vbr-mp3
instead of cbr,but that's the listeners choice after all,and i'm not
to much into that but let me just say that cbr at 192kbit sounds pretty fine to me.....(ie. cbr is high-quality too....)
but ok,it's a "small excursion"...hehe

> But if you want to play your videos on your standalone player, DivX will not help you, because the standalone cannot playback mpeg4 (DivX).

and this

>(A new generation of players is just emerging that play DivX.)


seems a bit contradictory ;i would prefer just the
last statement,with
an additional note that one should aim to make such divx files
that will look nice on both emerging divx players and PC's....
(ie. to aim for higher resolutions,makin it "16" compatible etc.)
although only very few people have these players now....
[this is not so important anyhow,divx players have miles to
go before they can stack up to PS versatility]

>384*288 (1/4 PAL) = Low Quality
+ filters generally not necessary

?
i would say that filters are MORE important on the
lores,than hi-res capture;16x16 error blocks are much easier to
spot on 384x288 then on 768x576......
(as 16x16 is relatively small for 768x576 and big for 384x288)
also;lores capture usually get smaller bitrate,and that
doesn't help either,so filtering is a must for lores...

>7xx*576 (Full PAL) = High Quality
Full PAL is actually at 768*576, but different capture cards will calculate the resolution in different ways, so that there will be different values. The chosen resolution is determined by your capture card. I am using an ATI Radeon and thus decided to use a resolution of 720*576.

here ,i think, it would be fine to state that 768x576 is a
preffered
resolution if you aim for mpeg4 codecs and the video
will be projected
to monitor or tv-out ( all monitors,and mine (heh) tv-out chip have
only square pixel output resolutons...768x576 etc. )...
and 720x576 will be best raw material to make dvd compliant
mpeg2 (ie. 720x576 has nonsqaure pixelAR)
if you have 720x576 source and you resize that to 640x480,you have
640x480 with unsquare pixel,and this shouldn't be so....(or?)
i like to keep it square pixelAR all the time,from capturing till encoding.....(you guessed it;i don't have dvd-player)
[your ati capturings on 720x576 don't fill teh complete screen,right?]
also perhaps it should be mentioned that vdsync 1411 includes
tweaked bt8x8 tweaker where you can set the pixelAR exactly correct
and according to ccir601,as bt cards are not quite standard compliant
on 720x576...(but ARE square pixel on 768x576)

[optimizing]
>1) A fast and large hard drive. Best would be 7200 rpm, with a large cache, and as many Gigs as possible.

it would be closer to the truth to say that any ata66 drive will
do (even huff at cca. 10MB/s is not problem for ata66 drive)
you're right...it can't be too big......
[i think it's important for users to know that paying
twice the money for 7200
or SCSI is not so wise if they can invest that extra
money in better
capturing device.....]
my 2MB cache,5400 ata133 drive working in ata66 mode (didn't applied
no w2k SP's) doesn't drop at all.....also "defrag." is a strange word in my dictionary....so you be the judge what's needed....

[preparing]
>Audio -> Compression -> in the dropdown box labeled 'name' you should choose CD-quality.

if one is capturing mono VHS,then this is not good choice;
mono VHS can't go above 16khz (not in it's wildest dreams)
so capping it at 44khz will only capture much more hiss....
i reccommend 32khz/16bit mono sound for mono VHS sources...
(or ; don't capture the hiss....mp3 doesn't like it either...)

>Video -> turn off Overlay and Preview using VFW drivers, with BT8x8 chips.

if you turn off both,how will you see the image?
preview should be on,and overlay not,as one cannot capture full-pal on VFW if overlay is on.....
if there are drops,THEN consider turning the preview off too...
(first step to troubleshoot framedrops)

>Set the framerate (PAL) to 25, set the buffers as shown in the screenshot below, and activate "Lock video stream to audio".

always capping without this ticked,and always fine
sync on VFW....more research is needed to see what it does
to VFW and what to WDM capturing....

>Capture -> Disk I/O
In this small window you can match VirtualDub to your computer's hard drive speed. I got tired of frequently switching these settings so I just leave the defaults.

don't think this is of importance;if the device drops frames the chances are this is not
the problem......(my Erazor continues to drop no matter the
buffering...as it's the driver issue....)
i think default is fine for majority.......

[384*288 (1/4 PAL) ]
>If it is possible to choose more than one Huffyuv codec, make sure you choose the one for the data format you just entered in the previous step (e.g., YUY2).

all huffyuv modes are lossless,so choose the one that allows you to go to highest
resolution with your CPU.....
(if "predict median(best)" works fine,then ok..if not,chose faster but
with less cempressability)

>For the PicVideo MJPEG codec, set the quality to 18 or 19, and under Advanced, set Luminance Quality to 2 and Chrominance Quality to 3.

picvideo will yield decent results from "17" to "19" (20 overkill and it seems to drop more at least here)
chroma subsampling can be 4:1:1 without loss in image quality (but reduces
bitrate even further)

>Noise reduction
The worse the source is the more disturbances you'll have in your capture. This is the so-called "Noise". VirtualDub lower the amount of noise, which is often also responsible for dropped frames. Unfortunately, this also softens the picture and needs some CPU power too.


NR shouldn't be used on-the-fly anyhow...(and + VDUb doesn't have
real good NR filter....and i have tried quite a few...)
also : from this sentence one could imagine that NR on
capturing might
decrease number of dropped frames,and this is not the case ;
a/d converting chipset is receiving the noisy signal and
converting it
.....denoise is done only AFTERWARDS,and WILL NOT help if the dropped
frames are caused by the noisy video....
(NR on-the-fly only blurs and loads the CPU...shouldn't be mentioned at all.......)
all post processing should be done afterwards....
(although someone will be ok with NR+deinterlace on the fly...i'm not..)

>Furthermore, I should probably mention that you should not touch the computer during the capture process!!!

this is ok,many people forget this and want to "do something while they capture"...ohh,come on......it's enough if it can do capturing alone...

[postprocessing the video]

i think folks should be encouraged to use avisynth right on this
spot ; from all that i see vdub's days as a filtering util
are numbered : avs is faster (works in YUY2),it has more powerfull
NR filters (lindsey dubb's filters have no vdub "cousins" , no vdub
NR that i saw can stack with them...)
sure,it's not user friendly,but hey,if you're capturing,you might as well go that mile extra....(or mile and a half..heh)
in my case,with simillar filtering,avs is almost twice as fast....
(and i have slow cpu,so....)
recently,.vcf files with cutting info can be converted to
.avs files and that means vdub is only used for editing and compressing ; all postprocessing and cutting is done inside the avs
script..(a dream cum drue.....)

[384*576 with vertical resize ("1/2 PAL") ]
>When capturing from analog sources, you often see a colored (green most of the time) line on the bottom of the picture. This is ugly to look at and can also lead to dropped frames. This problem can be solved by simply reducing the height of the captured video slightly. You can just deduct a few lines off the height, e.g., use 572 instead of 576.

never seen that green line myself,and also,this should only be encouraged if there are big problems with dropping;
this is messing the video in a bad way ,but was already discussed
(xesdeeni posed a nice explanation what happens)
use this trick only if you have no other place to go...
(this blurs image heavily)
i have a sample on http://i4004.bizhosting.com/
( 720x576 and 720x540...you'll see the difference only 16 lines are taken out but it's like 30% blurier )

>Setting up Vertical Reduction
Video -> Vertical Reduction -> 2:1 Linear (smoother picture but less CPU intensive) or 2:1 Cubic (sharper)

if cpu can't take it,you might as well capture at 384x576
and do vertical2:1 afterwards.....

-------------------------------------------------

ok,i guess that would be that........
[ and remember : processing separated , encourage avs use.....
capturing is one thing,and making decent encode of it quite
another.... ]

/ivo
ps.lol-is it detailed enough?

[bb]

NR shouldn't be used on-the-fly anyhow...(and + VDUb doesn't have
real good NR filter....and i have tried quite a few...)

Just one addition:
The noise reduction is very useful and improves quality if you capture to MJPEG, because the noise is reduced before encoding. DCT codecs like MJPEG hate noise, and it's a good idea to get rid of it as much as possible before the encoding step. Although the on-the-fly noise reduction is not the best, it improves overall quality in this case. I wouldn't use it when capturing to Huffyuv, and for MJPEG I'd set the strength slider rather low, like five or six ticks.

bb

[BaronVlad]

Oh guys...

what have I done by starting this thread...?

So much good thoughts, so much to read, I think I will have a closer look into it, I hope I will have the time tomorrow

Thanks to all of you, Wilbert I got your PM and will go into details asap.

Mijo, can you please send me your suggestions about the FAQ again, I lost it while setting up my engine again...

[kempodragon]

Regarding "Lock video stream to audio stream", Avery Lee specifically states not to use it for normal capturing. It is only used for compatability mode. I use "Adjust video clock dynamically to audio clock" and have never had any synch problems. Also, for those people who don't have RAID, it should be mentioned that a dedicated hard drive should be used. I watched my resolution capability jump from 352x480 to 720x480 while CPU usage dropped as much as 50% just by switching from my system drive to a separate hard drive (I don't know how well a dedicated PARTITION would work.)

[BaronVlad]

ok, here we go again, think this post will be a long one...

First let me summarize:

We all think that it is best to have a capping guide as the main part and all the post processing like encoding to different formats via VDub to Divx (most is ~ok in the guide) and XVid)as well as DVD and SVCD mentioned as not main parts.

We need the resizing and deinterlacing stuff superficial (maybe how to do with VDub) The detailed settings (which resizing / deinterlacing methods) linked to other documents, i.g. Wilbert, Luke...

We need NTSC capping options explained (who wants to add this part ?)

Now lets jump into the details:

Originally posted by killingspree

i think doing all these calculations etc manually might just be a little outdated...
(of course just the opinion of a tiny translator :-P)

First: You are not only a tiny translator, you did a very good job, the guide is online here and it wouldnt be if it was bad !!!

To the calculation: Nobody got the error in the calculation: Divx doesnt calculate with 1024 but with 1000, hehe...(we should correct it) Every user should use GKnot for the calculation, but is it bad to understand how it works ?

Originally posted by Wilbert

Deinterlacing: I only see deinterlacing for PAL I also don't see a discussion of what kind of deinterlacing problems you could have (only shifted fields, trully interlaced, messed up NTSC2PAL conversions, etc.), and what to do in those cases.

Mentioned above

Originally posted by Wilbert

Resizing: I missed the part (or reference) of why you should resize to 4:3. Note that if you captured at 704x576 it will not exactly be 4:3, but that's a detail. Another detail, regarding analog captures I wouldn't use Lanczos. That makes only sense if you have a clean source, and you are encoding to DivX.

4:3 thats true, should be said when we update and put in the resize thing, with my capping I tried different resizing methods, IMO Lanczos was pretty good, now I use "Bicublinresize" via Avisynth. It is fast and good, but maybe someone wants to write a summary (or point one out) about advantages and disadvantages of different rezising methods ?

Originally posted by ^^-+I4004+-^^
here ,i think, it would be fine to state that 768x576 is a
preffered
resolution if you aim for mpeg4 codecs and the video
will be projected
to monitor or tv-out ( all monitors,and mine (heh) tv-out chip have
only square pixel output resolutons...768x576 etc. )...
and 720x576 will be best raw material to make dvd compliant
mpeg2 (ie. 720x576 has nonsqaure pixelAR)
if you have 720x576 source and you resize that to 640x480,you have
640x480 with unsquare pixel,and this shouldn't be so....(or?)
i like to keep it square pixelAR all the time,from capturing till encoding.....(you guessed it;i don't have dvd-player)
[your ati capturings on 720x576 don't fill teh complete screen,right?]
also perhaps it should be mentioned that vdsync 1411 includes
tweaked bt8x8 tweaker where you can set the pixelAR exactly correct
and according to ccir601,as bt cards are not quite standard compliant
on 720x576...(but ARE square pixel on 768x576).

Please look above, think the DVD thing is important to add, but this should be done in accordance with a little how to set up the frameserver for cce or tmpeg (Avisynth / VDub) Who wants to do that part ?

Originally posted by Wilbert

Just curious, since I never used Deinterlace MAP. When is it advisible to use this deinterlacer. Only if your (parts of the) source is trully interlaced, or also in the case of shifted fields? How does it compare to decomb?

I tried different Deinterlacer via VDub, IMO the MAP deinterlacer made the best job (many people told me the same). It also works very well with strange resolutions like 720 * 540 (I know we shouldnt do this) If you dont want to analyse the source you can take this one, it does a good job, no matter the source is trully interlaced or a field order problem. Now I do digital caps, when I capture analog, I have a Cam connected to my ATI Card, there I get good results with "ComplementParity()" and "FieldDeinterlace(full=false,threshold=15,dthreshold=9,blend=false)" via Avisynth.

Originally posted by Wilbert
I like that, it would be very nice if I can help! I will sent you a PM. The advantages of using AviSynth is the speed, the presence of spatio-temporal filters, but also that you can deinterlace in the color format of the source itself.

Nice to hear, I am sure you can help with your Avisynth knowledge. I also use Avisynth now another advantage is the easy use of cce or tmpeg (I think), but we should also make a guide for the clueless noobs . Often they run away when they have to write their first avs. Thats why IMO the VDub way should remain in the guide. But we should add the Avisynth thing for "experienced user". I am glad to have you around here, Wilbert.

@Mijo: Hehe, I usually made 1 CD Divx, horrible ?

well of course it is true that the main point of the guide should be to capture in the best quality possible, but speaking from my experience encoding captured content is fairly different from dvd2divx/mpg encoding , especially filter usage... i mean perhaps we could focus more on filter usage etc and regard the actual encoding process as something people should already know when reading the guide...

Originally posted by killingspree

i mean perhaps we could focus more on filter usage etc and regard the actual encoding process as something people should already know when reading the guide...

This guide should be both, a guide for noobs and for the experienced, I think all the people posted in this thread looked into the guide to make it better, not to learn how capturing works. Please dont forget this. "Extreme" Filter usage could / should be added but not be the main focus (IMO)

Now the details of ivo :

Originally posted by ^^-+I4004+-^^

i would
opt for a opinion where the capture
guide and post-process guide should be completely
separated;no mixing between these two....
(in any good capturing these two steps are
separated anyhow..all postprocessing should
be done afterwards...denoising especially (heh).....
so if the deinterlacing guide is already existant,
in my mind it should be tweaked a bit for the
analog purposes [noise is there,and that
makes deint. harder,should we denoise first with separated
fields,or deinterlace first....you know what i mean..hehe]

We tried to explain that capturing and postprocessing should be strictly seperated !

This means that you first save the material (including commercials and all the other junk you'll later want to get rid of) in almost lossless compression to your hard drive, and afterwards you deal with the task of processing and converting it to its final format.

(http://www.doom9.org/capture/preface.html)

Filtering please look into the "Wilbert Part", denoising during recording worked for me, even if it may be not recommended...

Originally posted by ^^-+I4004+-^^

i think many would argue on the benefits/disadvantages of vbr-mp3
instead of cbr,but that's the listeners choice after all,and i'm not
to much into that but let me just say that cbr at 192kbit sounds pretty fine to me.....(ie. cbr is high-quality too....)
but ok,it's a "small excursion"...hehe

I just make ogg vorbis now, I never got these vbr / avi probs but it is true we should mention it, the cbr thing is in I think.

Originally posted by ^^-+I4004+-^^

> But if you want to play your videos on your standalone player, DivX will not help you, because the standalone cannot playback mpeg4 (DivX).

and this

>(A new generation of players is just emerging that play DivX.)


seems a bit contradictory ;i would prefer just the
last statement,with
an additional note that one should aim to make such divx files
that will look nice on both emerging divx players and PC's....
(ie. to aim for higher resolutions,makin it "16" compatible etc.)
although only very few people have these players now....
[this is not so important anyhow,divx players have miles to
go before they can stack up to PS versatility]

Not very important IMO, it is stated that normal DVD Standalones wont play divx, users that want to view it without PC should stick to SVCD or better DVD. This is the clear statement of these words. Every experienced user knows how to play MPEG4 with the new generation...

-> 384 * 288 is no good idea if you want to create a video archive on CD, it is the worst way to cap (apart from 160*120 or such things... ) Thats why I dont recommend to use filters. I had this discussion with Mijo in the past. The quality is bad, why waste time using and testing filters, you can do if you like.

-> The hardware stuff should be mostly in the FAQ, not in the guide I think.

Originally posted by ^^-+I4004+-^^

[preparing]
>Audio -> Compression -> in the dropdown box labeled 'name' you should choose CD-quality.

if one is capturing mono VHS,then this is not good choice;
mono VHS can't go above 16khz (not in it's wildest dreams)
so capping it at 44khz will only capture much more hiss....
i reccommend 32khz/16bit mono sound for mono VHS sources...
(or ; don't capture the hiss....mp3 doesn't like it either...)

I dont have one tape with mono sound...but if you are happy we can add this.

Originally posted by ^^-+I4004+-^^

>Video -> turn off Overlay and Preview using VFW drivers, with BT8x8 chips.

if you turn off both,how will you see the image?
preview should be on,and overlay not,as one cannot capture full-pal on VFW if overlay is on.....
if there are drops,THEN consider turning the preview off too...
(first step to troubleshoot framedrops)

Why should you see the image ? There is no need to. And the risk of drops is big, so turn it off, turn it off.

Originally posted by ^^-+I4004+-^^

>Set the framerate (PAL) to 25, set the buffers as shown in the screenshot below, and activate "Lock video stream to audio".

always capping without this ticked,and always fine
sync on VFW....more research is needed to see what it does
to VFW and what to WDM capturing....

Originally posted by kempodragon

Regarding "Lock video stream to audio stream", Avery Lee specifically states not to use it for normal capturing. It is only used for compatability mode. I use "Adjust video clock dynamically to audio clock" and have never had any synch problems. Also, for those people who don't have RAID, it should be mentioned that a dedicated hard drive should be used. I watched my resolution capability jump from 352x480 to 720x480 while CPU usage dropped as much as 50% just by switching from my system drive to a separate hard drive (I don't know how well a dedicated PARTITION would work.)

I did not know this so far, I always thought by myself: This option seems to keep it in sync, so turn it on, turn it on, so I had turned on both options but no problems doing this. Should it be changed in the guide ?

-> Huffyuv: could be added.

-> MJPEG: Sorry, Did not get what you meant

-> NR, Postprocessing: Please look above.

-> green line: I often had it and used it to avoid heavy drops, thought it was clearly said in the guide ?

Originally posted by ^^-+I4004+-^^

>Setting up Vertical Reduction
Video -> Vertical Reduction -> 2:1 Linear (smoother picture but less CPU intensive) or 2:1 Cubic (sharper)

if cpu can't take it,you might as well capture at 384x576
and do vertical2:1 afterwards.....

This ugly capturing method was integrated to increase a little bit the quality of 1/4 PAL caps but still have these small files. You can do everything afterwars, also resize into 768* 64 if you like.

Originally posted by ^^-+I4004+-^^

ps.lol-is it detailed enough?

Was my posting detailed enough ?

Another suggestions I got via E Mail:

BTW, these are the settings for NTSC capture
Due to some minor bug in VDub, 29.97 FPS cannot be set
The capture will be at 29.971 FPS and AVI2SVCD will reject the file
The FPS *MUST* be set to 29.9697 FPS to work properly

Should be added for all the NTSC guys (if it is true, I cannot check it)

Thats all folk, zhink it is time to retire, hope you see some information in my words.

Good Night everybody

[^^-+I4004+-^^]

>We need NTSC capping options explained (who wants to add this part ?)

framerate is 29,97,resolution is 640x480 (squarepixel)
and 720x480 (for ccir601 ie. mpeg2 ready)
( as avery speaks;
It’s best to capture at even divisions of the source frame rate. For NTSC, the highest frame rate you can get is exactly 29.97 fps – if you want to capture all frames, use exactly this value. It’s on the quick menu, incidentally.
NTSC video runs at 59.94 fields per second, but these are half-frames and two of them interleave together to form a full frame. Capturing video with a vertical resolution of 480 – 640x480, for example – at a frame rate of 29.97 fps will get all the fields. )

this is probably enough
[regarding the avi2svcd "issue",VDub can capture with
xx.xxx precision ,but if avi2svcd reqiures xx.xxxX precison,then
it's his problem so to speak.....i should think that CCE and tmpgenc
"eat" vdub's 29,97"1" (hehe) just fine....any americans here?]


>summary (or point one out) about advantages and disadvantages of different rezising methods

a while ago in vdub forum.....[here,i have it in a .txt file..heh
IE saving troubles...see if u can find it (saving my online time,writing offline now)
"Doom9's Forum > DivX > VirtualDub > Difference between Resize filter mods? "
seems ok to me.....]

>"FieldDeinterlace(full=false,threshold=15,dthreshold=9,blend=false)" via Avisynth.

my parallel tests proved "smoothdeinterlacer" to be much better....
(and i mean easy to see....i run both with (almost) default settings......
offcourse fielddeinterlace(blend=false) and smoothdeinterlace() )

>Thats why IMO the VDub way should remain in the guide. But we should add the Avisynth thing for "experienced user".

or make two versions of post-processing guide;vdub and avs one : i tell you , avs MUST be
forced (hehe)

>I usually made 1 CD Divx, horrible ?

and it is...(hehe)

>i mean perhaps we could focus more on filter usage etc and regard the actual encoding process as something people should already know when reading the guide...

couldn't agree more; there are already enough encoding guides....
(there are some "funny" concepts,but i have already written how i do
my NDub.....hehe)

>We tried to explain that capturing and postprocessing should be strictly seperated

i was more geared up the concept of COMPLETELY separating
capture from processing (like 1:capturing....blah,blah
2.post-process..blah,blah in two separate guides)
that would look clearer.....step by step.....
1:capturing guide
2:vdub post process (as we must...hehe)
3:avs post process (like 10x longer because of scripts..hehe)
4:encoding->see d9 guides on encoding...

> denoising during recording worked for me, even if it may be not recommended...

compared 2 versionsne on-the-fly NR'ed and other in post-process?
(no,don't look at me,i didn't...heh)
( obviously, same question to bb )

>384 * 288 is no good idea if you want to create a
video archive on CD

i didn't said it's a good idea,but previous to my hires capturing i did lores capture with erazor3 (still use it sometimes.looks MUCH better than hires bt capture resized to lores)
i think you did too (huh?) as i find some rather "compromising" posts
on that issue.....
my experience with hires ( now i even do 768x576 divx3 ) suggests that
filtering is more required for lores and some of the reasons i already said.....
(like getting the zero noise in still scenes but at the expense of some ghosting in faster scenes etc. )
some of us like to save space.....768x576 divx3 (by now you all know
how i feel about resizing the video i appreciate ; none of that for me...) has no place (or space..hehe) for savers.....but 382x288 can go quite lo on the bitrate...with proper filtering.......
( as you already have 384x288 for proposed resolution )
if you like,i'll provide you with some screenshots to prove
it.....guide shouldn't state that "384x288 is sh*t so don't bother with filtering"
for all that i'm concerned,you can throw it out completely(throw
lores from the guide),but in my eyes lores still needs filtering

>I dont have one tape with mono sound

so all of your talk-shows are stereo too?
(hehe)

>Why should you see the image ? There is no need to. And the risk of drops is big, so turn it off, turn it off.

i like to know something is being captured (inspite of the numbers
in capture panel).....no,i get no drops because of this
(highly tuned intel board...hehe)

>Should it be changed in the guide ?

hmm,hard to say; we should split the jobs ;
one should capture 60min of "locked" and 60min
of "unlocked" (60 min to see if the sync is preserved)
on VFW (i might do that one)
and the other(s) should try same on WDM (VFW is enough for
me,thanks...hehe)
and then make definitive decision (and tell some tale possibly...)

>MJPEG: Sorry, Did not get what you meant

on the mjpeg settings,"subsampling" of "4:1:1" works as well
as "4:2:2" but decreases the bitrate ,i like the bitrate as low
as it can get while capturing (ie. it's free (you don't have to pay to tick it) so why not save some bitrate )

>NR, Postprocessing: Please look above

i'm looking above and below,still i wonder...heh

>green line: I often had it and used it to avoid heavy drops, thought it was clearly said in the guide

i think you said something like "people often have this green line"...
here:
"When capturing from analog sources, you often see a colored (green most of the time) line on the bottom of the picture. "

so just say it:" I often have green line "....
(or the translation was bit off?)
i see it as one of the ATI quirks,and never experienced it myself...

>This ugly capturing method was integrated to increase a little bit the quality of 1/4 PAL caps but still have these small files. You can do everything afterwars, also resize into 768* 64 if you like.

hmmm?
and you should state that vertical reduction can be acomplished
afterwards....OR horizontal stretch if it'll look better than
1/4PAL (and probably will)
(this is again the issue of on-the-fly processing etc.)
yes,the bitrate will be higher in that case
(something simillar to capturing directly to svcd res. but for non-svcd purposes...)


oups,another biggie........

one more thing:i think "capture-karten und AR für dummies"
deserves translation (my german dictionary dates back to
60's so...) to english;most of it is pretty good,although in the end
( something like "typical scenarios samples","Beispiel 1" )guy got somewhat sideways with the concept of cropping first and doing some heavy calculus aftterwards to correct for it.... instead of simply RESIZING to 640x480 first
and crop (or better (i would say) avs letterbox ) afterwards....seems like wilbert forgot "letterbox" too,as i saw "addborders" though even
rudniak-gould said letterbox is faster and better for removing junk
on top and bottom

if someone has a will,let me know so i can add that part where
there are no AR doubts on resizing and AR is preserved perfectly...
( this would be an addition to the document,original wouldn't be touched )



nighty,night

/ivo

[Wilbert]

>green line: I often had it and used it to avoid heavy drops, thought it was clearly said in the guide

i think you said something like "people often have this green line"...
here:
"When capturing from analog sources, you often see a colored (green most of the time) line on the bottom of the picture."

so just say it:" I often have green line "....
(or the translation was bit off?)
i see it as one of the ATI quirks,and never experienced it myself...

Do you think it is a problem of the videocard? A while ago, when I still had a TNT2, I always had to capture at 704x576 and always saw ten lines of garbage at the bottom of the clip. Nowadays I'm using a Geforce 4, but I can't remember if it matters whether capping to 704x576 or 720x576. Using the latter resolution, I didn't have garbage.

seems like wilbert forgot "letterbox" too,as i saw "addborders" though even rudniak-gould said letterbox is faster and better for removing junk on top and bottom

Yeah, I never use letterbox. I will change it ...

>We tried to explain that capturing and postprocessing should be strictly seperated

i was more geared up the concept of COMPLETELY separating capture from processing (like 1:capturing....blah,blah
2.post-process..blah,blah in two separate guides)
that would look clearer.....step by step.....
1:capturing guide
2:vdub post process (as we must...hehe)
3:avs post process (like 10x longer because of scripts..hehe)
4:encoding->see d9 guides on encoding...

I agree, sounds like a good setup.

[regarding the avi2svcd "issue",VDub can capture with xx.xxx precision ,but if avi2svcd reqiures xx.xxxX precison,then it's his problem so to speak.....i should think that CCE and tmpgenc "eat" vdub's 29,97"1" (hehe) just fine....any americans here?]

I never use avi2svcd, but for CCE and TMPGEnc it doesn't matter whether the framerate is exactly 25 fps. Since I always check "Lock video stream to audio stream" and got a few dropped frames, my framerate is always a bit below 25 fps.

[BaronVlad]

Maybe we should make the guide open source and join in a development team at sourceforge ?

I will get a copy of the guide and talk to steVe how we can update the desierd things and integrate (via Link? or direct?) Wilberts avisynth scripts

[killingspree]

hey
wow i've spent about half an hour reading through all the stuff above...
just a few things:
a) i didn't say we'd leave out the encoding part completely. just guide the newbies to the point where they end up with a file they can load into gknot and then let them use gknot as they are used to... anybody not knowing how to use gknot probably should learn it first anyway. and the avisynth script writing wouldn't be too difficult either. you could almost have a oneline script with
avisource("...")or something like alignsplice if you've got more than one section. resizing and cropping can easily be done in gknot. about eventual filters you have to use in the scripts: we could probably provide cut and paste content.

b) in my eyes all the hardware discussion (hard disk, capture cards, etc should be in the FAQ)

c)about the green line: you can also experience it when using low quality vhs tapes. i had a few that have been recorded with my old VCR that had been breaking apart. the tapes could actually only be properly played in this one VCR. before throwing it apart i also captured the tapes and i frequently had these green lineson the bottom. i tried it on both an ati and a geforce 4 card, same result. ended cropping it away (:

d) about updating, i think we should decide wether to creat a seperate html page or rather include it on an existing on a case by case basis. i would volunteer to merge all the add ons corrections (looks like there's going to be quite a few of them) together to a new (version 2 or rather 1.2) :-P guide. i don't think we can bother doom9 with this work. i'll have to get my hands on the latest most actualy version as doom9 has changed a few things after the guide went online. shouldn't be a problem though.

e) a guy has mentioned the logoaway filter. i have actually never used it but i do think it would be a good idea to add it in someway (probably the filters section if one ever comes to exist - i believe it would be a good idea) to the guide. perhaps somebody knows a page where the usage of this filter is explained or perhaps somebody has knowledge and experience in using it so he/she could write a small section.

ok that should be it...

@bvlad: opensource ... well i guess it is already :-P but i don't believe it would work in a sourceforge way :-P

regards
steVe
PS: i believe this is post # 500 (:

[Wilbert]

So, you don't agree to make a separate Vdub postprocessing and AVS postprocessing sections, like Ivo proposed? We didn't mean that a capper has to do both, but that he can choose between Vdub postproc. (newbie) or AVS postproc. (more advanced). Related:

about eventual filters you have to use in the scripts: we could probably provide cut and paste content.

If someone is new to all of this avs stuff, he won't learn anything from it by copying example scripts (I mean he must learn AviSynth + plugins first and then come back). Remember the faq mustn't only explain how to do things, but more important why and the reader has to understand that.

e) a guy has mentioned the logoaway filter. i have actually never used it but i do think it would be a good idea to add it in someway (probably the filters section if one ever comes to exist - i believe it would be a good idea) to the guide. perhaps somebody knows a page where the usage of this filter is explained or perhaps somebody has knowledge and experience in using it so he/she could write a small section.

I know how to use that (both in vdub and AviSynth). I agree to add something about this in the guide, but as optional. The reason is that (imo) in case that the logo is in the picture itself, it is not worth to try to remove it because the results is ugly. You only get nice results if that logo is most of the time (or better always) located in a black area.

>i mean perhaps we could focus more on filter usage etc

I think it is good to mention some good filters (including advantages/disadvantages). But it is not good to explain them in detail, and claim this filterchain is the best, etc. Besides that it depends on the amount of noise, how long to encoding time must take, etc. If we are one year ahead there will be faster/better filters anyway.

[kempodragon]

I use only one AviSynth filter with any regularity for processing my vidcaps. With out a doubt, IMHO, the best deinterlacer/IVTC'er is Decomb. This filter works wonders on the majority of stuff I've recorded. Generally, I use filters sparingly, since over-filtering can make a video worse. Instead, you should try for the cleanest capture you can. I haven't done much VHS capping, mainly because my VCR only has composite output and I prefer capturing with S-video. Still, I may take a crack at it, in order to see what works best.