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

QualityEncode (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

QualityEncode (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

66 comments

Skip to comment form

    • Arve on Thursday, 12 June 2014 at 17:02
    • Reply

    For my own ripping script I stuck with the default. Encoding time is negligible compared to the ripping time anyway, but it’s nice to see numbers that tell me I wouldn’t have saved much more space with a higher level, despite my collection being about 10 times yours (too many CDs, too much cheap stuff on bandcamp).

      • Zach on Thursday, 12 June 2014 at 18:57
        Author
      • Reply

      Cool; I’m glad that you found the data useful! I decided to go with compression level 3 for mine, and have begun ripping everything. That’s a HUGE collection! My collection is completely CD, as I really have trouble with the quality of downloaded music. I know that it has gotten better over the years, but until FLACs or WAVs are available, I’ll just keep buying the discs. πŸ™‚

      Cheers,
      Zach

        • Arve on Friday, 13 June 2014 at 01:43
        • Reply

        Yeah, that was my attitude towards digital music as well for the longest time. Everything on bandcamp is choose-your-own format though, so I get FLACs there. And every physical buy you get there only includes a download, so I love it for being able to get other formats, like vinyl and tapes, and get a perfect FLAC included. I still buy way too many discs though, I’ll need an extra room soon.

          • Zach on Friday, 13 June 2014 at 09:15
            Author
          • Reply

          That’s pretty cool, so I will have to check it out. Thanks for the recommendation!

          Cheers,
          Zach

    • klausman on Friday, 13 June 2014 at 04:39
    • Reply

    For the record, the best ripping script I’ve ever used is abcde (a better cd encoder). It can be tailored to spit out just about any format and it automagically does tagging and the like.

      • Zach on Friday, 13 June 2014 at 09:18
        Author
      • Reply

      I had forgotten about abcde. I’ve just been using Asunder since it does everything that I need it to do, and I sometimes like to manually edit the CDDB entries that are automatically pulled. Now, if only there were some way to automagically pull in album art into each track… πŸ™‚

      Cheers,
      Zach

      Oh yeah, it would also be great if Gentoo could do the version bump of Asunder to 2.5, so that the nasty bugs were squashed.

        • klausman on Saturday, 14 June 2014 at 05:09
        • Reply

        Abcde allows you to edit the CDDB data it pulls. As for Asunder: I rip on a headless machine, so abcde’s text-only interface is preferrable for me.

    • Daniel on Sunday, 28 December 2014 at 14:13
    • Reply

    Nice to see this coparisson, I was about to do it myself! Thanks!

    I’ve been ripping my CD and vinyl collection over the last 15 years in MP3. But with current storage price and portable player’s ability to play better formats, it’s time to move to something better!

    After looking your table I’ll go for level 3 (1~2% less compression ratio than level 8) because I plan to use the files on my portable player without reencoding.

      • Zach on Tuesday, 6 January 2015 at 21:27
        Author
      • Reply

      Hi Daniel,

      Glad that you found my comparison useful. πŸ™‚

      Cheers,
      Zach

  1. Zach, this blog post was perfect and exactly what I was looking for. I am doing the same. Ripping a lifetime’s worth of CD’s into FLAC format, and I was wondering if I should change the default from 5. I’m moving to 3. 3 seems like a good tradeoff for less encoding time with negligible more space required.

    I’m using so I can run a headless Debian 8 machine with a CLI ripper. I’m currently simultaneously ripping to both FLAC and a low-quality mp3 which will only be used for the memory sticks for in the car.

    I hadn’t ever used abcde, but it looks interesting enough to switch to. Might give that a try.

    Thanks,
    David

      • Zach on Monday, 11 May 2015 at 14:23
        Author
      • Reply

      Hi David,

      I’m glad that the post helped you make a decision. I ended up going with 3 as well. I used Asunder (which is a GTK ripper) for the bulk of my music, but the CLI ripper that you mentioned seems interesting. Thanks for sharing your feedback!

      Cheers,
      Zach

    • Chris on Sunday, 12 July 2015 at 13:00
    • Reply

    I was looking for some idea of compression level:quality.

    If FLAC compression level 3 is most time efficient, which compression level is most time efficient/highest perceptible quality?

    I’m concerned about archiving my digitized collection at the highest perceptible quality (FLAC) for future conversion to mp3 (for use with mobile devices, etc.) Thank you for your article!

      • Zach on Sunday, 12 July 2015 at 22:05
        Author
      • Reply

      Hello Chris,

      FLAC stands for Free Lossless Audio Codec, so the compression level doesn’t affect the quality at all–it is always completely lossless. Regardless of the compression level that you choose for FLAC, you’ll be able to convert it back into WAV or uncompressed audio. The compression level simply changes the resulting file size, and the compute cycles needed to, for lack of a better term, inflate the audio back to its original uncompressed state. On modern systems, the difference in resources needed to play back the FLAC file is negligible. For your needs, any FLAC compression level will be fine.

      Hope that helps, and if you have any further questions, please don’t hesitate to ask.

      Cheers,
      Zach

        • Jon on Monday, 21 September 2015 at 15:32
        • Reply

        What about playing a FLAC file through a FLAC Player? Will higher compression impact the quality when played?

          • Zach on Monday, 21 September 2015 at 15:36
            Author
          • Reply

          Hello Jon,

          Can you please elaborate on your question? Higher compression shouldn’t impact the sound quality at all. It may require slightly more processing power in order to decode the FLAC before playback, but that’s about it. On modern systems, the difference in processing power needed for decoding should be negligible. Please let me know if you were wondering about something else.

          Cheers,
          Zach

            • StagNation on Thursday, 5 October 2017 at 12:37

            “Thanks for your input, Tom. I’ve never had to use these options and get true stereo separation with my FLAC files when playing them through my main system at home. BUT, since I use compression level 3 by default (flac -3), the –no-adaptive-mid-side and –no-mid-side are apparently inherent. πŸ™‚” You replied with this to Tom talking about getting true stereo separation. Is this still true for FLAC4? I see the efficiency of FLAC3 but I think 4 gives that little bit extra of compression, the reason I’m looking at FLAC in the first place, and doesn’t have the diminishing returns of the higher compression. So if FLAC4 still has the true stereo sound I will probably use that over 3, but I just wanted to make sure.

            • Zach on Thursday, 12 October 2017 at 12:17
              Author

            Looking at the man page for FLAC, I see:

            -3, --compression-level-3
            Synonymous with -l 6 -b 4096 -r 4 --no-mid-side

            -4, --compression-level-4
            Synonymous with -l 8 -b 4096 -M -r 4

            That means that the differences between 3 and 4 are: 1) that 3 uses a max-lpc-order of 6, whilst 4 uses 8; 2) that 3 uses no-mid-side whilst 4 uses adaptive-mid-side.

            Cheers,
            Zach

          • Tom on Thursday, 20 April 2017 at 16:12
          • Reply

          Jon –

          There is no quality loss with any level of compression. It is a lossless codec. However there are ways that the encoder saves precious disk space and still remain lossless. An example is how stereo is perceived. With that being said Mid Side and Adaptive Mid Side stereo is used in the encoding process to shave space. Below is my command line arguments for encoding my lossless uncompressed wav files. Hope you enjoy the quality in true stereo separation as intended by the artist. This could probably be accomplished simply with -3 -V (But I don’t like presets)

          -l 3 -V -p -e –no-adaptive-mid-side –no-mid-side –delete-input-file

            • Zach on Thursday, 20 April 2017 at 16:30
              Author

            Thanks for your input, Tom. I’ve never had to use these options and get true stereo separation with my FLAC files when playing them through my main system at home. BUT, since I use compression level 3 by default (flac -3), the --no-adaptive-mid-side and --no-mid-side are apparently inherent. πŸ™‚

            Cheers,
            Zach

        • Viorel on Saturday, 14 April 2018 at 21:28
        • Reply

        Bravo dude.
        You help me alot.
        Cheers!

    • Manuel on Saturday, 3 October 2015 at 14:45
    • Reply

    Thank you Zach, excellent article. I coincide with you that the choice of the level of compression depends on the size of the collection to want to ripped, and on the size of the device to storage.
    Apparently some participants of the comments, do not understanding that in the FLAC format, losses of sound quality do not exist, obviously in comparison to the source of the conversion. An information for them: All the mobile devices with Android 3.0 to more, already incorporate decoders for the FLAC format, so does not make sense to codify them with minor quality.
    Regardless,
    Manuel

      • Zach on Monday, 5 October 2015 at 11:56
        Author
      • Reply

      Hello Manuel,

      I’m glad that you found the article useful. I agree about the idea of lossless encoding. The compression level is basically tied to the amount of time to encode and decode, but has absolutely no effect on the quality of the sound.

      Cheers,
      Zach

    • pettis on Thursday, 14 January 2016 at 11:53
    • Reply

    Just wanted to say thanks for making this data available! I’m in the same spot you are–looking to re-rip my CD collection and make the switch from mp3 to FLAC. I wasn’t familiar with the FLAC’s 1-8 compression scale and unsure of the time/file size trade-off, so this post was quite helpful. I think I’ll go with lvl 3, too–I use portable music players a lot, so saving a few gigs here and there can let me pack more music for listening on the go. Using Grip on Linux Mint 17.3 xfce. Thanks!

      • Zach on Thursday, 14 January 2016 at 12:10
        Author
      • Reply

      You’re very welcome; glad that you found the information helpful. I have found level 3 to be a nice trade-off.

      Cheers,
      Zach

    • Pete D on Monday, 15 February 2016 at 20:50
    • Reply

    Just repeating others compliments, but thanks again for your valuable info. I’m using either foobar2000 or Kodi to rip my lifetime CD collection to Flac. Kodi prompted me for Flac level and Google sent me to your article. I’m sitting on a spare terrabyte in my 2 Terrabyte WD MyBook, and I will also keep an offsite backup for my music collection and home movies on a cheap 2 Terrabyte WD MyPassport Ultra (portable hard-drive for around $129 at Newegg).

    I see that efficiency “knee” at Flac Compression Level 3 as well, so that was my first thought too. But here I will differ a bit. Since I’m ripping with an old, nearly trashed HP Laptop running VIsta with a Pentium T4300 Dual Core 2GHz with 3G memory, time is worth more than storage space to me, so I’m gonna go with Flac Level 1 and may even go with Level 0, now that I’m not afraid of what might happen.

    So thanks again for doing up those stats and explaining the differences!

      • Zach on Tuesday, 16 February 2016 at 12:30
        Author
      • Reply

      Hi Pete,

      Thanks for the nice words, and I’m really glad that you found the information helpful! The important thing to remember is that ALL FLAC compression levels result in lossless sound. The only difference is the amount of processing power to encode/decode, and the corresponding file size. In your case, you may be right with the FLAC level 0.

      Again, glad to help! πŸ™‚

      Cheers,
      Zach

    • mark on Saturday, 2 April 2016 at 16:51
    • Reply

    Thanks Zach,

    Ditto on everyone else. Big CD collection to archive and save. Your post was just what I was looking for. Bought a fat new laptop, jumped ship from Apple and need to actually know what I am doing.

    Happy listening,

    Mark

      • Zach on Tuesday, 5 April 2016 at 12:14
        Author
      • Reply

      Hi Mark,

      You’re welcome. I’m glad that you found the post useful, and good luck with the ripping. It takes quite a long time to go through a large collection, but I’ve found that it is ultimately rewarding. πŸ™‚

      Cheers,
      Zach

    • Bob on Wednesday, 13 April 2016 at 22:47
    • Reply

    I’ve been doing the same thing recently, going though boxes of old cd’s ripping them to flac. Some I ripped to mp3 15 or 20 years ago and have some that are only at 128, most are 160 to 192k but still pretty low quality by todays standard. I started ripping them all at 320k or VBR0 maybe 8 to 10 years ago but that’s still not great quality.

    I’ve been compressing them all at 8. Time wise it makes almost no difference, the default of 5 took maybe 1 second per song, 8 takes maybe 3 seconds. It might only save 10-15MB per album, over alot of cd’s that can add up. If quality isn’t effected I can wait the extra 10 seconds per album.

      • Zach on Wednesday, 13 April 2016 at 22:50
        Author
      • Reply

      Hi Bob,

      To me, it wasn’t necessarily about the quality (seeing as *all* FLAC compression levels result in a lossless file). It was more about the time of encoding, and the resources needed to decode. As you can tell from the article, I decided that FLAC compression level 3 was best for my needs, but really, unless you’re 1) ripping on a machine that is quite old, or 2) trying to play back the files on a machine of similar age, the compression level probably won’t be all that big of a deal. I just found that level 3 was the best trade-off between encoding time, decoding resources, and file size.

      Cheers,
      Zach

  2. Great article. I’ve been personally compressing to level 8 to save the most amount of space. For me, when ripping CD’s the process takes so long anyway that a few extra seconds per track doesn’t matter. If the CD ripping program compresses while reading data for the next track then it really doesn’t matter at all. Re-encoding for mobile, where space is usually limited, takes a while so I think that I might stick with level 8. That way I can stick with lossless rather than lossy compression. Do you know of any battery life tests comparing different FLAC levels? That would be my only concern with having that much compression.

      • Zach on Tuesday, 26 April 2016 at 11:02
        Author
      • Reply

      Hi Kevin,

      I agree with many of your points. When re-encoding for mobile, my method is to take the FLAC files and turn them into fairly high-quality OGG Vorbis files. I do so using a great script that I found called FLAC2all, which copies the metadata and even the album art. The command that I use is:

      /usr/bin/python2 ~/stuff/music/flac2all_v3.38.py vorbis ~/stuff/music/flac/ -v 'quality=7' -c -o ~/stuff/music/ogg/

      Which uses the OGG VBR quality 7 encoding.

      Anyway, to directly answer your question, no I haven’t see any battery life comparisons with FLAC levels. What I can tell you is that the processing power to decode the FLAC should be the only influencer on battery life. With modern processors in mobile devices, I wouldn’t expect to see any ascertainable difference in battery life based on FLAC compression levels.

      Hope that helps.

      Cheers,
      Zach

      1. I use M4A to play music on my cell phone. The AIMP converter is perfect for doing the conversion since it maintains the metadata and the covers. Also, all copies of CD to FLAC I do with compression level 8. Since I met AIMP, I have never left <3 haha. regards.

        P.D: I'm using google translate

    • clever on Sunday, 18 September 2016 at 23:18
    • Reply

    Hi Zach,

    thx for the info provided here.
    Just wanted to point you in a direction if you still need something to pull artwork automatically. I was working on XBMC (Now Kodi) some time ago and wanted to do the same for video files and found tools like “Media Companion” and similar (sorry can’t remember more details). They will do the trick for you or others looking at this.
    Plex has everything inbuilt but now we’re really off topic.

    Cheers

      • Zach on Monday, 19 September 2016 at 21:12
        Author
      • Reply

      Thanks for the recommendation! I usually just either scan the covers for my albums, or pull them from a site manually. I figure that it only takes a couple minutes at most, and it only has to be done once. πŸ™‚

    • Erik Andersson on Tuesday, 18 April 2017 at 06:48
    • Reply

    So…have I understood this correctly:

    1. A higher compression rate (resulting in a smaller file-size) means it will take more time when ripping/encoding?

    2. A higher compression rate means that more processing power will be used for decoding/playback?
    2a. If correct, would that mean that someone like me, who keeps several applications and browser tabs open at once, could possibly benefit from using compression level 0, since it would mean whatever media application I am using would need less time making files “ready-to-go”?

    I hope my question is clear enough, this is something I really want to find an answer to, because despite having a pretty powerful computer, as I mentioned before I usually have a lot of things going on at the same time when using the computer, and thus I would not let a pass at the chance of relieving some workload (or not making it bigger at least).

      • Zach on Tuesday, 18 April 2017 at 11:03
        Author
      • Reply

      Hello Erik,

      1. Yes, using a higher compression rate means more time to encode (as shown in the table). Ripping time is not impacted, because ripping is always to uncompressed WAV. As I see it, though, the difference in time to encode is essentially negligible.

      2. Yes, with higher compression settings, more processing power is required for decoding and playback. Again, though, with any modern processor (which would be the bottleneck for decoding/playback), I think that you will see very little difference. If you’re running an old Pentium 4 or something like that, then you may see some substantial difference when decoding. However, even with my ageing first-generation Intel Core i7-960, I don’t see any spikes when playing back my tracks (ripped in FLAC compression level 3).

      I would highly doubt that your computer is under full load with just several applications and browser tabs open at once. As said, even with my older processor, I have no trouble playing back tracks whilst compiling Chromium from source (which is extremely processor-intensive).

      I hope that answers your questions, but if not, please feel free to reply.

      Cheers,
      Zach

    • Larrie on Saturday, 27 May 2017 at 19:06
    • Reply

    My head is spinning but love the data here. I understand file size difference in 2nd song but why is ratio better in 2nd song? Thanks for the info from all of you guys.

      • Zach on Sunday, 28 May 2017 at 10:51
        Author
      • Reply

      Hello Larrie,

      Thanks for your question. My guess is that the ratio is better in the second song because of actual song itself. The first song is full of instrumentation and is very seldom quiet. The second song is a choir, and there are several points of “silence” or very little data. With those points, the compression is able to take those seconds and essentially compress them down to nothing without losing any data (since it is lossless after all).

      That’s my best explanation for the noticeable ratio difference between the tracks.

      Cheers,
      Zach

  3. Hey Zach,
    Great info! Thanks for taking the time to explain this. It’s driven me to the flac documentation and I’ll be working on some scripts to help me manage my library as well.

    Questions:
    1. Audio sampling. I believe I’ve gained theoretical knowledge of bit depth and sample rates. I’ll have to do more reading to fully grasp them though. My immediate question is, it there anything I can/should/can’t/shouldn’t do about sampling or bit depth if my goal is to best preserve a standard cd? Will larger time samples result in better compression?

    2. Ripping. Sitting at your computer and ripping cd’s is time intensive, however kicking off a long running job while you go do other things is “cheap”.
    What if you rip from the cd raw, or at flac0, THEN kick off a script to re-encode the files at flac8. This would allow you to maximize your “rips per hour” and still reach optimal compression. Also, you could trade some of that time saved to enable some of the other “accuracy” checks to ensure that you have the best possible rip.

    I plan to put together the script referenced in “2”. This would give me a ‘master’ copy from which I could create copies for other mediums.

      • Zach on Thursday, 15 June 2017 at 12:49
        Author
      • Reply

      Hello Jody,

      I’m glad that you found the write-up helpful. FLAC is an outstanding format! For your questions:

      1. Nope, you don’t have to do anything special regarding sampling or bit depth when ripping from CD. The audio on a standard CD has a sample rate of 44.1KHz and a bit depth of 16. That is normally written 44.1/16, and shows that there are higher formats out there. For instance, I have a few albums from Bandcamp (one that comes to mind is Adam Fielding’s Pieces) which is 48/24. Those formats can go up to 192/24, but regardless of the original format, FLAC will, by default, keep the sample rate and bit depth the same.

      2. To me, it wasn’t worth scripting. I had to rip one CD at a time anyway, so the encoding difference didn’t really matter. Ripping to WAV seems pointless to me, since FLAC decodes directly back into WAV. So, I just set my ripper (Asunder) to rip and encode at FLAC 3, and that’s that. πŸ™‚

      Hope that helps.

      Cheers,
      Zach

      • Sean on Friday, 28 July 2017 at 12:55
      • Reply

      ALL CDs are 44.1kHz*16b unless otherwise noted, and the overwhelming majority of lossy files will decode to that.
      All the FLAC encoders I’ve seen will use the source sample rate and bit depth unless you specifically force them to do otherwise. In other words, your software should handle that itself.

      You will find no advantage in ripping initially to FLAC 0, then converting – the encode time will be small to negligible in comparison to the rip time. Also, a FLAC 0, FLAC 9, and WAV of the same song will all supply identical audio data; that is where the term ‘lossless’ comes from. Thus, any FLAC file can serve as a master/archive copy, regardless of compression level.
      If you want to best preserve the quality of your CDs, use a program that will prioritize quality. Despite its age and its clunky UI, Exact Audio Copy is the best available and I use it because of that, but there are other good options.
      The best way to save time? Get another CD drive and run one instance of your ripper for each.

        • Zach on Friday, 28 July 2017 at 13:01
          Author
        • Reply

        EVERY CD is 16/44.1, which is why downloaded tracks can be higher resolution these days (like 24/192). Your comments about all FLAC levels being lossless are correct. At any point in time, if you do a flac -d $FLAC_FILE, you’ll end up with the same uncompressed data. I personally don’t use EAC because I don’t use Windows. As a Linux user, I’ve found that abcde is nice for a terminal-based application, and for a GUI, I prefer asunder.

        Cheers,
        Zach

    • Sean on Friday, 28 July 2017 at 12:24
    • Reply

    This table is very helpful; thank you for all the testing. I assume decode times have a similar trend to encode times?
    I’ve been going through my family’s CD collections lately, re-ripping them as FLAC rather than the inconsistent-level mp3s they were originally put into. With 512GB microSD cards(!) on the market and 1TB being par for HDDs, it’s time.
    Looking at my EAC settings, everything is going in as FLAC level 6 which was the default. I’m not too concerned, but I’ll see if I can get a converter to put them all at FLAC 4 for the final deployment – cost viability of microSD cards tops off at 128GB or 200GB as of mid-2017, so IMO as powerful as phones are nowadays that extra bit of space is worth the trade compared to FLAC 3. The difference does seem negligible for a laptop or tower.

      • Zach on Friday, 28 July 2017 at 12:27
        Author
      • Reply

      Hello Sean,

      You’re welcome, and I’m glad that you found the table helpful. Decode times are essentially negligible on any modern hardware. I ended up going with FLAC level 3 for my needs, but everyone is different. The only place where I don’t use FLAC is on my mobile. I chose ~256Kbps VBR OGG.

      Cheers,
      Zach

        • Sean on Friday, 28 July 2017 at 13:07
        • Reply

        My phone (HTC M9) has a very respectable sound chip and a remarkably good music player, plus a microSD with support for up to 2TB(!!), so I can get away with FLAC files if I want to. I have yet to test whether my car’s sound system is good enough to warrant it though.
        Do your OGG files compare well to mp3s? I’ve read they aren’t well-optimized for high bit rates, but I’ve never actually tried them to find out. I’ve only ever seen them as laughably low bit rate sound effects for UIs and video games.

          • Zach on Friday, 28 July 2017 at 13:20
            Author
          • Reply

          I have a very high-end mobile as well, and am using a class 3 microSD card. I’ve found some stuttering with FLAC (even when using an AUX cable), which is why I went with Ogg. Space wasn’t the concern. Also having a fairly nice set of Focal ES 165KX3s in my car, I don’t notice much of a difference using OGG. I’ve never liked MP3 because even the higher encodings sound tinny to me. Out of lossy formats, I only use OGG. For almost everything, though, I use FLAC. On my home system, which is comprised of the Focal Aria 948s, the difference between OGG and FLAC is HUGE.

          Cheers,
          Zach

    • smoneck on Tuesday, 29 August 2017 at 10:22
    • Reply

    Hey Zach,

    thank a lot for the article! Extended your analysis and wrote and article here:

    https://music.stackexchange.com/a/61484/43702

    Interestingly the FLAC-3 is often worse than FLAC-2 and depending on the genre there is a big difference between FLAC-3 and FLAC-4. I hence recommend FLAC-4.

    Cheers
    Stephan

      • Zach on Tuesday, 29 August 2017 at 10:55
        Author
      • Reply

      Hi Stephan,

      Glad that you found the article helpful. Good extension of it. I disagree that tables are harder to read than graphs, but that’s just me. I find graphs and other visual “aids” to detract from data representations, but again, that’s my personal opinion. I also never found a need to encode more than once since my analyses were all done on a dedicated host that wasn’t performing any other tasks.

      Cheers,
      Zach

      • smoneck on Tuesday, 29 August 2017 at 16:29
      • Reply

      I was asked to move the article to another place (music –> sound design) and added some passages. So the link now is:

      https://sound.stackexchange.com/questions/41964/flac-compression-level-comparison-efficiency-analysis/

        • Zach on Tuesday, 29 August 2017 at 16:29
          Author
        • Reply

        Thanks for the new link.

        Cheers,
        Zach

    • beardsd on Thursday, 7 September 2017 at 08:56
    • Reply

    I use a headless system to perform all my ripping. I set it up to rip at level 8 compression. I don’t sit and watch it, but just put in a disk it rips it, and ejects it. I have many TB of flac files, and the time to do the extra compression once seems worse to me than the ongoing cost of additional storage no matter how cheap it gets, as my media collection keeps growing.

      • Zach on Thursday, 7 September 2017 at 10:39
        Author
      • Reply

      That’s certainly one aspect to consider. Space is not a concern for me, and as I have some very old machines, I’m more interested in the decoding time than the encoding time. Thanks for your feedback!

      Cheers,
      Zach

        • beardsd on Thursday, 7 September 2017 at 14:51
        • Reply

        Zach,
        I am interested in what you are seeing for decoding times. I have seen little here on that, but much more on the encoding time unless I missed it. But as I am starting to look into some portable flac media players that may actually become an issue.

        Thanks

          • Zach on Thursday, 7 September 2017 at 14:54
            Author
          • Reply

          I don’t have any full tests yet, but am planning on doing so at some point in the future. What I’ve seen is that decoding can really cause CPU utilisation spikes on very old hosts. The two in particular that I have seen problems are: 1) my mobile from an older microSD card, and 2) a completely obsolete host with an AMD K6-III (yes, I know that’s from 1999, but it still works). πŸ˜›

            • beardsd on Thursday, 7 September 2017 at 15:30

            Much like you, I also mostly use old or legacy type hosts. The majority of my systems are in the 10 – 15 year old range, I respect that you actually still have an AMD K6 machine up and running πŸ™‚

            Thanks

  4. I took a look at abcde – that was mentioned and recommended above and flac’s manual page.

    At abcde’s wiki page i found that abcde will “Calculate replaygain values for the individual file (or the album as a single unit)”.

    At Flac’s manual page I found:
    “–apply-replaygain-which-is-not-lossless[=]
    Applies ReplayGain values while decoding.
    WARNING: THIS IS NOT LOSSLESS. DECODED AUDIO WILL NOT BE
    IDENTICAL TO THE ORIGINAL WITH THIS OPTION.”

      • Zach on Friday, 19 January 2018 at 13:23
        Author
      • Reply

      Hi Magnus,

      I think that you’re looking at the wrong option in FLAC’s manual page. The page for abcde indicates that it calculates replaygain values, and abcde is for encoding. The FLAC man page indicates that replaygain is lossless during encoding, but the --apply-replaygain-which-is-not-lossless[=], which is a decoding option is NOT lossless. They are two separate flags, so I don’t think that there’s a problem here with abcde’s encoding.

      Cheers,
      Zach

    • Dave B on Thursday, 1 February 2018 at 12:06
    • Reply

    Hi, reading this with interest. Thanks for the handy table. Very instructive!

    First of all, I am new to FLAC but understand the concept of lossless.

    I am looking at purchasing a portable media player, one of the Chinese ones like the Xduoo X3, D9 or NiNTAUS X10 for high-quality audio on the go.
    As these are portable devices with potentially quite slow (but dedicated) processors and, probably very little RAM, would I be correct in assuming that ripping my audio to Flac 0 on my computer would ultimately be less taxing on the device and might speed up the ‘clunky’ interface?

    I’ve read that the interfaces of some of these portable players is laggy and, after reading this, think it might be down to FLAC 7 or 8 being used, and the on-the-fly device decoding is slowing everything down?

    Or maybe it’s just terrible UI/UX design. ;0)
    Cheers

      • Zach on Thursday, 1 February 2018 at 12:16
        Author
      • Reply

      Hello Dave,

      Thanks for your comments and questions. FLAC 0 will generate a larger file size, but will be decoded with less processing power. I haven’t personally tried any FLAC files on my slower devices (like portable music players). For those devices, I generally encode from FLAC into OGG Vorbis. I would venture a guess that the devices could use FLAC, and that FLAC 0 would be the least taxing on them, but I can’t say with certainty. My recommendation would be to purchase the player that you want and then try a few tests using the same track: 1) encoded as a FLAC 0; 2) encoded as a FLAC 3; 3) encoded as OGG Vorbis. That should give you a reasonable set to use as a comparison.

      Hope that helps.

      Cheers,
      Zach

    • Bruce on Friday, 9 February 2018 at 18:29
    • Reply

    Nice to know. For my own efforts I’ll be using max compression. This is due to sharing the flac with my mobile device, where the savings, although small, adds up quickly.

    –Bruce

      • Zach on Saturday, 10 February 2018 at 10:39
        Author
      • Reply

      The beauty of it is that you have that choice. πŸ™‚

      Cheers,
      Zach

    • Anders Erichsen on Wednesday, 21 March 2018 at 09:57
    • Reply

    Well… I must say i’m going all in on the highest compression. Even if one can get a 400 GB SD card it still takes a lot of space so every single bit tends to be important.

    Are you able to quickly change multiple file name by terminal/dos commands? Mostly it takes ones time to do the names of the files.

    Yehovah bless you

    Anders

      • Zach on Wednesday, 21 March 2018 at 10:58
        Author
      • Reply

      Hello Anders,

      What exactly are you trying to do by changing the filenames? I’m sure that there is a way to take care of it in a batch, but it depends on your OS/shell and your goal.

      Cheers,
      Zach

    • ProDigit on Thursday, 19 July 2018 at 16:22
    • Reply

    Computers are getting more powerful.
    Corei9’s are soon going to have 16 cores.
    There’s no reason anymore to encode in size 0.
    Sure, USB sticks are getting larger, and the cost of a single 256GB flash drive is affordable,
    But music databases are ever increasing.
    if you had a fixed amount of songs you’d save to a USB disc, today is the time when you can afford to be flexible with compression, because you get most disc space for the least amount of money.

    Truth be said, I have about 1000 DJ mixes of each 2 hours in length. This doesn’t fit on even the largest USB stick, not even at low bitrates.
    For me to make it happen, I’ll have to choose another, lossy format. WMA, and live with the minor artifacts.
    WMA VBR Q0 compresses at about 64kbits (from 48kbits for audio books, and up to 88kbits for high quality audio files).
    It’s a portable container, that currently beats OPUS at low bitrates.
    However, Opus is best at 96kbits.
    Much better than any other. Pretty transient.
    The meaning for WMA VBR Q0, is not to be transient, nor recoding, but to capture as much audio in as small of a space possible, without sounding overly annoying with artifacts.

    Anyway, back to Flac; I would consider your future. Hard drives are not going to surpass much beyond the current 2TB disk size. And Flash memory won’t be affordable much above 1TB in the near future.
    if you add more and more music to your library, i would consider compressing at the maximum compression setting.
    It is expected that future devices like cellphones will compress music at the same speed as current desktops, so I would really try to give it your best in compression.

      • Zach on Thursday, 19 July 2018 at 16:28
        Author
      • Reply

      Thank you for your opinions regarding compression and storage space. I don’t agree as I use some extremely old hardware in certain cases. That being said, that’s why I’m glad that we have many options for compression schemes. πŸ™‚

      Cheers,
      Zach

Leave a Reply

Your email address will not be published.