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: How Close Are We To 3.98 Final ? (Read 25646 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

How Close Are We To 3.98 Final ?

Reply #25 –
I'm referring from people saying earlier in this thread that 3.98 b6 is a step back from b5, which seemed to be a consesus of sorts.

I'm not suggesting I have or can ABX differences, hence me asking

But I figured since people have said 3.98 b6 is not an improvement, we're hardly likely moving in the right direction.

- Spike

How Close Are We To 3.98 Final ?

Reply #26 –
According to my tests it isn't a step back: we're moving forward.
What's disturbing with 3.98b6 is: we have had various different subversions published, with some of them not meant for the public.
I use the version from December 17, and I'm happy with it. I won't touch a newer published b6 until there's a strong reason for it (which however hopefully makes it into b7 then).
lame3995o -Q1.7 --lowpass 17

How Close Are We To 3.98 Final ?

Reply #27 –
You want most stable but outdated - use stable.
You want stable and new - use beta
You want very latest and don't care for stability - use alpha or cvs.


So beta and alpha users don't  / shouldn't need 'releases'.

How Close Are We To 3.98 Final ?

Reply #28 –
Quote from: shadowking on
... So beta and alpha users don't  / shouldn't need 'releases'.

Hm, I guess we have this:
The honorable Lame devs have the cvs as their common resource. The honorable exe compiling people from time to time look up the cvs and in case they find an update they compile it and provide it for us.
But not every state of the cvs is worth to be published.

From a user point of view: if a certain beta version has been found to be good why not use it? In this case it's disturbing if subversions (potentially meant for internal testing only) are published.

Maybe a way out works like this: to use a name like '3.98b6test' which is not to be compiled, and a name like '3.98b6' for versions to be published.
lame3995o -Q1.7 --lowpass 17

How Close Are We To 3.98 Final ?

Reply #29 –
Well halb27, thanks for the reply- clears a lot of things up for me.

I look forward to you testing this new 3.98b7 and seeing how it goes!

- Spike

How Close Are We To 3.98 Final ?

Reply #30 –
Quote from: halb27 on
From a user point of view: if a certain beta version has been found to be good why not use it?

The question isn't (in my mind) "Is this beta version good?" but "Is this beta version enough of an improvement over the previous, more throughly vetted version, to be worth the risk?"

I dare say most of us do not ABX every track we encode in an attempt to find the lowest possible transparent setting - we pick a "safe" preset and encode every track at it.  Along a similar vein, why would I spend my time ABXing every beta version looking for marginally lower transparent bitrates opposed to using a "safe" version?
Creature of habit.

How Close Are We To 3.98 Final ?

Reply #31 –
Quote from: Soap on
Quote from: halb27 on

From a user point of view: if a certain beta version has been found to be good why not use it?

The question isn't (in my mind) "Is this beta version good?" but "Is this beta version enough of an improvement over the previous, more throughly vetted version, to be worth the risk?"

I dare say most of us do not ABX every track we encode in an attempt to find the lowest possible transparent setting - we pick a "safe" preset and encode every track at it.  Along a similar vein, why would I spend my time ABXing every beta version looking for marginally lower transparent bitrates opposed to using a "safe" version?

Well, if we have a "safe" version and preset there wouldn't be the need for progress.
In fact generally speaking there isn't always the need for further development. Look at Musepack. Musepack isn't perfect of course, but it's been excellent for years, and there's not a lot of hope for a substantial further improvement. Similar is true for current Vorbis development (with the exception of low bitrate usage). Remarkable: when development slows down and comes nearly to a rest (for good reasons as there isn't a lot to improve yet) many people aren't content either. We've seen this with Musepack which was called a 'dead' codec by several members here.
With mp3 it's different. We had for instance the 'sandpaper noise' issue with 3.97 final which is very much worth to be overcome. Thanks to the Lame devs it's overcome now with 3.98 development. We have a major improvement with short block usage over 3.97final which can easily be heard with samples like eig. We still have some minor inaccuracies which can be overcome with future versions.
Of course: with any change of an encoder which brings improvement towards a problem there is a certain risk that something else may get worse. However if we don't want progress to stop we have to stick with this disadvantage. And: the more people take the challenge and test new versions the better we're off.
lame3995o -Q1.7 --lowpass 17

How Close Are We To 3.98 Final ?

Reply #32 –
And that's why for my music website I use the latest beta, and when we get to a "stable" 3.98, I'll probably reencode everything (if serious improvements are made by the time 3.98 comes around).

People have this funny notion that 3.97 is great because it's "stable" and that the 3.98 betas will be worse, or have tradeoffs, or something, and that they shouldn't be used until it too is declared "stable". I'm confused by that, when 3.98 betas are apparently an improvement over 3.97 and have noticeable benefits. Anyway, I'll continue to use 'em.

I also like the logic that a "stable" version isn't perfect, either. Exactly- that's why I like Aoyumi's Ogg encoders- they're always in beta, and continuously improving!

- Spike

How Close Are We To 3.98 Final ?

Reply #33 –
Oh, and it is getting some (Debian) packaging updates too.

I just committed updates that should mean that the source is more lintian clean, from the packaging standing point.

This works with Christian Marillat's  packages (such as ffmpeg), so that you can use all the goodies incorporated into lame 3.98 when producing your videos, instead of being stuck with version 3.97, if you want to (I do).

I can provide compiles that are drop-in replacements to i386, amd64 and powerpc.

Regards, Rogério Brito.

How Close Are We To 3.98 Final ?

Reply #34 –
What actually people wait from new build? Quality improvement?
There are samples that never will be transparent  at V5. No matter the version 3.90.3, 3.97 3.98 ......

For example old sample that is here already during many years. This one was tortured by developers many times
http://www.rarewares.org/test_samples/Waiting.wv

It will be never  transparent at 128 kbit/s or as good as encoded to AAC or Vorbis top encoders.

Maybe speed improvements ....

How Close Are We To 3.98 Final ?

Reply #35 –
Quote from: IgorC on
What actually people wait from new build? Quality improvement? ... Maybe speed improvements ...
Good question, and actually the essence of why I started the thread in the first place.

Regards,
Madrigal

How Close Are We To 3.98 Final ?

Reply #36 –
Obviously its quality. C'mon.. Otherwise use another faster mp3 encoder..VBR new is the default and the devs want a robust model and I like it. Fractional vbr quality - I like it. More bug fixes the better. Just because some samples will not be 100 % doesn't mean they cannot be improved.

How Close Are We To 3.98 Final ?

Reply #37 –
Quote from: shadowking on
Obviously its quality. C'mon.. Otherwise use another faster mp3 encoder.

Actually speed could be improved on 64-bit builds, which don't benefit from ASM optimizations like 32-bit builds do, even though the former are already faster than the latter. I'm also wondering why LAME runs so much slower on AMD CPUs than on Intel CPUs, when other codecs run at least as fast.

How Close Are We To 3.98 Final ?

Reply #38 –
Unfortunately, the only possible answer right now is: "when it will be ready".

Practically, LAME is heavily suffering from resource starvation. Last year, core resources were down to 1 single person (Robert). With such a starvation of developer time, it is basically impossible to draw a realistic roadmap and to put time dates on a planning. Moreover, you have to keep in mind that every one working on LAME does it on his/her spare time, which imply that allocated time can easily go down to 0 hours per week. (unlike some other open source projects, like x264, for which some people are getting payed).

You might also notice that people still working on the internals of LAME now (2008), are people that are doing it basically since the release of LAME 3.0, about 9 years ago. After some time, while still pleasing and interesting, you might to stop down on this side. (fortunately we had a bit of fresh blood to carry "peripheral" tasks like website and dpkg)

The positive side is that you can help to improve things, and that would be of great help:

*listening tests
*non-regression tests
*providing a concise, centralized, overview of individual test results
*do some triage over reported bugs @sourceforge
*do some triage over reported patches @sourceforge

Any small help would indeed help to release next version faster.


Quote from: skamp on
I'm also wondering why LAME runs so much slower on AMD CPUs than on Intel CPUs, when other codecs run at least as fast.

Are there many codecs wich run faster on current AMD CPUs (K8/K10) than on current Intel CPUs (Core2)? I'm a bit surprised there.

How Close Are We To 3.98 Final ?

Reply #39 –
Quote from: skamp on
I'm also wondering why LAME runs so much slower on AMD CPUs than on Intel CPUs, when other codecs run at least as fast.
I don't know how much Lame relies on that but AMD has sh*t (like ten times slower than Intel?) implementation of integer multimedia xtensions (MMX, integer SSE/SSE2).
Quote from: skamp on
Actually speed could be improved on 64-bit builds, which don't benefit from ASM optimizations like 32-bit builds do, even though the former are already faster than the latter.
You don't need assembly to use SIMD. C++ intrinsics is enough for that (xmmintrin.h/emmintrin.h), this should be 32/64-bit indifferent.

How Close Are We To 3.98 Final ?

Reply #40 –
Quote from: Martel on
I don't know how much Lame relies on that but AMD has sh*t (like ten times slower than Intel?) implementation of integer multimedia xtensions (MMX, integer SSE/SSE2).

Then why is Monkey's Audio (with 64-bit MMX ASM) faster on my Phenom 9600 (2.3GHz) than on a C2D E6600 (2.4GHz)? Isn't it using integer arithmetics? 106.6x vs. 100.1x, 78.5x vs. 76.5x, 68.6x vs. 65,0x, and 30.8x vs. 29.8x (fast, normal, high and extra high encoding levels). Same for WavPack: 186.1x vs. 123.8x, 144.6x vs. 109.4x and 84.5x vs. 73.4x (fast, normal and high).
FLAC is consistently faster as well (check out the numerous benchmarks). In my tests, LAME and Ogg Vorbis were substantially slower (is it just a coincidence that both are lossy codecs?). I know it's not a question of bottlenecks, since that web page lists encoding speeds up to 169.3x.

An editor of fudzilla.com wrote something about a second SSE unit in the Phenom not being used by most software, I'm not sure what to make of it:
Quote
AMD is still not a champ in the multi-media department. Intel decided to boost their SSE unit by doubling the frequency - which they did back with Pentium 4. AMD decided to use two separated units per core. The only problem is, there is little software supporting AMD's architecture, so most of the time the second SSE unit is idling which gives AMD quite bad scores.

There are also other types of calculations where the Phenom is much faster than Intel CPUs, like RSA with OpenSSL: the 3.2GHz Q9450 quad core Intel CPU scores 158 signatures per second, while my 2.3GHz Phenom CPU scores 162 with the same number of cores but a 900MHz handicap per core. The Phenom's performance isn't exactly what the press has made it out to be. Whether Intel products are globally faster isn't really what interests me, rather that some applications might run substancially faster on AMD CPUs than they currently do. I know the codecs in question are Free Software and their developers have limited time and resources, I'm just wondering why there are such discrepancies.

How Close Are We To 3.98 Final ?

Reply #41 –
Quote from: skamp on
Then why is Monkey's Audio (with 64-bit MMX ASM) faster on my Phenom 9600 (2.3GHz) than on a C2D E6600 (2.4GHz)?

I hope you are not comparing a 32bits build against a 64bits build, with different audio tracks.

Anyhow, if some of you are interested to discuss about performance, I'd suggest creating a new dedicated topic.

How Close Are We To 3.98 Final ?

Reply #42 –
Quote from: Gabriel on
I hope you are not comparing a 32bits build against a 64bits build, with different audio tracks.

It's hard to make accurate comparisons without the same test material. I only owned one of the CDs the guy used (Queen, Greatest Hits I). My OS is linux x86_64, and I assume his OS was a 32-bit Windows. The benchmarks conducted on Phoronix are more reliable: the WAV file can be downloaded, and details such as the OS & compiler are given.

How Close Are We To 3.98 Final ?

Reply #43 –
Quote from: Gabriel on
Practically, LAME is heavily suffering from resource starvation. Last year, core resources were down to 1 single person (Robert). With such a starvation of developer time, it is basically impossible to draw a realistic roadmap and to put time dates on a planning. Moreover, you have to keep in mind that every one working on LAME does it on his/her spare time, which imply that allocated time can easily go down to 0 hours per week. (unlike some other open source projects, like x264, for which some people are getting payed).

You might also notice that people still working on the internals of LAME now (2008), are people that are doing it basically since the release of LAME 3.0, about 9 years ago. After some time, while still pleasing and interesting, you might to stop down on this side. (fortunately we had a bit of fresh blood to carry "peripheral" tasks like website and dpkg)

The positive side is that you can help to improve things, and that would be of great help:
Thank you, Gabriel. Understood and very much appreciated.

Regards,
Madrigal

How Close Are We To 3.98 Final ?

Reply #44 –
Quote from: Gabriel on
Unfortunately, the only possible answer right now is: "when it will be ready".


You'd probably get more help if you at least documented what you're working on for the new release and how people can help. I still have no idea what's coming in this new version, or the status of it, which makes knowing what to test for kind of difficult. Is this information up somewhere? I'm not seeing it.

Roadmaps don't have to have dates.

How Close Are We To 3.98 Final ?

Reply #45 –
Quote from: showdax on
Quote from: Gabriel on

Unfortunately, the only possible answer right now is: "when it will be ready".


You'd probably get more help if you at least documented what you're working on for the new release and how people can help. I still have no idea what's coming in this new version, or the status of it, which makes knowing what to test for kind of difficult. Is this information up somewhere? I'm not seeing it.

Roadmaps don't have to have dates.



People can test for ringing, drop outs, distorted sound at lower VBR presets (V6..V5..V4) . They are there on low volume music; solo intros, vocals, guitar etc..

How Close Are We To 3.98 Final ?

Reply #46 –
"Very" close

 

How Close Are We To 3.98 Final ?

Reply #47 –
July 4 is the official release date according to the LAME website: History (of LAME)