But, if I just use lame for this transcoding, it dosen’t copy the id3 tags properly.  I needed to write a script to copy the id3 tags from the source file to the new, lower bitrate file.  Here’s the script:

#!/usr/bin/python
import sys
from mutagen.id3 import ID3

source = ID3(sys.argv[1])
dest = ID3(sys.argv[2])
for key in source:
    dest[key] = source[key]
dest.save()

There’s two tricks to using this properly:
1. The file being tagged (“dest” above) must already have some id3 header in it.
2. The mutagen library writes out id3 v2.4 tags that many programs don’t understand, so I use a second program to copy the id3 v2.4 tags to id3 v2.3. Here’s the complete transcoding script with the call to “cpid3.py” which is above:

#!/bin/bash
TMPFILE=$(mktemp).mp3
lame --add-id3v2 --pad-id3v2-size 1024 --quiet -f --preset fast medium "$1" "$TMPFILE"
~/bin/cpid3.py "$1" "$TMPFILE"
eyeD3 --to-v2.3 "$TMPFILE"
mv -f $TMPFILE "$1"
echo "Done with: $1"

So, when I saw that a WebOS root image had been leaked, I thought it would be great to download it and extract all the sound files so I could use them on my Android Nexus One as ringtones or notification sounds.   It was a pretty straightforward process, although the files were nested in several containers (a jar containing a tar containing a tar).  Many of the files were in PCM or WAV format, and for your convenience, I’ve converted them all to high-bitrate mp3 files.  This includes the default ringtone, which has gotten a bunch of press recently, that’s available as Pre.mp3, below, as well as all the system “alert” sounds like the ones I mentioned above.  They’re great.

Here’s the complete list of files:

Anticipation.mp3
Discreet.mp3
Dulcimer.mp3
Flurry.mp3
Guitar.mp3
Older Phone.mp3
Pre.mp3
Rain Dance.mp3
Scamper.mp3
Triangle.mp3
alert.mp3
alert_buzz.mp3
appclose.mp3
back_01.mp3
browser_01.mp3
card_01.mp3
card_02.mp3
card_03.mp3
card_04.mp3
card_05.mp3
default_425hz.mp3
delete_01.mp3
discardingapp_01.mp3
down2.mp3
dtmf_0.mp3
dtmf_1.mp3
dtmf_2.mp3
dtmf_3.mp3
dtmf_4.mp3
dtmf_5.mp3
dtmf_6.mp3
dtmf_7.mp3
dtmf_8.mp3
dtmf_9.mp3
dtmf_asterisk.mp3
dtmf_pound.mp3
error_01.mp3
error_02.mp3
error_03.mp3
focusing.mp3
launch_01.mp3
launch_02.mp3
launch_03.mp3
notification.mp3
notification_buzz.mp3
pagebacwards.mp3
pageforward_01.mp3
phone.mp3
ringtone.mp3
ringtone_buzz.mp3
shuffle_02.mp3
shuffle_03.mp3
shuffle_04.mp3
shuffle_05.mp3
shuffle_06.mp3
shuffle_07.mp3
shuffle_08.mp3
shuffling_01.mp3
shutter.mp3
switchingapps_01.mp3
switchingapps_02.mp3
switchingapps_03.mp3
tones_3beeps_otasp_done.mp3
unassigned.mp3
up2.mp3

mt-daapd is an iTunes daap-protocol server for Unix systems.  I’m using mt-daapd on by Ubuntu 9.04 system to stream music over the internet to my workplace.   The issue is that many of my mp3 files are 256kbps mp3 files, and streaming these takes up more bandwidth than necessary.

mt-daapd includes a transcoding system called “ssc” for “Server Side Conversion”.  This system works by either a shared-object plugin (i.e. ssc_ffmpeg) or via an external script file (i.e. ssc_script).

using the ssc_script functionality, one can invoke ‘lame’ (the mp3 encoder) to transcode high bitrate mp3 files into lower bitrate mp3 files.  The setup for this in mt-daapd wasn’t very obvious, so I’ll document it here.

Install mt-daapd

The version of mt-daapd provided by Ubuntu 9.04 includes support for transcoding, so you can just run:

$ sudo apt-get install mt-daapd

Turn on ssc

Edit your /etc/mt-daapd.conf file, and make sure you have the following lines in the correct places:

ssc_codectypes = mpeg

always_transcode = mpeg

ssc_prog = /path/to/script/shown/below/mt-daapd-mp3-ssc.sh

[plugins]

plugins = ssc-script.so

Create mt-daapd-mp3-ssc.sh

You’ll need to create a shell script to do the transcoding via ssc_scrpit / ssc_prog.  Here’s the script I’m using:

#!/bin/bash

FILE=$1
OFFSET=0

if [ "$2" == "" ]; then
OFFSET=0
else
OFFSET=$2
fi

if [ "$3" == "" ]; then
FORGELEN=$3
fi

lame -V6 –quiet “$FILE” -

Note that I’m looking at the 2nd and 3rd args, but I’m not doing anything with them.  These arguments are used to make sure that seeking works properly in your daap client.  I don’t care about seeking, and doing it properly is somewhat hard, so I’ve just ignored those arguments.  I think that this could be accomplished properly using the program ‘mp3splt’ but I haven’t looked into it enough to see what it would take.

Make sure the script above is put somewhere accessible by the user specified as ‘runas’ in your mt-daapd.conf.   Make sure the script is executable by this user as well.

Restart mt-daapd and see if it works

Restart mt-daapd via:

$ sudo /etc/init.d/mt-daapd restart

Then reconnect your daap client (I use rhythmbox).  You can see if the script is working by running “ps auwxww | grep lame” just after pressing play on a song.  You should see your script executing lame and doing realtime transcoding.

