Maximising FLAC compression to minimise disk usage

Tinkering
1

I thought I’d throw this out there for those among us that were sucked into the audiophool vortex of believing that uncompressed FLAC files sound better than compressed FLAC files. Given you now have Roon and Roon does the decoding on the server end rather than your endpoints :scream: you have the luxury of tossing belief and compressing your FLAC library to minimise disk usage. One less audiophool myth to concern yourself with :disappointed_relieved:

Here’s a simple way to do it using a Linux terminal (which could just as easily be a ssh session on your multicore NAS). If your music is stored on a NAS and your NAS has a decent multi-core processor you’re better off running this on the NAS from a ssh session than doing so from your PC with the NAS folders mounted.

Change into the root folder containing your music library and run the following:

find -type f -name \*.flac -print0 | xargs -0 -n1 -P4 flac -f -8 --totally-silent --preserve-modtime --verify --no-padding

Change -P4 to -Px where x is the number of CPU’s in your machine.

When you’re returned to the command prompt all sub-folders of the folder you started in will have been processed.

If you prefer to see movement so you know it’s not hung (which it won’t) omit --totally-silent from the parameters.

You can speed up the process even more by eliminating the --verify parameter … you don’t use it when you create FLAC files do you?

Your tag metadata will survive the re-encoding untouched.

Windows users could of course use dbPoweramp for the same outcome.

2 Likes
2

A quick scan learns that most of my FLACs are at compression level 5.

No wonder my system sounds as it does…

1 Like
3

According to audiophool lore it would sound at least 5x better if you removed that pesky compression.:joy:

4

That would be terrible: I’m afraid neither me nor my system would be to handle this.

That – and less compression would leave my NUCi5 with nothing to do, leading to a dull and lifeless sound (curtains drawn, blacks becoming greys, soundstage shrinking, space between instruments disappearing into well eh… thin air).

I think I’m fine. :slight_smile:

2 Likes
5

Any idea what level of compression Tidal uses in its FLAC files?

6

This would suggest Flac 3 is the optimum trade off.

However the additional size reduction is small and given the price of strorage these days it seems that there is not much point in bothering about thie level of flac compression.

http://z-issue.com/wp/flac-compression-level-comparison/

7

That depends on the level of compression already applied. If 5 or more I wouldn’t bother. I noticed some flac files that were large enough to look like they might be 24/96 so I figured I’d re-process them… according to flac the compression achieved between 40-50% reduction in file size. Must be those files had little compression applied initially.

8

Just got home and checked the outcome on a rather large directory tree on one of my drives… total saving 25GB…not bad for zero effort.

1 Like
9

You could take it further and de-embed any artwork from your files to a single jpg in the folder. Easier to review and replace as well.

I’m going to compress my FLAC files to -11…

10

I did that some time back across my entire library. Wrote a resumable bash script to get the job done - it basically saves the embedded artwork as folder.jpg, folder1.jpg etc - it will not overwrite an existing folder.jpg, rather generates a new filename. It’s trivial using a file manager to delete the smaller instances thereafter. Happy to share it if it’ll be of use.

11

Please share.

12

Got to find it…on a memory stick somewhere. Got it…

First generate a list of folders/directories to be processed:

find . -type d -exec ls -d {} \; >> ./files.list

Now parse and process it:

[code]#!/bin/bash

expects a list of directories to be processed

cwd=$(pwd)
filelist=./files.list

set the number of seconds to run

multiply by 3600 for each hour

(( seconds_to_run= 24 * 3600 ))

echo “Run duration: $seconds_to_run seconds”
echo "Albums to process: " $(wc -l $filelist)

while [ -s $filelist -a $SECONDS -lt $seconds_to_run ] ; do
file=$(head -1 $filelist)
echo Removing image tags from: “$file”
cd “$file”
for f in *.flac
do
metaflac --export-picture-to=zzfolder.jpg “$f”
metaflac --preserve-modtime --dont-use-padding --remove --block-type=PICTURE,PADDING “$f”

flac -f --preserve-modtime --totally-silent -8 “$f”

done
cd $cwd
# remove current file from list
sed -i.prev '1d' $filelist

done[/code]

3 Likes
13

Not worth the effort when you can get HDD drives 80 times that size for well under 100 bucks.

14

YMMV, opening a terminal window and pasting in a one liner is hardly effort.

15

For those of us with large RAID arrays with large disk sizes any expansion is going to cost a lot more than $100 I can assure you. I also need to factor in the sunk cost of the drives I remove, you can’t sell them on for too close to the retail price.

16

160GB freed up after processing all FLAC content on the drive…personal time invested … 20 seconds.

17

Worth noting that I CAN and so can other people I know her a difference between uncompressed and compressed FLAC. The key is that the differences are very subtle and highly dependent on the equipment you are using. You really can hear a major difference on endpoints and even servers with low processor power and memory. Compression at level 8 places the greatest strain on processors and memory to decode in real time. Higher bitrates and 96kHz and above also place more load. Analysis of the decompression algorithm performance on high end machines (MOST of these produce less sound alteration anyway) shows that high compression and high bandwidth FLAC decompression does result in “rounding errors” in the decompression.

Again, it is not a big problem and you would not notice the difference without spending a long time comparing and on quite expensive equipment in a very well designed environment. Back when FLAC was introduced decompression could use up all of the CPU on a computer decoding it and distort badly. We have better processors and algorithms now.

18

I have no words…

1 Like
19

Exactly: that was in 2000 / 2001. Nowadays processors are powerful enough to decompress FLACs at near idle. And as Roon Core handles the decompressing, removing that load from the endpoints, compression levels are less important than they used to be. Of course the FLAC encoder/decoders are more efficient too. For version 1.0.4 Xiph.org states “…Drastically reduced memory requirements of encoders and decoders” and for the latest version 1.3.1 they state: “Improved decoding efficiency of all bit depths but especially so for 24 bits for IA32 architecture”.

Nice to see that they still develop it.