Thank you to johnmeyer for starting this thread and thank you to the ForumAdmin for chiming in at this point. This explains a lot about the design theory of VegasPro being an NLE with high degree of compositing functionality. Thanks to everyone for reviewing this topic.

Indeed, thank you Forum Admin.
Clears everything up, and finally explains the "Adjust source media to better match project or render settings" option.

John, Vegas is doing compositing because the source video frame aspect ratio doesn't match the render template frame aspect ratio. Standard definition video frame aspect (720 * 1.2121 / 480 = 1.8181) is ever so slightly wider than HD (1920 / 1080 = 1.7777) or HDV (1440 * 1.3333 / 1080 = 1.7777) frame aspect.I am very much aware of the slight aspect ratio differences between SD and HD widescreen. I already took that into account before I posted.

What still puzzles me is this: both the top and bottom track have video that, by your own numbers, have the identical aspect ratio of 1.7777. Thus, whether the video is being rendered to HD or SD, and regardless of the aspect ratio of the final render, the track on the bottom should never "show through" and be seen, because it is the identical aspect ratio to the video on top: they both should be treated identically. Indeed, I tested this (see my first posts) by adding an fX to the lower track video that made it almost white. If even one pixel from that lower track got composited, either in the preview or the final render, it would have stuck out like a sore thumb.

I saw no sore thumb in either the preview or render.

Thus, while I fully understand your explanation, I don't think it actually explains the problem. In addition, I suspect that the "Adjust source media to better match project or render settings" is more of a band-aid for the problem than an actual fix.

However, thanks to several of these posts earlier in this thread, I have viable workarounds to the issue. I just hope that enough people read this thread and apply those workarounds so that they don't waste countless hours waiting for renders to finish, or start yet another post asking why preview speed is so slow. There are obviously dozens of other causes for both those problems, but few that can increase render times by large integer multiples, as both my tests and the test of others have shown.

