Go Back   Cockos Incorporated Forums > Projects > Deprecated REAPER issue tracker > Closed Issue

lame_enc.dll not feeded with floating point data Issue Tools
issueid=2298 04-09-2010 05:06 AM
Human being with feelings
lame_enc.dll not feeded with floating point data

Currently REAPER isn't feeding the lame_enc.dll with floating point data! Should be fixed.


Quote:
Originally Posted by robert (LAME developer)
If Reaper is using the old Blade replacement API functions (beEncodeChunk), then it will likely feed LAME with 16 bit short values. Though, it could use some newer functions to pass floating point values into LAME (beEncodeChunkFloatS16NI).
Quote:
Originally Posted by Changlog
2001-12-21 11:58 jd-

* Dll/: BladeMP3EncDLL.c, BladeMP3EncDLL.def, BladeMP3EncDLL.h:

Added DLL interface function beEncodeChunkFloatS16NI for floating point audio
Samples are input within the range +/- 32768, in non-interleaved channels

http://www.hydrogenaudio.org/forums/...dpost&p=699518


FIXED (3.46pre2)
Issue Details
Issue Type Closed Issue
Project Deprecated REAPER issue tracker
Category Plugins
Status Not a Reaper Bug
Priority 8
Affected Version 3.4
Closed Version (none)
Yes votes 0
No votes 0
Assigned Users (none)
Tags (none)

04-09-2010 05:58 AM
Administrator
 
When using the Blade API, Reaper is supplying floating point values via beEncodeChunkFloatS16NI, so this is not an issue.

BTW Reaper uses the Blade API only on Win32.

... note that Reaper does clamp the floating point output to +0dB when encoding to mp3.
Reply
04-09-2010 06:12 AM
Human being with feelings
 
Quote:
Originally Posted by schwa
... note that Reaper does clamp the floating point output to +0dB when encoding to mp3.
Why is this?


FIXED (3.46pre2)
Reply
04-09-2010 06:29 AM
Administrator
 
Probably because of ambiguity in LAME documentation. beEncodeChunkFloatS16NI doesn't seem to be documented at all, and lame_encode_buffer_float is documented with

* !! NOTE: !! data must still be scaled to be in the same range as short int, +/- 32768

That does say "scaled" rather than "scaled and clamped" ... before changing Reaper to allow passing unclamped floating point values to LAME for encoding), we should verify that it won't break either by looking in the LAME source code directly, or getting a statement with high confidence from someone who is familiar with the code.
Reply
04-09-2010 06:51 AM
Human being with feelings
 
Ok, I've forwared your answers to get a statement.

FIXED (3.46pre2)


