StaxRip - oversize problem

[zacharias]

hello there. i hope this is the propper section to pose my problem. here goes.
ive recently started ripping BDRips and DVD's and ive found stax rip. i've use Gordian Knot for the dvd's and i i want to use only a software to make all sorts of rips, so ive decided to try stax.

1. so, i've made a first BRRip with target size 1.46gb 1/3DVD and it came perfectly.
now, ive tried to do anothere BRRip with same quantizers but using a diferent target size 1/2DVD 2.19gb, and it turned out to be oversize 2.76gb ive used the same quantizers as i used in Gordian Knot. in GK ive hadnt any kind of trouble waht so ever. but in stax ive found this. can someone help me out? i rell dont know if the problem lies in quantizers or in the compressibility check. here are the specs. quantizers and all specs are the same in both passes.

http://img822.imageshack.us/img822/7632/10292315.png

http://img340.imageshack.us/img340/79/15444241.png

http://img14.imageshack.us/img14/9347/81373742.png

2. how to configure the compressibility check? should i just leave it defaul or config it like ithe second pass, or like this screen?

http://img819.imageshack.us/img819/314/64315567.png

i just want to create a standard profile where i only need to config minimal stuff. ^^

tks in advance, and many thanks to the software creators <3

[fantasmanegro]

for compressibilty test, leave it in single pass with Target Quantizer of 2.0

for 1 and 2 pass, use for min 2 and for max 31 for I, B and P frame, just leave the codec choice the best Quantizer.

for profile, unrestricted but i allways use AS@L5

by the way, i have been using StaxRip for a long time and i have no problems with oversized movies

[zacharias]

for compressibilty test, leave it in single pass with Target Quantizer of 2.0

for 1 and 2 pass, use for min 2 and for max 31 for I, B and P frame, just leave the codec choice the best Quantizer.

for profile, unrestricted but i allways use AS@L5

by the way, i have been using StaxRip for a long time and i have no problems with oversized movies

:) tks for the reply, but like ive said, i've always used this config in GK and avidemux too. i use the AS@L5, but do you config it in sum way for best results? :thanks:

[fantasmanegro]

