I started this thread seeking reassurance that my VideoStudio 8 copy was not faulty —it wouldn't let me choose my own VBR settings. Some replies, however, aroused my interest in finding out what one might be missing by having to make do with its VBR defaults and what could be done to overcome this limitation. The results of the tests I made to this end can by no means be taken as benchmarking figures for VideoStudio; however, they have helped me answer these questions and I hope they can be of use to others, too.
This is what I used for testing:
Hardware. Pentium 4 2.4 GHz processor, 1 GB RAM, 2 7200 rpm IDE HDs (80 and 120 GB), AVermedia analog capture card
Software. Windows XP with SP1, VideoStudio 7.01 (VS7), VideoStudio 8.01 (VS8), MainConcept Mpeg Encoder 1.04 Demo (MC), Bitrate Viewer (BV), VirtualDub_MPEG v. 1.5.10 (Vdub), MediaStudio Pro 7.0 Trial and MovieFactory Disc Creator 3 Trial —the last two only to check their VBR compression defaults.
Source. An AVI file 272 seconds long and 1.04 GB in size that was captured from an 8 mm camcorder tape using VS8 with MainConcept's MJPEG codec at quality level 19 and its associated default settings.
Output. More than forty mpeg files rendered from the source AVI by using a variety of constant and variable bitrate compression schemes in VS7, VS8 and MC.
Data. File size; peak, average and minimum bitrate (BV); maximum, average, minimum and total I, P and B frame size (Vdub).
This is what I found:
Continuous versus variable bitrate
First of all, I set to find out whether using VBR instead of CBR at the same bitrate level would actually be effective towards saving space in VideoStudio. To this end, I compared the sizes of the files obtained by rendering the source AVI with both CBR and VBR at 8264, 6000 and 4000 kbps —these numbers represent the Maximum value used by VS in the latter case.
The differences in size between the CBR and VBR rendered files were as follows: 10.3%, 9.4% and 8.9% for VS7 at 8264, 6000 and 4000 kbps, respectively; and 2.5%, 2.3% and 2.2% for VS8 at the same bitrates. Therefore, the space saved by using CBR instead of VBR would translate into time savings of 6.2 to 5.3 minutes per hour in VS7, but only 1.5 to 1.3 min/h in VS8 —to convert any percentage here into minutes, please multiply it by 0.6.
How important being able to fit 66 min of high-quality video rather than 60 on a DVD obviously depends on your specific requirements. In any case, using VBR as opposed to CBR will invariably save you at least 4 times more space in VS7 than in VS8. Why? Read on, please.
VS7 versus VS8
In the following test batch I compared the compression abilities of the current and previous version of VS by rendering the source AVI both at CBR values of 8264, 6000 and 4000 kbps, and at the same Max VBR values in combination with the default Aver and Min settings in VS7 and VS8 —no choice here.
Size-wise, VS7 and VS8 performed on a par at CBR: the largest difference between the files they produced at identical bitrates was only 0.05%.
VBR was a different matter, however. Thus, the VS7 files obtained at 8264, 6000 and 4000 kbps Max VBR were 8.1%, 7.3% and 6.9% smaller, respectively, than the corresponding VS8 files.
Therefore, VS7 appears to be more capable at VBR mpeg compression. This is most probably a result of its using a more aggressive —and also, possibly, more balanced— compression scheme (Max/90% Max/192 kbps in VS7 versus Max/99% Max/70% Max in VS8). In fact, version 8 uses much closer Max and Ave values (only 1% apart) and a much higher Min value (5784 vs 192 kbps at VBR = 8264 kbps).
Subsequent tests with MC revealed that the motion window of my source file fell in the medium-to-high bitrate region. Had I used a source file with slower scenes, the gap between VS7 and VS8 would probably have widened as the former could have taken advantage of the very low Min setting it uses (192 kbps).
Capturing versus rendering
This test compared the compression efficiency of Ulead's MPEG capturing and rendering engines (i.e. Ulead's MPEG.Direct and MPEG.Now encoders) by using VS8's 8264 kbps VBR template to capture the same video employed to obtain the source —albeit in mpeg format. The resulting file was 6.6% smaller than that rendered from the source AVI at the same maximum VBR (8264 kbps). However, re-rendering the captured file at VBR = 8264 kbps caused it to expand to a size only 0.05% smaller than that of the mpeg file initially rendered from the AVI.
Therefore, re-rendering a previously captured mpeg file in VS8 —which is eventually unavoidable towards making a DVD— offsets any gain resulting from the aggressive compression scheme used by Ulead's own (capture) encoder (8264/7437/3719 kbps) relative to its borrowed MC encoder (8264/8181/5784 kbps).
Confronted with the inability to alter the VBR settings, I set to test the following potential alternatives to efficiently reducing the size of mpeg files:
Using longer GOPs
The purpose here was to check whether using the standard PAL GOP sequence (15 frames) rather than the default VS sequence (12 frames) would improve matters. It didn't: size differences were only 0.2–0.3%. As revealed by the Vdub figures, this was a result of the gain in reducing the number of I frames —the least compressed ones— by 20% being offset by the increased number of P frames (6.7% more) and by both types of frame receiving more bytes in the files containing the longer GOPs.
Using audio compression
Ulead's AC3 (Dolby) audio plug-in is an efficient tool for saving space. In order to estimate any gains in using it instead of VBR video compression, I transcoded the VS7 and VS8 files obtained at VBR = 8264 kbps to AC3 audio from their original, LPCM format, using Ulead's default bitrate (256 kbps) in addition to 192 and 384 kbps.
The 192, 256 and 384 kbps transcoded files were shorter than their parent LPCM files by 13.7%, 13.1% and 11.8%, respectively, both in VS7 and in VS8. The equivalent time gains are 8.2, 7.9 and 7.1 minutes per hour. However, because, the space saved by the plug-in is constant in terms of bytes, the actual gain in time will depend on the particular bitrate used to compress the video —it increases with decreasing bitrate (e.g. from about 8 min at 8264 kbps to 14 min at 4000 kbps). In any case, these savings will add to any size gain one may obtain by compressing the video too.
I would like to finish this rather lengthy post by drawing several Conclusions:
1. Ulead seemingly uses four different VBR compression schemes:
· Max/90% Max/45% Max for captures (with Ulead's own, MPEG.Direct encoder)
· Max/90% Max/70% Max (Movie Factory)
· Max/90% Max/192 kbps (VideoStudio 7 and MediaStudio Pro)
· Max/99% Max/70% Max (VideoStudio 8 only)
Based on these numbers, you can expect VS8 to be least efficient of all Ulead video processing programs in terms compression —and it certainly is judging from the results.
2. You can only experience the real edge of VBR by using high enough Max values and low enough Min levels in combination with medium Ave values suited to the quality of your source and its length. Unfortunately, no Ulead program seems to let you choose a custom combination such as 8264/6000/4000, for example, with which MC produced a file 22.9% smaller than that obtained with CBR = 8264 kbps (a saving of nearly 14 minutes in 1 hour).
3. The lack of flexibility of VBR compression in Ulead's MPEG.Now encoder is probably the reason why some advanced users prefer to frameserve AVI files to an external encoder for rendering and then author the resulting mpeg files in their Ulead programs. Obviously, MainConcept would hardly ever sell a copy of their standalone encoder at $149 if anybody could get it bundled to a self-contained video editing program such as VideoStudio for less than $100. Some usage restriction in VideoStudio's implementation of the MC encoder must therefore have been introduced to avoid unfair competition with the parent product.
4. The fact that VS7 is a better performer than VS8 at compressing files makes VS8 more of a downgrade than an upgrade from its predecessor. This is probably a discouraging conclusion, but also, probably, one easy to reverse. What should we do?
· Buy the Dolby audio plugin and forget about VBR.
· Spend extra money on an external encoder —with or without a frameserver.
· Ask MainConcept to develop an enhanced mpeg plug-in for VS and price it reasonably.
· Wait for double-layer DVD blanks to get cheap and dependable enough to make this debate futile.
· Ask Ulead to correct VBR stiffness in VS8 if it is a bug or make its defaults more similar to those of VS7 otherwise —if only to honour the following statement in their VS8 product description brochure: “Ulead MPEG.Now codec maximizes picture quality and minimizes file sizes”.
Any suggestions and comments are welcome.
Thank you all for your patience.