Re: Double precision

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 <[email protected]> wrote:
>>>
>>>> Am Thu, 20 Jun 2013 18:31:58 +0200
>>>> schrieb Ove Karlsen <[email protected]>:
>>>>
>>>>> 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