not all the time, just once for all the movies (i know, i know it's not the best but, IT WORKS!!! ;D), i'm not advanced user as others to do that :D ...

i allways use Min 2 and Max 3 for I-Frames, and 2 for Min and 6 or Max for the rest, and always do comp. test.

as i said before, i have no problem with oversized movies with StaxRip but some times with Gordian Knot...

[zacharias]

not all the time, just once for all the movies (i know, i know it's not the best but, IT WORKS!!! ;D), i'm not advanced user as others to do that :D ...

i allways use Min 2 and Max 3 for I-Frames, and 2 for Min and 6 or Max for the rest, and always do comp. test.

as i said before, i have no problem with oversized movies with StaxRip but some times with Gordian Knot...

whts the use of comp test? should i do it 1st or after i iniciate the rip?

well with target size 2.18gb i got a weird undersize 1.38 gb...
here are the specs:

quantizers
http://img411.imageshack.us/img411/3379/51384672.png

comp. check.
http://img441.imageshack.us/img441/8272/87871013.png

any thoughts people?

ps: where u from fantasma?

[fantasmanegro]

i can see it is undersized, but in some cases it's better than oversized (700 mb target size)

about the comp. test.. it helps you to find the balance between size and resolution, it's very helpful in 2 pass with specific target size ( in my case 700 mb or 350 mb)... oh yes!... run it before the rip

and for the quatizers... you can increase the size of the movie changin the Max for P and B frames to 3 or 5... i cannot tell you exactly because i don't know what kind of movie is...

so... what is your target video resolution?...

can you post a picture of staxrip main window?

PS: i'm from mexico so please... dont say taco or taquito word... :D

[TheRealDeal]

the smaller the quantizer (1/2) bigger the size not the other way arround:rolleyes:
so if the movie is undersized you'll have to lower the maximum quantizer you've used, if it's oversized you'll have to raise it

I sugest you use this values
I frame min/max (1/1)
P frame min/max (2/7)
B frame min/max (2/7)

so if the encode it's oversized you'll have to raise the maximum quantizers values (I recommend max 8).. and fix the max maybe at 7 or 8, that way it won't get oversized tugaman :devil:

and on the option filters/ resize use the option lanzcos4

[zacharias]

tks for the insight. i'll try to rip it and ill feed u back. but one thing remains in doubt: sould i leave the compressibility check with default settings?

ps: wots with the tugaman? =P
kudos

[fantasmanegro]

config the compt. test like the 2nd pass

[Sharktooth]

Dont mess with quants. The encoder knows what he's doing... you wont, since you're not a computer nor a genious...
Rate control was made for the purpouse to choose the best quants to create a file of a given size.
I repeat myself... DONT MESS WITH MIN AND MAX QUANTS.
Leave them all at 1-31 or 2-31 AND enable Trellis for perfect distribution.

[zacharias]

Dont mess with quants. The encoder knows what he's doing... you wont, since you're not a computer nor a genious...
Rate control was made for the purpouse to choose the best quants to create a file of a given size.
I repeat myself... DONT MESS WITH MIN AND MAX QUANTS.
Leave them all at 1-31 or 2-31 AND enable Trellis for perfect distribution.

ok, but i repaet myself as well: in GK i mess with qunats and it's perfect all the time.
and what about output size? will it output the size i want, or am i gonna get surprised with over and undersize files?
kudos

[Sharktooth]

if you want to hit a specific filesize then do a 2-pass encoding.\
if you keep quants at 1-31 it will hit the filesize.
if by change you get an undersize that means you saturated the encoder.

[fantasmanegro]

if by change you get an undersize that means you saturated the encoder.

undersized? in my case i allways got oversized :)...

maybe GK config xvid in one way and StaxRip in other one...

i mean...could it be the software?

[Sharktooth]

no. it could be thou shalt not mess with quants.

[fantasmanegro]

ok... i get your point but why some guides put quants like min 2 max 16 for example?

and why does it works?

[TheRealDeal]

Dont mess with quants. The encoder knows what he's doing... you wont, since you're not a computer nor a genious...
Rate control was made for the purpouse to choose the best quants to create a file of a given size.
I repeat myself... DONT MESS WITH MIN AND MAX QUANTS.
Leave them all at 1-31 or 2-31 AND enable Trellis for perfect distribution.

Trellis
It is a sort of intelligent second quantization pass, in which a more thorough DCT quantization examination is done by the Trellis process. In this process it can drop some coefficients (removing detail) and bring back other coefficients that were removed by the simpler standard quantization routine. Dropping coefficients hurts detail, but if bitrate savings are higher, it means that the codec will be able to use lower quants and retain higher quality.


what's the point of using something that decreases file size removing detail??? :rolleyes:

Using the quantizers at 1/31 will also hurt on the final DRF of the file.. it will give higher quantizers (the higher the quantizer the bigger the loss of detail is) on parts that don't need them
And using quantizers level 1 it's also uselles since they use a bigger size and the difference betwen them and the quantizer level 2 can't be seen by the human eye :rolleyes:


the levels shoud be as the ones I said above for a DRF of min 2 (ideal) max 3 and bigger detail or

I frame 2/2
P frame 2/4
B frame 2/7

for a file that get's undersized, the final DRF will be a max of 4, higher than that it's a pretty average encode.. :)

[Sharktooth]

