Resize calculator PHP

[smok3]

ok, so i can add those numbers at the pulldown if you wish:
32/27 = 'ntsc 720 wide' - naming ok?
40/33 = 'ntsc 704 wide' - naming ok?
or will this just add to the confusion?

[SeeMoreDigital]

edit2:
The reason being I normally encode to square PAR.In that case...

Do what you did in post #60 (using VLC player).
Hard crop the black mattes, green lines and image roll away.
Using the remaining cropped image. Divide the image width by the height height which will give you the movies aspect ratio

Cheers

[smok3]

lol, ok i rest my case :)

[krosswindz]

In that case...

Do what you did in post #60 (using VLC player).
Hard crop the black mattes, green lines and image roll away.
Using the remaining cropped image. Divide the image width by the height height which will give you the movies aspect ratio

Cheers

Thanks.

ok, so i can add those numbers at the pulldown if you wish:
32/27 = 'ntsc 720 wide' - naming ok?
40/33 = 'ntsc 704 wide' - naming ok?
or will this just add to the confusion?

Wouldnt the same apply for PAL as
pal 704 wide = 16/11
pal 720 wide = 64/45

Similarly things would change for normal NTSC/PAL?

[smok3]

yeah, we need 4x PAL and 4x NTSC with
a. proper numbers?
b. proper names for the presets?
c. proper and short general explanation how they are mapped to each other?
suggestions?

maybe like:
---------------------
pal aa/bb
pal fullscan aa/bb
pal wide aa/bb
pal wide fullscan aa/bb
ntsc aa/bb
ntsc fullscan aa/bb
ntsc wide aa/bb
ntsc wide fullscan aa/bb
---------------------
?

the word instead 'fullscan' could be 'digital' but sounds kinda cheesy?

[krosswindz]

my 2 cents

The PAR values need to be rechecked however. If someone can confirm these values.

NTSC (704/480) = 10:11
NTSC (720/480) = 8:9
NTSC Wide (704/480) = 40:33
NTSC Wide (720/480) = 32:27

PAL (704/576) = 12:11
PAL (720/576) = 16:15
PAL Wide (704/576) = 16:11
PAL Wide (720/576) = 64:45

The standards are the same the only difference that source video frame size is different.

[SeeMoreDigital]

Hi krosswindz,

I'm getting quite confused by your posts now :eek:

If you normally generate encodes with "square" pixels. Why are you so interested in "non-square" pixel PAR values?


Cheers

[unskinnyboy]

SMD, My thoughts exactly.

krosswindz, I quickly skimmed through this thread now, but can't really understand what you are on about. What's your confusion about aspect ratios exactly? You seem to be making it harder than it has to be.

[krosswindz]

Hi krosswindz,

I'm getting quite confused by your posts now :eek:

If you normally generate encodes with "square" pixels. Why are you so interested in "non-square" pixel PAR values?


Cheers

my question was more like are those PAR values the correct ones for the videos of those source. I always encode with square PAR.

SMD, My thoughts exactly.

krosswindz, I quickly skimmed through this thread now, but can't really understand what you are on about. What's your confusion about aspect ratios exactly? You seem to be making it harder than it has to be.

If those PAR values are correct IMO


source PAR * cropped width
source DAR = ------------------------------
cropped height


Since the aim is to keep the target DAR as close to the source DAR as possible then choose a mod16 res which fits the target DAR with the lease amount of error.

edit: In this case cropped width and cropped height are with regards to the source frame size of being either 720/704 x 480/576

edit2: this DAR would be close the MAR (movie aspect ratio), which SMD uses in aspect ratio signaling calculator.

[smok3]

unskinnyboy, this thread has actually lead (some of us) to some conclusions,
a. that are no complete calcs out there, even if the theory behind it is really simple,
b. there is also a thread started by 2bdecided that never got exact answers - which means that no one really knows how exactly the theory patches to practice, check it out.

[unskinnyboy]

Since the aim is to keep the target DAR as close to the source DAR as possible then choose a mod16 res which fits the target DAR with the lease amount of error.A DVD can have only two DARs, 16:9 or 4:3, period. Your aim should be to get as close to the theatrical AR as possible. In the rare event that the DVD AR (I am referring to the AR of the DVD image here, after cropping away all black, NOT the DVD DAR) is different from the theatrical AR, then that's what you should get close to.

