Multicamera, minor glitches, and Project Inspector

megabit wrote on 9/21/2008, 6:30 AM
For my current, pretty serious music DVD production, I am preparing three separate projects (the main concert, the venue impressions, and the interview with the performer). In fact, they are my first multicam Vegas projects ever, so I am learning a lot these days :)

After I synced the main piece (the recital itself), and did some rudimentary multicam editing (using just Vegas tools), I realized (to some horror) than I didn't have Quantize to frames activated. Knowing I would do it again from scratch anyway, I continued editing - and never noticed any single glitch in the output.

Nevertheless, when preparing for syncing the next film (the interview), I of course paid special attention to follow the rules, and am 100% sure I DID activate Quantize to frames...

Some time ago, looking for some automation tools, I downloaded Excalibur demo (which I found very useful - in fact, it was very efficient in performing certain operations that Ultimate S just failed at). It's also worth noting that Excalibur (including the Project Inspector tool) are the only add-ons (scripts, plug-ins etc) that actually work perfectly with Vegas 8.1 - is it due to some better programming, or a pure coincidence I don't know, nevertheless congratulations Edward!

Now, to the point. Using the Project Inspector tool, I can find a couple of minor mistakes in my projects - the most serious being that a couple of clips do not start at frame boundaries. But guess what - this only happened in the second project, where Quantize to frames WAS enabled! The first project (where I forgot to activate Quantization) the Project Inspector doesn't find any such errors at all

Could someone (especially Edward) advise what could have happened, how to avoid such mistakes in the future, and - perhaps the most important thing: if I cannot see any glitches when previewing those areas in Vegas, is there still a danger of some in the final DVD (like e.g. when navigating from the menu, slow/fast playback, freezing frames etc.)?

I'm not yet sure whether I will be using the Multicam tool those add-ons offer, instead of that built in Vegas - I'm a little discouraged by the very idea of adding lots of markers, etc. With all the markers I need for chapter points, all the regions I need for subtitles export, I guess adding any more would turn my project in a mess... Or is it worth it, regardless? Opinions welcome.

BTW, it'd be nice if Vegas offered selective display of markers/regions; i.e. when Multicamera editing, I'd like any non-related markers to be switched off (NOT removed).

AMD TR 2990WX CPU | MSI X399 CARBON AC | 64GB RAM@XMP2933  | 2x RTX 2080Ti GPU | 4x 3TB WD Black RAID0 media drive | 3x 1TB NVMe RAID0 cache drive | SSD SATA system drive | AX1600i PSU | Decklink 12G Extreme | Samsung UHD reference monitor (calibrated)

Comments

jetdv wrote on 9/21/2008, 10:10 AM
Not sure why you'd be getting unquantized frames if Quantize was turned on. This should only happen if you turn it off. If you copied and pasted from another project where Quantize was turned off, I can see that happening as well.

