FLAC compression level comparison

So, I’m in the process of ripping all my music to FLAC since I am getting a completely new audio system in my home. With the high-end pre-amp, amplifiers, DACs, and floorstanding speakers in place, my full music collection (currently ripped in OGG) will no longer be of sufficient quality. Re-ripping a really large collection is a cumbersome task, so I wanted to make sure that I chose wisely with regard to the FLAC options that are available (particular concerning compression).

A little background is that FLAC is the Free Lossless Audio Codec, which means that there is no loss of quality at all. So, regardless of the compression level that is chosen, FLAC will always decode into the exact uncompressed audio track (bit for bit). The difference between the compression levels, then, is the resulting file size. Along with that benefit (higher compression results in a smaller file size), though, comes the downside of longer times to encode. According to Wikipedia (which cites comparisons that don’t seem to directly mention decoding times), there shouldn’t be any noticeable effect on the decoding of the FLAC files based on the compression level used during encoding. The default FLAC compression level tends to be 5 for most applications.

All of that being said, I decided to do a small test (n=2) with two songs. I firstly ripped the two songs into uncompressed WAV files, and then encoded them into FLAC from the command line using the following code:

time flac $SONG.wav --compression-level-X -o flacX.flac

That showed me the time to encode, and I substituted the compression level number (between 0 [lowest compression] and 8 [highest compression]) for ‘X’. Before looking at the results, here’s some information about the system used and the information contained in the results tables:

System specs:
Intel Core i7-960 (Bloomfield) @ 3.20 GHZ (quad-core with Hyperthreading)
24 GiB RAM (DDR3-1600)
Gentoo Linux with kernel 3.12.11
FLAC 1.3.0

Table data:

  • Quality: The FLAC compression level used
  • Encode (sec): The time it took to encode the song
  • Size (MiB): The resulting FLAC file size (rounded to tenths of a Mebibyte)
  • Ratio (%): FLAC file size as a percentage of the original uncompressed WAV
  • Enc + (sec): The additional time required to encode as compared to FLAC 0 (in seconds)
  • Enc + (%): The additional time required to encode as compared to FLAC 0 (as a percentage of increase)

Below you will find information about the two songs used as tests, and the results (in sortable tables):

Song 1:
Artist: Dream Theater
Album: A Change of Seasons EP
Song: A Change of Seasons
Length: 23’08″ (1388 seconds)
Uncompressed WAV: 128 seconds to rip – 233.6 MiB resulting file size

Quality
Encode (sec)
Size (MiB)
Ratio (%)
Enc + (sec)
Enc + (%)
FLAC 03.531174.674.7%0.0000.00%
FLAC 13.721173.574.3%0.1905.38%
FLAC 24.658173.274.1%1.12731.92%
FLAC 35.255165.070.6%1.72448.82%
FLAC 46.584163.870.1%3.05386.46%
FLAC 59.112163.469.9%5.581158.06%
FLAC 69.130163.469.9%5.599158.57%
FLAC 719.475163.369.9%15.944451.54%
FLAC 828.846163.169.8%25.315660.30%

Song 2:
Artist: Libera
Album: New Dawn
Song: Air (Air on the G string by Bach)
Length: 3’43″ (223 seconds)
Uncompressed WAV: 23 seconds to rip – 37.6 MiB resulting file size

Quality
Encode (sec)
Size (MiB)
Ratio (%)
Enc + (sec)
Enc + (%)
FLAC 00.51620.253.8%0.0000.00%
FLAC 10.54119.652.2%0.0254.84%
FLAC 20.69919.652.2%0.18335.47%
FLAC 30.80619.150.8%0.29056.20%
FLAC 41.02218.649.3%0.50698.06%
FLAC 51.43118.549.3%0.915177.33%
FLAC 61.42918.549.3%0.913176.94%
FLAC 73.04918.549.1%2.533490.89%
FLAC 84.52418.449.0%4.008776.74%

From both tests, it seems like FLAC compression level 3 is the right trade-off between file size and additional encoding time. Now, are either that big of a deal by today’s standards (in both available storage capacity and processing power)? Probably not. I could rip everything in FLAC 0 and call it a day, since the difference between FLAC 0 and FLAC 3 seems to be about 0.5 MiB for every minute of music. However, my current collection is approximately 391 hours (or 23460 minutes). That means that I will save somewhere in the neighbourhood of 12 GiB for my entire collection. Is that space savings worth the roughly 50% more time to encode? Maybe or maybe not.

At this point, my entire collection of ~391 hours of music will consume around 177 GiB if ripped at FLAC 0, and around 165 GiB if ripped at FLAC 3. On a 2 TiB HDD, that doesn’t seem like a big deal, really.

So, ultimately, I will either rip at FLAC 0 and not worry about the additional space, or FLAC 3 if I think it will help. At the rate that storage prices are dropping, FLAC 0 would seem like the obvious answer, but for so very little of an increase in encoding time, FLAC 3 makes more sense.

What are your thoughts?

Cheers,
Zach

Lenovo laptops now feature what?

Each month, the online discount retailer Working Advantage has a sweepstakes for some hot item. For November 2012, it is a Lenovo IdeaPad Z580. I received the following email about it yesterday:

Working Advantage Lenovo IdeaPad Z580 November Giveaway features top sirloin steaks

Last time I checked, the IdeaPad Z580 had some neat features, but definitely did not come with top sirloin steaks! :razz:

Cheers,
Zach

Zoom 5341J cable modem

After moving back to the midwest United States, I was immediately reminded of the frustrations of dealing with the primary cable internet provider–Charter Communications. They offer fairly good speeds, and when considering the price, the performance-to-cost ratio is outstanding. However, the reliability of the service leaves a lot to be desired.

One of the primary problems when I lived here before was the really poor modems (and corresponding Charter-infected firmware) that they provided. Never fear, though, as I came back with my own modem… or so I thought. Apparently in June of 2012, Charter announced that customers can no longer use their own modems. So, with my service came a free lease of a Cisco DPC3010. Not a bad modem, barring the firmware that Charter has loaded onto it (which eliminates the administrative login credentials, and thus, one can’t look at the logs). Though there is a user account for logging in (Username: chtruser Password: charter), the administrative functionality has been removed. The modem, however, (and again, likely the fault of the Charter firmware, and not the Cisco modem itself) refused to channel bond on downstream (upstream bonding is not yet offered). As a result, my downstream speeds were abysmal by comparison to the rated speeds.

After arguing with the customer service team at Charter, I finally convinced them to provision my modem. I have a Zoom 5341J modem, which is a nice, affordable modem that supports up to 8 bonded downstream channels and up to 4 bonded upstream channels. Within its administrative interface, it also features information regarding the lock status, modulation, channel ID, frequency, power, SNR, and (un)correctable errors. The modem also has a hidden menu which can only be accessed by going directly to the URL:

http://$MODEM_IP/RgEventLog.asp

replacing $MODEM_IP with the actual IP of the modem (which by default is 192.168.100.1, resulting in a full URL of http://192.168.100.1/RgEventLog.asp). This page shows all of the events in in the SNMP log, which is highly valuable information if you want to actively monitor your network status.

In any case, the new modem with the stock firmware (unmodified by Charter) is working beautifully with four bonded downstream channels (the maximum for my package). I strongly recommend the modem for its reliability and price point.

Cheers,
Zach