VirtualDub, Xvid and target size

[lagartixa]

Hi.

I am trying to convert a video with VirtualDub and the Xvid codec. I would like the file size to be 700 MB so that it will fit in 1 CD. In the Xvid Configuration, in Bitrate Calculator, it has 4 suggested sizes, in kbytes: 665600, 716800, 1331200, 1433600. As I understand, they correspond to 650 MB, 700 MB, 1300 MB and 1400 MB. I choose the second one and fill in all the other details like video length and audio bitrate.

Unfortunately, when the conversion if finished, I am getting a file that is 704 MB which is too big to fit in a single CD. How can I achieve a more precise file size? I know that it's possible because I have experimented a bit with FairUse Wizard and it very accurately produces a file of 700 MB or less, usually 699 MB.

Does anybody know? Thanks in advance.

[El Heggunte]

Do the math yourself, and choose a slightly-lower target bitrate, problem solved.

Besides: the year is 2014, DVD-Rs are as cheap as CD-Rs, so why on Earth one would need to create "1-CD encodes" is beyond me

[lagartixa]

That was not helpful. And I think it was a bit patronising.

Do the math yourself, and choose a slightly-lower target bitrate, problem solved.

If I knew how to do the right calculations myself, I would not have asked.

Besides: the year is 2014, DVD-Rs are as cheap as CD-Rs, so why on Earth one would need to create "1-CD encodes" is beyond me

That's a non sequitur. There are various valid reasons for why some people would choose CD, all of which are irrelevant as the question would still remain, namely: How to estimate the correct bitrate of a video for obtaining a specific file size? If one were to choose to record a DVD one would still have to calculate the file size, only that it would now be 4.38 GB.

[jagabo]

(video bitrate - audio bitrate) * 700 / 704 =

[hello_hello]

Is it always oversized? It might come down to the version of Xvid you're using and/or whether you're using an Xvid profile. Some profiles (ie home theatre) limit the bitrate for compatibility which I think can mess with the ability to hit an exact bitrate a little. I recall there was a version of Xvid years ago that produced oversized/undersized files if profiles were used, but more than just 4MB, they'd often be way over/under sized. Even so, any bitrate limiting might effect the over-all bitrate calculations a little.

You could try opening the oversized AVI with VirtualDub and changing the audio interleaving (Audio/Interleaving menu). It defaults to "1". I don't think changing it makes a difference if the audio is variable bitrate but if it's constant bitrate increasing it will reduce the file size a little. Increasing it to "2" should save you a couple of MBs.... or increase it a little more. It shouldn't effect playback and might let you reduce the AVI's size enough without having to re-encode the whole thing again. It just reduces the over-head a bit (use direct stream copy for the video compression when resaving the AVI). AutoGK uses "2 frames" for interleaving and I never had a problem playing the AVIs it created.

Personally I'd just aim for 695MB and then if the output is oversized a little it shouldn't matter.

[lagartixa]

(video bitrate - audio bitrate) * 700 / 704 =

I am trying to learn how to do the calculation generally, not just specifically for this one time.

Is it always oversized? It might come down to the version of Xvid you're using and/or whether you're using an Xvid profile.

Yes, it tends to be oversized, though I've only started doing this recently and haven't tried many different times. I have the latest version and I am using the default settings, which would be Xvid Home, I haven't changed any of the settings.

You could try opening the oversized AVI with VirtualDub and changing the audio interleaving (Audio/Interleaving menu).

Thanks for the tip, but I'm looking for a general way to achieve the desired file size, not just for this one time.

Personally I'd just aim for 695MB and then if the output is oversized a little it shouldn't matter.

Yes, that sounds reasonable.

I was thinking that maybe this oversizing is due to the AVI overheads, which I am not 100% sure how VirtualDub creates. In Xvid you can choose container format AVI-Legacy or AVI-OpenDML. I first tried telling Xvid it was AVI-OpenDML and got the 704 MB size, then I tried telling Xvid it was AVI-Legacy and the file was still slightly oversized, at 702 MB.

I'd like to learn how to do it perfectly, but yeah, if I can't I might just do what you suggested and go for 695 MB.

[DB83]

So did you actually try to burn that '704 mb' file to a CD ?

[El Heggunte]

