Very good work!I would like to try it out, but so far the compiled version from Roberto has crashed on me every time I tried to use it I think the problem is my CPU, as I have an AMD Phenom2, which doesn't support the SSE4 instruction set.

So, is there any possibility of getting a non-SSE4 binary?

I have been trying to compile it myself, but I have pretty much no idea what I'm doing, I just wanted to try this really badly ^^

Sorry if that've been asked already, but is there any objective tests of produced MP3s quality? As I understand - the process is touching a very low levels of encoder. Is it safe to use it for usual purposes and not testing - only?

Sorry if that've been asked already, but is there any objective tests of produced MP3s quality? As I understand - the process is touching a very low levels of encoder. Is it safe to use it for usual purposes and not testing - only?

The quality should be exactly the same as LAME since I didn't modify the algorithm. I just split the serial code into asynchronous parts and let them execute in parallel. All encoding features including bit reservoir are still present.

Sorry if that've been asked already, but is there any objective tests of produced MP3s quality? As I understand - the process is touching a very low levels of encoder. Is it safe to use it for usual purposes and not testing - only?

The quality should be exactly the same as LAME since I didn't modify the algorithm. I just split the serial code into asynchronous parts and let them execute in parallel. All encoding features including bit reservoir are still present.

So, in theory, I shall get bitwise-equal output from your version and the original one? If that's true, it's indeed safe to use it without any quality tests

Doesn't foobar2000 already do this if you have more than one core in your computer? I was getting similar numbers on quad core machine when I had to do some coding for my dad. My core duo goes about 43x if its not running warm.

I cannot confirm this on my quad core. Converting the test set with foobar2000 took me about 6 minutes which gave a 47.4x speed. (BTW, the test was encoding to CBR 128.)

QUOTE (Mike Giacomelli @ Aug 2 2009, 18:38)

Running two encodes in parallel results in essentially perfect parallelization. The only overhead comes from disk contention, which is still a problem for the multithreaded single process case anyway.

This is not a problem in "fpMP3Enc". I/O processing is a separate task and is controlled by a file I/O scheduler that sorts and serializes I/O operations on the same drive. The encoder tasks work only on memory.

That's the reason why foobar2000 has a 47.4x performance while "fpMP3Enc" has 80.2x. I think, on an i7 it's possible to get 150x and above... unfortunately I don't have such a system to test it.

QUOTE

Running one process will encounter additional overhead due to thread synchronization, lack of granularity in parallelism, overhead for inter-thread communication, etc. In order to make up for this, there would have to be additional work saved by running in one process and I don't see what that would be for MP3.

As you mentioned above, concurrent disk access is a problem when you execute multiple encoder processes in parallel. If you run them as tasks in one process you can use a file I/O scheduler that takes care of it, as I did.

I think fb2k's relative poor performance is somehow due to Windows's poor pipe performance.Try to write a fb2k compatible version and compare it with lame ?

By design, the encoder will run with at least three threads (1 CPU, 2 I/O). If you don't set the number of CPU threads in the command-line, the number of threads will be <number of processors> + 2.

If the encoding speed feels like being single-threaded, then either you're using CBR or ABR, or the number of threads is too high. Currently, using more than three CPU threads would slow down the encoding.