Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: mppenc 1.15v (Read 24203 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

mppenc 1.15v

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
And if Warhol's a genius, what am I? A speck of lint on the ***** of an alien

mppenc 1.15v

Reply #1
Quote
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
[a href="index.php?act=findpost&pid=283374"][{POST_SNAPBACK}][/a]


Nice, thank you.

How much work is left to do before tackling sv8?

mppenc 1.15v

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

mppenc 1.15v

Reply #3
Quote
Nice, thank you.

How much work is left to do before tackling sv8?
[a href="index.php?act=findpost&pid=283393"][{POST_SNAPBACK}][/a]


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.
And if Warhol's a genius, what am I? A speck of lint on the ***** of an alien

mppenc 1.15v

Reply #4
Thank you MDT!
"To understand me, you'll have to swallow a world." Or maybe your words.

mppenc 1.15v

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

mppenc 1.15v

Reply #6
"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

mppenc 1.15v

Reply #7
Quote
SSE2 is on AMD Athlons
[a href="index.php?act=findpost&pid=283544"][{POST_SNAPBACK}][/a]

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

mppenc 1.15v

Reply #8
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).
And if Warhol's a genius, what am I? A speck of lint on the ***** of an alien

mppenc 1.15v

Reply #9
Quote
Based on a c't article that showed very nice improvements for LAME with certain GCC optimizations for the Athlon 64

Do you have any link?

mppenc 1.15v

Reply #10
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

mppenc 1.15v

Reply #11
Quote
Quote
Based on a c't article that showed very nice improvements for LAME with certain GCC optimizations for the Athlon 64

Do you have any link?
[a href="index.php?act=findpost&pid=283556"][{POST_SNAPBACK}][/a]


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.

mppenc 1.15v

Reply #12
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.
And if Warhol's a genius, what am I? A speck of lint on the ***** of an alien

mppenc 1.15v

Reply #13
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

mppenc 1.15v

Reply #14
Quote
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).
[a href="index.php?act=findpost&pid=283552"][{POST_SNAPBACK}][/a]


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

mppenc 1.15v

Reply #15
Quote
the reason the special ogg encoder is so fast is they have written SSE2 in assembly.

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.

mppenc 1.15v

Reply #16
Quote
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.
[a href="index.php?act=findpost&pid=283827"][{POST_SNAPBACK}][/a]


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.

mppenc 1.15v

Reply #17
Quote
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)

mppenc 1.15v

Reply #18
Quote
Quote
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)
[a href="index.php?act=findpost&pid=284386"][{POST_SNAPBACK}][/a]


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

mppenc 1.15v

Reply #19
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)

mppenc 1.15v

Reply #20
Quote
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
[a href="index.php?act=findpost&pid=283666"][{POST_SNAPBACK}][/a]


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.

mppenc 1.15v

Reply #21
Quote
Quote
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
[a href="index.php?act=findpost&pid=283666"][{POST_SNAPBACK}][/a]


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.
[a href="index.php?act=findpost&pid=284428"][{POST_SNAPBACK}][/a]

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

mppenc 1.15v

Reply #22
mppenc listening test #1 - "I care because you do"
And if Warhol's a genius, what am I? A speck of lint on the ***** of an alien

mppenc 1.15v

Reply #23
Thank you, Seed.