Possible explanation for some slow renders .. bug?

Comments

johnmeyer wrote on 1/22/2015, 11:29 AM
Would "Muting" the unused/not needed Tracks give the same quicker render times result?Yes and no. Yes it will stop the un-needed compositing, but no, it probably isn't a viable workaround for most projects because in most projects, some of the events on each track are used at some point on the timeline.


Maybe the reason I never experienced this is because I never have any unused media in my project, not on a track and not in the media pool.As we've all done these tests, it is clear that the problem has to do with the PAR of the media in the project, but nothing whatsoever to do with the aspect ratio or PAR of the template you use for rendering. Therefore, if you don't use non-square pixel media (i.e., a PAR of something other than 1.000), then you won't encounter the problem.


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.Once again, atom12 nails it.


I don't think Vegas composites portions where there is [simply] no event below a top event.From all my testing, both for this bug, and in other tests, I think this is 100% correct.


Could you post your workaround(s) in the form of step-by-step examples, so I can see where I need to start? The complete workaround is easy to describe, but potentially very time-consuming. You look at the events on each track, other than the top track. If there is an event on the top track which "covers" this event, and if you don't have any child tracks, compositing mode set on a track above, or any fX that permits lower tracks to show through, then you delete that media. Save this under a different project name so as not to affect your original project, just in case ...

You only have to do this if you are using media that has a PAR other than 1.000.

So, as I said in the title of the thread, this is an explanation for some slow renders, and not everyone will experience it. However, if you do have the problem, it makes a HUGE difference in render times, and also timeline performance.

If you have this problem, it is a major deal.

As to whether it should be classified as a "bug," we get in to Humpty Dumpty territory: "When I use a word, it means just what I choose it to mean - neither more nor less." You can define the word "bug" to mean many different things. Some people only use it to describe a crash; I use it to mean anything that is unexpected, and counter to how most people would expect the product to function.
musicvid10 wrote on 1/22/2015, 12:39 PM
This sounds way too simple to work, but if one put everything in a square pixel project (1920 instead of 1440, or 852 instead of 720), and rendered accordingly to full display aspect, would it prevent the problem?

Sorry if I missed this or it got buried in the discussion.

farss wrote on 1/22/2015, 12:54 PM
[i]"This sounds way too simple to work, but if one put everything in a square pixel project (1920 instead of 1440, or 852 instead of 720), and rendered accordingly to full display aspect, would it prevent the problem?"[/I]

If all the media was square pixels in a matching square pixel project the problem would go away.
The problem though is what's the correct SAR. For 16:9 SD PAL Vegas gives an answer that for the horizontal dimension is an odd number of pixels which is obvious wrong but mathematically correct.

Bob.
johnmeyer wrote on 1/22/2015, 1:34 PM
This sounds way too simple to work, but if one put everything in a square pixel project (1920 instead of 1440, or 852 instead of 720), and rendered accordingly to full display aspect, would it prevent the problem?"The project settings have absolutely no effect on the outcome, so this would not fix the problem.

Remember, everything "above the line" in the project settings does not affect the render; they are only there to conform the video during timeline playback so you can see what things will look like in the final render, but while you are editing. The one exception is the Debugmode Frameserver which does serve out according to the Project Properties settings.

And yes, I did try doing what you suggested, just to make sure.

If all the media was square pixels in a matching square pixel project the problem would go away.Again, it doesn't matter what the project settings are set to, but the first part of the statement is correct: I have not been able to reproduce the problem if all the media is square pixels.
OldSmoke wrote on 1/22/2015, 3:01 PM
I must be doing something entirely wrong because I cant reproduce this render bug. I made a test project with HDV on top, HD 1080 60i on the bottom which is more then slightly rotated. I cut out several sections of the top track to simulate what John Meyer is doing in his project. I then rendered to NTSC DVD Widescreen a 2min. region three times:

1: The region that contains all the cuts,
2: A region of same length with no cuts,
3: The same region from 2 but with bottom track muted
4: The same region again from 2 but with the bottom track removed

