What is the best Bitrate Video Calculator for exact Target File Size ?

[TheRandomOne]

Does a good program exist ?

[SameSelf]

How about a handheld calculator? It's simple, and any online tool will performs the exact same calculation. There is power in knowing.

e.g. 1500 kb/sec x 3600 sec / 8 bits/byte / 1024 KB/MB = 659 MB

Or, if targeting a file size, e.g. 500 MB:

500 MB / 3600 sec * 8 bits/byte * 1024 KB/MB ~ 1,137 kb/s

[jagabo]

Better calculators also take into account the container overhead. That can be significant with VOB, TS, etc.

But the encoder won't hit the exact file size. And you won't see any difference in quality with a 5 or 10 percent difference in bitrate. So set your encoder to 1% percent smaller than you want and stop worrying about it.

[SameSelf]

Online calculators are too hamfisted to be of any real use. Just this weekend I finished authoring a DVD with an animated menu, chapters, and "extra content". Unfortunately, the limited space of DVD-5 was an issue. Choosing a single bit rate for everything on the disc is noobish which is all the online calculators do. Of course, expecting the encoder to hit the exact file size in only two passes is also a penny wise and a pound foolish. However, with all that said, I managed about 99% capacity on my DVD with my own handheld calcs . IOW, it fit!

[TheRandomOne]

Okay so what would you guys say is the best one to use ? Im not making any DVD or Physical Media just simple converting one file to another & making it a bit smaller thats it

[jagabo]

You're missing the point. It doesn't matter which one you use. The encoder won't give you an exact bitrate.

[SameSelf]

Okay so what would you guys say is the best one to use ? Im not making any DVD or Physical Media just simple converting one file to another & making it a bit smaller thats it

Do you have a problem with using a calculator or spreadsheet or similar tool to use the equation I outlined above? What more do you need?

[hello_hello]

Do you have a problem with using a calculator or spreadsheet or similar tool to use the equation I outlined above? What more do you need?

Container overhead? Audio bitrate?

TheRandomOne,
Some calculators will include the audio as well. Saves you having to work it out. You specify an audio size or show it the audio stream, tell it the output container type and desired final file size, and it'll work out the video bitrate for you.

Many GUIs do exactly that when you specify an output file size. How accurate they are depends on how accurately the encoder hits the target bitrate.
You can still work it all out yourself..... Total bitrate (file size) less Audio bitrate less some Container overhead = Video bitrate.

MeGUI has a bitrate calculator under it's Tools menu or it'll work it out for you when you use AutoEncode and specify a file size. It'll calculate the bitrate for M2TS, MKV or MP4 (or AVI for Xvid). I can't vouch for how accurate it tends to be as I use CRF encoding 99% of the time.

This is a standalone version of the bitrate calculator built into MeGUI:
https://www.videohelp.com/software/BitrateCalc
Or there's more to be found here:
https://www.videohelp.com/software?toolsearch=calculator&submit=Search&portable=&s=&ord...y=Name&hits=50

[hello_hello]

Could someone please explain this to me? Can putting video into a container reduce it's size, and therefor allow for a slightly higher bitrate?

Ignoring container overhead, sameself's equation makes sense to me:

500 MB / 3600 sec * 8 bits/byte * 1024 KB/MB ~ 1,137 kb/s

Yet I've asked three bitrate calculators to calculate the required bitrate for a 500MB file size and (MKV container specified where possible)
MeGUI's calculator says 1162 kbps,
This bitrate calculator says 1162 kbps, and
This bitrate calculator says 1165 kbps.

[SameSelf]

Could someone please explain this to me? Can putting video into a container reduce it's size, and therefor allow for a slightly higher bitrate?

Ignoring container overhead, sameself's equation makes sense to me:

500 MB / 3600 sec * 8 bits/byte * 1024 KB/MB ~ 1,137 kb/s

Yet I've asked three bitrate calculators to calculate the required bitrate for a 500MB file size and (MKV container specified where possible)
MeGUI's calculator says 1162 kbps,
This bitrate calculator says 1162 kbps, and
This bitrate calculator says 1165 kbps.

I don't know where 1,162 kbps comes from (probably some rounding, sloppiness, who knows), but 1,165 kbps is the result of treating 1,165 kbps as kilobits instead of kibibits. It is a longer calculation, but if you need to very precise about hitting your exact target size...

1,165 kilobits/sec x 1,000 bits/kilobit x 3600 sec / 8 bits/byte / 1024 KB/byte / 1024 MB/Byte = 500 MB = 500 MiB

[jagabo]

Yes, it's the difference 500MiB (500 * 1024 * 1024) and 500 MB (500 * 1000 *1000).

[SameSelf]

Yes, but where does 1,162 kbps come from?

Another reason not to trust online calculators.

[hello_hello]

Well there you go. Assuming it's correct......
http://www.chaneru.com/Roku/HLS/X264_Settings.htm#bitrate
The parameter given is the bitrate in kilobits/sec. (8bits = 1byte and so on). Note that 1 kilobit is 1000, not 1024 bits.

I'd imagine x265 is the same.

The bitrate calculator built into the old version of Xvid I have installed says I hour at 500,000 kilobytes = 1137 kbps, or 512,000 kilobytes = 1165 kbps, so it seems it's calculating kilo = 1000 for bitrate.

If you care to get specific, for 1 hour at 512,000 kilobytes (actually kibibytes, I assume):

No container = 1165 kbps
AVI (Legacy) = 1160 kbps
AVI (Open DML) = 1162 kbps
MKV = 1161 kbps
OGM = 1152 kbps

Edit:
So just to get this straight in my head, the equation treats 1000 bits per second (not 1024) as one kilobit per second, but the final file size is still calculated in binary. Is that correct? So.....

