I like to listen to radio stations on the Internet. Usually these are European stations in time zone UTC+1, and I live in timezone UTC-4. In winter this is 5 hours time difference, in summer 6 hours.

It is just not nice to listen to the radio at 8 pm, and then hear the night program of 2 am.

Is there a possibility somehow to buffer these 6 hours of audio, so that I hear everything 6 hours later? I think it would involve writing the stream to disk, and pick up the stream from disk 6 hours later.

It seems that matters are complicated by the variety of different streams and players that are being used. I could easily identify these:

rtsp://realorf.conova.com/salzburg.ra
mms://stream2.orf.at/radio_tirol
http://212.34.174.107:8010/listen.pls

And I would not be surprised if some .wmv is used as well.

If no linux tool exists for this, I might be interested in some general information as well, like "you'd have to write a C-program which does that and that."

jlinkels

Vlc and mplayer are probably the best video/audio tools available for average and advanced users. This can be a good start.

It is amazing how much it helps when you read the manual now and then!

mplayer provides a way for writing the stream to disk. I have put the command in a script, and that looks like this:

The -novideo option really is important. Otherwise mplayer assumes during playback this is a video stream, no matter how much you tell mplayer to use an audio decoder.

I have put this script file in a cron job, which starts to record my favorite programs at a certain time of the day. I record the pid of the process, so some time later, using another cron job I can stop the recording. Four hours of recording from this station yield a file of approximately 130-140 MB, which is quite reasonable.

With again another cron job I start mplayer in playback mode to start the rebroadcast of the recorded file.

The playback of the file can already start when the file is still being recorded, so time shift smaller than total recording time are also possible.

jlinkels

I use a similar process for recording streaming audio:

mplayer -cache 128 -vc dummy -vo null -ao pcm: file=raw.wav http://38.116.132.9/JackFM?MSWMExt=.asf


It works very well, however, I take the extra step in converting to .mp3 format and file size is reduce by 1/3 or more depending on the bit-rate you compress too:


lame -b 32 -m m -f --tt "Broadcast_stream" --ta "Jack_FM" ~/raw.wav ~/jack_fm.mp3

KC

Funny that I was not the only one trying to do this.

I did not feel the need for compressing the stream again, at under 30 MB/hour I don't worry too much about file size.

If you experience that audio quality is decreased after compressing again, do not compress. If you re-encode an already encoded audio stream, this is called transcoding, can seriously decrease audio quality, even if the bitrate would normally provide acceptable audio.

That is because during the first compression, certain parts (which we cannot hear anyway) are removed from the audio information. However, if you encode again with a different algorithm, the algorithm expects full uncompressed audio, not already crippled audio. Lame doesn't warn about this, because it is technically possible to feed an encoder with an already encoded stream.

You can compare this with the editing of a picture in Gimp. If you edit a RAW image, you can easily change brightness, contrast or color balance. If you try to do this with a highly compressed JPG image, results are far worse. This is because in the orginal JPG, all information which was not necessary for showing a nice picture to the human eye was removed. The picture is nice, but doesn't contain any information anymore which allows you to change some parameters while the picture is still being percepted as nice by the human eye.

jlinkels