As for the extra markers used by multi-cam, I can only answer for Excalibur (we'll let JR answer for Ultimate S). With Excalibur, you can have it automatically delete the markers when Multi-cam is run. This will get rid of "all the extraneous markers". Of course there may be some markers you do want left. You can do that as well by inserting "comment" markers (just begin the label with a ">" character and Excalibur will NOT delete that marker). In fact, it can also strip off the ">" character for you as it deletes the camera switch markers. It won't touch any regions you have defined.
johnmeyer wrote on 9/21/2008, 12:02 PM
I run into the quantize issue all the time. It happens if you use video from other sources or which has been rendered in other programs. The frame rate setting in these video files is often stored with slightly different precision than what Vegas uses and expects. For instance, for NTSC video, the frame rate is usually expressed as 29.97. However, it is really 1000/1001 * 30 which actually equals 29.970029970030. Not every video program stores this number the same way.

Several years ago, I wrote a script which had to deal with this, and briefly started to understand how Vegas stores things internally. Because Vegas started as an audio editing platform, and also because the Vegas designers wisely designed it to be able to handle multiple formats simultaneously, the way things are stored internally can lead to all sorts of round off issues. I am actually amazed when things DO line up.

My solution to these issues and problems when they occur is to use Randall Campbell's Quantize to Frames script. I didn't write this, so don't ask me for help if it doesn't work in Vegas 8. I still don't run Vegas 8.x, so I don't know if it works in that environment. The Vegas engineers very unwisely neglect to provide upward compatibility in their scripting environment.

However, if this script runs, it will take care of the problem you mention. You can then run my auditing script (available at VASST) which will look for any slight overlaps or gaps that this script might create.

Finally, there is that hidden "internal preferences" dialog that lets you change all sorts of forbidden settings in Vegas. I strongly recommend that no one mess with these at all, but having said that, someone posted about six months ago that one of these settings changes Vegas so that it displays red at the edge of any event if it doesn't line up with the project frame boundaries. This lets you instantly know that you're in trouble so you can correct the problem right then and there. Before I changed this setting, I constantly had the problem you describe. I haven't had the problem since I made the change. If you want to make the change, you change both "Show unquantized event start" and Show unquantized event end" from FALSE to TRUE.
megabit wrote on 9/21/2008, 12:37 PM
Edward, John;

Thank you very much for your input - great news: Johns's suggested scripts work in both 8.0c and 8.1, just as Excalibur does!

The auditing scripts does find short gaps/overlaps, but unfortunately only informs about their existence - doesn't highlight them or show the timecode (is it supposed to?)

Piotr

AMD TR 2990WX CPU | MSI X399 CARBON AC | 64GB RAM@XMP2933  | 2x RTX 2080Ti GPU | 4x 3TB WD Black RAID0 media drive | 3x 1TB NVMe RAID0 cache drive | SSD SATA system drive | AX1600i PSU | Decklink 12G Extreme | Samsung UHD reference monitor (calibrated)

megabit wrote on 9/21/2008, 1:18 PM
John,

I enabled the hidden settings in preferences, and now can clearly see all unquantized instances in red. Running the "Quantize" scripts reports the number of instances found, and indeed removes the red areas (creating some gaps and overlaps as a by-product).

But what worries me is that - even after no red areas are visible any longer - running the Quantize script again still reports the exact same number of unquantized events found! I tried several times, hoping it would report zero - but to no avail...

What am missing, John?

AMD TR 2990WX CPU | MSI X399 CARBON AC | 64GB RAM@XMP2933  | 2x RTX 2080Ti GPU | 4x 3TB WD Black RAID0 media drive | 3x 1TB NVMe RAID0 cache drive | SSD SATA system drive | AX1600i PSU | Decklink 12G Extreme | Samsung UHD reference monitor (calibrated)

farss wrote on 9/21/2008, 3:45 PM
Sorry to intrude but perhaps worth mentioning that you're working in PAL and therefore the frame rate is a nice simple integer number.
Even working in PAL though I've noticed another curious problem. The Export EDL script can have 1 frame offsets in the TC of cuts.
I haven't checked how accurate saving as AAF is as yet, just glad it works.
Possibly the script that's checking for non quantized in/out points is exposing much the same problem.
Aside from all of that though the impact of having unquantized in/out points appears to be zero so long as you don't create tiny gaps.

Bob.
johnmeyer wrote on 9/22/2008, 8:39 AM
PAL framerate may be an integer number, but that doesn't guarantee that it is stored as an integer number; in fact I'm pretty sure it is not. Everything is a multiple of some internal clock rate, I think.
megabit wrote on 9/22/2008, 8:41 AM
Bob, if everybody was "intruding" the way you do :)

Anyway, after putting together another project not involving multicam, I haven't noticed any unquantized starts/ends at all. So - regardless on the "Quantize to frames" Vegas setting - it's perhaps this changing active takes while watching the multicam track that introduces them.

But your words of then not having any serious impact really comfort me. Thanks!

AMD TR 2990WX CPU | MSI X399 CARBON AC | 64GB RAM@XMP2933  | 2x RTX 2080Ti GPU | 4x 3TB WD Black RAID0 media drive | 3x 1TB NVMe RAID0 cache drive | SSD SATA system drive | AX1600i PSU | Decklink 12G Extreme | Samsung UHD reference monitor (calibrated)

johnmeyer wrote on 9/22/2008, 1:49 PM
The auditing scripts does find short gaps/overlaps, but unfortunately only informs about their existence - doesn't highlight them or show the timecode (is it supposed to?)No, it only puts a marker at the beginning of the event. You have to fix it. The reason for this is that there isn't any hard and fast rule as to what needs to be done. Also, what you do can affect everything to the right of that event. If the script changed everything, it could create a real nightmare, especially in a multi-track project where everything must line up exactly.