I notice that the Playlist Control Bar calculates the total time of the Playlist based upon FadeOut points, where as the Backtiming column takes into account the StartNext points - On a test playlist with talkover beds, the difference in values was around 10 minutes. I noticed this when I started putting an End of Playlist “DUMMY” into each hourly playlist to denote when the last item would finish.
Just wondered whether the timing differences was a deliberate “feature” or not :-\
Charlie, re the PerfectTime script: can I ask which of those two values the script ‘picks up?’
As you probably recall, the script ‘cheats’ by using the time of the final Playlist item, so it should in theory use the backtiming column time rather than the Playlist Toolbar time.
(And just between us: I suspect that the Toolbar time calculation was never changed after StartNext was added as a cue point … ;))
Hi Cad
Well, it looks at the Backtiming Column from what I could tell. As a test, I ran it on my playlist was told that it couldn’t trim 138 seconds. So I put a StartNext marker about halfway through “Whole of the Moon” by the Waterboys, it then said it couldn’t trim 84 seconds. So, by my reckoning - it’s calculating total playlist time using the Backtiming Column.
As for the Control Bar duration display - I suppose it’s a good way of seeing how long a playlist “could be” were it not for StartNext markers and cheeky scripts that do all sorts to the timing of a playlist
Good-oh, that’s what the script should be doing! ;D
I agree with you that it’s confusing to have a time in the Backtiming column of the Playlist and a conflicting ‘duration’ in the Playlist toolbar.
My view is that the toolbar ‘duration’ should be calculated using StartNext cue points when present (instead of FadeOut cue points). After all, which will be correct if you put the Playlist into AUTO and run it? (Answer: the Backtiming ‘time!’)