Hi THG guys
Just read your article about DivX 4.01/XMpeg 41. I spent the last 5 days doing heavy experimentation with DivX encoding, with 3.2, 4.01 and 4.02 codecs (for my own use) and I was REALLY surprised when I compared my findings with your article.

DivX 3.2 offered a solution for those who wanted to stream. It would offer you to set a constant bitrate, and work with that. That meant that if you had highly-compressable data in the stream, you wouldn’t compress it as much as you could if you had a lower bitrate defined, and when it hit a scene (an action scene usually) with a LOT of data, it would compromise quality so as to fit into the pre-defined limited bitstream.

I couldn’t care less about a constant bitrate. As far as I’m concerned, when I watch the movie at home, It could freely vary between 3Megs/sec and 128KBit/sec. I mean, I don’t use ISDN or an analogue modem to transfer video between two computers inside my home. I use a LAN or read it from a CDROM. I suppose you know as well as me what the transfer rates of those two media types are, and understand they don’t pose a bottleneck.

I want the movie to be absolutely compressed, as much as possible, and to hell with the bitrate. Make it variable and spring around. But make it take up less space (which is what I REALLY care about, I keep the movies accessible on a large harddrive), and Hopefully eventually fit on a single CD without me having to split it.

Enter DivX 4.0x and gives me that ability. The Compress-as-much-as-the-codec-allows-without-regard-to-the-bitrate (1-Pass High Quality). THIS is what home-archiving people want, not the constant bitrate. Your article completely missed this point.

Furthermore, You have published your review about a week after the introduction of DivX 4.02
What this new codec did, was take my Matrix DivX (137 minutes), which took roughly 705MB using the 4.01 Codec (MP3 160KBit/44KHz Audio) and put it inside 469MB (Same audio settings, same encoder settings, same everything except for the codec itself. 85% quality on 1-Pass-Quality-Based on both versions). Movies that would never fit on a single CD now all of a sudden do. All I had to say was WOW.

I think the 4.02 codec is WAY ahead of the old 3.2, ESPECIALLY in terms of quality, but not as you erroneously compared it:

[the only mode 3.2 can do]
against
[the predefined-bitrate mode of the 4.0x codec]

but in

[The best 3.2 can do which is predefined-bitrate]
against
[The best 4.0x can do – which is the 1-Pass-High-Quality. And at ~85% (the 100% is not a solution for home-archiving, as the resulting file is ~1.5 to 2 Gigs in size, and completely impractical, unless you use a DVDR/RW/RAM or some other 2+ Gig archive solution)].

THAT is the comparison people are making. And they are taking the resulting AVI filesizes into account, that is the next important thing after quality, and you didn’t even mention in the article.

In short, I suggest you take a bit more time into looking NOT at what the codec writers are trying to shove into our plate, but at what people REALLY WANT and NEED, and compare existing technologies regarding how they actually satisfy (or do NOT satisfy) these NEEDS. What you did was like compare an automatic car with a stickshift car set in first gear, and conclude the automatic can go faster because you never bothered moving the manual into second.

By the way, you never published a solid MPEG-encoding comparison that would show Which CPU Solution (AMD or Intel) takes how much time to encode a movie, and compare it to how much it costs.
MAYBE NOW IS THE TIME.
(In fact, in all your recent CPU and Mobo chipset reviews, you systematically neglect this field, whereas it is a very critical field for many who buy those high-end power-monsters, who buy the machines especially for this purpose).

WAKE UP GUYS!!!!! We’re counting on you to do the fieldtesting work for us ;-)

I have E-mailed the author, but I think I'll also post it here (these forums are so well hidden, I found them because they were mentioned on Ace's

Hello Mr. Voelkel
I have read your article regarding MPEG4 video production, and I find it to be riddled with mistakes, some of them quite serious... Just to point out a few :
1. XMeg is NOT a new version of FlaskMPEG, but rather a derivative, FlaskMPEG is at V6Beta now
2. Neither program RELIES upon DivX, but rather ALLOW THE USE OF DivX. Many other codecs exist (Indeo comes to mind...)
3. Deinterlace does NOT deal that much with scene changes, but rather with fast motion to avoid combing effects.
4. Using the 1500K/Sec in DivX 3.XX "low motion" sets this as a MINIMUM BPS, while at "high motion" it sets it as a MAXIMUM BPS, both are a rather poor choice, and definately you can not predict CD-minutes recording the way you have, as more action-packed scenes require more BPS under BOTH methods. Also, using DivX 4.01 in CBR mode does it an injustice, as this MAKES it used 1500K/Sec, all the time, not allowing it to use the VBR 3.XX uses ANYHOW.
5. By Tom's OWN benchmarks, AMD's CPU's hardly "pale in comparison to Intel's"... Read you're editor's articles...
6. Treating DivX as a whole as a "hacked codec" is incorrect, as DivX 4.xx has been build from the ground up as a freeware... please re-check your sources...
7. In all quality-comparisons conducted so far, V4.xx came out superior by far to V3.xx... I'd recommend checking which source material has been used, converting low-quality MPEG1/2 could cause as much difference as doubling the bitrate in the codec...
8. "Super feature: Increasing brightness by 25 percent will produce a perfect video image" ? - Hardly... It will... add brightness maybe ? If the original is too dark, it WILL improve it, if its already perfect or too bright, it will ruin it...

Quite a few other mistakes of lesser significance were found... Please correct the numerous mistakes in this article & republish it, as it will surely puzzle many less-knowledgeable readers...

-= Programming made easy =-

Oren J. Maurice
Director of Technology, Entertec Ltd.
14 Shenkar street, Hertzlia 46725
ISRAEL

As near as I can tell the VBR ability of a codec depends on the control program not the codec. If the goal is to fit a movie on one CD then 469MB is fine but is a waste of space and of lower quality then if the final result took up the entire space on the CD (650 or 700MB). I don't know of any 469MB cds. Nandub SBC and <font color=red>F</font color=red>air <font color=red>U</font color=red>se are both variable bit rate encoders that can make use of divx3.11. Nandub can use 4.x and both allow you to pick a final file size so max quality is assured. Visit <A HREF="http://www.doom9.net" target="_new">http://www.doom9.net</A> and <A HREF="http://www.divx-digest.com" target="_new">http://www.divx-digest.com</A> for more info.

Remember if you ain't Muslim you ain't Shiite.

Another issue that was totally overlooked by the article was the speed difference between the two. Encoding at 1500kbps using Divx 3.2, generally I can encode at upwards of 60fps, but using Divx 4.02 using the same data rate, the fps drops to ~14. Depending on what you're encoding, this might be a big deal, it might not. But for me, 15fps is unacceptable. 15fps means that a 2 hour movie would take 4 hours, 60fps means it would take 1. That's a 4x speed handicap that Divx 4.02 has, but that's just my take on things.

Wahoo... 60fps with DivX 3.xx vs 14fps with divX 4.xx. What computer do you have to achieve 60fps ? that's a P4 3 GHz !! Or you do not compare the right things.
I could got 30fps with DivX 4.xx while decoding MPEG2 and 50fps without decoding.
There is no way you can have 60fps encoding while decoding MPEG2, or give the link to the app you use ! (Flask, DVD2AVI and AVIsynth and already been tested...)

I agree, that this article was quite inaccurate.
With what methodology did they compare the image quality? Also, with DivX 4.02, the most important parameters in the codec are the quantizers, which can make miracles with image quality...

I've said it before and I'll say it again, tomshardware should leave this kinda stuff to people who actually know what they are talking about