yetanotherid
21st April 2008, 18:18
This target file size thing.....
This post turned out to be a real scroller. I'm sorry about that, but I did some experimenting with converting and output file size, and am after an opinion as to what's going on, so I posted as much information regarding the different conversions I've done as I thought I'd need to.
First off, I'll admit I'm frighteningly new to the whole ripping DVDs to AVIs exercise. In fact my first rip was only about 6 days ago, although I've done many since then. I'm using AutoGK and have experimented with different versions of the XviD encoder, and aside from the file size issue which is the purpose of this post I've been very happy with the results. Most of the time, the quality of the output file has been superior to 99% of the AVI's I've downloaded. It makes me wonder why so many people seem to manage to produce such average quality rips.
Anyway... my first rip was with using AutoGK 2.8 (which I'm still using) and the XviD decoder that comes with it (or with version 2.5 of AutoGK to be exact). It was nowhere near the target file size I specified. So I read through this forum looking for answers but don't know if any of them are applicable, as I'm not sure simply "tweaking" settings is the answer. Plus I don't want to fiddle with something I don't understand, given that I assume the purpose of using AutoKG is because it'll make better decisions than I could. I tried a different version of the codec and hit the target size exactly, but the next rip (same input vob) was a mile off again. So I tried to carry out a bit of an experiment with different versions of XviD and found the results interesting. I used the same version of AutoGK each time (2.8) and between each rip I uninstalled the version of XviD I'd just used, removed all XviD traces from the registry, made sure all XviD's files were really gone from the hard drive, and rebooted the computer between rips if that's what I needed to do to make sure the previous version was completely gone. I didn't touch any of the XviD codec settings before any of the conversions, letting AutoGK handle everything (which I assume it does anyway so I didn't want to do anything that might have interfered with it working properly).
For the experimental conversions I ripped a small vob to my hard drive, and used that same vob each time. I'd previously theorised that there was no direct relation to the specified output file size being achieved and whether I let AutoGK choose the resolution or if I set it myself, so I set the same specific resolution each time. I also manually set the same bit rate for the audio, which was in MP3 format. I figured that way, there's two variables which won't be variable any more.
So here's the upshot of it all....
Only one version of the XviD codec I used hit my 100MB target size exactly each and every time (well give or take a few KBs). Every single one of the other codec versions has either failed to achieve the target size for me, or hit it one time, then missed it another (I didn't do multiple conversions with each codec version but I did do so with a couple of them, partly because I did the converting on two different computers at first to make sure the hardware or OS weren't a factor in hitting the target file size). But here's the bit I've been trying to get to....
None of the codecs missed the target size (if they didn't achieve it) by what I'd describe as a random amount. Every time the target size was missed the actual size was 60MB (as opposed to the 100MB size I specified) give or take 0.5MB either way, so to my way of thinking it's as if when the target size was missed, it's because the codec was actually aiming for the wrong size for some reason. Almost like AutoGK and the codec weren't communicating properly, and not because a setting in the codec itself needed a tweak. And because as far as I can tell AutoGK will over-ride any codec tweaking I might do anyway, there wouldn't be much point in doing so. Of course I could be wrong about all this as I'm just a newbie, but I'm curious and trying to find out just what's going wrong.
I also tried one of the codecs which was only outputting a 60MB file with another GUI type converter and got the same results, so maybe it's not AutoGK's fault.
Below are the results I got with the different codec versions. Maybe there's an expert here who's been patient enough to get through my post to this point, and would care to offer an explanation. After I did the converting I compared AutoGKs log files for each rip, and all the relevant bits were exactly the same for each one. I've posted the compression values from those files here, although they didn't vary much. They did appear to slightly differ (once again by the same amount) according to whether the output file size was correct or not. All the scripts AutoGK produced were the same.
Target File size for all conversions: 100MB
All logs:
Output will contain 15174 frames
Video size: 96,293,688 bytes (91.83 Mb)
Conversion 1A: 60.5MB
Koepi's XviD, version 1.0.3 (20/12/2004), Core2 Duo E6750 PC
Compressibility percentage is: 65.26
Predicted comptest value is: 65.26%
Expected quality of first pass size: 63.07%
Second pass speed was: 91.76 fps.
Total time: 6 minutes 24 seconds.
Conversion 1B: 100MB
Koepi's XviD, version 1.0.3 (20/12/2004), AMD 3200+ PC
Compressibility percentage is: 65.33
Predicted comptest value is: 65.33%
Expected quality of first pass size: 63.49%
Second pass speed was: 21.96 fps
Total time: 23 minutes 46 seconds
Conversions 2A & 2B: 60.5MB
Nic's XviD version 1.1.0 (06/04/2005), Core2 Duo E6750 PC (Results identical on AMD 3200+ PC)
Compressibility percentage is: 65.26
Predicted comptest value is: 65.26%
Expected quality of first pass size: 63.07%
Conversion 3: 100MB
Koepi's XviD version 1.1.2 (01/02/2007), Core2 Duo E6750 PC
Compressibility percentage is: 65.33
Predicted comptest value is: 65.33%
Expected quality of first pass size: 63.49%
Second Pass speed was: 87.03 fps
Total time: 6 minutes 32 seconds
Conversion 4: 59.8MB
Koepi's XviD version 1.1.3 Final (28/06/2007), Core2 Duo E6750 PC
Compressibility percentage is: 65.30
Predicted comptest value is: 65.30%
Expected quality of first pass size: 63.07%
Second Pass speed was: 94.33 fps
Total time: 6 minutes 24 seconds
Conversion 5: 100MB
Koepi's XviD version 1.2.127 Alpha (25/02/2006), Core2 Duo E6750 PC
Compressibility percentage is: 84.45
Using sharper matrix
Predicted comptest value is: 76.26%
Expected quality of first pass size: 86.75%
Speed was: 94.62 fps
Total time: 6 minutes 20 seconds
Conversion 6: 59.9MB
88keys XviD version 1.2.127 (29/03/2008), Core2 Duo E6750 PC
Compressibility percentage is: 84.45%
Using sharper matrix
Predicted comptest value is: 76.26%
Expected quality of first pass size: 86.75%
Second Pass speed was: 96.73 fps
Total time: 6 minutes 17 seconds
So I guess the 1.2 version of the encoder gives the same file sizes with better quality than the 1.1 version does. Or am I reading that wrong?
It was also interesting that the total encoding times for both the 1.1 and 1.2 versions didn't vary all that much from conversion to conversion on the same computer. I'd read that the 1.2 encoder version was optimised for dual core processors, but the 1.1 version was using both cores anyway, and was only a few seconds slower, so I'm not sure what the difference is.
And last but not least.....
At some stage I've used all the above versions of XviD until each one produced a file smaller than the specified size. At that point I stopped using it and tried another, which usually happened within a couple of conversions if it didn't happen the first time (like it's a 50/50 chance each time). So now I'm using the only codec version which after days and days of encoding, has not produced anything other than a file of pretty much the exact target size, no matter what other settings I give AutoGK to work with.
And that's Koepi's XviD version 1.2.127 Alpha (25/02/2006).
So does anyone know why a codec would hit the target size, seemingly only about 50% of the time, then output a smaller file size the other 50% of the time, and when it does output the smaller file size, why it's wrong by the exact same amount each time?
I've attached (hopefully) some of AutoGK's log files in case anyone wants to check that I'm not missing something.
Thanks.
This post turned out to be a real scroller. I'm sorry about that, but I did some experimenting with converting and output file size, and am after an opinion as to what's going on, so I posted as much information regarding the different conversions I've done as I thought I'd need to.
First off, I'll admit I'm frighteningly new to the whole ripping DVDs to AVIs exercise. In fact my first rip was only about 6 days ago, although I've done many since then. I'm using AutoGK and have experimented with different versions of the XviD encoder, and aside from the file size issue which is the purpose of this post I've been very happy with the results. Most of the time, the quality of the output file has been superior to 99% of the AVI's I've downloaded. It makes me wonder why so many people seem to manage to produce such average quality rips.
Anyway... my first rip was with using AutoGK 2.8 (which I'm still using) and the XviD decoder that comes with it (or with version 2.5 of AutoGK to be exact). It was nowhere near the target file size I specified. So I read through this forum looking for answers but don't know if any of them are applicable, as I'm not sure simply "tweaking" settings is the answer. Plus I don't want to fiddle with something I don't understand, given that I assume the purpose of using AutoKG is because it'll make better decisions than I could. I tried a different version of the codec and hit the target size exactly, but the next rip (same input vob) was a mile off again. So I tried to carry out a bit of an experiment with different versions of XviD and found the results interesting. I used the same version of AutoGK each time (2.8) and between each rip I uninstalled the version of XviD I'd just used, removed all XviD traces from the registry, made sure all XviD's files were really gone from the hard drive, and rebooted the computer between rips if that's what I needed to do to make sure the previous version was completely gone. I didn't touch any of the XviD codec settings before any of the conversions, letting AutoGK handle everything (which I assume it does anyway so I didn't want to do anything that might have interfered with it working properly).
For the experimental conversions I ripped a small vob to my hard drive, and used that same vob each time. I'd previously theorised that there was no direct relation to the specified output file size being achieved and whether I let AutoGK choose the resolution or if I set it myself, so I set the same specific resolution each time. I also manually set the same bit rate for the audio, which was in MP3 format. I figured that way, there's two variables which won't be variable any more.
So here's the upshot of it all....
Only one version of the XviD codec I used hit my 100MB target size exactly each and every time (well give or take a few KBs). Every single one of the other codec versions has either failed to achieve the target size for me, or hit it one time, then missed it another (I didn't do multiple conversions with each codec version but I did do so with a couple of them, partly because I did the converting on two different computers at first to make sure the hardware or OS weren't a factor in hitting the target file size). But here's the bit I've been trying to get to....
None of the codecs missed the target size (if they didn't achieve it) by what I'd describe as a random amount. Every time the target size was missed the actual size was 60MB (as opposed to the 100MB size I specified) give or take 0.5MB either way, so to my way of thinking it's as if when the target size was missed, it's because the codec was actually aiming for the wrong size for some reason. Almost like AutoGK and the codec weren't communicating properly, and not because a setting in the codec itself needed a tweak. And because as far as I can tell AutoGK will over-ride any codec tweaking I might do anyway, there wouldn't be much point in doing so. Of course I could be wrong about all this as I'm just a newbie, but I'm curious and trying to find out just what's going wrong.
I also tried one of the codecs which was only outputting a 60MB file with another GUI type converter and got the same results, so maybe it's not AutoGK's fault.
Below are the results I got with the different codec versions. Maybe there's an expert here who's been patient enough to get through my post to this point, and would care to offer an explanation. After I did the converting I compared AutoGKs log files for each rip, and all the relevant bits were exactly the same for each one. I've posted the compression values from those files here, although they didn't vary much. They did appear to slightly differ (once again by the same amount) according to whether the output file size was correct or not. All the scripts AutoGK produced were the same.
Target File size for all conversions: 100MB
All logs:
Output will contain 15174 frames
Video size: 96,293,688 bytes (91.83 Mb)
Conversion 1A: 60.5MB
Koepi's XviD, version 1.0.3 (20/12/2004), Core2 Duo E6750 PC
Compressibility percentage is: 65.26
Predicted comptest value is: 65.26%
Expected quality of first pass size: 63.07%
Second pass speed was: 91.76 fps.
Total time: 6 minutes 24 seconds.
Conversion 1B: 100MB
Koepi's XviD, version 1.0.3 (20/12/2004), AMD 3200+ PC
Compressibility percentage is: 65.33
Predicted comptest value is: 65.33%
Expected quality of first pass size: 63.49%
Second pass speed was: 21.96 fps
Total time: 23 minutes 46 seconds
Conversions 2A & 2B: 60.5MB
Nic's XviD version 1.1.0 (06/04/2005), Core2 Duo E6750 PC (Results identical on AMD 3200+ PC)
Compressibility percentage is: 65.26
Predicted comptest value is: 65.26%
Expected quality of first pass size: 63.07%
Conversion 3: 100MB
Koepi's XviD version 1.1.2 (01/02/2007), Core2 Duo E6750 PC
Compressibility percentage is: 65.33
Predicted comptest value is: 65.33%
Expected quality of first pass size: 63.49%
Second Pass speed was: 87.03 fps
Total time: 6 minutes 32 seconds
Conversion 4: 59.8MB
Koepi's XviD version 1.1.3 Final (28/06/2007), Core2 Duo E6750 PC
Compressibility percentage is: 65.30
Predicted comptest value is: 65.30%
Expected quality of first pass size: 63.07%
Second Pass speed was: 94.33 fps
Total time: 6 minutes 24 seconds
Conversion 5: 100MB
Koepi's XviD version 1.2.127 Alpha (25/02/2006), Core2 Duo E6750 PC
Compressibility percentage is: 84.45
Using sharper matrix
Predicted comptest value is: 76.26%
Expected quality of first pass size: 86.75%
Speed was: 94.62 fps
Total time: 6 minutes 20 seconds
Conversion 6: 59.9MB
88keys XviD version 1.2.127 (29/03/2008), Core2 Duo E6750 PC
Compressibility percentage is: 84.45%
Using sharper matrix
Predicted comptest value is: 76.26%
Expected quality of first pass size: 86.75%
Second Pass speed was: 96.73 fps
Total time: 6 minutes 17 seconds
So I guess the 1.2 version of the encoder gives the same file sizes with better quality than the 1.1 version does. Or am I reading that wrong?
It was also interesting that the total encoding times for both the 1.1 and 1.2 versions didn't vary all that much from conversion to conversion on the same computer. I'd read that the 1.2 encoder version was optimised for dual core processors, but the 1.1 version was using both cores anyway, and was only a few seconds slower, so I'm not sure what the difference is.
And last but not least.....
At some stage I've used all the above versions of XviD until each one produced a file smaller than the specified size. At that point I stopped using it and tried another, which usually happened within a couple of conversions if it didn't happen the first time (like it's a 50/50 chance each time). So now I'm using the only codec version which after days and days of encoding, has not produced anything other than a file of pretty much the exact target size, no matter what other settings I give AutoGK to work with.
And that's Koepi's XviD version 1.2.127 Alpha (25/02/2006).
So does anyone know why a codec would hit the target size, seemingly only about 50% of the time, then output a smaller file size the other 50% of the time, and when it does output the smaller file size, why it's wrong by the exact same amount each time?
I've attached (hopefully) some of AutoGK's log files in case anyone wants to check that I'm not missing something.
Thanks.