getting exact filesizes with xvid...

[neo211]

i assume this is the right area for this topic since it concerns xvid encoded material. if its not then i apologize.

i'm currently working on some fansubs (unlicensed) and i've noticed that some of the bigger groups like ANBU and AKeep normally have exact filesizes for most of their series. my question is how is this possible? i normally try to get my episodes to 170MB or 175MB per episode. i never get exact filesizes though. ANBU for instance normally has their episodes at 170MB (174,080 KB). And these filsizes are the same for every episode. I would be really grateful for any help on how to get all my episodes to be the exact same size. TIA for any help u may provide =).

[Shinigami-Sama]

two-pass strong rate control and a bunch of serect setting
>_>
bleh anbu
bleh naruto -_-
and most grops are give or take a meg maybe two
thye make sure the eps are almost exatcly hte same frame count
that maybe your problem
and a slight change in rate control

[neo211]

k at least now i know more then when i started lol. this may be a stupid question but, what is rate control and how do i do it? TIA m8

[Shinigami-Sama]

umm
rate control is what controls hte placement of bits to keep curve under/oversized fiels
and if you realy want to know ask around
jsut don't tell them you;er subbing thye get edgy
and iirc you can set it in hte advanced options thing
the usaual seeting are 5 10/20 I think
I keep seeing those numbers over and over again when talking aubt mis-sized files

[neo211]

cool, thanx for the help

i'm a bit confused bout what u said. something bout "iirc" not sure what that is and also where does the 5 10/20 go. theres alot of places i could put those numbers lol. sorry if i'm being annoying. i just didnt understand.

[jon.schaffer]

• iirc = "if I remember correctly"

• You said the file size you get are not exactly the same each time: be more precise... what is the size difference (+/- 1MByte, +/- 10 mByte)?

• Do you make one pass or two pass encodings?

[neo211]

normally its +/-1MB, i always do two pass encodings

i've tried using target bitrate and target size

[Manao]

neo211 : usually, the margin error coming from the rate control is ( at least for me ) around +/- 300 kbytes. The increase in the imprecision you're getting might come from the container overhead ?

Shinigami-Sama : could you please take some time to post, read at least once what you write and correct the numerous typos ? Fora aren't irc channels, and non english native speakers may find it difficult to read you. Furthermore, hitting return anytime you feel necessary doesn't help the already crippled readability of your posts.

[jon.schaffer]

I would tend to say that +/- 1 MB are not that inaccurate... It's quite usual to see these differences in size.

As Shinigami-Sama said, it may be possible to get closer results by tweaking the Overflow Treatment settings (in the 2nd pass mode --> more). BUT I would not recommend you to do so. You may indeed get perfect final size but you're pretty sure to get quality losses and/or artifacts too (unless you test many settings)...

But, if you really want to do so, read the Crusty's FAQ, which explains these options... (link in the first 'sticky' post)

Maybe someone else has another opinion on that point (is 1 MB a big 'size error' face to the 'small' 170 MB-size)

[jon.schaffer]

I would tend to say that +/- 1 MB are not that inaccurate... It's quite usual to see these differences in size.

As Shinigami-Sama said, it may be possible to get closer results by tweaking the Overflow Treatment settings (in the 2nd pass mode --> more). BUT I would not recommend you to do so. You may indeed get perfect final size but you're pretty sure to get quality losses and/or artifacts too (unless you test many settings)...

But, if you really want to do so, read the Crusty's FAQ, which explains these options... (link in the first 'sticky' post)

Maybe someone else has another opinion on that point (is 1 MB a big 'size error' face to the 'small' 170 MB-size?)

EDIT: maybe you could try setting the minimum quantizer for each frame type to 2 (in the second pass settings / advanced option / quantization).
It may prevent 'quantizer-1 frames' creation, and may make the bitrate control easier for the codec.
Just a guess...


EDIT2: sorry for double-post - EDIT/POST button confusion :rolleyes:

[neo211]

thanx for the great help guys i'll be sure to give your suggestions a try tonight. I just took a quick glance at Crusty's FAQ and am very impressed by it so far. I tend to be skeptical bout xvid faqs cause the ones i've read usually contradict one another at some points so i never really know which one to go by. this one seems extremely professional though. again thanx for the help and feel free to continue adding if u think of something new =).

[Shinigami-Sama]

Originally posted by Manao
neo211 : usually, the margin error coming from the rate control is ( at least for me ) around +/- 300 kbytes. The increase in the imprecision you're getting might come from the container overhead ?

