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.