[Flac-dev] Re: nice idea
lichvarm at phoenix.inf.upol.cz
Sun Oct 6 11:58:02 PDT 2002
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.
More information about the Flac-dev