Crossfades and overlaps

[Warblefly]

Thank you for reading this and for developing this software.

I'm guessing the new crossfade logic means my preference for pure overlaps, using the natural fade-out or ending of each track (as detected automatically), needs rethinking or retooling?

At the moment, I use my analysis program to detect the best point near the end of a track to begin the next track, and use only an overlap.

This is in 2.2.2.

myplaylist = crossfade(duration=30.0, smart=false, fade_out=0., fade_in=0., default=(fun(a,b)->add(normalize=false,([b, a]))), myplaylist)

Each track contains a liq_cue_in annotation for cue_cut (now removed after 2.2.2), a calculated duration, and a liq_cross_duration which is the time before the measured end of the track and the point where the next track (or news bulletin) should start.

Using no fade-in and fade-out, the tracks simply overlap, using the crossfade in 2.2.2 with an add() function to do the overlap. But, when testing 2.2.4, I now seem to have the fade out occurring suddenly at the point given by liq_cross_duration: and the outgoing track simply disappears here.

How can I stop this happening? Do I need to remake my playlist with a delay for the fade-out equal to the liq_cross_duration?

JW

[toots]

Hi! In 2.2.4 I think you should use liq_fade_out_delay to start the 0 length fade out at the end of the buffer. The parameter is not available in the arguments, though.

[Warblefly]

Thanks! This seems to work in 2.2.4. It's now in my annotate: section before the filename in my m3u8 playlists.

[Moonbase59]

Hey @Warblefly! Your cue_playlist actually inspired me to write a cue_file and a Liquidsoap protocol autocue:, and we work on the same (loudness/overlap) principles, I should say. It needs a little cleanup still but will eventually end up on GitHub, for additional polishing by the "gurus" here.

It currently generates values like these:

2024/02/17 02:25:28 [protocol.autocue:3] ("duration", "361.74")
2024/02/17 02:25:28 [protocol.autocue:3] ("liq_cue_in", "0.30")
2024/02/17 02:25:28 [protocol.autocue:3] ("liq_cue_out", "361.60")
2024/02/17 02:25:28 [protocol.autocue:3] ("longtail", "false")
2024/02/17 02:25:28 [protocol.autocue:3] ("liq_cross_duration", "13.20")
2024/02/17 02:25:28 [protocol.autocue:3] ("loudness", "-11.30 dB")
2024/02/17 02:25:28 [protocol.autocue:3] ("liq_amplify", "-6.70 dB")

and I’m quite happy with it. I do let it fade a little at times, but most playout is overlapped or segueing. It can be used with a simple add, or cross.simple and cross.smart, depending on what one wants.

Only drawback currently is that I need to modify @BusterNeece’s autodj_next_song() function, by adding the protocol to the request:

# START LS-REPLACE: 10_audodj_next_song_add_autocue
# AutoDJ Next Song Script
def autodj_next_song() =
    response = azuracast_api_call(
        "nextsong",
        ""
    )
    if (response == "") or (response == "false") then
        null()
    else
        r = request.create("autocue:" ^ response)
        if request.resolve(r) then
            r
        else
            null()
       end
    end
end

# END LS-REPLACE: 10_audodj_next_song_add_autocue

To do that, I use @RM-FM’s great ls-config-replace AzuraCast plugin.

My test station currently runs on these settings:

settings.protocol.autocue.path := "cue_file"
settings.protocol.autocue.timeout := 30.
settings.protocol.autocue.target := -18  # EBU R128 LUFS target
settings.protocol.autocue.silence := 40  # LU below song integrated loudness to trigger cue points
settings.protocol.autocue.overlay := 8  # LU below song integrated loudness to trigger overlay start
settings.protocol.autocue.overlay_longtail := 15  # seconds to trigger "long tail" handling

Processing an "average" (3–5 min) song takes about 2–3 seconds, my longest song (79:12 min, 468 MB, FLAC) takes ~24 s on my laptop, or ~14.5 s on the station, plus you get a "ReplayGain" (well, a good approximation at least) for free, in the form of a liq_amplify. (liq_amplify is enabled by default in AzuraCast.)

It appears this can actually be used for "on-the-fly" processing, instead of needing a pre-processing stage. It also doesn’t modify the song files. Users of unprocessed files (downloads, ungained, files with silence at the ends) will appreciate that.

Note: Values for above already set by the user in the GUI will not be overwritten. Automation is great, but manual "wins".

Results are rather good, I reckon. If you like to talk, just add me as friend in the Discord and reach out to me.

And thanks again for sharing yours!

N.B.: @RM-FM is also working on a similar solution, using ffprobe and pure LS code, and we’ve been talking a lot recently. Surely also something to watch out for.