Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[andrewberg]

Hi, I would like to use the "Aspect Ratio" library field to identify some old 4:3 TV recordings in my movie library, but find some odd A/R pairs (automatically filled by MC) I can't make sense of, e.g. "45:33" or even "75:45" etc.

To my knowledge (e.g. from MC's video > Window context menu), the simplest way to calculate a video's aspect ratio is the formula "height x [X] = width", with common factors ranging from: 1,33 (for 4:3 TV); 1,6 (laptop screens), 1,78 (for widescreen TV, a.k.a. 16:9), and movie formats like 1,85, 2,25 (k.a. Cinemascope).

Could MC use this formula to determine the "Aspect Ratio" field as well to make the values easy to read, please?

[ferday]

there are ways to make that calculation if you want it...set an expression field

formatnumber(math([width]*[height]^-1),2)&datatype=[number]

will give you 1.78, 1.33 etc.

>>>i've never gotten division to work correctly with math() therefore the ^-1

aspect ratios can be weird though, i'd probably go with something like

if(isrange([expression field],1.2-1.5),TV,higher res)

or something like that.  i've set mine to read TV, DVD, BD, or Phone depending on the calculated value

[Hendrik]

Could MC use this formula to determine the "Aspect Ratio" field as well to make the values easy to read, please?

Thats really just the same numbers. 45:33 means 45/33, which is 1.36363636 .. 45:33 is just more accurate.
It may make more sense to you if its actually a better match, ie. when it says 4:3 or 16:9, but not every file matches these "standard" ratios perfectly.

But because 4:3 or 16:9 makes more sense to people than 1.33333 or 1.7777, we opted to use this syntax at all times - using two different syntax for aspect ratios would be inconsistent, and inconsistency is the death of everything.

[6233638]

>>>i've never gotten division to work correctly with math() therefore the ^-1

Special characters in expressions (brackets, slashes, commas, spaces, semicolons etc.) need escaped with a slash first.
So to divide, you use // rather than /

[andrewberg]

Thanks for these ideas! I guess the current solution is the most exact, but incomprehensible...

...4:3 or 16:9 makes more sense to people than 1.33333 or 1.7777...

That would be true if the majority of videos matched any AR standards, but that's not the case for me. Odd values like 1,45678 would be equally exact (and more easy to understand than "45:33", "75:45" etc.), because they are based on the same factor, which is "height = 1"!
JR might do us all a favour and invent a new field, eg. "Height based Aspect Ratio" in a future version, using ferday's suggested formula...

[andrewberg]

I'm curious what those strings do --

formatnumber(math([width]*[height]^-1),2)&datatype=[number]
will give you 1.78, 1.33 etc.

Does "[width]*[height]" multiply width by height? That would be nonsensical...

Anyway, I've now set up a field with the formula, and it works just fine (only the output numbers have lots of zeros at the end, so rather than "1.78" I get "1.7800000"... ;-). Would you know how to avoid these?

Thanks so much for that!

[ferday]

62...you are right except that none of the examples use // and it doesn't (didn't) work for me, all my divisions come to zero, it's a simple enough workaround.  I'll try again it's been awhile since mc19 that I needed division, all mine use the inverse

Anyways as to the extra zeros...

Formatnumber(stuff,2) should round to two decimal places and there shouldn't be extra zeros...?
Math (width*height^-1) is actually division, since height^-1 is 1/height
&datatype=[number] just forces the output to be a number which can then be operated on

As I said I long ago abandoned the actual aspect ratio and made an if(is range) function to output TV,BD,Phone, or DVD instead.  This then gets tacked onto the file name so when I browse my movies I know what general resolution it's at.  Web based videos are often at really weird numbers

[Hendrik]

Odd values like 1,45678 would be equally exac

Actually, no.
45:33 is 1.363636363636363636363636363636.. to infinity!

So what do I show? 1.36? 1.364? 1.3636? All with varying degree of inaccuracy!
Storing the most accurate value in the database is always the best choice. Its not too hard to setup your own custom field and divide the two numbers if you want the aspect ratio to always read 1.36 etc.

Personally, I find its not the most interesting piece of information to have in the database anyway.

[andrewberg]

Anyways as to the extra zeros...
Formatnumber(stuff,2) should round to two decimal places and there shouldn't be extra zeros...?

I'm afraid the trigger (*,2) doesn't work in your formula "formatnumber(math([width]*[height]^-1),2)&datatype=[number]", for I still get the tail of  zeros...   Any other switches I might try?

@ Hendrik:

So what do I show? 1.36? 1.364? 1.3636?

I think it's safe to round, for digits beyond 2 will make no difference watching the video anyway. So all I need is another switch to make that formula round off the digits (see quote above)...

Generally, I need to identify those old 4:3 recordings to re-encode them for my DLNA TV (which is incapable to correct odd aspect ratios like a software player would; eg. DVDs encoded to 576:720 instead of 576:768 will display almost square, just ugly)...

[Hendrik]

Remove the datatype from the expression. FormatNumber outputs a string, when you turn that back into a number, extra zeros get added.

Note that the Aspect Ratio is not necessarily based on the resolution alone, but also Aspect Ratio signaled in the file.
That means that the Width/Height formula suggested above will not always result in the same value.

[andrewberg]

Remove the datatype from the expression. FormatNumber outputs a string, when you turn that back into a number, extra zeros get added.

OK, I've changed the expression to "formatnumber(math([width]*[height]^-1),2)", removing the part "&datatype=[number]". Strange enough, it seems to make no difference as the files I tried suddenly have no more zero tails, regardless which expression is in use... Fair enough for me ;-)

Note that the Aspect Ratio is not necessarily based on the resolution alone, but also Aspect Ratio signaled in the file.

Never mind that, my TV will ignore soft coded AR signals anyway, it only displays actual width & height... ;-)