You shouldn't be hung up on the DVD PAR values. Yes, your ratios are right AFAICS, but when you encode to AVI, how do you plan to use those DVD PAR values?

P.S: Can you please stop editing your posts once you've submitted them? Twice I had to revise my replies because you changed your post.

[SeeMoreDigital]

I'm in total agreement with unskinnyboy's comments....

[krosswindz]

A DVD can have only two DARs, 16:9 or 4:3, period. Your aim should be to get as close to the theatrical AR as possible. In the rare event that the DVD AR (I am referring to the AR of the DVD image here, after cropping away all black, NOT the DVD DAR) is different from the theatrical AR, then that's what you should get close to.

You shouldn't be hung up on the DVD PAR values. Yes, your ratios are right AFAICS, but when you encode to AVI, how do you plan to use those DVD PAR values?

P.S: Can you please stop editing your posts once you've submitted them? Twice I had to revise my replies because you changed your post.

This I suppose is because of my incorrect terminology. There are two many 3 letter acronyms floating around which refer to different things.

Let me define my terminologies before I go into

PAR = Pixel Aspect Ratio. Whose values are mentioned in #106 (http://forum.doom9.org/showpost.php?p=1130663&postcount=106) along with the respective video frame size.

After cropping that image (i.e removing the black borders) I would get the cropped width.

I calculate my sources aspect ratio (calling it source AR) to prevent any confusion.


source PAR * cropped width
source AR = ------------------------------------
cropped height


This source AR in my opinion should be as close as possible to the DVD AR that you have mentioned. When you encode with square pixels you would want the output resolution as close as possible to this. Please correct me if I am wrong.

I'm in total agreement with unskinnyboy's comments....

I hope this clarifies any of the confusions I have caused using incorrect terminology.

[SeeMoreDigital]

As I said in post 97 (http://forum.doom9.org/showthread.php?p=1130397#post1130397).

"At the end of the day, DAR, PAR and SAR are only different abbreviations that use the same maths to calculate a required "aspect ratio signalling" value - Don't get caught up in the abbreviations... Just do the maths" ;)

[krosswindz]

As I said in post 97 (http://forum.doom9.org/showthread.php?p=1130397#post1130397).

"At the end of the day, DAR, PAR and SAR are only different abbreviations that use the same maths to calculate a required "aspect ratio signalling" value - Don't get caught up in the abbreviations... Just do the maths" ;)

yeah, shouldnt get caught up with the abbreviations but do you feel the math that has been proposed above is right?

[unskinnyboy]

source PAR * cropped width
source AR = ------------------------------------
cropped height


This source AR in my opinion should be as close as possible to the DVD AR that you have mentioned. When you encode with square pixels you would want the output resolution as close as possible to this. Please correct me if I am wrong.Your formula is right, as long as you aren't mixing the values for DVDs and the values for MPEG-4.

Regardless of whatever your previous DVD PAR values were, when you encode to AVI, your PAR is now 1. If you put this in your formula, then source AR = cropped width / cropped height. Which means, how you resize the image will determine your final AR. Is it clear so far?

[krosswindz]

Your formula is right, as long as you aren't mixing the values for DVDs and the values for MPEG-4.

Regardless of whatever your previous DVD PAR values were, when you encode to AVI, your PAR is now 1. If you put this in your formula, then source AR = cropped width / cropped height. Which means, how you resize the image will determine your final AR. Is it clear so far?

Probably an example might be better for me to explain what I am trying to say.

Lets take this 720x480 frame (my cropping is using this frame size).

http://img209.imageshack.us/img209/7663/snapshot20080428224747lf0.jpg

The crop values I had were crop (2, 62, 0, -68) IIRC.

so using this


32 * 718
source AR = ----------- = 2.431322
27 * 350


IIRC the cropped frame of this image was 850x352

http://img294.imageshack.us/img294/2069/vlcsnap5158296kp3.png

this gives DVD aspect ratio which you are taking about as 2.414773

I tend to be conservative in cropping and do over crop a bit at times.

I hope that the math I proposed is correct. And better explains what I am trying to do here.

[smok3]

08h
.has 'notes' link to fullscan numbers as proposed above, so you can copy/paste those when needed (into custom PAR field) - on the 2nd thought there are reasons to not include those into presets.

[SeeMoreDigital]

To confuse you even more: -

