Double precision

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Double precision

Ove Karlsen
Does anyone know if increasing internal resolution in lame encoder would
be trivial? I thought in 2013, it might be nice to increase that to double.

Please CC me.

Peace Be With You.

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev
Reply | Threaded
Open this post in threaded view
|

Re: Double precision

Thomas Orgis
Am Thu, 20 Jun 2013 18:31:58 +0200
schrieb Ove Karlsen <[hidden email]>:

> Does anyone know if increasing internal resolution in lame encoder would
> be trivial? I thought in 2013, it might be nice to increase that to double.

Well, in 2013 you'd rather port the single precision code to run on GPUs;-)

But really, is there any hint that double precision would help anything
with MP3 quality? Even for studio productions, I only see 32 bit float PCM
as top-notch format. Would using double precision for intermediate
calculations really make any difference on a resulting bitstream? I'm
not even talking about audible differences.


Alrighty then,

Thomas

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev
Reply | Threaded
Open this post in threaded view
|

Re: Double precision

Ove Karlsen
On 6/21/2013 3:36 PM, Ove Karlsen wrote:

> On 6/21/2013 3:22 PM, Thomas Orgis wrote:
>> Am Thu, 20 Jun 2013 18:31:58 +0200
>> schrieb Ove Karlsen <[hidden email]>:
>>
>>> Does anyone know if increasing internal resolution in lame encoder
>>> would
>>> be trivial? I thought in 2013, it might be nice to increase that to
>>> double.
>> Well, in 2013 you'd rather port the single precision code to run on
>> GPUs;-)
> If you can massively parallelize it, then GPU might benefit.
>>
>> But really, is there any hint that double precision would help anything
>> with MP3 quality? Even for studio productions, I only see 32 bit
>> float PCM
>> as top-notch format.
> It was.. in 2000.
>> Would using double precision for intermediate
>> calculations really make any difference on a resulting bitstream? I'm
>> not even talking about audible differences.
> It sounds a bit more natural to me. If one only was doing bitcopies
> ofcourse nothing would change, but usually one does some processing in
> there, that benefits from precision.
>>
>>
>> Alrighty then,
>>
>> Thomas
> Peace Be With You!
Also I looked barely at the code. It says "sample_t" is internal
resolution, however I guess other parts of processing needs double aswell?

Peace Be With You.

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev
Reply | Threaded
Open this post in threaded view
|

Re: Double precision

Alexander Leidinger
In reply to this post by Thomas Orgis
On Fri, 21 Jun 2013 15:22:58 +0200
Thomas Orgis <[hidden email]> wrote:

> Am Thu, 20 Jun 2013 18:31:58 +0200
> schrieb Ove Karlsen <[hidden email]>:
>
> > Does anyone know if increasing internal resolution in lame encoder
> > would be trivial? I thought in 2013, it might be nice to increase
> > that to double.
>
> Well, in 2013 you'd rather port the single precision code to run on
> GPUs;-)
>
> But really, is there any hint that double precision would help
> anything with MP3 quality? Even for studio productions, I only see 32
> bit float PCM as top-notch format. Would using double precision for
> intermediate calculations really make any difference on a resulting
> bitstream? I'm not even talking about audible differences.

I remember that we had a switch in the code which changed from float to
double. I don't remember if we removed it at some point or if we still
have it. IIRC we also had an option for in the unix configure script
for this.

In general the difference between IEEE float and IEEE double _can_ make
a huge difference in the precision in the numbers if you just look at
the values. To understand it correctly you would have to learn about
the corresponding IEEE standard. In short (and exagerated): if you are
unlucky a simple integer value X would be represented in float as
(X-1).9 or some similar floating point value around the real value. For
double values the difference between the real value and the represented
value in memory is smaller. This starts to matter when you do a lot of
calculations (specially multiplications or divisions) with those
values, the "error" can accumulate to a big value.

