I still miss some options, most important to me is -V as i like to overclock my hardware. Veryfying doesn't slow encoding down much anyway. Also reading from stdin doesn't seem to work on windows, it will say "invalid wav file: -" and then proceeds create a 0 byte flac output file, another feature it could do without For the rest it's nothing metaflac can't handle.

Wonderful. This is typical of the results I get as well. I'm glad to see the relative encoding times are comparable on a fast, modern system.

Quote

A 95.5% speedup. Impressive. Flake -8 is my new god.

I'm glad you like it. Keep in mind that it is experimental at this point, but there will eventually be another release which will use FFmpeg's wav decoder & FLAC encoder. So far it seems it might end up being faster as well.

Quote

I still miss some options, most important to me is -V as i like to overclock my hardware. Veryfying doesn't slow encoding down much anyway.

Oddly enough, I was just thinking about this today. I noticed many people on Hydrogenaudio use this option. I will definitely add something similar when I start back working on Flake. I might have to use a modified version of FFmpeg's FLAC decoder instead of doing it directly through libavcodec. But you're right that this is an important feature of the reference encoder.

Quote

Also reading from stdin doesn't seem to work on windows, it will say "invalid wav file: -" and then proceeds create a 0 byte flac output file, another feature it could do without

Hmm. Maybe that has to do with having to set stdin to binary mode in windows...maybe. This is good to know though. Thanks for the feedback.

Quote

For the rest it's nothing metaflac can't handle.

I might even add metadata/cuesheet/seektable support someday. Personally, I'm not a fan of the vorbis/flac comment specification, but it works.

All of this is probably at least a month or two (or three) away. I have a lot going on in the next couple months.

I'd also like to join in saying "thank-you" for your efforts to improve FLAC encoding. Highly appreciated!I also integrated it into fb2k; the only drawback (= speed penalty) here is that reading from stdin doesn't work here either so temp. WAVs have to be uses with the converter...

Keep it up!

-sundance-

Btw, why didn't you use another vendor string than "[put libavcodec/libavformat versions here]"?

Btw, why didn't you use another vendor string than "[put libavcodec/libavformat versions here]"?

Because one of my main purposes for writing the encoder was to integrate it with FFmpeg. I just needed a frontend to test it with before integrating it, so I made Flake. The next release will have the lavc version as the vendor string.

I just needed a frontend to test it with before integrating it, so I made Flake. The next release will have the lavc version as the vendor string.

Thanks,-Justin

I can't speak for the rest of us, but i really like the standalone, dropin flac replacement that flake is. I'm not very familiar with the ffmpeg project, but i fear it won't be as easy to use from the commandline or as encoder for eac or foobar when integrated into ffmpeg.

I just needed a frontend to test it with before integrating it, so I made Flake. The next release will have the lavc version as the vendor string.

Thanks,-Justin

I can't speak for the rest of us, but i really like the standalone, dropin flac replacement that flake is. I'm not very familiar with the ffmpeg project, but i fear it won't be as easy to use from the commandline or as encoder for eac or foobar when integrated into ffmpeg.

Not to worry. I will still re-release Flake as a standalone encoder once the code is part of FFmpeg. I'll just use the relevant code from FFmpeg and might have to restructure it a little bit for use with Flake. FFmpeg has/is a commandline frontend to its libavcodec and libavformat libraries. When using FFmpeg, you'll most likely only be able to specify the compression level, not each individual option. Flake will use the FFmpeg code, but be specifically only for FLAC encoding and will provide more detailed options along the lines of what it has currently.

As far as familiarity, you can find out more about FFmpeg athttp://ffmpeg.mplayerhq.hu/It is a wonderful project with very good developers. If you don't mind the 50 or so emails a day, subscribe to ffmpeg-devel and watch for a while...or just browse through the archives.

Well I am propobly too late but I have builded some binarys for win32 using intel compiler. If someone want to try them here is link http://thefrontend.sourceforge.net/flake/. All versions compiled be me where faster then kurtnoise builds on my machine (Athlon XP 2000+). Archives include full sources, binarys and project files. In file TESTS-0.4-win32.zip are some speed tests results just to prove me claims ;-)

Well I am propobly too late but I have builded some binarys for win32 using intel compiler. If someone want to try them here is link http://thefrontend.sourceforge.net/flake/. All versions compiled be me where faster then kurtnoise builds on my machine (Athlon XP 2000+). Archives include full sources, binarys and project files. In file TESTS-0.4-win32.zip are some speed tests results just to prove me claims ;-)

Thank you! Especially for the win32 build environment stuff! I am currently working on a simple configure/build system for unix environments. I'll try to use some of what you have done as a basis to improve Windows compatibility in the next release.

