VHS to kDVD??
 

Hello, I wanted to convert my old VHS's tapes to DVD's or KDvd's, but I don't know how.

1) How can I transfer my VHS's to the computer?


I've heard of pc cards, Digitatl VCR's (with a usb connection), and adapters.


2) Which is gives better audio/video quality?

3) Which is the cheapest?

4) Where can I buy them?

Thanks, in advance.

Hi LeeKuid,

May I suggest you get a Hauppage Win TV-PVR 250 :)
This way, you can capture at a very high bitrate (~12Mbps), and then transcode to KVCD/KDVD.
You'll LOVE the captured quality ;)
http://www.hauppauge.com/html/wintvpvr250_datasheet.htm

-kwag

Kwag,
 

:) I also capture at 12Mbps with Pvr-250 and use rewritable DVD. :?: Which template are you using for KDVD?

Hi Kwag, first of all thanks for the fast response. :D

I wanted to let you know that the main thing why I want to transfer to my pc is my son's first memories. I tried to do this from my Hi8 camcorder using Roxio Easy Media Creator 7, and everything work fine. I noticed that the resolution was 320X240 and it was in avi format.


1) Is there any way to make the resolution higher, by either using another program or transferring the video some other way?

2) Is transferring the video as mpeg better, if so how can I do this?


I also found out about a Dazzle Digital Video Creator that it has a chip that converts video to DVD quality.


3) Would the Dazzle be a better choice than the Hauppage Win TV-PVR 250, why or why not?


Thanks, and sorry for all the questions.

I've used my PVR-250 very actively since I bought it last year and it's a very good card for capturing. You should definitely consider buying one.

However, I don't like the filtering it does by default so I've disabled them all (I use WinTVCap which uses an ini file for settings) and do all the filtering in the avs script.

Hello, you guys say that the Pvr-250 can capture at 12Mbps.

1) What is the resolution at 12Mbps?

2) Can you really tell the difference between 8Mbit/sec, and 12Mbit/sec?

3) Is there a cheaper card that does about the same that the Pvr-250 can do?

The resolution can be basically any of the VCD, half-D1, SVCD or DVD resolutions. The difference between 12Mbit/s and 8Mbit/s can probably be seen during a high motion scene. The datarate is adjustable so you can choose just about anything between 0-12Mbit/s, VBR can also be used.

Not with onboard mpeg2 hardware encoder capabilities, as thats the goal from that card.

At this time, I don't think so.

Edit: I posted (again) too slow :lol:

-kwag

Hi,after some reading here I see you were talking about
capturing at 12Mbit/s,I guess this is capturing "directly" to MPEG2???

And I also had a look at the options on my PinnacleDC10plus card,
there I have range from 500 to 6000 kbytes/sec.
(This card don't capture to mpeg).

When I capture I use 3300 kbytes/sec. and res. 768x576,
this give a filesize app. 10GB pr. hour. including PCM audio.
The encoded video looks great.

Should I use full datarate(6000kbytes/sec) when capturing,
or is it just waste of HD space??

Thanks
------------------
viking

I'd go for max if I had the diskspace to do it :wink: And yes, PVR-250 captures directly to MPEG-2.

Ok,
so from here I capture at full datarate,
full resolution and to make it DVD compatible,
capture audio at 48kHz.

Just a theoretical question at last,will the avisynth scripts work just as
good with standard DVD matrix and a cbr of 8000 as they do
with KDVD matrix?,or are they "designed" for the matrix?
(maybe a offtopic/stupid question :roll: )

-----------------
viking

Well, the DC Series do have an excellent mjpeg hardware encoder on board as they where/are sold as semi professional capture cards.

Keep in mind that mjpeg is like mpeg but in YUY2 AND like "I" Frame only while CBR capturing.

So a professional Studiostream can be found beside some others as

- Betacam SX (Mpeg-2 @18 MBit/s)

- Betacam IMX (Mpeg-2@ 50 MBit/s)

And all these are "I" Frame only as thats needed for frame acurate cutting and also CBR is used.

Betacam SX already is quite lossy as "I" Frame only would need much more bitrate.
So Betacam IMX at 50Mbit/s is a mega HQ Studio way of digitizing.

Now your DC10 (or mine DC30) are able to capture at 6000/kbytes per second using a very good Zoran/Philips chip.

6000*8 = 48000
48000/1024 = ca. 47Mbit/s!! And that at 4:2:2 YUY2! (PVR 250 mpeg2@MainProfile uses 4:2:0 YV12, Digi Betacam uses mpeg2 4:2:2 profile!)

So the VERY big potential of that card is just by 20% used if using for digitizing "TV Sheep-crap" ;-)
The only disadvantage is that this card doesnt got component Inputs like the mega expansive Targa system (in the past).
But s-video connection (means Y/C separated) at least is a very good quality mode/connection.