1165 kilobits per second * 1000 / 1024 = 1137 kibibits per second (old kilobits per second where kilo =1024).
And from there:
1137 / 8 * 3600 / 1024 = 500 MiB.

So specifying 1165 kilobits per second would be correct for the x264 encoder, excluding overhead.

Or to go the other way:

500 MiB / 3600 * 1024 * 8 = 1137 kibibits per second (old kilobits per second where kilo =1024)
1137 * 1024 / 1000 = 1165 kilobits per second.

I had a hard time getting my head around that one for some reason. Hopefully I've got it now.

[hello_hello]

1,165 kbps is the result of treating 1,165 kbps as kilobits instead of kibibits. It is a longer calculation, but if you need to very precise about hitting your exact target size...

1,165 kilobits/sec x 1,000 bits/kilobit x 3600 sec / 8 bits/byte / 1024 KB/byte / 1024 MB/Byte = 500 MB = 500 MiB

I don't know about "very precise" but unless my math is bad, specifying 1337 kbps for x264 would give you 488 MiB instead of 500 MiB (excluding overhead). That's getting a fair distance away from precise.

Yes, but where does 1,162 kbps come from?

Another reason not to trust online calculators.

It probably includes an estimate of container overhead. The list of calculators here includes some dedicated to creating AVCHD discs.

For x264 MeGUI calculates (1 Hour at 500 MiB):
MKV = 1162 kbps
MP4 = 1163 kbps
M2TS = 1099 kbps

For Xvid MeGUI calculates (1 Hour at 500 MiB):
MKV = 1162 kbps
MP4 = 1163 kbps
AVI = 1160 kbps

All that's without any audio. You can add more than one audio stream and extras such as subtitles. I'd assume the container overhead estimation would change accordingly.

[SameSelf]

I don't know about "very precise" but unless my math is bad, specifying 1337 kbps for x264 would give you 488 MiB instead of 500 MiB (excluding overhead). That's getting a fair distance away from precise.

My apologies if the engineer in me gets in the way. I guess a little explainer on what precision means couldn't hurt.

My bitrate and your bitrate agree to within 2 significant figures or to the nearest 100s. That is plenty for me because I NEVER specify more than to the nearest 100s bitrate anyway in my encoder. Call me a sucker for round numbers.

But like I said, if you want to encode to FOUR significant digits of precision, rock on.

[hello_hello]

My bitrate and your bitrate agree to within 2 significant figures or to the nearest 100s.

That is plenty for me because I NEVER specify more than to the nearest 100s bitrate anyway in my encoder. Call me a sucker for round numbers.

But like I said, if you want to encode to FOUR significant digits of precision, rock on.

And to think you referred to 1162 vs 1165 as "some rounding, sloppiness, who knows" before you knew it wasn't "another reason not to trust online calculators".

Do you have a problem with using a calculator or spreadsheet or similar tool to use the equation I outlined above? What more do you need?

Full disclosure about it's lack of accuracy wouldn't have hurt. Apparently there is power in knowing.

Two significant digits of justification aside though, your method is about 2.4% inaccurate, plus/minus container overhead not accounted for, and apparently plus/minus some OCD rounding to the nearest 100s you're just now mentioning.

BTW, I'd tend to disagree with the earlier accuracy claims regarding the encoder hitting the target bitrate. It's rarely 100% exact, but in my experience it's generally pretty accurate. Maybe it depends on the encoder. Some versions of Xvid were broken in that respect, but the internet wasn't littered with 350MB AVIs by accident. AutoGK gave me the requested file size countless times. If it missed, it was generally only by a megabyte or three.

As a quick test (I do very little 2 pass encoding these days) I encoded the first 1000 frames of a video I had handy (1024x576) with x264 while specifying a bitrate of 1000kbps. According to Bitrate Viewer I got exactly 1000 kbps. I'll confess though, if I wanted to burn an encode to disc, I'd allow a few MBs for a margin of error.

[SameSelf]

You sounded like you had legitimate questions, so my error was trying to answer them only find myself dragged into another fight. In case you didn't notice I said ~1,137 kbps in my first post. IOW, I fully recognize the limited precision. But I am done with trying to explain this as I am certain you will nitpick my responses again.

[hello_hello]

I didn't ask you a question. I pointed out your method isn't accurate and you tried to justify it.

If you were aware of the limited precision..... and I'll confess I wasn't until I used a bitrate calculator and discovered your calculations weren't precise.... why not mention it, given the OP asked about "the best Bitrate Video Calculator for exact target file size"?

My nitpick was the fact you described bitrate calculators as hamfisted and claimed they shouldn't be trusted. Which bitrate calculators have you used that aren't accurate?

Thanks to your lack of precision though, I learned something from this thread. I had no idea encoders use kilo = 1000 when specifying a bitrate. I now know you did, but you decided not to mention it.

[Adithya]

You should Try This https://sourceforge.net/projects/bitratecalc/

[manono]

Online calculators are too hamfisted to be of any real use.

Nonsense.

Choosing a single bit rate for everything on the disc is noobish which is all the online calculators do.

Then don't do it that way. Back when I made all DVDs to 4475-4478MB, I'd make the menus the way I wanted, I'd encode any extras to the lowest quality with which I felt comfortable (using CQ encoding with my chosen low-bitrate quantization matrix), then figured the remaining space I had available and used a bitrate calculator to find the bitrate for the main movie (taking into account audio, overhead and subs, if any). If for any reason it didn't come out the size I wanted, I'd run another pass in the encoder. I don't believe that extras should get the same quality as the main movie.

For what it's worth, for about 15 years or more I've used the bitrate calculator in Gordian Knot.

[SameSelf]

This thread should be closed.