Replacing the "default" argument in crossfade

[fkane]

Hi, I've been using @Warblefly 's scripts for pre-processing playlists to achieve smooth transitions. In short, it works by computing the best point to start the next track, overlapping it with the previous one without any fading per se, using liq_cue_in, liq_cross_duration, and an equal value for liq_fade_out_delay in the playlist annotations.

In Liquidsoap 2.2.5, we could specify that the tracks should blend together between the duration until the transition and the end of the track, using the default operator of crossfade:

myplaylist = crossfade(duration=30.0, smart=false, fade_out=0., fade_in=0., default=(fun(a,b)->add(normalize=false,([b, a]))), myplaylist)
However, in 2.3.0, the "default" parameter has been removed from crossfade. Can I rely on the built-in behavior to behave in the same way, or do I need to emulate it via other means?

I know 2.3.0 has its own built-in ability to automate transitions in a similar style, but I can't afford its CPU cost on the EC2 instance I'm running on.

Thank you,
Frank from Radio Calico

[fkane]

So, I've been running 2.3.0 as a test all day, and noticed that there doesn't seem to be any overlap at all between tracks now... it just plays each track through to completion before starting the next one, no matter what liq_cross_duration / liq_fade_out_delay says in the playlist annotations.

The crossfade operator is:

myplaylist = crossfade(duration=30.0, fade_out=0., fade_in=0., myplaylist)

An example playlist line for a track that should start playing the next one 10.1 seconds prior to the current track's completion:

annotate:liq_cue_in="0.100",liq_cross_duration="10.100",liq_fade_out_delay="10.100",duration="171.400",liq_amplify="-6.01dB":/home/ubuntu/media/Dion-Runaround_Sue/01-01-Dion-Runaround_Sue-LLS.flac

Is it possible to implement the desired behavior in 2.3.0? Thank you.

[gAlleb]

As I recall there have been some changes regarding that.

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

You can do:

def custom_crossfade(old, new) =

        add(normalize=false, [
            fade.in(
                initial_metadata=new.metadata,
                duration=0.1,
                new.source
            ),
            fade.out(
                initial_metadata=old.metadata,
                duration=2.5,
                old.source
            )
        ])

end

radio = cross(
    duration=2.5,
    caustom_crossfade,
    radio
)

---

If you don't like to do calculations on the fly you may want to look at cue_file autocue by @Moonbase59. It uses python script and is based on ideas of John Warburton. With cue_file you can preprocess your tracks and even write the tags into the file:
https://github.com/Moonbase59/autocue

It's been unmaintained for some time and doesn't have 2.3.0 compatibility out of the box but cue_file still works - https://github.com/Moonbase59/autocue/blob/master/cue_file and calculates liq_ values.

What you can try is this altered version: AzuraCast/AzuraCast#7584 (comment). It works with latest Liquidsoap and uses cue_file_ values instead of liq_. So when you annotate your files with cue_file_ tags and use this implementation of autocue you can avoid "CPU cost". After altering it's settings the crossfade function can look like this:

def custom_crossfade(old, new) =

        add(normalize=false, [
            fade.in(
                initial_metadata=new.metadata,
                duration=settings.autocue.cue_file.fade_in(),
                new.source
            ),
            fade.out(
                initial_metadata=old.metadata,
                duration=settings.autocue.cue_file.fade_out(),
                old.source
            )
        ])

end

radio = cross(
    duration=settings.autocue.cue_file.fade_out(),
    custom_crossfade,
    radio
)

cue_file is used as a preprocessor like:

% cue_file -wfkn /Users/music/1/07.flac

Overlay: -14.17 LUFS, Longtail: -26.17 LUFS, Measured end avg: -41.57 LUFS, Drop: 35.68%
Overlay times: 181.40/181.60/0.00 s (normal/sustained/longtail), using: 181.60 s.
Cue out time: 182.90 s
{"duration": 186.685079, "cue_file_cue_duration": 182.9, "cue_file_cue_in": 0.0, "cue_file_cue_out": 182.9, 
"cue_file_cross_start_next": 181.6, "cue_file_longtail": false, "cue_file_sustained_ending": true, "cue_file_loudness": "-6.17 LUFS",
 "cue_file_loudness_range": "9.50 LU", "cue_file_amplify": "-11.83 dB", "cue_file_amplify_adjustment": "0.00 dB", 
"cue_file_reference_loudness": "-18.00 LUFS", "cue_file_blankskip": 0.0, "cue_file_blank_skipped": false, 
"cue_file_true_peak": 1.004, "cue_file_true_peak_db": "0.03 dBFS"}

You can write tags or make your own wrapper to write playlist annotations instead.
You can also use -r flag to write replaygain tags as well. If your file has the above calculated values (some of them) and replaygain tags - calculation will be skipped - thus no CPU spikes.

In a script it can look like:

enable_autocue_metadata()
%include "/path/to/autocue.cue_file.liq"
settings.autocue.preferred := "cue_file"
settings.autocue.cue_file.fade_in := 0.1  # seconds
settings.autocue.cue_file.fade_out := 2.5  # seconds

# your other code

# crossfade function from above

# your other code

---

If for some reason you want to stick to liq_ values. You need to modify autocue.cue_file.liq from the official repository:
Find and comment out this lines (you can search for them with target_ filter):

