My DivX is too long

[floxi]

Hi!


My Problem is that my DivX is too long - I set the file size to two CDs with 700mb. Now each part is about 720mb so I am not able to burn it on CD.

Is there any possibility to compress the finished DivX parts again (without heavy loss of quality)?



Thanks

floxi

[Mac Sidewinder]

You could always join the files and either cut the credits off (and leave them off) or cut the credits off and re-encode them at a lower bitrate and see if that saves you enough space when you split the file again. If you re-encode the whole divx you will lose quality. You would be better off simply redoing the whole project and specify a smaller cd size.

If you used ac3 sound you could switch to mp3 to save space also. Just a few ideas.

Mac

[floxi]

hi!


thanks for your help!


floxi

[theReal]

Are you sure the size is 720 MB, or is it just 720,000 KB? I mostly end up with 716,000 - 718,000 KB files, that's why I'm asking. You have to divide it by 1024, not by 1000 to get the MB value, so it would only be ~703MB.

[floxi]

no, it is definitely too long. the file size of the whole movie is [1.504.157.696 bytes].

but thanks anyway


greetings

f´loxi

[jggimi]

Which is 1.400856018 GB. A hair oversize for 2 700MB CDs. :cool:

[theReal]

Is 17 MB a hair? As long as you divide by 1024, the 1.400856018 GB are 2 x 717 MB, which is indeed a little much for overburning.

Now I guess floxi you calculated the bitrate for Divx 4/5 and encoded with Divx 3??
This would theoretically result in a file that is 14 MB oversized every 700 MB (and 17 MB oversized is very probable), because Divx3 and Divx4 have different interpretations of the set bitrate (one divides by 1000, the other by 1024, I think).

If you have not yet encoded the end-credits seperately, you could try to squeeze them with a maximum quantizer, this might save you 30MB alltogether - enough for burning on 2CDs.

[TheWEF]

Originally posted by theReal
...Now I guess floxi you calculated the bitrate for Divx 4/5 and encoded with Divx 3...

hmm... actually that's not possible with gknot.

do you have two audio streams? are you sure you set correct interleaving?

wef.

[floxi]

i have only one audio-stream but waht IS interleaving?


thx


floxi

[snowbeach]

Hi guys!
I was surprised today seeing that my finished avi file is 1.444.010 KB big. Oooops! I ripped "Saving Private Ryan" with 640x352 (aspect ratio 1,78:1) and a bitrate of 1073 kbps for 2x700MB CDs (calculated by DivX4 Bitrate Calculator).
I do not why, but I think the problem are the proportions, I bet that the same movie with the poroportions of 640x272 and the rest stays as it is, will not lead to an bigger file than 1.400.000 KB. I gonna test it.
Can somebody confirm that and if yes what I need to change? The bitrate? :confused:
Thanks in advance....;)


PS: I'm not using GKnot!

[theReal]

I can't imagine aspect ratio could have such a negative influence on the filesize prediction.

Are you using psycho-visual settings? I heard this might lead to slightly wrong filesizes. However, usually Divx5 sticks to the bitrate very well.

btw. I'd just burn that movie like it is. Every 80 min CDR takes 705MB, I'm sure. You might get problems with filesizes around 710MB, but 705 should be ok.

(1,444,010/1024 = 1410 MB)

[snowbeach]

Hi theReal, thanks for your fast response.

I finished the test and you are right, it would be weird, if the aspect ratio influences the file size. The result is: I got nearly the same file size (640x352: 1.444.010 KB and 640x272: 1.444.604 KB).

No, I do not use psyco-visual effects due I do not exactly know what they're good for.
I experienced overburning with 80 min CDR (Memorex) up to 715 MB.

But there is still a mystery I face, because I also ripped "Sleepers", 2,4:1 aspect ratio and ca. 141 min. with 128 kbps audio decoding. The DivX4 Bitrate calculator says that I have to encode for 2 CDs with a bitrate of 1260 kbps. The result of the AVI file is 1105 MB (MP3 audio file included).
And as I said, for "Saving Private Ryan", aspect ratio 1,78:1, ca. 163 min. with 128 kbps decoded audio file the calculator says to use a bitrate of 1073 kbps. But in this case I got a file that is 1444 MB big (MP3 audio file included). :confused: :confused:

Hmmm???? Do you have an idea?

[theReal]

Look at the analyse log of sleepers. If it says "average quantizer: 2.0", you know why it doesn't get bigger (because it can't, quant 2 is 100% quality).

I heard that Saving Private Ryan is horrible to compress, maybe that makes it grow bigger than it should.

[snowbeach]

