Flac - Jun 2012 - flac -- exhaustive model search vs. -A <*>?

"Linda A. Walsh" <flac at tlinx.org> wrote:
> what does the exhaustive model search do?
I am not an expert on the guts of FLAC, but
there is some information about this at:
http://flac.sourceforge.net/documentation_format_overview.html

and scroll down to "MODELING".
> Does it try all of the functions listed under "-A" to find the
'best',
> i.e. bartlett, bartlett_hann, blackman, blackman_har-
>      ris_4term_92db, connes, flattop, gauss(STDDEV),  hamming,  hann,
>      kaiser_bessel, nuttall, rectangle, triangle, tukey(P), welch.
>
> Or is that something else?
That is something else.
> I've been using the -e option for a while in my flac encoding,
> but for something that sounds like it should be slow I wonder
> if it is testing all the models or if it might not be
> working correctly?
At:
http://flac.sourceforge.net/documentation_tools_flac.html#flac_options_exhaustive_model_search

it states, "If the max LPC order is high this
can significantly increase the encode time."
This suggest that if the max LPC order is low
then using -e will not be slow.

The max LPC order is set explicitly using the
-l option or, more usually, by setting a
compression level.  Compression levels are
described at:
http://flac.sourceforge.net/documentation_tools_flac.html#flac_options_level_0

Note that compression levels 7 and 8 also set
the -e option.

I have not attempted to explain what the LPC
order actually is because I do not understand
it well enough

Regards,
Martin.
-- 
Martin J Leese
E-mail: martin.leese  stanfordalumni.org
Web: http://members.tripod.com/martin_leese/

LPC (Linear Predictive Coding) is a filtering technique whereby the value
of a sample is computed ("predicted") as a weighted sum of the
previous
samples. The weights assigned to each previous sample are the coefficients
of the filter, and the number of previous samples considered the order of
the filter.

x2 = x1 - x0 is an example of such a filter, of order 2, and where the
coefficients are 1 and -1.

If you have the values of x0 and x1, you are able to predict the value of
x2, knowing only the order of the filter, and the coefficients, then that
of x3 from x2 and x1, and so on...
The higher the order of the filter, the more complexity you are able to
match at the signal level.

For more, there are plenty of reference on the internet (you can start
there :  http://en.wikipedia.org/wiki/Linear_prediction)

Best regards,
Pyt.

On Thu, Jun 14, 2012 at 11:28 PM, Martin Leese <
martin.leese at stanfordalumni.org> wrote:
> [...]
> I have not attempted to explain what the LPC
> order actually is because I do not understand
> it well enough
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/flac/attachments/20120615/4d7c0d9e/attachment.htm

Martin Leese wrote:
>
> At:
>
http://flac.sourceforge.net/documentation_tools_flac.html#flac_options_exhaustive_model_search
>
> it states, "If the max LPC order is high this
> can significantly increase the encode time."
> This suggest that if the max LPC order is low
> then using -e will not be slow.
>   
----
    That brings up another question then... What is 'hi' (v. low?)...

The doc on -l makes it look like 12 is the max for "subset streams":

          -l #, --max-lpc-order=#
              Specifies the maximum LPC order. This number must be <= 
32.  For
              Subset  streams,  it must be <=12 if the sample rate is 
<=48kHz.
              If 0, the encoder will not attempt  generic  linear  
prediction,
              and  use only fixed predictors. Using fixed predictors is 
faster
              but usually results in files being 5-10% larger.
---
What's a subset stream?  Under "--lax", it says:
    --lax  Allow  encoder to generate non-Subset files.  The resulting FLAC
              file may not be streamable or might have trouble being 
played in
              all  players  (especially  hardware devices), so you 
should only
              use this option in  combination  with  custom  encoding  
options
              meant for archival.
==There -- it sounds like  "subset" refers to the subset of "flac
encodings"
that is "streamable" and/or work on all(or most) players...  Sorta
like
320Kbps being the max rate for "MP3's that conform to the
standard"...

If that's the case then the highest -l value one can 'portably' use
would
be 12?  FWIW, I've tried 16 & 12 and noticed no difference in
exhaustive's
execution time.

Another "nit" I noticed, from 
http://flac.sourceforge.net/documentation_format_overview.html
in the inter-channel-decorrelation section -- it mentions -m vs.
-M, where -m always uses mid+side channel whether it is bigger or not,
while -M adaptively uses mid+side or stereo depending on which is better.

Why would flac levels 7 and 8 use -m (always when -M allows adaptive 
encoding
based on which is better?






-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/flac/attachments/20120617/899b39bb/attachment.htm

Linda Walsh wrote:
>
>
> If that's the case then the highest -l value one can 'portably'
use would
> be 12?  FWIW, I've tried 16 & 12 and noticed no difference in 
> exhaustive's
> execution time.
===Something that just occurred to me -- it "may" be the case that the
-l
value
can, at most, use 1 parameter per/bit of the data block size.
Since 44.1KHz, songs use a 4096 blocksize, it just so happens that's 
2^12, so more bits in -l at best would do no good, and at worst, might 
take more space for unused bits. (i.e. 16 might cost .5 bytes/4096 block)...




-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/flac/attachments/20120617/25dd1bbb/attachment.htm