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 (http://www.avisynth.org/index.php?page=ConvertingAnalogCaptures_to_XviD%2FSVCD). 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 :D

@Wilbert:

Originally posted by Wilbert

1) deinterlacing: how?

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

:eek: You are right...thats strange, I dont know if you know the German guide: http://212.223.15.244/extern_guides/CaptureGuide/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 (http://www.avisynth.org/index.php?page=ConvertingAnalogCaptures_to_XviD%2FSVCD). 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 :D .

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...:scared:

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 :D

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 :D . 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...:cool:

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...:D ) 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 ? :confused:

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 ? :cool: :D

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 versions:one 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]

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

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.

[^^-+I4004+-^^]

>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.


probably some cards (ati? never saw it on bt or erazor)
think of this garbage on the bottom as a noise and if
there's a noise they "hide" it with solid green....

btvfw driver hides noise with solid blue,btwincap hides it with
solid green (that's how i connected these two...)
but bt NEVER hides only few lines on the bottom ; if it sees noise
it hides the complete screen when noise in image
(overall) exceedes some treshold....(vfw driver has lower treshold than
btwincap,ie. you'll see more noise there until driver shuts-off the image and converts the screen to solid green)

so i never saw this with bt8x8 (as it's not triggered by only
few lines of noise on bottom of the screen...it's drivers can only
blank (fill complete screen with blue or green) if there's too much of noise
all round the image)

VHS has distinctive "head switching" noise on the bottom
(looks like succesive lines are not aligned...some get sideways..aslo
seems like something's missing...and it is;
this is the moment when one head is turned off and other begins to
scan the tape...cannot be seamless....)
and tv transmission has none of this but usually some blank
black space on the bottom
(sometimes only 1,5 line,sometimes more...
you can exactly see that 1 field ends on half of the screen
if you load this to image viewer,and blow it a bit;there's one
completely blank line (black line) and one that ends on the half the screen...interesting...huh?)

if you capture VHS you MUST see that garbage on the bottom (or this
"green line" that hides it) otherwise you're not capturing complete
video image .....576-1,5 lines....most of time all are used
(that's why we love PAL,right?hehe)

vlad,throw this one in too...(hehe)

[BaronVlad]

Ok, much to read, much to do.

steVe said, that the hardware stuff should be mostly in the FAQ, that is exactly my opinion, a guide should first describe how to do something, for me it is very important to show everybody, how to do captures, not only the advanced users that know all these things already. So the guide should show hardware related thinks on the surface (where it is important for the setup, i.g. bt8*8 <-> philipps), detailed things should be in the FAQ. Somebody please look into the FAQ (there is a short sentence about hardware linking to Scuba) If that is not enough or if there is something that has to be added, please drop a few lines ready to be inserted into the FAQ and I will do it.

But I agree, we also have to give some ideas to the advanced users. So, here is my suggestion for the new structure:

The guide will be divided into 2 main parts.

PART ONE (Capturing):


1. Preface / Basics
optimizing your system / additional software needed

2. Preparing the capture
general settings
extra settings:
384*288 (1/4 PAL) or direct VCD at 352*288
384*576 with vertical resize ("1/2 PAL")
7xx*576 (Full PAL) or direct SVCD at 480*576

3. Capturing

This part is alreday online, some minor bugfixes can be done (green line with VHS only, NR not with Huffyuv, the lock video to audio stream thing, NTSC should be added (see above)

PART TWO (Postprocessing):

We should have different methods in it:

1. Using VDub (Important for noobs, remember: everybody should end up with a watchable movie in the end)
cutting out commercials
Using Filters (Explaining how to add filters with a sample as it is done in the German guide already, could be "only" translated and bugfixed, which filters should be added -> Deinterlacing, Resizing and the other stuff, for detailed information linked to discussions about different methods in the forum)
Audio and video compression
frameserving (for the one who wants to do this)

2. Using GKnot (Some words about the differences between DVD and avi encoding with GKnot and the a Link to doom9s guides)

3. Using Avisynth (best way for advanced users)
Wilberts part, explaination how scripts work, how to add the plugins, do filtering...
Short summarry of how to do the encoding with the following program (MPEG4 via VDub Mod can be linked to my part above, think the mpeg2 stuff can be linked to doom9s guides.

After that we can have some Addons when we want to, i.g.:

audio problems
"high quality sound" (vbr mp3/ogg)
improving playback quality
(more to come)

Appendix


These are my thoughts, please let me know what you think.

I need your help,

I would be glad if steVe could do the bugfixes and translate and modify the VDub part.

Wilbert already writes the Avisynth Guide, I would be very happy to be allowed to integrate this into our little guide.

ivo, it would be nice, if you could look into the hardware stuff (FAQ) and give me a suggestion.

Who wants to do the GKnot part ? Shouldnt be much, but I am sorry, I dont have so much time to do all this, cause university starts and I have to hurry up a bit with my "real life"

;)

BTW: Little Update in the FAQ yesterday (thanks Mijo)

[killingspree]

Originally posted by BaronVlad

I would be glad if steVe could do the bugfixes and translate and modify the VDub part.

i sure can do this as long as their's no specific (expecially short) deadline. i'm going to be away large parts of the upcoming weeks and will not be able to do much more than answer a few PMs/mails and probably have a short look at the doom9 news.
still if you mail the bugfixes to me i'll try to incorporate everything as fast as i can.
@bvlad: i think the vdub part that was included in your analoque guide is already translated. correct me if i'm wrong. if there's some parts missing (which i don't hope as i actually tested all the links etc and compared the two folders) please tell me and i'll translate them with highest priority!
i think this is the part: http://www.doom9.org/capture/postprocessing.html

regarding all the changes i completely agree with BaronVlad

regards
steVe

[Wilbert]

These are my thoughts, please let me know what you think.

I agree!

Wilbert already writes the Avisynth Guide, I would be very happy to be allowed to integrate this into our little guide.

I will give you a first draft on Monday, and we can discuss it then.

Who wants to do the GKnot part ? Shouldnt be much, but I am sorry, I dont have so much time to do all this, cause university starts and I have to hurry up a bit with my "real life"
If no one else wants to do this, I can do it. But it will take much time. The main problem is that I don't have internet at home, so I have to ask other people for the GKnot software. And I have to practice a bit because I never used GKnot for this :)

[BaronVlad]

That sounds quite good, thank you very much for your help.

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

I will ask Karl, whether it is ok, if we translate his aspect ratio for dummies guide, as it is very important to understand all these things. Any volunteer to do the translation ?

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

As we have started an open discussion, I post my Bugfix thoughts here for steVe:

We leave the Preface as it is, changes to be made will take effect, when the rest is ready.

optimizing your system / additional software needed as it is

2. Preparing the capture
- Audio -> Compression. I got a mail with the hint to use the MS ADPCM at 44,1 KHz to reduce the audio size to 1/4 of before, maybe we could add this as a little hint (didnt check this out by now.
- "Video -> turn off Overlay and Preview" change to "Video -> turn off Overlay and activate Preview or maybe deactivate both to save CPU time"
- Capture -> Settings:
Add the NTSC Settings with Screenie (if possible):
~something like this: "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"
- "Lock video stream to audio stream" add: Do this only, if you capture with compatibility mode, no need to this in normal captures

extra settings:
- In all resolution regarding green line:
~Something like that (you are free to choose the find the right expression instead of my bad English): If you capture from a tape, you normally should see an ungly line at the bottom (i.g. green or pink) If you dont see this line you may not have the correct resolution (the whole picture). To avoid dropped frames you can try to crop some pixel at the bottom (i.g. 286 instead of 288 or something similiar)
- Huffyuv: Add the comment that we should start with "Predict median (best)" and that we can go beyond if we get problems.
- Noise reduction:
add the comment, that NR should only be used when capping MJPEG not when using Huffyuv because of loosing information.

This is the End of steVes part one.

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

Postprocessing using VDub:

Lets have a look into the translation of the German part. Should be ok (if you have the Deinterlacing and resizing stuff in it)

But we should add, that the "right" resolution is 768 * 576 (thats PAL, what should we do with NTSC ??? The same ? :stupid: ) and you have to correct the resolution, if you capped with 720 or 704 * 576

After a Deinterlacing sample add a link to Lukes Guides (see Capture FAQ for details)
Also color correction should be added, if you dont want to go into details you can also find this in Lukes Guides.
After the resize options explained with a sample link into the following discussion:
http://forum.doom9.org/showthread.php?s=&threadid=42274 (more suggestions welcome)

Compression: Correct the calculation (100 instead of 1024 when using DivX). delete the Excel sheet thing and add a recommendation for GKnot

Thats all for steVe now, I think, and it is enough

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

@Wilbert: I am looking forward to see you Avisynth part :)

Regarding GKnot: That should be no big thing: to load more than one avi into GKnot (i.g. segmented capture as recommended always) you have to use a little avs with segmentedavisource. Remember that you have to delete the last little file when capturing huffyuv, no need to do this with mjpeg, dont ask me why.

When done, just load this avs with GKnot, do your settings -> doom9s guides.

I am happy to see such a great effort, starting to work with GKnot just for this little guide, thank you.

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

I am sure, I forgot something, please add.

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

We just have to wait for ivos suggestions, I think...


Thanks for your time ;)

[Ookami]

IMO, the guide should not cover too much, because it will only drive the newbies away.

For instance someone who just wants to capture a few TV shows in the month and make LQ encodings, a discussion about the NTSC->PAL conversion problem is way over the head and interest.

I always though that you though the same way, Tim?

-Full PAL etc.

This was discussed more than once. As for the different full PAL res. of the various card (704x576 vs. 720x576 etc.) Karl has made some nice explanations about that one, you can ask Karl about it to do it for the guide.

-Resizing algos:

http://forum.doom9.org/showthread.php?s=&threadid=33290&perpage=20&highlight=resizing&pagenumber=2

-Deinterlacing

IMO, you could just link to the FAQ and Manonos new doc (when it's out).


>Audio -> Compression. I got a mail with the hint to use the MS ADPCM at 44,1 KHz to reduce the audio size to 1/4 of before, maybe we could add this as a little hint (didnt check this out by now.

Great God! No! ADPCM is lossy! How about encoding to WMA or MP3 to have even less audio size? ;) IMO, the audio is the least problem, especially if you capture with Huffyuv or Loco :) .

>If you capture from a tape, you normally should see an ungly line at the bottom (i.g. green or pink

Totally unecessary. It depends on with what you capture anyway. Not to mention that I've captured from live TV with headswitching noise because certain TV station even send *cough* SVHS material *cough* through the air...

>add the comment, that NR should only be used when capping MJPEG not when using Huffyuv because of loosing information.

? Now, that's really illogical, captain! NR is more efficient if you have MORE of the original information avalaible! So, this was the main reason why I always said that devices like the DC 10 etc. are in a minus when you want to postprocess your video with filters etc. NR depends on the taste of the user and the end format. If you encode to a crappy VCD then it's mostly overkill to do NR at all (want to blur your lo res picture even more?), but even this is debatable and depends on the observer.

More comments when I read more of this...

Cheers,

Mijo.

[Wilbert]

Just a few random comments:

But we should add, that the "right" resolution is 768 * 576 (thats PAL, what should we do with NTSC ??? The same ?) and you have to correct the resolution, if you capped with 720 or 704 * 576

The right resolutions are (corrected for the ITU bla bla standard) given in (1) and (2):

1) hx576 with h=720*59/54 = 786.7 (PAL), which implies that capping at 768x576 still needs correcting. The problem is of course that you can't capture at 786.7x576 :)
2) hx480 with h=720*10/11 = 654.5 (NTSC), which implies that capping at 640x480 still needs correcting.
3) capturing at 704x576 (AR =1.3354) => resize to 4x3. Note 704*59/54/576=1.3354.
4) capturing at 720x480 (AR =1.3657) => resize to "not exactly 4x3".
5) NTSC similar comments, regarding (3) and (4).

Also color correction should be added, if you dont want to go into details you can also find this in Lukes Guides.
Maybe someone knows this. Luke use the Histogram in Virtualdub to correct the brightness and contrast. If I check histograms in one of the tabs, nothing happens ?

When done, just load this avs with GKnot, do your settings -> doom9s guides.
Yes, it's not much work.

