Normalizing all my audio files with ReplayGain

0 comments

ReplayGain is a nice standard for normalizing the volume levels in your audio files.  Unfortunately, each audio format has its own library and tools to use it.  For example:

  • ogg vorbis: vorbisgain
  • mp3: mp3gain
  • aac (possibly also mp4 audio, m4a, and whatever other extensions Apple uses): aacgain
  • flac: metaflac --add-replay-gain
  • wavpack: wvgain 
Fortunately, I came across a nice tool called rganalysis that applies Replay Gain to all your audio formats at once.  To install:
cd ~
sudo easy_install -U plac
sudo easy_install -U quodlibet
sudo easy_install -U mutagen
git clone git://github.com/DarwinAwardWinner/rganalysis.git
cd rganalysis

To test, try something like:

./rganalysis.py --dry-run <path to music>

To run, use:

./rganalysis.py <path to music>


The full set of command line options can be found here.

P.S. Audacious is a nice audio player that supports ReplayGain by default.  Also, to convert wav files to flac, use the following command:
flac --best *.wav
P.P.S. If you just want to normalize all audio for any audio player (actually modifying the audio file waveform), you can use normalize:
normalize-audio *

Context menu option to add a song to audacious playlist

0 comments

Personally, I like the Audacious audio player.  It's simple, supports ReplayGain, automatically adds multiple selected files to the playlist, and is popular.

Recently, I wanted to add a couple songs to an already playing playlist.  Although I could just select the file(s) and then drag them to into the player, I wondered if I could create a right-click context menu to add them to the playlist instead.  It turned out to be really easy:

Follow this guide and instead of their brasero command line example, use:

audacious -e %U
Then, when editing the .desktop files, change the "Name" line to:
Name=Audacious Playlist
and add the following line:
Icon=audacious

Base64 quirks

0 comments

Base64 is an amazing text-based encoding scheme.  That said, it has its quirks.

For example, RFC 2045 states "Encoded lines must not be longer than 76 characters" but that add excessive processing overhead when, say, converting a 3MB image to base64.  However, if you don't add line breaks at all, some browsers and rendering engines choke on large data sets.  So, a general rule of thumb is to add a line break char ("\n") every 8191 characters (or every 8000 to keep it simple and allow some cushion).  This should fix any browser/renderer issues and make the data much more readable in formats such as SVG.

Another issue: adding base64 data to JSON is problematic because JSON doesn't allow line breaks within a single key/value pair (line breaks are generally stripped out automatically).  Viewing a JSON file with a large base64 encoded object will typically give you garbled lines.  I've tried a number of editors (gedit, leafpad, tea, eclipse, nano, emacs, scribes, geany) for a decent read-only viewing experience and the best options I've found so far are vim and SciTE.

Note: if you plan on using SciTE, install it and then from the menu choose "Options > Open User Options File" and enter the following:

open.filter=All Files|*.*
line.margin.visible=1
line.margin.width=3+
title.full.path=1
title.show.buffers=1
split.vertical=0
wrap=0
buffers=20
check.if.already.open=1
position.maximize=1
font.base=$(font.monospace),size:11

Finding the right NoSQL database

0 comments

At work the other day I needed a simple database to store some JSON data.  I figured I'd use the opportunity to review the various NoSQL databases available and choose my favorite.  My needs were simple:

  1. Must support Windows and Linux
  2. Must have a cross-domain read/write RESTful API (preferably without complicated JSONP callbacks)
To save you the two days of searching it took me, I'll summarize my findings here:

  • MongoDB - no writeable REST interface
  • OrientDB - version 1.0 was released this week but was too buggy and the REST interface wasn't cross-domain
  • CouchDB - I couldn't find any mention of a RESTful API in their documentation
  • ArangoDB - alpha quality, not meant for production
  • Riak - doesn't support Windows
  • Cassandra - no REST interface
I was starting to lose hope when I remembered a friend mentioned ElasticSearch awhile ago so I figured I would try it out.  VoilĂ  - It worked great!  Its REST API fit well with jQuery AJAX and it supports both Windows and Linux.

I'll update this post soon with some code samples and instructions on how to install an excellent Dashboard GUI.

P.S. ElasticSearch isn't perfect.  As with anything, there's a few gotchas to be aware of.

Compiling PhantomJS 1.5 on Webfaction

0 comments

Webfaction is a cool web host because they allow you to compile source code and run custom binaries.  One example of when this might be useful is to run PhantomJS.  Normally, you would download and install the pre-compiled version as described in an earlier post, but I ran into a bug the other day that was fixed in trunk and I couldn't wait for 1.5.1 to be released so I compiled PhantomJS on Webfaction myself and thought I'd share it in case it's useful for anyone else:

mkdir -p $HOME/src

cd $HOME/src

wget 'http://ftp.tux.org/pub/X-Windows/ftp.hungry.com/chrpath/chrpath-0.13.tar.gz'
 
tar -xzf chrpath-0.13.tar.gz
 
cd chrpath-0.13

mkdir build

./configure --prefix=$HOME/src/chrpath-0.13/build

make && make install

cp $HOME/src/chrpath-0.13/build/bin/chrpath $HOME/bin

cd $HOME/src

git clone git://github.com/ariya/phantomjs.git && cd phantomjs
 
git checkout 1.5
 
./build.sh

cp $HOME/src/phantomjs/bin/phantomjs $HOME/bin


To test:

phantomjs --version