[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mp3encoder
Subject:    RE: [MP3 ENCODER] low bitrate files and lame
From:       "M. Alexander Broadhead" <alex.broadhead () clearband ! com>
Date:       2001-11-12 20:22:07
Message-ID: 000701c16bb7$b3e6a930$1a09010a () clearband ! net
[Download RAW message or body]

Howdy Alexander,

> >> lame -h -b32 in.wav out.mp3
> >
> > Tryenabling the -k switch (keep all frequencies), though
> this may make things
> > even worse at such a low bitrate.  Also, give VBR a shot
> (--vbr-new and -V n,
> > where n is from 0 (highest quality) to 9 (lowest quality).
>
> He wants to stream files, so VBR is not an option. Maybe ABR, but lame
> isn't very good at low bitrates (does someone out there wants to
> implement intensity stereo and send a patch?).

Intensity isn't that hard to code up - I've put it into ClearBand's codec.

Making intensity worthwhile, on the other hand, is something I still haven't
figured out.  It's the usual problem, making a tradeoff of bits saved
(objective) for quality lost (subjective).  You have to decide where to put
the intensity threshold, a process for which I could find no algorithms
other than the obvious brute force one of iterating, which is ridiculously
computationally expensive.  (You're stuck basically reencoding each frame up
to 31 times and then picking the best.  Hmmm...  Maybe there's some sort of
divide and conquer that could make this logarithmic?  I may play with this
again.)  My code just has a #define for the intensity threshold right now...

If anyone knows of a better algorithm, I'd love to hear it, and might
consider taking the time to patch LAME to use it too as a sort of trade.  As
it is now, though, it's just not worth the effort.  (Keeping in mind that
speed _is_ a concern for me.  I guess if all you want is a file, and
real-time is of no consequence, then brute-force intensity might be worth
it.)

Hope that helps,
Alex



[prev in list] [next in list] [prev in thread] [next in thread]