Yeo I know thats "still" a limitation but will be made more tolerant.
In your case if you would go higher, that would mean cropping the width before in a more significant way to still keep the 720 max mpeg4/nero "Standard Profile"-width wich is 720. And thats also the max width for encodes accepted on the most mp4/AVI supporting SAPs in that Inputmode.

If for instance you got a PAL anamorph 720 source and make a "to-nonamamorph" PAR1:1 resizing, then the max width will be 1040 as suggestion (Full DVD 720px width @ PAR1:1 @ roundedDownMOD16!), so watch out as for SAP compatibility you should then lower the height till the final width gets 720 or 704.

Anyway that limit when more sizing up the height is wanted will be kicked out so or so as THIS would make Pan-Scanning of the source image Posible (if someone really needs that as it kills Moviearea in a hughe way)

I dont remeber the review site (*grrr) but there are some Chips on specific players used which just do use the same routine as in mpeg1/2 mode, just a proper 1:1 recognision is added. Means also non-Par 1:1 is supported to be played back correct on TV, like 720x576.

But thats as said no standard (now) and should be tested.

For my personal test it doesnt make sense to crush an 4:3 image into 720x540 as the height will be scaled for the TV and NO interlaced encodes are possible. 702(704)x576 for me is (still) the perfect way to end up for (still) analogue TV purposes.

In case of interlaced you would have to MotionBob the source to for example 720x540 but at 50fps! to at least keep the known movement-smoothness in interlaced video. But if you deal with a fieldblendedsource then happy-blending will be on the TV or Plasma/LCD

Fabrice, thanks for the bugreport on the overhead of the NTSC target size!
There maybe occured a hughe error when coding more into the deep of the mpeg4 resizing core, so ....

The wanted PAL/NTSC mpeg2/1 final targetsize is now matching.

@ ALL

TRASH 0.08 or 0.07 and change to 0.09 cause of the fixed bug which was discovered by fabrice. Its was probably present since the mpeg4 target support.

http://home.arcor.de/packshot/PARanoia_0.09b.exe

finally..!!!!!!!!!!

this version works for me, i was going insane trying to get this to work with my setup...thanx for the new update.!

Downloaded Inc,

I can't make resizing height as original height yet, am I doing anything wrong?.

Edit: Ooops, I see you already edited your post. I guess that resizing up it's not implemented...

In some cases in mpeg4 resizing you can, but when I recognised that it isnt totally supported I edited my post.

The "little" tricky thing is, that the recommended eight result forces internally to be the maximum height for avoiding too much copping of the width.
On the one hand this "safe barrier" makes outputs less cropped in the width, but on the other hand no panscanning is possible. So this means a new "if" routine above the present routine.

Just a slight cosmetic bug: 'safe' should be 'save'.

ok, this may set me up for an attack, but I never had tried resizing before encoding, and I cant believe the difference, i used to got right into it with what ever TOK gave me....all I can say is WOW..! the quality of the final video is what I have been looking for.. not everyone knows everything, even after being here into this site for 2+ years I just thought that what I was doing and learning was fine, and BOOM>>>! something I had not really tried turns out to be the best thing ever..........

just thought I would mention this is all..........................................

You mean that you used to encode in full res (720x480) ?

no, i just never used any resizing tools to get the right size down before encoding, now i see the results of using a program that adjusts the size to the proper size before encode..........i mostly do 352x240 or 480x480.or 352x288 - 480x576.........but would let MovieStacker and TOK do the work.

Settings will be written into an ini file on exit und loaded when starting again.

Mpeg4 Resoltion Profiles added in "Settings".

http://home.arcor.de/packshot/PARanoia_0.10b.exe

First try, first shot.
v0.10b
Avisynth in default %programfiles% folder, that in my spanish XP version is "C:\Archivos de programa\AviSynth 2.5"
(I don't remember if i added 2.5 or it is the default folder, does it matter?, avisynth is correctly installed as it works fine always)

http://www.digitalfaq.com/archives/i.../2005/10/9.png

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

Would it be possible to add in "avisynth script" menu, an option for load a base avs scipt from maybe a paranoia\scripts subfolder. Then at source-resize usual generated script, paranoia would append the base script.

MUCH RESPECT PLAYER!! 8)
Love the tool

I do quote my To do List of the first post:

Regarding your error. Well I'll have a look at it.
Meanwhile do put a copy of MPEG2Dec3.dll in PARanoias folder.

Sorry Inc, i missed that list.
Also i did your suggestion as error message say it, thanks.

And a "little" hint: Do switch to DgIndex and dgdecode.dll
--> No Frameloss --> More options --> more developed

Thanks, i have both, only testing.

:?: Off topic, but with DgIndex which option should I use for 23fps "Film", "Honor Flags" or "Force Film"? In DVD2AVI, would use 'Force Film".

The mode are : Honor pulldown, Ignore pulldown and Force film.
The mode to use is still Force film.

Note: there is a very good manual delivered now.

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.

:D Thanks, Phil. :oops: Typing from memory. :D Will get manual.

LOL
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

Yes I have :roll:
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

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!!!! :roll: .

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

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:
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 ;)

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.