Now... for the audible difference... well, the whole concept of MP3 is
to rely on the fact that the ear does not hear at all deviations from
the original.

Bye,
Alexander.

--
http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID = 72077137

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev
Reply | Threaded
Open this post in threaded view
|

Re: Double precision

Ove Karlsen
On 6/21/2013 10:36 PM, Alexander Leidinger wrote:

> On Fri, 21 Jun 2013 15:22:58 +0200
> Thomas Orgis <[hidden email]> wrote:
>
>> Am Thu, 20 Jun 2013 18:31:58 +0200
>> schrieb Ove Karlsen <[hidden email]>:
>>
>>> Does anyone know if increasing internal resolution in lame encoder
>>> would be trivial? I thought in 2013, it might be nice to increase
>>> that to double.
>> Well, in 2013 you'd rather port the single precision code to run on
>> GPUs;-)
>>
>> But really, is there any hint that double precision would help
>> anything with MP3 quality? Even for studio productions, I only see 32
>> bit float PCM as top-notch format. Would using double precision for
>> intermediate calculations really make any difference on a resulting
>> bitstream? I'm not even talking about audible differences.
> I remember that we had a switch in the code which changed from float to
> double. I don't remember if we removed it at some point or if we still
> have it. IIRC we also had an option for in the unix configure script
> for this.
That would be excellent. I am going to look for it then.

>
> In general the difference between IEEE float and IEEE double _can_ make
> a huge difference in the precision in the numbers if you just look at
> the values. To understand it correctly you would have to learn about
> the corresponding IEEE standard. In short (and exagerated): if you are
> unlucky a simple integer value X would be represented in float as
> (X-1).9 or some similar floating point value around the real value. For
> double values the difference between the real value and the represented
> value in memory is smaller. This starts to matter when you do a lot of
> calculations (specially multiplications or divisions) with those
> values, the "error" can accumulate to a big value.
Only on simple IIRs the difference can be heard. It might take a
high-end D/A though (multibit).
>
> Now... for the audible difference... well, the whole concept of MP3 is
> to rely on the fact that the ear does not hear at all deviations from
> the original.
Yes. I do still think that internal resolution should be double though.
>
> Bye,
> Alexander.
>
Peace Be With You!

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev
Reply | Threaded
Open this post in threaded view
|

Re: Double precision

Ove Karlsen-2
On 6/21/2013 11:19 PM, Ove Karlsen wrote:

> On 6/21/2013 10:36 PM, Alexander Leidinger wrote:
>> On Fri, 21 Jun 2013 15:22:58 +0200
>> Thomas Orgis <[hidden email]> wrote:
>>
>>> Am Thu, 20 Jun 2013 18:31:58 +0200
>>> schrieb Ove Karlsen <[hidden email]>:
>>>
>>>> Does anyone know if increasing internal resolution in lame encoder
>>>> would be trivial? I thought in 2013, it might be nice to increase
>>>> that to double.
>>> Well, in 2013 you'd rather port the single precision code to run on
>>> GPUs;-)
>>>
>>> But really, is there any hint that double precision would help
>>> anything with MP3 quality? Even for studio productions, I only see 32
>>> bit float PCM as top-notch format. Would using double precision for
>>> intermediate calculations really make any difference on a resulting
>>> bitstream? I'm not even talking about audible differences.
>> I remember that we had a switch in the code which changed from float to
>> double. I don't remember if we removed it at some point or if we still
>> have it. IIRC we also had an option for in the unix configure script
>> for this.
> That would be excellent. I am going to look for it then.
>>
>> In general the difference between IEEE float and IEEE double _can_ make
>> a huge difference in the precision in the numbers if you just look at
>> the values. To understand it correctly you would have to learn about
>> the corresponding IEEE standard. In short (and exagerated): if you are
>> unlucky a simple integer value X would be represented in float as
>> (X-1).9 or some similar floating point value around the real value. For
>> double values the difference between the real value and the represented
>> value in memory is smaller. This starts to matter when you do a lot of
>> calculations (specially multiplications or divisions) with those
>> values, the "error" can accumulate to a big value.
> Only on simple IIRs the difference can be heard. It might take a
> high-end D/A though (multibit).
>>
>> Now... for the audible difference... well, the whole concept of MP3 is
>> to rely on the fact that the ear does not hear at all deviations from
>> the original.
> Yes. I do still think that internal resolution should be double though.
>>
>> Bye,
>> Alexander.
>>
> Peace Be With You!