-Deinterlacing
IMO, you could just link to the FAQ and Manonos new doc (when it's out).
Personally I wouldn't do just linking. You will scare all newbies away. Don't get me wrong, these guides are very good. But if you are new to all of this stuff, I think that the way Luke explained it in his guide is far more comprehensible. Besides these docs (FAQ and Manonos new doc) consider only AviSynth deinterlacing.

[BaronVlad]

Hmmpf...

steVe, please be sure to think about Mijos statement above.

If you like, then add something with the greeeeeeeen line, otherwise just delete the sentence and let them all run into this trap :D

@Mijo: I also think that the guide shouldnt cover to much for the newbies, cause of that we have the simple VDub way and will not change so much (only some bugfixes) to be sure, that EVERYBODY is able to make (good) captures with this guide, i sent Karl a PM regarding the translation and will look into it / ask him for this NTSC stuff.

Think it is time to think of something else than capturing now, my brain is empty as you see above.

EDIT: seems that Wilbert an me started writing the same time, but he was faster. It is better to have a clear describtion in the guide, but for these things we need somebody to write this, that is alot of work and if we have an own part, we should integrate it as "optional" to keep the guide clean and short and not to scare the noobs, cause not everybody does it all the time.

I am sure, steVe does his job very well, including the resolution thing in some words that evrybody is able to understand :D

I am not able to get one word into my head anymore. :stupid:

[killingspree]

hi
of course i'm going to regard it... i think we might mention the green lines somewhere in brackets (you might see a few ... if you do you can crop them away...)

unfortunately i still have not recieved the updated guide from doom9 although i've droped him a PM this morning. so as long as i do not have this new guide, editing doesn't make any since IMHO

still some very good thoughts in the above posts (:

regards
steVe

edit: damn must we always be posting at the same time (: well i'll see what i can do... i think we should get it very well structured. so that the newbies just have to follow the destinct line through the guide and the advanced user have to loop trough a few links to get the detailed information etc. but in order to do the structuring i'll first need a full list of contents... best would be in cronological order... perhaps i'll do a post tomorrow listing the current content and will add the necessary things as they come along in this thread! what do you think about that?

[BaronVlad]

Originally posted by killingspree
what do you think about that?

Great,

I am away a bit to clean up my room now...:scared:

[killingspree]

just wanted to say that i got the guide from doom9... the editing can begin (:

steVe

[killingspree]

ok well, as promised i'll have the table of contents here so we can sort out how we are going to part the guide etc... i'll also indicate here what changes have been done already: the guide i'm handling now is the exact same version as published online

1. Preface / Basics

translated Dr. karl's link (:
optimizing your system / additional software needed
we'll leave those "as is" as baronvlad said above

2. Preparing the capture
[i] audio: bvlad said i should change it, ookami said i shouldn't because it is lossy (MS ADPCM at 44,1 KHz) :confused:
video: changed the overlay & preview off to just overlay off
i also added all to other stuff bvlad wrote in his thread above. a zip file with the pages that have been changed is attached to the end of the post!

general settings
extra settings:
384*288 (1/4 PAL) or direct VCD at 352*288
384*576 with vertical resize ("1/2 PAL")
7xx*576 (Full PAL) or direct SVCD at 480*576

about the green line. i somehow don't know what i should write now?? i chose the "you might see" version: [update:]i now used the 'version' wilbert used below with a little add on from myself, as the formulation sounds way superior (:

Capturing from VHS tape you will ALWAYS see few lines on the bottom that a) look weird (looks like they don't belong there) and have some noise... or
b) have same color ( green or pink) in a case when capture driver tries to hide this "headswitching noise" so you don't see it.
If you don't see anything of this from VHS source,better check your input resolution,as you MUST see these if you're capturing complete signal (480 lines for NTSC and 576 for PAL),funny,but something is wrong if you DON'T see these lines from VHS. The lines (or greens field) will be treated in the Post-Processing section of this guide. If your computer drops frames during capture you can also try to cut these few lines off when capturing.

changed HuffYUV and NR as advised above. still again i'm not sure if this is what you guys want. (especially regarding Ookamis post) i've added that NR should only be used before capturing if using MJPEG codec, otherwise one can also do this afterwards!

3. Capturing

4. Postprocessing the video
cutting out commercials

5. Audio and video compression
ok, i think i've corrected the 1000/1024 'error' when calculating the bitrate, see quote below. somebody please check this! oh and one more thing: when calculating the audio bitrate you still calculate with 1024 don't you?
Therefore take 636 MB x 1000 gives Kilobyte x 8 gives Kilobit. That is the space
available on your CD. (636 x 1000 x 8 = 5210112 Kilobit). Now calculate kilobit
per second (5210112 / 90min. / 60sec. = 964).
frameserving

6. Add-ons
audio problems
high quality sound (vbr mp3/ogg)
improving playback quality

Appendix


ok... sorry i know this message is incomplete, but i don't have enough time to correct the other things atm. i'll probably do it tonight!
one more problem (question): where should i put the resolution thingy? rather on each page (full, 1/2 and 1/4 PAL) or somewhere further up in the beginning?

steVe
PS: i'll attach the files later on... (:

[BaronVlad]

Hi steVe,

glad to see editing is on the run.

Regarding audio, please believe Mijo, cause :stupid:

BTW: I got a mail with the hint, that the Link to "Frameserving" at the startpage doesnt work, this is true, could you check what is going on there ?

Thanks.

[^^-+I4004+-^^]

after a day and a half off (really gettin too saturated),and now writing from notepad (power-cut
seems likely...lol! wilbert doesn't have web at home,i
won't have electricity at all (soon)...what are we doing? hehe...anyhow),so excuse any mistakes and formatting issues (i've resized notepad window to
resemble the size of space for posts on forum...let's see if it works...hm..works better with "wordwrap" off..now i copy-paste)

uhhh as i see it's gonna be quite a job,let's see....
you asked about FAQ;
i think that in answer to "3.) Which TV Capture cards are commonly used? "
you linked two misleading documents;
they both point that the ultimate and cheap solution for home capturing are combo-boards , but i disagree :
i have seen the images coming from asus,ati,matrox and
simple bt8x8 card beats all of these....
and bt8x8 cards are even cheaper.....and if in addition bt8x8 card with huffyuv and hires looks better than advc100,need i say more ? ( even though my
hdd is "RIP"(not "rip",but RestsInPeace),i will probably get the samples again and
publish that on my web....after that,you might as well remove these 2 links that states that combo boards
are better than the rest.....and link that web of mine...hehe )

also;i think the start of "21.) What can I do against dropframes? " is a bit off too ;
dropped frames ARE a disease that NEEDS to be cured
(it's good that you linked the cure too (vdsync) )
also
"If you have so many dropped frames that you will notice them (the video "stutters") "

EVERY dropped frame is visible; (see how much drops
can you tolerate if you capture sports...i should say not too many...),so this sentence is too mild :one
should aim for 0 dropped frames from the beginning...
ie. if the dropped frame (because of a/v sync...these ones are rare,truth) occurs on some fast scene,it's not satisfactory to know why did it happen...(when you miss the piece of video )
so :dropped frames are a disease that needs to be cured,and as we know the cure,why should we settle for
less than "0 dropped frames" across complete capture...?
this disease is caused by hardware/drivers out of
specs,but it's a disease anyway....

i don't see other mistakes (although these 2 are not drastic mistakes,but simply my experience on devices
is different (i'll try to provide screenshots as soon as possible hmm..and if possible) and dropped frames
should be avoided :stating that "few dropped frames
doesn't make a difference and they are not a disease that needs to be cured" doesn't help much : just encourage users to be with progs that resample sound
or live with those drops..(i go for first solution...)

now few things form this thread;

on adpcm compression during capture: no,i don't see the need for this....audio bitrate is not the problem anyhow........but if one really needs to go that far to save some small amounts of space,you can mention it....(i doubt there's a need for this )

on "Due to some minor bug in VDub, 29.97 FPS cannot be set The capture will be at 29.971 FPS ", as i said..i
believe avery lee knows EXACTLY what's the framerate of NTSC,and seems like avi2svcd author doesn't
( 29.9697 ? this precision (on vertical deflection) is impossible to achieve
in analog video signal! so NTSC is 29,97 for all that i'm concerned......)
if this is true ALL vdub ntsc capturing that was done with veedub has wrong framerate : i doubt this is the
truth....i see that tmpgenc sees files captured by vdub as "29,97" and accepts them (even though i produced this file on pal input and had dropped quite a few frames)
if no one from usa can confirm this,i say let's just drop it......

>>If you capture from a tape, you normally should see an ungly line at the bottom (i.g. green or pink
>Totally unecessary.

so it's not necessary for people to know why the noise
(and subsequent green line in some cases) appears on
the bottom of the screen ALWAYS when they capture VHS
and sometimes from live-tv?hmmm
regarding the english for this perhaps;

"Capturing from VHS tape you will ALWAYS see few lines on the bottom that a) look weird (looks like they don't belong there) and have some noise...
or
b) have same color ( green or pink) in a case when capture driver tries to hide this "headswitching noise" so you don't see it.
If you don't see anything of this from VHS source,better check your input resolution,as you MUST see these if you're capturing complete signal (480 lines for NTSC and 576 for PAL),funny,but something is wrong if you DON'T see these lines from VHS "
and "see further notes on post-process guides to get rid of it"....etc.

that should make them sleep easier (hehe)

NR issue is occurring again: bb has said that NR will
do good for MJPEG,but it's not so easy : it will also
introduce SOME ghosting (this looks like evaporating of moving objects ) more you NR the more you see of ghosting :and then MJPEG doesn't like this pixelization and you're right where you started from
(or?)....i think NR on this early stage will only cause problems;it'll blur,it'll ghost probably will
result in poorer end result (ie.unsharper image)
and MJPEG will still have "ringing" on sharp edges (like subtitles etc.)
NR will introduce ghosting for huffyuv too...(it's just like introducing NR filter afterwards...only you cannot tweak it to suit image noise best,as you're denoising while capturing ie. you cannot tweak it after you started to capture......)
i say leave it ,but only as a hint... say that it will introduce some blurring too.........
(if everyone would use it,then we will have much more
blurred video....bare in mind that resizers blur too,and that there'll be another NR in post process probably too.....as this on-line NR can't remove all the noise...)
in other words;
NR in VDUB is not that good
NR on-the-fly is not good either....
blurring the image while capturing is wrong....
(it'll be too blurry afterwards because of resizing/codec anyhow...no need to do it deliberately)

>1) hx576 with h=720*59/54 = 786.7 (PAL), which implies that capping at 768x576 still needs correcting

768x576 cannot be corrected for ITU standard,as it doesn't have much to do with it......
720*mpeg2 PAR(59/54) is pretty funny calculus if you ask me..that way you didn't got anything that is related
to square pixel (1:1) of 768x576.......but: 576x1.333(4:3AR)
=768 and the pixels are square so it's good....
it's 768x576 and it's not ccir601 compliant as ccir601
requires non-square pixels....we PC people don't have use for non-square pixels.....we use them only if we aim for DVD compliant mpeg2/mpeg1 video...
(ie. you used 720 as a reference,but it's not a reference for video on PC,but reference for video
on DVD....)
and if you capped with 704 or 720 and aim for perfect
square pixel then you need to do some elaborate resizing to get it prefectly right (this is explained
in derkarl's guide to some extent....a reason more why we should see it in english too...also i regard my simple method as more precise and better and has no
AR error at all...i have mentioned it above)
alternatively ,you can just watch 704x576 with player set to 4:3 and it's good.........(player will compensate)

>If I check histograms in one of the tabs, nothing happens ?

i think it only works for lo-res....in hires video image
overrruns this tab so it's not visible (my explanation anyway...)
complete histogram thing is not defined well enough:
what's an "image with same amounts of black and white"?
rather calibrate your monitor and use your eyes.....
small error can be tweaked with "tweak" of avs anyhow...vdub has filter for adjusting this too
(no,not "levels"..levels is undefined too(and funny for user)...there's a
plugin)
i would skip this issue.......

and a bit about GKnot; i have never used it (and probably never will...don't see real use for it for
.avi....probably because i know my codecs pretty well by now),but i know a story something like this;
"i want everything automated,so i let GK to do all
decisions for me;it does resolution,it does bitrate..i mean if GK says it's good,i say ok....."
after this i saw some 512x384 divx that looked pretty
bad.....(source was 720x576).......
so,if GK will always do such thing,then does he/she need it at all?
i think decision on resolution should be based on different merits;for example,if we know that target for mentioned case was 50min on 700MB,we know (or i know) that you can pack more resolution to cca. 1800
kbit/s (or at least i'm doing it all the time) than mere 512x384........this compressability test is all
wrong if you ask me.....with it you rely on machine
deciding for you;and for noise in analog capture how will it do it?it's always different noise,source etc.
50min on 512x384?ohh,come on....i'm using mpeg4 because it's better than mpeg2,better than SVCD...720x576->512x384 is sh*t most of the time....and worse than SVCD for sure...
(just one example how rookie can be tricked into
making lousy PC video...)

respect

/ivo

[Jukke]

Hi,
Just a quick note on using GKnot on captured material. I use a pretty straight forward procedure on this subject. Capture in 720x576 (PAL) with I-frames only (for cutting purposes) as mpeg2. Cut out unwanted parts if needed with suitable tool, then straight to GKnot and go by the Doom9-guides with the following exceptions:
* Just after the DVD2AVI-project is made, convert the mpa-audio to mp3 cbr 128 with BeSweet and add this to the GKnot-project
* Always set the input as 4:3 PAL (as I live in a PAL-country)

If you use GKnot0.28, let GKnot mux the audio with VDubMod. If you use GKnot0.27 or older, mux the audio separately with VDubMod.

This procedure works like a champ with my AIW Radeon 9000 with its Philips-tuner and captured via MMC8.1

Just my two cents...

[Wilbert]

768x576 cannot be corrected for ITU standard,as it doesn't have much to do with it...... 720*mpeg2 PAR(59/54) is pretty funny calculus if you ask me..that way you didn't got anything that is related to square pixel (1:1) of 768x576.......but: 576x1.333(4:3AR)=768 and the pixels are square so it's good....
Of course if you capture with Huffyuv the pixels are always square, not matter what resolution you capture at. The problem is that your image itself is squeezed.

it's 768x576 and it's not ccir601 compliant as ccir601 requires non-square pixels....we PC people don't have use for non-square pixels.....we use them only if we aim for DVD compliant mpeg2/mpeg1 video... (ie. you used 720 as a reference,but it's not a reference for video on PC,but reference for video on DVD....)
I don't agree with your here. The problem is that if you capture at 768x576 your clip will be squeezed a little bit, and you have to correct for it. But apperently you don't agree with that, and you call the calculations which show that "funny".

A side note. I think it's good not to talk about this ITU stuff, in the vdub newbie section.

[BaronVlad]

hi again,

@Jukke:

Sorry, we are discussing about avi captures (Huffyuv, mjpeg) here, no need to do DVD2AVI...

@all:

I got a mail from Mijo, my thoughts after reading this is:

Let us wait a bit, until Wilbert has a beta version of his Avisynth guide and steVe has a beta of the new guide. Then we discuss about all this again. It is important that we have one version to discuss about, not only a theory

The FAQ will stay the same until we are ready with this guide, Scubas ideas about the hardware are a bit old but good, think we can live with this point.

BTW: I got also a Mail from Karl (Thanks): It is ok to translate the capture aspect ratio thing (there wont be a describtion for NTSC as Karl has no time for this). As the home of this document was videoxone all the time, ich will ask tED66 where to put the translated document . We now need a volunteer to do the translation, he should know all these standards and stuff very good to make sure, that the translation is of the same quality, the original is. (bb, Mijo ? :D )

[killingspree]

Originally posted by BaronVlad


BTW: I got a mail with the hint, that the Link to "Frameserving" at the startpage doesnt work, this is true, could you check what is going on there ?

checked that... the link is working in the version i have on my computer but doesn't work on doom9. somehow i think the page got lost during upload. got to talk about this to doom9 as soon as possible. also there seem to be a problem when using the next button from the 'audio and video compression site'. it directs you right to the appendix. frameserving is completely left out this way ?!? strange as it is not a pure linking error, because i wrote 'appendix' next to the next link (:

anyway, i did some more changes today... look in my post above for details! also i quoted some changes above. please somebody read through them quickly and check for eventual spelling mistakes or errors! thanks

Lets have a look into the translation of the German part. Should be ok (if you have the Deinterlacing and resizing stuff in it)

But we should add, that the "right" resolution is 768 * 576 (thats PAL, what should we do with NTSC ??? The same ? ) and you have to correct the resolution, if you capped with 720 or 704 * 576

Originally posted by BaronVlad

After a Deinterlacing sample add a link to Lukes Guides (see Capture FAQ for details)
Also color correction should be added, if you dont want to go into details you can also find this in Lukes Guides.
After the resize options explained with a sample link into the following discussion:
http://forum.doom9.org/showthread.php?s=&threadid=42274

ok got a few 'problems' here.
a) i've been looking for the deinterlacing part now for quite some time but haven't found it. not in the english guide neither in the german counterpart. :confused: of course i could add something like this, but if there was something i could just copy and paste it would be much more convenient!
b) should i do these color correction thingies too? i mean i've followed luke's guide some time ago when doing my first captures, but it was a while ago and i didn't capture very much lately thus i'd have to read /practice a bit before writing the section (time issue)
c) resizing: again... should i do this? I can but it will take some time...

oh and about the 'true resolution' of PAL/NTSC: you got me :confused: there to (:
steVe

[Wilbert]

@BaronVlad,
What format do you want the guide? html?

But we should add, that the "right" resolution is 768 * 576 (thats PAL, what should we do with NTSC ??? The same ? ) and you have to correct the resolution, if you capped with 720 or 704 * 576
I think it is 640x480 for NTSC.

a) i've been looking for the deinterlacing part now for quite some time but haven't found it.
General talk:
http://www.lukesvideo.com/interlacing.html
http://www.lukesvideo.com/telecining.html

How to deinterlace with vdub filters:
http://www.lukesvideo.com/highresprocess.html

b) should i do these color correction thingies too?
That would be very nice. If that histogram stuff doesn't work, you can download a histogram filter from Donald Graft (http://shelob.mordor.net/dgraft/histogram.html). I guess it works in the same way.

c) resizing: again... should i do this? I can but it will take some time...
Yes, that's not so much work. For the vdub newby guide I suggest not to talk about ITU compliance.

[^^-+I4004+-^^]

Originally posted by Wilbert
Of course if you capture with Huffyuv the pixels are always square, not matter what resolution you capture at. The problem is that your image itself is squeezed.


I don't agree with your here. The problem is that if you capture at 768x576 your clip will be squeezed a little bit, and you have to correct for it. But apperently you don't agree with that, and you call the calculations which show that "funny".

A side note. I think it's good not to talk about this ITU stuff, in the vdub newbie section.

pixel AR is not conditioned by the compressor (huff or
mjpeg) but with the sampling frequency of card/driver...

768x576 looks same as tv image and is not squeezed
(at least not on my tv-out which is square pixel too
it has 768x576,800x600,640x480,so it's square pixel all the way)

why are you correcting the square pixel resolution with the
standard for unsquare mpeg2 pixel?
square pixel doesn't need no correction;576*1,3333=768....
here's a good read for you:it explains how come 720x576 (and 720x480)
fills the complete screen on dvd video (note that PAL is 59/54 and NTSC is 10/11 for mpeg2 raster....)
include that PC always have square pixel on monitor (my tv-out has it too,how bout yours?) and you'll understand why you can't do
720x59/54 to give you anything....
http://www.mir.com/DMG/aspect.html
also,see this page
http://free-st.hinet.hr/ikostic3/video_/video.htm
this is what happens when i changed pixelAR DURING the capture...
note that image on monitor stays within same dimensions,but underlying
image is changing AR...try it on tv-out too....when the image was
stretched (horizontally) the most,it got nearest to the tv image
(you have this image on tv via the astra satellite if you have access
so you can compare tv-out and live tv)
(or elaborate why have you used such calculus?)

also i have already stated tthat ntsc is 640x480 for sqaure pixel
and 720x480 for unsqaure mpeg2 pixel
use 640x480 for PC mpeg4 video,and 720x480 for dvd compliantt video

[BaronVlad]

Thanks for the input again, Wilbert, steVe, could you put this into it ? Thanks.

@ivo: I think we should mention this thread somehow in the guide for the "freaks" that want to think much about AR... but not put all this in the guide, this as Wilbert said, wouold scare the Noobs away. And that would be worst case...:)

[Wilbert]

You are confusing me. You have to convince me more that I'm wrong.

why are you correcting the square pixel resolution with the standard for unsquare mpeg2 pixel?
We are not talking about 59/54 mpeg2 pixel, but we are talking about PAL 59/54 pixel.

From your url:
An image with a standard display aspect ratio of 4:3 (i.e. TV) with 576 lines (i.e. PAL) would thus have:

- 768 square pixels per line, or
- 702+54/59 non-square 59:54 pixels per line

Note that a 720 pixel scanline has thus captured an extra 17+5/59 pixels! (Too bad it doesn't work out to an even 8 per side...) A 720x576 frame is not actually a 4:3 image.
I agree with this. But your broadcasting station is broadcasting 720x576 frames, and not in 4:3. If it isn't, those extra 17+5/59 pixels must be black, or the image on your television itself is slightly stretched (which can be the case, I don't know) to match 720x576.

(or elaborate why have you used such calculus?)
See also
http://www.lurkertech.com/lg/pixelaspect.html
starting from "Wait, How Can That Work?".

[killingspree]

hey
just wanted to tell you guys that i'm leaving for a one week holiday to italy... (might take a little longer too)
if anybody wants to do some work on the guide (see above posts for detail) i've uploaded the complete guide as a zip file...
you can download it
here (http://members.tripod.de/stefanstrobl/download.htm)
please send any changed sites, or additions to this mail adress (steve.a1@a1.net)

cheers
steVe

PS: sorry for the shitty design of the 'page' i just created it VERY quickly because tripod doesn't let you link to downloads directly ):

[^^-+I4004+-^^]

@wilbert
you'll hear from me in PM (this is not the place...
not anymore....)
at the end you'll just confirm who was right..
in this thread (hehe)
or better another thread (for 2 more guys that might gett
interested...hehe)

@all;
such hardware suggestions (links that i mentioned) should be removed from
FAQ.....
users that own few capture devices (and in parallel_like
2 or 3 at same time in one machine) should be reference ;
you have only one device?
you can't say anything and you can't provide decent test...
by now (and with this link) we know more....
see it here;
http://forum.doom9.org/showthread.php?s=&threadid=50927
also,there's no big use for scuba's link either;
he didn't suggest anything but categorized cards in some fashion of his.....
reccomendations are not good;tests ARE!
(few more tests like this and we need no more;
ATI and ASUS compared to some other device (anything with hires capability will do) are what we need now (so ,in conjuction with my
tests, you can draw conclusions )
so if anyone has a will to make few seconds of VHS capture to
2 devices he owns....his efforts would be appreciated
(few last threads show that there's much confusion about hardware still)



also,leave out PAR thing,but just mention that 768x576
is ideal for mpeg4,and 720x576 for dvd mpeg2..
that's enough........
(i wuz just duscussing it with wilbert...nothing that should make
it into guide...this is over their heads by a long shot;i my self
have spent few hours considering it...and it's pure hell!)

thank you gentlemen.....

cheers
/ivo

[Huge]

First, this is a great guide and I've never captured from TV before. I followed it pretty closely and now have the first episode of the new 24 series on my Thinkpad at 720x576 with great quality.

This capture bought up two things I didn't see in the guide. So here's my wish list:


Considerations for capturing wide-screen TV.
How to open all the avi's in TMpeg and encode for DVD
How to compress the audio into AC3


In my case, we'd just need to set the aspect ratio flag in TMpeg, the second I'm not too sure about but I guess you could use an AVISynth script or frameserve from VDub but which you use I don't know. The last one could simply be a note in the BeSweet page that says you can do AC3 too, and then how to mux it in.

[Wilbert]

@wilbert
you'll hear from me in PM (this is not the place...
not anymore....)
at the end you'll just confirm who was right..
in this thread (hehe)
or better another thread (for 2 more guys that might gett interested...hehe)
Haven't read your PM yet, but you are right. I'm very sorry, and a bit embarrassed that I was saying this nonsense. Guess it was the end of the week, and I was tired. I don't know any other reason. What is true however, if you capture at 768x576 you will miss a part of the image. Maybe we can drop this and continue with more usefull stuff.

[Wilbert]

@all,

I've finished the AviSynth part. See
http://www.avisynth.org/index.php?page=ConvertingAnalogCaptures_to_XviD%2FSVCD

Since I still don't know in what format BaronVlad it wants to have, I attached it here as a text file. (I hope I removed most of the Wiki stuff...)

edit: Ok, I will put "only the AviSynth part" in the guide on killingsprees homepage. I hope I can upload it tomorrow.

[BaronVlad]

@Huge: Thanks,

TMPEG: There are some words about frameserving to another application (TMPEG, cce...). Wilbert is working on an Avisynth part (seems to be finished :) ), you can load the scripts into your encoder.

Wide Screen...dont know, if you have ideas please let us know.

ac3 doesnt make much sense IMO cause you dont capture these informations. Why create such an audio ? I think Standalone DVDs also play files with mp2 audio. As always: Correct me if I am wrong since I dont have one.;)

@Wilbert: :scared: I knew that I forgot something...

Nice work !

HTML would be best to add it. Please drop steVe a mail with your part including your suggestions of titles / sections (dont know the right expression in English) for an easy integration.

Thanks a lot.

[Huge]

Originally posted by BaronVlad
@Huge: Thanks,
Wide Screen...dont know, if you have ideas please let us know.

ac3 doesnt make much sense IMO cause you dont capture these informations. Why create such an audio ? I think Standalone DVDs also play files with mp2 audio. As always: Correct me if I am wrong since I dont have one.;)


