|
|
undersized files with 0.28 alpha 3 ?
I've had a bunch of jobs done overnight (with 5.0.2 as a codec)
all of them ~50Mb short of the target size (2CD rips)
I was just wondering has anybody else tried the same config and have undersized files as well...
just so that you know that i'm looking into it - correct bitrate sometimes not being propagated to the codec settings
but no worries
update
it looks to me like bitrate value has to be mutiply by 1024 rather than 1000 in order to see the same value in the codec...
(I was confused with diffence in the past...)
will be fixed in the alpha4...
(for the moment you can manually adjust bitrate)
always check analyze.log (divx5) if you do not get correct filesize. in the last line you clearly see if the codec did reach the given goal or not.
wef.
Originally posted by TheWEF
always check analyze.log (divx5) if you do not get correct filesize. in the last line you clearly see if the codec did reach the given goal or not.
wef.
Can you explain that bit a little bit more, plz?
For instance, in the end I can see something like:
Progress: expected 2604548664, achieved 1457195384
(this actually from encode where the movie was maxed out
- only quant 2 is used through out analyse.log)
So basically you're saying that if achieved is less than expected
then it's not codecs fault - it did whatever it could ?
Originally posted by len0x
So basically you're saying that if achieved is less than expected
then it's not codecs fault - it did whatever it could ?
it means that the program did set the correct bitrate (in terms of calculating correctly).
the codec quot;did whatever it couldquot;, but it was quot;the codecs faultquot; or it's limitations that the filesize is wrong.
since everything is quant-2 it actually was the users fault, because he didn't do a compcheck to find out that his desired bitrate was above the limit...
2604548664 bits should be the videosize that you can read in gknots bitrate tab (~ 310 Mb).
wef.
Originally posted by TheWEF
since everything is quant-2 it actually was the users fault, because he didn't do a compcheck to find out that his desired bitrate was above the limit...
wef.
well , I don't think it's users fault, though
I knew that it's gonna be maxed out (very dark source, comp test 150% ) - but there is no way I can do the desirable size, anyway
ok, now I don't get: I have analyse.log with not reaching
expecting values. But quant is not always 2!
I'm using 5.0.2 with no b-frames. Is that codecs fault ?
Originally posted by len0x
Is that codecs fault ?
Yes, this is a known problem with DivX5.02. As a rule of thumb you should use quality based encoding if you have 80% or higher in the compression test or you'll get undersized files.
Originally posted by hakko504
Yes, this is a known problem with DivX5.02. As a rule of thumb you should use quality based encoding if you have 80% or higher in the compression test or you'll get undersized files.
that's odd - never had such problem before...
(but I was messing around with .2 .3 .4 beta recently - may be problem comes from settigs)
p.s. although this time I was ripping Gone With the Wind on 4CDs
(and ended up with just 40 mb short in total)
Originally posted by hakko504
As a rule of thumb you should use quality based encoding if you have 80% or higher in the compression test or you'll get undersized files
... or adjust the settings or script (showthread.php?s=amp;threadid=24584) to decrease the compressability so that you still can use 2-pass encoding if it's important that you reach a specific size.
I did 2 rips using different movies with Gknot 0.28 Alpha 4, Divx 5.03, and CD set to 700MB, 2-Pass. Both files where about the same size, 672MB and 673MB. I’m going to run another a couple of other moive to see if it keeps happening.
Originally posted by DoC hEx
I did 2 rips using different movies with Gknot 0.28 Alpha 4, Divx 5.03, and CD set to 700MB, 2-Pass. Both files where about the same size, 672MB and 673MB. I’m going to run another a couple of other moive to see if it keeps happening.
I did 4 rips in total two of them are ok, but the other two has sort of the same problems as yours... It's strange, coz I bet if you look analyze.log you'll see that codec didn't do well (achieved lt; expected).
But I'd test it with original GK 0.27 to be safe.
I'm starting to suspect that may be log/mv files are not read properly between passes with new version of GK (although I'm not sure if it's possible at all...)
hi all,
great to see gk is now open source and it's going to be more actively developed!!
i also have the same undersize problem here,
i am using 5.02, got beta 3 and overwrite the exe in my gk folder
ripped a pair of movies and both of them were 30-40 MB undersized, strange because both are noisy and old
(i usually make 715MB movies)
best regards!!!
Originally posted by anr
i also have the same undersize problem here,
i am using 5.02, got beta 3 and overwrite the exe in my gk folder
ripped a pair of movies and both of them were 30-40 MB undersized, strange because both are noisy and old if you're using credits - before alpha 5 recalculations of the bitrate after encode of the credits were not properly set (end hence lower bitrate that should be - less size). Alpha 5 should fix that problem. |
|