flac dev - Sep 2004 - Re: nice idea

--- 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 (signal processing engineer) but it seems to me that if a
> simple shift like that can improve the compression ratio, then
> shortening the default block size will have the same effect.
seems like it would, unless the dictionary overhead was
significantly less than the FLAC frame overhead.

as an experiment it is interesting but is probably not
practical wrt. FLAC.  it doesn't sound like it would be
an improvement since you are multiplying the input size
by 10 in exchange for making it more predictable.  even
if it does work, oversampling in the encoder and the
inverse in the decoder are expensive.

Josh


__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com

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. 

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 predictable
> > 
> > OK, IANASPE (signal processing engineer) but it seems to me that if a
> > simple shift like that can improve the compression ratio, then
> > shortening the default block size will have the same effect.
> 
> seems like it would, unless the dictionary overhead was
> significantly less than the FLAC frame overhead.
> 
> as an experiment it is interesting but is probably not
> practical wrt. FLAC.  it doesn't sound like it would be
> an improvement since you are multiplying the input size
> by 10 in exchange for making it more predictable.  even
> if it does work, oversampling in the encoder and the
> inverse in the decoder are expensive.
> 
> Josh
> 
> 
> __________________________________________________
> Do you Yahoo!?
> New DSL Internet Access from SBC & Yahoo!
> http://sbc.yahoo.com
> 
> 
> -------------------------------------------------------
> 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

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