Important!
This article is one of the most-viewed on The Z-Issue, and is sometimes read thousands of times per day. If it has helped you, please consider a small donation to The Parker Fund by using the top widget at the right. Thanks!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 0 | 3.531 | 174.6 | 74.7% | 0.000 | 0.00% |
| FLAC 1 | 3.721 | 173.5 | 74.3% | 0.190 | 5.38% |
| FLAC 2 | 4.658 | 173.2 | 74.1% | 1.127 | 31.92% |
| FLAC 3 | 5.255 | 165.0 | 70.6% | 1.724 | 48.82% |
| FLAC 4 | 6.584 | 163.8 | 70.1% | 3.053 | 86.46% |
| FLAC 5 | 9.112 | 163.4 | 69.9% | 5.581 | 158.06% |
| FLAC 6 | 9.130 | 163.4 | 69.9% | 5.599 | 158.57% |
| FLAC 7 | 19.475 | 163.3 | 69.9% | 15.944 | 451.54% |
| FLAC 8 | 28.846 | 163.1 | 69.8% | 25.315 | 660.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 0 | 0.516 | 20.2 | 53.8% | 0.000 | 0.00% |
| FLAC 1 | 0.541 | 19.6 | 52.2% | 0.025 | 4.84% |
| FLAC 2 | 0.699 | 19.6 | 52.2% | 0.183 | 35.47% |
| FLAC 3 | 0.806 | 19.1 | 50.8% | 0.290 | 56.20% |
| FLAC 4 | 1.022 | 18.6 | 49.3% | 0.506 | 98.06% |
| FLAC 5 | 1.431 | 18.5 | 49.3% | 0.915 | 177.33% |
| FLAC 6 | 1.429 | 18.5 | 49.3% | 0.913 | 176.94% |
| FLAC 7 | 3.049 | 18.5 | 49.1% | 2.533 | 490.89% |
| FLAC 8 | 4.524 | 18.4 | 49.0% | 4.008 | 776.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
93 comments
Skip to comment form
The files are encoded by FLAC0 and FLAC8 respectively ;
Is the two encoder files that decoder get the same time? Why?
Author
Hello Chris,
I’m not sure that I understand your question. The charts show the differences in encoding times and resulting file sizes for two songs at all the various FLAC compression levels from 0 through 8. I simply wanted to provide some data points so that people could make their own decisions regarding the best FLAC compression level for their needs.
Cheers,
Nathan Zachary
Hi Zach
Thank you for getting back to me.
I want to know compression levels files FLAC0.flac or FLAC8.flac decompression timed to WAV file.
Song 2:
WAV -> FLAC
FLAC 0 encode 0.516s
FLAC 8 encode 4.524s
FLAC -> WAV
FLAC0.flac decode ?s
FLAC8.flac decode ?s
Thanks.
Author
Hello Chris,
Ah, I understand your question now. I don’t have that workstation any longer as it was showing its age quite badly (it had an Intel Core i7-960 [Bloomfield] @ 3.20 GHZ [quad-core with Hyperthreading]). I can do the decoding on my current machine, but please keep in mind that decoding is also processor-bound. My new machine has an AMD Ryzen Threadripper 3960X (24-core [48-thread] and 3.8GHz). Here are the stats for a new track (1984 by Ivan Torrent, but this one is 24-bit/48KHz (encoding and decoding):
I hope that information helps.
Cheers,
Zach
Hi Zach
This article was signposted during a search for information on the compression of WAV files using FLAC and whether using high compression settings affects sound quality.
Nearly all the discussion on this page is about finding the optimum trade-off between time invested in ripping a bunch of CDs and the cost of storage.
A friend noted he could easily detect the difference between playing a CD and then playing the FLAC file of the CD through the same system – the FLAC file was inferiro to the CD. Others have observed the same anomaly.
At first, one explanation was that to increase the compression, the FLAC codec discards data, so is not truly “lossless”. All information on FLAC assures me that regardless of compression level used the original WAV file can be reconstructed, bit perfect, from a FLAC file.
Paul McGowan, PS Audio, provides a possible explanation in a YouTube video at https://www.youtube.com/watch?v=ejE1XDxawMY
Further searching through the audiophile forums suggests the sound quality is improved if the rip is to WAV rather than FLAC; if FLAC is used then better sound quality is achieved if (i) the rip uses level 0 in preference to uncompressed FLAC and any other level; and (ii) all tags are removed from the rip. This is purely a consideration about sound quality, not about preferences or convenience.
When listening to music it is the “ears that have it”, not numbers in a technical specification. Are there alternative codecs, which deliver improvements in sound quality, such as ALAC?
However, is there a reasonable explanation for the perceived difference in the sound quality when replaying compressed FLAC files?
The explanation offered by Paul McGowan in the video makes a lot of sense to me, suggesting it is down to the way a rendering device is able to decode a FLAC file. Mark Palmos writes “Flac 0. Storage is so cheap these days, seems like a no brainer to me… also Flac 0 is less likely to hiccup on a slower system since decoding it is less demanding to decode.” (https://sound.stackexchange.com/questions/41964/flac-compression-level-comparison-efficiency-analysis/ )
By the way, another posting on the same page compares the total time for a rip using dbPoweramp set to different FLAC compression levels => “Here’s the total times for each rip, from clicking start, to end with all FLAC files done: Level 0 = 6:19; Level 5 = 6:18; Level 8 = 6:23” These times must be in min:sec.
So, Zac, have you any experience comparing the sound quality of FLAC files using different compression levels and is there an explanation for any differences, other than processing overhead when replaying the file?
Author
Hello,
Thanks for your comment. I have personally never heard any difference between a FLAC file and a WAV file on my systems. In my opinion, I think that the quality of the hardware decoding the FLAC will be more important than anything relating to the encoding process. Also, I should note that if I am ripping from a CD, I don’t rely on the ripper to convert the file to FLAC. Instead, I firstly rip the audio tracks from CD to WAV and then use the latest stable version of FLAC to encode. As once can’t always be certain of a particular application’s bundled version of FLAC, I find it best to follow this two-step process. To answer your question about comparing the sound quality of various compression levels, yes, I tried all of the ones mentioned in this article on my 2-channel system at home. I was not able to detect any differences.
Cheers,
Zach
Hi there!
There are no differences in FLAC, it is a bit by bit lossless format. We use it to master our audio files for our sound libraries and archive old game and movie projects that have a lot of files.
As a teacher of sound design and an audio engineer that has a mastering studio I can tell you that in the course of my teaching career, many students and colleagues also told me that they can hear differences between PCM-WAV and FLAC files. I always disprove them by conducting a blind A/B test. You can do one yourself using the awesome ABX comparison plugin for Foobar2000.
To save you the trouble I made a small experiment just now that I read your post.
I took a song from one of our libraries and converted it from our internal production format which is 96KHz/32-bitFP(IEEE) WAV/RF64 to both FLAC and WAV at 96KHz/24-bit.
Then I imported them into my workstation and played both in parallel with the second one (doesn’t matter which) playing in reverse phase.
Here you can see both files playing at normal volume together. I mark the phase reverse in one of the tracks.
>>> REMOVED LINK <<< As expected in bit-for-bit similar files, there is nothing outputted in the master as you can see. And I have my master configured at -120 dB range and at the highest frame rate for meter reporting which is a lot. The reason you don't see there noise form my hardware is because I'm running my workstation with a top-notch RME soundcard. I mark the output which is showing clearly -inf (minus infinity) at all time. Here are the master meters, my configuration at the top goes to -143 dB and the DAW has around 1530 dB of dynamic range. >>> REMOVED LINK <<< Nothing. Then I import the rendered mix of those two files and open them in an audio editor and then I add +120 dB of gain and I inspect all meters: Waveform, Spectrogram, Peak levels. Here are the results: >>> REMOVED LINK <<< Again, nothing! FLAC is a safe format for archive, in fact is a great format for archive. Only consideration with all those formats are immersive channel formats like 7.1.2 (Atmos), Higher Order Ambisonics, etc. But with a little reading of the manual and some testing all those are great options absolutely harmless to your audio. If you have any proof of otherwise I would be happy to hear it. To save you the trouble I already saw many videos of people claiming that they hear differences, but they lack the expertise to use audio tools as an audio laboratory. For example, many times people use inferior audio editors that cannot sync tracks correctly due to bad programming, even the most expensive ones don't do that well. I highly recommend the Reaper DAW for any serious experimentation with audio. It's already used by academia and forensics and don't get fulled by the low price, it's because its creator is an awesome person. Hope I helped you with your quest for fidelity, it's all for the glory of the sound arts! Cheers!
Author
Hello Panos,
Thank you for your reply. The point of my post wasn’t to claim that there are audible differences between WAV and FLAC, but rather to compare the different compression settings when it comes to encoding and decoding. That being said, the information that you provided may help others.
Cheers,
Zach
Hi Zach, thanks for accepting my comment.
I understood your point, I was replying to Fleuchary.
I saw that the links was removed, don’t really know if that is a policy for this site. The links just contain simple screenshots of my experiment and are hosted in the known ImgBB. If that is a site-wide policy then no problem, the images are just for your information.
You have a very nice discussion blog going on, kudos! 🙂
Cheers!
Panos
Interesting discourse since 2014. Sorry for being years late to the party.
I’m sure by now you have found https://hydrogenaud.io/index.php?board=67.25 which is probably the definitive place for FLAC discussions.
There is a key misunderstanding about FLAC, you (at the of your published writing) may not be aware about. FLAC is asymmetrical in terms of encoding and decoding time. When FLAC was developed one of the goals was to make a lossless encoder that is asymmetrical. Encoding times are longer, but decoding times near real-time.
With CPUs becoming more powerful, the encoding time is very low. In fact there is a project that helped spur greater compression and speed development in the main FLAC branch. That project is the FLACCL project, which leverages the GPU to compress FLAC files. Once again you can find more detailed information at hydrogenaud.io.
So for archival purposes, there is no reason to encode a FLAC at level 0. The time difference encoding between 0 to 8 is there but the space savings is there. Yes I understand that storage space has become cheaper over time, I just view it as “if i encode it at 8 which is very safe, i get the smallest possible file and i can fit more albums into my USB stick for backup)
My current process depends on source:
My system is using win10.
if CD source: Rip via CueTools 2.16 (latest as of jan 26, 2021)
Cuetools is set to FLAC level 8 compression via FLACCL (the gpu FLAC encoder) I find FLACCL faster on my system than using the reference FLAC 1.3.3
CueTools is also set to encode into tracks and create both a cue sheet, and a m3u file. Produce a log file of its rip, along with AccurateRIP logging and extraction log. This is done so I can recreate the cd if need be.
CueTools is also set to “GAPS Appended +HTOA” for those pesky hidden data tracks.
My layout is Artist (main directory holding) – year – album (disc/discnumber and disc publisher, disc id) The artist then year just means I can throw in multiple albums by the same person and keep it all straight.
For something I have purchased off a website like 7digital. I purchase in FLAC always. At this point I can run it through Cuetools set exactly the same, just to see if there is a difference in encoding levels.
In fact, this is how I came across this post. I was doing some research into what encoding level 7digital does to its FLAC. I noticed a 40 meg difference between their version of an album and my re-encoding of the same album that uses their FLAC files a a source. One can say “its only 40 megs”, multiply that across 200+ albums. There is space savings.
so TLDR: FLAC is asymmetrical in terms of encoding and decoding. It encodes files “slowly”, and decodes it very quickly. So you are basicly trading upfront time to encode a file to make an archive. Which is fine. 5 is the sweet spot between time encoding and compression. I prefer 8 because I want smallest size, and don’t really care about the time. I can run the encoding over night if need be.
Author
Hello Jon,
Thank you for your comment. You are correct about FLAC being asymmetric in terms of encoding versus decoding. With processors continuing to get faster and storage continuing to get cheaper, the level is becoming less relevant altogether. I think that ultimately it will come down to the particulars of an individual’s situation. As such, hopefully this post is still relevant today and can help people make informed decisions (by reading the comments as well). 🙂
Thanks again for taking the time to share your experience and comment!
Cheers,
Zach
G’day Zac
Apologies if this has already been covered in the plethora of comments. Recently I did some ripping tests using dbPowerAmp. At compression 0 the file came in at 526Mb, and when I subsequently tried to compress the file using JRiver I found that I could only get around a 5% compression using level 5, so not worth it.
However, when I re-ripped the CD (again using dbPA) and setting it to level 5 the file size came in at 328Mb so about 37% compression, and well worth it for the space saving. So it seems to me that unless you compress at ripping time you can’t save much space later on.
For me I would like to save hard drive space becuase it is a solid state drive at only 512Gb, but even more importantly I need to keep the files smaller to fit onto Micro SD cards.
Regards, Brett
(Sydney, Oz)
Author
Hi Brett,
These days, I’m just using the CLI for encoding WAV files into FLAC. I have opted for a two-step process of ripping in uncompressed WAV and then encoding into FLAC manually via CLI (truthfully, though, any CD ripper that you use does this two-step process behind the scenes). I haven’t ever tried ripping, encoding into FLAC at a certain level and then re-encoding at a different level, but I would think that doing so could potentially yield undesirable results. Multiple encodings could likely lead to poor quality and possibly even lossy quality, although I’ve never done any experimentation with that. Thank you for your feedback regarding your experience!
Cheers,
Zach
You can’t encode flac into flac – such encoding would require the player to decode the file twice. Instead, if you want to encode a flac file with a different level, you would need to first decode it and then pass it to flac encoder again. Since it’s lossless, there are no possible side effects.
Hi Zach,
I arrived at your site after searching for the optimum encoding level.
As it happens, I had already chosen 3 previously (down from 8) and I did actually notice a difference in sound quality.
Given that it’s lossless, I know you shouldn’t hear any difference – but I did (I wasn’t even listening for anything – it was purely incidental) – I was listening to a particular CD and thought something was different – better even – and when I checked the date on my files, I noticed it was one of my re-rips.
So perhaps 8 is a bit extreme?
Thanks for the article.
Cheers,
Tony.
Author
Hi Tony,
Those are very interesting findings. As FLAC is lossless, there really shouldn’t be any difference in quality upon playback. My guess is that the difference could be based on the decoding capabilities of the player. When I did my tests, I used my main equipment at home as well as a DAC and headphones. I wasn’t able to detect any differences, but if the equipment cannot “unpack” the FLAC files appropriately (due to outdated codecs or hardware limitations), it’s feasible that there was an audible difference.
Cheers,
Zach
Tony,
Our ears sometimes play tricks on us. You might accidentally “hear” the sound slightly differently once, maybe depending on the background noise or some other factor, and then confirmation bias kicks in. Rest assured, the quality is exactly the same, unless your CD was scratched. But in that case the ripping software would have shown some errors. If you do a blind test, the difference will go away.
Could you teach me ?
1. 1st Audio
Play Time : 04:20
File Size : 151,082,289 Bytes
—————————-
Channels : 2
Average Bit Rate : 4616 Kbps
Sample Rate : 96000 Hz
Bits per Sample : 24
Samples : 25027840
Compression Ratio : 100.17%
Production Info : reference libFLAC 1.3.1 20141125
2. 2nd audio (same file just size different)
Play Time : 04:20
File Size : 36,508,943 Bytes
—————————-
Channels : 2
Average Bit Rate : 1105 Kbps
Sample Rate : 44100 Hz
Bits per Sample : 16
Samples : 11497164
Compression Ratio : 78.30%
Production Info : reference libFLAC 1.3.1 20141125
3. 3rdn Audio (other file)
Play Time : 04:18
File Size : 108,765,340 Bytes
—————————-
Channels : 2
Average Bit Rate : 3361 Kbps
Sample Rate : 96000 Hz
Bits per Sample : 24
Samples : 24845474
Compression Ratio : 72.93%
Production Info : reference libFLAC 1.3.2 20170101
determined by Gom Audio
What is Compression ratio ? That’s matter related to file size ? Wich best compression ratio to converting to vorbis ogg format 500kbps, 16 bits sample, 44100Hz sampe rate ? any suggestion ?
Author
Hello Amy,
I’m not sure what you are specifically asking. The compression ratios indicate the file size as compared to the original, uncompressed audio track. If you’re converting to Ogg Vorbis, you can really choose any settings that you would like depending on the desired file size and corresponding quality. You can see more about the Ogg Vorbis compression levels here:
https://grahammitchell.com/writings/vorbis_intro.html
Cheers,
Zach
Hi guys,
Below some explanation in detail. The short version is that compression levels seems not always to be correctly translated by some audio brands firmware. In my case Naim. When converting the files to uncompressed FLAC files, problem was solved. Nevertheless, above is still a great article and before the firmware upgrade, this worked brilliantly. (I had it too at compression level 3)
Now the not so quick note on the compression levels.
I use a Naim system (first Super Uniti and now back again to Unitiqute2 with NAP100) and noticed with the firmware update the bit rate was not 1411 kbit/s anymore but random numbers and notably lower (ranging from 500 to roughly 900 kbit/s).
My entire cd collection (mostly 16bit 44.1kHz) is ripped in FLAC compression level 3. Although I cannot find anything on the Naim forums, it turns out that the software does treat compression levels badly. I first re-ripped some of my cd’s in FLAC with no compression. And yes, magic, the Naim pics up the higher bitrate (albeit being it a bit weird showing most of the time 1413 kbit/s which is obviously wrong as it should be 1411.2 kbit/s).
In anycase, this explained the decraded audio experience with the firmware upgrade, which after approx. 3 years I figured why. (Up till now I used my superuniti which I downgraded back 3 years ago when my music experience seemed to be worse with the newer firmware. Thanks to my unitiqute2 newest firmware, which showed the actual perceived bitrate, I now know why).
Naim claims the the UnitiServe is the best (and maybe their only) way to get exact rips. Anybody who understands a bit about machine language knows that any zero and one wrong can lead to a programme failure and therefore there are no errors if you rip with your computer.
I hope that my contribution here will help some people.
Regards
Jon
Author
Thank you, Jon, for sharing your experience here! I have never run into any problems with FLAC compression, but I don’t use any Naim hardware. This is a reason that I strongly suggest a vendor-neutral approach to decoding. In my particular case, I have a Linux server that I built, and it uses Asynchronous USB to go into my Pre-amp. So, the music server itself is decoding the FLAC files and THEN sending them to the pre-amp for DAC. It’s sad to me that a well-known equipment manufacturer like Naim doesn’t adhere to open standards with their firmware. If they did, the FLOSS decoder for FLAC would be implemented properly and there wouldn’t be any problems with the decoding of compressed files. Again, though, thank you for sharing your experience!
Cheers,
Zach
I am in the process of rejuvinating older recordings in various formats to compile and burn as an audio CD and as flac is able to accept metadata editing, to include CD text and ISRC code, It seemed to me that converting all to lossless flac prior to burning as a CDA would not need any compression and set it to zero (default was 5).
Imagine my gratitude for the information provided in your post! By setting the compression to zero I am enjoying the benefits of much faster conversion time.
Thank you!
Author
I’m glad that the post helped you with your decision regarding compression levels. 🙂
Cheers,
Zach
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.
Author
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
Quite interesting to revisit this topic after 2 years.
“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.”
We’re up to 20TB disks now and although flash disks (memory sticks?) have not gone that much bigger, they’re not really used for music storage or at least not to store an entire collection. I have USB in the car for sticks and Bluetooth from my phone. Then a network NAS at home that stores all my video and audio material, with the audio played through an RPI with IQaudio DAC – the NAS has 4 x 4TB so all in all, a fairly cheap setup that provides high quality playback and vast amounts of storage.
In terms of mobiles, I’ve got 128GB standard on mine (LG V40 with DAC) and another 128GB in the microsd slot. That’s more than enough space to store the stuff that I’m interested in listening to for a few weeks or months. I don’t expect to be able to store my entire collection on my phone …
And then of course, streaming has come on big time in the last few years so some people don’t even store stuff locally any more. There are a lot of options to stream DSD, MQA and other high quality formats from online services.
I don’t think space is that much of a big deal any more but I would still use some form of compression – level 3 seems pretty good. Of course with this much cheap storage available, no compression is likely to be an option for many.
Author
Thanks for your thoughts, Robby. I personally don’t like any of the streaming services as I would rather own the music and store it locally (preferably in hi-res, but at least CD quality). As far as storage is concerned, at least for me, it’s a LONG way off before I can store everything uncompressed. Having 1,000,000+ tracks takes up a lot of storage space even in FLAC, let alone uncompressed formats.
Cheers,
Zach
Space is still the consideration, we are only at the point where 2TB SSD’s are affordable, a quiet and low power consumption system shouldn’t be using a spinning disc anymore.
Processing power continues to increase far faster than storage. i9 is now 24 cores, a small investment to archive once and benefit from space savings forever is well worth it.
Author
That is certainly a valid perspective. As I use a music server away from my listening room, the space isn’t a concern for me. I don’t feel the need to go back and re-encode to save space, but for some people the space may be the most important resource. The point of the post was to provide some data points and allow people to make their own decisions based on their needs.
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
Author
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
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
Author
The beauty of it is that you have that choice. 🙂
Cheers,
Zach
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
Author
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
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.”
Author
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
replaygainvalues, and abcde is for encoding. The FLAC man page indicates thatreplaygainis 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
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.
Author
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
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
Author
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). 😛
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
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
Author
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
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/
Author
Thanks for the new link.
Cheers,
Zach
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.
Author
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
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.
Author
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
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.
Author
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
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.
Author
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
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.
Author
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
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).
Author
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
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
Author
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. 🙂
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.
Author
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
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
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.
Author
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
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
Author
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
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!
Author
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
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!
Author
You’re very welcome; glad that you found the information helpful. I have found level 3 to be a nice trade-off.
Cheers,
Zach
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
Author
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
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!
Author
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
What about playing a FLAC file through a FLAC Player? Will higher compression impact the quality when played?
Author
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
“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.
Author
Looking at the man page for FLAC, I see:
-3, --compression-level-3Synonymous 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
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
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-sideand--no-mid-sideare apparently inherent. 🙂Cheers,
Zach
Bravo dude.
You help me alot.
Cheers!
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
Author
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
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.
Author
Hi Daniel,
Glad that you found my comparison useful. 🙂
Cheers,
Zach
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.
Author
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.
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.
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).
Author
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
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.
Author
That’s pretty cool, so I will have to check it out. Thanks for the recommendation!
Cheers,
Zach