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