...
# settings.autocue.target_cross_duration := settings.autocue.cue_file.fade_out()
...
# log(level=2, label="autocue.cue_file",
# 'Setting `settings.autocue.target_cross_duration` to \
# #{settings.autocue.cue_file.fade_out()} s, from \
# `settings.autocue.cue_file.fade_out`.'
#)
...
# stdlib_print(
# 'Setting `settings.autocue.target_cross_duration` to \
# #{settings.autocue.cue_file.fade_out()} s, from \
# `settings.autocue.cue_file.fade_out`.'
# )
...
### Similar line to the first:
# settings.autocue.target_cross_duration := settings.autocue.cue_file.fade_out()

[fkane]

Thank you @gAlleb - I tried using the new built-in autocue stuff today instead, but even if I pre-generate the tags with the modified cue_file you pointed me toward, LS segfaults quite often on me with no useful error message (LS 2.3.0 on Ubuntu 24.04.1 on a t3.medium EC2 instance.) So it doesn't look like that's an option at the moment :(

I also couldn't get the desired behavior working by using a custom crossfade function with the cross() operator. No matter what I do, if I have fade-in and fade-out times of zero, the first track plays through to completion and then the second track starts right after, regardless of the fade duration specified. What I want is this:

It used to be that specifying a liq_cross_duration for the overlap period, together with zero fade-in and fade-out times, would accomplish that.

In 2.2.5, it also became necessary to add liq_fade_out_delay in order to push out the fade-out of the first track to the end of the crossfade duration.

I thought perhaps now I also have to set liq_fade_in_delay to 0, or maybe liq_cross_start_next to get the next track to start immediately during the transition. But neither seems to have an effect.

What's the right way to just get the transition illustrated above in 2.3.0, where the duration is specified by liq_cross_duration metadata? (Assuming enable_autocue_metadata() is not an option)

[gAlleb]

I tried using the new built-in autocue stuff today instead, but even if I pre-generate the tags with the modified cue_file you pointed me toward

Built-in autocue doesn't read tags from modified cue_file (cue_file_ tags). You have to include and use autocue.cue_file.liq to read them as described above. It it a more segue like transitions that happen on a radio. Which is what we need, right?)
I use it and quite happy with it, some of my files are pretagged, some not. So if you wanna reduce CPU usage you may wanna pretag the files (with replaigain also) and use the cue_file (with cue_file_ tags). It has 2.5 seconds fade_out by default but iit works nice (considering cue_in/cue_out points).

---

What's the right way to just get the transition illustrated above in 2.3.0, where the duration is specified by liq_cross_duration metadata?

Indeed I assume some changes been made, and for me personally all this values is a nightmare)) although I'm crossfade agnostic). liq_cross_duration is a length of buffer:

duration (of type {float}, which defaults to 5.0): Duration (in seconds) of buffered data from the end and start 
of each track that is used to compute the transition between tracks.

override_duration (of type string, which defaults to "liq_cross_duration"): Metadata field which, 
if present and containing a float, overrides the ‘duration’ parameter for current track.

If you want a clean overlap then this could do it, say we have 16 sec. track (defined with liq_cue_in=00.0,liq_cue_out=16.00):

annotate:liq_cue_in=00.0,liq_cue_out=16.00,liq_cross_start_next=11.00,
liq_cross_end_duration=5.0,liq_fade_out_delay=5.0,liq_cross_duration=10.00:/1.flac

With such annotation the cross that will work will be the simple one:

def custom_crossfade(old, new) =
        cross.simple(
                old.source, 
                new.source, 
                fade_in=00.0,
                fade_out=00.0
            )
end
radio = cross(
       # duration, should be not longer than a track length. Other wise it will give a warning like:
       # "End of track reached while buffering next track data, crossfade duration is longer than the track's duration. "
       # "Make sure to adjust the crossfade duration to avoid issues."
        duration=10.0,
        custom_crossfade,
        radio
    )

The above will give us clean overlap of 5 seconds. You can change the duration to 5.0 or liq_cross_duration to 5.0. This won't change the overlap because 5.0 is enough for this overlap computation. But if it's too long - that can cause problems too.

[fkane]

@gAlleb Victory! Thank you!

It seems the root of all evil was specifying a liq_cross_duration equal to the desired transition time in the annotations. Everything started working as expected when I no longer specified liq_cross_duration in the metadata at all, and just passed 30 seconds into the duration parameter for cross() - together with your other suggested annotations. I'll have to do something special for jingles that are shorter than that, but I think that's solvable. I'll just specify a shorter liq_cross_duration for those tracks, as the "broken" behavior of no transitions is actually what I want in that case.

My confusion stems from my copy of the Liquidsoap Book that states pretty clearly that duration / liq_cross_duration does represent the total transition time, and not just the underlying buffer size. I'm not yet sure if my issue arose from liq_cross_duration not being large enough due to the size requirements of that buffer increasing, or if specifying liq_cross_duration at all triggers a bug in 2.3.0.

I'll keep the autocue stuff in my back pocket for now; I was assuming the integrated autocue stuff supported tags so that is probably why I segfaulted. Still, it makes me nervous to know my server will crash if I miss tagging any of my tracks or jingles - and a larger instance type with more memory would be cost prohibitive.

[toots]

Glad you made it work.

cross and crossfade were reworked and simplified in light of the new autocue process.

We do need to update the book, it's pretty high on our todo.

Actually, the repo is here: https://github.com/savonet/book and anyone who wants to contribute is welcome to!