./configure --help did not list it.

Anyway I am compiling a windows binary ATM, and have looked at
configMS.h also. I can´t see any mention of it. I also saw some various
discussions in a search online, where doubles where criticised for
speed. So I don´t know if that resulted in favorising 32bit code.

No one knows the code good enough to just know the variables that need
resolution increase, to keep a double precision signalpath, and processing?

--
Ove Karlsen,
www.ovekarlsen.com


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev
Reply | Threaded
Open this post in threaded view
|

Re: Double precision

Ove Karlsen-2
On 6/22/2013 9:37 AM, Ove Karlsen wrote:

> On 6/21/2013 11:19 PM, Ove Karlsen wrote:
>> On 6/21/2013 10:36 PM, Alexander Leidinger wrote:
>>> On Fri, 21 Jun 2013 15:22:58 +0200
>>> Thomas Orgis <[hidden email]> wrote:
>>>
>>>> Am Thu, 20 Jun 2013 18:31:58 +0200
>>>> schrieb Ove Karlsen <[hidden email]>:
>>>>
>>>>> Does anyone know if increasing internal resolution in lame encoder
>>>>> would be trivial? I thought in 2013, it might be nice to increase
>>>>> that to double.
>>>> Well, in 2013 you'd rather port the single precision code to run on
>>>> GPUs;-)
>>>>
>>>> But really, is there any hint that double precision would help
>>>> anything with MP3 quality? Even for studio productions, I only see 32
>>>> bit float PCM as top-notch format. Would using double precision for
>>>> intermediate calculations really make any difference on a resulting
>>>> bitstream? I'm not even talking about audible differences.
>>> I remember that we had a switch in the code which changed from float to
>>> double. I don't remember if we removed it at some point or if we still
>>> have it. IIRC we also had an option for in the unix configure script
>>> for this.
>> That would be excellent. I am going to look for it then.
>>>
>>> In general the difference between IEEE float and IEEE double _can_ make
>>> a huge difference in the precision in the numbers if you just look at
>>> the values. To understand it correctly you would have to learn about
>>> the corresponding IEEE standard. In short (and exagerated): if you are
>>> unlucky a simple integer value X would be represented in float as
>>> (X-1).9 or some similar floating point value around the real value. For
>>> double values the difference between the real value and the represented
>>> value in memory is smaller. This starts to matter when you do a lot of
>>> calculations (specially multiplications or divisions) with those
>>> values, the "error" can accumulate to a big value.
>> Only on simple IIRs the difference can be heard. It might take a
>> high-end D/A though (multibit).
>>>
>>> Now... for the audible difference... well, the whole concept of MP3 is
>>> to rely on the fact that the ear does not hear at all deviations from
>>> the original.
>> Yes. I do still think that internal resolution should be double though.
>>>
>>> Bye,
>>> Alexander.
>>>
>> Peace Be With You!
>
> ./configure --help did not list it.
>
> Anyway I am compiling a windows binary ATM, and have looked at
> configMS.h also. I can´t see any mention of it. I also saw some
> various discussions in a search online, where doubles where criticised
> for speed. So I don´t know if that resulted in favorising 32bit code.
>
> No one knows the code good enough to just know the variables that need
> resolution increase, to keep a double precision signalpath, and
> processing?
>
PS: I saw -k has been removed also. Seems to be a bit agressive patching
going on. I actually use that option. High bitrates are better without
additional filtering, which can add ring and phasecharacther.
On lame 3.97 -mj -q0 -k -V2 -b160 -B192 --abr 190, sounds very good. I
don´t know if the -V2 makes much difference in there at the moment.
Better might be without the --abr, and instead be able to limit to any
bitrate. -b170 -B180 for instance.

