I have checked the ‘mixdown problem’ and have found that playlist Mixdown (to MP3 in my case) is unreliable when processing any item which contains both a Start Next cue point and a Fade Out cue point. This will be the case if the user has used my IVP script and marked that item as ‘underlay’ (code u).
It seems that the following config. option in Miscellaneous, Options affects this bug as well: Regard Start Next marker as EOF
Please also note that I have the Regard Fade Out marker as EOF setting on (its default setting).
If the Regard Start Next marker as EOF config. option is off (my usual setting), and an item contains both a Start Next cue point and a Fade Out cue point, Mixdown ignores the Start Next cue point and does not start the next item until Fade Out.
If the Regard Start Next marker as EOF config. option is on, and an item contains both a Start Next cue point and a Fade Out cue point, playlist Mixdown typically processes the Start Next cue point correctly; however, this is not guaranteed, and one such item in my test playlist is still not handled correctly by playlist Mixdown, having the same problem as above (Start Next is ignored and next item does not start until Fade Out).
It’s a little late, so that’s all I have tested so far; but it does not seem right that the config. option should affect playlist Mixdown when it does not affect AUTO mode playout of the same playlist (which always plays all items in the Playlist correctly, and as intended). For example, I have not yet tried switching the the Regard Fade Out marker as EOF setting off and repeating the test.
Note to Richard: as a workaround, use AUTO playout and a program such as the excellent freeware mp3DirectCut (http://mpesch3.de1.cc/mp3dc.html) to ‘record’ the output and then manually top/tail the recording (you can that in mp3DC as well). Unfortunately, that’s a ‘real-time’ job rather the somewhat faster mAirList Mixdown.
First of all, I don’t think that “Regard Start Next as Effective End” has any effect on how Mixdown handles the segues.
There’s only a single spot in the source code where this option is used (I have verified that again), namely the GetEffetiveDisplayDuration method of IPlaylistItem. This method, in turn, is used to calculate the remaining duration to be displayed in the players, the playlist and the screen objects. But it does not affect the actual playback.
I will now check the mixdown code for the correct handling of Start Next points, and report back in a few minutes.
Thanks Cad. I didn’t see this problem last night, however I hadn’t changed the default of “Regard Start Next marker as EOF” and all my tests were on overlays, but still they had “Start Next” and “Fade Out” markers. With Voicetracks I had to remove the “Fade out” marker as it was set on import and caused the ramp to be hit hard (Due to it being set to -20dB by the import process". These VT’s were top’n’tailed in Audition.
Whilst poking around config (This program is full of little surprises in config) I found the ability under Encoders to record to file, so I thought about that under a real-time playback, and I also have Adobe Audition for real-time capture. However, my 16 month old woke up and put paid to further tinkling.
OK, I’ve done more extensive testing and theorising here, and I now think I know what the problem is, and probably how to fix it. 8)
Torben: I had similar problems with Playlist PFL, and I have also found a specific bug there.
STEPS TO REPRODUCE:
Open mAirList and drag a dry vocal sweeper or VT of at least 20 seconds duration into the Playlist.
Set the StartNext marker point of the vocal item to 250mS (yes, I do mean milliseconds :D).
Drag a music bed or any instrumental (like production music) into the Playlist, after the vocal.
(optional) Save the Playlist as a .mlp file for future testing.
Click This Playlist, PFL, PFL tab.
Click Start PFL if necessary.
After the music starts playing, click PAUSE.
PREDICTED RESULT:
The music item stops, all clocks stop, the progress bar(s) and position slider all stop, but the first (vocal) item continues playing to EOF.
I think this is technically a separate bug from the Mixdown problem, because you cannot ‘click PAUSE’ during a Mixdown. ;D
… but dragging the slider while Playlist PFL is in PLAY can be very messy, especially if any item contains both StartNext and FadeOut points.
I believe that part of the underlying problem is that StartNext is ‘sometimes’ being ignored when calculating the start time (or ‘arrival time’) of the following item, especially when the item contains both a StartNext and FadeOut point. If an item contains a StartNext, the following item’s ‘arrival time’ must always be calculated using that StartNext (add it to the ‘first’ item’s ‘arrival time’), even if the ‘first item’ contains a FadeOut, CueOut, or Anchor.
Conversely, when calculating an item’s ACTUAL end time (or ‘departure time’), StartNext MUST play NO part in that: one must decide which of FadeOut, CueOut, Anchor, or EOF is the correct value to add to the item’s ‘arrival time’ to calculate the item’s ACTUAL ‘departure time’ for the purposes of Playlist or container PFL; so that you can properly handle everything if the position slider is dragged to the left (i.e. backwards in time). You may want to consider forcing a PAUSE while slider moves are being processed and handled by mAirList, only enabling PLAY when all items have been checked for their ‘arrival time’ <= new position <= ‘departure time,’ then each eligible item needs to be placed in a ‘BASS player’ and positioned at (new position - ‘arrival time’), ready for (restarted) playout. (Phew!)
I should add that Playlist PFL does seem to work correctly if you allow it to play the entire Playlist whthout clicking or dragging anything. Mixdown does not appear to do the same, perhaps because it’s being processed in > real time? It could be my MP3 encoder (external LAME), so I’ll try a Mixdown to WAV and report back again.
However, note that you resume the playback, the voice track won’t play. That’s one of the limitations of the current container (and mixdown) algorithm. It will be addressed in the major rewrite I’m planning to do.
I assumed that (or something similar) was the answer.
As you say , that’s a limitation of the current algorithm; you do need truly multi-player compatible PFL to be able to do true voicetracking.
Ditto, you need to CORRECTLY calculate the relative start time of all items, even if the playlist is a complex one with lots of StartNexts, and even envelopes added by a script (as IVP does) to enable items to be ‘ducked’ under a subsequent item: otherwise, the results sound very bad (audio examples available upon request).
The (sometimes?!!) incorrect start times seem to be the underlying problem here: if that could be fixed within the current mixdown/container playout algorithm, then at least mixdowns would be correct.
Unfortunately, that’s a ‘real-time’ job rather the somewhat faster mAirList Mixdown. 
Mixdown does not appear to do the same, perhaps because it’s being processed in > real time? It could be my MP3 encoder (external LAME), so I’ll try a Mixdown to WAV and report back again.