@TheRealDeal and others: as i already said, rate control perfectly knows WHEN and WHERE to put a frame with quant X.
If you screw the rate control parameters, obviously it wont work as expected.
Of course xvid rate control is not perfect, coz nothing is perfect but still better than anything that a human would chose without knowing the encoder internals and not knowing where and when to put a frame with quant X.
There is no point in using quant 2 for a black frame for example... so the encoder will use a higher quant (even 31 if its the case) and the result will be more bits for more important frames. problem comes when you force the encoder to NOT use higher quants... so in the end you get WORSE quality.
So, messing with RC parameters, expecially quant parameters is NOT a good idea... and DRF means nothing...

[TheRealDeal]

and DRF means nothing...

:helpful:

now there I LMAO...

now ask a REAL ENCODER what DRF is and what it stands for... :search:

The higher it is the worse quality a encode has... so don't tell me that fixed quantizers and DRF don't mean a thing

[Sharktooth]

LOL, you want to teach me the lesson? i encode since years, probably much more before you started.
DRF is a useless metric and just shows the quant distribution... that is useless (read again the example in my previous post... that extends to a whole lot of situations)... it doesnt mean ANYTHING coz a i can produce a better looking video with a worse DRF and in the worst case scenario a same looking video in less disk space (and that's a matter of fact!). If you dont believe me ask the xvid or x264 developers.
DRF is just a myth...

[TheRealDeal]

lol

if DRF is a myth as you say.. explain this then

here are the specs of an encode I've made from a Blu-Ray (real Blu-Ray not the mkv crap they call bluray) using only the resize filter on megui
I tested that theory a few weeks ago and here it is the result

with fixed quantizers of

I frame 1/1
P frame 1/3
B frame 1/7

[ About file ]

Name: Alice In Wonderland 1.avi
Date: 22/07/2010 18:40:54
Size: 2,723,960,832 bytes (2597.771 MB)

[ Generic infos ]

Play duration: 01:48:35 (6514.848181 s)
Container type: AVI OpenDML indexes multi-chunks (*)
Number of streams: 3
Type of stream nr. 0: video
Type of stream nr. 1: audio
Type of stream nr. 2: audio
Audio streams: 2
ISFT: VirtualDubMod 1.5.10.2 (build 2540/release)
JUNK: VirtualDubMod build 2540/release

[ Relevant data ]

Resolution: 720 x 400
Width: multiple of 16
Height: multiple of 16
Average DRF: 2.833386
Standard deviation: 1.094857
Std. dev. weighted mean: 0.474012

[ Video track ]

FourCC: XVID/XVID
Resolution: 720 x 400
Frame aspect ratio: 9:5 = 1.8
Pixel aspect ratio: 1:1 = 1
Display aspect ratio: 9:5 = 1.8
Framerate: 23.976 fps
Number of frames: 156200 (125726)
Stream size: 1,980,593,347 bytes
Bitrate: 2432.097622 kbps
Qf: 0.352218
Key frames: 2083 (0; 239; 478; 717; 956; ... 156036)
Null frames: 0
Min key int: 1
Max key int: 239
Avg key int: 74.987998
Delay: 0 ms

[ Audio track nr. 1 ]

Audio tag: 0x2000 (AC3)
Bitrate (container): 448 kbps CBR
Channels (container): 6
Sample rate (container): 48000 Hz
Chunks: 156188
Stream size: 364,827,904 bytes
Delay: 0 ms

[ Audio track nr. 2 ]

Audio tag: 0x2000 (AC3)
Bitrate (container): 448 kbps CBR
Channels (container): 6
Sample rate (container): 48000 Hz
Chunks: 156188
Stream size: 364,831,488 bytes
Delay: 0 ms

[ About MPEG4 encoding ]

User data: DivX503b1393p
User data: XviD0050
Packed bitstream: Yes (*)
QPel: No
GMC: No
Interlaced: No
Aspect ratio: Square pixels
Quant type: MPEG
Number of frames: 156200
Drop/delay frames: 0
Corrupted frames: 0

I-VOPs: 2083 ( 1.334 %)
P-VOPs: 60135 ( 38.499 %) ##########
B-VOPs: 93982 ( 60.168 %) ###############
S-VOPs: 0 ( 0.000 %)
N-VOPs: 0 ( 0.000 %)

Max consecutive B-VOPs: 2
1 consec: 19512 ( 34.384 %) #########
2 consec: 37235 ( 65.616 %) ################

[ DRF analysis ]

Average DRF: 2.833386
Standard deviation: 1.094857
Max DRF: 5

DRF=1: 23291 ( 14.911 %) ####
DRF=2: 38925 ( 24.920 %) ######
DRF=3: 34504 ( 22.090 %) ######
DRF=4: 59478 ( 38.078 %) ##########
DRF=5: 2 ( 0.001 %)
DRF>5: 0 ( 0.000 %)

I-VOPs average DRF: 1
I-VOPs std. deviation: 0
I-VOPs max DRF: 1

P-VOPs average DRF: 1.647360
P-VOPs std. deviation: 0.477861
P-VOPs max DRF: 3

B-VOPs average DRF: 3.632908
B-VOPs std. deviation: 0.482055
B-VOPs max DRF: 5

and with the default values of 1/31 for all frames

[ About file ]

Name: Alice In Wonderland 2.avi
Date: 22/07/2010 18:45:14
Size: 2,721,943,528 (2596.521 MB)

[ Generic infos ]

Play duration: 01:48:35 (6514.848181 s)
Container type: AVI
Number of streams: 3
Type of stream nr. 0: video
Type of stream nr. 1: audio
Type of stream nr. 2: audio
Audio streams: 2
ISFT: VirtualDubMod 1.5.10.2 (build 2540/release)
JUNK: VirtualDubMod build 2540/release

[ Relevant data ]

Resolution: 720 x 400
Width: multiple of 16
Height: multiple of 16
Average DRF: 3.034814
Standard deviation: 1.048243
Std. dev. weighted mean: 0.359382

[ Video track ]

FourCC: XVID/XVID
Resolution: 720 x 400
Frame aspect ratio: 9:5 = 1.8
Pixel aspect ratio: 1:1 = 1
Display aspect ratio: 9:5 = 1.8
Framerate: 23.976 fps
Number of frames: 156200
Stream size: 1,980,593,347 bytes
Bitrate: 2439.097622 kbps
Qf: 0.373960
Key frames: 2083 (0; 239; 478; 717; 956; ... 156036)
Null frames: 0
Min key int: 1
Max key int: 239
Avg key int: 74.987998
Delay: 0 ms

[ Audio track nr. 1 ]

Audio tag: 0x2000 (AC3)
Bitrate (container): 448 kbps CBR
Channels (container): 6
Sample rate (container): 48000 Hz
Chunks: 156198
Stream size: 364,827,904 bytes
Delay: 0 ms

[ Audio track nr. 2 ]

Audio tag: 0x2000 (AC3)
Bitrate (container): 448 kbps CBR
Channels (container): 6
Sample rate (container): 48000 Hz
Chunks: 156199
Stream size: 364,829,696 bytes
Delay: 0 ms

[ About MPEG4 encoding ]

User data: DivX503b1393p
User data: XviD0050
Packed bitstream: Yes (*)
QPel: No
GMC: No
Interlaced: No
Aspect ratio: Square pixels
Quant type: MPEG
Number of frames: 156200
Drop/delay frames: 0
Corrupted frames: 0

I-VOPs: 2083 ( 1.334 %)
P-VOPs: 60135 ( 38.499 %) ##########
B-VOPs: 93982 ( 60.168 %) ###############
S-VOPs: 0 ( 0.000 %)
N-VOPs: 0 ( 0.000 %)

Max consecutive B-VOPs: 2
1 consec: 19512 ( 34.384 %) #########
2 consec: 37235 ( 65.616 %) ################

[ DRF analysis ]

Average DRF: 3.034814
Standard deviation: 1.048243
Max DRF: 5

DRF=1: 10481 ( 6.710 %) ##
DRF=2: 51724 ( 33.114 %) ########
DRF=3: 15897 ( 10.177 %) ###
DRF=4: 78072 ( 49.982 %) ############
DRF=5: 26 ( 0.017 %)
DRF>5: 0 ( 0.000 %)

I-VOPs average DRF: 1
I-VOPs std. deviation: 0
I-VOPs max DRF: 1

P-VOPs average DRF: 1.860563
P-VOPs std. deviation: 0.347024
P-VOPs max DRF: 3

B-VOPs average DRF: 3.831265
B-VOPs std. deviation: 0.375255
B-VOPs max DRF: 5



as you can see the size and final video bitrate is practically the same but the DRF of the fixed quantizers is lower than the default values... That alone means that the 1st encode retained more quality from the source because the smaller DRF is closer to the original file the encode is. That is what DRF is used for, it's almost a quality check from the source to the encode but if that alone is not enough to show you that fixed quantizers and lower DRF is better on a xvid encode here are 3 snapshots from the two encodes taken from B frames (because those are the ones that represent the bigger part of the rip, and if a movie is good on the B frames than on the P/I should be good also, most of the people take ss from I frames that are the ones who look better but don't represent the quality of the rip so I frames ss can deceive the quality of the rip)