First one is easy, at least for me. My capture card capture 4:3 even if it's sent a 16:9 movie so the AR is fine when you do the capture. The only thing you need to do when you recompress using TMPeg is to make sure you set the final movie to 16:9 widescreen. This simply adds a flag to the MPEG file and tells the TV to expand it.

AC3 give me better file sizes at higher bitrates... that's all.

[Wilbert]

@Wilbert: I knew that I forgot something...

Nice work !

HTML would be best to add it. Please drop steVe a mail with your part including your suggestions of titles / sections (dont know the right expression in English) for an easy integration.
Steve went to italy. I got the html files of his homepage, and included mine. But for some reason I can't upload them to my webpage yet. I will tell you when that is done.

[Wilbert]

The problem was our university. I splitted them over two zip files:
http://www.geocities.com/wilbertdijkhof/capturenew_041403.zip
http://www.geocities.com/wilbertdijkhof/capturenew_041403_2.zip

I included a changelog.txt with my changes. Things that still aren't done:

- deinterlacing in vdub
- color correction in vdub
- mpeg2 encoding
- gknot stuff
- minor other things I forgot

Maybe Ivo can drop in and change what he wants to change. After that I will include mpeg2 encoding (references to Dooms guides, with some remarks).

[BaronVlad]

Hi Wilbert,

Thanks for your work again ;)

Think we need to change the author in the next versions, BaronVlad may be correct for the first version but not for the ones to come...

On the Avisynth page you had links to the different filters and plugin (i.g. avisource included a link to http://www.avisynth.org/index.php?page=AviSource ) Why did you edit this in the guide version ? IMO the documents could remain on the avisynth server but we could link to them for the users that want additional information. Just a short sentence at the top that you leave doom9.org to avisynth.org when following these links and then -> target_blank.

What do you think about it ?

[Wilbert]

On the Avisynth page you had links to the different filters and plugin (i.g. avisource included a link to http://www.avisynth.org/index.php?page=AviSource ) Why did you edit this in the guide version ?
I didn't remove them. That's how Wiki works. You don't need to define a full url, but just type AviSource for making a new link. Anyway, I will add the links next time.

IMO the documents could remain on the avisynth server but we could link to them for the users that want additional information. Just a short sentence at the top that you leave doom9.org to avisynth.org when following these links and then -> target_blank.
I prefer to have it all in one place. But besides that, at the time of writing, it was not possible for me to add pictures.

[^^-+I4004+-^^]

here's another version of capture guide;
http://free-zd.hinet.hr/ikostic3/

if anyone has any doubts about it(any parts i updated),i'll do my best to prove that i have included FACTS only in this version (all of them based on my experiences),but off course,edit at will.(especially typos or so..hehe)...changelog is extended too..
(i have changed the things that i mention in this thread...no,no big talk on PAR,don't be scared )

/ivo

[Wilbert]

Nice! I will add the links above, the SVCD encoding and some other minor stuff.

[killingspree]

hi
i'm back again for a few hours (i'll be leaving again this evening) i'm just downloading the guides to take a look at them.
i believe that a general changelog for the guide would be great. so everybody can follow the changes that have been made. also this seems to be the only way to really give the appropriate amount of reference to all of the people that contributed to this guide!

regards
steVe

[killingspree]

hi
i'm currently downloading both versions of the guides... unfortunately i will only be at home for a few hours, but i'll see what i can do!

i think to somehow include a changelog would be a great idea to keep track of all the different changes and also to give appropriate reference to all the contributers that have helped (and are still helping) in creating this guide.

regards
steVe

edit: please for further 'changes' do not include the 'images' folder unless you changed something in there (added a pic for example) this will reduce the size of the .zip files by more than 90 percent! thanks

[BaronVlad]

OK guys. Cut.

This guide is NO opensource project. steVe did the translation and he hopefully adds the resize thing, also Wilbert adds the part about Avisynth and GKnot. Thanks for that.

I downloaded "ivos guide" and I dont want anybody to work on a modified version until I think, it is ok ! IMO there are some things that have to be corrected, I will do this.

@steVe and Wilbert: Please use ! Wilberts ! last document to edit your things, and only these things confirmed by me (and Mijo) or are direct translations of the German part, please make also sure that the pictures are in the right directory, didnt work for me from the beginning.

If we dont stick to this procedure, the guide will find its end in a big chaos and will be simply wrong !

I will look into ivos thoughts and will pick the good parts and put them into the guide.

And please no endless discussion about hardware, aspect ratio... anymore. This will also end up in a complete chaos.

Now let us do the things we wanted to, when we are finished, we can have a look at the complete work and think about what has to be done.

And I will confirm whether it will be done or not.

Sorry for these hard words, but it had to be said.;)

[Wilbert]

i think to somehow include a changelog would be a great idea to keep track of all the different changes and also to give appropriate reference to all the contributers that have helped (and are still helping) in creating this guide.
We already have done that! Maybe you can mail me your changes (of a five days back), so that I can add them to the changelog.

@BaronVlad:

I downloaded "ivos guide" and I dont want anybody to work on a modified version until I think, it is ok ! IMO there are some things that have to be corrected, I will do this.
Ok, I will wait for your updates before continuing ...

[killingspree]

all my changes have been posted above...

but my problem is that somehow i've lost track of who is doing what and who's responsible for that. perhaps bvlad can give me a little update on the things that happened in the past 5 days... i am :confused: i have to admit...
(yes i still have to get into usual everyday life routine)

anyway... i'm going to take a look at wilberts version now... regarding IVO's version: i might take a short look at the changes so we can, after they've been (dis)approved by bvlad, include them into the guide...

regards
steVe

[killingspree]

damn it somehow hit submit twice (:
i gotta get some sleep... haven't slept more than 12 hours since saturday.

[Wilbert]

but my problem is that somehow i've lost track of who is doing what and who's responsible for that. perhaps bvlad can give me a little update on the things that happened in the past 5 days... i am i have to admit... (yes i still have to get into usual everyday life routine)
I'm not bvlad, but I can give you a little update. I added my avisynth stuff (after I got your version of the guide from your website), and posted an updated of the guide. After this ivo posted his corrections on my update. My changes (and also ivo's) can be read in the changelog.txt.

[BaronVlad]

Originally posted by killingspree
but my problem is that somehow i've lost track of who is doing what and who's responsible for that. perhaps bvlad can give me a little update on the things that happened in the past 5 days... i am :confused: i have to admit...
(yes i still have to get into usual everyday life routine)


Please refer to Wilberts version. Changes should be done in this version only. There is a changelog included that tells you what has been done (mostly the Avisynth part)


Originally posted by killingspree
anyway... i'm going to take a look at wilberts version now... regarding IVO's version: i might take a short look at the changes so we can, after they've been (dis)approved by bvlad, include them into the guide...


Originally posted by Wilbert
Ok, I will wait for your updates before continuing ...


No need to wait.

@Wilbert: You can continue with the GKnot part and add the explainations for the Avisynth filters like it is in the Wiki document (didnt know this before)

@steVe: We need the resize options explained as it is done in the German original, this includes deinterlacing. After explaining the procedure, please add a link to discussions about different filter / deinterlacer in the forum or similiar documents for the people to help them finding the right filters, I think Mijo mentioned some above.

Regarding ivos suggestions: I will look into these. There should be no problem to add some things after the rest has been done.

[killingspree]

ok thanks for the update...
so i'm going to wait for bvlad to approve the changes IVO made and then add my changes there... i'lll see that i always have the most up to date version of the guide as a zip file on my webspace... i'll probably do two files one for the pictures and the other one for the html files as the pictures won't change as much... (i hope so at least)

just reading through the changlog file (:

steVe

[BaronVlad]

Think the problem is, that we all write our postings the same time, so this might be funny to read for someone that joins us later...:D

@all: Please look into my lst posting above this one. This is the "to-do-list".

In short words:

No need to wait and changes based on the last version of Wilbert

Would be very good, if steVe could at first correct the image folder and put these two versions (text and images, text only) online, so we start with the same version.

Thanks.

[killingspree]

based on the ivo or wilbert guide?...
i can do this in like 5 minutes so it shouldn't be a problem. also i'm updating (or rather adding) my changes to the changelog.txt right now...
yes it always seems that we post our messages exactly at the same time... kind of confusing :-P

steVe

[BaronVlad]

EVERYTHING BASED ON WILBERTS GUIDE.

How we should continue:

1. steVe, please get Wilberts version of the guide, not ivos.
2. steVe, please put it online (image folder corrected) in two versions (text and images / text only)
3. You both please use only this version downloaded from steVes webspace to make sure that changes are done with the same version
4. Wilbert, if you have updates, please send them to steVe, so he can update the file on his server
5. include changes in the changelog
6. Please inform us here, if updates are done.

The suggestions of ivo will follow when I looked into it.

[killingspree]

ok i did the following changes: (didn't edit the changes because of ivo's changes beeing somehow unsure etc)
-fixed broken image links in wilberts part!
-fixed links so one can go from the 'capture' page to any of the three postprocessing parts
- did a placeholder for the missing gknot postprocessing guide...
- put the picturs into the right folder, fixed the links
- updated the changelog... now we're at 1.3? i don't think we should adapt a more complicated version system...

i'm going to upload it in a minute (or 2)... (have to update my html page etc)

steVe

edit: one more thing before i can upload the guide:
a) what is this empty 'x' folder in the zip file? any purpose? or can i remove it?

new: edit2: everything should be acessible in a few minutes... i've uploaded it... oh and yes i'm going to be away until most likely monday again... perhaps i can write a PM or two (or post a few short answers but i do not have a computer at hand where i can edit the guide... please send all changes to my email
oh yea... the page where you can download the version 1.3 guide: http://members.tripod.de/stefanstrobl/download.htm

[Wilbert]

edit: one more thing before i can upload the guide:
a) what is this empty 'x' folder in the zip file? any purpose? or can i remove it?
Yes, you can remove it. That's my fault (I didn't see it in the zip files, so I didn't remove it).

[^^-+I4004+-^^]

i have completely changed the stuff on filtering plus' and minuses as i'm experiencing such results ;lores needs filtering (why shouldn't it,who said it doesn't need filtering? hires needs filtering too,but because downsizing will be applied (anyhow) it needs it less (downsizing serves as a blur filter too)...

saying lores needs no filtering is misleading...confusing too.....unfiltered lores is wasting bitrate same as unfiltered hires....(wasting it on noise)also why should hires need "more" filtering?( it needs more *filters*,that's true,but you have already separated deinterlacing,resizing from the filtering in usual sense (cleaning the image) and that's a good thing )

is this "guideforge"?well i think we should all work together on it,making it better work,discussing potential problems,try to establish things (but with the means of experimenting,experience and so....not because someone said "lores needs no filtering"....that guy is showing lack of experience if he can say that....i can prove this with endless screenshots of before/after filtering...every VHS needs SOME filtering,and after all,this should be universal guide,not just guide for "clean video sources only"....or? )
objective should be the truth (the proven truth)

it has happened that i had pretty lousy sources,so i expect other people did too and therefore accent should be put to filtering (plus and minuses of different techniques).....making it "capture and encoding only" will make people think they always need to do the basic dvd-ripping job (in encoding sense) without filtering,so they'll get end result with lores,and lots of noise everywhere,and probably oversized file...pretty confusing to novice,isn't it?

it's just that i expect noob to love to read about this stuff (as i did when i started) ,and while i agree that PAR is NOT for noob (i don't know if it is for anyone...and why it exists at all...),noob may want to know what is temporal and what spatial smoothing,what denoising does,why it does,what filter works for what,etc.
i think filtering is not something advanced,but a MUST for good deal of analog captures....

no one can do this thing alone,so vlad,i think you should welcome help(sure,check and double check any suggestions): luke's guide did some awesome job,but it wasn't ambitious enough to go for the "real thing" and stayed on cartoons,lores encoding of realmedia and so....(some of the filter chains were pretty weird too),but it was a pioneer job on this subject and still serves as nice reference on many subjects...
this guide is already better in a sense that it aims for much better image quality with less resizing,proper output formats etc.
people in this thread have come forward to help,not to argue about whose copyright it is,and who contributed more...(and no,it' s not "ivo's version"(and it doesn't have plague so everyone should run away from it),but version "mildly updated by ivo"..just another in a way towards Better Guide)

(uhh,am i talking too much or what?)

[strong lang. edited out_there was no need for it...]

/ivo

[Wilbert]

Don't want to say to much about this, because this is a public forum. But I agree with all your points. I thought the aim was for "the best possible analog capture guide", and nothing less.

[BaronVlad]

Everybody calm down, nobody wants this thread to find its end in a flame. So in short words:

I didnt get the point you critisize.

1. I need your help, I didnt reject any help, if I would, I hadnt started this thread.
2. I am glad to see so many good suggestions.
3. But there have to be clear rules, otherwise we get the chaos nobody wants.
4. This rule is, that someone has look at the parts that will be added.
5. I created the German guide with all its mistakes, so IMO it should also be my decision what will be changed, when I see good arguments, I will change many things.
6. steVe did the translation and has a clear list what should be done, think we all agree about the points to be changed.
7. Wilbert created the Avisynth part and will hopefully also write the GKnot part.
8. I did not say with one word, that I dont look at your suggestions, ivo, or that I dont want to have them in the guide, if this is untrue, please show me, where I said this. You have many good suggestions (some strange too) but I want to have a look at it first and then add them (i am working on it right now, including all the thoughts you had), cause they are a direct edit of the original and not an addition like wilberts part or the changes steVe makes.

If we all got these points we will end up with a very good guide, ok ?

If you dont feel better now, fell free to contact me via PM to clear up this misunderstandig that it is obviously.

Thanks.

To the Full PAL, PAR, DAR thing: I had a hard afternoon with Karl aspect ratio for dummies and created some words about it, I set it to Karl, so we hopefully will see a corrected version for noobs and experienced users in the near future.

[Ookami]

First let me say, that this whole talk about "the absolute truth" is wrong, in every possible sence. Video quality, capturing even editing and this whole issue is dependable on your taste. So saying "SVCD is better than Xvid" is just as wrong as saying the opposite. Or saying bilinear resizing is enough/not enough, or 352x288 is LQ. But, somewhere you have to draw the line. For instance I was the first one on this board who didn't wanted to make a FAQ with primarly my opinion, but I inserted links to discussions where people had different opinions, altough the new FAQ by Tim and me is a mixture between classical FAQ's on Doom9 and links to discussions. E.g. Someone who thinks that VCD is good enough will surely disagree with all people who think that low res capturing is LQ, shall BaronVlad put every single opinion on this board in HIS (I'd like to emphasize that) guide?

Now, let's adress some points.

>>I will look into ivos thoughts and will pick the good parts and put them into the guide.
>huh,now i see why it's so easy to split over some issues and why
>MCF become matroska etc.

No, you don't see that, because:
a) You have never put months of work into something and published it (at least I have not seen such a thing)
b) You certainly didn't published your own work and let other people tinker in it without your approval
c) It's normal that the guide is shaped by Tim's taste/opinion as it's his guide