So this card can even be used to digitize streams provided by a Betacam SP Device and that was the standard some years ago in broadcasting editing services.

See the point? Thats why you should everytime "smile" when looking at this card. :)

A friend of mine (from whom I got my DC30) used that one on a MAC for preparing/cutting video jobs to give them to the WDR afterwards (West German Broadcasting Station).

BUT! 3300kbytes/s when capturing 768x576 is at the limit!
Why? Cause even if TV Signal is crap (in relation) and even its less detailed - on the other hand its much more complex cause of uneasy components like noise! And if you would inspect your stream very carefully at 200%-400% Zoom in Vdub you already can see some artifacts, cause mjpeg needs much more bitrate then mpeg2 when using B and P Frames.
And thats the goal from mjpeg as its like I frame only, means now extra compression-lossy-routines given like predicted and Bidirectional frame algorhythms (P / B). Give it room to breath and an excellent signal as input and you can see the difference.

:wink:

BTW: We talked at gleitz forum about that Picvideo3 YV12 issue!
It seems that avisource() from avisynth 2.5x on uses as default a request of a YV12 stream. And if the codec is able to provide that, then the picvideo3 internally changes the colorpspace to YV12.

Now that Pixel_Type="YUY2" workout "could" be the solution, ... IF Its proofed that picvideo3 REALLY doesnt change the colorspace by that!
But if he again re converts the conversion to YUY2 again, that would be a mess!

So I personally would stay with picvideo2 till that is proofen not to be the thruth 8O
:wink:

Thanks for the info., Inc.
This is very interesting stuff.

Seems like the card is ok then.
Im capturing a clip right now with full data rate that ill encode
to see the difference from 3300kbytes.
The main reason I bought the card was to capture 9(!)
cassettes that I recorded with a SVHS-C camera.The camera is
outdated(made in 1998) :!: ,and I don't use it anymore.
I replaced with a mini-DV camera.(Panasonic NV-GS 50).
So I use S-Video input when capturing from the old camera.
But when capturing from VHS,I use composite,since my vcr don't
have s-video output.
The reasom why I used 3300kbytes,was that,as you said,broadcasted
stuff is crap more or less,and VHS is a poor format.
But I see that now,as we want to get the absolutely best quality and
most of the details,we need max. data rate.(still learning :roll: )

About the PICvideo codec,last week I formatted my pc,reinstalled
everything,and installed Picv 3 codec,
and tried DirectShowSource() and AviSource()
and they report YUY2 for Dirshow() and YV12 for AviSource().

When playback the video in WMP using DirectShowSource()
the colors are clearer/stronger than when I use AviSource().
But that can be a vfw / wdm issue as you said earlier.
Ill make a try with "Pixel_Type="YUY2"" .
I think I got PICv 2 somewhere on my HD so ill make a test.

----------------------
viking

MAKE A TEST using picvideo3!!:

Do use this cript:

Open it in Vdub and safe it in Vdub using "shift-1" .... make a jpeg or PNG from it and post it here! *please!!!!* :)

I did as you said but got this error from VDub:

AviSynth open failure:
StackVertical:image formats don't match

---------------------------
viking

They don't fit because they don't have the same colorspace. You'll have to open each part on its own (a, b and c) and take a screenshot of the same frame, try to take it from a scene with a lot of red for example. I recommend using PNG since it's a lossless format.

Thats when scripting fast out of mind :eeks:
:banghead: :)

Good Morning!
I left out the stackvertical stuff and used a,b,c script lines one by one.


http://www.digitalfaq.com/archives/i.../2004/11/2.jpg

http://www.digitalfaq.com/archives/i.../2004/11/3.jpg

http://www.digitalfaq.com/archives/i.../2004/11/4.jpg

And heres the PICvideo3 settings(default):

http://www.digitalfaq.com/archives/error.gif

---------------------
viking

EDIT by Incredible:
I changed the preview of Vikings "orig"! pics to JPG converted ones on my server so the loading of this post becomes faster than when PNGs are used ;-)

@ Viking and all Picvideo3 users ...

It seems that this issue "could" be solved:

