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!

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.

I donīt know the story of flake but now while i test around i am not really thrilled to have the extra options.These options like l32 or v1 simply brake the standard in my eyes. l32 encoded files donīt play on every hardware and v1 is confusing even winamp and my Squeezebox again when i want to fast forward.What about *.flak for flake encodings? So everyone knows he may have to reencode to use it properly when he gets such a file by accident.This may have been discudssed before but i somehow missed that.

The P3 is optimized for Pentium III and should work for all processors above P3 specs. It Works very well on Athlon XP processors (I have Athlon XP 2000+). I have in mind to add P4 build but I can't build it on my machine because of PGO optimization that req running the program and my CPU doesn't support P4 builds.

The original (ORG) build is not considered for normal usage only added for speed testing of PGO and PGO&P3 builds. For most CPUs the .\flake.exe build is good and should be used as safest solution.

QUOTE (PrakashP @ Oct 17 2006, 22:46)

@wisodev

I would be interested what compiler flags you use (and which compiler). Have you added asm to the sources?

All I have added is build enviroment in win32 directory. No assembly optimizations added by me. I have added some small changes to code to build it cleanly under MSVC with Intel compiler. Maybe Justin can add them to official sources (just diff my sources with SVN revision 110 to see what have been changed).

I am using MSVC++ v7.1 and Intel C++ Compiler v8.0.040. This version of Intel compiler works best for me. I have tried newer versions but I can't get better results.

The compiler flags are main reason for speedups of my builds. I am using PGO optimization provided by Intel C++ compiler and for P3 build additionaly /QxK flag is used to enable even more optimizations. More information is avaible when you check the project settings for eacg configuraion (all witch begin with Release, the Debug builds are obviously not optimized ;-).

The P3 is optimized for Pentium III and should work for all processors above P3 specs. It Works very well on Athlon XP processors (I have Athlon XP 2000+). <snip> The original (ORG) build is not considered for normal usage only added for speed testing of PGO and PGO&P3 builds. For most CPUs the .\flake.exe build is good and should be used as safest solution.

Thanks for the info wisodev. With that in mind I won't bother with the ORG build. Here's the PGO and PGO+P3 results:

I donīt know the story of flake but now while i test around i am not really thrilled to have the extra options.These options like l32 or v1 simply brake the standard in my eyes. l32 encoded files donīt play on every hardware and v1 is confusing even winamp and my Squeezebox again when i want to fast forward.What about *.flak for flake encodings? So everyone knows he may have to reencode to use it properly when he gets such a file by accident.This may have been discudssed before but i somehow missed that.

The files may confuse some software decoders and skip in some hardware decoders, but I assure you they are 100% valid FLAC files based only on the specification. The issues that occur are not Flake issues, they are due to there being 2 levels of compliance, the subset specification and the full specification. Flake gives a warning when the files do not fall within the subset specification, but all generated files fall within the full specification.

If you're worried about getting a FLAC file which may cause problems, I could try to write a small utility program which would do frame analysis and detect whether a file falls within the subset specification. As for winamp, maybe adding a seektable using metaflac would help?...I don't really know how the winamp plug-in does seeking and I don't use winamp (anymore). I do use xmms, which completely locks up when seeking with the variable bitrate files...no good. Personally, I see these as software bugs, but I can't really blame the makers since that feature of the specification is not implemented by the reference encoder. MPlayer plays & seeks just fine...it uses its own demuxer & FFmpeg's decoder.

On an unrelated note, thanks for all the benchmarks! The graph is great Now that I see the results, I'm seriously considering abandoning the "mirror the reference encoder" idea for compression levels. I think trimming it down to just 7 presets corresponding to 0, 1, 5, 8m1, 10, 11, and 99 should pretty much cover what is needed.