Cool. I learned something new. Does "average quantizer: 2.0" always mean that the compression is 100% quality? What are the other possibilities for average quantizer and what do they mean?

Are problems, like I've faced now, predictable? And what is the solution in this case? I think I have to reduce the bitrate? (Is there any math formula or just trial and error?)

Many thanks in advance! ;)

[theReal]

Quantizer 2 is the best quality a frame can be encoded at, so an average of 2.0 means all frames were encoded at 2.
DivX with it's default settings can chose between 2 and 12 to achieve the desired bitrate in the end.

The problem of a too small divx is predictable: use Gknot, make a compress test and see what numbers you get. Then, you can choose a higher resolution before you encoded the whole movie.

The file getting too large is an exception, I think, and you can't predict it (with a bitrate that is too low, usually the quality is crap, but the filesize is still correct). You can encode it again at a lower bitrate and hope that this will never happen to you again ;)
And again, use Gknot, so you're sure the bitrate calculation takes into account frame overhead and audio-overhead and stuff...

[snowbeach]

Thank you very much for your information. ;)

Due to the fact that I'm a fan of manual work ;) (create my own AVS file, etc.), I am interested in the way doing it without GKnot.
Do we have other ways to make a compress test to predict the quantizer (e.g. some math)?

[theReal]

You can run a first-pass of 5% of the whole movie and then read the log file frame by frame. It will only take you about a week or so until you are through ;)

[snowbeach]

ok. i think i will stay then with gknot. :cool: thanks.

[llemor]

FYI, there's a workaround in manual work.

1) create your avs - use SelectRangeEvery(280,14) for 5% comp. test

2) open your avs with VDub, then set DivX5.02 codec to 1-pass quality based mode with quntizer=2.

3) save your avi test file

4) get the filesize of your encoded avi test file

5) calculate bits/(pixel*frame)

= avi test filesize(in KB)*1024*8/(w*h*framenos/framerate)

for framenos = (total framecount/280)*14 + 14

Difficult? then let's stick to GKnot's way :D :D :D

[theReal]

llemor, that doesn't really make a good compress test because you have all those scene-changes (every 14 frames) in your calculation.
That makes the filesize of the 100% quality file too big.

The only way is to encode a first-pass at quant 2, then take the log file, disregard every 14th frame and get the filesize from the values of all the other frames.
Maybe somebody could make a program for that - wait, somebody already has - it's called Gknot! :D :D :D

[llemor]

Hmm... that sounds interesting.

So, then we really have to do the GKnot's way.:cool: :cool: :cool:

[snowbeach]

Ok, maybe it is a bit to difficult, but not too much! :cool::cool::cool:

"The problem of a too small divx is predictable: use Gknot, make a compress test and see what numbers you get. Then, you can choose a higher resolution before you encoded the whole movie."
theReal

To prove, if I've understood your statement in this case:

If I have a too small divx in the end with a avg. quant. of 2.0, it does not matter that I choose a higher resolution (e.g. increase bitrate from 1366 kbps to 1500 kbps), because the movie won't reach a better quality and the file will have the same size?

And if the avg. quant. is e.g. 2.654789... or 6.456782... a higher bitrate can improve the movie quality and the file will get bigger in this case?

[theReal]

it does not matter that I choose a higher resolution (e.g. increase bitrate from 1366 kbps to 1500 kbps)


When your movie was encoded at quant 2, if you choose a higher bitrate (NOT a higher resolution), then it does not matter, the filesize will stay the same. You could also encode at 100% quality based and it would still be the same. If you want it bigger, then you must increase the resolution.
If the resolution is already at the maximum, fill the CD with other stuff (better audio... whatever)

[snowbeach]

If you want it bigger, then you must increase the resolution.

I thought that increasing the resolution has no influence on the file size???!!

I think you mean bitrate? ;)

[Mac Sidewinder]

If you are encoding at quant 2 then you are automatically letting the codec use as much bitrate as needed to achieve this. That is why increasing the bitrate has no effect on the final filesize. What thereal is saying is since you are already encoding at quant 2, the only way to increase the video filesize is to increase the resolution. This way the codec has more "area" to cover thus more bits are needed to encode the higher resolution at quant 2.

But you will find out that when you encode this at the higher resolution at quant 2, that increasing the bitrate again will not increase the new filesize (if you follow me).

If you are encoding "normally" (other than quant 2), and you restrict the codec to try to hit a certain number of cds or a certain filesize, THEN increasing the resolution will not increase the filesize, GordianKnot will adjust the bitrate down accordingly. But you will get a worse encode since the codec has to encode the higher resolution with the same number of bits as it was encoding the lower resolution.

I think you are confusing the terms "bitrate" with "resolution".

Mac