Lame 3.96 beta Options

[Gabriel]

Lame 3.96 is now in beta stage.

We did some extensive tests and fixed several bugs.
If feedback is positive, we should be able to release 3.96 final around the end of March.

(note: this one is not announced on Sourceforge, as we should have a 3.96 release soon)

[dev0]

Great job.
If you want to have extensive coordinated quality testing, we could set up an extra sticky thread with instructions.

[sony666]

big thanks to everyone involved

[Hanky]

Great news. I strongly believe it's about the time now to set up a large scale quality test to make the upcoming 3.96 final the recommended version instead of the current 3.90.3

[jtclipper]

Excellent news, thank you for devoting time and effort on this free and great tool.

BTW is there a roadmap available ?

[RyanVM]

I see Alpha4 is the last release on Rarewares. Is that the same build that's now beta 1, or is the first beta build updated from there?

EDIT: Also, I don't lurk here as much as I once used to, but when did the change to APS happen that allows for 96 and 112kbps frames?

This post has been edited by RyanVM: Mar 6 2004, 20:23

[indybrett]

EDIT: Also, I don't lurk here as much as I once used to, but when did the change to APS happen that allows for 96 and 112kbps frames?

Probably with 3.95.1, which has not had extensive listening tests like 3.90.3.

Edit: grammar

This post has been edited by indybrett: Mar 6 2004, 20:38

[john33]

I see Alpha4 is the last release on Rarewares.  Is that the same build that's now beta 1, or is the first beta build updated from there?

EDIT: Also, I don't lurk here as much as I once used to, but when did the change to APS happen that allows for 96 and 112kbps frames?

The available CVS isn't updated yet. I'll catch it in the morning.

[Cryton]

Great news. I strongly believe it's about the time now to set up a large scale quality test to make the upcoming 3.96 final the recommended version instead of  the current 3.90.3

Hasn't this been discussed over and over before? People seem reluctant to invest a lot of time and effort in testing when LAME 4.0 is on its way.

[Jebus]

Great news. I strongly believe it's about the time now to set up a large scale quality test to make the upcoming 3.96 final the recommended version instead of  the current 3.90.3

Hasn't this been discussed over and over before? People seem reluctant to invest a lot of time and effort in testing when LAME 4.0 is on its way.

Yes, and in the last discussion Takahiro said that 4.0 was a long way off still. This leads me and a great many others to believe that we should upgrade now if possible.

[RyanVM]

I see Alpha4 is the last release on Rarewares.  Is that the same build that's now beta 1, or is the first beta build updated from there?

EDIT: Also, I don't lurk here as much as I once used to, but when did the change to APS happen that allows for 96 and 112kbps frames?

The available CVS isn't updated yet. I'll catch it in the morning.

For the record, I did some encoding with alpha 4 and things sound OK to me.

[john33]

Now available at Rarewares. This is actually just a bump to beta 1 from alpha 4.

[ArsonDragon]

Now available at Rarewares.   This is actually just a bump to beta 1 from alpha 4.

Just what I was waiting to try out. Thank you for putting it up, john33. And thanks to the developers, too.

[westgroveg]

CODE

ABX Results:
Original vs C:\Documents and Settings\Administrator\Desktop\TEST SAMPLES\LAME test samples\ringing-edit--APS-3.90.3.wav
   9 out of 10, pval = 0.011

CODE

ABX Results:
Original vs C:\Documents and Settings\Administrator\Desktop\TEST SAMPLES\LAME test samples\ringing-edit--APS-3.96b1.wav
   9 out of 10, pval = 0.011

3.90.3 sounded slighly better to me.

Edit: -=666=- This sample was taken from f123's site & cut down slightly, there is a HF hiss present.

This post has been edited by westgroveg: Mar 7 2004, 12:14

[getID3()]

Freeformat decoding has issues, specifically: it can't. Encode with LAME to freeformat (any bitrate) goes fine, the files play, but LAME 3.96b1 can't decode them

CODE

> lame396b1 --decode free640.mp3
Input file is freeformat.
Error reading headers in mp3 input file 640.mp3.

Decoding 3.96b1-encoded freeformat files with 3.95.1 shows some issues at high bitrates. I test-encoded a 10-second file at every bitrate between 320 and 640 and came up with these results:

• At some random (but reproducible) bitrates, LAME3951 crashes on decoding the 396b1-encoded freeformat file.
  The affected bitrates: 330, 331, 429, 493, 497, 513, 530, 534, 550, 557, 558, 568
  
• Most bitrates that don't crash give this kind of error message for all encoded frames when decoding:
  CODE
  <snip 381 preceeding frames>
  Frame#   382/24614  638 kbps   MS    fatal error.  MAXFRAMESIZE not large enough.
  Frame#   383/24614  638 kbps   MS    fatal error.  MAXFRAMESIZE not large enough.
  Frame#   384/24614  638 kbps   MS    fatal error.  MAXFRAMESIZE not large enough.
  Frame#   384/24614  638 kbps   MS    
  
  
