Any quality check besides the human eye ?

[avdw]

Hi,

sorry for this hyper-newbie question.

Is there any program, besides the human eye that can give you some idea of the quality of an AVI-file ?

I've only used some tools like Gspot, allthough it gives a lot of neat info, the "Frame Quality" (Qf) fields sometimes gives a high value for a really ugly encoded file, while sometimes giving extremely low values for a great looking encoding. So, this can't help me.

The other program I know about is DRF Analyzer, probably abandonned, so I dunno if the info it gives really is of interest, I'm such a newbie but I think the value to look for to get some idea of the encoded quality is the "AverageDRF", which I think, the lower it is, the better the quality.

Are there any other tools that can give you some kind of idea, besides playing it and watching the movie ?

Secondly :
- My personal interest is converting PAL DVD's (playtime around 1hour 30 mins) to 1CD Format (700MB).
I've tried many tools but I'm not getting any satisfying results with any of them. Gspot tells me the storage dimensions of the movies are 720 x 576. Is there any logic as to which resolution encoding gives the best results, or are all movies different ?

Right now, I'm encoding to Xvid with a resolution of 560 x 256, is that good ? bad ? what is recommended ?

I've read weeks of tutorials/manuals/forums ..... but I'm still crawling around and my encoding are not good.

Please be gentle, I've read almost all stickies and guides.

[TheRyuu]

All encodes will depend on the taste of the encoder. I don't think any computer program can calculate an "idealized" value.

[Dark Shikari]

A good comparison of quality is SSIM--you need to compare it between the original source and your output file, of course. x264 will automatically output SSIM values.

Closer to 1.0 = better, and 0.99 is generally twice as good as 0.98, and 0.96 twice as good as 0.92, and so forth.

PSNR is another, which x264 also automatically outputs.

But of course trust your eyes above all else.

[Adub]

Frankly, I don't see why you shouldn't just use your eyes for the encodings that you are making.

If you are having trouble getting quality encodes, try some predefined profiles, or posting your current settings.

[avdw]

Thanks for the tips. I'll use me eyes next time :)

About that SSIM, I'm encoding to XVid, is there any way or tool that I can use the see these SSIM values ?

Thanks !

[Dark Shikari]

Thanks for the tips. I'll use me eyes next time :)

About that SSIM, I'm encoding to XVid, is there any way or tool that I can use the see these SSIM values ?

Thanks !MSU Video Quality Tool.

[IgorC]

I would prefer the last patched SSIM avisynth plugin. Not one from MSU (my father was student in MSU :) ) geniuses. However MSU GUI has some interesting visualizations like images of lowest/highest quality frames etc.

And the scale of x264's SSIM is hard to interpretate:
0.95 - bad quality
0.98 - medium
0.99 and higher - good.

Little numeric difference for a huge visual deal.

While for avisynth SSIM:
0.6 - bad
0.7 - acceptable
0.8 - ok, good
0.9 and higher - very good, excelent ....

[Sergey A. Sablin]

I would prefer the last patched SSIM avisynth plugin. Not one from MSU (my father was student in MSU :) ) geniuses. However MSU GUI has some interesting visualizations like images of lowest/highest quality frames etc.

And the scale of x264's SSIM is hard to interpretate:
0.95 - bad quality
0.98 - medium
0.99 and higher - good.

Little numeric difference for a huge visual deal.

While for avisynth SSIM:
0.6 - bad
0.7 - acceptable
0.8 - ok, good
0.9 and higher - very good, excelent ....

MSU and x264 both calculates SSIM like it's described in original paper, while AviSynth do exactly the same + lumamask (if specified) + scaling final index:
SSIM(avs) = 100 * SSIM^8. (yes, it's from 0 to 100, not from 0 to 1 and I'm not sure whether ^8 makes any sense here)

so, it's basically only the matter of scaling - take MSU or x264 SSIM and perform two operations using calc, excel, whatever...

[avdw]

The problem is, as will those hundreds of frontends, they all use their own, or different versions of DGIndex and DGDecode,
whatever you do, you always get some errors about incompatible/wrong DGIndex file used, etc... etc....

Time to force the frontend developers to TALK to each other, make their tools compatible and last but not least, give us at least a little explanation about the options in the program.

As for MeGUI, it might be good, but the interface is a complete mess, there is no single logic in it, first you have to do something from the drop down boxes, then ? Uggggh, try another button and see if that works ? No, so you need to go searching in the menus for the function you have to use first, then try again ? Then set some options in the encoding profile, then go searching for the menu option how to choose a predefined target size, than all previously executed commands are invalid, and you have to go searching again where to continue.

I finally got it as far as setting a predefined size of 700 MB, it ran the 2 passes, resulting in an AVI file of over 1 Gigabyte in size....... Pfffffffffff.........


It's one giant mess !

As for Megui, some simple explanations ? Some manual ? Some walkthrough ? Nothing at all !
First time you run it, you are presented with all bunch of tools it has to update ? What will it do with them ?
Will it dump them in it's own subfolder ? Will it install them all in their predefined folder, thereby fucking up all other frontends that require a specified version of those tools ? It downloaded them, and now their all are zipped it a subfolder called "update_cache" .... What do i have to do with them ? Do I have to manually install them all, therefor getting all other frontends and tools spit out errors on the fly..... I have no single idea.

A helpfile ? Seems like that's the ultimate nightmare of a frontend programmer, the biggest help is some link to some wiki page with no contents at all....

[Ranguvar]

I personally wouldn't use anything but my own eyes...

If you can't tell the difference, then who cares? Go for the smaller filesize!

[Dark Shikari]

I personally wouldn't use anything but my own eyes...

If you can't tell the difference, then who cares? Go for the smaller filesize!There is a danger with this, of course.

You probably can't tell the difference between 1000 kbps and 990 kbps, right? So drop to 990kbps.

Now, you probably can't tell the difference between 990kbps and 980kbps, right? So drop to 980kbps...

Repeat the process and eventually you'll notice that the quality has dropped massively, even though each little step wasn't noticaeble.

[Irakli]

There is a danger with this, of course.

You probably can't tell the difference between 1000 kbps and 990 kbps, right? So drop to 990kbps.

Now, you probably can't tell the difference between 990kbps and 980kbps, right? So drop to 980kbps...

Repeat the process and eventually you'll notice that the quality has dropped massively, even though each little step wasn't noticaeble.

Wow, this is really nice example! That's why one should always compare encoded video with the original.

[seunosewa]

What SSIM would you define as "acceptable"?

[Dark Shikari]

What SSIM would you define as "acceptable"?Depends strongly on the source.

If the source is very grainy 1080p, it might take 100 megabits per second to get 0.99 SSIM due to the difficulty of retaining the grain, yet if you go for a much lower bitrate (say, 5 megabits) and the encoder throws out the grain, it still looks pretty tolerable, yet the SSIM is only 0.95 or 0.93 or lower due to the loss of grain.

Yet if the source looks like this (http://i3.tinypic.com/86spjdl.jpg), for example, you could get 0.99 SSIM at an absurdly low bitrate yet it might not look that great.

Those are two extremes, of course, but SSIM is really only good as a comparison between two encodes of the same source, not between different sources.