There are several descriptions on the net on how to hack around missing library dependencies and download them (via getlibs) or to tweak out the pkgconfig file to shoe horn the amazonmp3.deb file into an amd64 system.

I like to keep my installs really pristine, and avoid workarounds like getlibs and modified packages, so I’ve decided to go with a 32-bit chroot for running amazonmp3.  Generally, the process involves downloading another version of Ubuntu (in our case, 8.04, which is what the amazonmp3 package was built against), and then chroot-ing into this install area to run the 32-bit program.  Several existing tools make this easier than it sounds.

Get Ready

There are several dependent packages that you should install first.  In your base system, please run:

$ sudo apt-get install debootstrap schroot

Install 32-bit Intrepid into a subdirectory

Using the new debootstrap package that you just installed, you can now run:

$ mkdir ~/chroots

$ sudo debootstrap –arch=i386 intrepid ~/chroots/intrepid-32

The second command will take a while to run, and will download several hundred MB of intrepid packages, and install them under the newly created directory ~/chroots/intrepid-32

Edit /etc/schroot/schroot.conf

You should add a section to /etc/schroot/schroot.conf that looks like this:

[intrepid-32]
type=directory
description=Intrepid 32-bit
location=/home/YOUR_USERNAME/chroots/intrepid-32
priority=3
users=YOUR_USERNAME,root
groups=YOUR_USERNAME,root
root-groups=root,adm
run-setup-scripts=true
run-exec-scripts=true
personality=linux32

Do a little bit of post-install cleanup.

I’ve found that by default, I don’t have sudo permissions inside the chroot, so I do this one small step:

$ sudo cp /etc/sudoers ~/chroots/intrepid-32/etc/sudoers

That way, when I enter the chroot, I have sudo permissions available as well.

Get inside the chroot and make sure it works

You can now go inside the chroot via the following command:

$ schroot -c intrepid-32

You should see that while inside the chroot, your prompt should start with “(intrepid-32)” indicating that you’re chrooted.  Great.  Give a simple sudo command a try to make sure it works, like this:

$ sudo ls ~

Type your password, and confirm that you can run things as root.

At this point, you can do anything else you want in the chroot, like installing other packages, or cleaning things up.  You may want to run “sudo apt-get update ; sudo apt-get dist-upgrade” just for fun.

Install amazonmp3.deb in the chroot

The chroot shares your home directory, /tmp, and several other directories with your main system (so be careful!).  But, this also makes life easier.  While you’re outside of the chroot, download amazonmp3.deb and put it in /tmp or your home directory. Then, get inside the chroot, and run:

(intrepid-32)$ sudo dpkg -i amazonmp3.deb

It will complain about some missing dependencies.  Install those libraries via apt-get, and then run the dpkg -i again, and you should be in business.  To run amazonmp3, you may need to double-check your DISPLAY environment variable and make sure that it’s properly set inside the chroot.  Once you’ve done that, you should be able to easily run amazonmp3 inside the chroot, and download music to your home directory.

Good luck!

I started out with netjuke, which died and got absorbed into the horrible jinzora project.   So then I switched to Ampache, which worked fairly well, but needs some serious UI upgrades/changes to make it reasonably useful.

Now that I’m fully ubuntu-ized, I’m using mt-daapd through an SSH tunnel to listen via a native client app.  This solution has lots of interesting benefits:

1. Running mt-daapd locally means other people in my house can see my music, including my TiVo and any other desktops with an iTunes/daap compatible frontened.
2. I don’t have to worry about security issues with having all my music accessible via a web portal that could be hacked.
3. mt-daapd is available as a package in Ubuntu, so that means upgrades are easy.  Doing upgrades (by hand) of php-based web apps was really becoming a drag.
4. This means less junk on my slacy.com web server, which I’m trying to significantly trim down and make more secure by having less applications.

1. I’m using audacious for playback instead of xmms
2. I switched to a more recent version of lame.

After doing so, about 1 in 10 files would fail to play (either silence, or strange thumping noises) on audacious, saying one or more of the following messages:

(audacious:12805): MADPlug-WARNING **: samplerate varies!!
(audacious:12805): MADPlug-WARNING **: layer varies!!
(audacious:8645): MADPlug-WARNING **: number of channels varies!!

If I downloaded the file and played that, it worked just fine, so it was something weird about the fact that it was streaming.  My lame transcoding commandline was:

lame –mp3input -h –vbr-new -V 6 -B 320 -b 32 -S -m j $file -

The problem seems to be –vbr-new, since if I remove that option, it works great all the time.  Go figure.

In general, I think audacious sucks.  Now I also think that madplug sucks.  Oh, and by the way, all of this was precipitated by Fedora removing xmms from their repositories due to mp3 licensing issues.  Fedora sucks too.  Ugh!  It seems as though mp3 playback under Linux has taken a huge step backwards…

So, I decided to just suck down the whole site and scrape out all the URLs to all the mp3 files and download them. It was very straightforward.

First, scrape the site by doing something like this:

wget -nd -nH -r –no-parent -nc http://2008.sxsw.com/music/showcases/alpha/0.html

Then, do something like:

grep mp3_download *.html

(Yes, they were silly enough to use a CSS class for all their mp3 download links named ‘mp3_download’.)

Then, you’ll have a file with a bunch of raw HTML links. Pull that into something like emacs and do some replace-regexp commands to trim it to just the URLs themselves. (There are 740 of them). I then took the resulting list of mp3s, split it into 2 files, and am running two copies of wget in parallel to suck them all down. Here’s a copy of the list of all 740 mp3 files.

Send me an e-mail to my private account if you’d like me to hook you up with a .tar.bz2 of all 740 files. I wonder if they’ll release that .torrent soon?

UPDATE: The download completed overnight, and the resultant files are about 3.4GB.