I over-layered Vikings pics in Photoshop and used the "Difference" Mode in the Layer view.

This is the result ...

http://www.digitalfaq.com/archives/i.../2004/11/5.jpg

http://www.digitalfaq.com/archives/i.../2004/11/6.jpg

SO.... If Pixel_Type="YUY2" is used in avsisource() it seems that the picvideo3 decoder is FORCED to provide the original encoded YUY2 state.
If just Avisource() is used without flags, then Avisource() forces the Picvideo3 decoder to provide a to YV12 colorspace converted stream.

Conclusion for me: Avisource("X:\xxxxxx.avi", Pixel_Type="YUY2") when using Picvideo3 is the way to go ... IMHO

Thanks a lot Inc.,you solved the problem :!: :ole:

From here I use
Avisource("X:\xxxxxx.avi", Pixel_Type="YUY2")
for my captures.

So the "final" script will be like this:
---------------------------
viking

Looks nice!

But do a final test and apply at the very end of your script again a ...

info()
bob()

I would like to know which's the fieldorder now reported by avisynth! and do some framesteps forward in vdub using a movement scene of your capture.... if the result is ok, then NO! back 'n forth behaviour will do occur (if happen,vertical flickering is normal).

AviSynth reports this:

Fieldbased(Separated)Video: NO
Parity: ASSUMING TOP FIELD FIRST

And I looked at the movement scenes,everthing looks OK.
as far as I can see.

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

viking

I did some corrections to your script:

You should also download the latest kerneldeint.dll, http://gast3.ssw.uni-linz.ac.at/~kp/...eint_1.5.2.zip . There were some bugs fixed, one affected the motion masking portion.

Boulder, one question ...

why do you force after the stupid bobber (bob(x,x)) a reallocation of the fields by 4,1,2??

I think it -was- right as his stream ended up ok?

Also the DC10/DC30 do provide at default TFF streams (only as you also did assume a BFF after the bobbing).

I dont know but does make an assumption of a Fieldordering makes sense in a bobbed state? As the stream in that temprarely state is truely progressive? I only do know those assumeXXX commands placing before the bobber or after the reinterlacer - means when the stream is in interlaced state?

NO straight doubts, but nice questions.


I only remember that discussion between Kika and Scharfis_Brain at Gleitz.de where something like this ended:

bob()
separatefields()
Selectevery(4,0,3)
weave()

... does not change the fieldorder as its compensated by 4,0,3 as bob gots a bug related to an unwanted internal fieldorder change

bob()
separatefields()
Selectevery(4,1,2)
weave()

... does end up with a changed fieldorder

now ...

kernelbob()
separatefields()
Selectevery(4,1,2)
weave()

.. here when using kernelbob() its the other way around as kernelbob() keeps the fieldorder internally ..

kernelbob()
separatefields()
Selectevery(4,0,3)
weave()

... does change the fieldorder.

hmmmm ....



:arrow: thats why I did first a script using an imported capture of my card/driver by just using .... assumeXXX().bob() ... when I captured the first time, ... to recognise the true order of the fields delivered by my capturedevice/driver.

So in every Avisynth script where I do process an interlaced footage I do apply AssumeTFF() right after the import of a capter based on my capturecard ... so everything is at it has to be.
Avisynth at default DOESNT interprete the fieldorder out of the source! Its just avisynths default! which is used when doing an info() on a simple imported avi in avisynth.
I heared that IF mpeg2 captures are treatenn via DVD2avi .... mpeg2source does provide the right fieldorder flag into avisynth - but Im not shure ... and also here it has to be proofed IF the capturing application does set the flag in the mpeg stream right ....

Interlaced ..... oh oh oh oh oh :D

I just did that to keep both SelectEvery lines the same (easier to remember in future cases), and to make sure that the stream is TFF when it hits KernelBob as AssumeBFF() followed by SelectEvery(4,1,2).Weave() produces TFF output. It would be easiest if KernelBob used the field order flag set by Avisynth instead of having to enter the order parameter every time :wink:

(note:I increased my post above)

Another point to try would be ...

Kernelbob() with a threshold set to ZERO and no other enhancements set should behave the same like Bob(), means no adaptive interpolation.

You could do a test...
v=Avisource(....).assumeTFF() # or the ACTUAL Fieldorder provided by your card/driver
a=v.bob(0,x)
b=v.KernelBob(order=x,sharp=false,threshold=0)
subtract(a,b)

looking at the difference of both bobbers

