Matt Carlson
Forum Replies Created
-
Your experience is not unique. Vegas 11 development contained a few major shifts in the core program that have ended up being extremely buggy. Here are a few of the big, still lingering problems of Vegas 11.
1) Your color problems result from a serious bug in Vegas 11 when calculating transparencies, fades, stretches, etc. With certain codecs it happens much more frequently (for me anything h.264 based.) Starting your projects in an 8 bit color space instead of 32 bit will lessen the frequency of these mathematical color vomits.
2) The OFX plugin architecture for Vegas 11 is extremely sensitive to input (which is like saying humans are extremely sensitive to water… i.e. totally screwed.) Quick changes in sliders that require resulting changes in preview will crash often. The frequency of these crashes is much higher using more than one monitor. The OFX instability goes far beyond simple lack of input consistency unfortunately. The new OFX GUIs (especially the new titler) do not update correctly causing frequent crashes.
3) The graphics acceleration through CUDA has been inconsistent and only solid on certain cards and on machines dedicated only to Vegas. Preview RAM inconsistencies, rendering crashes and artifacts, and a distinct lack of a better preview on unqualified machines has made most users turn graphic acceleration off.
-
The original posters current computer rig has one glaring problem that should be addressed. The GT 440 is actually a hindrance. As the last few months have shown the CUDA implementation in Vegas is not entirely stable and it does not scale it’s workload efficiently. The GT 440 only has 96 CUDA cores. If you have GPU acceleration turned on much of the preview and rendering workload is being pushed through the GT 440. A mid level card (say the GTX 560) has between 350 and 450 CUDA cores. On a well built platform the CUDA would supplement computational workload. Here now in Vegas the GT 440 is overburdened and slows down the system and from what I have seen on this board causes instability.
I think (only a theory) that having a graphics card without CUDA in this case would be more stable and better overall than having one with limited CUDA resources.
-
This is a bug that has not been addressed yet and not anything specific to a lack of proper workflow or hardware. Most people do not do a lot of time stretching with Vegas video because it’s stretch algorithm is jerky in its output compared to other NLEs so the glitch does not present itself in usual use. Transitions will reduce to one color at a certain point when a stretched event is involved. Turning off GPU acceleration is only a moderate fix. The glitches will happen less but they will still happen. The really pernicious part of this bug is that it has no obvious consistency to it. I rendered a project part and noticed the output had the glitch. Without changing anything minutes later I rendered the same part and it was fine. Several iterations later it was back… then not. Changing to 8 bit color completely eliminated the problem (but of course the project’s color corrections were unusable and had to be redone.) I assume your project is in 32 bit full range color?
-
The output is created in three separate steps and FCP is better at two of them. First there is the source material. This is converted to a raw editing format inside the structure of our computers of choice. This conversion for Vegas and FCP are equal as they both have the same goal. Second is the filtering step. This takes the raw data and changes it (color correction etc.) The data is still raw but FCP has, at least superficially, tools that are more attuned to what we as humans want to see and how to get there. Vegas users have a much harder time reaching their visual ideal (while FCP users must deal with interface deficiencies.) The last step is converting that re-arranged data back in to a linear usable file. FCP has become that (irrational) standard that everyone points to with it’s ProRes codec rendering. Codecs are many and varied and some look better than others although most can attain the same quality by changing their parameters. They, however, work on the raw data given to them and as I said FCP has done a better job at making that data more of what we wish to see.
You are not crazy in thinking FCP has a better output. Vegas coloring has been known to have deficiencies in the past. At this point those deficiencies are almost all gone, though. Still there are times when it feels like the Vegas precision math seems to be taking shortcuts for whatever reason and the final product is slightly less. For the most part the final codec rendering is where things get messed up and that is in our control to change… sort of. The codecs used are, almost down to each instance, different than other NLEs out there and are widely considered inferior in Vegas. This is due to certain aspects of the codec structure being removed or changed due to legal crap. Now that we have entered in to the arena of GPU processing the math being used to calculate changes in the light we see has mutated. Sometimes the shortcuts designed to make things faster end up hitting a snag that turns in to what we see having artifacts, or being a bit blurry, or losing clarity of color. The one thing Apple has been good at is being stubborn to the point of pure obstinance so FCP has kept its visual quality a constant (to the detriment of interface innovations that other NLEs have now provided.)
-
In both Chrome and Internet Explorer I get the correct file. What browser are you using?
-
Sorry I misread your post. I will check the file.
-
Ever since Sony dropped the letter suffixes from their builds (10a.. 10b.. etc.) they have released 32 bit and 64 bit builds as separate numbers one number apart.
520 and 521 are the same build. 520 is for 32 bit and 521 is for 64 bit. I am guessing since they have been consistent for a while with this it will continue in the future.
-
More than likely your automatic crossfades option was set to off during the install/uninstall of VASST. CTRL+SHIFT+X will toggle it back on or find the icon (it looks like a pacman going up… usually between the enable snapping icon and the auto ripple icon.)
-
Vegas does not import AC3 in any form no matter what codecs you have installed (although you can render to AC3.) It is a pure license agreement thing. You have to convert AC3 audio outside of Vegas first with something like AC3 Pro.
-
Just because you are a born skeptic does not mean you are wrong. In this case they are releasing build 521 (I would guess) to point and say “look we are fixing things.” That they are fixing things that no one really cares about is problematic. Here is a list of crashes that still happen to me in 521…
1) Newblue Titler… even with the latest release from Newblue it still kills Vegas from time to time. The Titler Pro interface within Vegas is very slow in responding to interface button clicks. It does not like 32 bit color… speaking of which.
2) 32 bit color is still extremely unstable (a crash nearly every fifteen minutes or so)
I am finding being in 32 bit color crashes color plugins more often than 8 bit, especially Color Corrector and Secondary (the most used plugins I would guess.) My experience has this happening much more if scopes are active.
Any stretched event brought in to a fade/transition has a high probability of screwing up (in my case everything turns blue.)When I saw 521 had been released I was optimistic that after having all this time knowing about the major problems some of them would be addressed. Having worked on programming projects I am left with the feeling that the knowledgeable programmers have left the building and the updates are being pushed out by individuals too afraid to touch the kernel architecture or they are explicitly told not to.