Trying to understand math in resizing DivX to vcd

[ritmo2k]

I cant seem to figure out the math needed to perform this?
I have for instance a DivX that is 640x304. What calculations would I use to re-encode to vcd?

I am using:

BiCubicResize(352,150,0.00,0.75)
AddBorders(0,45,0,45)

which is very close, but I know its not right. I hate doing a hack job, anyone know what calculations I would perform?

Thanks,

[western shinma]

This sounds familiar, but just keep in mind that it is easier to use 320x240 for your calculations, since the VCD will be resized to 4:3 during playback anyway. Edit: Of course you will still use 352x240 for your final encode.

So since 320 is half of 640, just use half of 304 for your vertical.

[ritmo2k]

Cool!
I wanted to email you directly, but couldnt get your email!
Thanks as always dude!

That makes sence! I am using 150 now, and its close.
304/2 is 152... Nice....


regards,

[mb1]

Halfen the resolution is completely wrong.

You have to consider that DivX is pixel aspect ratio 1:1 and VCD is 1.092 (PAL).
http://toolbox.sgi.com/TasteOfDT/documents/video/lurker/pixelaspect.html

And PAL has fixed VCD resolution of 352x288 (NTSC 352x240).

So correct for PAL:
BicubicResize(352,184,0,0.6)
AddBorders(0,52,0,52)

Correct for NTSC:
BicubicResize(352,152,0,0.6)
AddBorders(0,44,0,44)

For bicubic resize a value of 0.6 gives better quality than 0.75 ...

[ritmo2k]

Isnt that what i we said though?
I was incorrefctly using 150, but now using 152 for vert?
Is this not what you said to use as well?
What am I missing?
jlc

[mb1]

Reading the postings above you resize now to 320x152 (half of 640 and half of 304) which is wrong.

[western shinma]

Originally posted by mb1
Correct for NTSC:
BicubicResize(352,152,0,0.6)
AddBorders(0,44,0,44)
[/B]

Looks like we're in agreement after all. What I said was that he should use 320 for the calculations, which was meant to imply that he would of course go back to using 352 after figuring out the vertical resolution. I'm sorry this didn't come across clearly, but ritmo2k obviously understood what I meant.

Likewise if I were doing PAL calculations I would use 384x288 to figure things out and then go back to 352 for encoding.

OK, I edited my original post to eliminate further confusion. If you think I'm just covering my ass, you could look at the last thread where I explained my method to ritmo2k in far more detail, but I'm not going to dig it out now.

[ritmo2k]

Thanks Western Shinma!
I knew what ya meant...

Hey, my nick is also my Yahoo account (get it) trying to avoid spam...

Email me offline if you dont mind! I would really be greatfull!

Thanks,

[DDogg]

You may find this of interest also:

http://rilanparty.com/vbb/showthread.php?s=&threadid=5544