[Flac-dev] Re: nice idea

[Hod McWuff]

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 at 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