Thursday, February 23, 2012

nginx Self-Signed SSL

In this tutorial, I will be setting up nginx to listen on 443 for SSL connections. I will be creating a self-signed SSL certificate. I am running Ubuntu Server 10.04, your configuration locations may be slightly different.


1) Generate a Private Key

openssl genrsa -des3 -out server.key 1024

2) Generate a CSR

openssl req -new -key server.key -out server.csr

3) Remove Passphrase from Key

cp server.key
openssl rsa -in -out server.key

4) Generating a Self-Signed Certificate

openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

5) Copy the .crt and .key files to /etc/ssl/

cp server.crt /etc/ssl/certs/
cp server.key /etc/ssl/private/

6) Configure nginx

Add the following to /etc/nginx/sites-available/default

ssl_certificate /etc/ssl/certs/server.crt;
ssl_certificate_key /etc/ssl/private/server.key;

server {
    listen 443;
    ssl on;
    location / {


Of course, if you're not running nginx as a reverse proxy, your information in location / {} will be different. This is only an example to illustrate the use of the extra SSL options.

Reboot nginx

/etc/init.d/nginx restart

If everything goes well, you should be able to browse to (where is the IP of your server).

Configure nginx as a Reverse Proxy for Apache

In this tutorial, I will be setting up an Ubuntu 10.04 Server running Apache on port 8080 and nginx on 80. Apache will forbid connections from anything but localhost, and nginx will act as a reverse proxy and forward requests to Apache.

1) Modify /etc/apache2/ports.conf

Find the following lines in /etc/apache2/ports.conf:

NameVirtualHost *:80
Listen 8080

Change them to:

NameVirtualHost *:80
Listen 80

2) Modify /etc/apache2/sites-available/default

(Your distribution might just use apache2.conf, Ubuntu's a bit different, it keeps virtual hosts in separate files)

<VirtualHost *:80>
<VirtualHost *:8080>

Now change
<Directory /var/www>
    Options Indexes FollowSymLinks MultiViews
    AllowOverride None
    Order allow,deny
    allow from all
<Directory /var/www>
    Options Indexes FollowSymLinks MultiViews
    AllowOverride None
    Order deny,allow
    Deny from all
    allow from

(You may also wish to do the same for the "/usr/lib/cgi-bin" directory...)

3) Restart Apache

/etc/init.d/apache2 restart

If you try to access the server on 8080 remotely, you should get a 403 Forbidden.

4) Configure nginx

If you haven't already installed it...

sudo apt-get install nginx

Delete or move /etc/nginx/sites-available/default
Also, create the directory /etc/nginx/logs/

Now, create and edit /etc/nginx/sites-available/default

The file should look like this:

