similar to: [PATCH] Fix documentation rice partition order

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

--- doc/html/documentation_tools_flac.html | 8 +++++--- doc/html/ru/documentation.html | 2 +- man/flac.1 | 6 ++++-- man/flac.sgml | 5 +++-- src/flac/main.c | 4 +++- 5 files changed, 16 insertions(+), 9 deletions(-) diff --git a/doc/html/documentation_tools_flac.html b/doc/html/documentation_tools_flac.html

On Fri, Apr 03, 2020 at 03:26:42PM -0700, Alexey A Nikitin via samba wrote: > On Friday, 3 April 2020 10:46:54 PDT Ralph Boehme wrote: > > Am 4/1/20 um 11:09 PM schrieb Alexey A Nikitin via samba: > > > Is there a way, preferrably without ugly hacks, to prevent this from happening on accident, by mistake? By this I mean ideally so that Winbind remains responsive even if someone

On Fri, Apr 10, 2020 at 02:41:39PM -0700, Jeremy Allison wrote: > On Fri, Apr 10, 2020 at 02:37:45PM -0700, Jeremy Allison via samba wrote: > > On Fri, Apr 03, 2020 at 03:26:42PM -0700, Alexey A Nikitin via samba wrote: > > > no longer a threat, but it is pretty much ignored if 'winbind offline logon' is enabled... > > > Can anyone explain why? Because when auth

On Fri, Apr 10, 2020 at 02:37:45PM -0700, Jeremy Allison via samba wrote: > On Fri, Apr 03, 2020 at 03:26:42PM -0700, Alexey A Nikitin via samba wrote: > > On Friday, 3 April 2020 10:46:54 PDT Ralph Boehme wrote: > > > Am 4/1/20 um 11:09 PM schrieb Alexey A Nikitin via samba: > > > > Is there a way, preferrably without ugly hacks, to prevent this from happening on

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

Hey there, sorry to bug you, I've ran into a little problem conscerning a logcheck-rule I just wrote. I use logcheck and logcheck-database on Debian Etch. When logcheck reports me something I don't want it to, I normally write a rule to match that logentry and put it in a file called my_rules in /etc/logcheck/ignore.d.server/ ... that worked perfectly fine. Until that rule: Logcheck

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

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

Hmm, what if the FLAC options produce a larger file on output than input? Would -f (force) cause the whole process to fail as soon as the output exceeded the input? Brian On Apr 9, 2007, at 17:01, Josh Coalson wrote: --- Harry Sack <tranzedude@gmail.com> wrote: > is it possible to re-encode an existing FLAC file by using the FLAC > file itself as input to the encoder like

Hi to all! I have a database of audio files that I want to losslessly compress. Unfortunately I have several 8bit A-law and mu-law files in the database and I see from here http://flac.sourceforge.net/documentation_tools_flac.html that they are not supported by the reference flac encoder/decoder. Is there a reason for this? Would it be possible to add support for these files in the reference

1) changelog.html "Add ability to handle utf8 filenames on Windows (large set of patches from Janne Hyv?rinen)" AFAIK Windows internally uses UTF-16LE, not UTF-8. IMHO it's better to use a general word 'Unicode' instead of 'utf8'. 2) documentation_bugs.html "The following are major known bugs in the current (1.2.1) release:" 1.2.1 is not the current

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

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

Hi, I meant that it seems problematic to write an updated file to itself, because the operation could erase the data before it is read. Unless you read the entire file first, or write to a temporary file which is then renamed. I deal with FLAC files that are over a gigabyte, meaning that this could easily exceed normal buffers. Just curious. I guess I could go test it myself... or

You should read the manual for the FLAC command line utilities. There are many options that would probably achieve what you desire. In particular, one of the links that I sent below clearly leads you to a page describing how cuesheets are related to the SEEKTABLE, and you can create a --seekpoint= marker for each track. Sometimes you really need to take the time to read everything

Because u-law and a-law are non-linear algorithms and the mathematics of FLAC (and AFAIK all lossless encoders) are build for linear PCM. Adding these formats would change the FLAC format altogether, decoders are not made to work with it (they can only output plain PCM) Best option would be converting these files to 16-bit plain WAV and compressing, but I guess files won't be much smaller