Lossless Compression Test, FLAC, WP, MA, TAKC, TTA, LA, OF, SHN, WMA Options

[saratoga]

Does flake -11 play in Rockbox? Is there an example file I can try?

[skamp]

Flake -11 compresses my music collection only 0.2% better than FLAC -8…

[IgorC]

and at cost of decoding speed.

[lvqcl]

flake-svn-r114: -0 to -10 are subset compatible, -11 and -12 aren't. (For CUETools.Flake, -9 to -11 are not compatible).

My Samsung R0 can play non-subset files (with Rockbox and with original firmware as well).

[C.R.Helmrich]

Flake -11 compresses my music collection only 0.2% better than FLAC -8…

Thanks a lot, that answers a question I was about to ask.

Chris

[2012]

Does flake -11 play in Rockbox? Is there an example file I can try?

flake -12 Sample:
http://www.hydrogenaudio.org/forums/index....showtopic=97370

rockbox failed to play this for me on an Android (2.3) device.
On a side note, native FLAC support in newer Androids plays this file with no issues.

Flake -11 compresses my music collection only 0.2% better than FLAC -8

What version?
I would expect 0.6%-1.2% with SVN-r264.

and at cost of decoding speed.

Not by a big margin AFAICT.
FLAC decoding is fast enough to the point where other factors (like I/O in bad storage devices) might be more relevant.

Decoding support and maybe streamability are real issues with non-subset files. Decoding speed(when the support is there) is not!

This post has been edited by 2012: Oct 9 2012, 03:21

[A_Man_Eating_Duc...]

I'm have already seen some weirdness with Flake v0.11, -5 compresses better than -6.

Where can i get a copy of Flake SVN-r264?

Should i be using Flake v0.11 or r264 for the test?

This post has been edited by A_Man_Eating_Duck: Oct 9 2012, 20:15

[2012]

I'm have already seen some weirdness with Flake v0.11, -5 compresses better than -6.

Interesting.

Here is the full help for reference:

CODE

Flake: FLAC audio encoder
Version SVN-r264
(c) 2006-2009 Justin Ruggles