server {
    listen 80;
    access_log /etc/nginx/logs/access.log;

    location / {


Reboot nginx
/etc/init.d/nginx restart

You should be good to go now, try browsing to port 80 on the server and you should get content from Apache, but the server will appear to be running nginx.

Attacks like keep-dead should be a lot less effective against your server now. You can also configure nginx for SSL and not have to worry about configuring SSL for Apache.

It would also be a good idea to drop any external traffic to port 8080 with a firewall, as Apache still responds with a 403 if the firewall doesn't block the port.

You can see the access log at /etc/nginx/logs/access.log

Also, here's some nice examples for nginx configuration, if you're interested in configuring it further:

Crop Using FFMPEG

The ffmpeg parameter for cropping is:

-vf crop=1920:800:0:140

This takes a 1920x1080 resolution input, and crops 140px off of the top and bottom. The syntax is:

-vf crop=x:y:left_and_right:top_and_bottom

Here is an example:

ffmpeg -i INPUT.mkv -acodec copy -vcodec libx264 -crf 0 -vf crop=1920:800:0:140 OUTPUT.mkv

This takes INPUT.mkv, keeps the audio, transcodes it with x264 in lossless mode, and crops 140px from the top and bottom of the video.

Saturday, February 18, 2012

MP3 vs Lossless: Analysis with Phase Inversion

Lossy audio technology, such as MP3, has changed the way we listen to music. In the early days of portable music, MP3 technology made storing multiple CDs of music tracks on flash or mini hard disk storage practical. Instead of 700 mb of uncompressed WAV files, you could simply use MP3 to fit an entire CD into about 100 mb without any noticeable quality loss.

However, it has always been debatable just how much is lost when making an MP3 out of a lossless source like a track on a CD. There have been many comparisons and evaluations of lossy audio compression. Most people can pick out the tinny sound of a low bitrate MP3, and some can tell the difference even on higher bitrates, such as 128 kbps and beyond.

The image above shows the frequency analysis of a lossless track versus a 128kbps MP3 encode of the same track. All of the data in gray was lost in the MP3 track and is only present in the FLAC track. Everything above approximately 16.5 KHz was simply discarded when the MP3 was made.
Despite the loss of quality, there are no major legally licensed online sources of lossless music. Most music stores sell audio tracks at a bitrate and format that is similar to 320 kbps MP3 (some use VBR MP3, some use AAC, but they are all fairly similar at high bitrates).

The question is, can most people tell the difference between a lossless track and a 320 kbps MP3 of the same track?

Probably not.

In fact, if you did a double-blind study, I doubt many people could tell the difference. If you want to prove me wrong, test yourself here:

That's how I did after 10 tests.
Whether or not you can actually tell the difference between 320 kbps MP3s and 128 kbps MP3s is not what concerns me though. There is another matter that I feel is more important than whether or not we can "hear" the difference.

It is no doubt that information is lost when making an MP3 track at ANY bitrate. The human ear *probably* can't detect these differences (especially at 320 kbps) under any normal circumstances, it is below the just-noticeable difference threshold, but there are times when these small changes stand out a lot.

For example, if you have a CD version of a karaoke track and the actual track with voice, assuming that the studio simply muxed the voice over the karaoke track, you can reproduce the original voice track by playing one of the tracks inverted at the same time as the other track. This, in theory, cancels out any similar data, leaving only the difference.

Unfortunately, it only works reliably if you have lossless copies of each track. The MP3 copies have already changed too much data to be useful.

For the demonstration, I will invert a lossy MP3 track and play it against its lossless FLAC track and see what is left over.

If you have two identical lossless copies of an audio track, and you invert one of them and play them back synchronized, you will be left with pure silence. Try this out in Audacity if you don't believe me, import two copies of the same audio file, invert one, and play them both.

This is what I will demonstrate below: if you have two different tracks mixed together, and you play the second track inverted simultaneously with the mixed track, you should be left with a pure version of the first track.

For this example, I have made three recordings from my guitar. Both are <10s clips of playing a few chords. Mixed together, they sound awful, but it will get my point across.

I created FLAC versions of each recording, and a FLAC version of the two recordings mixed together.
I also created MP3s from the FLAC versions of each of those three files.

Here they are if you are interested in trying this yourself:

The MP3 versions are transcoded directly from their counterpart FLAC files.

In theory, if we invert (in Audacity, Effects > Invert) both chords1.flac and chords2.flac and play these two inverted tracks simultaneously with chords-mix.flac, we should get pure silence. And, indeed, we do! Here is the result: flac-merged-inverted.flac, a perfectly blank track!

(Fun fact: if you play "chords-mix.flac" and an inverted copy of "chords1.flac" in Audacity, you will be left with "chords2.flac")

The mixed track played simultaneously with the inverted forms of the two individual tracks results in pure silence.

Now, what happens when we do the same with the MP3 versions? The result is not pure silence, but additional noise! mp3-merge-inverted.flac

This is all leftover noise from the MP3s. Their encoded forms lose data and introduce noise, and therefore, when we play  the inverted MP3 tracks with the mixed MP3 track, we get erroneous noise when there should be silence.
As you can see in the frequency analysis above (and you can hear scratchy noise on the track if you listened to it), there is definitely data in the MP3 files that shouldn't be there! This is because, in order to make use of space, lossy compression will mix and match data in ways that lose high frequencies that appear in Fourier analysis. Normally, you wouldn't notice this "noise", but when we isolate it, you can clearly hear it.

Thursday, February 9, 2012

Use .cshrc to run bash

On the CS department computers at school, the default shell is csh, and we're not allowed to run chsh to change it. However, bash is available, so, you can modify your .cshrc file to automatically run bash instead.

Edit ~/.cshrc so that it only includes the following code:

if($?prompt) cd ~ && exec bash --login