Howdy Alexander, > > 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?
Sort of. First off, the spec lets you use intensity with or without mid/side. Mid/side, when it is on, is applied to all of the bins of the signal. Intensity, though, can be applied starting at any scalefactor band in the spectrum; it is then used for all higher bands as well. The trick to optimizing intensity is picking that band, which I'm calling the 'intensity threshold' for lack of any other term. > > 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? That's a different concern. Theoretically, if you had a good algorithm for picking the 'intensity threshold' (frequency band), you could _always_ enable intensity. (And sometimes it would pick zero bands to intensify.) FhG does this; you have to explicitly disable intensity on their codec. (They also always enable mid/side, and there's no way to suppress it.) BTW, I was wrong about the number of iterations above. It would be 13 or 21 at maximum, depending on whether the frame is long or short block encoded. (I grepped back through the archive and found my own earlier questions on this subject...) > 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. A good idea, I think, but a little complicated. I'd probably just add in the code to LAME, and then add any improvements I came up with from the ClearBand path. And if someone actually came up with a better (patentable) algorithm, I'd be up a creek? I really don't know where the line is drawn on the (L)GPL. It clearly protects the source and executables, but does it protect algorithms as well? Even if the algortihms are simply plugging in standard CS methods to new problems? I don't know. > As already said, just an idea... (with interesting possibilities). I may play with this some in the near future. I'll see if I come up with anything, and if I can find the time to come up to speed with the relevant sections of LAME, which is sure to take longer than actually adding the new code. Alex _______________________________________________ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
