OK, then how about a speculative approach?
I'm going to go on these assumptions: * linear predictive coding * exhaustive search option * lpc coding is capable of producing zero residual * doing so is practical with a tiny block size Start with say, 64 samples (arbitrary), and compute a zero-residual LPC coding. Then use that coding to try and "predict" ahead into the un-encoded input stream. Compare against the actual input, and end the block where residual starts to show up. On Sun, 2002-10-06 at 14:58, Miroslav Lichvar wrote: > On Sat, Oct 05, 2002 at 12:26:12PM -0400, Hod McWuff wrote: > > On Sat, 2002-10-05 at 03:19, Miroslav Lichvar wrote: > > > On Fri, Oct 04, 2002 at 01:57:03PM -0400, Hod McWuff wrote: > > > > Agreed that the oversampling isn't useful in the long term. I'm not sure > > > > what you mean by 'dictioniary overhead'. > > > > > > > > I'd like to see an easy-to-invoke set of parameters that will spare no > > > > cpu expense and produce the tightest theoretically possible output. > > > > > > > > I'm guessing the best of Marco's idea can be achieved by adding > > > > heuristics to dynamically determine optimal frame size based on say, a > > > > maximum standard deviation of a complexity measurement. The idea is to > > > > tie the frame breaks to dramatic changes in the signal. If the guitarist > > > > plucks a string, or the vocalist starts a new syllable, that should also > > > > mark a frame boundary. > > > > > > I was playing with variable blocksize some time ago. I used something > > > like brute force search, no invention at all. I got ~1.5% improvement > > > of compression, but 10 second sample took about hour of encoding :-). > > > If there is some fast algo for that, it would be cool. > > > > Hmm... when using variable bitrate with MP3, the bitrate clearly follows > > complexity. I've no idea how that algorithm works, but maybe it can be > > adapted. When it decides to change the bitrate, that's where you want a > > frame break. > > This algorithm determines amount of bits you give to one block, > not where block has to begin or end. This isn't exactly what we need. > > Problem is not measuring complexity of whole blocks, we can use for > that flac coding itself, but problem is how to find quickly and > accurate (preferably in samples) boundaries, where the complexity or > better difference changes. > > -- > Miroslav Lichvar > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Flac-dev mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/flac-dev
signature.asc
Description: This is a digitally signed message part
