[Flac-dev] Re: nice idea
hod at wuff.dhs.org
Fri Oct 4 10:59:02 PDT 2002
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 at 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.
> Do you Yahoo!?
> New DSL Internet Access from SBC & Yahoo!
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> Flac-dev mailing list
> Flac-dev at lists.sourceforge.net
More information about the Flac-dev