The unfortunate thing with NTSC DVD sources is that they're more difficult to convert to "square pixel" encodes than PAL DVD sources.

Upon playback, PAL DVD sources are displayed at either 768 pixels wide (for 4:3 sources) or 1024 pixels wide (for 16:9 sources).

By contrast, NTSC DVD sources are displayed at either 640 pixels wide (for 4:3 sources) or 853.33 pixels wide (for 16:9 sources).

Sadly, 853.33 pixels does not conform to a "mod-16" width (ie: 853.33 does not divide by 16). Meaning the closest mod-16 pixel width to 853.33 is either 848 or 864 pixels

[krosswindz]

To confuse you even more: -

The unfortunate thing with NTSC DVD sources is that they're more difficult to convert to "square pixel" encodes than PAL DVD sources.

Upon playback, PAL DVD sources are displayed at either 768 pixels wide (for 4:3 sources) or 1024 pixels wide (for 16:9 sources).

By contrast, NTSC DVD sources are displayed at either 640 pixels wide (for 4:3 sources) or 853.33 pixels wide (for 16:9 sources).

Sadly, 853.33 pixels does not conform to a "mod-16" width (ie: 853.33 does not divide by 16). Meaning the closest mod-16 pixel width to 853.33 is either 848 or 864 pixels

That does not confuse me as much as the number of 3 letter acronyms. I would really appreciate it if you could confirm that the math I suggested is right?

[unskinnyboy]

krosswindz, let's see if the way you are doing it is universally applicable, OK?

