Sounds like a good start. However, think what it would mean if we could get rid of any residual. In the best case scenario, the output would be a series of function coefficients describing a wave, and a length parameter. In the case of music, you can reasonably expect an unforseeable attack and a consistent decay for each sound component. That means if you can totally describe the first wave to hit (say a guitar string) you can use those function coefficients to help determine what the combined wave will look like when, say, the bassist starts up. The key here is the ability to come up with that exact-match equation. I expect it to take some serious crunching to accomplish, but I really don't know the magnitude of the problem.
It would appear that either the full-prediction or a limited-residual target would need to be implemented in much the same way. If I'm getting you right, you'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 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
signature.asc
Description: This is a digitally signed message part