Shinigami-Sama : could you please take some time to post, read at least once what you write and correct the numerous typos ? Fora aren't irc channels, and non english native speakers may find it difficult to read you. Furthermore, hitting return anytime you feel necessary doesn't help the already crippled readability of your posts.
sorry abuot that my mind was swimming with various confused thoughts as yuo can tell by my title:rolleyes:
I tend not to notice my of my typoes seeing as how I have mild dislexia and when I glace over my posts it all looks right to me
as for hte return I peroid button has lost nearly all of its funcality so I tend ot use line breacks for periods now; which is reinforced by my constant irc lurkinghood

back on topic
I would;nt mess with ratecontrol either but it was jsut food for thought
though jon raised a good point it may be quant1 making hall the fuss I'd lean my bet on that now that I see it

[Kagura]

Originally posted by neo211 ANBU for instance normally has their episodes at 170MB (174,080 KB).

That can be easily done. However, it is really not worth the effort to appear "l33t." Here's how Keep does it: First, create an encode that is smaller than the target size you want. Then, open up the file in notepad or dos editor and add a bunch of random meaningless characters to the very end of the video. Save and close the editor. Check the filesize and repeat the process until you get a match.

[neo211]

u sure it cant have an adverse affect on the file? it just seems a little simple is all. i expected something complicated lol. thanx for 411 though.

[Soulhunter]

Example:

Set 900kbps -> Get 893kbps... >.<

Redo 2nd pass @ 910kbps -> Get 897kbps... >.<

Redo 2nd pass @ 915kbps -> Finally get 900kbps... \o/


Bye

[Kagura]

kbps isn't going to help precise filesizes. The poster wanted to know how to create encodes with the exact same size. Same bitrate will get it to +/- 300 kb probably. Not precise enough. ;)

[neo211]

thank you for clearing that up Kagura =). i thought i was quite descriptive in what i was looking for lol. thanx for your post though Soulhunter. Any help is always appreciated =).

[Soulhunter]

Originally posted by Kagura

kbps isn't going to help precise filesizes. The poster wanted to know how to create encodes with the exact same size. Same bitrate will get it to +/- 300 kb probably. Not precise enough. ;)

Actually the difference is more like +/- 30kb, not +/- 300kb !!!

And nobody would satirize you for a 30kb difference... :P


Bye

[Soulhunter]

Thought about my last post and realized its even less than +/- 30kb...

Coz, the samallest possible "tweak" would be to lower the quantizer of a single frame !!!


Example with a random file:

Frame 1765 @ Quantizer 3 = 42194bytes

Frame 1765 @ Quantizer 4 = 37487bytes

Frame 1765 @ Quantizer 5 = 34163bytes


Example with a different file:

Frame 4298 @ Quantizer 3 = 27996bytes

Frame 4298 @ Quantizer 4 = 22017bytes

Frame 4298 @ Quantizer 5 = 18249bytes

Bye

[Kagura]

Ah, Soulhunter, how wrong you are.

First, to absolve myself of any wrongdoing, I point you to the usage of the word "probably" in my original post. Anyways, that's beside the point. I was merely trying to show that neo211 wanted to know how those groups managed to get the exact same filesize to the byte for every single encode. S/he doesn't want to know how to get it around the ballpark figure of 175 or 170 mb. For the question, even 30 kb would be off since the objective of getting each episode to the same figure is to "show off" one's abilities. It's the same as making stuff with the same CRC code time and time again.

Now, to repudiate(did I use the word right?) your argument:

Your argument might have weight if the same bitrate only changed one frame. However, let's compare two possible sources used.

Source 1
Audio 22.2 mb
Video 34575 frames 202 mb

Source 2 (for the next episode)
Audio 30 mb
Video 35272 frames 156 mb

How will you compensate for the difference in frame count? Also, how will you ensure that the audio and video combined (which is what makes the final product) will equal the exact final size? It won't even be +/- 30 kb in this situation.

The solution is to use 2 pass file size to create something that is consistently less than the target size by a little bit.