I was the first person who had the opportunity to read/comment on Tim's guide (in german back then), and I cannot say that he accepted everything (we disagreed and/or many things I couldn't write because of lack of time) I said or inserted every comment of mine. The same applies for the recent updates. What would happen if I had reacted the same way that you did when he didn't agreed with me (for example I was against, putting the VirtualDub real time NR in the guide etc.)? There is a reason why there is discussion and then he puts in what he wants. Isn't it normal that he first checks our writings and then accept it/or not? BTW, you should be thankfull (and everyone else) that he even takes your recommandations into account. I cannot count how many times I wrote some recommandations etc. only to be ignored, not thanked etc. He's certainly not afraid to ask people that know more than him, we should give him that credit (and more...)!BaronVlad/Tim is quite some time around and on every board they greet him, that also means that he has not choosen to ignore you nor insult you, he just wants have control how this guide grows. If I recommend something, he also, checks it first, isn't that the whole point? Or shall we make a Wiki document?

-low res/filtering and the whole other bunch

Again, there is no absolute truth. You say that you always have (!) to filter, I say you don't. You're talking in absolutes that are absolutely wrong :D .

How you capture depends on:

a) Hardware/software
b) Time
c) Wanted result
d) Knowledge
e) the rest I've forgotten ;)

Certainly not on an "absolute truth/ideal way". If there wouldn't be so much different opinions, there certainly wouldn't be so much very different "best way" ideas, postings and guides. :)

-So, if you want to watch something one time and you're not a picky person, then you can e.g. capture direct Divx at low res.

-If you want to achieve the best possible capture, then you'll capture with Huffyuv at max. res with later applying of filters etc. and transcoding to a high end format like DVD.

But, even if two persons agree on most of things, I doubt that they agree on all points.

If you're talking about the best achievable result, then you can dismiss every capturing resolution below the max., 99,9% of the capture hardware etc. Is that what you want? So, I think I have made it clear that it clearly depends on taste; filtering even more...

My opinion that everything is a compromise between the a),b),c),d) and e) points :) .

>no one can do this thing alone,so vlad,i think you should welcome help,not remove it

Agree, almost nothing is done alone, but we/you should also respect that Tim/BaronVlad did/does the majority of the work, not anyone else. It's his baby, he should decide what and when to change. Those who not agree should, IMO, think a moment why they're doing this...
I never noticed that someone started to flame Doom9 because he disagreed/didn't wanted to insert something in his guides.

As for your "I know what I am saying", I doubt that you could be called the only one who knows his capturing stuff. And even if you would be THE man, it still doesn't mean squat as many of these points solely depend on taste/time/resources.

Why not write your opinions/comments on this board or PM/mail him, he surely look into it and insert it? How can you act like he dismissed every one of your opinions when you don't see/know what he does?

BTW, thank you for making your postings more readable, seems that Doom9's on GD comment helped.

@Wilbert

>Don't want to say to much about this, because this is a public forum.

I don't understand this comment. What do you want to say?

Cheers,

Mijo.

[^^-+I4004+-^^]

EDIT BY BARONVLAD:

Message removed, no flame please

We state: especially porn should be filtered as hell as ivo says.

[Ookami]

EDIT BY BARONVLAD:

Message edited, as there is no sense in keeping an answer to a thread that already has been removed (see above). Mijo knows that I edited it !

The rest of Mijos post (@ivo):

I advice you to act like an adult in the future.

BTW, I'm still waiting for some real tests by yourself, you know with exact test settings, same testing circumstances and the whole other bunch you don't believe in.

Anyway take care and good luck, you'll need it with such an attitude.

Cheers,

Mijo.

[^^-+I4004+-^^]

EDIT BY BAONVLAD:

Message edited, no flame please

Edited posting follows->

> BTW, I'm still waiting for some real tests by yourself, you know with exact test settings, same testing circumstances and the whole other bunch you don't believe in.

as i said.i'm willing to forget,drop me a few lines and i'll arrange something (and in croatian lang.)(if you still have any interest in bt huff and mjpeg samples


ok,now back to some more productive stuff;
hope vlad succeeds in translating derkarl's stuff as it's a hard nut to crack (even the non-german speaker can see it...like i am)
but it's worthy,believe me......


btw. i didn't hear if wilbert agreed on my version of avs' cutting out commercials?

[BaronVlad]

Hi,

@ivo: This is a thread about the capture guide. It is NOT the right place to fight your personal war against Mijo. We all have different opinions from time to time, it is the same with Mijo and me but this a chance to create new ideas not to flame as you did.
Mijo did not strike you.

EDIT:

I think you can imagine, what i wrote here first, but it was late. Ok, I also wont strike you, but IMO you should

edit your long post above and remove the profanity and disrespect, and please dont continue with it, not here or in another section / thread, otherwise you may get Rule 4 not now, but in the future

It would make me sad to see this strike as we all are here to work together on this guide ! And where do we get all the ideas from, when you are not around us ? :) You will see it in the guide, what I mean, if you like, PM me and I send you the list of the things I put in.

As we all are adults we should behave as such and removing this is IMO the best way to proof it, but this is up to you again.

/EDIT

EDIT 04/19/03: Messages of ivo and Mijo edited.

Thanks.;)

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

@all: But now lets continue with the guide:

I looked into ivos suggestions and put most of them (some modified)into it (thanks for your thoughts), or better sent them to steVe to do this. We will see it in the next (hopefully nearly final) version

vcf2avs:

I edited a bit and sent this version to steVe, but maybe Wilbert can add it as well:

"Cutting out commercials with VDub (as an GUI) and incorporating cuts into .avs scripts:

Often you want to cut parts of your capture (for example to cut out commercials). It is somehow complicated to do this without any help direct in an Avisynth script. An easy way to do this is:



a) cut out commercials with VDub (see the section of the guide that explains this procedure)

b) Save the edits of your video into a "vcf-file" (File -> Save Processing settings)

c) convert VDub cutting data to avs compatible "trim" command by the means of "vcf2avs" (by "bb")



after this you have one .avs file which contains "avisource" or "segmentedavisource" command for opening the avi in question,and trimming points (trim commands) as you have done this in VDub.

simply incorporate this data into your existing avs script and the avisynth will do the cutting as well as processing.



You can get bb's "vcf2avs" here: http://forum.doom9.org/showthread.php?s=&threadid=30587&highlight=vcf2avs

