On 12 Nov, M. Alexander Broadhead wrote:
> 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
I don't know exactly what you mean with "intensity threshold". The point
where you use IS instead of MS?
> 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 you talk about the IS<->MS criterium, can't you use a heuristic? E.g.
everything below XXX kbps uses IS instead of MS, everything above XXX
kbps uses MS and everything between needs to be computet?
> 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.)
LAME has users which didn't mind to wait a little bit longer if they get
a file which sounds better.
Just an idea, don't know if this is possible or accepted by involved
parties:
What about putting the IS code under some kind of Mozilla lizence, is
this possible (mixing both lizences in one file, restricting it to a
specific part of it (e.g. the IS part))?
This way the source for IS would be usable for other people withhin the
LGPL, and ClearBand would be able to legally adopt improvements in the
IS code.
As already said, just an idea... (with interesting possibilities).
Bye,
Alexander.
--
0 and 1. Now what could be so hard about that?
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7
_______________________________________________
mp3encoder mailing list
[EMAIL PROTECTED]
http://minnie.tuhs.org/mailman/listinfo/mp3encoder