The current development version of Flake has about a 15% speed improvement over pre-release 06 (on x86 linux gcc 3.4.4). Compression has generally improved only slightly so far, except at compression level 0, which has a significant improvement. FFmpeg integration of the full encoder is only about 1/2 done right now, but is going very well I think. Right now it has levels 0 to 5, and you can change specific options on the commandline. If you build FFmpeg from current SVN, here are some of the FLAC encoding options.

Also, the most updated Flake webpage is at another location. I will be able to post some test samples of my own instead of linking to other sites since I now have more storage space. I am limited to only 10MB on my Earthlink account.http://jbr.homelinux.org/flake/

Thank you! Especially for the win32 build environment stuff! I am currently working on a simple configure/build system for unix environments.

Quick note about the win32 project files (VC++ 7.1 and ICL 8.0 compatible): the FLAKE code compiles only with ICL not CL because of C99 option in intel compiler settings (without this option code does not compile). So the build environment works only with visual studio and intel compiler integrated. But it works very well without any nasty errors and produce great binarys ;-). I will in near future update the build environment to Intel 9.1 (actually I have done this locally and only need to update online stuff, but before that some tests will be committed to check if new version works good as prevoius).

Well I am propobly too late but I have builded some binarys for win32 using intel compiler. If someone want to try them here is link http://thefrontend.sourceforge.net/flake/. All versions compiled be me where faster then kurtnoise builds on my machine (Athlon XP 2000+). Archives include full sources, binarys and project files. In file TESTS-0.4-win32.zip are some speed tests results just to prove me claims ;-)

another thing I would suggest is a big fat warning if the compression setting used is not in the FLAC subset. not sure, looks like currently all settings are in the subset. but I'm considering restricting the subset further (to lpc order<=12 and blocksize <=4608) for the next release, at least for <=48kHz.

another thing I would suggest is a big fat warning if the compression setting used is not in the FLAC subset. not sure, looks like currently all settings are in the subset. but I'm considering restricting the subset further (to lpc order<=12 and blocksize <=4608) for the next release, at least for <=48kHz.

Thanks Josh. The 0-8 presets in Flake are within the subset, but the block size can be specified on the commandline to be any valid size within the spec, not just limited to the predefined ones required for subset.

I agree with your intentions to further restrict the subset requirements. Block size over 4608 is rarely beneficial anyway unless it is a quite stationary signal, but the affect on decoding speed is substantial. Maybe this would also make it easier to standardize hardware support. There are products which say that they support FLAC levels 0 to 8. This doesn't really say much about what else is truly supported outside the predefined levels. If subset limits were restricted to the settings of level 8 it would be simpler and more definitive to just say that a product supports the FLAC Subset format or the full FLAC format (or FLAC 2 ).

I'm posting again here because the FFmpeg FLAC encoder has some significant changes. Nearly all of Flake-06 has been integrated, along with some pretty great improvements by Michael Niedermayer (lead FFmpeg developer). It is quite a bit faster than Flake (level 8 is about 60% faster than the reference encoder). Some of the key improvements are:

encoding speed at lower levels is now on-par with the reference encoder

Very big. 1-pass is only a little slower, but it does not give as good results as Levinson-Durbin. The two seem to be equivilant in compression at around 3-4 pass. So the real benefit is if you have a fast computer and/or lots of time to spare to wait for it to squeeze out a few more tenths of a percent. Decoding speed is not affected.

A good thing to add in the future that might give similar compression results would be to adaptively select or brute-force search for an optimal window function to go along with the Levinson-Durbin recursion. I think Josh might be adding something like that to the reference encoder, but I'm not sure. I know it currently is user-selectable, but it would be great if the best window was chosen by the encoder for each frame. FFmpeg currently uses only a Welch window function. I just chose that because it is a simple calculation and seems to work well most of the time.

I have actually been doing experiments solving the full prediction linear system with SVD; this should give a lower bound on the compression achievable by the FLAC filter. so far it works but it will not be ready for the next release.

Josh

(edit: lower bound on the least-squares solution I mean; I have some other experiments solving the system another way but that's too new.)

I have actually been doing experiments solving the full prediction linear system with SVD; this should give a lower bound on the compression achievable by the FLAC filter. so far it works but it will not be ready for the next release.

I suppose the pseudo-inverse approach (through SVD) is even slower (but more accurate) than the Cholesky approach.

I have actually been doing experiments solving the full prediction linear system with SVD; this should give a lower bound on the compression achievable by the FLAC filter. so far it works but it will not be ready for the next release.