mppenc 1.15v is out.

What's changed:

1. The encoder now employs a workaround for denormal number issues. Recently-reported synthetic samples with passages of digital silence are handled correctly regardless of the compiler used.
2. A small fix to the code now allows AMD64 Windows compiles to be made easily. We have not noticed speed gains. Microsoft's 64-bit compilers should mature before we release official 64-bit builds of the encoder.
3. The German comments in the source have been translated to English by CiTay. It will make it easier for newcomers to work with the code.

mppenc 1.15v for Windows
mppenc 1.15v for Linux
mppenc 1.15v source

Nice, thank you.

How much work is left to do before tackling sv8?

Nice work!
Its still unbearably slow on Mac OS X though (--standard = 2.7x on my 1.5GHz PowerBook).

A lot.

We've received a 1.2 GB suite of samples from a person who's worked with Andree back in the good old days, one of which is ABXable at --insane. I'd want to consult with Frank about these, plus some of the samples submitted to me by Pio2001. A part of the team will surely start to dig in SV8's source and work on it while others work on SV7. I'd personally prefer to have 1.16 ready first, and even this is several months away, if not more.

Thank you MDT!

just an indirect remark,
@ musepack website the hint ( alt text ) for the download image for several entries is 'Homepage' and not 'Download'

"A small fix to the code now allows AMD64 Windows compiles to be made easily. We have not noticed speed gains."

SSE2 would normally give all the speed increase (as with the ogg encoder the sse2 version is many times faster). SSE2 is on Athlon 64 Intel Celerons (later models) and P4s.

Speed increases for 64 bit audio encoding (from the testing I have done across most encoders) is very small...

Edit: typo on Athlon

A typo? AFAIK Athlons & AthlonsXP & Durons & SocketA Semprons don't have SSE2 (unless you count 3DNow), just SSE.
BTW, big thanks MDT

I think that SSE2 on the 64-bit Athlons does not perform as well as on P4s, and reports about the new 90nm CPUs from AMD indicate that SSE3 isn't so hot on them either.

Based on a c't article that showed very nice improvements for LAME with certain GCC optimizations for the Athlon 64, we've created 10 32-bit builds (at least one of them was SSE2-optimized) of mppenc. None of them gave any speed increase over the official build. Currently GCC 3.4 and MSVC produce Windows binaries that reach the same speed. A 64-bit OS and a decent 64-bit compiler will make things faster (some of the benefits being more registers on the CPU to utilize).

Do you have any link?

Seed,

Congratulations for your work, it is really appreciated

One thing I noticed when I briefly browsed the subversion repository, is that the code is quite hard to read. It seems very efficient and cleverly written (ie: high emphasis on optimization, by a DSP specialist) but unfortunately many constants, and calculations, are not explicitely detailed.

It would be good if the people who understand a complex calculation could add some explanations in a comment when they encounter it.

This way, I think many more people (including me) could more easily understand the code.

I've been programming DSP audio effects back in 2000, but this seems to be die-hard DSP code or something

Edit: fixed spelling

Here's an overview, from c't 5/2005 (the bars show the time needed to encode an album to MP3). Please support c't mag.

NumLOCK, 99.9% of the code in mppenc is Frank's. If we had the same level of understanding, surely we'd document it, but none of us has a clue what some of the lines do.

I hope that with every email he writes to us more will be revealed. We're forced to listen to a lot of samples, hoping to find obvious bugs we can fix ourselves, but without the help of an ace psymodel coder we're almost lost.

Edit: I should clarify myself. 99.9% of the code that we have no clue about, Frank could help with. Even the parts of the code Andree wrote are quite alien to us. If anyone can help with actual coding, now is the time to offer your help. We truly want to make something special out of this lossy codec and continue to develop it even beyond what was planned before. In the next week I'll share a few of the samples we're working with. I expect to hear from anyone who cares and knows how to perform an ABX test. Any help is better than staying on the side and watching the others.

Hi,
I wonder if the "MPC seeking issue" is related to the decoder or to the encoder natively?
This point is quite interesting in case Rockbox begin the codec implementation...

Best regards,
Tanguy

For SSE2 I think you cannot just leave it upto the C complier to work it out, the reason the special ogg encoder is so fast is they have written SSE2 in assembly. It is possible with to do it in the C compiler, but it will be compiler specific and for that thought (you possibly only have 4 functions that need sse2) you could universally add it in assembly. It is a dangerous path to step down then you have to look at code which with long jumps is invalidating your level 0 cache, perhaps HT optomizing? could get obsessive

Again, they use SSE, not SSE2. IIRC there were some SSE2 versions but the speed gain between non-SSE & SSE was much bigger than between SSE & SSE2. I don't know how it is with quality though.

SSE = 32 bit float arithmethic
SSE2 = 64 bit float arithmethic

If the code uses 32 bit floats, you're not going to get speedup from SSE2.

Except if you need the 32 bits float to int convertion that is part of SSE2. (actually I am wondering why it was not already there in SSE)

SSE already has some 32 float->int conversion instructions?

Yes, but SSE only provides float->int convertion of two 32bits floats at once, while SSE2 is providing the same operation on 4 at once.

Double precision floats are also usefull for fast float->int conversions. I think that in this case SSE2 might also provide advantages with its ability to handle double precision floats. (but this is untested as I do not have any SSE2 computer)

Wouldn't seeking be related to the framing, in which case sv8 is likely to be the first 'fixed' version. I've never had a problem with it myself, as iirc foobar2000 builds seek tables in advance.

Thanks Seany,
So SV8 is still planned... Cool news indeed...

mppenc listening test #1 - "I care because you do"

Thank you, Seed.