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
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 > Flac-dev@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flac-dev-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20021007/2b74aba2/attachment.pgp
On Sun, Oct 06, 2002 at 04:41:02PM -0400, Hod McWuff wrote:> > 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.Hmm, looks interesting for me. But i would rather use usual lpc with order like 8 or so (your example -- i think residual will show up just by 64th sample in most cases), and watch residual size for extrapolated samples. What about something like this: * compute lpc for small block (as you say, 64 samples for example) * watch residual size for extrapolated samples by the block, in sample where starts significant changes, mark begin of a new block, estimate framesize of completed block * start by the mark again, process this way few thousands of samples ahead * join small blocks according to frame header overhead * encode marked blocks -- Miroslav Lichvar