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: Sound problem with --alt-preset fast standard (Read 9827 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Sound problem with --alt-preset fast standard

Reply #25 –
Sadly I found another track that encodes badly with fast compared to standard. Right in the beginning of The Beatles - Lucy In The Sky With Diamonds Lennon's voice gets a little garbled with the fast setting. Neither the standard or r3mix presets have any problem.

Using LAME 3.90 stable

I posted Lucy In The Sky in three different flavors for you.

--alt-preset fast standard
--alt-preset standard
.cdda audio file

www.hashhut.com/soundtest

Thanx for letting me bug....

Sound problem with --alt-preset fast standard

Reply #26 –
Whats the difference between the fast and standard modes?

Is it just different vbr modes as in --vbr-old and --vbr-new?

If not please clarify, as I would like to know, thanks in advance.

AgentMil
-=MusePack... Living Audio Compression=-

Honda - The Power of Dreams

Sound problem with --alt-preset fast standard

Reply #27 –
I'll take a look, thanks.

Sound problem with --alt-preset fast standard

Reply #28 –
Quote
Originally posted by AgentMil
Whats the difference between the fast and standard modes?

Is it just different vbr modes as in --vbr-old and --vbr-new?

If not please clarify, as I would like to know, thanks in advance.


Ehmm.. it's a little bit complicated if you don't understand the code.  Basically though, vbr-mtrh is setup fairly differently than vbr-old, so the tweaks I make to one can not be carried over in exactly the same manner to the other.

vbr-mtrh is harder to modify to do the same things that I've been doing with vbr-old.  I've mostly been able to get things to work nearly the same in both but there are a few points where mtrh does not perform quite as well.. the problem mentioned earlier in this clip exploits that issue.  I can fix the problem.. it's not that hard, the hard part is fixing it without increasing bitrates everywhere else.

Sound problem with --alt-preset fast standard

Reply #29 –
Ah damn... :mad: I just found out that one of the changes I implemented in the last compile to fix the problem with your first sample, slightly altered the normal behavior somewhere else... causing a clip similar to distort.  It was a stupid bug, and I've fixed it now... I'm willing to bet this clip you just found is caused by the same thing.

Sound problem with --alt-preset fast standard

Reply #30 –
Alright, I listened to your clip.  Part of it is related to what I just mentioned, and part of it is that the original tunings I made were not quite sensitive enough.  I'll work on this some and see what I can do.  I may just have do some things which increase bitrate to get around this.. we'll see.

In the meantime I suggest you use --alt-preset standard (non-fast) until I get the issue resolved.

I should be able to fix this one way or another though before too long, at which point I'll release an updated compile.

Sound problem with --alt-preset fast standard

Reply #31 –
Thanx! I have started using standard for now. Some good news is I've encoded 66 albums and so far only noticed these two tracks that had problems. Pretty good rate so far.

If only LAME was optimized a little for apples G4 processors then I wouldn't be soo tempted to use the fast setting. As is I only get .6 speeds on normal and bout 1.6 on fast. Pretty sad......

Sound problem with --alt-preset fast standard

Reply #32 –
Alright, I should have completely fixed the problem now.  There wasn't much I could do to prevent a slight bitrate increase in some situations, but they should be fairly rare I think.

The code is in CVS now, and I'll probably provide an updated compile later. 

Quote
Originally posted by kye
Thanx! I have started using standard for now. Some good news is I've encoded 66 albums and so far only noticed these two tracks that had problems. Pretty good rate so far. 


Yeah, the problem should have only manifested itself in very specific situations, which were not particularly common.  This is why I missed the last little bug that I just fixed.

Quote
If only LAME was optimized a little for apples G4 processors then I wouldn't be soo tempted to use the fast setting. As is I only get .6 speeds on normal and bout 1.6 on fast. Pretty sad......


Actually I think the biggest issue may be that GCC just produces slow code really.  Someone said that codewarrior was faster for the PPC so maybe if someone can compile with that it would produce better results.

I think this:

http://www.psrv.com/altivec.html

...might be the best bet, if someone actually has access to it...

Apparently it allows for automatic Vectorization and Parallelization of C/C++ code (similar in the Vectorizing part at least to ICL for x86) for the G4.

Sound problem with --alt-preset fast standard

Reply #33 –
well, i have access to codewarrior, but i'm not a programmer.

would compiling on codewarrior for mac osx be something relatively easy or a specialist-only task?

if relatively easy, a few hints on how to start would be nice. if not, please ignore this post until a competent person wants to take a shot.

brett.