Skip to content

A kingdom for a music player!

The quest for the my perfect music player continues. I won't go into the details, why iTunes sucks so much, others have done this already.

A long time ago, I started with Songbird. They were crazy enough to take Mozilla's XULRunner runtime and turned it into a music player. But it had the browser still built in and came with lots of features, making this thing quite bloated. Maintaining ~20k songs became very unpleasant, CPU usage was definitely too high for a music player.

Then there's Cog, which is neat, but was more of an ad-hoc player and not meant to maintain a music library.

Later on, Unixhaus suggested to use Clementine. Crossplatform, open-source, nice interface and a Nyanalyzer - what more could one ask for? Sticked with it for quite a while, but there were still 20k songs to manage and cpu usage was rather high. 15% CPU usage on a MacBook Pro just for playing music? And often enough CPU usage spiked for a few minutes, doing something and then dropped to 15% again. Very annoying.

OK, what else is out there? Winamp! No, seriously, there's Winamp for Mac. Yeah, I tried it, I admit. Again with the 20k songs, Winamp performed quite well...but: it feels kinda creepy having Winamp on a Mac. Try it and see feel for yourself :-\

Another contender was Ecoute. It's has a 15-day-free-trial version, then it's US$8 in the Mac App Store. It's got a very nice UI, but after a while it kept freezing again and again and became unusable. Good thing they offered a trial version!

I haven't tried Enqueue yet. It's US$ 10 in the Mac App Store but unfortunately there's no trial version. It looks a lot like iTunes, exactly what I'm trying to avoid.

Someone mentioned Vox - their tagline is "The Lightweight Music App for Mac OS X". OK, I haven't tried it yet, but from looking at their screenshots they seem to have a different understanding of lightweight.

So, what now? Clementine is the player I used most of the time, but gave up some months ago, trying out other alternatives.

A few days ago I thought "Hm, I wonder what happed to Songbird?". They are at version 2.x now and I felt like giving it another shot. They still have this browser stuff underneath, but the application feels a lot faster now, they cut down on bloated plugins in the initial installation (though there are plenty addons to choose from) and for now Songbird seems to have made it and it's very usable, for me. And, like Clementine, it's cross-platform and open-source (sans the Nyanalyzer) and for now it's working just fine.

I could end this entry with "Stay tuned for updates" but I hope that I won't need to update this post and that Songbird continues to stay usable.

Remove U3 from an USB flash disk

This "SanDisk Cruzer" USB flash drive has this nasty U3 thingy included. Every time it connects with a host, this U3 partition reappears and gets in the way, trying to do super smart stuff.

So, how to get rid if this malware feature? Overwriting the whole device did not help. There's a removal tool...for Windows. There's a removal tool for Macs too, but only up to MacOS 10.6 :-\

For Linux, there's u3_tool. This hasn't been updated in a while but let's hope we won't need tools like this in the future. Here's a short description to get u3_tool going:
 svn co u3-tool-svn
 cd trunk u3-tool-svn
 automake --add-missing
 ./configure --prefix=/opt/u3-tool
 make && sudo make install
After the build completed, let's use it:
$ /opt/u3-tool/sbin/u3-tool -i -v /dev/sdb
Total device size:   1.88 GB (2017525760 bytes)
CD size:             16.00 MB (16777216 bytes)
Data partition size: 1.86 GB (2000748544 bytes)

$ /opt/u3-tool/sbin/u3-tool -p 0 -v /dev/sdb

WARNING: Loading a new cd image causes the whole device to be wiped. This INCLUDES
 the data partition.

Are you sure you want to continue? [yn] y

$ echo $?
And it worked :-) Good riddance, U3!

Repair broken MP3 files

Some application (which shall remain nameless) complained about "invalid MP3 formatted files", but gave no clue about what exactly was "invalid". The files played just fine, their ID3 tag were displayed too, so this application appeared to be overly picky about these files. Let's have a closer look:
$ file foo.mp3
foo.mp3: Audio file with ID3 version 2.3.0, contains: MPEG ADTS, layer II, v1, 192 kbps, 44.1 kHz, Stereo
Aha! Although the file was named .mp3 it really was an mp2 file. Of course, most program can play MPEG-2 just fine, but this application refused to do so.

The ever-so-faithful lame was quick to help:
$ mv foo.{mp3,mp2}
$ lame --mp2input foo.mp2 foo.mp3
Also, the ID3 version said "2.3.0", which is perfectly valid but maybe there was something else wrong with these files so I needed some magic program to check (and repair) this file's ID3 tag. mid3iconv (from python-mutagen) is supposed to do just that:
$ mid3iconv -d foo.mp3
Updating foo.mp3
Now our file looked like this:
foo.mp3: Audio file with ID3 version 2.4.0, contains: MPEG ADTS, layer III, v1, 128 kbps, 44.1 kHz, JntStereo
...and the application was happy to process this file :-)

smartctl & external disks

When monitoring S.M.A.R.T. values of disks in a Unix system, smartmontools is usually the way to go.

Unfortunately monitoring external disk enclosures may be difficult or not possible at all. I haven't seen a firewire enclosure that supported SMART commands yet.

USB enclosures tend to work, but I noticed that the scheduled self-tests would not complete. For example, for the following disk a short (S) self-test is scheduled every day at 3am and a long (L) self-test every saturday at 6am:
$ cat /etc/smartd.conf
/dev/disk/by-id/scsi-SSAMSUNG_HD103UJ -d sat -a -o on -S on \
                           -s (S/../.././03|L/../../6/06) -I 190 -I 194 -W 5
But so far every test did not complete:
$ smartctl -d sat -l selftest /dev/sdb
SMART Self-test log structure revision number 0
Warning: ATA Specification requires self-test log structure revision number = 1
Num  Test_Description    Status           Remaining  LifeTime(hours)
# 1  Extended offline    Aborted by host      00%     25980
# 2  Short offline       Aborted by host      00%     25973
Someone else had a similar problem and suggested to run "smartctl -a /dev/disk... every few seconds while the self-tests are in progress, so that the disk would not shut down. Preliminary tests showed that this helped in my case as well.

From now on the self-test schedule in smartd.conf will be accompanied by some cronjob doing just this:
while smartctl -d sat -l selftest /dev/sdb 2>&1 | \
               grep -q "Self-test routine in progress"; do 
      sleep 30
The crontab(5) entry for the schedule above:
# m h  dom mon  dow   command
0   3    \*   \*    \*   script /dev/disk/by-id/scsi-SSAMSUNG_HD103UJ
0   6    \*   \*    6   script /dev/disk/by-id/scsi-SSAMSUNG_HD103UJ
We might add some fuzzyness to this "script" of course, so that it will work when the actual self-tests starts a bit late.