This is a screencap from my NTSC R1 4:3 DVD of Cyrano de Bergerac (1990) (http://www.imdb.com/title/tt0099334/) which has a PAR of 8:9:

http://img301.imageshack.us/img301/9360/vlcsnap3244586ru4.th.png (http://img301.imageshack.us/my.php?image=vlcsnap3244586ru4.png)

To get rid of all the black, I need to use crop(4,42,-2,-48). My resultant image is now 634x390:
http://img238.imageshack.us/img238/6244/cyranocroppedlf9.th.png (http://img238.imageshack.us/my.php?image=cyranocroppedlf9.png)

If I plug the values into your formula, I get:

8 * 634
source AR = ----------- = 1.4450
9 * 390

Are you suggesting that 1.44:1 is the AR of this movie?

[SeeMoreDigital]

That does not confuse me as much as the number of 3 letter acronyms. I would really appreciate it if you could confirm that the math I suggested is right?Well this bit of maths you did works: -


32 * 718
source AR = ----------- = 2.431322
27 * 350


However, if you know your NTSC DVD source is 16:9, you could also calculate the movie aspect ratio like this: -

16÷9 x ((718÷720) ÷ (350÷480)) = 2.431322751


Cheers

[smok3]

krosswindz, let's see if the way you are doing it is universally applicable, OK?

This is a screencap from my NTSC R1 4:3 DVD of Cyrano de Bergerac (1990) (http://www.imdb.com/title/tt0099334/) which has a PAR of 8:9:

http://img301.imageshack.us/img301/9360/vlcsnap3244586ru4.th.png (http://img301.imageshack.us/my.php?image=vlcsnap3244586ru4.png)

To get rid of all the black, I need to use crop(4,42,-2,-48). My resultant image is now 634x390:
http://img238.imageshack.us/img238/6244/cyranocroppedlf9.th.png (http://img238.imageshack.us/my.php?image=cyranocroppedlf9.png)

If I plug the values into your formula, I get:

8 * 634
source AR = ----------- = 1.4450
9 * 390

Are you suggesting that 1.44:1 is the AR of this movie?

which NTSC '4:3' DVDs have par=8/9 and which have par=4320/4739 ? (anyway i'am sure one could find some with 8/9 as well....) - again, better to use your wisdom to respond to the 2bdecided thread;
http://forum.doom9.org/showthread.php?t=132378

[krosswindz]

krosswindz, let's see if the way you are doing it is universally applicable, OK?

This is a screencap from my NTSC R1 4:3 DVD of Cyrano de Bergerac (1990) (http://www.imdb.com/title/tt0099334/) which has a PAR of 8:9:

http://img301.imageshack.us/img301/9360/vlcsnap3244586ru4.th.png (http://img301.imageshack.us/my.php?image=vlcsnap3244586ru4.png)

To get rid of all the black, I need to use crop(4,42,-2,-48). My resultant image is now 634x390:
http://img238.imageshack.us/img238/6244/cyranocroppedlf9.th.png (http://img238.imageshack.us/my.php?image=cyranocroppedlf9.png)

If I plug the values into your formula, I get:

8 * 634
source AR = ----------- = 1.4450
9 * 390

Are you suggesting that 1.44:1 is the AR of this movie?

you got me wrong... I said that this work using the source video frame. If I assume that the source video frame is 720x480


8 * 714
source AR = ----------- = 1.627350
9 * 390


which is close to what you have after cropping which is 1.625641.

[smok3]

appears as this is the 4320/4739 case - 704 active area stretched to 720 (but you can't be sure)
http://somestuff.org/resizeCalc.php?ssmw=720&sar=0.911&sar2=&ssmh=480&CT=90&CL=6&CR=&CB=&trw=&dar=1&dar2=&mod=&padw=&padh=&css=&doit=true
spits DAR as 1.668

[krosswindz]

appears as this is the 4320/4739 case (but you can't be sure)
http://somestuff.org/resizeCalc.php?ssmw=720&sar=0.911&sar2=&ssmh=480&CT=90&CL=6&CR=&CB=&trw=&dar=1&dar2=&mod=&padw=&padh=&css=&doit=true
spits DAR as 1.668

Very true because the source is assumed as 720x480. If you do the similar work using my math it seems to come to a similar number.

[krosswindz]

May be to make point clearer all the cropping I do is on the actual source frame viz. 720x480/704/480 (NTSC), 720x576/704x576 (PAL).

[unskinnyboy]

you got me wrong... I said that this work using the source video frame. If I assume that the source video frame is 720x480...I understood you now. Earlier, I assumed you were saying something else. But, in fact, we may have been trying to say the same thing.

So, yes, your math is right. :)

smok3, I'll check out the other thread.

[EuropeanMan]

I'm in total agreement with unskinnyboy's comments....

I agree with USB here...it was SO simple just to cut away all black and you have the DAR of the source. When encoding to AVI/MKV or whatever...one should get a resolution as close to the original DAR as possible...WITH also keeping mod16 in mind.

Also, the formulae here in many instances do hold validity as well...but will THIS lead to a calculator for A/R that is universal? and what would be the +/- error %?

[SeeMoreDigital]

Hi unskinnyboy,

When you do the maths, a loss of just "one" cropped pixel in width, can make quite a difference to your calculations: -

4÷3 x ((715÷720) ÷ (390÷480)) = 1.629629296
4÷3 x ((714÷720) ÷ (390÷480)) = 1.627350427
4÷3 x ((713÷720) ÷ (390÷480)) = 1.625071225
4÷3 x ((712÷720) ÷ (390÷480)) = 1.622792023


Cheers

[smok3]

but will THIS lead to a calculator for A/R that is universal? and what would be the +/- error %?
from a DVD-ripper-person point of view, certainly no, from a video-person perspective it is universal enough just now as it seems.

[unskinnyboy]

I agree with USB here...it was SO simple just to cut away all black and you have the DAR of the source. When encoding to AVI/MKV or whatever...one should get a resolution as close to the original DAR as possible...WITH also keeping mod16 in mind.Wait! No, not "original DAR" again! When you say "original DAR", it means the DAR of the DVD, which can only be 4:3 or 16:9, and that's not what you want to get close to (if your source is just MPEG-2, then it can have 1:1, 4:3, 16:9 or 2.21:1). You want to get close to the AR of the movie. Perhaps this is indeed what you meant to say, but let's be sure of using the absolute correct terms here. Part of the reason why the AR concept seems so confusing is because of loosely using these terms. This is why we were trying to explain this 4 years ago, and we are still trying to explain this now.

Also, the formulae here in many instances do hold validity as well...but will THIS lead to a calculator for A/R that is universal?Nope.

When you do the maths, a loss of just "one" cropped pixel in width, can make quite a difference to your calculations: -

4÷3 x ((715÷720) ÷ (390÷480)) = 1.629629296
4÷3 x ((714÷720) ÷ (390÷480)) = 1.627350427
4÷3 x ((713÷720) ÷ (390÷480)) = 1.625071225
4÷3 x ((712÷720) ÷ (390÷480)) = 1.622792023
Yes, agree. Cropping is very crucial here. If you have have overcropped or undercropped by even 1 pixel, that will have a butterfly effect on the final AR. That plus, the MoD-16 restriction, will mean that you'll never be able to get the proposed AR down to the last point. It'll always be an approximation.

And we haven't even touched on ITU-R BT.601, capture windows (say if you were capturing your source) etc.

[krosswindz]

Yes, agree. Cropping is very crucial here. If you have have overcropped or undercropped by even 1 pixel, that will have a butterfly effect on the final AR. That plus, the MoD-16 restriction, will mean that you'll never be able to get the proposed AR down to the last point. It'll always be an approximation.

And we haven't even touched on ITU-R BT.601, capture windows (say if you were capturing your source) etc.

IMO cropping a source definitely changes the source AR, and not the source PAR. Plus taking into consideration source whose AR varies at different parts of it. If we crop keeping that in mind it will definitely affect the final AR.

It would be nice if we have more hard ware vendors implementing non mod16 macro blocks in hardware. There have been many implementations floating around for implementing them efficiently on hardware. IIRC I have only seen probably one vendors chip that probably implements at least mod8 macroblock. Most chips I have seen break on anything other than mod16.

These two links provide a nice explanation, but if you use those numbers we end up not getting the right AR quite a few times. Is this because the source was violating something :confused:

http://www.doom9.org/capture/par.html

http://lipas.uwasa.fi/~f76998/video/conversion/

[smok3]

just a note /maybe to myself/: agreeing or disagreeing without the numbers is not the purpose of this thread.

[unskinnyboy]

IMO cropping a source definitely changes the source AR, and not the source PAR. Of course. However you crop, PAR won't be affected. I never said otherwise. Did you get that impression from anything I said? When I say final AR, I mean the final DAR of the AVI file, obtained after resizing.

Plus taking into consideration source whose AR varies at different parts of it. If we crop keeping that in mind it will definitely affect the final AR.For floating frames, I try to strike a balance wherein I might overcrop some parts and undercrop some parts, the aim being to keep as much of the picture as possible, and try to resize to compensate for this. You might end up with a wrong final DAR, but that's OK.

It would be nice if we have more hard ware vendors implementing non mod16 macro blocks in hardware. There have been many implementations floating around for implementing them efficiently on hardware. IIRC I have only seen probably one vendors chip that probably implements at least mod8 macroblock. Most chips I have seen break on anything other than mod16.I am not sure what you mean by "non mod16 macro blocks in hardware". The MoD16 restriction (well, not really a restriction, but rather a recommendation) is more for aiding the codec to compress the input video optimally, and to ensure that it works across the board for all filters, some of which may process the image using the same 8x8-DCTs-grouped-into-a-macroblock way. EDIT: Yes, some standalones do have a problem with non-MoD16.

These two links provide a nice explanation, but if you use those numbers we end up not getting the right AR quite a few times. Is this because the source was violating something :confused:

http://www.doom9.org/capture/par.html

http://lipas.uwasa.fi/~f76998/video/conversion/
Example? Could be the ITU-R BT.601 black magic.

[krosswindz]

Of course. However you crop, PAR won't be affected. I never said otherwise. Did you get that impression from anything I said? When I say final AR, I mean the final DAR of the AVI file, obtained after resizing.

For floating frames, I try to strike a balance wherein I might overcrop some parts and undercrop some parts, the aim being to keep as much of the picture as possible, and try to resize to compensate for this. You might end up with a wrong final DAR, but that's OK.

I am not sure what you mean by "non mod16 macro blocks in hardware". The MoD16 restriction (well, not really a restriction, but rather a recommendation) is more for aiding the codec to compress the input video optimally, and to ensure that it works across the board for all filters, some of which may process the image using the same 8x8-DCTs-grouped-into-a-macroblock way. EDIT: Yes, some standalones do have a problem with non-MoD16.


Example? Could be the ITU-R BT.601 black magic.

my bad... i just woke up and wasnt reading properly.

mod16 is not a restriction but most hardware vendors choose not implement grouping 8x8 or 4x4 or 2x2 into a macroblock. These days you have efficient algorithms to do this which can be verified in hardware. If you want I can pm you some papers.

Lets no digress from the topic at hand of calculating an AR withing allowable error range.

Lets take the previous example used in post #117 (http://forum.doom9.org/showpost.php?p=1130708&postcount=117)

Source video frame is 720x480.

From these articles one can get the source PAR of NTSC Wide would be 1.215446 (one can easily calculate this) unless I am in correct.

I am just giving the final source AR (one can easily calculate it) as 2.493401. Agreed this is within 5% error.

Now if we assume the frame size is 704x480

source AR comes out to be 2.437837 which is closer to what we have calculated.

I am not saying that I am right, I am probably wrong in interpreting it and getting an incorrect PAR.

[SeeMoreDigital]

And we haven't even touched on ITU-R BT.601, capture windows (say if you were capturing your source) etc.Indeed....

However, for all those who insist on accomodating for the ITU spec. Here's how it can be worked into a typical calculation: -

For a PAL movie (Cropped: Top = 70, Bottom = 70, Left = 0, Right = 0. Disc AR = 16/9. PAL ITU = 1.025640385)

With PAL ITU = 16÷9 x ((720 ÷ 720) ÷ (436 ÷ 576)) x 1.025640385 = 2.408843473
Without ITU = 16÷9 x ((720 ÷ 720) ÷ (436 ÷ 576)) = 2.348623853

For a NTSC movie (Cropped: Top = 58, Bottom = 59, Left = 0, Right = 0. Disc AR = 16/9. NTSC ITU = 1.02536086)

With NTSC ITU = 16÷9 x ((720 ÷ 720) ÷ (363 ÷ 480)) x 1.02536086 = 2.410398349
Without ITU = 16÷9 x ((720 ÷ 720) ÷ (363 ÷ 480)) = 2.350780533

Cheers

[krosswindz]

SMD, can you provide any link for the PAL/NTSC ITU numbers. I just want to understand them better.

[krosswindz]

Looking at this link http://trac.handbrake.fr/wiki/AnamorphicGuide#itu

I am not sure about this but I am just wondering shouldnt the NTSC/PAL PAR which I wrote up in post #106 (http://forum.doom9.org/showpost.php?p=1130663&postcount=106) account for these.

Apologies if I am being stupid, ignorant and hence incorrect.

[unskinnyboy]

mod16 is not a restriction but most hardware vendors choose not implement grouping 8x8 or 4x4 or 2x2 into a macroblock. These days you have efficient algorithms to do this which can be verified in hardware. If you want I can pm you some papers.I don't really understand what you are trying to say, so please yes, PM me the papers and point out which are the relevant sections I should look at.

Looking at this link http://trac.handbrake.fr/wiki/AnamorphicGuide#itu

I am not sure about this but I am just wondering shouldnt the NTSC/PAL PAR which I wrote up in post #106 (http://forum.doom9.org/showpost.php?p=1130663&postcount=106) account for these.

Apologies if I am being stupid, ignorant and hence incorrect.
You have already accounted for those. The PARs for all the 704x??? ones correspond to ITU-R BT.601 compliant PARs. As per the specs, 704x480 for NTSC and 704x576 are the active pixel areas (it's actually 702x???, but we won't go there, so as not to confuse you further). It's only valid for DVDs authored with ITU-R BT.601 or for captures done with ITU-R BT.601 compliant cards, though. But, just because a DVD is 704x??? doesn't mean that it's ITU-R BT.601 compliant nor does a 720x??? DVD means that it isn't. There's no rule of thumb there.

Like I've implied before, don't always depend on your formula to get the AR right, though - you could have a WS image letterboxed into a 4:3 DVD, authored with a 4:3 DAR and 8:9 PAR.

[krosswindz]

I don't really understand what you are trying to say, so please yes, PM me the papers and point out which are the relevant sections I should look at.


You have already accounted for those. The PARs for all the 704x??? ones correspond to ITU-R BT.601 compliant PARs. As per the specs, 704x480 for NTSC and 704x576 are the active pixel areas (it's actually 702x???, but we won't go there, so as not to confuse you further). It's only valid for DVDs authored with ITU-R BT.601 or for captures done with ITU-R BT.601 compliant cards, though. But, just because a DVD is 704x??? doesn't mean that it's ITU-R BT.601 compliant nor does a 720x??? DVD means that it isn't. There's no rule of thumb there.

Like I've implied before, don't always depend on your formula to get the AR right, though - you could have a WS image letterboxed into a 4:3 DVD, authored with a 4:3 DAR and 8:9 PAR.

I have sent you one... a really short one.

Just that this formula could be used as tool to aid a ripper. To make his decision process easier. Its not for the ripper to depend on them.

[smok3]

to simplify, the real problem is (with DVDs at least):
1. was dvd authoring path ITU-R BT.601 compliant
2. what software/hardware players are ITU-R BT.601 compliant
which seems unsolvable.
p.s. personally i don't care about unknown sources thought, i do manipulate my own material - mostly.
-----------------------
p.s.2 for other lost souls, this seems to be the simplest explanation i have found so far (no, i do not say or claim that it is perfecly correct, but should be more than good enough for illustration):

from http://www.afterdawn.com/glossary/terms/itu-r_bt_601.cfm
ITU-R BT.601 is the designation for an entire set of standards that defines rules for converting analog (PAL or NTSC) television signals to digital and back. The standard was formalized by the International Telecommunications Union (ITU) and has since been used as a guideline for nearly all digital consumer video formats. This standard is also commonly referred to as simply Rec.601, or even by its older name of CCIR 601.

Resolution
The most commonly used portion of ITU-R BT.601 is the Resolution of 720x576 for PAL video and 720x480 for NTSC. This Resolution is achieved by sampling at a Frequency of 13.5MHz (13,500,000 samples per second) across horizontal lines 53.333µs (.000053333 seconds) long. Since the actual line length for PAL and NTSC TVs is 52µs and 52.666µs respectively. That means a standard ITU-R BT.601 Frame includes either PAL video with an Active Area (the part of the Frame containing visible pixels) of 702x576 or NTSC video with an active area of 711x480. In reality many real-world implementations of this conversion use either a different resolution, such as 640x480/576, or a slighly different line length, resulting in the active area of the picture to use all 720 Pixels.

DVD
The best known application of ITU-R BT.601 is probably DVD-Video, where frame sizes of 720x480 and 720x576 are standard. However, like all implementations, the actual conversion back to an analog signal is dependent on the player, and may not follow the ITU specification. Likewise, video encoding for video often uses all 720 Pixels for a standard 4:3 image. For either Widescreen (Anamorphic) or 4:3 Letterbox DVDs it may be necessary using the additional pixels to maintain the source's Aspect ratio.

DV
DV, used in most Standard Definition (SD) digital camcorders, uses the recommended resolution of 720x480/576, but uses the entire width of the frame for the picture. When using DV as a source for other formats that respect the ITU-R BT.601 specifications with regard to line length it may be desirable to resize to match the active area of your TV's picture and add borders to the sides.

-----------------------
08j
.very primitive crop-only mode (wip), not very usefull right now, only thing it really does is;
$target_requested_width = $source_sampling_matrix_width
- $crop_L - $crop_R;
$destination_aspect_ratio = $source_aspect_ratio;
.AR suggestions are now displayed as numbered list

[smok3]

09
.aftercrop resolution (in avisynth display textarea) now includes the number in pixels which suggest how much would a crop need to be modified to be modN friendly (previous idea about crop-only mode was rejected) - trying to keep things simple.

example, if you get something like this:
Crop(0,0,-0,-0) # 1280x1080(-8px)
that would mean that you need to crop height for additional 8 pixels (if you need modN cropping that is...)

.different behaviour: if requested width is undefined, then it equals sampling matrix width

(not tested very much)

[Adub]

Okay, so I am new to the whole anamorphic encoding thing.

I am in the process of backing up my Pirates of the Caribbean: Dead Man's Chest NTSC DVD.

I noticed that there were black bars on the top and bottom. If I cropped 62 pixels off of both the top and bottom, I got rid of all remnants of black bars.

Now, I want to store this on my computer for archival purposes and viewing. So, I assume, I want my new PAR to be square, or 1:1.

So, I went to your calculator, smok3, and punched in my res and crop settings. It recommended this:

# resizeCalc
# pixels = 207360, DAR error = 0.023
# Crop(Left, top, -right, -Bottom)
Crop(0,65,-0,-65) # 720x350(-2px)
LanczosResize(720,288) # (mod16)

Now, this looks funny to me, but if I understand anamorphic encoding correctly, it is supposed to. So, my question is, if I add those settings to my script, encode, and then mux with mkvmerge, I should set the AR flag to be 16:9?

[krosswindz]

Okay, so I am new to the whole anamorphic encoding thing.

I am in the process of backing up my Pirates of the Caribbean: Dead Man's Chest NTSC DVD.

I noticed that there were black bars on the top and bottom. If I cropped 62 pixels off of both the top and bottom, I got rid of all remnants of black bars.

Now, I want to store this on my computer for archival purposes and viewing. So, I assume, I want my new PAR to be square, or 1:1.

So, I went to your calculator, smok3, and punched in my res and crop settings. It recommended this:

# resizeCalc
# pixels = 207360, DAR error = 0.023
# Crop(Left, top, -right, -Bottom)
Crop(0,65,-0,-65) # 720x350(-2px)
LanczosResize(720,288) # (mod16)

Now, this looks funny to me, but if I understand anamorphic encoding correctly, it is supposed to. So, my question is, if I add those settings to my script, encode, and then mux with mkvmerge, I should set the AR flag to be 16:9?


Looking at your crop values, there is something wrong I just used your crop values and calculated the expected AR assuming that the source is 720x480 NTSC Wide screen


32 * 720
source AR = ------------- = 2.438095
27 * 350


going by mod16 resolution when you resize to square PAR what the calculator outputs as 720x288 is right. You dont set the AR to anything other than 1:1.

[Adub]

Wait a sec. Aren't you just talking about the PAR? I am pretty sure that the flag that I set in MKVMerge is supposed to be the DAR, which I sure as hell don't want to be 1:1.

[SeeMoreDigital]

Hi Merlin7777,

By my calculations the movie aspect ratio of your (Pirates of the Caribbean: Dead Man's Chest NTSC DVD) source, after cropping is: -

16÷9 x ((720÷720) ÷ (356÷480)) = 2.397003745

If you want to generate a "non-square" (aka: anamorphic) pixel encode, your nearest mod-16 pixel frame size height would be 352

352 x 2.397003745 gives you a "square pixel" frame width of 843.7453182
843.7453182 ÷ 720 gives you a "non-square" aspect ratio signalling value of 1.171868498 or 75:64

So you need to generate your "non-square" encode at 720x352 pixels with aspect ratio signalling value 75:64

Easy in it....

EDIT: For "quickly" working out calculations such as: 16÷9 x ((720÷720) ÷ (356÷480)), just feed them into Google's "seach box". Like this (http://www.google.com/search?hl=en&q=16%C3%B79+x+%28%28720%C3%B7720%29+%C3%B7+%28356%C3%B7480%29%29&btnG=Google+Search). Then, to convert the "decimal" into a "fraction" use this web site: http://www.mindspring.com/~alanh/fracs.html

[Adub]

Okay, so let me get this straight. When I am dealing with anamorphic material, I should only crop to get rid of the black bars, and resize to reach the closest mod-16 resolution.

Then, I perform the math that SeeMoreDigital just did, and this should tell me what I should place into the MKVMerge "Aspect Ratio" box.

Is that correct?

So, first I find my MAR. I then multiply this by the closest mod-16 height value to get my "square pixel" frame width. If I divide this width by my "old" width, I get my ARS value.

I am slowly starting to get it. So you basically encode the main video content, removing all black bars, and modifying your source as little as possible. Then, in order to achieve a "square pixel" final output, you just enter the ARS into MKVMerge, and you are good to go.

I think I have it know. If I am wrong tell me. This is very interesting stuff. In addition, is there a proper guide to the math as stated above by SeeMoreDigital?

[SeeMoreDigital]

Sounds about right to me...

Personally I don't generate MKV muxes, so I'm not sure at what stage MKVMerge detects and places the aspect ratio signalling within the MKV container.

It looks as though you can either manually enter the "width/height" of your output encode. Or MKVMerge can pull-in the aspect ratio signalling information from within the MPEG-4 (in .AVI or .MP4) stream.

Here's and example: -

http://www.mediafire.com/?ndzyeegi1jw

[smok3]

if you need to just crop to mod16, then
http://somestuff.org/resizeCalc.php?ssmw=720&sar=1.215&sar2=1.18519&ssmh=480&CT=64&CL=&CR=&CB=64&trw=720&dar=1&dar2=&mod=&padw=&padh=&css=&doit=true
(adding 4px to the height to get out with mod16 resolution after crop, ignoring the resizer and like smd said, you would flag your video accordingly, in my example DAR=2.424)

Crop(0,64,-0,-64) # 720x352