A multicore FLAC encoder Options

[GeorgeFP]

Hi!

Maybe you already know fpMP3Enc, my multicore MP3 encoder...

This time, I'd like to introduce my multicore FLAC encoder. You can download the binaries here.

The package contains Win32 binaries for XP, Vista and 7, and Win64 binaries for Vista and 7.

The FLAC encoder is part of my "fpStream" project. The command-line to convert a WAV file to FLAC is as follows:

CODE

FPSTREAM.EXE readfile in -f <wav-filename> + wavin wav -s in + fpflacenc enc -s wav [-<compression level>] + writefile out -s enc -f <flac-filename>

The benchmarks so far:
I used the same test suite as in fpMP3Enc (Intel Q9450, 61 WAV files, about 5 hours playing time). The compression level was 5. The files were encoded one after the other, not in parallel.

- flac 1.2.1: 3 min 26 secs
- fpFLAC x64: 1 min 13 secs

So, the speedup was 2.8x. This is quite good if you consider that this version does not contain any SSE optimizations.

What's missing:
- SSE optimizations
- Metadata support (tags, seek points etc.)
- free of bugs

And some limitations:
- Win32 version: The total WAV file size sum must not exceed 400MiB(? - not sure).
- Win64 version: The total WAV file size sum must not exceed 400GiB.
- Input: WAV 16-bit stereo, 44.1kHz

Comments and feedback are welcome!
George

[NuSkooler]

I cannot wait for this to be ready for production so to speak!

Any chance @ GPU support?

[GeorgeFP]

I cannot wait for this to be ready for production so to speak!

Well, the truth is, I don't know if fpFLAC has a future. The feedback is very, very poor.

Any chance @ GPU support?

I will add GPU support into my framework and if the fpFLAC project will be continued it will also support GPUs.

[Bylie]

Well, the truth is, I don't know if fpFLAC has a future. The feedback is very, very poor.

Well to be honest I've been following all of the new projects with a lot of interest and am really impressed by the progress made. Who wouldn't be:

• fpFLAC/MP3 makes much better use of multicore CPU's which are destined to be the future as CPU clockrates are stagnating for quite some time now. I just saw that also GPU support will be integrated, very nice!
• FLACuda already leverages all the GPU processing potential currently being neglected in anything but games.
• TAK which has made some nice improvements compressing audio even further.
• Others which I probably forgot...

But, personally, I'm not very inclined to switch to a new, unproven piece of software even if it incorporates proven code and/or algorithms like FLAC, WavPack, LAME, ...

Maybe a better approach to this would be, to somehow try, to integrate these new projects into the existing, proven, codebase supervised and/or publicly supported by the original developers trying to maintain the same stability and quality of the original software. This might even be a different branch at first but I really think the "umbrella effect" could have a positive effect on the acceptance of the new code/projects by the users which ultimately will result in more useage and feedback.

I know this is sort of an idealistic vision because in reality it might just not be that easy due to a number of realworld problems/conflicts (licensing, time, ...) but I really think it could give these new projects a lot more visibility and it might even give the original software a new momentum.

This post has been edited by Bylie: Dec 24 2009, 15:24

[GeorgeFP]

But, personally, I'm not very inclined to switch to a new, unproven piece of software even if it incorporates proven code and/or algorithms like FLAC, WavPack, LAME, ...

Maybe a better approach to this would be, to somehow try, to integrate these new projects into the existing, proven, codebase supervised and/or publicly supported by the original developers trying to maintain the same stability and quality of the original software. This might even be a different branch at first but I really think the "umbrella effect" could have a positive effect on the acceptance of the new code/projects by the users which ultimately will result in more useage and feedback.

Believe me, if I had the chance to integrate my framework into the existing C code I would have done so. But multi-core programming is very different to serial programming and thus, I had to write fpFLAC from scratch.

Of course, you can wait until the original developers will add multi-core support to their projects. I don't know of any activities going in this direction, neither for FLAC nor for LAME.

[Bylie]

Believe me, if I had the chance to integrate my framework into the existing C code I would have done so. But multi-core programming is very different to serial programming and thus, I had to write fpFLAC from scratch.

Of course, you can wait until the original developers will add multi-core support to their projects. I don't know of any activities going in this direction, neither for FLAC nor for LAME.

I really try to not underestimate the amount of work and research that goes into these projects and I can surely understand that saying something like "integration will yield benefit x and y" might sound much easier than actually doing it!
However, the problem will remain for projects like fpFLAC and others that they are seen more like a proof of concept and hence are more interesting for developers and testers which won't make a large userbase. This might actually not be a problem if the goal is to provide a proof of concept, but if the idea is to get more and more realworld usage/feedback I think somewhere along the line the proof of concept stage has to evolve into something more users will (want to) use. This is where the "umbrella effect" or "public developer support" might play a role as it gives visibility to these projects beyond this forum and also, kind of, assures the large group of endusers that it's OK to also use this for anything else than testing.

This post has been edited by Bylie: Dec 25 2009, 18:46