NORMALISATION AND CROSSFADING

[glenbuck1]

Hi,

I have the following entries in a 2.3.x script file:

set("protocol.ffmpeg.replaygain",true)
enable_replaygain_metadata()
enable_autocue_metadata()

#playlists
jingles=playlist(mode="random", "/home/radio/jingles")
Sixties=playlist(mode="random", "/home/radio/music/decades/60s70s80s/1960s")
#FlashbackYears is an hour long
FlashbackYears=playlist(mode="normal", "/home/radio/playlists/FlashbackYears.pls")

#scheduling
Tuesday=mksafe(switch(track_sensitive=false, [({0h-21h}, Sixties), ({21h-22h}, FlashbackYears), ({22h-0h}, Sixties)]))

radio=mksafe(switch(track_sensitive=false, [({2w}, Tuesday)]))
radio=mksafe(crossfade(rotate(weights=[2, 1], [radio, jingles])))

The jingles and Sixties playlists behave as I want but when transitioning to FlashbackYears, it takes 1.5 minutes before it starts playing.

Am I right in assuming that this is happening due to calculating the regain level and, if so, how should I fix it, please?

Thanks for any help.

Richard Bartholomew

[gAlleb]

Hi @glenbuck1
First I wouldn't recommend using both autocue and replaygain as they both normalize loudness. So you're doing the same thing twice at some sort.

Default autocue LUFS target is -14.0 which can be easily changed to -18.0 via settings.autocue.internal.lufs_target

settings.autocue.internal.lufs_target := -18.0

Next thing you need to do is to tell autocue use replaygain metadata if you have any

settings.autocue.amplify_behavior := "keep"

Now add enable_autocue_metadata() so at the top of your script you'll have

settings.autocue.amplify_behavior := "keep"
settings.autocue.internal.lufs_target := -18.0
enable_autocue_metadata()

And you don't need replaygain anymore.

---

Am I right in assuming that this is happening due to calculating the regain level and, if so, how should I fix it, please?

No, because the first file that is due to play from the FlashbackYears playlist is calculated when your start your LS instance.

---

Second, logic applied to your playlists is a bit odd. Why do you need that separate Tuesday switch. And why do you use track_sensitive=false? You say, that your playlist is an "hour long" playlist, so why not keep track_sensitive=true to avoid abrupt transitions?

I would do it this way:

settings.autocue.amplify_behavior := "keep"
settings.autocue.internal.lufs_target := -18.0
enable_autocue_metadata()

#playlists
jingles=playlist(mode="random", "/home/radio/jingles")
Sixties=playlist(mode="random", "/home/radio/music/decades/60s70s80s/1960s")

#FlashbackYears is an hour long, we add loop=false so it will stop playing after it is through
FlashbackYears=playlist(mode="normal", loop=false, "/home/radio/playlists/FlashbackYears.pls")

# We reload FlashbackYears playlist every Tuesday at 20:00 before it's due to play

thread.when(predicate.activates({ 2w and 20h00m00s }), fun() -> FlashbackYears.reload())

#scheduling 
# We play FlashbackYears only on Tuesdays from 21 to 22 (it can start a little bit late and stop a little bit late 
# as we have track_sensitive=true, assuming, as you say, it's one hour long, but we will have nice transitions). 
# At other times Sixties will be played.

radio=switch(track_sensitive=true, [({2w and 21h-22h}, FlashbackYears), ({true}, Sixties)])

radio=rotate(weights=[2, 1], [radio, jingles])
radio=crossfade(radio)
radio=mksafe(radio)

---

[glenbuck1]

Hi, Stefan

Thanks very much for your help and you have fixed my problem of the 1.5 minute delay before FlashbackYears begins...now, if I could only get cue sheets to work the way I want them to (ie so that the voice breaks in the recording were not clipped off before they had actually completed), I'd be set fair!

Second, logic applied to your playlists is a bit odd. Why do you need that separate Tuesday switch.

As a bit of background and clarification.

Our station is, primarily, one of live shows and we use Liquidsoap to provide a fallback source if one of our presenters has internet issues so that we don't have dead air. As well as this, we use Liquidsoap to play a few pre-recorded shows each week and FlashbackYears is one of these. Therefore, I should have been more precise when I said that it lasted for an hour; yes, it does but it is a single file.