• The few bitrates (321, 330, 331, 36, 429, 450, 475, 493, 497, 500, 513, 534, 549, 550, 551, 554, 556, 557, 558, 567, 568, 587, 588, 614, 629, 630, 634) that don't crash or spew errors give something like this:
  NOTE: the number 44000 here is arbitary - the actual value seems generally random and ranges from 222 all the way up to 3728270, with most values around 30000-50000)
  CODE
  bitstream problem (notice how it's detected as 32kHz, not 44kHz as it should be): resyncing...
  input:  free629.mp3  (32 kHz, 2 channels, MPEG-1 Layer III)
  output: free629.mp3.wav  (16 bit, Microsoft WAVE)
  skipping initial 1105 samples (encoder+decoder delay)
  Frame#     1/44000   96 kbps   bitstream problem: resyncing...
  Frame#     2/44000  128 kbps   bitstream problem: resyncing...
  Frame#     3/44000  224 kbps   bitstream problem: resyncing...
  Frame#     4/44000   56 kbps   bitstream problem: resyncing...
  Frame#     5/44000   48 kbps  
  Occasionally there's one or more of these in there as well:
  CODE
  Error: sample frequency has changed in MP3 file - not supported
  
  
• A few bitrates gave unique errors:
  CODE
  > lame --decode free530.mp3
  bitstream problem: resyncing...
  big_values too large! 306
  big_values too large! 419
  input:  free530.mp3  (8 kHz, 2 channels, MPEG-2.5 Layer III)
  output: free530.mp3.wav  (16 bit, Microsoft WAVE)
  skipping initial 1105 samples (encoder+decoder delay)
  mpg123: Bogus region length (-232)
  CODE
  > lame --decode free621.mp3
  bitstream problem: resyncing...
  big_values too large! 294
  big_values too large! 297
  mpg123: Can't rewind stream by 1093 bits!
  input:  free621.mp3  (32 kHz, 2 channels, MPEG-1 Layer III)
  output: free621.mp3.wav  (16 bit, Microsoft WAVE)
  skipping initial 1105 samples (encoder+decoder delay)
  CODE
  > lame --decode free622.mp3
  bitstream problem: resyncing...
  big_values too large! 306
  input:  free622.mp3  (8 kHz, 2 channels, MPEG-2.5 Layer III)
  output: free622.mp3.wav  (16 bit, Microsoft WAVE)
  skipping initial 1105 samples (encoder+decoder delay)
  Frame#     1/2708    32 kbps         WAVE file contains 0 PCM samples

[guruboolez]

Lame decoder doesn't fully support freeformat. Max bitrate is something like 540 or 550 kbps.
Anyway, I've tried to decode -b330 --freeformat encoding (3.96) with both 3.93 and 3.96, and it doesn't work.


EDIT: I've used lame 3.93.1 for 330 kbps encoding, and both 3.93 and 3.96 decodings are fine. Apparently, the problem concerns the encoder.

This post has been edited by guruboolez: Mar 7 2004, 19:12

[rutra80]

These latest LAME versions additionally treat some non-freeformat encodings as freeformat ones and it is problematic too. I already wrote about it in a couple of my previous posts but no interest so far...

EDIT: Ooops, it seems to be fixed in 3.96b1, sorry!

This post has been edited by rutra80: Mar 7 2004, 19:52

[CyberInferno]

I'm not sure at this rate there will ever be a validated version past 3.90.3. I'm all for development, but how are users supposed to thoroughly test 3.95.1 when 3.96 comes out a couple months after? It seems to me like all the development efforts should go to one version or the other unless there is a very specific reason to do otherwise (like if one is for cbr and the other for vbr).

[guruboolez]

Lame 3.90.x is not developped anymore. Just some extra features, like header or new VBR presets.
The only active branch is lame 3.94 and superior (and maybe 4.0, but it's something different). There's nothing wrong to see 3.96 release two months after 3.95. Lame 3.96 is just an improved version of lame 3.95. There's also nothing wrong to see 3.96 released before a collective test of the previous version. We had a lot of time to report quality bug for 3.95. Nothing happened... Lame development is just faster than lame public testing, and fortunately, developers are not waiting to us. Otherwise, lame 3.91 would be the latest version.

This post has been edited by guruboolez: Mar 8 2004, 02:58

[sony666]

I would like a switch to disable replaygain scanning, because I do it anyway after encoding with mp3gain. Currently, the only way to turn it of is disabling the whole LAME tag with -t, which is not really desireable for VBR files...

If anyone is interested in a compile with RG scan disabled at all (MSVC 7.0+NASM), I can email it. It is 10% slower than John33's binary at Rarewares.

[westgroveg]

I would like a switch to disable replaygain scanning, because I do it anyway after encoding with mp3gain. Currently, the only way to turn it of is disabling the whole LAME tag with -t, which is not really desireable for VBR files...

I agree with this because I want album/title values in my files but is there really any harm having title values in the lame tag? I think a better request would be for mp3gain to write album values to the lame tag as I have suggested many times before. Writing values to the ID3 tag can also cause tagging problems (when re-tagging or tagging after the values have been written).

This post has been edited by westgroveg: Mar 8 2004, 04:19

[fairyliquidizer]

Lame 3.96 is now in beta stage.

We did some extensive tests and fixed several bugs.
If feedback is positive, we should be able to release 3.96 final around the end of March.

(note: this one is not announced on Sourceforge, as we should have a 3.96 release soon)

Will 3.96 final be 3.96 or 3.97? :-)

This post has been edited by fairyliquidizer: Mar 20 2004, 15:37