The problem is seemingly the result of arithmetic imprecision in time point comparison, and if this gets fixed, it would be nice for GW to then clearly define whether boundary cuepoints are inside or outside the region.
Tip: workaround for random cuepoint include in edits
Tip: workaround for random cuepoint include in edits
Other batch process users experiencing the problem wherein a cuepoint at the boundary of a delete or trim may or may not get retained, seemingly randomly, may find this workaround useful:
The problem is seemingly the result of arithmetic imprecision in time point comparison, and if this gets fixed, it would be nice for GW to then clearly define whether boundary cuepoints are inside or outside the region.
The problem is seemingly the result of arithmetic imprecision in time point comparison, and if this gets fixed, it would be nice for GW to then clearly define whether boundary cuepoints are inside or outside the region.
-
Leprechaun
- Posts: 19
- Joined: Sat Sep 03, 2005 8:57 pm
- Location: Metro Atlanta, Georgia (U.S.A.)
- Contact:
Re: Tip: workaround for random cuepoint include in edits
This is a great tip. Although I don't do much batch editing, the tip enhances my awareness of conditions impacting cue points (I'm thinking specifically in manual selection between cue points) and the order of selection.
A big THANKS for sharing!
A big THANKS for sharing!