I tried lame.exe ("LAME 3.98.4 modified to add float wav input" version from http://www.rarewares.org) and there I don't loose >0dB content when feeding 32bit float wav into it. I can later bring down the MP3 and nothing got clamped/clipped.
Reply
04-10-2010 07:22 AM
Human being with feelings
 
schwa,

I think the LAME developer already said that it shouldn't be clamped.


I was asking this:

Quote:
Originally Posted by Dstruct
I've just tried it in REAPER (via 3.98.4 lame_enc.dll from Rarewares). Stuff over >0dB gets lost in the MP3. So lame_enc.dll doesn't handle floating point input properly yet? Or is REAPER not feeding it properly (which I doubt)?
And the LAME developer answered

Quote:
Originally Posted by robert
If Reaper is using the old Blade replacement API functions (beEncodeChunk), then it will likely feed LAME with 16 bit short values. Though, it could use some newer functions to pass floating point values into LAME (beEncodeChunkFloatS16NI).

FIXED (3.46pre2)


The next version also seems to get 32bit float input support:

Quote:
Originally Posted by LAME 3.99 alpha 3
preparing to use ieee float [-1,+1] as internal pcm sample representation in LAME frontend
Reply
04-10-2010 07:46 AM
Administrator
 
LAME already has 32 bit float input support (which Reaper uses), the only issue is whether there is any maximum (normalized) absolute value for the floating point inputs. In fact that last comment suggests that they will be clamping internally (though it isn't totally clear).
Reply
04-10-2010 07:54 AM
Human being with feelings
 
But I tried lame.exe ("LAME 3.98.4 modified to add float wav input" version from http://www.rarewares.org) and there I don't loose >0dB content when feeding 32bit float wav into it. I can later bring down the MP3 and nothing got clamped/clipped. No distortion.


Shouldn't lame_enc.dll behave the same?

FIXED (3.46pre2)
Reply
04-10-2010 07:57 AM
Administrator
 
The concern would be that there may be some encoder settings where supplying >0dB inputs would break things. Or that inputs up to +6dB will work but over +6dB would break, or other details that we don't know about.
Reply
04-10-2010 07:57 AM
Human being with feelings
 
Ok, let's wait for some answer(s) then.

FIXED (3.46pre2)
Reply
04-10-2010 12:20 PM
Human being with feelings
 
the authors (robert) will give a shorter and probably better defined answer.

3.98.4

BladeMP3EncDLL.c
http://lame.cvs.sourceforge.net/view....1&view=markup

Code:
// accept floating point audio samples, scaled to the range of a signed 16-bit
//  integer (within +/- 32768), in non-interleaved channels  -- DSPguru, jd
__declspec(dllexport) BE_ERR	beEncodeChunkFloatS16NI(HBE_STREAM hbeStream, DWORD nSamples, 
                                                        PFLOAT buffer_l, PFLOAT buffer_r, PBYTE pOutput, PDWORD pdwOutput)
{
    int nOutputSamples;
    lame_global_flags*	gfp = (lame_global_flags*)hbeStream;

    nOutputSamples = lame_encode_buffer_float(gfp,buffer_l,buffer_r,nSamples,pOutput,0);

    if ( nOutputSamples >= 0 )
    {
        *pdwOutput = (DWORD) nOutputSamples;
    }
    else
    {
        *pdwOutput=0;
        return BE_ERR_BUFFER_TOO_SMALL;
    }

    return BE_ERR_SUCCESSFUL;
}
lame_encode_buffer_float(), lame_encode_buffer_sample_t() uses sample_t type (float). i don't see any automatic, internal limiting, but feeding +6dbfs (or so) signals might give some other (encoding) problems.

otherwise manual scaling is done with:

lame.c
http://lame.cvs.sourceforge.net/view...43&view=markup
Code:
//...
///lame_encode_buffer_sample_t()
//...
 /* Apply user defined re-scaling */

    /* user selected scaling of the samples */
    if (NEQ(gfp->scale, 0) && NEQ(gfp->scale, 1.0)) {
        for (i = 0; i < nsamples; ++i) {
            in_buffer[0][i] *= gfp->scale;
            if (gfc->channels_out == 2)
                in_buffer[1][i] *= gfp->scale;
        }
    }
and..

machine.h
http://lame.cvs.sourceforge.net/view...34&view=markup

Code:
/* sample_t must be floating point, at least 32 bits */
typedef FLOAT sample_t;
typedef sample_t stereo_t[2];
#if 1
#define EQ(a,b) (\
(fabs(a) > fabs(b)) \
 ? (fabs((a)-(b)) <= (fabs(a) * 1e-6f)) \
 : (fabs((a)-(b)) <= (fabs(b) * 1e-6f)))
#else
#define EQ(a,b) (fabs((a)-(b))<1E-37)
#endif 

#define NEQ(a,b) (!EQ(a,b))
//...
Reply
04-15-2010 06:11 PM
Human being with feelings
 
@schwa:

Here a new reply:

Quote:
Originally Posted by robert (LAME developer)
LAME won't break if you feed float values above "full-scale".
http://www.hydrogenaudio.org/forums/...dpost&p=700940


So can we change this now in REAPER or is it still now enough proof?


FIXED (3.46pre2)
Reply
Reply

Issue Tools
Subscribe to this issue

All times are GMT -7. The time now is 04:06 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.