(Note, that bb's version will provide you with the same accuracy as VDub cuts,giving you exactly the same output as with VDub cutting)"

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

And I finally got this aspect ratio thing ready, this was a hard afternoon, but it seems to be ok now, as Karl looked into it and I did some changes because of his suggestions (Thanks), it will be in the guide instead of the describtion of Full PAL in preface, here is a "sneak preview":

"What exactly is Full PAL ? We are talking about analogue capture, the signal is brought to you analogue and you have digitize it. There are no pixels from the beginning, so your capture card has to be told to create a pixel resolution. But we normally have a DAR (Display aspect ratio) of 4/3, on the TV screen AND on the computer monitor. As a standard we always have 576 lines. This should result in 576 * 4/3 = 768. The result in the calculation (Link zu "Der Karl's Capture Karten aspect ratio fuer Dummies ;-)") of “Der Karl” for the right resolution is ~702 (active) pixel. Why ?



To confirm this we have to think about another thing: Pixels are not the same on different sets. On a computer monitor a pixel has exactly same height and width, a PAR (Pixel aspect ratio) of 1/1 (square). A DVD Player and the signals for your TV i.g. have another PAR: 54/59 (non square), so this would be ~ 576 * 4/3 * 54/59 = about 704 including ~ 1 or 2 pixel overscan (black borders). This is nearly the same “Der Karl” calculated (Differences because of divisibility).



As a result of this, the resolution of your capture card may differ from others, as there are:



704*576 with a PAR of 54/59 and 1 max. 2 pixel overscan (black borders)

720*576 with a PAR of 54/59 and ~ 18 pixel overscan

720*576 without overscan -> not concurring with the ITU -> use generic PAR (45/48)

768*576 with a PAR of 1/1 without overscan



This is theory, nothing is actual the same in practice, i.g. you will only see "real" square pixel on a TFT, but it should also be mentioned that the drivers of your card sometimes have problems with the “right” resolution:

With a BT 8x8 Chipset (common TV Capture Card) try 768 or 704 * 576 cause of (often) wrong scaling of the cards when 720 is used

With Philips (mostly Asus/NVidia) try 704 (old drivers) or 720 (newer versions), as these cards have no scaler the resolution should be always the right one.

With ATI try 720 or 704. If you use 720 as I do, be sure to stick to the right PAR when resizing. Here it is “generic PAR” (45/48)



If you use a DV Codec, please remember that capturing with that one is limited to 720 anyway.



To get the right final resolution you should get a 4/3 resolution:

for MPEG4 : PAR=1/1, MPEG1/2: PAR=54/59 (VCD 352*288, SVCD stretched to 480*576), DVD 720*576 (including overscan) or better 704*576 without.



But as always: It is up to you to find the right aspect ratio / resolution, but if you found a descent one, dont forget to resize the way you should to get your 4/3 image...":)

[Wilbert]

@all: But now lets continue with the guide:

I looked into ivos suggestions and put most of them (some modified) into it (thanks for your thoughts), or better sent them to steVe to do this. We will see it in the next (hopefully nearly final) version

vcf2avs:

I edited a bit and sent this version to steVe, but maybe Wilbert can add it as well:
When Steve put it on his website, I will use that version. I will add the GKnot part coming days.

[^^-+I4004+-^^]

>edit your long post above and remove the profanity and disrespect, and please dont continue with it, not here or in another section / thread, otherwise you may get Rule 4 not now, but in the future

normally i don't go into such lengthy (and pretty useless) discussions but my ex-pal mijo deserves every bit of it...(no,don't worry,this tone won't continue...)
you have my approval to erase both of my posts (first one considering
the "guideforge" and the second one as a reply to mijo)
however i think it would be for the best to erase his post too (as neither his or mine post were really usefull for this thread...i think anyone will agree on that one!)
i think that would be fair to me,him and the community.......
if you would on the other hand decide to erase my posts only,that's ok with me,but his post would have no context,so...(better erase that too...hehe)...these posts of ours are typical email discussions posted to pub-forum and it wasn't so cool...(who was worse?well,probably me,but he had his moments too...),so erase it all,no problem (this stuff is useless...except for elaborate way why porn shouldn't be filtered...lol!)

erase this too...let's forget it!

**********************************************************************
(stuff below this line should be kept,it's back to the subject)

>it will be in the guide instead of the describtion of Full PAL in preface, here is a "sneak preview":

huh.will it "scare off the noob's"?hehe,just kidding..........
anyone should know why 704,720 or 768,so it's good to include it....
btw. i THINK derKarl is constatntly making one BIG (like major) mistake on PAR thingie;here's how (or this thing got twisted somewhere?);
PAL PAR is NOT 54/59 in my mind!it is 59/54!!!
(ie. x(width)=59,y(height)=54 (!!))
in my mind,54/59 for PAL has no sense....
when i say following it might be easier to comprehend;
PAL(mpeg2) is 720x576,NTSC(mpeg2) is 720x480!
(are you starting to see it now?)
NTSC PAR is 10/11(!!) wonder why?(heheh,yes!)
720x480 is obviously not 1,3 (as NTSC screen is ie. 4:3)) so for compensation it would require some unsquare PAR...we know what kind of PAR too;
pixel should be *with more height than width*!!!
(now you know why is 10/11 and NOT 11/10....,and why is it more stretched in mentioned way than PAL is in the other way(PAL is *with more width and less height*(59/54):because of 720/480 vs. 720/576 relation.....)
720x576 is also not square PAR but it doesn't require such correction!
his pixel must be a bit *wider than tall* to bring 1,25(720x576) to perfect AR (1,3) this is 59/54 pixel!!!
(few calculus';
ntsc 720/480= 1.5
AR of tv is 1.3
pal 720/576= 1.25
it is OBVIOUS that NTSC needs exact the OPPOSITE AR correction than PAL!!!this AR correction is done by the means of PAR!
in simple language;when watched on monitor,NTSC's 720x480 is geared toward letterbox (image is stretched in horizontal way!)
PAL is (EXACT THE OPPOSITE) squeezed in horizontal way!
therefore;PAR for NTSC has exact the OPPOSITE relation of pixel side lengths; NTSC PAR squeezes,and PAL PAR stretches!)

and i slight YESSSS!here (as i think i'm correct here,and in my mind this explanation of mine is even better than GKnot FAQ on this...seems like no one really likes to even think about it...except for me...heh...if i'm on the other hand wrong,please argument how and why...you'll reallly have to think hard to prove this wrong;REAL HARD!...i hope..heh )

in fact seeing the NTSC PAR made me realize complete truth about PAR!
before that it was pretty hazy to me...i mean,pixelAR..come on people,can that exist...implications are enormous etc.
but it seems to exist and in the way i described here:
figure "54/59" should only be used on calculations where there's need to correct for this offset that par creates in accordance to normal AR (but math is not my best side,so i won't go into all of these corrections,derkarl calculus etc. if this number is used for that,it's probably ok,but it's not ok to say PAL PAR is "54/59"! )

my reference was;
http://www.mir.com/DMG/aspect.html
and it states;
"The pixel aspect ratio for 625-line video (PAL) is 59:54. Exactly."
and
"The pixel aspect ratio for 525-line video (NTSC) is 10:11. "
[this was written by " ©2001 Matthew Marjanovic."...lol!
he's croatian too! i regard his explanation better than
http://www.lurkertech.com/lg/pixelaspect.html
so big thanks flies out to him for publishing such extraordinary document...heck,lurkertech lead me nowhere! or was it just that i didn't payed enough atention to NTSC PAR there?
heh]

please contact karl to correct this,i would also love some credit for it,but not necessary....

and another intetresting thing;see this;
>The actual MPEG-1 specification specifies the following pixel aspect ratios:
1.0950 for "CCIR Rec. 601, 525-line" images with frames of "711x487 at 4:3"
0.9157 for "CCIR Rec. 601, 625-line" images with frames of "702x575 at 4:3"

(from this same web)
remember how i said somewhere that "pal is PAL is 576-1,5 lines"?
and that one line on the bottom is blank,and the next one (towards up)
is only half filled?
seems like mpeg1 folks saw this too (hehe) and mpeg2 folks decided that's even better to capture 1 line extra (probably because 575 is uneven number so encoders don't love it...and it' not even "16" compatible!)
i'm so clever,it's not even funny anymore (lol!)







regards,my people

/ivo

[Darksoul71]

@^^-+I4004+-^^:
normally i don't go into such lengthy (and pretty useless) discussions but my ex-pal mijo deserves every bit of it...

1) Keep your private stuff with Mijo out of the forum. Stick to PM or e-mail for "personal war". I´ve e-mailed with Mijo a few times and he seems to be a very polite person.
2) I´ve NEVER EVER seen any posting of you with less than 10 ugly structured lines. As I told you once before: Learn to use paragraphs and Line brakes.

@BaronVlad:
Re vcf2avs: Also don´t forget my little "VCF2AVS" :)
http://forum.doom9.org/showthread.php?threadid=41927&highlight=VCF2AVS

-D$

P.S.: Happy easter for everyone

[^^-+I4004+-^^]

>As I told you once before: Learn to use paragraphs and Line brakes.

i'm now just following d9's suggestion;that means writing into this silly lil window of forum,and i'm on 800x600 (dunno if that's the source for funny lines...)and frankly by now i don't care!
you're not satisfied with broken lines,nor with longer and unbroken lines....so,read it if you can,skip it if you can't...see if i care...
you're another authority here?
hmm,see above what i mean on authorities....
he who gets interested will succeed in reading my stuff...this way,or the "tornado" way....

>Re vcf2avs: Also don´t forget my little "VCF2AVS"

we know of your lil tool,but it has some weird frame offset,so i prefer bb's version (with an frame accuracy!)
last version (i tested) of yours still had this bug,so i just skipped it........if you have better version(and no frame offsets) than bb,then probably you'll get to be mentioned too....

[BaronVlad]

Hi,

I am glad to see you think this way with Mijo, ivo. We will see what will happen to the posts. I dont know this actually, of course everything will be removed, if anything will be removed, there is no sense to have an answer for a thread that is gone, but as I said, I dont know this actually.

To the PAR...thing: Especially you asked for a clear describtion of this, now you got it. Maybe you should get into contact with Karl to discuss these things with him :D Come on, everybody knows what is meant, you can also explain it the other way round (704/54*59=768 or 768*54/59=704) Who cares ? I dont.

This explaintation was for PAL only as Karl had not written one for NTSC and I think he wont do this in the future as he told me. I will think about the NTSC thing and add a few words in the future.

@DS: I got the part about vcf2avs from ivo and only edited a bit cause I had to work hard on Karls words, but as it is a sticky in the German board (;) ) you are right, we should at least mention it or more. I will go into details and check the proggie out asap.

[^^-+I4004+-^^]

>Come on, everybody knows what is meant, you can also explain it the other way round (704/54*59=768 or 768*54/59=704)

as i said,in calculus it's ok butif you say "PAL PAR is 54/59" then it's wrong statement.....now,this is NOT your fault!
for example;
> 54/59 (non square), so this would be ~ 576 * 4/3 * 54/59 = about 704 including ~ 1 or 2 pixel overscan (black borders). This is nearly the same “Der Karl” calculated (Differences because of divisibility).

when yout turn it around (for the calculus) then it's OK!!!
but spec says clearly;PAL MPEG2(and DV) PAR is 59/54...i have been mentioning NTSC only for explanation and comparison.....
let me put it in even simpler way;
let say that we have 720x576 but with 59/59 or 54/54 or simply 1:1 PAR;
this would mean we have sqaure pixel,and then we can calculate without problems;720/576=1.25
this means we have image that is squeezed in horizontal way....(like we have on monitor;as monitor converts all pixels to square pixels!!!)
if 720x576 with square PAR (1:1) is projected to tv,same thing will happen as on monitor...uncorrect AR of 1,25,but not as visible as on monitor because of tv's overscan...(non the less,it's the wrong AR)

i think this should be rectified;if karl knows english,direct him to my previous post,so he sees it....he should pick it up from there....

to clear thing a bit more (calculus) see how xesdeeni corrects for 4:3 screen in this thread
http://forum.doom9.org/showthread.php?s=&threadid=34122&highlight=pal+resolution+is
scroll to his first answer,you'll see where and how he used "3/4" (only for calculus...)
like this;
"However, lines of (horizontal) resolution is defined based on a square screen (called a "screen height"). So our 4:3 television has to remove its aspect ratio, so we get (325 * 3/4)"

this is no big deal (after all it's just PAR...hehe) but 54/59 as a PAL PAR will confuse quite a few!
it's "59/54" for all the reasons i said before.....
(i dunno why would someone like karl swap "x" and "y" axis for PAR,but he did....for calculus YES,for specs NO!)

vlad,do it like this; read my previous post (carefully) and decide for yourself what makes sense,also pay visit to the link i posted there (marjanovic)....direct karl to it too,if still looks to hard or confusing for you,(or no consesnus can be achieved with karl) i suggest you simply leave it out....i'm investing all my knowledge (and then some...hehe) so that the guide has the facts only....54/59 is a fact.....BUT ONLY IN CALCULUS for the rare ones that decide to calculate with PAR's....karl decided,but made a mistake leaving it 54/59 in specs too.....
(contacting karl?,just point him here...i don't know if i can explain it better than that parallel with NTSC's 720x480 on 10/11 PAR.....but if he had some doubts afterwards he can contact me...no problems..)

and guess what;wilbert's confusion with 720 and 768 is directly derived form mistakes such as this (but he did the opposite;
"h=720*59/54 = 786.7 (PAL), "
and if wilbert got confused with it, well,you see what i mean...better to keep it as correct as it can be!)

i would be luckiest man on earth if those scumbags in ccir decided to use sqaure pixels only and not make this havoc for everyone with silly 720 59/54 pixels!(i really mean this is silly!)

on the end,small copy paste from gknot forum sticky on ccir601 etc.:
(from chibi jasmin)
>"Resizing of MPEG-sources compliant to ITU-R BT.601 standard

PAR=pixel aspect ratio – DAR=display aspect ratio

According to ITU-R BT.601:

PAL PAR 117/128 (y/x), x/y=1.094 [128/117] PAR"


see,this is a CORRECT WAY!!!
if u use 54/59 u should always note (y/x) afterwards.....
as 59/54 is (of course) x/y
i belive usual naming convention is "x/y",and in calculus we might need "y/x" (54/59) so it's best to note it ALWAYS in every calculus,otherwise such "bugs" will arise...


cheers

/ivo

[Darksoul71]

@Vlad:

@DS: I got the part about vcf2avs from ivo and only edited a bit cause I had to work hard on Karls words, but as it is a sticky in the German board ( ) you are right, we should at least mention it or more. I will go into details and check the proggie out asap.

It´s ok. I´m not nitpicking. I just wanted to point out. It´s funny that bb developed a tool with nearly the same functionality (even the same name) during the same time I did. IMHO "my" VCF2AVS has some good functionalities for the "analogue capture guys" like batch splitting or batch audio conversions. This really helps for people that archive a lot of movies.

@Ivo:
>you're another authority here?
Nope, I just can´t stand some guys bashing on each other in the forum. I always had some problems with "authorithies". So I shurely won´t be an authority......

we know of your lil tool,but it has some weird frame offset,so i prefer bb's version (with an frame accuracy!)
last version (i tested) of yours still had this bug,so i just skipped it........if you have better version(and no frame offsets) than bb,then probably you'll get to be mentioned too....
I dunno which version you´ve tested but I think that I fixed this bug something like 4 versions ago...
bb was so kind to point out. I subtracted 1 frames because I thought that the first frame in AVISynth was Frame 0.

BTW: "probably you'll get to be mentioned too...." ????
I don´t need "to be mentioned too...".
FYT: I´ve developed "my VCF2AVS" for my personal needings and shared it with the other peoples.

@other: Sorry if this is totaly OT but I couldn´t stand...

-D$

[BaronVlad]

Hi,

I edited ivos and Mijos postings, it is ok for Mijo as he said and I think it is also ok for ivo, if not, this is not my problem anymore, cause I wanted you (ivo) to edit it. You did not, so everything is gone, also some suggestions you made about filtering of porn, but you had the chance to save this.

Now let us please continue with the guide or some rules may follow.:D

@ivo: I got your point, but as I told you, you can see it the other way round and then it is correct. I know that Karl looked into this thread, I will ask him about 54/59 <-> 59/54, we will see, what he wants to admit.

Something else:

>you're another authority here?
DS is right, your postings are very hard to read, I am glad to see you not continuing in using "tornado style" But please try to use also a SHORT describtion of your thoughts. And also have a look at what you are saying. What you said above is very near to 4). As I said I dont want to see this strike, but you will not get another warning.


@DS: bb and you should have developed this tool together, this would have been less work for both of you.
:)

But dont be afraid, I know what you meant, I will have a look asap as I promised.;)

[Wilbert]

A short update:

The AviSynth part is done, only the vcf2avs has to be included. I'm still waiting for Steve to share the updated version.

About GKnot: I installed v0.28 + beta 3. I thought that would be cool, since you can also encode to XviD using this version. However when opening a huffyuv-avi (yuy2), I don't see the clip in the preview (which is necessary for cutting parts of the clip). I will post in the Gknot forum for this. In the mean time, can someone check whether this problem is also present in v0.27?

[^^-+I4004+-^^]

>I got your point, but as I told you, you can see it the other way round and then it is correct.

true,small "(x/y)" or "(y/x)" after the "59/54" or "54/59" (respectively..hehe) will do....

>But please try to use also a SHORT describtion of your thoughts

and that's no lie that i tend to go on and on and on...(and on..heh)..probably out of fear that someone might not understand it all (so i put more (slightly different) explanations of the same thing....) and i really don't know if one can be clear enough on the PAR...heh...

luckily,99% of the time there's no PAR speak....
(but non the less,i'm no poet to condense all i think in smallest package; i prefer novels!.....hehe)



btw. vlad have you uploaded newest version somewhere so i can get the html only?if not,please send it via-email or so (PM?).....

thanks...

[Belgabor]

Originally posted by Darksoul71
@BaronVlad:
Re vcf2avs: Also don´t forget my little "VCF2AVS" :)
http://forum.doom9.org/showthread.php?threadid=41927&highlight=VCF2AVS


For completeness sake you might want to mention that VDubMod basically also supports this :)

The Script Editor can:
- Import the curret frame
- Import the selection
- Import the selection as trim statement
- Import the complete select/del editting as aligned splice of Trim statements

Cheers
Belgabor

[Darksoul71]

@Belgabor:

For completeness sake you might want to mention that VDubMod basically also supports this

Oops, forgive me :D

Honestly I haven´t had the time to test VDubMod. It´s great to see a combination of VDub and AVISynth.

-D$

[^^-+I4004+-^^]

bb's vcf2avs;
AviSource("D:\Video\rawstuff\seve-obrve-atv2000capture_1_01.avi")
Trim(0,36)+Trim(57,206)+Trim(235,435)+Trim(450,1000)+Trim(1257,2406)+Trim(2758,3431)

d$'s vcf2avs;
AVISource("D:\Video\rawstuff\seve-obrve-atv2000capture_1_01.avi")
Trim(0,36)+Trim(57,206)+Trim(235,435)+Trim(450,1000)+Trim(1257,2406)+Trim(2758,3431)