So did you actually try to burn that '704 mb' file to a CD ?

Well-spotted, because since ages ago, a standard CD-R / CD-RW supports up to 703.xx megabytes without overburning,
and up to ~720 megabytes with overburning.

[lagartixa]

So did you actually try to burn that '704 mb' file to a CD ?

Kind of. I went to ImgBurn, opened the file and clicked on the calculator and it said there was not enough space. I did not try to overburn.

[DarrellS]

Yeah, seems like most of the CDs that I used to burn back in the day were 704MB.

According to the wiki page, for 80 minute CDs, the capacity is 737 MB (703 MiB).

A CD-ROM can easily store the entirety of a paper encyclopedia's words and images, plus audio & video clips
CD-ROM capacities are normally expressed with binary prefixes, subtracting the space used for error correction data. A standard 120 mm, 700 MB CD-ROM can actually hold about 737 MB (703 MiB) of data with error correction (or 847 MB total). In comparison, a single-layer DVD-ROM can hold 4.7 GB of error-protected data, more than 6 CD-ROMs.

Capacities of Compact Disc types (90 and 99 minute discs are not standard)

Capacity[edit]
Type	Sectors	           Data max. size	Audio max. size	    Time
		         (MB)	Approx.(MiB)	   (MB) 	   (min)
  8 cm	094,500 	193.536	     184.570	  222.264	    21
	283,500 	580.608	     553.711	  666.792	    63
650 MB	333,000 	681.984	     650.391	  783.216	    74
700 MB	360,000 	737.280	     703.125	  846.720	    80
800 MB	405,000 	829.440	     791.016	  952.560	    90
900 MB	445,500 	912.384	     870.117	1,047.816	    99

Note: megabyte (MB) and minute (min) values are exact; MiB values are approximate.

[Detmek]

Lagartixa, did you use one-pass or two-pass encoding?
Also, it is posible that audio is a bit oversized, bitrate calculator is wrong or bug in Xvid rate-control algorithm.

[lagartixa]

Yeah, seems like most of the CDs that I used to burn back in the day were 704MB.

I usually see it mentioned as 700 MB, 702 MB, or 703 MB, not 704 MB, I guess you are rounding up the number.

According to the wiki page, for 80 minute CDs, the capacity is 737 MB (703 MiB).

Yeah, I saw that, to be precise it says 737,280,000 bytes, but actually the CDs I got are 736,966,656 bytes.

[lagartixa]

Lagartixa, did you use one-pass or two-pass encoding?

I used Twopass.

Also, it is posible that audio is a bit oversized, bitrate calculator is wrong or bug in Xvid rate-control algorithm.

I'm not sure. I also processed the audio with VirtualDub, converted it to MP3. I did not use zones / rate control, so I think it's probably not that. So yeah, maybe the bitrate calculator is wrong for some reason, I'd really like to learn what's up.

[El Heggunte]

Xvid's bitrate control is not that great, depending on the version AND on the complexity of the source video itself.

You could also remux with AVI Mux GUI, and check whether the container overhead gets reduced.

I am trying to learn how to do the calculation generally, not just specifically for this one time.

The time you have spent in this thread, waiting for a spoonfed answer,
you could have used it for Googling elsewhere --- OR for re-learning how to solve elementary arithmetic problems
This is not tensor calculus, definitely.

[DB83]

Yeah, seems like most of the CDs that I used to burn back in the day were 704MB.

I usually see it mentioned as 700 MB, 702 MB, or 703 MB, not 704 MB, I guess you are rounding up the number.

According to the wiki page, for 80 minute CDs, the capacity is 737 MB (703 MiB).

Yeah, I saw that, to be precise it says 737,280,000 bytes, but actually the CDs I got are 736,966,656 bytes.

You appear to be pedantic now to the point of annoyance and fail to spot simple arithmetic.

By your own comment above, that '704' file should burn despite what the calculator on imgburn tells you and what other have told you in this thread.

For the sake of a few 'pence' why don't you just actually try to burn it ?

[lagartixa]

I was not being pedantic, I was simply making conversation, like he was. As has been explained, the amount of data that fits a CD is irrelevant, the question is about how to estimate the correct bitrate / file size while using VirtualDub and Xvid.

[DB83]

