Crossfade/normalize

[SpeedyCharly]

I've posted the same question on Azuracast github, but no one seems able to respond;

I've taken to studying the Liquidsoap logs to familiarize myself with Azura's operations. Here is a piece that comes up often in my case, and I don't quite understand why...

2021/11/25 22:24:25 [next_song:3] Prepared "/var/azuracast/stations/radio_des_festivals/media/Country Franco/La Cabane À Sucre - Viateur Caron (New).mp3" (RID 5).
2021/11/25 22:24:25 [cue_next_song:3] Cueing in...
2021/11/25 22:24:25 [crossfade_0:3] Analysis: -80.616358dB / -24.460022dB (1.44s / 1.44s)
2021/11/25 22:24:25 [crossfade_0:3] new >= old + margin, old <= medium and new <= high.
2021/11/25 22:24:25 [crossfade_0:3] Do not fade if it's already very low.
2021/11/25 22:24:25 [crossfade_0:3] Transition: crossed, no fade.
2021/11/25 22:24:25 [lang:3] AzuraCast Raw Response: annotate:title="Le temps qu'il nous reste",artist="Claude Martel",duration="252.00",song_id="b895d5adb8468a0d7b55b7d91646992b",media_id="8587",liq_amplify="0.00dB",playlist_id="2":/var/azuracast/stations/radio_des_festivals/media/Country Franco/10 Le temps quil nous reste.mp3

All of my playlists are normalized to the same target volume with MP3 Gain and, Normalize is also set in my AzuraCast config. Therefore, such occurrences shouldn't exist. From the volume analysis above, it seems that Liquidsoap doesn't recognize the MP3 Gain metadata? If so, would another normalizer be a better choice?

As an aside, one more question; does Liqudsoap natively truncate leading/ending silence on media as part of the crossfade process? I don't see a switch [as in SamBroadcaster] to turn this on or off.

[Russsgithub]

@SpeedyCharly

Hello,

As far as I'm aware crossfade will calculate the levels at the time of the crossfade. So at 1.44s from the end of the track the level is -8.616358dB and the incoming track starts at -24.460022dB . Replay gain uses RMS or LUFS to calculate the average level for the whole track, so say -14dB RMS over the whole track will probably have values over and under -14dB, which is what the crossfade fuction finds and decides what to do in the transtion, in this case not crossfade.

I think the normalizer is also RMS so will take into account a relatively long window.

Replay gain:-
liq can use "liq_amplify" metadata key to override an amplify function. I'm not sure how azurcast deals with this, though I see the metadata in the annotate line above set at 0.0, so it is being set though maybe not correctly.

I dont't think liq truncates silence in the crossfade process, though it does have things like blank.eat blank.strip blank.detect functions to deal with silence in a file.

The docs for liq are very good

https://www.liquidsoap.info/doc-dev/reference.html

as is the book

http://www.liquidsoap.info/book/book.pdf

Russ

[SpeedyCharly]

Sorry to say, but that doesn't answer the question. My media files are normalized prior to uploading to the server; Liquid should therefore see them as roughly equal in volume and perform a full cross & fade every time. Why isn't it happening as expected? The image below shows what a proper crossfade should look like;

[Most should recognize the source of that screenshot]

Note the many customizing options that are absent in LS where the only control is over duration. Also note from the shape of the graphs that ending and leading silences have been truncated from the files to avoid fading to and from dead silence; how does LS solve that? Further, there is an option to skip crossfade altogether on short media as it most often leads to information loss at the listening end.

I'm not suggesting that you reverse-engineer the app in question; but we definitely need more 'user-friendly' control over the crossfade process...

BTW; the references you are citing are written for Linuxian techno geeks and are mostly gibberish to a regular Joe trying to run a hobby station...

[toots]

#2128 (comment)