[Flac-dev] Re: nice idea

[Hod McWuff]

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.

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.
> 
> -- 
> 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/20021005/3911c816/attachment.pgp