So, thank you very much for the reply (I'm always thrilled when SCS posts here in the forum), but I am still not convinced that there isn't a problem that needs to be fixed. I respectfully suggest that you think some more about your explanation, do the test I outlined (of making the lower track video super-bright, and then looking at the render) and then see if perhaps you might not want to improve future versions of the product to avoid this problem.

The logic to decide if a track obscures the tracks beneath it does not look at what is in the other tracks. So while you can logically observe that both track 1 and track 2 contain media with the same frame aspect ratio and so therefore can't both be visible, the heuristic in Vegas is just seeing that track 1 is not entirely opaque and so therefore compositing must be done.

Final word on this problem: Sony "Support" absolutely STINKS!!!

I finally received a "reply" today, over three weeks after submitting the bug report, complete with the test case that I posted here. I clicked on the link in the email I received, and was linked to a page on the Sony support web site that said: "Permission Denied. You do not have permission to access this document."

I spent ten minutes trying to access my past support issues, and all of it is gone, and I no longer have access to anything I have submitted. Whatever Sony did, or did not do with my bug, I'll never know because they won't let me see my own support tickets.

I am pretty fed up with SCS at this point. I would guess that they are probably not doing very well, and this is the result.

So, I am sorry to report that I cannot provide the "capper" to this story, and let you know what Sony did with this bug.

John Meyer

[edit]Their support still stinks (3+ weeks to answer the question), but I found out why I was locked out: they responded using my new email, but the tech support was filed under my old email. Their response is that the underlying video is SD and therefore a different aspect ratio. I am pretty certain that I tested this and proved that this wasn't the reason for the problem (although people above certainly did suspect that it might be).

I assume didn't read the ForumAdmin's reply?

I feel that this is case "can be" seen as a bug but it may not be one.

I assume didn't read the ForumAdmin's reply?You assume wrong.

Although it's a bit cryptic, from Admin's reply I gather that Vegas is not calculating PAR in the lower tracks when making it's decision whether compositing is required. If that's the case, I too believe it needs to be corrected. Lots of hours could be saved.

Edit: in Admin's first response, that since SD is a slightly wider frame aspect ratio Vegas sees that compositing must take place - it seems that the logic for compositing decisions should go a bit deeper. At the very least, only compositing the uppermost track with black edges should take place rather than every track being calculated if the PARs on every track fill the project designated frame size.

Although it's a bit cryptic, from Admin's reply I gather that Vegas is not calculating PAR in the lower tracks when making it's decision whether compositing is required. If that's the case, I too believe it needs to be corrected. Lots of hours could be saved.Yes, that is it, exactly. You always seem to hit the nail on the head.

I've done a lot of additional testing, and the PAR calculation is definitely the culprit.

The advice I received from SCS and from several forum members about the Project Properties dialog "Adjust Source Media ..." setting does not have any effect at all on the rendering time. In general, I have found that checking that box results in bad outcomes so, except for testing this problem, I never check it.

I have done quite a bit of script writing for Vegas over the past twelve years, and when you create scripts you quickly come face-to-face with the way in which Vegas keeps track of both pixels and time. Bottom line: because Vegas lets us combine different frame rates, pixels sizes, and PAR, roundoff errors get to be a really big problem. For instance, exactly where should the boundary be placed between frames that have a frame rate calculated from this equation:

30 * (1000/1001) ?

That, of course, is how the "29.97" NTSC frame rate is calculated, but if you plug that into your old HP-67 calculator, you get 29.97002997...

In this case, the issue is PAR. The PAR for HDV is also a transcendental number calculated from the fraction 4/3 which of course equals 1.3333333 ...

The round-off error from this calculation is probably (I can't, of course, say for certain) involved in the erroneous decision within Vegas to composite the lower track.

If the actual math inside of Vegas calculated the real pixels from the HDV clip by using fractions instead of decimals (i.e., 1440 * 4 / 3), the first calculation would be to multiply 1440 by 4 which gives 5,760. This number is exactly divisible by three, so when you divide by three you get precisely 1920.000 pixels. By contrast, if you store the PAR as a decimal (1.33333), not matter what number of decimal places you store, when you multiply 1440 by that number, you can never get an exact result with an infinite number of zeros to the right of the decimal point.

Good programmers figure out how to deal with this stuff.

It is quite clear that Vegas includes lots of logic for dealing with many of these situations. Most of this great programming was done by the genius programmers who invented Vegas and took it through its first half dozen iterations.

Unfortunately, either because the tech support team doesn't understand the problem, or because of priorities, or because they don't care, this particular issue is not going to be addressed.

Sigh ...

I learned to surrender to Sony Vegas and accept it for what it is... along with the skeleton crew that runs it. At least it is affordable and we all seem quite fluent in it. Surrender to the render.

However, it does stink.

I learned to surrender to Sony Vegas and accept it for what it is...Me too. It is still a fantastic product. Just too bad that they don't have the money and/or talent and/or marketing expertise to understand what is important to their customers, and therefore which bugs might make a huge difference to a workflow, and which are only minor annoyances.

Fortunately, thanks to this thread, I have a viable workaround for myself, but I am left wondering (as I did in my OP) how many people think Vegas is slow to render when -- absent a bug fix -- all they have to do is delete unused media from lower tracks.

BTW, one great outcome of reading all the responses is that I now much better understand how to use the multi-cam capability, and can easily avoid this problem in future multi-cam projects, thanks to what people posted above.

Thanks!

JM: " . . all they have to do is delete unused media from lower tracks."Would "Muting" the unused/not needed Tracks give the same quicker render times result?

Grazie

Maybe the reason I never experienced this is becasue I never have any unused media in my project, not on a track and not in the media pool. Before I render a project, I use Vegasaur's project audit to check for any unwanted issues liek unused media, gaps, quantized frames and many more.

I am still on the fence whether to call it a bug or not. Unused media ona lower track is just wrong and the minimum one should do is mute the track.

As for better programming. Make a quick multicam project with a couple of simple cuts and expand the multicam track back to seperate tracks. What you get is events with muted portions where the other track is supossed to play; this is just the way Vegas does it. Now, if you have an unused and not muted track below another, what is Vegas supposed to do? Look through the whole project and check if there is anywhere a moment where the top track is muted/100% opaque and you actually want the lower track to play? How would you program that? How about if you have more then just one track below with similar condition? Basically what I mean is that there is only so much intelegence you can put in a software and you will still never have covered every possible scenario. So the safe way in this case is to composite any track that is below unless it is muted. But that is just my opinion.

Although it may not handle every situation, I think an easy addition (as I mentioned earlier) is a compositing mode: "none," that could be applied to tracks in a project where lower track compositing is not needed, and would disregard all tracks except background (black/0).

@atom12
I think "muting" the track does exactly do that; I need to test it however.

@OldSmoke, in my tests it does, but the workflow for some of us (good or bad) is to cover an edited base track with b-roll scenes. In this case we would want the lower track clips to be present in the render whenever there are NO higher track clips covering them.

In case I wasn't clear in my earlier post, I'd like to have editing available between clips on different tracks, just no inter-track compositing. The logic for a "none" compositing would be: video present on this track ? disregard lower tracks. No video present on this track? Composite based on settings of uppermost track containing video.

@atom12

Do you mean compositing mode on event level rather then track level?

@Old Smoke
In my workflow, on track level. Vegas' logic is obviously already checking compositing modes for all tracks on a frame by frame basis. The ability to disregard what's below would speed things up in many of my projects.

Eg: Track 1 is an edited interview. Track 2 is b-roll of accompanying material (perhaps from a different camera, scan etc. with differnt PAR - the type of non-sync material that wouldn't lend itself to a multicam edit).

I don't think Vegas composites portions where there is simple no event below a top event. But if there is an event, even tough it is fully covered by the top, it will get processed and that is, if I got it right, what the whole thread is about.

It doesn't always composite it there's nothing below, but it does always "check." If a clip or still that does not fill the frame is present it has to be "composited" with the black/0 alpha background even if there is nothing below it.

It doesn't always composite if there's nothing below, but it does always "check." If a clip or still that does not fill the frame is present it has to be "composited" with the black/0 alpha background even if there is nothing below it.
I think if the software would constantly check if on the track below is a clip/event it will become very difficult because you could have many tracks all with just one clip/event. I would rather think that Vegas looks at the amount of tracks used, not muted, and processes them. That would be the "safe" approach and would work under almost all circumstances. There are always different ways to "skin the cow", none is perfect and none will get everyones approval but to call it a bug is a bit over the fence in my opinion.

I haven't had time to run tests along with you guys, but I am deeply interested in the discussion between johnmeyer and atom12.

Could you post your workaround(s) in the form of step-by-step examples, so I can see where I need to start?

TBH, I isolated the behavior a long time back, but kind of passively accepted it as essential collateral to rendering with multiple tracks, even when there is no intentional compositing.