similar to: flac -- exhaustive model search vs. -A <*>?

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

Linda Walsh <flac at tlinx.org> wrote: ... > That brings up another question then... What is 'hi' (v. low?)... Zero, or close to zero, is low. 12 is high. ... > What's a subset stream? This is explained at: http://flac.sourceforge.net/format.html in the bulleted point beginning, "FLAC specifies a subset of itself as the Subset format." ... > Another

Shayne Wissler <wissler at gmail.com> wrote: > I have a program that is given a random file and needs to determine > whether it is Vorbis or FLAC. For Vorbis, there are various places > where I can infer that I have a bad stream. But for FLAC, when I call > either FLAC__stream_decoder_process_until_end_of_metadata or > FLAC__stream_decoder_process_single, it searches the

I mean that the first statement [Subset streams must use one of 192/576/1152/2304/4608/256/512/1024/2048/4096 (and 8192/16384 if the sample rate is >48kHz).] published on https://www.xiph.org/flac/documentation_tools_flac.html#flac_options_blocksize page IS NOT EQUAL to second statement [The blocksize bits in the frame header must be 0001-1110. The blocksize must be <=16384; if the sample

I mean that the first statement [Subset streams must use one of 192/576/1152/2304/4608/256/512/1024/2048/4096 (and 8192/16384 if the sample rate is >48kHz).] published on https://www.xiph.org/flac/documentation_tools_flac.html#flac_options_blocksize page IS NOT EQUAL to second statement [The blocksize bits in the frame header must be 0001-1110. The blocksize must be <=16384; if the sample

I think you've found a bug, Bart. flac 1.2.1 did not have any FLAC__format_blocksize_is_subset() function, so the source you're seeing in format.c must be new. If the format documentation you linked to is correct, then either the specifications are self-contradictory, or the code is not implementing the subset checks as described. My interpretation is that blocksize bits of 0110

For some reason all documentation lists the max rice partition order to be 16, while the maximum is 15. This fixes flac -H, the man page and the HTML source code documentation --- doc/html/documentation_tools_flac.html | 2 +- man/flac.1 | 8 ++++---- man/flac.sgml | 8 ++++---- 3 files changed, 9 insertions(+), 9 deletions(-) diff --git

Any progress? > I agree. Please keep up informed. >> FLAC__format_blocksize_is_subset() was introduced by commit #8ab0138 >> (https://gitorious.org/flac/flac/commit/8ab013837d379d3d1fa84eac5420faec41852fd7) >> over 5 years ago and available in the latest stable release 1.3.0. >> >> It would be nice if the official FLAC documentation used common >> adopted

>>>>>>>>> I'm misleading about FLAC subset constraints... Please help me >>>>>>>>> understand exact FLAC subset limitation. >>>>>>>>> >>>>>>>>> From https://www.xiph.org/flac/documentation_tools_flac.html#flac_options_blocksize: >>>>>>>>>

--- doc/html/documentation_tools_flac.html | 6 ++--- include/FLAC/stream_encoder.h | 42 +++++++++++++++++----------------- src/flac/main.c | 20 ++++++++-------- 3 files changed, 34 insertions(+), 34 deletions(-) diff --git a/doc/html/documentation_tools_flac.html b/doc/html/documentation_tools_flac.html index 9f85a25..0964cd2 100644 ---

For some reason all documentation lists the max rice partition order to be 16, while the maximum is 15. This fixes thee HTML online documentation --- documentation_tools_flac.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentation_tools_flac.html b/documentation_tools_flac.html index bc1f2b8..5100cb4 100644 --- a/documentation_tools_flac.html +++

what does the exhaustive model search do? 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? I've been using the -e option for a while in

On 16/07/13 8:10 PM, Erik de Castro Lopo wrote: > Leigh Dyer wrote: > >> Certainly -- I've uploaded the analysis files for both the -6 and -7 >> encodes, in case you wanted to compare: >> >> http://wootangent.net/~lsd/blah/6.ana >> http://wootangent.net/~lsd/blah/7.ana >> >> The encode seems to proceed normally until 59% of the way through the

Martijn van Beurden wrote: > You've exposed at least two very serious FLAC bugs, > namely a malfunctioning RICE2-partition encoder and a bug concerning > choosing verbatim frames over fixed/lpc frames. The second, not choosing verbatim frames over fixed/lpc frames is almost certainly a direct result of the first problem. The fix was changing one local variable from FLAC_uint32 to

Erik de Castro Lopo <mle+xiph@mega-nerd.com> wrote: > Martin Leese wrote: > > So what is "OggPCM"? I started this thread > > because I was puzzled why someone was > > changing a draft instead of the document > > itself. > > The original OggPCM was started by a person who really didn't > lnow what they were doing and wouldn't listen to

I have been tidying up the VorbisComment page in the XiphWiki. The problem with it was that it was a mixture of proposals and discussion of those proposals. This made it difficult for implementers to see what to implement. The problem section is: http://wiki.xiph.org/index.php/VorbisComment#New_ENCODER_field_name_proposal This is a mess, and all I could do was add attributions to the

On 7/23/13, Silvia Pfeiffer <silviapfeiffer1 at gmail.com> wrote: > On 23 Jul 2013 15:17, "Martin Leese" <martin.leese at stanfordalumni.org> > wrote: ... >> Information about Metadata >> has been collected together in the Xiph Wiki >> at: >> https://wiki.xiph.org/Metadata > > That page is a bit outdated. It has CMML in it which we

"Kurosawa, Taku" wrote: > Hi Martijn, > > Sorry for the late reply again, > The application we are preparing this time is not exactly similar to > Replaygain. > > Replaygain as we understand is something which normalize the loudness at > content provider side, but our application takes different approach. It is > designed to normalize the loudness at player

Brendan Bolles wrote: > Hey everyone, according to Wikipedia's 4-year-old information, there is no > standard for putting metadata into an Ogg file. True. > That metadata must be > included in the codec. More generally, in a stream in the Ogg file. Codecs are streams, but so are things like Ogg Skeleton. Information about Metadata has been collected together in the Xiph Wiki

I have been tidying up bits of the Wiki. This one is not clear cut, so I decided to seek advice. Also, I wasn't sure where to post this question, so defaulted to ogg-dev. Should Speex and CMML be removed from the Wiki Sidebar at: https://wiki.xiph.org/MediaWiki:Sidebar ? Many thanks, Martin -- Martin J Leese E-mail: martin.leese stanfordalumni.org Web: