Feature Requests item #1713308, was opened at 2007-05-05 02:12 Message generated for change (Comment added) made by janstary You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=360706&aid=1713308&group_id=10706
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: robs (robs) Assigned to: Nobody/Anonymous (nobody) Summary: Replace or supplement use of wget with (lib)curl Initial Comment: 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 ---------------------------------------------------------------------- Comment By: Jan Starý (janstary) Date: 2013-02-04 04:50 Message: 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? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=360706&aid=1713308&group_id=10706 ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan _______________________________________________ SoX-devel mailing list SoX-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sox-devel