first are the fixed quantizers and then the default ones pic

http://comparescreenshots.slicx.com/comparison/69007/picture:0


as you can see from one picture to another the quality loss is very noticeble being the worst picture (the 2nd one) the one that used the default quantizers (1/31) wich means that precise frame used a higher value of quantizer that made the image look WORSE!!!

So.. here it is the myth working fine with fixed values :devil:

Maybe what you are saying it's true to x264 encodes... I'll give you that but to xvid encodes it's not!!

[Selur]

btw. about oversizing with Xvid it normally helps to adjust the overflow treatment settings (especially strength). I normally use 10 instead of the default 5.
(I agree with staying with quantizer range 1-31, but with Xvid I always use 2pass encoding,..)

[AlekseiV]

here are the specs of an encode I've made from a Blu-Ray (real Blu-Ray not the mkv crap they call bluray)lol... encoding BluRay to XviD and calling an x264 MKV "crap"... :p

[Sharktooth]

lol

if DRF is a myth as you say.. explain this then

here are the specs of an encode I've made from a Blu-Ray (real Blu-Ray not the mkv crap they call bluray) using only the resize filter on megui
I tested that theory a few weeks ago and here it is the result

with fixed quantizers of

I frame 1/1
P frame 1/3
B frame 1/7

[ About file ]