(source vcf;
VirtualDub.subset.AddRange(0,37);
VirtualDub.subset.AddRange(57,150);
VirtualDub.subset.AddRange(235,201);
VirtualDub.subset.AddRange(450,551);
VirtualDub.subset.AddRange(1257,1150);
VirtualDub.subset.AddRange(2758,674); )

also;still d$ version cannot fit 800x600 desktop properly (nor it can be resized to fit),d$ version has quite a few extras (making it almost 1MB dload,bb's version is 9KB(!)dload...)

didn't tried vdubmod,but i would have the need to copy-paste trimming stuff anyway,as my avs script is...well,it's 9KB big,need i say more...it also has some avs ONLY plugins,etc.

so i'll stay on bb's version with cropping done (800x600,remember..cannot crop 768x576 with VDub...)by TmpgEnc,as it downsizes the cropping window nicely,so i only enter the data to my existing script..... i rarely crop anyhow....there are not so much 16/9 movies aired here.....

[Darksoul71]

@^^-+I4004+-^^:
Thanks for your test and your comment.

also;still d$ version cannot fit 800x600 desktop properly (nor it can be resized to fit),d$ version has quite a few extras (making it almost 1MB dload,bb's version is 9KB(!)dload...)

I know this. My version was "optimized" for >=1024x576 as I´m running this res. The programm itself is not resizeable because this would make it neccessary to resize all components. Another solution would be using tabs (like GKnot), but I dislike this.

Regarding size: I´ve kept down the zip size as far as I could. There are various plugins and tools includes that make the package that "big" but honestly 1 MB isn´t a big deal. I´m currently runnning 56k dial-up for my www connection and 1 MB takes only a few minutes.

-D$

[killingspree]

ok here i am back again
i don't know if i can but i'll try to include every changes bvlad/tim sent to me tonight and bring another version (1.4) online ... but i can't promise a thing. wouldn't be the first time i fall asleep infornt of my comp. (less than 10 hours sleep in the last 5 days)

steVe
PS: damn this thread seems to have gotten pretty ugly at one point. keep it nice and clean guys (;

edit (new): ok i've uploaded the new/modified version of the guide (1.4) hope i didn't miss anything.
link: http://members.tripod.de/stefanstrobl/download.htm
nur changelog: http://members.tripod.de/stefanstrobl/changelog.txt

[^^-+I4004+-^^]

>Thanks for your test and your comment.

no problem...as i said,i'll be the first to admit when i'm wrong...
i hope you have "segmentedavisource" too.(didn't had the time to test it)..ok,i'll take your word for it...hehe

>but honestly 1 MB isn´t a big deal

true,1MB is not much and there are many extras there,as i said....

resolution?yeah,well if the cancer research proggie won't let me help-in because of simillar thing,you can see others see only their desktop as a reference,so it's not like you're the only....
i like progs that are ment for all resolutions.....btw. have i mentioned i use large fonts too...hehe(no,not blind,but just like to get away from the screen a bit..)

but anyhow,even not all functions are visible,i can see the converting part (obviously.... as i tested it)

>damn this thread seems to have gotten pretty ugly at one point

i have modified the "suspicious" parts of another post....now,some of vlad's and mijo's responses are left hanging in thin air,but i have already said that the "guideforge" one needs erasing (now i did editing,only to leave part on lo-res filtering) too........

snug a peek at newest version,looking good......

@vlad ; THANKS for including my thoughts there too....
and SORRY for too much bitchin'........

(btw. those translator comments come in handy too!)

[BaronVlad]

:)

Thanks all !

I dont have much time this mornig, I will go into details, I hope, I will get the time this evening

Special :) @ivo !

[Belgabor]

Originally posted by Darksoul71
@Belgabor:

Oops, forgive me :D

Honestly I haven´t had the time to test VDubMod. It´s great to see a combination of VDub and AVISynth.


Sorry, I didnt mean you should have mentined D$, just to put it into the guide (for completeness sake ;))

So no reason for needing forgiveness :D

[Darksoul71]

@Belgabor:
>So no reason for needing forgiveness
But I´m really sorry that I haven´t even touched VDubMod :D

-D$

[BaronVlad]

Hi,

I read through the guide and did some minor bugfixes that I sent to steVe, also Darksouls program and the script editor of VDubMod will be mentioned.

Maybe someone could help Wilbert with the GKnot setup ? I cannot, cause I lent the cables to a friend of mine and cannot do any caps this time. Maybe it is just because Wilbert hasnt deleted the last small Huffyuv file before loading into GKnot ???

Regarding the ugly PAR and NTSC thing: I will contact Karl.

Now I have to leave and I have the bad feeling that I forgot something very important. Please remind me, if this is true. :(

[^^-+I4004+-^^]

>Maybe someone could help Wilbert with the GKnot setup ? I cannot, cause I lent the cables to a friend of mine and cannot do any caps this time. Maybe it is just because Wilbert hasnt deleted the last small Huffyuv file before loading into GKnot ???


my avs205 will crash on last frame with segmented mjpeg's too ie. not that huff is only affected
(all multisegmented VDUb produced files have this last empty 12kb file..)
if i got (with the VDub editing) on the last frame and try to go back,it crashes avs....
(dunno what GK does on opening of the file...)

but usually the last frame doesn't stay there (in the avs script) at all (it's trimmed before the encoding) so it doesn't crash.....but even in event of crash (on the end of the encoding),the rest of the file is usefull....

i believe this bug (last empty segment crash) was corrected in recent avs release...

those are my experiences on last segment empty issue...

[Wilbert]

Maybe someone could help Wilbert with the GKnot setup ? I cannot, cause I lent the cables to a friend of mine and cannot do any caps this time. Maybe it is just because Wilbert hasnt deleted the last small Huffyuv file before loading into GKnot ???
That's not the problem I have, cause I didn't use segments. The problem is that the preview (of gknot 0.28) doesn't show anything when loading a huffyuv.

Tomorrow, I will put up a new version including Steve's changes.

However I do have a general question about gknot (relating to capping of course):
I would like to know some reasons why people would use gknot for processing captures.

0) delete commercials => vdubmod + script editor

1) For deinterlacing (PAL), the (often) correct deinterlace option isn't even there. Better to do it manually with SeperateFields, to see how to deinterlace. For NTSC it is probably usefull.

2) For resizing. Capping in 7XXx576 => 640 x 480 (or scalings) for XviD. I always thought that 720x576 and 704x576 had to be resized differently. But Ivo corrected me, I hope I understand it now. So resizing is also trivial.

3) Color correction => vdubmod need with script editor

So, the only reason I can think of to use gknot is the compressibility test. But if this is the only reason, one could make the script (without gknot). Open the avi in gknot, and replace default gknot.avs with the self made gknot.

Any opinions?

[BaronVlad]

Hi Wilbert,

on my system I have GKnot 0.28 beta 5, Avisynth 2.51 beta (March, 12th) and Huffyuv v2.121 - CCESP Patch v0.2.2, I encoded a short clip to Huffyuv since I cant cap now but had no probs with loading in GKnot and getting a preview, maybe your files are avis larger than 2 GB ? There may be such a problem ? :confused:

Regarding your thoughts about GKnot:

:D

You are somehow right, Wilbert, but there may be some people that are not able to write an Avisynth script on their own, and those can use GKnot for this. After this load this script with VDub(Mod) and edit something, load again...

I often do it this way, ok with DVDs, but I think some people do this with Captures also.

So you can learn to combine editing your caps with Avisynth scripting, GKnot and VDub...;)

[Wilbert]

but had no probs with loading in GKnot and getting a preview

Weird, can you try the following huffyuv (three frames):

http://www.geocities.com/wilbertdijkhof/huffyuv4.avi


You are somehow right, Wilbert, but there may be some people that are not able to write an Avisynth script on their own, and those can use GKnot for this.
As you notice, that works great for dvd's. But not for captures. I will see what I can do.

[BaronVlad]

:eek: 3 frames = 850 KB...:eek:

Wow, that is really what we call lossless compression. :)

I had no problem with GKnot, I could load the clip and got a preview, my script:

avisource("c:\huffyuv4.avi")

Which versions of programs and codec did you install ?

