Cutting Through The Crap

So, MUS 15 at UCSD (and a lot of other courses offered by the Music department) makes tracks relevant to the course available through a web application called DAR (short for Digital Audio Reserves). It has the potential to be really nifty, but as you’ve already guessed it’s actually a huge pain. Check out the FAQ. If you don’t like Real Player (and it’s likely that you don’t), it’s possible to play the music using VLC or MPlayer, but I wanted more than that, since I can’t always be on the internet, and streams are a pain to deal with in general.

(click for bigger)

First, let’s have a look at the links on the page you see above. The link for “Spectacle to Refute All Judgements” is http://earth.ucsd.edu:8080/ramgen/darp/MUD8/MUD87523_1.mp3, and the file itself looks like:

rtsp://132.239.2.41:554/darp/MUD8/MUD87523_1.mp3
 

The “mp3” file is an imposter, containing the location of an rtsp stream. As I’ve already mentioned, MPlayer can handle the stream, and I found online that the -dumpstream argument will dump the stream to disk, so running mplayer -dumpstream rtsp://132.239.2.41:554/darp/MUD8/MUD87523_1.mp3 results in a 5.2MB file.

This is where we start to get ambitious, and run into two different problems. First, the file really is a dump of the stream, so it still requires a player that supports Real formats to play. Second, scripting mplayer by using mplayer -dumpstream `wget http://earth.ucsd.edu:8080/ramgen/darp/MUD8/MUD87523_1.mp3 -O-` results in some strange output. After looking around unsuccessfully for a solution to the first problem, I emailed my TA. While waiting for a response, I looked at the second problem, because it didn’t seem to make sense.

The normal output from mplayer looks something like this:

numist@spinnaker:Users/numist/tmp/dar$ mplayer -dumpstream rtsp://132.239.2.41:
554/darp/MUD8/MUD87523_1.mp3
MPlayer 1.0rc2-4.0.1 (C) 2000-2007 MPlayer Team
CPU: Genuine Intel(R) CPU           T2500  @ 2.00GHz (Family: 6, Model: 14, Ste
pping: 8)
CPUflags:  MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compiled for x86 CPU with extensions: MMX MMX2 SSE SSE2
115 audio & 237 video codecs

Playing rtsp://132.239.2.41:554/darp/MUD8/MUD87523_1.mp3.
Resolving 132.239.2.41 for AF_INET6...
Couldn't resolve name for AF_INET6: 132.239.2.41
Connecting to server 132.239.2.41[132.239.2.41]: 554...
Cache size set to 640 KBytes
realrtsp: Stream EOF detected
Core dumped ;)

Exiting... (End of file)

“Core dumped ;)”, cute.
The output from mplayer using wget to fill in the rtsp link looks like this:

numist@spinnaker:Users/numist/tmp/dar$ mplayer -dumpstream `wget http://earth.u
csd.edu:8080/ramgen/darp/MUD8/MUD87523_1.mp3 -O-`
--2008-06-09 20:53:32--  http://earth.ucsd.edu:8080/ramgen/darp/MUD8/MUD87523_1.mp3
Resolving earth.ucsd.edu... 132.239.2.41
Connecting to earth.ucsd.edu|132.239.2.41|:8080... connected.
HTTP request sent, awaiting response... 200 OK
Length: 50 /x-pn-realaudio
Saving to: `STDOUT'

100%[======================================>] 50          --.-K/s   in 0s      

2008-06-09 20:53:32 (483 KB/s) - `-' saved [50/50]

MPlayer 1.0rc2-4.0.1 (C) 2000-2007 MPlayer Team
CPU: Genuine Intel(R) CPU           T2500  @ 2.00GHz (Family: 6, Model: 14, Ste
pping: 8)
CPUflags:  MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compiled for x86 CPU with extensions: MMX MMX2 SSE SSE2
115 audio & 237 video codecs

.laying rtsp://132.239.2.41:554/darp/MUD8/MUD87523_1.mp3
Resolving 132.239.2.41 for AF_INET6...
Couldn't resolve name for AF_INET6: 132.239.2.41
Connecting to server 132.239.2.41[132.239.2.41]: 554...
realrtsp: got message from server:
23;This server is not configured to play the data type you requested. Please co
ntact the Real Server Administrator for assistance.
rtsp_session: session can not be established.
Resolving 132.239.2.41 for AF_INET6...
Couldn't resolve name for AF_INET6: 132.239.2.41
Connecting to server 132.239.2.41[132.239.2.41]: 554...
http_read_response read 0 (i.e. EOF).
No stream found to handle url rtsp://132.239.2.41:554/darp/MUD8/MUD87523_1.mp3


Exiting... (End of file)

There is some weird output going on here, and it’s not creating any files on disk.
I spent a while staring at this until I noticed the line .laying rtsp://132.239.2.41:554/darp/MUD8/MUD87523_1.mp3. That period at the beginning is not a typo, it’s what gives away the problem: the file that wget grabs uses DOS line endings. Of course! Stripping the \r fixes the problem and allows mplayer to get the stream without you having to save the “.mp3” file to disk and grabbing the rtsp link inside by hand.

At this point, my music TA emailed me back, and said something astonishing:

Well, you can download the stream container file (the suspicious 1k mp3 files that are linked on DAR), open that as a text file, and voila find the address to the bona fide rtsp:// audio stream. Then mplayer can be used via CLI to save the stream as a wav, mp3, or whatever else (with a command like: mplayer -cache 10 -ao pcm -aofile stream.wav rtsp://blah.rm). Or apparently you can use either Flashget (a standalone app) or Flashgot (a Firefox extension), either of which can take that same rtsp:// address and save it directly to your box. I’ve never used either of those, so you’ll have to use “the google.”

I really hope you’re able to work something out. Yes, DAR sucks donkey balls. But the university is unfortunately unwilling to budge on using Real’s crap-in-a-can system. Oh, well. If all else fails, call the music library. They’re usually fairly adept at working these issues out. But if you’re having problems with it, I’m not sure how much more help they can be.

Astonishment. I sit there for a few moments very impressed and completely humbled. -aofile is deprecated in the latest mplayer, but this new information led me to -ao pcm:file="filename", which causes mplayer to dump the stream to a wav file.

At this point I had enough information to make a (very dumb) scriptlet to get the streams. I could have cleaned it up and made it a lot more intelligent, but I’m a bit short on time and don’t have a reason to. Final result:

url="http://earth.ucsd.edu:8080/ramgen/darp/MUD8/MUD87523_1.mp3"
filename="01 Jason Forrest - A Spectacle to Refute All Judgements"
wget -q $url -O- > link
dos2unix link
mplayer -cache 1024 -vc dummy -vo null -ao pcm:file="$filename" `cat link`
lame --alt-preset standard "$filename" && rm "$filename"
rm link
echo "Finished encoding $filename" | growlnotify -a Terminal "DAR: Finished"

If you’re not familiar with the commands in here:

• wget janks files over http. If you have a command line, you probably have wget.
• dos2unix converts files with DOS line endings into files with UNIX line endings (\r -> \n). It’s probably not on your system by default.
• mplayer is a media player (and more!). If you’re on Linux you might already have it, if you’re on OS X you’ll need to install it yourself either from their site or via MacPorts
• lame is an mp3 encoder. I use it because disk space is cheap, but not that cheap. The scriptlet uses --alt-preset standard for it’s quality setting because there’s no point in wasting extra bits using --alt-preset extreme since the wav was generated from a previously compressed file anyway. If anything, we don’t want to hear the artifacts being added. This is probably not on your system by default.
• growlnotify is a command-line interface to Growl. If you don’t know if you have growlnotify installed into your path, then it’s not installed into your path. You should install it though, it’s really handy.

I’m sure folks have had this problem before me, and I’m equally sure people will have problems using DAR after I’m gone. Hopefully one of them will see this.