Your editor is fortunate enough to live in a town with an excellent radio
station. It is a public station, funded (mostly) by its listeners and
operated (mostly) by volunteers. It is a nearly 30-year-old application of
many free software concepts to the airwaves; appropriately, its name is
KGNU. For those who do not live in the area,
or who find the reception problematic here on the edge of the mountains,
KGNU makes a set of streams available over the net; there is even an Ogg
stream.
KGNU airs an incredible variety of music and public affairs programming;
much of what is heard there is available nowhere else in the area.
Unfortunately, some of the most interesting programs are not broadcast at
times when it is convenient for your editor to listen to them. Some of the
best music is late at night, and the public affairs programs
broadcast during the day tends to be incompatible with the need to write
LWN articles.
As a result, your editor has a strong desire to record shows of interest
and listen to them at a later time. This is, of course, a classic, legal
exercise of fair use rights. For years, this activity has been performed
using a DAT deck, which will happily record a three-hour show without
breaks. Unfortunately, this solution (1) requires somebody to push
the "record" button at the right time, and (2) depends on the continued
operation of an aging piece of audio equipment whose reliability was not
the greatest even when it was new. It would make a lot of sense to,
instead, simply record the audio stream from the net. Recording could be
automated, and the result could be moved to a portable player for
convenient listening.
It is not surprising that proprietary players for streaming media lack a
"record" option. But, one would think, free players would provide such an
obvious bit of functionality. As it turns out, however, most of the free
players which can tune in network streams also lack recording capability.
Whether this omission is simply a matter of other development priorities
coming first or is, instead, a capitulation to the entertainment industry
is not clear. Regardless of why, a Linux user who has fired up totem,
amarok, or xmms to play an audio stream will not readily find a "record"
option there.
There are, however, a number of options available for those who would
record audio streams on a Linux system. Here are a few that your editor
has found.
Recording through the sound system
Audio streams passing through the ALSA sound system are generally available
to applications via a capture interface. So, in fact, almost any free
recording application can be used to grab the stream as it passes
through the kernel. A simple example can be made with arecord:
arecord -f cd -d 7200 stream.wav
This command will record a stream in WAV format, automatically stopping
after two hours. Other recording applications (ecasound, ardour, etc.) can
also be used.
There are some downsides to this approach. Recording in this way occupies
the sound system, making it impossible to listen to anything else. Changes
to mixer settings can affect the recording. Depending on the sound
hardware in use, the system might have trouble simultaneously playing an
audio stream and recording it. And, regardless of other problems, this
solution involves several transformations to the audio stream between the
network interface and its eventual resting place on the disk. Your editor
would rather store the stream as it was received from the source.
ogg123
If the stream of interest is in the Ogg Vorbis format, the ogg123 tool
can be used to capture it. A command like this will do:
ogg123 -d wav -f stream.wav http://stream-url
With a second option (-d oss), ogg123 can simultaneously
play the stream and record it to the disk file. There is an option for
specifying the duration of the recording (useful for grabbing shows via a
cron job), but it did not work properly on your editor's system.
For whatever reason, ogg123 lacks the ability to save an Ogg
stream directly to disk - it must convert it to the uncompressed WAV format
first. One can always re-encode the stream - at recording time using a
pipe, even - but putting an audio stream through a second round of lossy
encoding cannot do it any good. It would be much nicer to just save the
stream directly to disk.
wget
If something exists on the net, there is a way to tell wget to
fetch it. Audio streams are no exception; running:
wget http://stream-url
will do the trick. No transformations will be applied to the stream - it
will be saved as received from the source, which is as it should be. On
the other hand, wget is not really designed with streams in mind.
In particular, it lacks an option for setting the recording period, making
it a bit harder to run in an automated mode - though a couple lines of
shell scripting suffice to take care of that problem.
mplayer
While most streaming media players lack a record option, mplayer is a notable
exception. A stream can be recorded with a command like:
mplayer -dumpstream -dumpfile stream.ogg http://stream-url
Of course, streams in just about any format can be recorded in this
manner; mplayer will save the stream as it receives it.
The list of options understood by mplayer easily qualifies as one
of the longest for any application anywhere on the planet. A definitive
study could require some months, but, as far as your editor can tell, none
of those options tell mplayer how long it should run. As with
wget, that omission makes mplayer a little harder to use
in an automated mode.
Some distributions are more enthusiastic about including mplayer
than others. Packages for almost any distribution are readily available,
however, to those who search for them.
streamripper
The definitive tool for capturing streams may well be streamripper. This utility
will grab a stream and store it to disk, possibly splitting it into
separate tracks as it goes. It can function as a relay, making it possible
to listen to a stream as it is being recorded - or to distribute a stream
around an internal network. In its simplest form, streamripper is
run as:
streamripper http://stream-url
Options exist to limit recording time, control separation into tracks,
establish a stream relay, and automatically discard advertisements. There
are graphical frontends for GNOME (streamtuner) and KDE (KStreamRipper).
There is also an amarok
plugin available.
To conclude
From your editor's point of view, streamripper is the right tool
for this job. It is the only one which was designed for the purpose of
capturing audio streams in their original format. In a pinch,
wget will do the job, as will mplayer. Employing a huge
tool like mplayer for this purpose feels somewhat like using a
nail gun to hang a calendar, however.
For now, we are lucky in that there are quite a few high-quality streams
which can be time-shifted and enjoyed in this manner. Unfortunately, the
future looks to be made up of DRM-encrusted streams and no access for users
of free software. No fair use rights. If we want to live in a world where
broadcast streams are accessible with free tools and developers of stream
players are not afraid to add "record" buttons, we need to ensure that the
legal climate does not become more hostile than it is already. Otherwise,
finding a good stream capture tool could become much harder than it is
today.
(
Log in to post comments)