For this test I even disabled my GPU and rendered CPU only. The result can be seen here:


As you can see, 2,3 & 4 take the same amount of time to render; 1 is a bit slower but that is expected. What am I missing?

On a side note: Why is John not using a multicam track?

Proud owner of Sony Vegas Pro 7, 8, 9, 10, 11, 12 & 13 and now Magix VP15&16.

System Spec.:
Motherboard: ASUS X299 Prime-A

Ram: G.Skill 4x8GB DDR4 2666 XMP

CPU: i7-9800x @ 4.6GHz (custom water cooling system)
GPU: 1x AMD Vega Pro Frontier Edition (water cooled)
Hard drives: System Samsung 970Pro NVME, AV-Projects 1TB (4x Intel P7600 512GB VROC), 4x 2.5" Hotswap bays, 1x 3.5" Hotswap Bay, 1x LG BluRay Burner

PSU: Corsair 1200W
Monitor: 2x Dell Ultrasharp U2713HM (2560x1440)

larry-peter wrote on 1/22/2015, 3:23 PM
@OldSmoke,
First I would ask if "Adjust source media to better match project or render settings" is enabled, because according to Admin's earliest post, that switch would eliminate the issue. I'm not sure if it's "evil" but, like John Meyer, I never use it.

Second, since what I believe we're testing is tracks that are composited when they don't need to be vs. tracks where compositing is definitely not taking place, by rotating the square pixel track on the bottom, you're forcing compositing to happen there as well as (we think) the 1.33PAR track above it. See what happens if the "adjust" switch is off, plus no rotation on the bottom track.

Edit: as to the why of multicam or not, speaking for myself, if I somewhat know my edit points going in, or if I expect few edits to be made, it can sometimes be faster working this way than working in multicam.
OldSmoke wrote on 1/22/2015, 3:43 PM
@atom12
[I]First I would ask if "Adjust source media to better match project or render settings" is enabled[/I]
NO, that is never enabled on my system and YES, it is evil.

I did no rotation on the bottom track and that wasn't any different and wouldn't follow John Meyer's test from his initial post, I think.
The reason I did this test again is because my system is way to fast to use test render project and clips.

Edit: If you don't use a multicam track then each clip must be aligned on the timeline, after all he is doing a live event, which can be very time consuming even with a tool like Plural Eyes.

Proud owner of Sony Vegas Pro 7, 8, 9, 10, 11, 12 & 13 and now Magix VP15&16.

System Spec.:
Motherboard: ASUS X299 Prime-A

Ram: G.Skill 4x8GB DDR4 2666 XMP

CPU: i7-9800x @ 4.6GHz (custom water cooling system)
GPU: 1x AMD Vega Pro Frontier Edition (water cooled)
Hard drives: System Samsung 970Pro NVME, AV-Projects 1TB (4x Intel P7600 512GB VROC), 4x 2.5" Hotswap bays, 1x 3.5" Hotswap Bay, 1x LG BluRay Burner

PSU: Corsair 1200W
Monitor: 2x Dell Ultrasharp U2713HM (2560x1440)

johnmeyer wrote on 1/22/2015, 4:09 PM
I must be doing something entirely wrong because I cant reproduce this render bug.Did you download my little bug test file from my OP? It has two small media files, plus the VEG, a total of 50 MB. All you have to do is open, render to the template of your choice, and then repeat the render with the bottom track muted. If your system is so fast that the render is done instantly, just duplicate the events three or four times to make the video stretch across more of the timeline.

Why is John not using a multicam track?Because I'm a Luddite. Well, actually it is because I used to use Ed's Excalibur multi-cam. When Vegas included it, I never bothered to learn it, but I never updated Excalibur beyond Vegas 7, so I can't edit AVCHD (which was introduced in V8) without first creating an intermediate. So, for a two-camera shoot, I just line up the two video tracks and the soundboard audio using PluralEyes, and cut from there.

