Page 1 of 1

looping query

Posted: Fri May 11, 2007 7:59 am
by ldowell
I have a question about something I'm trying to do with looping. I'm trying to use a wave file that is ~10 sec in duration. At approximately 3s I have placed a loop start, and at ~6s a loop end. If I let it loop more than a couple of times it 'appeared' to not run the final 4s. If I let it loop only once or twice, or not loop at all it completed playback correctly. In digging into the forum, I found some references to playback buffers and the possibility of the playback cursor appearing to exit the loop while in fact another loop was being played. I tacked about 5s of silence to the end of the wave file in question and now am getting playback as I would expect, that is begin/loop/end regarless of loop count. Am I trying to do something SCS wasn't intended to do (small time frames relative to buffering, that is)? Is the buffer size something I can manipulate to adapt for this. Thanks for any and all info'

Lyle Dowell

On a side note, I'm a new user of this s'ware. I'm quite impressed with it's capabilities, flexibility, and ease of use.

Posted: Fri May 11, 2007 7:03 pm
by Mike Daniell
Hmmm - it appears there is still a bug with the progress indicator not repeating the last cycle of the loop if the loop is released within the playback buffer time of the end of the loop. I'll take another look at this.

You can adjust the playback buffer length under View / Options / Audio Driver, but note that the setting is global, ie you can't adjust it on a per-file basis. There's some info about the Audio Driver settings in the SCS Help.

Posted: Mon May 14, 2007 1:54 am
by jkowtko
Mike, I've noticed that when you play a looped file within the Editor, you'll get the second iteration of the loop accompanied by an attenuated end of track (the part after loop end) from the first iteration. I only noticed this in the editor though, not in the run screen.

Posted: Mon May 14, 2007 2:04 pm
by Mike Daniell
Found the cause of the problem reported by Lyle. This can occur if the length of the loop is less than the playback buffer length. Under these circumstances the read-ahead of the audio file could be two or more cycles ahead of what you hear. This will be fixed in 9.4 by dynamically downsizing the playback buffer for any cue that contains a loop so that the playback buffer size will always be less than the loop length (with a minimum playback buffer size of 200ms).

When 9.4 becomes available could you try this with your test, John? Can't think what would cause the attenuation.