-0 for really-fast encoding-1 for fast encoding-5 for normal encoding"-8 -m 1" for high compression-10 for best compression within subset-11 for extra compression outside subset (-12 speed loss isn't worth the tiny gain)-99 for experimental

I would probably get rid of the numbered presets in favor of named presets. What do you all think about this idea?

Not sure if this fits the bill, but I can't think of any other way of displaying it...

Actually, that was quite useful. The two points on the encoding line that stood out to me numerically after looking up and down the chart a few times also appear to stand out rather obviously in the chart.

The files may confuse some software decoders and skip in some hardware decoders, but I assure you they are 100% valid FLAC files based only on the specification. The issues that occur are not Flake issues, they are due to there being 2 levels of compliance, the subset specification and the full specification. Flake gives a warning when the files do not fall within the subset specification, but all generated files fall within the full specification.

If you're worried about getting a FLAC file which may cause problems, I could try to write a small utility program which would do frame analysis and detect whether a file falls within the subset specification. As for winamp, maybe adding a seektable using metaflac would help?...I don't really know how the winamp plug-in does seeking and I don't use winamp (anymore). I do use xmms, which completely locks up when seeking with the variable bitrate files...no good. Personally, I see these as software bugs, but I can't really blame the makers since that feature of the specification is not implemented by the reference encoder. MPlayer plays & seeks just fine...it uses its own demuxer & FFmpeg's decoder.

Thanks for your answer. I read the first time deeper about flac and switches. I am sure you can penetrate normal flac to the point it doesnīt work on any player also No need for a tool that tests the frames. This -v1 doesnīt seem to need any more decoding power than without so it is time to "correct" the decoders.btw. this latest wisodev build is awsome fast!

Not sure if this fits the bill, but I can't think of any other way of displaying it.

Synthetic Soul,

The plot of the results look great. I was wondering why it is that "-m 1" is only tested on "8". Can it not be used on levels 9 and up? I didn't see anything about that, so I apologize if I missed it. I have to wonder how much it could potentially increase encoding times of those above 9, especially if it can increase 12's encoding time significantly.

@Synthetic Soul:Thanks for the tests, it would also be nice to have "-8 -m 1 -v 1" in next time, maybe instead of "-8 -v 1"? This should have a very good compression/encoding time ratio.

QUOTE (kockroach @ Oct 19 2006, 13:26)

The plot of the results look great. I was wondering why it is that "-m 1" is only tested on "8". Can it not be used on levels 9 and up? I didn't see anything about that, so I apologize if I missed it. I have to wonder how much it could potentially increase encoding times of those above 9, especially if it can increase 12's encoding time significantly.

I simply used the settings requested by Justin, and added -8 -m 1 as it was mentioned by MedO shortly after, and it was suggested that more info was required (so I thought I may as well add it to the list).

My wife is possibly beginning labour at the moment, so I kind of have other things on my mind.

I think trimming it down to just 7 presets corresponding to 0, 1, 5, 8m1, 10, 11, and 99 should pretty much cover what is needed....I would probably get rid of the numbered presets in favor of named presets. What do you all think about this idea?

I think it's a good idea. And if we really want we always can use cryptic -b -t -l -m -r -s combinations

Well, the only setting that changes between -8, -9 and -10 is the -m switch, and you override that manually, so you get the same results because the settings are identical. The same goes for -11/-12.

Edit: I just saw that -11 -m 1 is bigger than -8 -m 1. I guess the "estimate" search method just isn't optimised for those high predictor orders. Just a guess, I don't know much about FLAC technology...

Edit2: I confused rows in the table... thanks Josef Pohm for the hint.

I have a Rio Karma and while it can play FlAKE -12 compressed flac files, it has a lot of trouble seeking with these FLAC files. FLAC 1.1.2_CVS which gets close compression works great with my Rio Karma.

What I'd like to know is what are the best settings for Flake to work with my Rio Karma? I'd like to compare compressions sizes to find out which is better. I was playing around and ended up gettng a larger file that didn't work vs FLAC 1.1.2_CVS.

What setting is it in FLAKE that causes it not to be fully compatible with my Rio? I tried the -v 1 as suggested earlier in the thread to make it compatible with FLAC and that also failed.

I have a Rio Karma and while it can play FlAKE -12 compressed flac files, it has a lot of trouble seeking with these FLAC files. FLAC 1.1.2_CVS which gets close compression works great with my Rio Karma.

What I'd like to know is what are the best settings for Flake to work with my Rio Karma? I'd like to compare compressions sizes to find out which is better. I was playing around and ended up gettng a larger file that didn't work vs FLAC 1.1.2_CVS.

What setting is it in FLAKE that causes it not to be fully compatible with my Rio? I tried the -v 1 as suggested earlier in the thread to make it compatible with FLAC and that also failed.

Jon

For now the best setting for your Rio would probably be "flake -10". It generates files which are roughly equivalent (compatibility-wise) to "flac -8". Definitely don't use -v 1 since it is probably the most experimental option and has compatibility issues.

edit: to answer your other question more fully, it's probably the max LPC order which is causing problems on the Rio with flake -12 files.

edit2: Given the many questions, for the next release, I will try to make some documentation devoted to compatibility of various features of the FLAC specification and Flake encoding parameters.