EDIT: Somehow, you say that you will perform multiple encodes of the same thing. Well, no duh you can do that and obtain very close to the same (still won't be exact though). However, in the high-pressure world of just-in-time anime encoding, there is no time for second tries. ^^ If you want to be l33t, gotta get it right the first time.

[Soulhunter]

Originally posted by Kagura

Ah, Soulhunter, how wrong you are.

Should I really answer to this ???

Calm down...


Originally posted by Kagura

I was merely trying to show that neo211 wanted to know how those groups managed to get the exact same filesize to the byte for every single encode.

Yeah, but he also asked how to get exact filesizes for his own encodes...

So, I gave him a example how to create "as accurate as possible" results without "hacking" !!!


Originally posted by Kagura

Your argument might have weight if the same bitrate only changed one frame. However, let's compare two possible sources used.

Source 1
Audio 22.2 mb
Video 34575 frames 202 mb

Source 2 (for the next episode)
Audio 30 mb
Video 35272 frames 156 mb

How will you compensate for the difference in frame count? Also, how will you ensure that the audio and video combined (which is what makes the final product) will equal the exact final size?


I dont really understand ya question...

Whats so hard @ calculating the filesize of the video ???


Source 1
Audio 22.2 mb
Video 34575 frames 202 mb

Assuming its 23.976fps / VBR MP3 audio (1 frame interleaved) / AVI...

175MB = 179200kb

179200kb - 22733kb (audio) - 1632kb (overhead) = 154835kb (video)


Source 2
Audio 30 mb
Video 35272 frames 156 mb

Assuming its 23.976fps / VBR MP3 audio (1 frame interleaved) / AVI...

175MB = 179200kb

179200kb - 30720kb (audio) - 1665kb (overhead) = 146815kb (video)


Originally posted by Kagura

It won't even be +/- 30 kb in this situation.

Yeah, coz probably it would be even less than +/- 30kb... :P

If it comes out oversized/undersized simply raise/lower the target size or bitrate !!!


Originally posted by Kagura

Somehow, you say that you will perform multiple encodes of the same thing. Well, no duh you can do that and obtain very close to the same (still won't be exact though).

Well, +/- 5kb is exact enough for me !!!

At least the file is not hacked... :P


Originally posted by Kagura

However, in the high-pressure world of just-in-time anime encoding, there is no time for second tries. ^^ If you want to be l33t, gotta get it right the first time.

Well, in my case the filtering needs 10x longer than the encoding... ^^

So, re-doing the second pass 2 or 3 time is not such a big thing for me !!!


Bye

[Kagura]

Do you still not understand? He said "exact value" and the keep/anbu method of getting to exact filesizes. It has nothing to do with getting it in the ballpark.

Also, your "method" of adjusting for filesizes depending on the source doesn't have precise overhead values. They are not as exact as you have listed. Moreover, features such as bvhq, vhq, and trellis all change the file sizes of the frames per quant, meaning that two videos will receive different amounts of "savings" from these features depending on how they react to the source. Try encoding them yourself (once, not many times) and then report your results.

Sure, +/- 5 could be enough for you, but again (as I've said in every reply), it is not the answer to his question. Everyone knows how to get ballpark file sizes already.

Finally, your last comment makes no sense. Okay, so it's okay for yourself. That's fine. But how does that apply to the anime encoding scene that I mentioned? Sure, it's not a problem for you, but if you do that for any group, you'll be fired by the second day.

[dragongodz]

BWHAHAHAHA HAHAHA . ah thats better. :D

how does that apply to the anime encoding scene that I mentioned? Sure, it's not a problem for you, but if you do that for any group, you'll be fired by the second day.
any "group" that would "fire" an encoder for not padding their encode to exact bit size with sh*t are wankers anyway. if thats the sort of B.S. that parts of the fansub scene has reduced to then the lunatics really have taken over the asylum.

thank god i dont get most of the fansubs released nowdays then, become rather selective in my old age, and havent noticed such crap with what i do get. :D

i think neo211 has his answer now anyway.

[Didée]

Leaning out of the window, eyes wandering around, I behold children playing in a sandbox ... what a nice day. Oh, look! They start a quarrel about their moulds. Aren't they cute :) ?

[Soulhunter]

Originally posted by Kagura

Also, your "method" of adjusting for filesizes depending on the source doesn't have precise overhead values. They are not as exact as you have listed...

I dont see the problem here...

Please re-read my last post(s) !!!


Originally posted by Kagura

Moreover, features such as bvhq, vhq, and trellis all change the file sizes of the frames per quant, meaning that two videos will receive different amounts of "savings" from these features depending on how they react to the source.

Whats your point ???

This "savings" have no influence (for size prediction) in 2pass mode !!!


Originally posted by Kagura

Sure, +/- 5 could be enough for you, but again (as I've said in every reply), it is not the answer to his question. Everyone knows how to get ballpark file sizes already.

Really ???

Somehow strange...

Why are 90% of the fansubs out there 2-3 MB undersized then ???


Originally posted by Kagura

Finally, your last comment makes no sense. Okay, so it's okay for yourself. That's fine. But how does that apply to the anime encoding scene that I mentioned? Sure, it's not a problem for you, but if you do that for any group, you'll be fired by the second day.

This means your group demands you to release 2-3 eps per day ???

Damn, this speedsub groups are crueler than I thought... :eek:


Bye

[neo211]

wow didnt think such a simple question would get such a heated debate going. thanx for everything guys. i tried your method of using Notepad but it just freezes so i wont bother than that. thanx for the suggestion though. i didnt realize getting exact file sizes was such a pain so i dont think i mind getting it to within +/- 5kb as Soulhunter suggested. thanx for all the help guys and any future info or suggestions is still greatly appreciated so dont hold back =).