Actually it IS relevant because you appear to have created a file that CAN burn to a '700 mb' CD, which is your purpose in this, but you fail to appreciate that or are too stubborn to try it.

If vdub does not do to your 'satisfaction' then why not try another tool such as autogk - also mentioned above - which also has the 700 mb basic setting but probably does thing differently to vdub and I guess what many people who create these 'split to fit on a CD' files use.

[lagartixa]

The time you have spent in this thread, waiting for a spoonfed answer,
you could have used it for Googling elsewhere --- OR for re-learning how to solve elementary arithmetic problems
This is not tensor calculus, definitely.

I have tried Google, there are various bitrate calculators around but I don't know how they are different or better than Xvid's. In any case, you just don't know the answer, if it was that simple you would have already told me. You continue to be patronising and unhelpful.

[lagartixa]

Actually it IS relevant because you appear to have created a file that CAN burn to a '700 mb' CD, which is your purpose in this, but you fail to appreciate that or are too stubborn to try it.

OK. Let me tell you a story.

Before I came here to post, I converted the video to a DVD ISO file using DVD Flick, then converted it to an Xvid AVI file using FairUse Wizard, which took many hours, just to see if it could be done. I got a file that was 699 MB. If all I wanted was to fit the video into a CD I would have done that already.

To spell it out, in case my English is not good enough for you: I don't want to know how to burn a 704 MB file into a CD, I want to know how to calculate the bitrate or video size to obtain a file that is precisely 700 MB or less, using VirtualDub and the Xvid codec.

[jagabo]

I want to know how to calculate the bitrate or video size to obtain a file that is precisely 700 MB or less, using VirtualDub and the Xvid codec.

Type in the size you want rather than using the pulldown.

[ndjamena]

-Void-

[ndjamena]

[Attachment 28339 - Click to enlarge]

So, where's the confusion?

[DB83]

Which is NOT how people have interpreted your OP where you wrote

"Unfortunately, when the conversion if finished, I am getting a file that is 704 MB which is too big to fit in a single CD."

So if this is not asking how to.... I am in the wrong topic.

But I outa here now since you do not wish to accept advice.

[hello_hello]

Personally I think the problem's likely to be un-solvable. Xvid's bitrate control isn't that terrific and a MB or four over/undersized is probably not too out of the ordinary. I recall when using AutoGK regularly it was pretty good at outputting the requested file size/bitrate but now and then the output would be off by a MB or so. Every so often it'd be off by a bit more, but the only cause I can think of is Xvid. It's not like AutoGK would be getting the calculations correct 90% of the time but not for the other 10%.

You didn't say whether you're using an Xvid profile (one with bitrate restrictions) but if you are it might pay to try again using the default Xvid settings. If the second time it hits the target size exactly but not the first, then it's no doubt Xvid's fault.

Are you using the same version of Xvid FairUse Wizard does? Are you definitely encoding with Xvid when using FairUse Wizard? Have you converted the same video with both VirtualDub and FairUse Wizard to confirm you're getting slightly different file sizes even when specifying the same bitrate for the same video etc? I don't know how many videos you've converted with FairUse Wizard but maybe even though it's achieved the exact output size to date, it doesn't necessarily mean it always will.

[manono]

I recall when using AutoGK regularly it was pretty good at outputting the requested file size/bitrate

When I was doing this I don't think I remember being more than a MB off from the 700 or 701 MB I requested (since CDs burn up to 703 MB with no problem). I always used the GKnot bitrate calc. I have no idea how good the one included with XviD is but my suspicion is the OP is doing something wrong, even though this isn't exactly rocket science.

[lagartixa]

Personally I think the problem's likely to be un-solvable.

OK. Probably.

You didn't say whether you're using an Xvid profile (one with bitrate restrictions) but if you are it might pay to try again using the default Xvid settings. If the second time it hits the target size exactly but not the first, then it's no doubt Xvid's fault.

Actually, I said "I have the latest version and I am using the default settings, which would be Xvid Home, I haven't changed any of the settings."

Are you using the same version of Xvid FairUse Wizard does?

No, I am using version 1.3.3, FairUse Wizard uses version 1.2.1.

Are you definitely encoding with Xvid when using FairUse Wizard?

Yes.

Have you converted the same video with both VirtualDub and FairUse Wizard to confirm you're getting slightly different file sizes even when specifying the same bitrate for the same video etc?

