The only problem when switching will be no more support via calcumatic i.e. - if its still used.

.... so Karrrrrrrrrrrrrrrrrl. Keep Calcumatic up-to-date by taking in the evening a glass of wine and apply some lines to the code so dgindex outputted d2v's will be supported.

If you dont have time and if I can help you .... just rrrrring da bell.

Thanks, Phil. Typing from memory. Will get manual.

LOL
He's just been too damn busy to look into the code and make calcumatic compatible with dgindex .
But I agree that this would be the right timing to do it .
Cheers

__________________
Rui

Yes I have
And it won't be this week end, for sure

-kwag

Ok, we'll wait then .

__________________
Rui

New release,
watch the changelog in the announcement thread.

Looks amazing.

Yes it does

-kwag

@Incredible

It's really a major upgrade

Keep up the excelent work!

Kudos,

Incredible, Incredible.

First little "cosmetic" bug : in the "show/preview/Safe script". It is "save". The same for the button name.
Thanks

Edit: I add an other bug. "F3" answers that there is no source loaded, even if there is one.

And "shure" should be "sure"

Thanks for the new version, I'll try it on my next capture today

Incredible,

How is the resizing from NTSC to PAL......and PAL to NTSC handled ???

Also is there a brief manual available for the options yet ???

Spelling related issues will be surely fixed

a) @Phil
So only via HotKey that issue is present? Not via Pulldown choice?

b) @Boulder
I got in mind this morning that the active µs which differ from standard will only be taken into account when avi-captures are the input, so in your case as you feed DgIndex with your PVR captures, that should also be an option in case of d2v-inputs.

c) @Supermule
How is it handled? Also like all other calcs, means respecting the active µs and source PAR. mpeg4 inputs will be recognised as std. 52.000µs (no matter if PAL or NTSC as these do differ minimal which would be compensated anyway as a MOD based output will be the result.
BUT! NTSC will be treaten as active 480 height, means 525/60Hz "cropped", as full active NTSC is 648x468 ... means in case of PAL-->NTSC the image should be a bit "bigger" in a whole (factor 468/480) and vice versa at NTSC-->PAL.
Look here (thats the source reference of PARanoia):
http://www.uwasa.fi/~f76998/video/co...nversion_table

Converting between Formats:
Look at Point 4.6 in the link

Means the PAR and ARs will result full ok, just the imagesize differs by a factor of 468/480

Well, coincidently that links also the source for my information, but sometimes I wonder how much would a good or bad PAR(within limits) effect the naked eye viewability of a commoner llike me!!!! .

But let me tell you, its a commendable piece of code you have written .

Fortunally, the menu works correctly. Only the hotkey fails.

I don't understand fully the difference between the two options in the "non-ITU" settings.

Ah, I don't have the PVR anymore as I got me a second-hand Hauppauge card with BT878 chipset some time ago.

Feeding a 696x576 PicVideo MJPEG capture I get this:


I think it would be better to leave the video as it is or bob it instead of separating the fields. Also, the video length is incorrect - PARanoia shows 9368 frames as the length but the clip is 38113 frames long.

Thats odd!

First there is NO routine applied when whatching the preview in the MainWindow (not avs window)!

Internally a simple API vfw call is used to receive the video informations and playback of an AVI file.

Hmmm .... I did test some picvideo avi captures and length and size in the prew.Window are ok ...

EDIT: Well the problem of the preview Main Window results of an uncommon 696 width! The purpose was to correct avis when using std. widths like 704 or 720, 544,528,480 etc, and not already fixed ones in their width

I use 696x576 because that's the closest resolution to the actual sample rate, BT878 chip and Hauppauge's drivers. Anything above it is scaled.

Yep I know .. 51.560µs

I think Ill have to rewrite the import parsing routine.