LAME (Lame Aint an MP3 Encoder)

Hi all,

I was wondering if there's a prog for sifting through a directory of MP3s and detecting those encoded by LAME, and pulling the version of LAME used and potentially other encoding meta data (eg, switches used).

I'm also wondering if there's a Windows port if such an application exists.

Thanks,

Eric

Hello,

My partner and I are both high school students who are working on a
device that encrypts secret messages into sound files. The method that
we are using involves the conversion of data into an mp3 format, and
this results in a loss of data that is crucial to the success of the
device. We would like to be able to predict which points are going to
be modified significantly or lost completely when we write our data as
an mp3. Could you help us?

We were able to achieve success with .flac files (since they're a
lossless audio format), but with mp3 files, were unable to recover the
secret message since the mp3 compression altered the data points. We
were thinking that if we could know which points (in the time domain)
would be adversely affected, we could avoid those points. Any
clarification on how .mp3 files compress data would be very helpful.
Thank you!

Patches item #3507729, was opened at 2012-03-18 04:06
Message generated for change (Tracker Item Submitted) made by idigdoug
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300290&aid=3507729&group_id=290

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: libmp3lame
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Doug Cook (idigdoug)
Assigned to: Nobody/Anonymous (nobody)
Summary: static_assert fails to link on some systems

Initial Comment:
On some systems (notably VC2012 beta), the form of static_assert used in psymodel.c leads to a link error. The attached patch changes this to use a different static assertion that seems to have better behavior.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300290&aid=3507729&group_id=290

Bugs item #3084227, was opened at 2010-10-09 03:45
Message generated for change (Comment added) made by riccardoferri
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100290&aid=3084227&group_id=290

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Libraries
Group: Quality
Status: Open
Resolution: None
Priority: 6
Private: No
Submitted By: tiger man (t1g3rm4n)
Assigned to: Robert Hegemann (robert)
Summary: low birate compression is better with 3.96

Initial Comment:
Hi, i\'m compressing some wavs for a website at 64 kbps and i\'ve just discovered that from lame 3.97 and following compression is worst than 3.96.1
I\'ve attached two mp3, you can clearly hear it on the kick drum, with 3.96 is equal every shot while with 3.98 it changes overtime and it addsl also a little distortion sometimes.
Hope this helps, in the meantime i keep using 3.96.1.
command line is --cbr -q 0 -b 64
thanks for reading.


----------------------------------------------------------------------

Comment By: Riccardo Ferri (riccardoferri)
Date: 2012-03-17 16:47

Message:
Hallo, i've noticed this issue also on 3.99.3, any news about it ?
Also i have a request, would it be possible to include the older algorythm
on newer lame releases, something like --cbr-old ? like you have done for
vbr?
It would be very nice as 3.96.1 is still the best encoder for cbr up to
160kbps, also the build i have was for ppc only so it doesn't works anymore
under osx 10.7 Lion. Lastly,  it's extremely slow on OSX (less than 1x with
q 0).
thanks.

----------------------------------------------------------------------

Comment By: tiger man (t1g3rm4n)
Date: 2011-07-19 18:32

Message:
i just want to add that this issue is not strictly related to this audio
file, you can hear this issue on most electronic/looped music, expecially
tracks with few sounds, where drums transients are clearly audible.

----------------------------------------------------------------------

Comment By: tiger man (t1g3rm4n)
Date: 2011-07-19 18:25

Message:
Hi, i have done more tests, with lame 3.97 and newer there are issues with
cbr encodings, while vbr are ok.
comparing this 2 command lines:

with lame 3.96.1
--cbr -b 80 -q 0 -k