Next step:

v=Avisource(....).assumeTFF() # or the ACTUAL Fieldorder provided by your card/driver
a=v.bob(0,x).separatefields().selectevery(4,1,2).w eave().info().subtitle("This is the result of Bob()",10,400)
b=v.KernelBob(order=x,sharp=false,threshold=0).sep aratefields().selectevery(4,1,2).weave().info()..s ubtitle("This is the result of kernelBob()",10,400)
interleave(a,b)

... doing a comparison "one after one" of these normaly in a NOP operation ending streams incl. the report WHICH fieldorder results.

Im at office so Im just able to write out of my mind ... without script checking :)

I thought about that zero threshold as well, I'll have to test it. However, my capture script for interlaced footage is already slow enough so I can't bob and reinterlace twice, it would take several hours to finish a 45-min episode :lol:

EDIT: btw, ColorMatrix is something which might be useful if the colors are off after encoding :wink:

OK, I did some testing.

The difference between Bob(0,0.5) and KernelBob(order=x,sharp=false,threshold=0) is small, unnoticable without using Subtract() but it looks like the edges are the areas of difference.

AssumeTFF().Bob(0,0.5).SeparateFields().SelectEver y(4,1,2).Weave().Info() = TFF
AssumeTFF().KernelBob(order=1,sharp=false,threshol d=0).SeparateFields().SelectEvery(4,1,2).Weave().I nfo() = BFF (WTF?!)

Using AssumeBFF() and order=0 makes both TFF.

If TFF is assumed and I add AssumeFrameBased() after KernelBob, it's TFF (as Avisynth defaults to BFF).

Looks like KernelBob() swaps the field order..

8O ... holy ... In our tests it was the other way around ... but wait! I think we didnt add assumetff() right at the beginning!!!
As many people do forget that avisynth assumes BFF as default when beeing feeded with avis. So it seems thats the other way around, that Kernelbob does change the fieldorder as you said .... hmmmm

These little funny command additions could mess up everything .... yeah! Lets beleive in avisynths internal process *lol
I think thats worth a big testing .... beside that AC3 thing :lol:

Actually AssumeFrameBased() belongs to KernelBob(), that was in scharfis_brain's original function. Leak just forgot to add it in the dll version, and I had some strange issues before we noticed that. Maybe they happened because the assumed field order is swapped?

So the conclution is to use the script as it is,to keep right
field order? :?

But I did tests today with and without bob(),
and I can't see any difference on the final video.Only longer
encoding time.

But another question,whats normal colorspace for DV captures?
When I tried AviSource()Info(),avisynth reported RGB24,
and when I used DirectShowSource()Info() it reported YUY2.
Maybe it is an idea to use pixel_type="YUY2 at this videos to??

I know this is bottom field first video,so the script would be like this(without bob() ):
------------------------
viking

I think the native colorspace is YV12 (I have no DV experience). However, with DV material you get a headache with the different decoders as some of them screw up the chroma upsampling and you need to fix that.

This forum might interest you : http://forum.doom9.org/forumdisplay.php?s=&forumid=59 , especially the reinterpolate420 -thread could be useful.

Interesting reading,my panasonic DV codec outputs only RGB24.
So after reading it seems I have to try ffdshow DV decoder,
that gives 4:2:0 YV12 output when using
DirectShowSource() with AviSynth 8O

----------------------
viking

Does anybody know the difference between the Win TV-PVR 250 and the Win TV-PVR 150 model?

You meant the 350 :)
The PVR 350 is identical to the 250, except it has a hardware MPEG decoder, and TV out.
That's all the difference.

-kwag

Nope, there is also a Win TV-PVR 150 model. I seen it in the stores and it looks just like the Win TV-PVR 250, but I just don't know the difference. I've even asked the people that work there and they don't know either.

Ok, I found the differences in this link:

http://www.hauppauge.com/pages/compare_pvr.asp


1) Which of the first four would you guys go for? Why?

2) Do the MCE models only work with Windows XP Media Center Edition?


I also have in mind of going for this one:

http://www.pinnaclesys.com/ProductPa...26&Langue_ID=7


3) What do you guys think about this one in comparison of the other four?

I can see clearly that the 150 doesn't have MPEG-1 encoder on the chip :!:
So I guess the 150 is a trimmed down version of the 250.

I would go for the PVR-350 ;)

-kwag

Thanks kwag. :D

What gives a better video SVideo, Composite, or Coaxial?

So, what did you think about the Dazzle?