The old Vegas credit scroll produces ugly results when rendered to interlaced output (e.g., NTSC DVD). The text flickers and you can see scan lines traveling through the text as it rolls up the screen.

I fully understand the issues involved, and also have read, today, most of the posts on this forum where this topic has been discussed. I spent more time figuring this out than I did editing a two-camera HD shoot of a complete Nutcracker (that took less than eight hours, including re-syncing the original CD audio, and ducking the applause in and out).

To cut to the chase, the Vegas title scroll generator doesn't have any way to force the text to always progress up the screen by an exact (integer) number of scan lines. What this means is that the baseline of a particular letter may be aligned exactly with the bottom of a scan line on one frame, but in the next frame, Vegas advances the text to whatever position is required by the length of the total title scroll. As a result, the base of that character will now probably be somewhere between two scan lines, and the TV set will have to figure out how to display that. The result is text which flickers and morphs as it goes up the screen.

During the course of this long day, I tried a LOT of things including, but not limited to, changing all the following settings (in various permutations):

Project Deinterlace, None, Interpolate, Blend
Credit Roll Event Reduce flicker on/off
Credit Roll Event smart/disable resample
Credit Roll Event field order TFF/progressive
Text bold/normal (and different sizes)
Text color 255/235
Background color 0/16
Frameserve to Nick Hope's HD to SD AVISynth script and render in external MC MPEG encoder
Change project AND credit roll to 720x480 widescreen and render to DVD MPEG from that
Make credit roll 10x longer; render resulting slo-mo credits to intermediate; import that and speed up 10x
Use a supersample envelope

All of these tests were done on a 1440x1080 credit roll, which was being rendered (using the Best setting) to a 720x480 widescreen MPEG-2 file.

I could go on, but it was a long day. Surprisingly, absolutely nothing listed above made even the slightest difference. I was rather surprised that the "reduce interlace flicker" has zero effect.

I also tried every single blur fX available in Vegas, at different settings.

I viewed the output on a real, old-fashioned CRT monitor with a DVD player that uses component (not composite) output, and also on a LCD big screen display, both from an xBox connected via HDMI as well as an old DVD player connected via composite (no S-video input on this TV).

I was about to give up, but decided to try to manually force Vegas to line up the text the way a real credit roll generator would do. It actually isn't that hard, once you've done it once. I don't have time for a complete tutorial, but here is the essence of how you do it.

This procedure makes the scrolling text look very good on an interlaced TV set, and look spectacular on a modern progressive set that deinterlaces NTSC DVDs.


First, you start with the vertical resolution of the output you are trying to create. Don't worry about the resolution of the credit roll itself, or of the project properties. These don't matter. However, to do this test, temporarily set the project properties to match the output resolution (this is important).

Then, go to the timeline and go frame-by-frame until the top of a letter just comes into view at the bottom of the screen. Then, go back one frame until it disappears.

Write down the frame number.

Go forward on the timeline until the top of that letter is at the top of the display. Go forward until you just see the top of the letter you used as reference begin to get clipped. Go back until it is not clipped.

Write down the frame number and subtract it from the first number.

Now, here comes the math. If the Vegas engineers had done their work, they could have added a single feature that would let you "slave" the crawl to the desired output resolution in such a way the the letters in the scroll would always line up exactly at the same vertical position relative to the raster (or pixel matrix). The following simple math would then be buried behind the UI, where it belongs.

But, the way to do this manually is to realize that if you want the letters to go up exactly one scan line for each frame (which would be a very slow scroll, especially for HD), then you need to force the result of the difference between the first and second frame number to be exactly the vertical resolution: 480 for NTSC SD; 576 for PAL SD; and 1080 for HD.

You do this by changing the length of the credit roll event.

If you want a faster scroll, then you want the text to jump two, or three, or four scan lines. You can divide the vertical resolution by any integer and use that number. For a two line jump in NTSC, you would divide by two, yielding a difference of 240 frames (288 for PAL, and 540 for HD). At 30 frames per second, it takes eight seconds for the text to go from the bottom to the top of the frame. This is a little fast, but still reasonable. If you divide 480 by three (so that the text jumps exactly three scan lines every frame), you only have 160 frames for the text to move across the screen, which happens in just over five seconds. This is too fast.

So, for NTSC, you are pretty much stuck with 240. There may be a way to adapt this to work so that the text aligns on alternating fields. This will probably result in twitter, but will avoid all the problems of the scan lines seeming to move through the text.

You then temporarily change the Vegas ruler to frames, and then open the credit roll event and read its duration in frames. You then multiply (or divide) the ratio of the number you got from the difference between the two numbers above by the duration, and then enter the new duration into the event.

The credit roll will now be the correct duration so that text lines up on the same scan line in each successive frame, and you will get flicker free text, without having to blur over all the artifacts created by the poor credit roll generator.