Name: Alice In Wonderland 1.avi
Date: 22/07/2010 18:40:54
Size: 2,723,960,832 bytes (2597.771 MB)

[ Generic infos ]

Play duration: 01:48:35 (6514.848181 s)
Container type: AVI OpenDML indexes multi-chunks (*)
Number of streams: 3
Type of stream nr. 0: video
Type of stream nr. 1: audio
Type of stream nr. 2: audio
Audio streams: 2
ISFT: VirtualDubMod 1.5.10.2 (build 2540/release)
JUNK: VirtualDubMod build 2540/release

[ Relevant data ]

Resolution: 720 x 400
Width: multiple of 16
Height: multiple of 16
Average DRF: 2.833386
Standard deviation: 1.094857
Std. dev. weighted mean: 0.474012

[ Video track ]

FourCC: XVID/XVID
Resolution: 720 x 400
Frame aspect ratio: 9:5 = 1.8
Pixel aspect ratio: 1:1 = 1
Display aspect ratio: 9:5 = 1.8
Framerate: 23.976 fps
Number of frames: 156200 (125726)
Stream size: 1,980,593,347 bytes
Bitrate: 2432.097622 kbps
Qf: 0.352218
Key frames: 2083 (0; 239; 478; 717; 956; ... 156036)
Null frames: 0
Min key int: 1
Max key int: 239
Avg key int: 74.987998
Delay: 0 ms