with any lame newer than 3.96.1 (currently i'm using 3.98.3)
--cbr -b 80 -q 0 --highpass 0.01 --lowpass 21.00

this is to make sure that no filters will be applied on both conversions,
including resample.

as you can hear from the new attached files, conversion with the old lame
is quite good, very precise and almost all transients are reproduced fine,
while on 3.98 it's quite noticeable the loss of precision and quality.

the more you go up with kbps, the less this bad effect appears,
unfortunately it looks it totally goes away only at 192kbps, it's very rare
and barely noticeable at 160kbps.

i've attached the 2 new tests, and for file size reasons a -V 0 mp3 that
you can decode to wav in order to test by yourselves.

thanks

----------------------------------------------------------------------

Comment By: tiger man (t1g3rm4n)
Date: 2011-03-11 10:31

Message:
Hi, here's the wav, can't upload here because of file size sorry:

http://rapidshare.com/files/452074419/slice.wav

I've tried with 3.99 alpha14, in this case it looks much better than
previous versions but 3.96 is still better, on this file is barely
noticeable but please try this second wav, is the same track but in another
point:

http://rapidshare.com/files/452074437/slice2.wav

i've tried with 3.96, 3.98.4 and 3.99 alpha14 (all x86) using this command
line

lame.exe --cbr -q 0 -m s -b 80 *.wav

3.96.1 - no noticeable issues
3.98.4 - similar to 3.96 but it's less precise and sometimes it loses some
high frequencies and gives an effect like a little saturation or
"underwater"
3.99 a14 - probably the worst one, it lose a lot of high frequencies
compared to 3.96 and it seems the "underwater" effect is constantly active.

i've tried compressing at 64kbps with 3.96 and it looks like it's better
than 3.99a14 at 80kbps, it has less high frequencies but it does not have
that ugly bubbly effect.

maybe i'm missing something on the command line ?
Hope this helps and thanks for getting into it

----------------------------------------------------------------------

Comment By: Robert Hegemann (robert)
Date: 2011-03-05 06:14

Message:
Would it be possible to upload the corresponding uncompressed wave file?
Else, as current CVS has some fix for some other CBR related report, could
you try latest 3.99 alpha 14?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100290&aid=3084227&group_id=290

The existing static assert used in machine.h and psymodel.c is problematic.

#define STATIC_ASSERT_EQUAL_DIMENSION(A,B) \
{extern char static_assert_##A[dimension_of(A) == dimension_of(B) ? 1
: -1];(void) static_assert_##A;}

It creates a symbol and references it, meaning the symbol may not be
optimized away. In addition, while this is probably a compiler bug, it
does fail to compile when using the VC2012 beta with LTCG enabled.

My preferred definition for this static assertion is as follows:

#define STATIC_ASSERT_EQUAL_DIMENSION(A,B) \
enum {static_assert_##A = 1/((dimension_of(A) == dimension_of(B)) ? 1 : 0)}

This works, doesn't define anything, and fixes my build failure.

Please consider fixing this.

Thanks!
Doug

Hi

Regarding the bug I previously reported here :
http://sourceforge.net/tracker/?func=detail&atid=100290&aid=3498760&group_id=290 
<http://sourceforge.net/tracker/?func=detail&atid=100290&aid=3498760&group_id=290>
<http://www.hydrogenaudio.org/forums/index.php?showtopic=93864&st=0&gopid=788612>http://www.hydrogenaudio.org/forums/index.php?showtopic=93864

I wrote a small patch to fix it, it basically adds a third parameter to 
/optimum_bandwidth/ function to inform that the track is in mono/stereo 
and change the lowpass frequency calculation accordingly.

Here is the patch :

diff -rupN lame-3.99.5/libmp3lame/lame.c 
lame-3.99.5-lowpassfix/libmp3lame/lame.c
--- lame-3.99.5/libmp3lame/lame.c    2011-10-18 23:51:20.000000000 +0200
+++ lame-3.99.5-lowpassfix/libmp3lame/lame.c    2012-03-08 
20:33:53.981285364 +0100
@@ -191,11 +191,12 @@ lame_init_params_ppflt(lame_internal_fla


  static void
-optimum_bandwidth(double *const lowerlimit, double *const upperlimit, 
const unsigned bitrate)
+optimum_bandwidth(double *const lowerlimit, double *const upperlimit, 
const unsigned bitrate, const int stereo)
  {
  /*
   *  Input:
   *      bitrate     total bitrate in kbps
+ *      stereo      0 for mono channel calculation, non 0 for stereo
   *
   *   Output:
   *      lowerlimit: best lowpass frequency limit for input filter in Hz
@@ -228,8 +229,10 @@ optimum_bandwidth(double *const lowerlim
          {320, 20500}
      };

-
-    table_index = nearestBitrateFullIndex(bitrate);
+    if(stereo)
+        table_index = nearestBitrateFullIndex(bitrate);
+    else
+        table_index = nearestBitrateFullIndex(bitrate*2);

      (void) freq_map[table_index].bitrate;
      *lowerlimit = freq_map[table_index].lowpass;
@@ -711,11 +714,11 @@ lame_init_params(lame_global_flags * gfp

          switch (gfp->VBR) {
          case vbr_off:{
-                optimum_bandwidth(&lowpass, &highpass, gfp->brate);
+                optimum_bandwidth(&lowpass, &highpass, gfp->brate, 
gfp->mode!=MONO);
                  break;
              }
          case vbr_abr:{
-                optimum_bandwidth(&lowpass, &highpass, 
gfp->VBR_mean_bitrate_kbps);
+                optimum_bandwidth(&lowpass, &highpass, 
gfp->VBR_mean_bitrate_kbps, gfp->mode!=MONO);
                  break;
              }
          case vbr_rh:{
@@ -759,9 +762,6 @@ lame_init_params(lame_global_flags * gfp
              }
          }

-        if (gfp->mode == MONO && (gfp->VBR == vbr_off || gfp->VBR == 
vbr_abr))
-            lowpass *= 1.5;
-
          gfp->lowpassfreq = lowpass;
      }

Bugs item #3498760, was opened at 2012-03-07 09:39
Message generated for change (Tracker Item Submitted) made by eiyuxuzeloor
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100290&aid=3498760&group_id=290

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Frontends (lame/mp3x/...)
Group: Quality
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: eiyuxuzeloor (eiyuxuzeloor)
Assigned to: Nobody/Anonymous (nobody)
Summary: Lowpass differs with same bitrate per channel

Initial Comment:
I am encoding a mono file to mp3 with Lame and a bitrate of 80, and a stereo file with a bitrate of 160.
I'm using preset cbr.
Since the bitrate per channel is the same in both cases, I expect the lowpass to be the same, but it is not.

See here for more details : http://www.hydrogenaudio.org/forums/index.php?showtopic=93864

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100290&aid=3498760&group_id=290

Anyone? I didn't think that this was a difficult question. Well, at
least I hoped.

Am Wed, 29 Feb 2012 10:31:57 +0100
schrieb Thomas Orgis <thomas-forum@...>: 

> So... I suppose "LAME3.95 " is from 3.95.0. How does the string from
> 3.95.1 look, exactly? Is it "LAME3.95r"?

I did some testing and it seems like 3.95.1 writes the same
string as 3.95 . Now, is there an additional trick how I can identify
the version? Some auxilliary info in the tag that reveals the true
encoder?


Alrighty then,

Thomas

To Whom it may consern:

I have found undesireable effects from your MP3 Encoder and to be blunt I
am fed up of looseing the sound on my You Tube Videos among other such
programs every time your Encoder message pops up, which forces me to exit
any and all programs I have running on my computer and restart, this is the
40`s time (and I have been keeping count)

I hope it is a simple bug for doing business this way is a federal offense
last I checked. Either way it is not doing your product or your company any
good to continue on with out solveing this problem.

I am sure you would be frustrated and rather upset if you also have to
restart your computer every single time espesialy in the middle of working
on a program your self.

Also I am not intrested in your Encoder as I have a encoder all ready and
besides to be frank when your Advert pops up my blood begins to boil so I
am rather well put off from your product as a whole, please fix this or you
will find that your product wont attract much if any clients.

Yours in Frustration and in respect:

Arnold