Logging Output with LiquidSoap
In ye olden days, logging of station output used to occasionally involve a stack of VCRs, long play tapes and presenters tasked with swapping out tapes. Nowadays, everything is done on a computer.
It can still be a painful or expensive experience. However, with a bit of Linux knowledge you can do it for “free”. What’s more, you can throw in some silence detection as well!
To start off, you’ll need a Linux machine with an appropriate soundcard installed. If you need some tips on balanced soundcards, why not check out this blog post. Something running Ubuntu or Debian plus an ALSA compatible soundcard is a good place to start.
You’ll need to now install LiquidSoap. On Debian and Ubuntu systems, this is as simple as running the apt-get install liquidsoap command as root (sudo on Ubuntu systems).
Once the installation is finished, you’ll need to create a LiquidSoap configuration file for logging. Something like the following should work for logging:
set(‘log.file.path’, ‘/tmp/logging.log’)
# Action on silence dection
def silence_handler()
system(“/home/user/some_command.sh”);
end
# Setup the stream and silence detection
stream = mksafe(input.alsa())
stream = on_blank(silence_handler, stream)
# Log to disk
output.file.wav(
‘/path/to/logger/station_name-%Y-%m-%d-%H.wav’,
reopen_when={0m0s},
stream)
You can save this file as log_stream.liq in the home directory of the user this will be running as. But before you do, remember to change /path/to/logger/ to something sensible.
What this does is pulls audio from the soundcard using ALSA. It then log it to disk in uncompressed WAVE format as station_name_2015-31-01-15.wav. At the top of every hour (00:00), it will start a new file.
It will also run /home/user/some_command.sh when a silence is detected. This bit is optional but can be used to trigger e-mail alerts when things go off air.
To run this, it’s as simple as calling liqudsoap log_stream.liq & and letting it run. If this doesn’t work, the user you’re running as might need to be a member of the audio group to access the soundcard.
Either way, checking the contents of /tmp/logging.log will tell you what went wrong.
Making it fire up on launch is as simple as adding the above line to /etc/rc.local just before the end line. Another option is to add it as an @reboot entry to your crontab.
Anyway, while our script does log audio and breaks it into hour long chunks, logging in an uncompressed format will burn through your disk space in no time. That’s why we need a script with the following contents (remembering to change the paths):
#!/bin/bash
FILE_NAME=`date +%Y-%m-%d-%H -d “1 Hour Ago“`
lame -b 256 –cbr /path/to/logger/station_name-$FILE_NAME.wav/path/to/logger/station_name-$FILE_NAME.mp3
rm /path/to/logger/station_name-$FILE_NAME.wav
When run every hour (at a few minutes past), this will convert the WAV file to a 256kbps MP3 file and delete the original file. Changing the bitrate is as simple as changing 256 to whatever you desire (e.g. 64, 128, 512).
You could get a bit more clever and re-encode older files after so many days. However, the disk space saved plus artifacts from re-encoding audio files tends to make the effort worthless.
That does bring us round to another issue though. Deleting the old files. That’s as simple as setting up a cron job to run the following every day:
find /path/to/logger/ -name “*.mp3” -mtime +45 -exec rm -r {} \;
This deletes files any files in the /path/to/logger/ directory (which you’ll need to change to match your setup) over 45 days old. That’s usually enough to exceed regulator requirements (though it’s up to you to check this out!).
