Buma

I’m building a radio automation patch. The main part of this patch are two players which are totally automated and filled with tracks contained in a database (with rotation rules etc, but that’s not the problem here...)

So, I need to play these two buffers one after the other without gap or silence. The problem is that some tracks that will be loaded into these buffers can have seconds of “silence” at the end or start.

I need to trigger the crossfading between each buffer at the right time and I need to be sure that the track is actually finished. As much as possible, I would really want to avoid storing thousands of (manually set) cue points in a database.

My first thought was to use a combination of peakamp~ an thresh~ to detect a significant decrease of amplitude and then trigger the crossfading, but of course, that won’t work if the buffer contains “silence” right in the middle of a track and triggers the xfade whereas the track is not actually finished.

Now, I think that the offline analysis on the freq. domain of each buffer might be the solution, maybe something like segmenting the buffer and ensure that the last segment was played before triggering the crossfading.

I hope that my explanations are clear enough. Does somebody have any advice ? A better idea ? I would really appreciate some help on this point.

Hello,
I’m building a radio automation patch. The main part of this patch are two players which are totally automated and filled with tracks contained in a database (with rotation rules etc, but that’s not the problem here...)

I need to trigger the crossfading between each buffer at the right time and I need to be sure that the track is actually finished. As much as possible, I would really want to avoid storing thousands of (manually set) cue points in a database. 

Now, I think that the offline analysis on the freq. domain of each buffer might be the solution, maybe something like segmenting the buffer and ensure that the last segment was played before triggering the crossfading. 

crossfade-point-detection-between-two-buffers-gap-killer

What's a good rule for when a song is done? 3 seconds of silence? 5? 10?

What you can do is have two players for each of the two tracks: the first player is the one you listen to, and the other is listening ahead to see if the song is finished. (So you'd have four sound file players in total for two tracks to do overlapping playback.)

The key thing is that when starting a song, you start the "future" version with a time offset of n seconds. (the look ahead time + time for a crossfade)

If I can suggest an alternative for your detection function: use abs~ into rampsmooth~ 1 88200 into thresh~ 0.001 0.005.

This will give you a peak follower with a release of two seconds. You can set it longer if necessary, and you might want to adjust the thresholds, but it will get you in the ballpark.

Your detection function will need to be able to identify silences in advance of when you need to start the crossfade for the next song, so build in some overlap time. Haven't done this one myself, but it should work.

What's a good rule for when a song is done?  3 seconds of silence? 5? 10?

What you can do is have two players for each of the two tracks: the first player is the one you listen to, and the other is listening ahead to see if the song is finished.  (So you'd have four sound file players in total for two tracks to do overlapping playback.)

The key thing is that when starting a song, you start the "future" version with a time offset of n seconds.  (the look ahead time + time for a crossfade)

This will give you a peak follower with a release of two seconds.  You can set it longer if necessary, and you might want to adjust the thresholds, but it will get you in the ballpark.

Your detection function will need to be able to identify silences in advance of when you need to start the crossfade for the next song, so build in some overlap time.  Haven't done this one myself, but it should work.


Based on your suggestion, of having some kind of parallel "ghost players" to detect the correct cue points, I imagined this modification:

A "ghost player" is started at the same time that the real player but reads the buffer in reverse at speed *4. At the same time, a timer is started to count the milliseconds elapsed from the end of the buffer till the thresh~ is reached.

This way, I can start the player without latency and get the "End cue point" while the real buffer is played normally.

(I'll find the crossfade point from this number but, as I want to implement different types of transitions there's still work to be done.)

It's not ultra precise yet but it's ok. I'll have to tweak the settings, add your rampsmooth~suggestion, and maybe add a third player to do the process in reverse to get the Start cue point.

Here's a rough prototype. I will post the complete deck later.

Based on your suggestion, of having some kind of parallel "ghost players" to detect the correct cue points, I imagined this modification: 

This way, I can start the player without latency and get the "End cue point" while the real buffer is played normally. 

(I'll find the crossfade point from this number but, as I want to implement different types of transitions  there's still work to be done.)

Here's a rough prototype. I will post the complete deck later. 

The silence detection or "gap killer" is now implemented in the patch. It sets the correct start point and end point and the playing speed ratio is adjusted in consequence.

Now, I realize that to have an efficient crossfading, or to activate it or not, I need to know if each song ends abruptly or with a smooth fade-out. If the track ends abruptly, the track contained in the next buffer should not overlap the other one. (For a radio mix, we want to avoid two chords played together for example, but instead add 500ms of silence between each buffer or play a jingle) But if the track ends with a long fade out, we can use this fade out to play a "sweeper" or to start the next buffer.

Using the previous technique of reading the buffer in reverse, I guess I have to calculate the ramp time between 0. and the average amplitude or energy of the buffer. (?) But I'm not sure this is the best solution. I'm afraid this won't produce the expected results.

The silence detection or "gap killer" is now implemented in the patch. It sets the correct start point and end point and the playing speed ratio is adjusted in consequence. 

Now, I realize that to have an efficient crossfading, or to activate it or not, I need to know if each song ends abruptly or with a smooth fade-out. If the track ends abruptly, the track contained in the next buffer should not overlap the other one. (For a radio mix, we want to avoid two chords  played together for example, but instead add 500ms of silence between each buffer or play a jingle) But if the track ends with a long fade out, we can use this fade out to play a "sweeper" or to start the next buffer.

Using the previous technique of reading the buffer in reverse, I guess I have to calculate the ramp time between 0. and the average amplitude or energy of the buffer. (?) But I'm not sure this is the best solution. I'm afraid this won't produce the expected results. 

You could use peakamp~ 100 into atodb into zl.stream 11 into zl.median.

The difference between successive median values should tell you whether it's a sharp transition or a gradual one, since a quick cutoff will have a rapid drop whereas a fadeout will change gradually. (Using median rather than mean is really useful here!)

Alternatively, you can use two envelope followers, one with a faster release and one with a slower release and compare the difference between them. Something like average~ 1500 rms into rampsmooth~ 3000 3000 and rampsmooth~ 3000 44100. When the difference gets large, you've got a cutoff. You might try converting the output of average~ Into decibels.

For either solution, you will probably need to play around with those numbers.

You could use peakamp~ 100 into atodb into zl.stream 11 into zl.median.  

The difference between successive median values should tell you whether it's a sharp transition or a gradual one, since a quick cutoff will have a rapid drop whereas a fadeout will change gradually.  (Using median rather than mean is really useful here!)  

Alternatively, you can use two envelope followers, one with a faster release and one with a slower release and compare the difference between them.  Something like average~ 1500 rms into rampsmooth~ 3000 3000 and rampsmooth~ 3000 44100.  When the difference gets large, you've got a cutoff.  You might try converting the output of average~ Into decibels.  

For either solution, you will probably need to play around with those numbers.


That's brilliant. Thank you very much. I will try that tomorrow and post the results.

That's brilliant. Thank you very much. I will try that tomorrow and post the results.
Thanks again Peter !


Crossfade point detection / "gap killer" / Determine fade-out time of a buffer