I thought this with 64bit internal processing would be optimal for mp3.

Peace Be With You.

--
Ove Karlsen,
www.ovekarlsen.com


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev
Reply | Threaded
Open this post in threaded view
|

Re: Double precision

Thomas Orgis
Am Sat, 22 Jun 2013 14:13:11 +0200
schrieb Ove Karlsen <[hidden email]>:

> I thought this with 64bit internal processing would be optimal for mp3.

I just wanted to note that I do see the point that there might be gains
in the computations if intermediate results are handled in double
precision. Errors can accumulate, sure. Improvement of mathematical
error should be measurable, considering corresponding input WAV and
using a decoder that also honours the precision (libmpg123 needs some
patching to really support double precision, but not much). But I
presume there is serious double-blind-testing to do to determine
audible difference.

It would be interesting to see if raised internal precision has any
effect at all with 16 bit input. Disclaimer: I didn't work on LAME code
myself, so don't know details on how the filters are implemented.


Alrighty then,

Thomas

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev
Reply | Threaded
Open this post in threaded view
|

Re: Double precision

Alexander Leidinger
In reply to this post by Ove Karlsen-2
On Sat, 22 Jun 2013 09:37:01 +0200
Ove Karlsen <[hidden email]> wrote:

> On 6/21/2013 11:19 PM, Ove Karlsen wrote:

> ./configure --help did not list it.
>
> Anyway I am compiling a windows binary ATM, and have looked at
> configMS.h also. I can´t see any mention of it. I also saw some
> various discussions in a search online, where doubles where
> criticised for speed. So I don´t know if that resulted in favorising
> 32bit code.
>
> No one knows the code good enough to just know the variables that
> need resolution increase, to keep a double precision signalpath, and
> processing?

I searched for what I had in mind, I found:
http://lame.cvs.sourceforge.net/viewvc/lame/lame/configure.in?r1=1.137&r2=1.138
But this is the other way around, I removed a configure option which
switched from double to float (disabled by default).

If you look at the source (libmp3lame directory), you will see that a
lot of places with floating point variables use "FLOAT" as the type.

Then look at machine.h, search there for FLOAT and FLOAT8.

Bye,
Alexander.

--
http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID = 72077137

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev
Reply | Threaded
Open this post in threaded view
|

Re: Double precision

bouvigne
In reply to this post by Thomas Orgis
Le 22/06/2013 16:47, Thomas Orgis a écrit :
> It would be interesting to see if raised internal precision has any
> effect at all with 16 bit input. Disclaimer: I didn't work on LAME code
> myself, so don't know details on how the filters are implemented.

Using double instead of float has some effect, for sure, as the
resulting file will be different. The question is then to know if this
has any audible effect or not.

Changing compilation options, using assembly or not, or compiling for a
different architecture (x86 vs x86_64) all have some impact on the
resulting bitstream.

I actually asked about the reverse question (changing from double to
float) in 2004:
http://osdir.com/ml/audio.mp3.lame/2004-05/msg00052.html