FairUse Wizard does not do video files, only DVDs or DVD ISOs, so like I said I converted the video first with DVD Flick, so the original file was converted in the middle to a DVD before it got to FairUse Wizard. FairUse Wizard is pretty automated so I don't even know how it calculates the bitrate.

I don't know how many videos you've converted with FairUse Wizard but maybe even though it's achieved the exact output size to date, it doesn't necessarily mean it always will.

Right. I have only converted about 5 movies with FairUse Wizard, but they were accurate.

Anyway, I think that the problem is not in any of these. Whose fault is it? Is it VirtualDub's fault? Is it Xvid's fault? Is it my fault? I believe it is not my fault because I have been very careful to check everything was chosen correctly. I also don't think it is VirtualDub alone, or Xvid alone either. I think probably it's a combination, I think the culprit is the AVI overhead, Xvid estimates the container overhead will be something but VirtualDub creates a container with different overhead, slightly higher as usually I get oversized files. As FairUse Wizard does everything itself, it knows how much the precise overhead it creates will be, hence it can predict a more accurate bitrate. That's my theory.

[ndjamena]

Good theory.

Personally I'd just aim for 695MB and then if the output is oversized a little it shouldn't matter.

[lagartixa]

"AVI files and common problems"
http://www.virtualdub.org/blog/pivot/entry.php?id=25

By the way... what are OpenDML AVI files?

Earlier, I said that chunks are tagged with a four-byte length. This limits the size of any chunk to ~4GB (4,294,967,295 bytes), and in fact, the practical limit is a lot lower due to compatibility concerns, around 1-2GB. The index also has the same limitation and this limits the size of standard AVI files to 2GB. A group called the OpenDML AVI M-JPEG File Format Subcommittee devised a semi-backwards-compatible way to extend this limit, by appending additional structure to a standard AVI file. The result is that legacy applications still can't read beyond 2GB, but the rest of the data is appended after the standard AVI and pointed to by a new type of two-level index. VirtualDub calls this the AVI2 format; by default it writes standard AVI files until it hits 2GB, at which point it switches to the new format.

"AVI-OpenDML and AVI-Legacy?"
http://forum.doom9.org/showthread.php?t=80157

VDubMod can only write Hybrid files and Legacy AVI, but no pure Open-DML.

"AVI-Mux GUI estimate overhead"
http://www.alexander-noe.com/video/amg/en_estimate_overhead.html

Some rules on overhead calculation:

Let's first define one unit of overhead:

standard AVI file: 24 bytes
Open-DML without legacy index: 16 bytes
Open-DML with legacy index: 32 bytes within the first RIFF list, then 16 bytes. The size of the first RIFF list was 1 GB till AVI-Mux GUI 1.16.2, and is adjustable beginning with version 1.16.3

So...

According to the first two references, VirtualDub "by default it writes standard AVI files until it hits 2GB, at which point it switches to the new format" and VirtualDubMod "can only write Hybrid files and Legacy AVI, but no pure Open-DML". And as you can see from the third reference "Open-DML with legacy index" takes 32 bytes while "Open-DML without legacy index" takes only 16 bytes, but Xvid does not have two options for Open-DML only "AVI-OpenDML".

[ndjamena]

Take a look at the Options|Preferences|AVI options in the VirtualDub Menu. I don't really know what it's saying, but I doubt Open-DML is causing a 4MB difference in a file size that small (or at all).

We don't know what FairUse wizard is doing to get so close to 700mb, it's possible it sets the target bitrate low and then adds padding to get the correct size.

Handbrake removed the Target File Size setting from it's GUI because they could never get the bloody thing to work accurately enough, so I know it's not an easy feat to achieve.

However, I do know that MKVMerge is a much more efficient MKV Muxer than some others, even though it adds a rather large void to the beginning of the file for the convenience of Header editors. Unless you want to start looking at these files with Hex editors, I don't think you're going to find an answer to this one.

[lagartixa]

I think the solution will be this:

On Xvid codec calculator to choose "AVI-Legacy" and in VirtualDub to save the file with "Save old format AVI..." which will force it to use the 16 bytes container overhead and this should produce a more accurate bitrate / file size.

That's what I'll try.