search for: mcwuff

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'. >...

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 o...

--- Hod McWuff <hod@wuff.dhs.org> wrote: > On Fri, 2002-10-04 at 10:26, Marco "elcabesa" Belli wrote: > > oversampling.. i maean digitally change the wave file rate form > 44khz to 440 > > khz > > > > it make next sample easyer predictable > > OK, IANASPE (si...

...dual 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...

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

constant prediction see this page http://flac.sourceforge.net/format.html oversampling.. i maean digitally change the wave file rate form 44khz to 440 khz it make next sample easyer predictable if i'll found my old work i'll tell you how much compression i could achieve

...mum 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. On Fri, 2002-10-04 at 13:27, Josh Coalson wrote: > --- Hod McWuff <hod@wuff.dhs.org> wrote: > > On Fri, 2002-10-04 at 10:26, Marco "elcabesa" Belli wrote: > > > oversampling.. i maean digitally change the wave file rate form > > 44khz to 440 > > > khz > > > > > > it make next sample easyer predicta...

...3, 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. 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...

...re suggesting an "estimation" pass to determine block size before doing the final encode, and I'm trying to do it on one shot. I'm probably the one going too cycle-hungry here. On Mon, 2002-10-07 at 16:03, Miroslav Lichvar wrote: > 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 i...