usage: flake [options] <input> [-o output.flac]
options:
       [-h]         Print out list of commandline options
       [-q]         Quiet mode: no console output
       [-p #]       Padding bytes to put in header (default: 8192)
       [-0 ... -12] Compression level (default: 5)
                        0 = -b 1152 -t 1 -l 2,2 -m 0 -r 3 -s 0
                        1 = -b 1152 -t 1 -l 2,4 -m 1 -r 3 -s 1
                        2 = -b 1152 -t 1 -l 4   -m 1 -r 3 -s 1
                        3 = -b 4096 -t 2 -l 6   -m 1 -r 4 -s 0
                        4 = -b 4096 -t 2 -l 8   -m 1 -r 4 -s 1
                        5 = -b 4096 -t 2 -l 8   -m 1 -r 5 -s 1
                        6 = -b 4096 -t 2 -l 8   -m 1 -r 6 -s 1
                        7 = -b 4096 -t 2 -l 8   -m 3 -r 6 -s 1
                        8 = -b 4096 -t 2 -l 12  -m 6 -r 6 -s 1
                        9 = -b 4096 -t 2 -l 12  -m 6 -r 8 -s 1 -v 1
                       10 = -b 4096 -t 2 -l 12  -m 5 -r 8 -s 1 -v 1
                       11 = -b 8192 -t 2 -l 32  -m 6 -r 8 -s 1 -v 1
                       12 = -b 8192 -t 2 -l 32  -m 5 -r 8 -s 1 -v 1
       [-b #]       Block size [16 - 65535] (default: 4096)
       [-t #]       Prediction type
                        0 = no prediction / verbatim
                        1 = fixed prediction
                        2 = Levinson-Durbin recursion (default)
       [-l #[,#]]   Prediction order {max} or {min},{max} (default: 1,5)
       [-m #]       Prediction order selection method
                        0 = maximum
                        1 = estimate (default)
                        2 = 2-level
                        3 = 4-level
                        4 = 8-level
                        5 = full search
                        6 = log search
       [-r #[,#]]   Rice partition order {max} or {min},{max} (default: 0,5)
       [-s #]       Stereo decorrelation method
                        0 = independent L+R channels
                        1 = mid-side (default)
       [-v #]       Variable block size
                        0 = fixed (default)
                        1 = variable

Compression levels in flake 0.11 were configured slightly differently:

CODE

       [-0 ... -12] Compression level (default: 5)
                        0 = -b 1152 -t 1 -l 2,2 -m 0 -r 4,4 -s 0
                        1 = -b 1152 -t 1 -l 3,4 -m 1 -r 2,2 -s 1
                        2 = -b 1152 -t 1 -l 2,4 -m 1 -r 3   -s 1
                        3 = -b 4608 -t 2 -l 6   -m 1 -r 3   -s 1
                        4 = -b 4608 -t 2 -l 8   -m 1 -r 3   -s 1
                        5 = -b 4608 -t 2 -l 8   -m 1 -r 6   -s 1
                        6 = -b 4608 -t 2 -l 8   -m 2 -r 8   -s 1
                        7 = -b 4608 -t 2 -l 8   -m 3 -r 8   -s 1
                        8 = -b 4608 -t 2 -l 12  -m 3 -r 8   -s 1
                        9 = -b 4608 -t 2 -l 12  -m 6 -r 8   -s 1
                       10 = -b 4608 -t 2 -l 12  -m 5 -r 8   -s 1
                       11 = -b 4608 -t 2 -l 32  -m 6 -r 8   -s 1
                       12 = -b 4608 -t 2 -l 32  -m 5 -r 8   -s 1

Where can i get a copy of Flake SVN-r264?

r264 is just the last revision that was pushed to the subversion repository:
http://sourceforge.net/scm/?type=svn&group_id=177048

I built it myself from source in GNU/Linux. I have no idea how to build windows binaries, sorry.

Should i be using Flake v0.11 or r264 for the test?

Here are the results for some random album:

CODE

libflac-1.2.1   -8      327.41MiB
flake-0.11      -12     324.69MiB
flake-r264      -12     323.96MiB

I remember flake 0.11 being not that close to r264 in experiments I conducted a long time ago. But It could be all in my imagination.

[_m²_]

and at cost of decoding speed.

No, they both play in real time, which is exactly the same either way. And I certainly don't want my music to play any faster.

This post has been edited by _m²_: Oct 9 2012, 22:25

[Wombat]

Just a reminder to flake. It does much worse as regular flac or Chudovs CUEtools encoders on things that are lossywav´d or music that don´t use all bits.

[lvqcl]

No, they both play in real time

So what?

And I certainly don't want my music to play any faster.

I do. (not to play but to decode much faster than realtime).

This post has been edited by lvqcl: Oct 9 2012, 22:41

[A_Man_Eating_Duc...]

Thanks 2012

Does anybody know of a Win32 build of Flake SVN-r264?

[Porcus]

What about bringing http://encode.ru/threads/1137-Sac-(State-o...dio-Compression into the lot?
Not because I think it is worth using, just because it is kinda boring to see the same rankings as last year over again. (And because I'm curious whether how big a mouthful he's trying to chew with that name.)

[A_Man_Eating_Duc...]

I have no problems adding that in, the Wavpack --hhx6 is going soo slow anyhow.

how crazy do i need to go on the switches?

[lvqcl]

Does anybody know of a Win32 build of Flake SVN-r264?

http://www.hydrogenaudio.org/forums/index....showtopic=97389

Compiled with MSVS 2010 (so it requires at least WinXP)

[saratoga]

I guess its the larger frame size that breaks flake -11 in rockbox. If it fits in memory on most targets, I'll see about adding support for -11. If not, well I guess its not a big deal since compression is almost no better and its an optional feature.

[A_Man_Eating_Duc...]

Thanks lvqcl for the binary

UPDATE:
OptimFrog has 3 more presets to go, Highnew, extranew and Bestnew
Flake v0.11 has 2 more left, 11 and 12 (I might as well let it finish and compare)
Wavpack -hhx6 has only just got to Faith No More
Sac is the possibly the slowest encoder i have ever seen (2:57 to encode a 4:04 track in fast mode). I'll do my best to put at least one mode in there but if i get a powercut I'll have to axe it.

I'll start the SVN-r264 Flake once Flake v0.11 is finished.

This post has been edited by A_Man_Eating_Duck: Oct 10 2012, 05:49

[shadowking]

Try wavpack -hhx4 its twice as fast but compresses like x6 in nearly all situations.

[Destroid]

I confirm the above from my own results on subset of files (32bit float, mono and stereo)- over twice as fast encoding speed with only 0.10% - 0.30% file size increase. YMMV.

Similar to what I mentioned about TAK (-p4 vs. -p4m), the difference in ratio between WavPack -hhx4 and -hhx6 can be estimated fairly easily. Is worth the time? Maybe for testing the extreme limits of compression ratio and archival but not much for practical use.

This post has been edited by Destroid: Oct 11 2012, 02:58

[IgorC]

A_Man_Eating_Duck,


Maybe it's obvious but what is a goal of your test? The evaluation of compression of lossless formats mainly on rock music?

Most likely 8047 files is an overkill. Just a give a number, ~10% of that amount is already representative and You won't lose precision of the results.

Other thing is that compression varies per music style among other factors. Probably You already know that and I mention it to get it clear just in case.

This post has been edited by IgorC: Oct 11 2012, 03:38

[A_Man_Eating_Duc...]

@IgorC,
I just want to know how different lossless codecs compress my music, nothing more, nothing less.

My results won't change me from using FLAC -6, I'm just curious.

[Case]

PS: i just realized i can't even play .la files in my foobar2000!!!
Where should i take the right input .la component?

This is a bit late but Peter released a generic command line decoder input for foobar2000. It allows you to use any codec for playback that has command line Windows binaries available. You can find the component and pre-made config for .LA files here. With this component the player won't crash.

[nu774]

BTW, I noticed that ALAC (at least Apple implementation) is ridiculously poor at compressing files with several bits at LSB side are all zero (such that created just by up-scaling the bit depth from 16 to 24 or something).

[tuffy]

BTW, I noticed that ALAC (at least Apple implementation) is ridiculously poor at compressing files with several bits at LSB side are all zero (such that created just by up-scaling the bit depth from 16 to 24 or something).

24 bit ALAC files store the bottom 8 bits uncompressed, which is as non-optimal as it gets for those cases.

[nu774]

24 bit ALAC files store the bottom 8 bits uncompressed, which is as non-optimal as it gets for those cases.

Ah, thanks to let me know that.