Skip to main content
Topic: Lame 3.97 beta 1 released (Read 93003 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Lame 3.97 beta 1 released

Reply #100
For the non-technical people, Gabriel: does this affect MP3 encodes? I mean, do I have to do it again with the "fixed" compile?

Sorry if this is a dumb question.
I'm the one in the picture, sitting on a giant cabbage in Mexico, circa 1978.
Reseñas de Rock en Español: www.estadogeneral.com

Lame 3.97 beta 1 released

Reply #101
This does not affect encoding, we are just discussing about decoding changes.

Lame 3.97 beta 1 released

Reply #102
Quote
Quote
What I think will be the final version of this is now at Rarewares. Includes exe, amended source files and diff files for the amendments.

I have the feeling that you are assuming that the mp2 delay is the one of current TooLame version and the mp3 delay the one of current Lame version.
Regarding mp2, this might cut the beginning of files produced with another encoder, and regarding mp3 the situation is the same unless you are reading the encoder delay field of the header.
[a href="index.php?act=findpost&pid=334080"][{POST_SNAPBACK}][/a]

Yes, the mp2 delay is that for the current tooLAME. Unless I have misunderstood, I believe that foobar uses the same value and I did assume that it should, therefore, be OK. Clearly, that could be a source of contention.

The mp3 delay I've used is the one extracted in 'lame_decode1_headersB_clipchoice' in mpglib_interface.c. Is that OK to use?

I am more than willing to be educated about these subjects!!
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/

Lame 3.97 beta 1 released

Reply #103
MP3: if you extracted the delay from the header, it should be fine.

MP2: we were using the minimum theorical encoder delay, to be sure to not cut usefull samples. Using the tooLame delay hardcoded would cut samples if you are decoding a file produced with an encoder using a smaller delay than tooLame.

Lame 3.97 beta 1 released

Reply #104
Quote
MP3: if you extracted the delay from the header, it should be fine.

MP2: we were using the minimum theorical encoder delay, to be sure to not cut usefull samples. Using the tooLame delay hardcoded would cut samples if you are decoding a file produced with an encoder using a smaller delay than tooLame.
[a href="index.php?act=findpost&pid=334095"][{POST_SNAPBACK}][/a]

Thanks Gabriel. I'll put the mp2 delay back as it was and leave the user to add an encoder delay.
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/

Lame 3.97 beta 1 released

Reply #105
OK, the final, final version is now at Rarewares!!  The written decoded mp3 file now contains the correct number of samples and is of the same length as the original wave file. The console display now also indicates the number of samples being skipped at the end of the file. mp2 decoding has been reverted as it was originally.
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/

Lame 3.97 beta 1 released

Reply #106
Has the actual decoding library (MAD, mpglib, whichever) been altered?

Lame 3.97 beta 1 released

Reply #107
Quote
Has the actual decoding library (MAD, mpglib, whichever) been altered?
[a href="index.php?act=findpost&pid=334639"][{POST_SNAPBACK}][/a]

It's mpglib, exactly as currently used in the standard compile. My compile simply makes use of information that the standard compile does not.
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/

Lame 3.97 beta 1 released

Reply #108
Okay, thanks for replying. Does it return bit-identical output to fb2k or did you simply mean it returns the same number of samples?

Lame 3.97 beta 1 released

Reply #109
Quote
Okay, thanks for replying. Does it return bit-identical output to fb2k or did you simply mean it returns the same number of samples?
[a href="index.php?act=findpost&pid=334785"][{POST_SNAPBACK}][/a]

They appear not to be bit identical, but I suspect that has something to do with fb2k's internal processing of the samples. IIRC, fb2k massages the samples internally at higher resolution.

However, if you compare the decoded wave files with the original wave file, then they both differ from the original in exactly the same numbers and positions of missing/different samples.
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/

Lame 3.97 beta 1 released

Reply #110
Thanks again john33.

Lame 3.97 beta 1 released

Reply #111
Where has the Windows version of Lame 3.97b1 gone from the Rarewares MP3 file library? 

The Hydrogenaudio Knowledgebase page on the recommended LAME version states that v3.97b is what's currently recommended.

Has the recommended LAME complile gone from beta1 to beta2?

The 1st post at the top of this thread from Sep 11 2005 states that 3.97b1 was the recommended compile at that point.  Has that changed since the last post in this thread on Oct 16 2005?  Or is there just some missing link on the Rarewares page to a Windows v3.97b1 download at this point?

There was a mention of this recently here.  But as yet there doesn't seem to be a definitive answer.

Thx

TS
Geopoliticus Child Watching the Birth of the New Man

Lame 3.97 beta 1 released

Reply #112
Quote
Has the recommended LAME complile gone from beta1 to beta2?
It's taken years for HA to recommend anything since 3.90.3 final, and are we now expecting that recommendation to be updated for each new beta ?

Don't hold your breath.

Regards,
Madrigal

Lame 3.97 beta 1 released

Reply #113
Quote
It's taken years for HA to recommend anything since 3.90.3 final, and are we now expecting that recommendation to be updated for each new beta ?
Okay... mia culpa... an admittedly poorly thought out question.  But more to the point again... where did the Rarewares link to download 3.97b1 go... and/or where can it be downloaded now?

TS
Geopoliticus Child Watching the Birth of the New Man

Lame 3.97 beta 1 released

Reply #114
Quote
Quote
It's taken years for HA to recommend anything since 3.90.3 final, and are we now expecting that recommendation to be updated for each new beta ?
Okay... mia culpa... an admittedly poorly thought out question.  But more to the point again... where did the Rarewares link to download 3.97b1 go... and/or where can it be downloaded now?

TS
[a href="index.php?act=findpost&pid=347939"][{POST_SNAPBACK}][/a]

There is no reason to use the beta 1 version. By definition, subsequent beta versions are bug fixes rather than new features, as indicated:
Quote
LAME 3.97 beta 2  November 26 2005

    * Gabriel Bouvigne:
          o Fixed an initialization error when input is not using a standard sampling frequency
          o Fixed a possible assertion failure in very low bitrate encoding
          o Slight change regarding ATH adjustment with V5
          o Reinstated bit reservoir for 320kbps CBR
          o ReplayGain analysis should now be faster when encountering silent parts
    * Takehiro Tominaga:
          o Fixed a possible link problem of assembly code

IIRC, the ATH change was as an attempt to correct an issue that was apparent using V5, and the remainder are really in the category of bug fixes.

The recommendation should be updated to beta 2 since, otherwise, we'll be in the position of still recommending a beta over the release simply because the release hasn't had 'n' hours of testing!!
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/

Lame 3.97 beta 1 released

Reply #115
well, there are a few quality changes to 3.97b2 that should be tested, and, of course there is always the possibility that something is screwed up unintentionally - so i can see why someone would ask the question...


later

Lame 3.97 beta 1 released

Reply #116
Quote
well, there are a few quality changes to 3.97b2 that should be tested, and, of course there is always the possibility that something is screwed up unintentionally
Does that mean that there were, as you said, "quality changes to 3.97b2" that weren't part of 3.97b1?  Or is john33 correct in saying that the only changes were just bug fixes that don't affect the overall quality?

It's still odd that there's no copy of Windows 3.97b1 available on the Rarewares website, though there are versions of 3.97b1 available for MacOS X, Linux x86, Solaris SPARC, and HP-UX on PA-RISC.

TS
Geopoliticus Child Watching the Birth of the New Man

Lame 3.97 beta 1 released

Reply #117
The Change Log is as quoted above as between beta 1 and beta 2:
Quote
red = features and bug fixes which affect quality
blue = features and bug fixes which affect speed
black = usability, portability, other

LAME 3.97 beta 2   November 26 2005

    * Gabriel Bouvigne:
          o Fixed an initialization error when input is not using a standard sampling frequency
          o Fixed a possible assertion failure in very low bitrate encoding
          o Slight change regarding ATH adjustment with V5
          o Reinstated bit reservoir for 320kbps CBR

          o ReplayGain analysis should now be faster when encountering silent parts
    * Takehiro Tominaga:
          o Fixed a possible link problem of assembly code
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/

Lame 3.97 beta 1 released

Reply #118
Quote
It's still odd that there's no copy of Windows 3.97b1 available on the Rarewares website, though there are versions of 3.97b1 available for MacOS X, Linux x86, Solaris SPARC, and HP-UX on PA-RISC.
[a href="index.php?act=findpost&pid=349035"][{POST_SNAPBACK}][/a]

...that's just because john33 packaged 3.97b2 quickly, while roberto hasn't repackaged for the other arches...

seriously tho, i doubt there will be much (or any) difference unless you are using -V5 or -b 320


later

 
SimplePortal 1.0.0 RC1 © 2008-2019