[ Audio track nr. 1 ]

Audio tag: 0x2000 (AC3)
Bitrate (container): 448 kbps CBR
Channels (container): 6
Sample rate (container): 48000 Hz
Chunks: 156188
Stream size: 364,827,904 bytes
Delay: 0 ms

[ Audio track nr. 2 ]

Audio tag: 0x2000 (AC3)
Bitrate (container): 448 kbps CBR
Channels (container): 6
Sample rate (container): 48000 Hz
Chunks: 156188
Stream size: 364,831,488 bytes
Delay: 0 ms

[ About MPEG4 encoding ]

User data: DivX503b1393p
User data: XviD0050
Packed bitstream: Yes (*)
QPel: No
GMC: No
Interlaced: No
Aspect ratio: Square pixels
Quant type: MPEG
Number of frames: 156200
Drop/delay frames: 0
Corrupted frames: 0

I-VOPs: 2083 ( 1.334 %)
P-VOPs: 60135 ( 38.499 %) ##########
B-VOPs: 93982 ( 60.168 %) ###############
S-VOPs: 0 ( 0.000 %)
N-VOPs: 0 ( 0.000 %)

Max consecutive B-VOPs: 2
1 consec: 19512 ( 34.384 %) #########
2 consec: 37235 ( 65.616 %) ################

[ DRF analysis ]

Average DRF: 2.833386
Standard deviation: 1.094857
Max DRF: 5

DRF=1: 23291 ( 14.911 %) ####
DRF=2: 38925 ( 24.920 %) ######
DRF=3: 34504 ( 22.090 %) ######
DRF=4: 59478 ( 38.078 %) ##########
DRF=5: 2 ( 0.001 %)
DRF>5: 0 ( 0.000 %)

I-VOPs average DRF: 1
I-VOPs std. deviation: 0
I-VOPs max DRF: 1

P-VOPs average DRF: 1.647360
P-VOPs std. deviation: 0.477861
P-VOPs max DRF: 3

B-VOPs average DRF: 3.632908
B-VOPs std. deviation: 0.482055
B-VOPs max DRF: 5

and with the default values of 1/31 for all frames

[ About file ]

Name: Alice In Wonderland 2.avi
Date: 22/07/2010 18:45:14
Size: 2,721,943,528 (2596.521 MB)

[ Generic infos ]

Play duration: 01:48:35 (6514.848181 s)
Container type: AVI
Number of streams: 3
Type of stream nr. 0: video
Type of stream nr. 1: audio
Type of stream nr. 2: audio
Audio streams: 2
ISFT: VirtualDubMod 1.5.10.2 (build 2540/release)
JUNK: VirtualDubMod build 2540/release

[ Relevant data ]

Resolution: 720 x 400
Width: multiple of 16
Height: multiple of 16
Average DRF: 3.034814
Standard deviation: 1.048243
Std. dev. weighted mean: 0.359382

[ Video track ]

FourCC: XVID/XVID
Resolution: 720 x 400
Frame aspect ratio: 9:5 = 1.8
Pixel aspect ratio: 1:1 = 1
Display aspect ratio: 9:5 = 1.8
Framerate: 23.976 fps
Number of frames: 156200
Stream size: 1,980,593,347 bytes
Bitrate: 2439.097622 kbps
Qf: 0.373960
Key frames: 2083 (0; 239; 478; 717; 956; ... 156036)
Null frames: 0
Min key int: 1
Max key int: 239
Avg key int: 74.987998
Delay: 0 ms

[ Audio track nr. 1 ]

Audio tag: 0x2000 (AC3)
Bitrate (container): 448 kbps CBR
Channels (container): 6
Sample rate (container): 48000 Hz
Chunks: 156198
Stream size: 364,827,904 bytes
Delay: 0 ms