However, thanks to this problem, and the solutions offered, I went ahead and learned how the multicam works. Geez, am I a dope. It is really easy, and only took about three minutes to learn. So, from now on, I will be using the Vegas multicam.

BTW, it turns out that you don't need to do any rotation on the bottom event. The problem still remains, although the hit on performance is not quite so bad because Vegas doesn't have to do the (unnecessary) rotation on an HD clip, something that requires enough CPU to cause a noticeable additional slowdown. However, it is clear that the lower track is still being used. I just tested this, and with no rotation on the bottom track, the render to DV Widescreen took nine seconds (instead of thirteen), and with the bottom track removed (or muted) it took four. Still a 2:1 difference, which is a big deal.
OldSmoke wrote on 1/22/2015, 4:22 PM
@John Meyer
Did you download my little bug test file from my OP? It has two small media files, plus the VEG, a total of 50 MB. All you have to do is open, render to the template of your choice, and then repeat the render with the bottom track muted. If your system is so fast that the render is done instantly, just duplicate the events three or four times to make the video stretch across more of the timeline.

That is what I did in my very first test but still no go. I doubt my last test is any different from your initial project and as you can see I can't reproduce it.

Multicam editing in Vegas is one of the easiest I came across. This is my usual workflow:
1) put all the different camera files on a separate track
2) I then assign one as the "master" track to align all other tracks
3) Use track motion on the "master" track and the next track so that both become a side by side image.
2) align them on the time line
3) group all the events to ensure they don't get out of sync
4) apply color correction on the media level as good as possible
5) create the Multicam track and edit away

2&3 is only in case the cameras can't be synced. If all the media has synced time code you can actually ask Vegas to align all the media according to their time code.

Proud owner of Sony Vegas Pro 7, 8, 9, 10, 11, 12 & 13 and now Magix VP15&16.

System Spec.:
Motherboard: ASUS X299 Prime-A

Ram: G.Skill 4x8GB DDR4 2666 XMP

CPU: i7-9800x @ 4.6GHz (custom water cooling system)
GPU: 1x AMD Vega Pro Frontier Edition (water cooled)
Hard drives: System Samsung 970Pro NVME, AV-Projects 1TB (4x Intel P7600 512GB VROC), 4x 2.5" Hotswap bays, 1x 3.5" Hotswap Bay, 1x LG BluRay Burner

PSU: Corsair 1200W
Monitor: 2x Dell Ultrasharp U2713HM (2560x1440)

johnmeyer wrote on 1/23/2015, 12:49 AM
I've officially given up on this project. I had several emails back and forth with Sony support today, and they don't think there is a problem.

So, by definition, there isn't a problem.

I know how to work around it, and if Sony is OK with new customers sometimes having long renders and therefore thinking that Vegas is a pig that renders slowly compared to the competition, that is their problem, not mine.
Lovelight wrote on 1/26/2015, 9:35 PM
I had the same result with a different bug. Sony refuses to get their head out of sand.
relaxvideo wrote on 6/18/2020, 12:09 PM

I'm so glad that i found this topic, thanks johnmeyer!

I have exactly the same problem, and loose many hours deleting bottom, unwanted, not visible events. I make a 8 cam school event editing in every Januar. All cams are 1920x1080x50p 16:9 HD, so no aspect ratio issue here. Problem is not exist when events doesn't have any FX on it. I can have 8 tracks and the preview and render times are as fast as if only the top event exist. But as soon as i add a simple color correction or levels fx to the top event, all the below clips are computed, timeline preview will stutter and rendering takes 2-3x more times on my i7 pc.

John: what is your mentioned "viable workaround"?

many thanks!

johnmeyer wrote on 7/24/2020, 10:23 PM

relaxvideo,

Sorry for the delay, but I never come here any more, but was trying to help someone in another forum find all his posts in this forum that uses very strange non-standard forum software.

I answered the question several years ago in this thread, but it is such a long thread that it would have been easy to miss. In any other forum, I'd provide a link to that old post, but this doesn't appear to be possible with this strange forum software so I'll just paste my old reply below. I can't remember if I wrote a script to automate it (I have written over 100 Vegas scripts, and have forgotten what some of them do ...).