IMO the GKnot part should be a simple way how to do first steps with Avisynth, you can keep this part very short and link to doom9`s DVD Guides and your Avisynth part to reduce redundant words.

Thanks for your help again ;)

[^^-+I4004+-^^]

i agree completely with wilbert on GK part (we tend to agree
more and more lately...heh)...not real use for it on .avi's,but i agree with wilbert too (isn't that nice too..heeh) as if it can be sorted out to work for layman then it should be easier for him...right?GK should make for few steps less then we guys normally do...correct?
(ie. if it'll make people more aware of avs...as i said...)

for a man that likes to learn more ; VDub,Ndub,avisynth should make him bussy for a while...

another one for wilbert;
i belive you didn't included crop.addborders trick
(i believe i didn't saw it in,there's stuff on removing junk on top and bottom,and indeed letterbox is good enough for that,but it can be junk on the sides too.......i will apologize if i made you remove this part if it was present before...as it happens i believe it would be best to leave "letterbox" for top/bottom,and make an addition "Removing garbage from the sides (left/right) of the clip")?

i have used it yesterday with decent results;
[code]
#removes the junk,adds black borders,centers the image.....
#addblackborders for 16 compatibility[some nasty results on 572x416 #divx]
#for processing in yuy2 left and right must be even
#syntax:AddBorders(clip, int left, int top, int right, int bottom)
Crop(16,0,556,420).AddBorders(10,6,10,6)
#above is good for 7xx x 576->576x432 poor VHS as am using now for #TLN1..

( as junk on the sides is eating bitrate too...non 16 solid colors are not liked by the mpeg codecs,but i think they like junk on that borders even less!hehe )

wilbert,glad to see you had time to test that all 7xx resolutions have same amount of image inside....as i did here
http://i4004.0catch.com/704_720_768%20line.htm
(if someone missed it..heh)

/ivo

[killingspree]

Originally posted by Wilbert

Tomorrow, I will put up a new version including Steve's changes.


please make sure you really use the latest version of the guide... i am doing some changes atm and will upload it a bit later half an hour or so...

i will of course post here as soon as the new version is 'online'

steVe

[killingspree]

ok version 1.5 is up... (:

link: http://members.tripod.de/stefanstrobl/download.htm
changelog only: http://members.tripod.de/stefanstrobl/changelog.txt

please somebody read through the added deinterlacing and resizing part in the vdub post processing page. thanks

@Wilbert:
a) would you mind if i cropped / resized you avisynth screenshots a bit to improve loading times?
b)please check the changelog... i've added something to your part (of course only because Bvlad told me to :D)

steVe

[kempodragon]

I found a workaround for getting a preview of a Huffyuv file. Make a simple avs file using the AviSource () command and open the avs file in Gknot. Worked perfectly.

Whoops!! Someone already beat me to it. Shows what happens when you work third and are just getting up. :)

[Ookami]

A few suggestions:

- explaining overscan etc. ("Why do I see the mike on the PC monitor and not on the TV?" and "Help! I see not only headswitching, but even garbage on ________ !" :D ), maybe add it to the headswitching part
- (VD postprocessing) adding a link that explains the differences of the various res. filters (for those who want to read into it)
- on the additional NR filters add a bit more or at least a link to neuron2 site (as that's advanced stuff anyhow)
- add a few more reference links in the Appendix

Er, had more ideas... Sigh, getting old.

Nice work, y'all!

[Wilbert]

3 frames = 850 KB...

Wow, that is really what we call lossless compression.

:)

I had no problem with GKnot, I could load the clip and got a preview, my script:

avisource("c:\huffyuv4.avi")

Which versions of programs and codec did you install ?

Btw, you loaded the avi directly (without a script). Weird.

Installed programs/codecs:
- RipPack 0.28 beta6
- GKnot 0.28 beta5
- not the codec pack
- huffyuv v2.1.1 (http://math.berkeley.edu/~benrg/huffyuv.html, down atm)
- Windows 2000 SP2

Could you sent me the following file: avifil32.dll (w.j.dijkhof@tue.nl). Len0x said that this file is responsible for loading the huffyuv.


another one for wilbert;
i belive you didn't included crop.addborders trick
(i believe i didn't saw it in,there's stuff on removing junk on top and bottom,and indeed letterbox is good enough for that,but it can be junk on the sides too.......i will apologize if i made you remove this part if it was present before...as it happens i believe it would be best to leave "letterbox" for top/bottom,and make an addition "Removing garbage from the sides (left/right) of the clip")?
I removed the crop.addborders, and replaced it by letterbox. Btw, letterbox can also be applied to the left/right side of the clip. Will make a remark about it ...


please somebody read through the added deinterlacing and resizing part in the vdub post processing page. thanks

@Wilbert:
a) would you mind if i cropped / resized you avisynth screenshots a bit to improve loading times?
b)please check the changelog... i've added something to your part (of course only because Bvlad told me to )
Sure, no problem. I will look at the changelog (and download 1.5).


I found a workaround for getting a preview of a Huffyuv file. Make a simple avs file using the AviSource() command and open the avs file in Gknot. Worked perfectly.
So, you also couldn't load it directly? I will try this.

[BaronVlad]

I didnt load the avi directly, I used a script to load it, but in the script there is only "avisource()", the rest like cropping, resize... should be done with GKnot, can you show us your script ?

Mail is sent.:)

[Wilbert]

the rest like cropping, resize... should be done with GKnot, can you show us your script ?
I will post the script on friday. Btw, letterboxing (cropping is not necessaary) can't be done in GKnot. Resizing analog caps of 720x576 is also not possible, because it is always resized to 640x464 (and it has to be 640x480). That's what I meant with GKnot is not suited for this job :) Since I'm away tomorrow, I will post a new version on friday.

[TheWEF]

i did not read all of this long thread.
but i read PAR 54/59 and 11/10 in a number of posts and just want to mention (once more...) that these numbers are not correct.

PAL PAR is 128/117
NTSC PAR is 72/79

check out A Quick Guide to Digital Video Resolution and Aspect Ratio Conversions (http://www.uwasa.fi/~f76998/video/conversion/) and
this thread (http://forum.doom9.org/showthread.php?s=&threadid=42708).
btw.: you find all the correct PARs for commonly used capture resolutions if you press "select" in gknots PAR group box in the resolution tab.

this is just a hint. i'm tired of discussing this and i will not in this thread.

wef.

[Wilbert]

i did not read all of this long thread. but i read PAR 54/59 and 11/10 in a number of posts and just want to mention (once more...) that these numbers are not correct.

PAL PAR is 128/117
NTSC PAR is 72/79
I'm aware of this.


btw.: you find all the correct PARs for commonly used capture resolutions if you press "select" in gknots PAR group box in the resolution tab.
I do have a question about this though. Recently Ivo thaught me that 720x576 needs to be resized to 640x480 (and not 640x464), note we are talking about analog capturing (no dv or dvd). Can I select that in GKnot somewhere?

this is just a hint. i'm tired of discussing this and i will not in this thread.
Someone else?

[Wilbert]

I put up a new version.

- images240403.zip: only new pictures (of GKnot) [Steve, can you include those in your images v1.5 zipfile]
- htmlfiles240403.zip

changelog:

1.6 changes by Wilbert (24/04)
- changed processing_avisynth.html
- switched sections 4.2 and 4.3
- added links to AviSynth filters
- added 4.2.1: Processing interlaced video
- added 4.2.2: Using multiple captures to reduce noise
- changed the trimming in AviSynth part. Easiest is to do it with the script editor, therefor only links to vcf2avs
- added processing_gkont.html
- added gknot1.jpg-gknot7.jpg
- changed compression.html (switched audio and video)

I hope you like the GKnot part, of course other suggestions are welcome. If you want to use GKnot differently for this, please add a detailed proposal for this.

I didn't have the energy to read the rest. I suggest that we use the weekend to decide what needs to be added/changed/improved.

links:
http://www.geocities.com/wilbertdijkhof/htmlfiles240403.zip
http://www.geocities.com/wilbertdijkhof/images240403.zip

[TheWEF]

Originally posted by Wilbert
Recently Ivo thaught me that 720x576 needs to be resized to 640x480 (and not 640x464), note we are talking about analog capturing (no dv or dvd).

don't trust him! ;)
analog or digital - there is no difference.
just use gknot:

input res: 720*576
input par: select 128/117 (720*576)
H-Moldul: 1
horizontal res: 640
-> vertical res: 468 - that would be exact, but as you know, the codecs don't like that, so...

H-Moldul: 16
horizontal res: 640
-> vertical res: 464

you could also crop 8 pixels off each side to get real 4/3:

704*576 -> 640*480

wef.

[Wilbert]

don't trust him!
analog or digital - there is no difference.
just use gknot:
First, I know how to do the calculations, like you showed. Second there must be a difference between analog and digital. Ivo showed me (and of course I checked that), that capping at 768x576, 720x576 and 704x576 results in the same image. It is not the case that 704x576 is a cropped version of 720x576, but it is a scaled version. This implies that both must be resized to the same 4:3 resolution (640x480).

The pics (provided by Ivo) are given here:

wilbert,glad to see you had time to test that all 7xx resolutions have same amount of image inside....as i did here http://i4004.0catch.com/704_720_768%20line.htm
(if someone missed it..heh)
But of course, you can also check it yourself.

[killingspree]

Originally posted by Wilbert
I put up a new version.

- images240403.zip: only new pictures (of GKnot) [Steve, can you include those in your images v1.5 zipfile]


will do that right away...

steVe

[TheWEF]

Originally posted by Wilbert
This implies that both must be resized to the same 4:3 resolution (640x480).

or 640x464 or something else...
this just implies that obviously you have to find out the correct capture resolution first, everything else is guessing.

wef.

[^^-+I4004+-^^]

>Recently Ivo thaught me that 720x576 needs to be resized to 640x480 (and not 640x464),

now,i never said explicitly what input res. to resize to what output resolution,i have only showed you all horizontal sizes have complete image (ie. capture cards are not doing any cropping)
but ,hell,wilbert,you said it my friend,and you're right and it makes sense!!
indeed,7xx x 576 (xx being 04,20,68) NEEDS to be resized to 640x480 to have perfect AR!
i'm suggesting 768 as preffered only because it has more data,more quality than less resolutions!
704,720 or 768 resized to 640x480,you should end up with EXACTLY the same image (AR wise)....curently i don't have time to do that test,but i will (or if wilbert has more time....i have to capture "all the presidents man" in few moments....)

one should not forget one truth too;pixels on monitor are square(for 4:3 resolutions),so no need to take unsqaure pixels in account and resize as such they will be watched on devices that support unsqaure pixels!
(as 640x464 is step in that direction;not real need for such resizing!)

another reason why i don't like GK?
it first crops and then resizes (to have some spped up in processing)
i forst resize,then crop (to have perfect AR!)
GK will typically make some roundings (to "16") and i don't like it!this makes some AR offset,so i FIRST resize to 4:3 resolution,and then crop...in fact i never crop in that tsense...i add borders to keep mpeg codec happy...(as i have tried all sorts of things...funny resolutions....believe me,codec doen't like "2" or "4" resolutions...especially in horizontal way!)

but yet another thought;how do standalones(divx players) "see" PAR of divx->if they do same as PC (always square) there are no worries even in long term usage!

cheers
/ivo

ps. and again,wilbert thanks for support..........
and
ps2.@wef_sorry for misunderstanding on PAR's(in gk forum)

[TheWEF]

Originally posted by ^^-+I4004+-^^
ps2.@wef_sorry for misunderstanding on PAR's(in gk forum)

that's ok, but anyway...

Originally posted by ^^-+I4004+-^^
indeed,7xx x 576 (xx being 04,20,68) NEEDS to be resized to 640x480 to have perfect AR! [B]

Originally posted by ^^-+I4004+-^^
[B]so no need to take unsqaure pixels in account and resize as such they will be watched on devices that support unsqaure pixels!
(as 640x464 is step in that direction;not real need for such resizing!)

...what you are saying is still not true.
but i can't explain it any better than in the sticky in the gknot forum, or the perfect explanations in all the links i provided.

wef.

[TheWEF]

Originally posted by Wilbert
This implies that both must be resized to the same 4:3 resolution (640x480).

check out this:
http://www.dynalink.com.au/files/pdfs/bt878_specs_sheet.pdf

these capture devices can do internal cropping, resizing, scaling,...
so it's impossible to say what is correct without knowing how the drivers and capture software are programming and using the chips internal functions.

i guess you have to contact haupauge to really find out. or capture movies with round objects (balls) in it...


wef.

[^^-+I4004+-^^]

>...what you are saying is still not true.

no?really?
take a look here;
http://i4004.0catch.com/
[link is on the bottom of the page,couldn't enter this link directly it seems to big for this crappy reply window]
or,copy paste this to adress bar of browser...
"http://i4004.0catch.com/resizing%20the%207xx%20and%20pixel's%20appearance.htm"

(with this one,my talk of PAR is over,as i already said and (on this link)proved everything......non-believers,do your own tests....)

i reccomend you especially the slides
"http://i4004.0catch.com/alan_j_pakula_640x480[from%20768x576].jpg"
and
"http://i4004.0catch.com/alan_j_pakula_source768x576.jpg"

and i'm challenging you;if you see any AR change with those two samples,then i'm the one that's stupid all this time!
you'll have tot do better than just pointing us to GK sticky with numbers only:why should i use 640x464 for video that's to be played on 4:3 monitor,tv-out and i truely believe divx hardware players only play in square pixel mode(hm,is there PAR data in videoinfoheader of .avi file at all? i didn't saw it.....but i know mpeg2 has it!)

>but i can't explain it any better than in the sticky in the gknot forum, or the perfect explanations in all the links i provided

for all that i care,your sticky only has numbers and less explanations on why and how?(for example,you need to make that differentiation dvd player display/monitor display...you need to say that very clearly! or did you? anyhow,reading that sticky told me nothing on why 720x576 needs to be unsquare to fill the screen and how does it do it,and how come ntsc has 720 pixels too...because of this i made few sketches how do ntsc and pal mpeg2 pixels look on dvd-player->tv )

if i resized 7xx x 576 to 640x464 i would get AR offset->my tv-out is pure 4:3 square pixel (800x600 or 768x576)!
i have pointed you to 768x576 and 640x480 so you see there's no AR change between those two (and the 640x480 end image is the same for all 4 input resolutions...wondered why?)
bare in mind that 768x576 is prefectly square PAR for all our considerations!

you said
>i did not read all of this long thread.
but i read PAR 54/59 and 11/10

but no one here said that ntsc is "11/10"!luckily for ntsc people,derkarl only messed up the PAL PAR numbers in his lil documents!

and a final note;(this is just a repetition);your program is twistng the AR because you crop first and resize afterwards(that "16" compatible thing is making this offset.... i presume the calculus for this scaling and including the preservation of AR is correct(needed for 7xx x 576->640 x xxx resizing),but "16" is still a problem)

i'm not saying it's a big offset (as it probably isn't),but if you resized first,you wouldn't be having any of it!
yeap it would be a tad slower processing,but....at least i know i'm watching at perfect AR every time on my capturings....
every dvd-rip made with GK has a slight AR offset if GK is cropping first!(and it is!)

this was discused before here,and i wasn't the only one to notice this habit of cropping first (in my view wrong practice!)
http://forum.doom9.org/showthread.php?s=&threadid=46286
(the funny thing is that i was stating all this stuff on PAR there (as i am now!) too but i didn't know about PC producing ONLY square pixels,so i was unsure and erased some bits....but the part on resizing first as explained by me and justinus is very accurate...


i presume you don't have capture card,so you couldn't do such tests.....

ok,folks i'm off and won't come again to this thread;if you need any help with it,contact me via PM,as i won't go into all this thing again--> as it happens i have explained it at least 3 times by now,so you'll have to excuse me.....

gretins

/ivo

PS. no hard feelings,but now you do need a good explanation why should one use 640x464 instead of 640x480 on 4:3 display...

[TheWEF]

well, i should have known better. hopeless case. i'm gone... :)

[BaronVlad]

Originally posted by TheWEF
well, i should have known better. hopeless case. i'm gone... :)

:D Thanks WEF for coming here, I have to admit that I am very confused about this PAR..., if should have a look at your recommendations and talk with Karl about all this...:confused:

@Wilbert: Thanks for the GKnot part. One question: Dont you see a possibility to use GKnot for cropping..., you can change some things in the script afterwards, if you like, but replacing the need to write the Avisynth script on your own, that was my intention, you can choose the source resolution as theWEF said above. Problem is cutting the commercials, as I suggested here: http://forum.doom9.org/showthread.php?s=&threadid=51832

Hm..maybe you will find a way to make postprocessing more easy :)

But you made one big mistake in your parts, Avisynth as well as GKnot:

The author of these parts is not me, you did this great work, so you should put your name instead of mine there. :D

[Wilbert]

@TheWEF

well, i should have known better. hopeless case. i'm gone...
Before you go, I've two questions:

1) Do you think that it depends on the capture device whether 704x576 is a scaled or a croppped version of 720x576? All the links seem to assume that it is a cropped version, or am I misreading it?

2) Relating to the previous page. Suppose you capture at 768x576 (full pal resolution). Must this be resized to 640x480?

@BaronVlad,

@Wilbert: Thanks for the GKnot part. One question: Dont you see a possibility to use GKnot for cropping..., you can change some things in the script afterwards, if you like, but replacing the need to write the Avisynth script on your own, that was my intention, you can choose the source resolution as theWEF said above. Problem is cutting the commercials, as I suggested here: http://forum.doom9.org/showthread.php?s=&threadid=51832.
I know that's what you want, but I don't see any possibility to do that. Cutting commercials is not the only problem. Other problems are letterboxing (not possible), deinterlacing (especially pal), smoothing (the available smooth options are in general too soft), color correction (not possible). I just don't see how to do that in GKnot.

I will put up a new version this afternoon... I also want to see agreement on this par stuff :)

[TheWEF]

Originally posted by Wilbert
1) Do you think that it depends on the capture device whether 704x576 is a scaled or a croppped version of 720x576? All the links seem to assume that it is a cropped version, or am I misreading it?

at least in ivos case he seems to have gotten various scaled versions of the same frame.
this could be different with other hard or software, i don't know. without special testing it's impossible to tell what's the correct capture resolution (and the correct par). to find out if the captured frames are clipped or not i suggest this: connect your standalone dvd player to your capture card, capture and rip the dvd, compare frames...

here is my guess:
720x576 probably is the correct capture res for PAL (dvd frame is not clipped) and the par for resizing is 128/117. (-> 640x464)

if you find that the dvd frame is clipped, then it's probably pretty hard to tell whether the correct capture res is 704x576, par 128/117 (-> 640x480) or 768x576, par 768/767 (-> 640x480) and what you choose doesn't matter too much.

wef.

[Ookami]

Take a look at the last part of Karl's Capture Karten und aspect-ratio fuer Dummies ;-) (Arbeitsweise der Capture-Chips).

[BaronVlad]

@Mijo: Wer ? Ich oder WEF oder alle ?

:confused: :)

[Wilbert]

Yesterday I read the guide more carefully, and the answer is already given in there:

preface.html:

"704*576 with a PAR of 59/54 and 1 (max. 2) pixel overscan (black borders)
720*576 with a PAR of 59/54 and approx. 18 pixel overscan
720*576 without overscan -> not concurring with the ITU standards -> using a generic PAR (48/45)
768*576 with a PAR of 1/1 without overscan"

and also:

"With a BT 8x8 Chipset (common TV Capture Card) try 768 or 704 * 576 because of the (often) wrong scaling by the cards when 720 is used.
With Philips (mostly Asus/NVidia) try 704 (old drivers) or 720 (newer versions), as these cards have no scaler the resolution should be always right.
With ATI try 720 or 704. If you use 720 as I do, be sure to stick to the right PAR when resizing. Here it is the "generic PAR" of 45/48.
If you use a DV Codec, please remember that capturing with that one is limited to 720 anyway."

which implies the following:

768x576, 704x576 or 720x576 (without overscan) --> resize to 4:3
720x576 (with 16-18 pixels overscan) --> crop overscan --> resize to 4:3

I updated the guide. I added the NTSC counterpart:

"704*480 with a PAR of 10/11 and 1 (max. 2) pixel overscan (black borders)
720*480 with a PAR of 10/11 and approx. 18 pixel overscan
720*480 without overscan -> not concurring with the ITU standards -> using a generic PAR (8/9)
640*480 with a PAR of 1/1 without overscan"

I also updated processing.html (see changelog) and processing_avisynth.html. I think my part is finished, at least I don't know what else to change or add ...

http://www.geocities.com/wilbertdijkhof/htmlfiles280403.zip

[Der Karl]

Hi Wilbert,

sorry for my bad russian ;)

>which implies the following:
>768x576, 704x576 or 720x576 (without overscan) --> resize to 4:3
>720x576 (with 16-18 pixels overscan) --> crop overscan --> resize to 4:3

Right!

>I updated the guide. I added the NTSC counterpart:
>"704*480 with a PAR of 10/11 and 1 (max. 2) pixel overscan (black borders)
>720*480 with a PAR of 10/11 and approx. 18 pixel overscan
>720*480 without overscan -> not concurring with the ITU standards -> using a generic PAR (8/9)
>640*480 with a PAR of 1/1 without overscan"

Completely false!

NTSC uses a completely different timing _and_ scaling.
There are 486 scanlines with an "active part" of 52.66666µs/line.

German:

Das kann man nicht vergleichen! NTSC ist komplett anders. Die 13.5 MHz Samplingfrequenz lt. ITU
sind ein Kompromiß zwischen PAL/SECAM und NTSC.

Wie Wef schon schrieb: Hier http://www.uwasa.fi/~f76998/video/conversion/
ist alles sehr gut zusammengefasst.

Gruß Karl

[BaronVlad]

Wow,

Hi Karl, welcome to this forum ! :)

Thanks for your input, I will send you a PM, think it is more easy for both of us to write our suggestions in German words :scared:

[Der Karl]

@Baron Vlad

>This user's mailbox is currently full, and cannot be sent any messages until it is cleaned out.

Gruß Karl

[BaronVlad]

Grrr...

Yes I know ! I deleted some messages, should work now :(

Thanks Karl:)

[Ookami]

Hello Karl... Nice to "see" you here. Danke fuer Deine Muehe!

>Registered: Oct 2001

? :)

Too tired to write anything useful so I'll just check my mail and go to bed.

Good night,

Mijo.

[BaronVlad]

Hi,

sorry for this short post.

Tomorrow I will have a look into the guide (btw: where is steVe ?)

@Karl: thanks for the PM, I will also try to get this into my little brain tomorrow...

I have to leave now since my sweetheart was born exactly 27 years ago :)

[Wilbert]

>I updated the guide. I added the NTSC counterpart:
>"704*480 with a PAR of 10/11 and 1 (max. 2) pixel overscan (black borders)
>720*480 with a PAR of 10/11 and approx. 18 pixel overscan
>720*480 without overscan -> not concurring with the ITU standards -> using a generic PAR (8/9)
>640*480 with a PAR of 1/1 without overscan"

Completely false!

NTSC uses a completely different timing _and_ scaling.
There are 486 scanlines with an "active part" of 52.66666µs/line.
Thanks for the correction! Would the following be true (situations that can occur):

1) capping at 704x480 (7 pixels are cropped of horizontally, and 6 vertically) => crop/add black borders to obtain 711x486 => resize to 640x480.

I guess you could also crop to two pixels 702x480 and resize directly to 640x480.

2a) capping at 720x480 (9 pixels are added horizontally, and 6 cropped vertically) => crop/add black borders to obtain 711x480 => resize to 640x480.

2b) capping at 720x480 (upscaled to 720 horizontally, and 6 cropped vertically) => resize to 711x480 => crop/add black borders to obtain 720x480 => resize to 640x480 [of course, you could do this in two steps].

3a) capping at 640x480 (8 pixels are cropped of horizontally, and 6 vertically) => ok.

3b) capping at 640x480 (downscaled to 640 horizontally, and 6 pixels cropped vertically) => resize to 648x480 => add pixels 648x486 => resize to 640x480 (this can also be done in two steps)

I guess, in practice you can't see whether situation 3a or 3b is occuring (assuming that they can occur both)? In situation 1, most pixels are cropped. So, I guess best is to capture at 720x480 ?

I have to think about this more ...

[killingspree]

Originally posted by BaronVlad

Tomorrow I will have a look into the guide (btw: where is steVe ?)


right here...
just didn't have anything usefull to say... this AR discussion is a little over my head actually... (:
in addition i got quite a lot of work to do for the final written exam (Matura - oder Abi wie ihr sagt :-P) i got next week. Math is just killing me atm... i'm spending most of the time to get at least some into my head.

did i miss anything? if yes pls drop me a PM/email!

steVe

edit: like my new avatar? :D

[Wilbert]

did i miss anything?
No, except that the "NTSC par" stuff must be added correctly. I also noted there's nothing about NTSC deinterlacing. Perhaps you or BaronVlad can add this. All info can be found in Lukes guides IIRC.

Btw, I will ask Len0x to add telecide()/separatefields(). This should be enough to do the deinterlacing part in GKnot itself. (I also figured out, how to do the pal-resizing in GKnot.)

[killingspree]

Originally posted by Wilbert
No, except that the "NTSC par" stuff must be added correctly. I also noted there's nothing about NTSC deinterlacing. Perhaps you or BaronVlad can add this. All info can be found in Lukes guides IIRC.


sorry... i won't have time to do any serious work in the next week or so... afterwards i can again devote more time to doom9 and the guide!
still if you send me an email with some smaller changes to do i can add them.

cheers
steVe

[BaronVlad]

Hi steVe, nice avatar...

You should not do anything until your "abitur" is done !

But do we have a complete latest version of the guide ready ?

I somehow dont know exactly, is it steves site and the update of Wilbert (page 6 of this thread?)

Thanks.

EDIT: I got Wilberts part from page 7...:)

[killingspree]

Originally posted by BaronVlad
Hi steVe, nice avatar...

But do we have a complete latest version of the guide ready ?

I somehow dont know exactly, is it steves site and the update of Wilbert (page 6 of this thread?)


i've downloaded but still not looked at wilberts changes... but i'm quickly going to upload the new htmlfiles.zip to my page... only takes a minute anyway!
still wilberts link is the latest version. at least i haven't done and do not know about any further changes. wilbert?

steVe

edit: uploaded and ready for download!
@Wilbert: somehow it seems that something is changing some image pathes in a few html files (postprocessing and compression) while you are working on the guide. it has happened the second time now that the images/ path before the actualy jpg was gone. this time a hight and width = 40 has also been added to some paths. i don't have any explanation for this but could you just check if you find anything that is causing this? have fixed the image paths in the uploaded file!

[Wilbert]

still wilberts link is the latest version. at least i haven't done and do not know about any further changes. wilbert?
Yes, that is the latest version.

it has happened the second time now that the images/ path before the actualy jpg was gone.
That was my mistake, sorry. Won't happen again. (The problem was that I changed those two html pages on this pc, without unzipping the images.)

[BaronVlad]

Nice,

so let me summarize:

- I want to thank Karl for his PM -> PAL PAR will be in the guide as it is now.

- NTSC ? I dont know anything about NTSC, so I hope that Wilberts thoughts are correct now, anybody please confirm this ?! Otherwise we should cut this. (Page 7 of this thread) For this reason somebody instead of me should write the resize / Deinterlace stuff for NTSC also, otherwise it will be as it is now -> no NTSC Deinterlacing specifications directly in the guide, it is not that important I think, cause we linked to some threads.

- GKnot part: Do you want to change anything, Wilbert ? You said something about resize... ? If not we are almost ready with it, but one little point: In your picture one (A) you should choose "Bitrate = 128" in your sample, not your wav File to calculate the right bitrate. Also "C" in this picture: You can also choose MB via Dropdown and number of CDs...

- Is it ok for Len0x to add telecide()/separatefields()? If this is ready I think we can go online with the new version (including some minor changes in the Appendix..), close this thread and when it is online start a new one including todo list and newbie questions / problems.

Todo, as Mijo said: Connection of capture cards and (quality) problems with this

Your suggestions please
:)

[Wilbert]

NTSC ? I dont know anything about NTSC, so I hope that Wilberts thoughts are correct now, anybody please confirm this ?!
We will work this out with Karl, don't worry. Give me two days to think about it and to write it down properly.


For this reason somebody instead of me should write the resize / Deinterlace stuff for NTSC also
I can't do everything :) But once we know the ntsc stuff above, I can add a ntsc resize (sub)section.


In your picture one (A) you should choose "Bitrate = 128" in your sample, not your wav File to calculate the right bitrate. Also "C" in this picture: You can also choose MB via Dropdown and number of CDs...
I will correct this, thanks.


GKnot part: Do you want to change anything, Wilbert ? You said something about resize... ?
No, not in this version. If Len0x adds telecide()/separatefields() (I didn't ask yet), we can deinterlace with the GKnot options. Resizing is also possible, directly in GKnot. We can always change the GKnot section in a next update, but not know. The only problem is that I still can't see the clip when loading a huffyuv (directly or via a script) :)

[alky]

didnt read whole thread... but i am missing a delogo filter in the guide... i use this:
http://shelob.mordor.net/dgraft/delogo/delogo.html

[killingspree]

Originally posted by alky
didnt read whole thread... but i am missing a delogo filter in the guide... i use this:
http://shelob.mordor.net/dgraft/delogo/delogo.html

thank you... it has been pointed out to us already... it is part of our to do list (: nobody is using it atm though so we have are still looking for somebody to write this part (wouldn't be much but still...) *hinthint* :D

steVe

[Wilbert]

I have thought about it (NTSC resizing) more closely:

From the reference of Karl:
"525/59.94 systems have a line length of 63+5/9 (63.555...) µs, of which 52+2/3 (52.666...) µs is the "active" part that contains actual image information.
(The rest is reserved for horizontal blanking.)
52+2/3 µs × 13.5 MHz = 711 samples (pixels) per scanline.
In the vertical direction, there are 484 whole scanlines and 2 half lines. As above, all of them get digitized and half lines will be treated as if their missing other half belonged to the active picture, giving a total of 486 scanlines.
Thus, the active image area is 711×486 pixels. This is the actual area that forms the 4:3 (or anamorphic 16:9) frame."

Bottom line is that there are 486 scanlines. When capping 6 of them are cropped to obtain 480 scanlines. The following situations can occur when capping at: 640x480, 720x480 or 704x480:

1) capping at 704x480 (7 pixels are cropped of horizontally, and 6 vertically):
crop two pixels to obtain 702x480, and resize to 640x480. [PAR 72/79]

You can also resize directly (thus without cropping) to 640x480, making a small AR-error. (But people do this with PAL: 704x576-->640x480 too.)

2a) capping at 720x480 (9 pixels are added horizontally, and 6 cropped vertically):
crop/add black borders to obtain 711x486, and resize to 640x480. [PAR 72/79]

remark: in practice croppings/adds must be even.

2b) capping at 720x480 (upscaled to 720 horizontally, and 6 cropped vertically):
add black borders to obtain 720x486, and resize to 640x480. [generic PAR 9/10]

3a) capping at 640x480 (8 pixels are cropped of horizontally, and 6 vertically):
no need to crop or resize. [PAR 1/1]

3b) capping at 640x480 (downscaled to 640 horizontally, and 6 pixels cropped vertically):
add black borders to obtain 720x486, and resize to 640x480. [generic PAR 81/80]

Question 1) Does situation 3b happen in practice?

Question 2) If the answer to Q1 is affirmative, I guess the best is to advice people not to capture at 640x480. Since it is a bit hard to see whether situation 3a or 3b is occuring.

Question 3) Opinions? Is the above true? Karl, what do you think about it?

edit: there was a typo in 3b: PAR has to be 81/80 instead of 80/81.

[alky]

Originally posted by killingspree
thank you... it has been pointed out to us already... it is part of our to do list (: nobody is using it atm though so we have are still looking for somebody to write this part (wouldn't be much but still...) *hinthint* :D

steVe

hmm kay could write some about that...

but problem is i do not know a filter with "really good" results, delogo is a start, x-logo is better... but the perfect delogo filter would need some kind of motion detection to "move" picture information over the empty space a removed logo leaves.

anyone experienced enough in coding and video stuff ? :P

[Der Karl]

@Wilbert

It seems o.K. for me.
But: I dont have any experience in NTSC-capturing, so it ist only theory for me.
I am also not able to answer your questions - sorry!

Gruß Karl

[BaronVlad]

OK, as nobody is against Wilberts NTSC thoughts and it seems to be ok for Karl, we should put this into the guide (1-3, including Wilberts thoughts of hard decision...) thanks Wilbert.

steVe: Could you please merge this ? Then I will look into it, make some minor changes ("Helping hands" in the preface and appendix) and we can go online. As I said above, this thread will be closed and we start a new one,

including new "to do list" (logo, Connection of capture cards and (quality) problems with this, filters by Len0x)

Thank you all for your work in this guide :)

EDIT:

@Wilbert: Just saw your post: http://forum.doom9.org/showthread.php?s=&threadid=52550

Any reaction ? Something to confirm your thoughts ?

[Wilbert]

OK, as nobody is against Wilberts NTSC thoughts and it seems to be ok for Karl, we should put this into the guide (1-3, including Wilberts thoughts of hard decision...) thanks Wilbert.
Could you also update processing.html (the resize part). I will change processing_avisynth.html according to this.


@Wilbert: Just saw your post: http://forum.doom9.org/showthread.php?s=&threadid=52550. Any reaction ? Something to confirm your thoughts ?
I hope that jggimi sents something. Besides that, I didn't have any reaction so far. We will see ...

[killingspree]

Originally posted by BaronVlad

steVe: Could you please merge this ?

sure can as my written final exam (Abi) is over now... i just missed what i should merge... :confused: i'll do it right away tomorrow (too tired today...)

steVe

[Wilbert]

@killingspree
i just missed what i should merge...
I changed it for you:

1.8 changes by Wilbert (30/04)
- changed preface.html
- added NTSC resizing part
- changed processing_avisynth.html
- added NTSC resizing part
- updated processing.html
- added NTSC resizing

Changes are based on the link: http://www.uwasa.fi/~f76998/video/conversion/
Maybe you can add this link in preface.html and in links.html.

Could you merge it with your latest changes. I uploaded the three html files to my webpage:

http://www.geocities.com/wilbertdijkhof/new_html0705.zip

After you sent it to BaronVlad he can make his changes/updates. The results of the NTSC test captures (which nobody sent yet) can be added in a new version if necessary.

[killingspree]

thanks a lot (: greatly appreiated.

i'm going to merge the files as soon as possible (my computer is currently doing some encoding) and send a copy to bvlad. also i'm going to upload the new version to my webspace... i guess we are then ready for a new improved release...

just wondering if it wouldn't be smarter to do the tasks that are still open before releasing the new version. i mean something about a logo filter can't be too much work, if you really want me to i could do it... would require a few days though...
also i do not know what you exactly want to do with lenox's filters... do you just want to mention them, give a short explanation on what they do, or do you want to write an actual guide?
about the card <-> quality issues, how do you want to incorporate that? do you want to do a seperate page like the audio HQ excursions etc? doesn't this rather belong into a FAQ? just wondering... (:

steVe

[Wilbert]

just wondering if it wouldn't be smarter to do the tasks that are still open before releasing the new version. i mean something about a logo filter can't be too much work, if you really want me to i could do it... would require a few days though...
I think it is better to leave that for a next update. Cause I also want to add "delogo" using AviSynth. It is always better not to rush things ...


also i do not know what you exactly want to do with lenox's filters... do you just want to mention them, give a short explanation on what they do, or do you want to write an actual guide?
My idea is that when it is possible to deinterlace using GKnot (I guess that will be if the telecide and separatefields options are added), we can do the cropping, resizing and deinterlacing in GKnot itself. (Instead of loading the complete script in GKnot.)

[killingspree]

ok... i've merged your changes with the other files and uploaded it:

http://members.tripod.de/stefanstrobl/download.htm
http://members.tripod.de/stefanstrobl/changelog.txt

[edit:]ok, webspace seems to work again (:[edit]

@baronvlad: i've mailed you a copy (:

so this should be it...

steve

[BaronVlad]

Thank you steVe, I got the copy.

Wow, Wilbert, a whole lot of work with the PAL, NTSC..., it looks quite complete now.

One thing: In the GKnot part the audio should be corrected (select the bitrate in the main tab, not the wav) ;)

Just saw, that len0x said something about putting some other deinterlacer into the script (http://forum.doom9.org/showthread.php?s=&threadid=51832&perpage=20&pagenumber=2). Is it then possible for you, Wilbert to use GKnot, or should we go online and edit this part later on, btw I didnt get why you cant use GKnot. If you have the wrong deinterlacer, just edit the script, the rest can be done...

maybe: :stupid:

;)

[Wilbert]

One thing: In the GKnot part the audio should be corrected (select the bitrate in the main tab, not the wav) :)
:D :D :D I forgot that one. I will send it on monday to you.


Is it then possible for you, Wilbert to use GKnot, or should we go online and edit this part later on,
I think it is better to edit this part later on, because it cost a lot of time.

Oh, and don't forget this :) :
Changes are based on the link: http://www.uwasa.fi/~f76998/video/conversion/ Maybe you can add this link in preface.html [instead of the "reference ?"] and in appendix.html.

If you have the wrong deinterlacer, just edit the script, the rest can be done...
Yeah, maybe you are right.

[killingspree]

ok i've written the logo removal part now... it's rather short but i've added all the links to the detailed explanations descriptions.

no pictures have been added so you'll only need to dl the htmlfiles.zip

comments are greatly appreciated, i'm sure this part still needs improvement!

steVe

dl: (sorry i cannot access my webspace right now, will upload later - please PM until then)

[BaronVlad]

Thanks for your mail and the implementation of the logo filter steVe. :)

I sent you a mail back with some changes regarding the appendix and preface.

Please tell me what you think of it.

I think we are close to "Capture Guide version 2.0" :D

[ADLANCAS]

Hi,

in Capture Guide, capter - 4.2 using AviSynth:
"You have to find the settings only once. For the next capture you can use the same values, provided you don't change them in the capture settings."

and I followed the instructions and found that from TV capture I need same values, but from VHS I need to change them. I have tested with some captures to get this results and didn´t changed capture settings.

Do I need different values depending on my source ?
Depends on how good is my tapes?

my scripts is:
saturation=0.9
cu=-(1-saturation)*256
ColorYUV(off_y=1,gain_y=-3,cont_u=cu,cont_v=cu) # for TV capture
ConvertToYV12()
Histogram()

for VHS capture the best values are => gain_y=10

I know that you are making a review of this guide, but maybe this is important to explain the right way to make color adjustment.

Thanks,

Alexandre

[killingspree]

hi
thanks for your input
indeed you are right. if you switch sources you will also have to adjust your settings again. I think that you will not find two devices (TV, VCR, Camcoder) that have the same output. i guess we should mention that in the guide

thanks again
steVe

[BaronVlad]

As we have finished version 2.0 this thread is closed and I started a new one here: http://forum.doom9.org/showthread.php?s=&threadid=54067