Extracting Audio

There are a lot of good talks, but they are usually posted in video format. Most do not require visual attention to be understood, and so it would make sense to publish the audio. It would save bandwidth and time.

But until that happens, you must download them, and then extract the audio. Here’s how I (currently) do this.

Github: Gist: 4464109: Small bash script to extract audio from video files.


# Some consts


# Kick off the conversions
for file in *
  mime_type=$(file --brief --mime-type ${file})
  # Discard the subtype:
  #*/ XXX avoid silliness of the syntax highlighter

  if [ "${mime_type}" = "video" ]
    # Build the outfile

    # Consider existence to mean that it's been done before
    if [ -e "${outfile}" ]
      echo "Skipping ${file} (destination exists)..."

    # Announce it:
    echo -n "${file} TO ${outfile}..."

    # Do the conversion
    avconv -i "${file}" -vn -acodec ${OUT_CODEC} ${outfile} &> /dev/null &
    echo "${pid}"

    pids="$pids $pid"


# Waiting...
for pid in ${pids}
  echo "${pid} is pending..."
  wait ${pid} || failed="${failed} ${pid}"

if [ -z "${FAIL}" ]
  echo "Done."
  echo "Process(es) failed (${FAIL}), check state manually."

Output will look something like (simulated):

$ ./
Skipping talk_0.mp4 (destination exists)...
talk_1.mp4 TO talk_1.ogg...18443
talk_2.flv TO talk_2.ogg...18444
talk_3.ogv TO talk_3.ogg...18445
18443 is pending...
18444 is pending...
18445 is pending...

Changes that would be desirable include:

  1. Not kicking off too many conversions at once. This would require basically melding the two loops, to count the active number of processes, and only add new ones when old ones had finished.
  2. Better file location handling. Mixing input and output files isn’t ideal, and I end up manually moving the audio files to where they belong for easy consumption.
  3. Better file handling. Once I’m done with a file (assuming it wasn’t in the $failed list), it can be deleted. I don’t intend to watch the files that I convert to audio. The main risk is that a talk will have visually essential information that I’ll only discover upon listening, and if I still wanted to understand those portions I would have to redownload.
  4. cron integration. In theory I can add a script like this to my crontab, and then (assuming the changes directly above), simply download talks, and let the script manage the rest.
  5. Player integration. In my case this would be telling mpd to update the directory where I keep spoken word content, and possibly add new files to the MPD queue.

But one step at a time. I tend to go through phases where I listen to many talks and when I listen to none. Part of the reason is that I hadn’t built this script before, so I would often download talks and they would sit for a time until I would manually extract them.

Part of the future of computing ought be building systems that enable us to easily interact with the digital world, without jumping through many hoops. Often what is possible is not taken advantage of because of the efforts required to get there. For example, I have never visited the Musée du Louvre, despite it being on the same planet, because getting there would take a lot of time and money. But at least through their website and other sites on the Internet I can easily enjoy some of the art displayed there (and in the numerous other museums of the world).


Trying MPD (Music Player Daemon)

For awhile now I’ve had an Ampache instance for streaming audio data. I originally set one up some time ago, but ran into various roadblocks with configuring the codecs that made it frustrating to use (at least have my audio files are in Ogg Vorbis format). As is usual, if at first you don’t succeed, take a breath and go again. This time the codecs work great.

But, I have continued using Rhythmbox on my actual computer for listening to audio. And it’s great. I really like it. But it’s also got a bug (among other trackers that have it reported, here’s one: Launchpad: Bug #840854 in Rhythmbox: rhythmbox randomly crashes at the end of some tracks) that’s bugging me.

I figured it might be worthwhile to give another player a try. Several years back I switched to Rhythmbox from Amarok which is also a good player, but began growing sort of big for my tastes. This time I poked around and ended up reading about the Music Player Daemon (MPD).

I actually ended up reading about it in a roundabout fashion. I was looking for information about which players support the MPRIS D-Bus standard, as I use that to feed the audio metadata to Conky so I can see what audio file is playing (it looks like there is a Gnome Shell extension (Gnome Shell Mediaplayer Extension) that may suit those needs in the future?).

In that search I came across mpDris, which is a client that connects to MPD to provide data via D-Bus and MPRIS. It took me a few cycles to wrap my head around what was going on with MPD. mpDris is a nice thin metadata-only piece, which doesn’t care about actually controlling anything. MPD, for its part, takes a similar philosophy, providing only the backend.

For the frontend I initially went with the command-line client MPC, which stands for Music Player Client. That got me up and running.

The problem I found was that, in its default installation MPD runs as a service for the entire computer, using ALSA to output sound. This caused problems with Pulse Audio. Something on the lines of it expecting uninterrupted control of ALSA. My options were to have Pulse Audio run as a system-wide service (which is not recommended) or to run MPD from my user session. I went the latter route.

It works great. One caveat was that mpDris needed to wait for MPD to be started, as it dies when it cannot connect. It also took a little bit to rework the script I was using to consume MPRIS data for Conky, as I had earlier updated it to work with Rhythmbox 3 (which if I recall uses MPRIS 2.1), and mpDris only supports the original MPRIS 1.0 at present.

I went with Sonata as a graphical frontend. It works well. It’s a very light frontend, though it lacks some of the audio libary management features of some others.

I may yet return to Rhythmbox, but for now it’s been an informative experience trying out MPD. One thing I haven’t delved into yet is using Ampache as a client for MPD. That may allow for reducing the complexity of the configuration/data storage of Ampache. It seems like it may be possible to simply replace Ampache with MPD entirely for what I use it for.

You may have noticed the abundance of links in this post. Most every time I interact heavily with free software, I am amazed at the number of projects and the number of people that have contributed to allow me to use this software. Even with all of those links, many other components went unmentioned, as they were libraries or other parts glossed over.

As an aside, if you are reading this post around mid-to-late November 2011, you may notice the anti-censorship link over the logo. That’s a link to information regarding COPA SOPA, the latest attempt by a minority of our society in the USA to act in a malicious and ruinous fashion at the expense of the rest of us.

While it is prima facie unconstitutional, that’s no reason to let such dreck be peddled by the representatives of the people. Censorship is an intolerable price to pay to protect a non-intrinsic right that’s already been extended well beyond the point of diminishing returns. Copyright needs reform, but not in this draconian manner.