capturing CBC Radio from an internet stream

[Eric Battersby]

On Mon, 3 Mar 2008, D. Hugh Redelmeier wrote:

> I used curl.  Here's the script I used:
...
>    curl --max-time 3660 -o $DATE.ogg
>    http://$OGGTRIAL:80/cbcr1-toronto.ogg

This is good to know.

> Originally this worked fine.  Perhaps a year later, it seemed to often
> stop about 30 or 40 minutes in.  Which was annoying.

Did it hang or stop?
If it stopped, why not loop the code to continue capturing, as
a backup?

> | I got a 36s segment OGG file.  It appears that some history is captured
> | in the stream also.
>
> What do you mean by "history"?

I ran the capture for 15s real time, but got 36s of data.
If I immediately rerun the capture, the first 20s would be duplicated.

> | Could you break your shows into segments shorter than 1h, if 1h
> | is a problem?
>
> Sure, but what do you do with the seams?  I don't like
> discontinuities.

Ideally, no, but there may be no choice.  I did notice that the OGG
files seem to have time codes built in.  Perhaps, there are some OGG
file editors that can recombine them.

I did some testing of creating 5m MP3 files from WMA files,
from CBC's "The Debaters" (a great show).
The discontinuities consisted of the occassional 1 word repeat,
which didn't bother me.

> | I hadn't heard of 'mmsrip'.  That seems to be a good tool.
> | I haven't done much capturing, but I have used VLC (gui based), or this:
> |
> |    mplayer.exe -dumpstream mms://somehost.com/somedirectory/somefile.wmv
>
> Is this under DOS or MS Windows?  What's this ".exe" thing?

I think I copied that from somewhere else, but I ran it under
Linux, so that should be:

   mplayer -dumpstream mms://...

> | Why rely on alternate timezones which are arbitrary, instead of
> | a general solution?
> | Why not set up a daemon to capture the stream every N minutes,
> | along with some cleanup routines?
>
> You mean capture the radio all the time?  That seems a bit rude:
> wasting CBC's bandwidth for no good reason.  It would waste disk space
> too unless I threw it away regularly (which proves that the bandwidth
> was wasted).

That is a good point, but how wasteful is it really?
I mean large corporations and their servers must expect lots
of "hits" to their live feed,
with many people continuously listening to their station.

It "wastes" disk space, but you just remove files after N days.

The other choice is to record live from air, direct to digital.
My MP3 player can do that, and save the result as WAV, but
this is not so convenient as I have to leave it on before
the show I want.

> | Why bother with WMA format at all?  I had a player from several
> | years ago that played WMA files.  It does not play today's WMA files.
> | Convert it to MP3, so it will work in ALL MP3 players.
> | I know, the quality suffers slightly converting lossy to lossy,
> | but this is not high fidelity music we are talking about.
>
> The sound is bad enough.  I don't wish to make it worse.  So I would
> have to use a high mp3 bitrate.  Then I would waste disk space.  And
> waste flash memory in the player.
>
> I admit that this is theory.  I haven't tested.  But there is only one
> way for sound to come out through a lossy codec: worse.

I listened to the MP3 files converted from WMA and they were not bad.
The high bit rate was not needed; 64 kbps was fine.

> | I tried this:
> |
> |   $ ffmpeg -i cbc01.wma  cbc01.mp3
> |   $ file cbc01.mp3
> |   cbc01.mp3: MPEG ADTS, layer II, v1,  64 kBits, 44.1 kHz, Monaural
> |
> | Unfortunately, it produced an MP2 file, not MP3.
> | I am not sure what is wrong.  MP2 is similar,
> | but may not be supported on all MP3 players.
>
> I don't know what all the darned codecs are.  ffmpeg does have a flag
> (-formats) to print a list of supported codecs (the list depends on
> how it was compiled, for example).  It also has a flag (-acodec) to
> specify the audio codec to use.  I'd say RTFM but, in the case of
> ffmpeg, that would be very cruel.

I have the '--enable-libmp3lame' flag, but '-acodec mp3' does not work.
ie:
   does     work:  ffmpeg -i tmp1.ogg -acodec mp2 tmp1.mp3
   does not work:  ffmpeg -i tmp1.ogg -acodec mp3 tmp1.mp3

> | Also, I don't like MP3 files longer than 10m because
> | many MP3 players do not have a "very very fast-forward", nor
> | a rewind into the end of the previous track.
>
> I've yet to deal with this.  My preferred players have an option to
> resume where they left off.  This is mostly good enough.

"Resume" is a fairly common standard.
The problem is with clumsy fingers or being jostled.
You want to rewind or fast forward a little, so you try to hold the
">>" or "<<" button, but you accidently tap the button instead.  Now
you at the start of a track, instead of the middle.
Getting back to where you were can be time consuming.

> I intend to try RockBox.  I have even bought a Sandisk e2xx player to
> run it.  I intend to hack it to do what I want.  But I haven't even
> installed RockBox yet.

Why is this better than using a USM MP3 player, if you have a choice?
Are you hacking it get it to work or to do something more?

> Players seem to get worse, not better.  I don't use my ZenV much.  It
> doesn't think that it holds files, it thinks it holds music.  So
> instead of UMS (USB Mass Storage -- looks like a disk), it has another
> protocol (perhaps MTP / PaysForSure).  So you navigate through albums
> and artists and other things for which I have not internalized a model.
> I put stuff on it using gnomad2.  I had to hack on that to get it to
> work on x86_64 (so I now have check-in rights on the development tree).
>
> My Samsung devices are UMS because I found firmware for other places
> (Singapore?) that did this.  The stock North American firmware is MTP
> / PaysForSure.  Grrr.  I think that the UMS firmware supports ogg
> vorbis, but I don't know for sure.

I don't bother with those "pay" DRM players.
I am now using an MPIO ML200 (2GB) player and am fairly satisfied
with it.  I copy MP3 files thru the USB port.
Yes, some older players even had more features.
The best one I had was the RioVolt SP250 MP3/CD player.


> To get PaysForSure branding, Microsoft required player manufacturers
> to drop ogg vorbis support.  When this was pointed out to anti-trust
> folks, Microsoft said "oh, we didn't really mean it".  But the damage was
> done -- I don't know of any PaysForSure licensees that now support ogg
> vorbis.  If I were a licensee, I would not trust that MS actually
> meant their "we didn't really mean it".

Are you using PlayForSure or other commercial service?
Do you need that?

--
Eric Battersby.
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists