This is getting silly. But this is the end of the mplayer/mencoder theme.

I've used mencoder, part of the mplayer suite, to do lots of different types of file format conversions. Here's another one, only this time it uses mplayer to do the conversion, Normally, mplayer plays A/V data, while mencoder transcodes A/V data between different formats.

However, mplayer has a "-ao" flag ("audio out"), which is normally used to control which hardware interface to send sound to (and/or how to send the audio data). E.g. It can choose between the ALSA or the OSS interfaces on a Linux system, or the sun interface on a Solaris system, or the OSX interface on a Mac. It is used to specify the specific sound card if more than one is present. It can also choose to send the audio to another abstraction layer such as SDL, esd, arts, or jack (all of which typically end up sending to a real sound card, although sometimes one on another computer). It can even use specialized hardware like that found in those TV capture cards that also output audio and video signals.

For some reason, mplayer's -ao flag has the ability to send audio data to plain PCM/WAV data file. This data is more or less identical to what it would send to sound hardware (at least, sound hardware found on PC-based computers). It creates a legitimate WAV file, but note that the data generated this way is not compressed.

BEGIN USAGE
sysadmin@artoo:~$ ra2wav
Usage: ra2wav .ra
END USAGE

BEGIN EXAMPLE
( EXAMPLE )
END EXAMPLE

You can see that the resulting wav file is very large. A logical next step would be to use something like lame to covert it to an mp3 or ogg file.

Here's the code

BEGIN CODE
( CODE for ra2wav )
END CODE

Note that, because mplayer really is a player but we're using it to transcode data, it needs to be told not to use a video codec ("-vc null") or to actually display video ("-vo null"). Note this is also done when using mplayer to identify data about the file using the "-identify" flag. The word "fast" tells the pcm driver to process faster than real (clock) time.

In writing this post, I couldn't remember why I decided to write this using mplayer. But in trying to create the "correct" version using mencoder, I couldn't figure out how to do it. I expected this to work:

mencoder -oac pcm -o "$j" "$i"

However, it doesn't. It says "WARNING: OUTPUT FILE FORMAT IS _AVI_. See -of help.", then "REALAUDIO file format detected.", and finally "Video stream is mandatory!". Apparently mencoder assumes it's working on a video file (an AVI file, by default). I can't figure out how to make it realize it's only to process audio data. There is an output format flag ("-of") that has a "rawaudio" format, but I couldn't make that work--it still insisted that a Video stream is mandatory. The man page says "-of" is still in beta, perhaps someday there'll be a "wav" or "pcm" format. If anyone has a suggestion, I'd love to learn how to make mencoder do what I want.

Originally timestamped 2005-10-18 but again trivially cleaned up while writing this entry, aviid (which works on more than just AVI files) prints informational parameters about a movie file.  It even works on audio files.  Here's some sample output

BEGIN OUTPUT

Star Wars: The Legacy Revealed.mpg
ID_VIDEO_ID=0
ID_AUDIO_ID=0
ID_FILENAME=Star Wars: The Legacy Revealed.mpg
ID_DEMUXER=mpegps
ID_VIDEO_FORMAT=0x10000002
ID_VIDEO_BITRATE=6000000
ID_VIDEO_WIDTH=720
ID_VIDEO_HEIGHT=480
ID_VIDEO_FPS=29.970
ID_VIDEO_ASPECT=0.0000
ID_AUDIO_FORMAT=80
ID_AUDIO_BITRATE=0
ID_AUDIO_RATE=0
ID_AUDIO_NCH=0
ID_LENGTH=7192.19
ID_VIDEO_CODEC=mpegpes
ID_AUDIO_BITRATE=384000
ID_AUDIO_RATE=48000
ID_AUDIO_NCH=2
ID_AUDIO_CODEC=mad
ID_VIDEO_ASPECT=1.3333

END OUTPUT


Offhand I don't know how to interpret some of the parameters (e.g. ID_VIDEO_ID), but I find others very useful (like ID_VIDEO_ASPECT, ID_VIDEO_HEIGHT, ID_VIDEO_FPS). 

BEGIN aviid

#!/bin/sh

while [ $# -gt 0 ]; do
 i="$1";
 shift
 echo $i
 mplayer -identify -vo null -ao null -frames 1 "$i" 2>&1 | grep ID_
 echo
done

END aviid

As you can see, this is a very simple wrapper around mplayer. In fact, mplayer's man page refers to a "standard" wrapper called midentify found in the TOOLS directory of the mplayer distribution, but that script isn't included in the mplayer package for Ubuntu.  The -identify flag is the important one causing the parameters to be printed.  The -vo null -ao null part makes sure mplayer doesn't try to render video or play audio, important because this is intended to be a command-line tool not a GUI/multimedia tool.  Similarly, without the -frames 1 option mplayer will happily play the entire file, even with audio and video output set to null.

mplayer prints some stuff to standard error and other stuff to standard output, so the '2>&1' construct redirects all error to output, making sure it all gets piped to the grep command.  As it turns out, none of the ID information is on error, so redirecting it to /dev/null would have been just as effective, but I find this approach more elegant, should I ever want to extend the grep pattern or even process it with some other command.  Finally, the grep command filteres out everything but the informational parameters.

First post! After actively using the Internet since 1994, I've finally found some motivation to open one of these blog thingys. Naturally, that motivation is nerdy in nature. My intention is to post those shell scripts (and other computer-y hacks) that I've created in that time. Here's the first one. It's timestamp is dated 2007-11-08. I use it to play the BBC7 Live Stream without having to fire up a web browser to their difficult-to-navigate website. It also avoids having to install RealPlayer because it uses mplayer.   It also requires the 'LWP' Perl Module (for GET), but that could be replaced easily enough.  Finally, it assumes the BBC won't change the URL for the stream.

BEGIN bbc7live

#!/bin/bash

while true; do
  mplayer -cache-min 5 "`GET http://www.bbc.co.uk/bbc7/realplayer/dsatg2.ram`";
done

END bbc7live

The infinite loop is necessary because mplayer doesn't reconnect when the stream breaks (realplayer does).  The -cache-min tells mplayer how much to cache (in seconds, I believe).  I chose 5 seconds over whatever the longer default was because the time it was taking to fill the cache would be lost when the stream breaks: at each break mplayer would drop the cache contents and reconnect (thanks to the while loop).  But it wouldn't reconnect where it left off (because it's a real-time stream) but rather at the current time, which thanks to the previous large cache is several 10s of seconds later than where it broke off.