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. |
Quote:
|
Quote:
He's just been too damn busy to look into the code and make calcumatic compatible with dgindex :lol:. But I agree that this would be the right timing to do it :D. Cheers |
Quote:
And it won't be this week end, for sure :? -kwag |
Ok, we'll wait then ;-).
|
New release,
watch the changelog in the announcement thread. |
Looks amazing.
|
:jawdrop: :jawdrop: :jawdrop: :jawdrop: :jawdrop:
Yes it does :D:D:D -kwag |
Great Upgrade, Mr. Andrej!
@Incredible
It's really a major upgrade :!: Keep up the excelent work! :D 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" :wink:
Thanks for the new version, I'll try it on my next capture today :D |
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 |
Quote:
But let me tell you, its a commendable piece of code you have written :D . |
Quote:
I don't understand fully the difference between the two options in the "non-ITU" settings. |
Quote:
Feeding a 696x576 PicVideo MJPEG capture I get this: http://www.digitalfaq.com/archives/error.gif 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 ;) |
Quote:
|
Yep I know .. 51.560µs
I think Ill have to rewrite the import parsing routine. |
Site design, images and content © 2002-2024 The Digital FAQ, www.digitalFAQ.com
Forum Software by vBulletin · Copyright © 2024 Jelsoft Enterprises Ltd.