Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: LAME 3.93.1 vs 3.90.3 (Read 32668 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

LAME 3.93.1 vs 3.90.3

LAME 3.93.1 using --preset standard -Z: 6,563,619 bytes
LAME 3.90.3 using --alt-preset standard (-Z is default): 6,775,038 bytes

why? is there a quality difference?

 

LAME 3.93.1 vs 3.90.3

Reply #1
Because 3.90.3 is using a different rounding mode than a normal compile done by a regular c compiler.
On the other hand, original alt-preset were developped by taking this difference into consideration.

LAME 3.93.1 vs 3.90.3

Reply #2
I've just added a 3.93.1 ICL4.5 compile, using Dibrom's switches, to the MP3 page at RareWares. It is not clear from Mitiok's page whether his 3.93.1 is ICL4.5, 6 or 7.

LAME 3.93.1 vs 3.90.3

Reply #3
Quote
I've just added a 3.93.1 ICL4.5 compile, using Dibrom's switches, to the MP3 page at RareWares. It is not clear from Mitiok's page whether his 3.93.1 is ICL4.5, 6 or 7.

download~link for 3.93.1 must be fixed.

LAME 3.93.1 vs 3.90.3

Reply #4
Quote
download~link for 3.93.1 must be fixed.

Ooops!!  Sorry about that. I just fixed it.

LAME 3.93.1 vs 3.90.3

Reply #5
the rounding mode is now more technically "correct", but the --alt-presets are not tested with it properly. if they "overcompensate" the wrong rounding mode, a quality regression MAY have occurred (though nothing is proven yet).

LAME 3.93.1 vs 3.90.3

Reply #6
Quote
the rounding mode is now more technically "correct", but the --alt-presets are not tested with it properly. if they "overcompensate" the wrong rounding mode, a quality regression MAY have occurred (though nothing is proven yet).

Hm... the presets are optimized for 3.90.2 and because of different routines 3.93.1 uses they'll probably result in bad quality. So there's no need for a 3.93.1 compile with the --alt-presets. Unless it's results are better with the presets, but I don't think so... Ô_o

LAME 3.93.1 vs 3.90.3

Reply #7
LAME 3.93.1 ICL4.5 using --preset standard -Z: 6,777,728 bytes

LAME 3.93.1 vs 3.90.3

Reply #8
Quote
Hm... the presets are optimized for 3.90.2 and because of different routines 3.93.1 uses they'll probably result in bad quality.

hmm. probability is just a guess, too.

formerly gabriel stated that the alt-presets shouldn't be affected by the changes (by design).

I don't see, why we shouldn't believe in that, until the contrary is proven.



EDIT: Sorry for quoting gabriel in here. as it turned out later in this thread, I was confusing him with another lame dev, namely Alexander Leidinger.

LAME 3.93.1 vs 3.90.3

Reply #9
Quote
Quote
Hm... the presets are optimized for 3.90.2 and because of different routines 3.93.1 uses they'll probably result in bad quality.

hmm. probability is just a guess, too.

formerly gabriel stated that the alt-presets shouldn't be affected by the changes (by design).

I don't see, why we shouldn't believe in that, until the contrary is proven.

The alt-presets can seen to be affected by the simple fact that the resulting bitrate differs between the two rounding modes.  This will affect quality on some level.  The question is whether it is detectable or not, and how often.

I don't know where Gabriel made this statement, or why (or even if -- I don't remember seeing this at least), but it's incorrect and misleading.

Also, as I've stated in the past, I have heard a difference between using an ICL compile (with the rounding mode I tuned for) vs. an MSVC compile (with a rounding mode I didn't tune for) in at least one case.  The chance for there to be more differences certainly is very real.

LAME 3.93.1 vs 3.90.3

Reply #10
I do not remember this statement neither (but I might be wrong)

LAME 3.93.1 vs 3.90.3

Reply #11
hmm. maybe I am completely wrong, this discussion was long long ago. and if you look at my other post above, I stated by myself, that a regression in quality MIGHT have occured.

LAME 3.93.1 vs 3.90.3

Reply #12
hmm. poor amano was searching through 1 million posts, trying to find the one, he was thinking to refer to. and, of course, it wasn't Gabriel to state it and it wasn't stated as clearly as I remembered. so a big sorry to dibrom and gabriel.
the post I was referring to was from lame dev. ALeidinger, somewhen in early october ( http://www.hydrogenaudio.org/forums/index....5&t=3836&st=25& ).
I concluded from that that the developers were aware of the possibility to break the presets, but made all important changes optional to not break them. considering this post  a regression in quality appeared to me (of course) possible (dramatically proven by 3.93.0) but NOT probable. sorry, if I got some things wrong.

Quote
...
The changes between 3.92 and the actual code are bug fixes, portability fixes, speed improvements for "non-mainstreem OS's" (as you like them to call) and also new code (substep noiseshaping and some VBR changes). The portability fixes and speed improvements for other OS's are done in a way to not affect the quality. The substep noiseshaping has to be explicitely activated. So these changes can't change the quality per definition. Can we agree on this?
Now for the bugfixes and for the VBR changes:
The VBR changes are from Robert, and Takehiro had some problems with them. Robert and Takehiro talked about the changes and fixed the problems. Reading the public parts of their discussion and reading the commit log of the changes I had the impression they also did listening tests and made sure the quality at least stayed the same. Takehiro can tell you more about this.

For the bugfixes: bugfixes are per definition improvements, even if they affect the quality in a negative way. If they affect quality in a negative way, the problem is the algorithm, not the bugfix. So if a bug results in better quality, this isn't a deterministic behavior, it may affect other input data in a negative way (this now depends on the definition of "bug", but at least the bugfixes after 3.92 are real bugs you want to have fixed). If I remember correctly, there are also fixes which result in a better portability of the generated MP3s (and these may affect the bitrate and may therefore result in a worser sounding MP3s, but even if the quality degrades, the resulting MP3 is an improvement because the bitstream is more correct). And I think this may be the reason for the higher bitrate for the fast preset.

I followed the lame-cvs list (every commit results in a mail to this list and the mail contains the files which got changed and the commit message for these files). For some of the commits I talked with the commiter about the change (mostly with Takehiro). The only problems I see at the moment is the preset fast issue.
...