My results for Flake SVN r110 wisodev build P3 optimised with RW corpus.
Setting Ratio Enc Dec
=================================
0 65.352% 136x 106x
1 62.822% 114x 104x
2 62.661% 98x 104x
3 59.581% 94x 97x
4 59.392% 92x 93x
5 59.292% 90x 96x
6 59.649% 66x 96x
7 59.307% 54x 96x
8 59.132% 49x 95x
8 -m 1 59.115% 83x 94x
8 -v 1 58.747% 47x 93x
9 59.019% 40x 95x
10 59.006% 28x 94x
11 58.758% 22x 83x
12 58.729% 9x 83x
12 -v 1 58.378% 9x 84x
99 58.336% 2x 72x
Something interesting here, I noticed that -5 often gives better results than -6, in fact, the size is often similar to that of -7 and -8. Fiddling with the settings a bit, I noticed that this is because of the setting "order method: estimate" which seems to produce better results than "2-Level" and sometimes better than "4-Level" as well.
I didn't test on many files, so this might be a coincidence, but on the few files I tested the commandline "flake -8 -m 1" was always faster and always produced bitrates similar or better than "flake -8". Might be worth investigating...
These results appear to bear yours out completely. I'm so glad you posted or I would have been really concerned about my -6 results!
I will post results for the other wisodev compiles (normal and org) as well, in the next day or so. I will also post the spreadsheet used to calculate the summaries (uploaded to Google Docs & Spreadsheets).
Edit: Something else of note. In fact two somethings.
Firstly, I should mention that the results above are CPU-only times, where my TAK lossless comparison values are CPU+IO times. I started reporting CPU+IO in that comparison and it's awkward to stop now.
Secondly, the scripts I use to perform my tests use FSUM to check the decoded WAVE files against the MD5 hashes of the source files once all files are decoded. This normally serves me well, but in this instance nearly all files fail the check.
I have done a little checking and it appears to be down to the WAVE header written, which I think is 2 bytes smaller than the source (bear in mind the source files are decoded WavPack files). Again, from my limited understanding, this appears to be down to the ExtraParamSize bytes not being written by the FLAC decoder. From the document I have read it appears that these bytes are not required if no extra parameters are present. Strangely enough though every fourth file or so the hashes do match!
Edit: It seems that, as expected, with the files that do match MD5 hashes, neither have the ExtraParamSize bytes; therefore FLAC is acting consistently, while the source files are not consistent. Maybe this is noticable as most decompressors just return the original WAVE header, whereas FLAC creates its own?
I really have no idea what all this means, but it thought it worth noting. I bit compared a few files that had mismatched MD5s using foobar and the audio is bit-identical, as you would expect.
Here's the report from FSUM for -5 (it's the same for all though).
FAILED MD5 41_30sec.wav
FAILED MD5 ATrain.wav
FAILED MD5 Bachpsichord.wav
OK MD5 Bartok_strings2.wav
FAILED MD5 BeautySlept.wav
FAILED MD5 BigYellow.wav
FAILED MD5 Blackwater.wav
FAILED MD5 bodyheat.wav
OK MD5 chanchan.wav
FAILED MD5 DaFunk.wav
FAILED MD5 death2.wav
OK MD5 Debussy.wav
FAILED MD5 EnolaGay.wav
FAILED MD5 experiencia.wav
FAILED MD5 female_speech.wav
FAILED MD5 FloorEssence.wav
OK MD5 getiton.wav
FAILED MD5 gone.wav
OK MD5 Hongroise.wav
FAILED MD5 Illinois.wav
FAILED MD5 ItCouldBeSweet.wav
FAILED MD5 kraftwerk.wav
FAILED MD5 Layla.wav
OK MD5 Leahy.wav
FAILED MD5 LifeShatters.wav
FAILED MD5 macabre.wav
FAILED MD5 Mahler.wav
FAILED MD5 male_speech.wav
OK MD5 Mama.wav
FAILED MD5 MidnightVoyage.wav
FAILED MD5 mybloodrusts.wav
OK MD5 NewYorkCity.wav
OK MD5 OrdinaryWorld.wav
FAILED MD5 Polonaise.wav
FAILED MD5 Quizas.wav
FAILED MD5 riteofspring.wav
OK MD5 rosemary.wav
FAILED MD5 Scars.wav
OK MD5 SinceAlways.wav
FAILED MD5 thear1.wav
FAILED MD5 TheSource.wav
OK MD5 TomsDiner.wav
OK MD5 trust.wav
OK MD5 Twelve.wav
FAILED MD5 velvet.wav
OK MD5 Waiting.wav
31 checksums failed