G
Guest
Guest
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 ;-)
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 ;-)