Menu
▾
▴
#99 Replace or supplement use of wget with (lib)curl
From Chris:
Long term it might be nice to link to something like libcurl and
bypass wget; at least for shoutcast support. The reason is that when
you connect to shoutcast servers, your supposed to send a
"Ice-MetaData:
1" in your HTTP request and then it will start including song
name/artist metadata in the stream. wget won't let us do that as far
as
I can tell.
Then we could parse and print this data to the screen. Not sure if
libmad has hooks to detect invalid frame and let us jump in to see if
its metadata or not.
If someone is interested, here is a web page that talks about parsing
the metadata. http://www.codeproject.com/cs/media/SHOUTcastRipper.asp
wget has a generic --header option, which we can use as wget --header="Ice-MetaData: 1".
I am testing with http://81.173.3.133:8082 (which is a shoutcasted mp3 stream).
This can be played with "play -t mp3 http://81.173.3.133:8082" (using 14.4.1)
which makes it skip over the
ICY 200 OK
icy-notice1: ...
response and plays the subsequent mp3 stream fine.
Downloading this stream with
wget -O stream.mp3 -v -S --save-headers http://81.173.3.133:8082
I see that some ICE info actually is there:
ICY 200 OK^M
icy-notice1:<BR>This stream requires <a href="http://www.winamp.com/">Winamp</a>
<BR>^M
icy-notice2:SHOUTcast Distributed Network Audio Server/Linux v1.9.8<BR>^M
icy-name:SublimeFM^M
icy-genre:Jazz^M
icy-url:http://www.sublimefm.nl^M
content-type:audio/mpeg^M
icy-pub:1^M
icy-br:128^M
Specifically, this is the "Sublime" radio station, playing "Jazz".
Is this the metadata you were after? It seems that this server
does send them, even without the "Ice-MetaData: 1" header.
Trying again with --header="Ice-MetaData: 1"
added to the wget call, I don't see any difference.
What exactly is the Ice-MetaData supposed to do?
Make the server respond with metadata even if it wouldn't by default?
Anyway, I believe there is other motivation to get rid of wget.
Some systems (for example OpenBSD and MacOSX) do come with ftp(1)
in their base install that can write to stdout with "ftp -o - ...".
That makes wget an unnecessary dependency. In fact, the OpenBSD
port of SoX patches the source exactly in this way - replacing
the wget(1) call with a ftp(1) call.
(Linux also has an ftp(1) binary, but it cannot write to stdout AFAIK.)
If we want to replace the network functionality with libcurl(3),
we have to have libcurl installed; that means curl(1) will be around.
Isn't it easier then to just use curl(1), which I believe can do whatever
ftp(1) or wget(1) can do as far as downloading a given remote file goes?
Currently, all inputs are opened uniformly: with formats.c:xfopen(),
which returns FILE* whether the input is a local file, a pipe or a remote file.
That needs popen(). So would it also be a motivation to support systems that
do not have popen()? (What systems are those?) We want to keep the uniform
threatments of all inputs as FILE*'s, right?