IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
mppenc 1.15v
Seed
post Mar 18 2005, 20:22
Post #1


Musepack Project Coordinator


Group: Developer
Posts: 161
Joined: 24-June 02
Member No.: 2385



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
Go to the top of the page
+Quote Post
seanyseansean
post Mar 18 2005, 21:15
Post #2





Group: Members (Donating)
Posts: 487
Joined: 12-August 02
From: Cheltenham, UK
Member No.: 3029



QUOTE (Seed @ Mar 18 2005, 08:22 PM)
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?
Go to the top of the page
+Quote Post
krmathis
post Mar 18 2005, 21:40
Post #3





Group: Members
Posts: 742
Joined: 27-May 02
From: Oslo, Norway
Member No.: 2133



Nice work! smile.gif
Its still unbearably slow on Mac OS X though (--standard = 2.7x on my 1.5GHz PowerBook).
Go to the top of the page
+Quote Post
Seed
post Mar 18 2005, 21:42
Post #4


Musepack Project Coordinator


Group: Developer
Posts: 161
Joined: 24-June 02
Member No.: 2385



QUOTE (seanyseansean @ Mar 18 2005, 09:15 PM)
Nice, thank you.

How much work is left to do before tackling sv8?
*


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
Go to the top of the page
+Quote Post
dev0
post Mar 19 2005, 10:03
Post #5





Group: Developer
Posts: 1679
Joined: 23-December 01
From: Germany
Member No.: 731



Thank you MDT!


--------------------
"To understand me, you'll have to swallow a world." Or maybe your words.
Go to the top of the page
+Quote Post
jtclipper
post Mar 19 2005, 10:24
Post #6





Group: Members
Posts: 256
Joined: 25-May 03
From: Greece
Member No.: 6805



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


--------------------
Dimitris
Go to the top of the page
+Quote Post
spoon
post Mar 19 2005, 12:13
Post #7


dBpowerAMP developer


Group: Developer (Donating)
Posts: 2723
Joined: 24-March 02
Member No.: 1615



"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

This post has been edited by spoon: Mar 19 2005, 23:23


--------------------
Spoon http://www.dbpoweramp.com
Go to the top of the page
+Quote Post
rutra80
post Mar 19 2005, 12:58
Post #8





Group: Members (Donating)
Posts: 810
Joined: 12-September 03
Member No.: 8821



QUOTE (spoon @ Mar 19 2005, 01:13 PM)
SSE2 is on AMD Athlons
*

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

This post has been edited by rutra80: Mar 19 2005, 13:02
Go to the top of the page
+Quote Post
Seed
post Mar 19 2005, 13:12
Post #9


Musepack Project Coordinator


Group: Developer
Posts: 161
Joined: 24-June 02
Member No.: 2385



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
Go to the top of the page
+Quote Post
Gabriel
post Mar 19 2005, 13:45
Post #10


LAME developer


Group: Developer
Posts: 2950
Joined: 1-October 01
From: Nanterre, France
Member No.: 138



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?
Go to the top of the page
+Quote Post
NumLOCK
post Mar 19 2005, 13:48
Post #11


Neutrino G-RSA developer


Group: Developer
Posts: 852
Joined: 8-May 02
From: Geneva
Member No.: 2002



Seed,

Congratulations for your work, it is really appreciated smile.gif

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 rolleyes.gif

Edit: fixed spelling

This post has been edited by NumLOCK: Mar 19 2005, 13:55


--------------------
Try Leeloo Chat at http://leeloo.webhop.net
Go to the top of the page
+Quote Post
CiTay
post Mar 19 2005, 14:12
Post #12


Administrator


Group: Admin
Posts: 2377
Joined: 22-September 01
Member No.: 3



QUOTE (Gabriel @ Mar 19 2005, 01:45 PM)
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?
*



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.
Attached thumbnail(s)
Attached Image
 
Go to the top of the page
+Quote Post
Seed
post Mar 19 2005, 14:16
Post #13


Musepack Project Coordinator


Group: Developer
Posts: 161
Joined: 24-June 02
Member No.: 2385



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.

This post has been edited by Seed: Mar 19 2005, 17:49


--------------------
And if Warhol's a genius, what am I? A speck of lint on the ***** of an alien
Go to the top of the page
+Quote Post
Tang
post Mar 19 2005, 21:51
Post #14





Group: Members (Donating)
Posts: 158
Joined: 27-January 04
Member No.: 11536



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
Go to the top of the page
+Quote Post
spoon
post Mar 19 2005, 23:31
Post #15


dBpowerAMP developer


Group: Developer (Donating)
Posts: 2723
Joined: 24-March 02
Member No.: 1615



QUOTE (Seed @ Mar 19 2005, 12:12 PM)
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).
*


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 wink.gif then you have to look at code which with long jumps is invalidating your level 0 cache, perhaps HT optomizing? could get obsessive smile.gif


--------------------
Spoon http://www.dbpoweramp.com
Go to the top of the page
+Quote Post
rutra80
post Mar 20 2005, 09:13
Post #16





Group: Members (Donating)
Posts: 810
Joined: 12-September 03
Member No.: 8821



QUOTE (spoon @ Mar 20 2005, 12:31 AM)
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.

This post has been edited by rutra80: Mar 20 2005, 09:15
Go to the top of the page
+Quote Post
Garf
post Mar 22 2005, 08:37
Post #17


Server Admin


Group: Admin
Posts: 4853
Joined: 24-September 01
Member No.: 13



QUOTE (rutra80 @ Mar 20 2005, 10:13 AM)
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.
Go to the top of the page
+Quote Post
Gabriel
post Mar 22 2005, 09:15
Post #18


LAME developer


Group: Developer
Posts: 2950
Joined: 1-October 01
From: Nanterre, France
Member No.: 138



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)
Go to the top of the page
+Quote Post
Garf
post Mar 22 2005, 09:22
Post #19


Server Admin


Group: Admin
Posts: 4853
Joined: 24-September 01
Member No.: 13



QUOTE (Gabriel @ Mar 22 2005, 10:15 AM)
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)
*



SSE already has some 32 float->int conversion instructions?
Go to the top of the page
+Quote Post
Gabriel
post Mar 22 2005, 09:37
Post #20


LAME developer


Group: Developer
Posts: 2950
Joined: 1-October 01
From: Nanterre, France
Member No.: 138



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)
Go to the top of the page
+Quote Post
seanyseansean
post Mar 22 2005, 10:56
Post #21





Group: Members (Donating)
Posts: 487
Joined: 12-August 02
From: Cheltenham, UK
Member No.: 3029



QUOTE (Tang @ Mar 19 2005, 09:51 PM)
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
*


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.
Go to the top of the page
+Quote Post
Tang
post Mar 22 2005, 19:25
Post #22





Group: Members (Donating)
Posts: 158
Joined: 27-January 04
Member No.: 11536



QUOTE (seanyseansean @ Mar 22 2005, 01:56 AM)
QUOTE (Tang @ Mar 19 2005, 09:51 PM)
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
*


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... smile.gif
Go to the top of the page
+Quote Post
Seed
post Mar 25 2005, 14:33
Post #23


Musepack Project Coordinator


Group: Developer
Posts: 161
Joined: 24-June 02
Member No.: 2385



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
Go to the top of the page
+Quote Post
Somebody
post Mar 30 2005, 00:44
Post #24





Group: Members
Posts: 178
Joined: 30-September 01
Member No.: 107



Thank you, Seed.
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 19th April 2014 - 13:58