[ Audio track nr. 2 ]

Audio tag: 0x2000 (AC3)
Bitrate (container): 448 kbps CBR
Channels (container): 6
Sample rate (container): 48000 Hz
Chunks: 156199
Stream size: 364,829,696 bytes
Delay: 0 ms

[ About MPEG4 encoding ]

User data: DivX503b1393p
User data: XviD0050
Packed bitstream: Yes (*)
QPel: No
GMC: No
Interlaced: No
Aspect ratio: Square pixels
Quant type: MPEG
Number of frames: 156200
Drop/delay frames: 0
Corrupted frames: 0

I-VOPs: 2083 ( 1.334 %)
P-VOPs: 60135 ( 38.499 %) ##########
B-VOPs: 93982 ( 60.168 %) ###############
S-VOPs: 0 ( 0.000 %)
N-VOPs: 0 ( 0.000 %)

Max consecutive B-VOPs: 2
1 consec: 19512 ( 34.384 %) #########
2 consec: 37235 ( 65.616 %) ################

[ DRF analysis ]

Average DRF: 3.034814
Standard deviation: 1.048243
Max DRF: 5

DRF=1: 10481 ( 6.710 %) ##
DRF=2: 51724 ( 33.114 %) ########
DRF=3: 15897 ( 10.177 %) ###
DRF=4: 78072 ( 49.982 %) ############
DRF=5: 26 ( 0.017 %)
DRF>5: 0 ( 0.000 %)

I-VOPs average DRF: 1
I-VOPs std. deviation: 0
I-VOPs max DRF: 1

P-VOPs average DRF: 1.860563
P-VOPs std. deviation: 0.347024
P-VOPs max DRF: 3

B-VOPs average DRF: 3.831265
B-VOPs std. deviation: 0.375255
B-VOPs max DRF: 5



as you can see the size and final video bitrate is practically the same but the DRF of the fixed quantizers is lower than the default values... That alone means that the 1st encode retained more quality from the source because the smaller DRF is closer to the original file the encode is. That is what DRF is used for, it's almost a quality check from the source to the encode but if that alone is not enough to show you that fixed quantizers and lower DRF is better on a xvid encode here are 3 snapshots from the two encodes taken from B frames (because those are the ones that represent the bigger part of the rip, and if a movie is good on the B frames than on the P/I should be good also, most of the people take ss from I frames that are the ones who look better but don't represent the quality of the rip so I frames ss can deceive the quality of the rip)

first are the fixed quantizers and then the default ones pic

http://comparescreenshots.slicx.com/comparison/69007/picture:0


as you can see from one picture to another the quality loss is very noticeble being the worst picture (the 2nd one) the one that used the default quantizers (1/31) wich means that precise frame used a higher value of quantizer that made the image look WORSE!!!

So.. here it is the myth working fine with fixed values :devil:

Maybe what you are saying it's true to x264 encodes... I'll give you that but to xvid encodes it's not!!
First, having a lower DRF doesnt mean higher quality.
As i said, if the encoder chooses to place a higher quant for a certain frame it means it will use a lower quant for another frame. That's usually done with some criteria and as i previously said, it will lead to a better overall picture quality.
clamping min/max quants wont help at all.
also comparing 3 pictures on a whole encode is a bit unfair also coz you didnt show the frametype (I/P/B)... so you're comparing apples with oranges.
DRF is NOT used in any software except DRF analyzer and avinaptic... there is a reason...
also in the first encode the one with quantizers clamped, just notice HOW MANY quant 1 frames there are. Now, if you look around the forum you will notice that quant 1 frames are just a WASTE of space coz they will give almost no quality benefits over quant 2 frames.
Also look at deviation. In your first encode it's higher meaning there are more quantizers fluctuations... that means fluctuating picture quality... that said, im not impressed AT ALL by the 3 screenshots you posted. maybe post a clip of both encodes instead...
so here's your theory teared apart...