John

------------------

Could you post your workaround(s) in the form of step-by-step examples, so I can see where I need to start? The complete workaround is easy to describe, but potentially very time-consuming. You look at the events on each track, other than the top track. If there is an event on the top track which "covers" this event, and if you don't have any child tracks, compositing mode set on a track above, or any fX that permits lower tracks to show through, then you delete that media. Save this under a different project name so as not to affect your original project, just in case ...

john_dennis wrote on 7/25/2020, 12:51 AM

@relaxvideo @johnmeyer

This thread resurfaced when we were investigating an issue in Vegas Pro 17-321.

https://www.vegascreativesoftware.info/us/forum/vp17-timeline-playback-performance-for-multiple-tracks-321-update--116872/?page=1

I worked with one other person before that thread who ended up cutting gaps in the lower/hidden track in order to get the job out of the door, but I can't find the thread. I'm going to have to post less often...

My main system:
Motherboard: Asus X99-AII
CPU: Intel i7-6850K
GPU: Sapphire Radeon RX480-8GB
RAM: Corsair Dominator (4 x 4 GB) DDR4 2400
Disk O/S & Programs: Intel SSD 750 (400 GB)
Disk Active Projects: 1TB & 2TB WD BLACK SN750 NVMe Internal PCI Express 3.0 x4 Solid State Drives
Disk Other: WD Ultrastar/Hitachi Hard Drives: WDBBUR0080BNC-WRSN, HGST HUH728080ALE600, 724040ALE640, HDS3020BLA642
Case: LIAN LI PC-90 Black Aluminum ATX Full Tower Case
CPU cooling: Corsair Hydro series H115i
Power supply: SeaSonic SS-750KM3 750W 80 PLUS GOLD Certified Full Modular Active PFC Power Supply
Drive Bay: Kingwin KF-256-BK 2.5" and 3.5" Trayless Hot Swap Rack with USB 3
Sound card: Crystal Sound 3 on motherboard. Recording done on another system.
Primary Monitor: Asus ProArt PA248q (24" 1920 x 1200)
O/S: Windows 10 Pro 22H2, Build 19045.2130

Camera: Sony RX10 Model IV

https://www.youtube.com/user/thedennischannel

michael-harrison wrote on 7/25/2020, 5:29 AM

@john_dennis somehow this makes sense at 6am where the last time I ran across the subject, it didn't.

Since the default compositing mode is source alpha and there's no way for VP to be sure that any given frame *doesn't* contain alpha, it has to render the track stack from the bottom up. If there's nothing at frame 100 on a given track, it does nothing but otherwise has to spend the time rendering because a track higher up *might* have a single pixel with alpha.

Seems like this is something that *might* be scriptable @wwaag? but if not, many of us might benefit from a pre-rendering checklist step of "cut out media from lower tracks if there's no alpha above"

Last changed by michael-harrison on 7/25/2020, 5:30 AM, changed a total of 1 times.

System 1:

Windows 10
i9-10850K 10 Core
128.0G RAM
Nvidia GTX 1660 Studio [most likely latest]
Resolution        1920 x 1080 x 60 hertz
Video Memory 6G GDDR5

 

System 2:

Lenovo Yoga 720
Core i7-7700 2.8Ghz quad core, 8 logical
16G ram
Intel HD 630 gpu
Nvidia GTX 1050 gpu

 

Future System 3:

Processor        Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz, 3192 Mhz, 6 Core(s), 12 Logical Processor(s)
BaseBoard Product        ROG STRIX Z390-E GAMING
Installed Physical Memory (RAM)        48.0 GB

Musicvid wrote on 7/25/2020, 7:34 AM

@johnmeyer 

Nice to hear from you, John. I've followed many of your posts on Videohelp. Are you still set up to do 16mm transfer?. I've got a full reel I got from a public television producer. Forum talk here is about the same, same archetypes, different names ....

wwaag wrote on 7/25/2020, 10:13 AM

I wrote a couple of scripts, Remove Hidden Events and Mute Hidden Events, that do this--actually at the request of @relaxvideo Here's a graphic depiction of what they do.

They can be downloaded in the Happy Otter Free Tools library at https://tools4vegas.com/library/ I've not tested whether such a scripting action has any impact on subsequent render performance.

AKA the HappyOtter at https://tools4vegas.com/. System 1: Intel i7-8700k with HD 630 graphics plus an Nvidia 1050ti graphics card. System 2: Intel i7-3770k with HD 4000 graphics plus an AMD RX550 graphics card. System 3: Laptop. Dell Inspiron Plus 16. Intel i7-11800H, Intel Graphics. Current cameras include Panasonic FZ2500, GoPro Hero11 and Hero8 Black plus a myriad of smartPhone, pocket cameras, video cameras and film cameras going back to the original Nikon S.

johnmeyer wrote on 10/11/2021, 6:25 PM

I finally wrote a script that mutes events on lower tracks if they are covered by events on tracks above. It is similar to what wwaag wrote, but is done with old-fashioned jscript. Since I am still using ancient versions of Vegas, I don't know if jscript is still supported in the more modern versions.

The purpose of the script is to significantly reduce render times in certain multi-track Vegas projects.

The unnecessarily long renders happen if you have a non-trasnparent fX on an upper track (e.g., Levels, or Color Corrector) and then have complex operations being performed on lower tracks, but which don't show through. For a test case I put three copies of the slowest fX (min/max) on events on three lower tracks. I first soloed the top track and my test render took 9 seconds. I then un-soloed the track, and verified that the video in the Vegas preview display didn't change (i.e., the lower track video wasn't going to be used). I then rendered my few seconds, and the render estimate went from nine seconds to over ten minutes.

I'm providing this script as is, with the understanding that it may not work with modern versions of Vegas, if they've taken away jscript support, and also with the understanding that you have to make sure that you don't have any way that the "covered" events on the lower track could show through (see the Notes section in the script for examples). The script does handle event fades and opacity level, but is oblivious to any track operations, and also does not handle any changes made with a compositing envelope. Bottom line: it can be fooled, but for many projects, it can make a massive reduction in render times.

/**
* Mute video events on lower tracks if they are completely covered by any event on tracks above.
*
* Written By: John Meyer
* Written: October 11, 2021
*
* The script mutes events on all secondary tracks which are completely covered by events on tracks above.
* The reason for this script is that, under many circumstances, Vegas will needlessly composite video on lower tracks
* even if that video is never used. This can cause render times to balloon, often by integer multiples (2x, 3x, etc.)
*
* For the problem to happen, the upper events must have some non-transparent fX applied or must have a zoom in pan/crop, neither of which should allow
* lower events to show through, but both of which cause Vegas to needlessly render lower tracks. Mixing videos with different PARs can also cause problems.
*
* Discussion about problem here:
* https://www.vegascreativesoftware.info/us/forum/possible-explanation-for-some-slow-renders-bug--99410
*
* NOTE:
* This script will create problems if fX on upper events create transparency that let lower events show through, e.g., the Cookie Cutter fX.
* It should not be used when nested tracks are present.
* It will create problems if pan/crop causes video to shrink, or if rotation is used, or anything else that lets lower events show through.
* Any track-level panning will cause problems
* Any compositing envelope will cause problems
*
**/import System;
import System.IO;
import System.Windows.Forms;
import Sony.Vegas;  
/**
**************************************************************************
* Start of main program                                                  *
**************************************************************************
**/try {
    var evnt_last        : TrackEvent;
    var evnt             : TrackEvent;
    var scratch_evnt     : TrackEvent;
    var currenttrack     : Track;
    var eventEnum        : Enumerator;        
    var scratchtrackEnum : Enumerator;
    var ZeroFadelength   : Timecode = new Timecode("00:00:00:00");//  Add top scratch track
    var scratchtrack     : VideoTrack = new VideoTrack();
    Vegas.Project.Tracks.Add(scratchtrack);               // Add track.
    scratchtrack.Name = "Scratch Track ***Delete***";     // Add track header reminder, in case script gets interrupte and temp track remains//  Get list of tracks and enumerate the scratch track events
    var trackEnum = new Enumerator(Vegas.Project.Tracks);    
    var moretracks = FindNextVideoTrack();
    while (moretracks) {                   // Iterate through all video tracks, ignoring audio tracks
      currenttrack     = Track(trackEnum.item());   //    Copy all events on current track to scratch track
      eventEnum = new Enumerator(currenttrack.Events);
      while (!eventEnum.atEnd()) {
        evnt = TrackEvent(eventEnum.item());
        evnt.Copy(scratchtrack,evnt.Start);
        eventEnum.moveNext();
      } // End while (!eventEnum.atEnd()//    Merge overlapped events on scratch track into one event with no fades
      if (scratchtrack.Events.Count > 0) {
        MergeScratchTrackEvents();
      }
      else {
        throw ("No video events on top video track");  // I'm not sure this can happen, but in case it does ...
      }//    Split events on next track
      moretracks = FindNextVideoTrack();
      if (!moretracks)         //Get next video track, if there is one, otherwise exit while loop, clean up, and go home.
           break;  
      currenttrack = Track(trackEnum.item());  
      SplitEvents ();//    Mute all events on current track that will never bee seen in final video
      MuteCoveredEvents ();  } // End while (moretracks)
      Vegas.UpdateUI();    Vegas.Project.Tracks.Remove(scratchtrack);} catch (e) {
  MessageBox.Show(e);
}// End of main program
// ***********************************************************************
// Beginning of functions
// ***********************************************************************// Get next video track, skipping audio tracks. Return null if no more video tracks
function FindNextVideoTrack() : boolean{
  trackEnum.moveNext();
  while (!trackEnum.atEnd()) {
    var track : Track = Track(trackEnum.item());
    if (track.IsVideo()) {
      return 1;
    }
  trackEnum.moveNext();
  }
  return 0;
}// Merge overlapped events on scratch track, preserving fade on last event in groupfunction MergeScratchTrackEvents () {
  eventEnum = new Enumerator(scratchtrack.Events);
  evnt_last = TrackEvent(eventEnum.item());  // Before iterating through events, fix fade on first event
  // Shorten first event if it has a fade-in, because fade will allow lower track to show through
  evnt_last.Start = evnt_last.Start + evnt_last.FadeIn.Length;
  evnt_last.Length =  evnt_last.Length - evnt_last.FadeIn.Length;
  evnt_last.FadeIn.Length = ZeroFadelength;  // Remove first event if it has opacity set to less than 100%
  if (evnt_last.FadeIn.Gain < 1 ) {
       scratchtrack.Events.Remove(evnt_last);
       eventEnum = new Enumerator(scratchtrack.Events); // Re-enumerate after event is removed
       evnt_last = TrackEvent(eventEnum.item());
  }  eventEnum.moveNext();  // Go though all events after first one
  while (!eventEnum.atEnd()) {
     evnt = TrackEvent(eventEnum.item());     // Fades that don't overlap with adjacent event will let video show through, so event must be shortened by fade amount
     // This "if" handles fade-in, the next "if" handles fade-out     if (evnt.FadeIn.Length > ZeroFadelength && evnt.Start >= evnt_last.End ) {
       evnt.Start         = evnt.Start + evnt.FadeIn.Length;
       evnt.Length        = evnt.Length - evnt.FadeIn.Length;
       evnt.FadeIn.Length = ZeroFadelength;
     }     if (evnt_last.FadeOut.Length > ZeroFadelength && evnt_last.End <= evnt.Start ) {
       evnt_last.Length         = evnt_last.Length - evnt_last.FadeOut.Length;
       evnt_last.FadeOut.Length = ZeroFadelength;
     }     // Remove events which have opacity less than 1
     // Original version attempted to also eliminate events with pan/crop setting.
     // The following line will also eliminate events containining any fX (replace "if" below)
     // if (evnt.FadeIn.Gain < 1 ||  videoEvent.Effects.Count>0 ) {     var videoEvent = VideoEvent(evnt);
     videoEvent.VideoMotion.ScaleToFill = true;     if (evnt.FadeIn.Gain < 1 ) {
        scratchtrack.Events.Remove(evnt);
        eventEnum = new Enumerator(scratchtrack.Events); // Re-enumerate after event is removed
        evnt_last = TrackEvent(eventEnum.item());
        eventEnum.moveNext();
        evnt = TrackEvent(eventEnum.item()); //Events are now re-enumerated, but function will start over at first event
     }     //Remove event completely contained within previous event
     if (evnt.Start >= (evnt_last.Start) && evnt.End <= (evnt_last.End)) {
        scratchtrack.Events.Remove(evnt);
        eventEnum = new Enumerator(scratchtrack.Events); // Re-enumerate after event is removed
        evnt_last = TrackEvent(eventEnum.item());
        eventEnum.moveNext();
        evnt = TrackEvent(eventEnum.item());
     }
     // Merge events which overlap or which are abutted
     if (evnt.Start <= (evnt_last.End) ) {
        evnt_last.Length = evnt.Start - evnt_last.Start + evnt.Length
        evnt_last.FadeOut.Length  = evnt.FadeOut.Length;
        scratchtrack.Events.Remove(evnt);
        eventEnum = new Enumerator(scratchtrack.Events); // Re-enumerate after event is removed
     }     evnt_last = TrackEvent(eventEnum.item());
     eventEnum.moveNext();  } // End while( !eventEnum.asEnd() )     // If last event on scratchtrack has fade out, make adjustment
     if (evnt_last.FadeOut.Length > ZeroFadelength  ) {
       evnt_last.Length = evnt_last.Length - evnt_last.FadeOut.Length;
       evnt_last.FadeOut.Length = ZeroFadelength;
     }
} // End Function MergeScratchTrackEvents()// This function splits events on the current track at the event boundaries on the scratch track.
function SplitEvents () {
  scratchtrackEnum = new Enumerator(scratchtrack.Events);
  while (!scratchtrackEnum.atEnd()) {
      scratch_evnt = TrackEvent(scratchtrackEnum.item());
      eventEnum = new Enumerator(currenttrack.Events); // restart enumeration of current track
      while (!eventEnum.atEnd()) {
        evnt = TrackEvent(eventEnum.item());
        // This will split events on current track at the begin/end event boundaries on the scratch track
        if (scratch_evnt.Start > evnt.Start && scratch_evnt.Start < evnt.End ) {
            evnt.Split(scratch_evnt.Start - evnt.Start) ;
        }
        if (scratch_evnt.End < evnt.End && scratch_evnt.End > evnt.Start ) {
            evnt.Split(scratch_evnt.End - evnt.Start) ;
        }
        eventEnum.moveNext();
      } // End while (!eventEnum.atEnd()      scratchtrackEnum.moveNext();  }  // End while (!scratchtrackEnum.atEnd()}  // End function SplitEvents// This function mutes the events on the current track which lie under the events on the scratch track
// No attempt is made to be intelligent about terminating loops early, etc.
function MuteCoveredEvents () {
  scratchtrackEnum = new Enumerator(scratchtrack.Events);
  while (!scratchtrackEnum.atEnd()) {
      scratch_evnt = TrackEvent(scratchtrackEnum.item());
      eventEnum    = new Enumerator(currenttrack.Events);   // restart enumeration of current track
      while (!eventEnum.atEnd()) {
        evnt = TrackEvent(eventEnum.item());
        if (scratch_evnt.Start <= evnt.Start && scratch_evnt.End >= evnt.End ) {
            evnt.Mute = true;
        }
        eventEnum.moveNext();
      } // End while (!eventEnum.atEnd()
      scratchtrackEnum.moveNext();
  }  // End ehile (!scratchtrackEnum.atEnd()
}