Consequently, we have a schedule for each day of the week which I thought would be best served by coding it the way I did...plus it was easier for me to get my head around it!

why do you use track_sensitive=false?

I accept that this means that tracks may cut off in the middle and will be less smooth; however, as our shows are advertised as beginning at specific times, we don't want the start of a pre-recorded show to be late by, potentially, several minutes because a long track had just begun before one of our pre-recorded shows and, therefore, the end of the show would be lost as the live show following it would start on time.

I did notice one downside to this this morning...the song which was cut short before FlashbackYears began, was played out from the cut-off point once FlashbackYears had ended!

Thanks once again for your very helpful response.

Richard Bartholomew

[gAlleb]

I did notice one downside to this this morning...the song which was cut short before FlashbackYears began, was played out from the cut-off point once FlashbackYears had ended!

If you didn't have such strict rule to start next program after FlashbackYears you could use radio = fallback.skip(FlashbackYears, fallback=radio) instead of your current fallback.

or

FlashbackYears_fallback = fallback(
  track_sensitive=false,
  [
    switch(
      id="FlashbackYears_switch",
      [(predicate.once({ 2w21h00m00s }), FlashbackYears)]
    )
  ]
)
# When FlashbackYears_fallback source becomes active:
# Skip current track, play FlashbackYears_fallback, continue with new track
radio = fallback.skip(news, fallback=radio)

But this will not satisfy it. Alternatively you can skip Sixties playlist while FlashbackYears are played.
For examaple, FlashbackYears kicked in and is on air - while it's playing you can skip the Sixties source so the track that has been playing prior will be skipped in the background at 21:10:

thread.when(predicate.activates({ 2w21h10m00s }), fun() -> source.skip(Sixties))

[glenbuck1]

Hi,

Thanks for the additional comments.

I've been playing around with the lufs level for autocue since the level of the Liquidsoap stream is far lower than when any of our presenters connect for a live show. So far, I've gone up to a value of -2.0 but am not noticing a significant difference from, say, the default of -14.0. I haven't had the courage of going to a + value because of the likelihood of introducing distortion etc. Is there something else I've missed that would raise the overall volume, please, or do I need to revisit RegainPlay?

Thanks for further time.

[gAlleb]

If your tracks have replaygain tags - their LUFS target from the tags will be applied no matter of your settings. To control your LUFS target and change it if you have pretagged file - you should remove settings.autocue.amplify_behavior := "keep" line. Then you can change settings.autocue.internal.lufs_target := -18.0 (value is float - meaning you must have .0 at the end). I wouldn't recommend anything higher than -12 LUFS.

Usual radio normalization is between -23 and -18 (-18 is replaygain2 and what is used if you use replaygain protocol in Liquidsoap). Some radios make their stations louder. e.g. some streaming service targets:
Spotify: -14 LUFS integrated.
YouTube: -14 LUFS integrated.
Apple Music: -16 LUFS integrated.

And last and most important bit. This stuff won't work if you don't apply normalization to a source.

Before your crossfade line/function you have to have this one:

# your playlist schedule and so on

radio = amplify(1., override="liq_amplify", radio)

# then crossfade

radio = crossfade(radio)

# your live dj `input.harbour` and fallback.
# DJ's live input should be after `crossfade` and `amplify`. Ideally to have even sound - 
# dj's should apply the same normalization

[glenbuck1]

Thanks, Stefan

I have already removed settings.autocue.amplify_behavior := "keep" as I thought the behaviour you described would be what happened and our library is many thousands in size and I don't know how many have a regain value set.

Thanks for your recommendation and it's interesting to know what the likes of Spotify use!

I'll keep an eye on all things (including our presenter setup) to see how things stand.

[glenbuck1]

Since experimenting with this further, we have decided to take a different approach to our compression because we have been getting major level fluctuations between our live presenters and the audio output from Liquidsoap. Therefore, we are now looking into applying Liquidsoap compression from the server to our live shows as well.

However, this raises another issue which I'll create a new request for!

Thanks for the help given on this.