...so I suspect that I might actually be the one who changed the default
to float latter on (that was a long time ago, so I'm not sure anymore).

Advantages of using floats over double were then :
* ability to use the vector unit (SSE) instead of FPU, even for
processors which did not featured SSE2 instructions
* faster binary
* ability to use some SSE assembly/intrinsics (not sure if it's still
there nowadays)

Even nowadays, with proper use of SSE you can crush twice as many floats
as you could process double.
I'd even think that float over double might enable to get some
significant speed boosts through proper use of SSE or GPGPU.
Unfortunately, we don't have much SSE code in Lame, so this advantage is
still mostly theoretical.

Regarding the quality difference, I suspect that double instead of float
would only make a negligeable difference, which would be significantly
less important that other changes (like improving our resampling filter,
as an example).

--
Gabriel Bouvigne
www.mp3-tech.org
personal page: http://gabriel.mp3-tech.org


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev
Reply | Threaded
Open this post in threaded view
|

Re: Double precision

Ove Karlsen-2
On 6/30/2013 10:10 PM, Gabriel Bouvigne wrote:

> Le 22/06/2013 16:47, Thomas Orgis a écrit :
>> It would be interesting to see if raised internal precision has any
>> effect at all with 16 bit input. Disclaimer: I didn't work on LAME code
>> myself, so don't know details on how the filters are implemented.
>
> Using double instead of float has some effect, for sure, as the
> resulting file will be different. The question is then to know if this
> has any audible effect or not.
>
> Changing compilation options, using assembly or not, or compiling for
> a different architecture (x86 vs x86_64) all have some impact on the
> resulting bitstream.
>
> I actually asked about the reverse question (changing from double to
> float) in 2004:
> http://osdir.com/ml/audio.mp3.lame/2004-05/msg00052.html
>
> ...so I suspect that I might actually be the one who changed the
> default to float latter on (that was a long time ago, so I'm not sure
> anymore).
>
> Advantages of using floats over double were then :
> * ability to use the vector unit (SSE) instead of FPU, even for
> processors which did not featured SSE2 instructions
> * faster binary
> * ability to use some SSE assembly/intrinsics (not sure if it's still
> there nowadays)
>
> Even nowadays, with proper use of SSE you can crush twice as many
> floats as you could process double.
> I'd even think that float over double might enable to get some
> significant speed boosts through proper use of SSE or GPGPU.
> Unfortunately, we don't have much SSE code in Lame, so this advantage
> is still mostly theoretical.
>
> Regarding the quality difference, I suspect that double instead of
> float would only make a negligeable difference, which would be
> significantly less important that other changes (like improving our
> resampling filter, as an example).
>
Well the reason I raise the topic, is mainly one of principle. I think
there is a small benefit, and that we can afford. Also see my post on
not needing a filter and bitrates etc.  I think it would be a good
contemporary refresh of the encoder. Not that I am going to be snapping
any whip here.

I actually DID a search and replace of some floats, and managed to
compile atleast the encoder. And first impression is that it does sound
a bit more natural. That is typical for EQ´s aswell, etc. I always use
double, and find floats to give a bit quantized sound, unless one is
doing very little processing, no IIRs etc.

Anyway it was just a suggestion, and most playback equipment will not
benefit much.

Peace Be With You!

--
Ove Karlsen,
www.ovekarlsen.com


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev
Reply | Threaded
Open this post in threaded view
|

Re: Double precision

Rogério Brito
Hi.

On Sun, Jun 30, 2013 at 5:44 PM, Ove Karlsen <[hidden email]> wrote:
> I actually DID a search and replace of some floats, and managed to
> compile atleast the encoder. And first impression is that it does sound
> a bit more natural. That is typical for EQ´s aswell, etc. I always use
> double, and find floats to give a bit quantized sound, unless one is
> doing very little processing, no IIRs etc.

You said that "it does sound a bit more natural" and "find floats to
give a bit quantized sound".  Can you *really* hear the differences?
At what bitrate?

I am not really a golden ears (really, really, far from it) and I can
safely encode most of my music from my CDs with lame's -V7 and,
sometimes, with -V5.  I can say that I can't ABX most things at a
bitrate achieved by -V4 and, even though I never tested it, I would
expect to fail 100% of the time at trying ABX'ing stuff at -V2 or
higher qualities, with floats or not.

Have you really ABX'ed your results with your use of a double instead
of float? It would be highly interesting to know if you can ABX those.


Regards,

--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFCAAAA
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Lame-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/lame-dev