An update is coming soon for Vegas but, as I told the Vegas forum earlier, installing the DVDA update (even the demo) fixes this problem everywhere. The MPEG encoder is shared by all SF apps.
clamping was a shortening of the dynamic range in the Y/U/V levels held in the data.
A programming oops, which slightly relates to the term "clamping" which suggests an intentional activity. On a graduated scale, this would create a halo or staircase where the source data was in fact smooth as silk.
Clamping is a natural characteristic of all digitisation, this clamping was noticable. 8 data bits per plane (Y,U,V) per pixel have to be treated carefully and this is what has been corrected. AFAIK.
The level clamping problem slipped in when we implemented the new MPEG sdk for DVDA 1.0b. Levels were squashed from 0-255 to 16-235. This has been fixed.
Improvements have been made for AC-3 previews*, yes. It might still sound a little odd when doing 5.1>stereo downconverts on the fly, but it does work better in the update.
*computer previews are not exactly what you'll see/hear on a DVD player/TV (you already knew that).
Thank you SoFo, this not only corrected the clamping, but also improved the internal MPEG-2 encoding speed slightly from F=5.1 to now F=4.7. Clamping seems to have taken some CPU performance ;-)
However, using the Satish frameserver and the MC standalone encoder still is much faster (F=2.6) ! Can we expect this to be solved with the V4.0c update?