similar to: Why Rice order in "--best" switch is limited to 6?

No, FFMPEG uses its own FLAC encoder/decoder, based on Flake source code, that based on FLAC reference encoder/decoder source code. Yes, I agree that "optimal"? values for reference encoder/decoder may differ "optimal"? values for FFMPEG's encoder/decoder. But we're talking about the "highest reasonable" values, not "optimal". >>>>>

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

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

MSVS profiler shows that the following code in stream_encoder.c takes several percent of CPU time: for(rice_parameter = 0, k = partition_samples; k < mean; rice_parameter++, k <<= 1) ; this code is equivalent to: rice_parameter = 0; k = partition_samples; while(k < mean) { rice_parameter++; k <<= 1; } The idea was to accelerate it:

Op 01-10-15 om 18:14 schreef lvqcl: > Currently libFLAC stores residual signal as 32-bit signed int. And there > are the following comments in stream_encoder.c: The residual is stored as a Golomb/Rice code. As far as I know, that is not limited to 32-bit in the format itself, only in the implementation. However, there are two residual coding methods now: rice and rice2. rice2 was added

Hi all, Someone over at Hydrogenaudio pointed me in the direction of this 'bug' report: http://sourceforge.net/p/flac/bugs/352/ I don't know what Josh was thinking (look at the comments section) but AFAIK it's just a documentation thing, maybe he confused partition order and rice parameter? Anyway, here are two patches that should 'fix' this. -------------- next part

Please help me understand what values of FFMPEG's "compression_level" preset generate subset FLAC stream and what not-subset? Default value of compression_level for FFMPEG's FLAC encoder is 5. FLAC specific encoder parameters: Encoder flac [FLAC (Free Lossless Audio Codec)]: Threading capabilities: no Supported sample formats: s16 s32 FLAC encoder AVOptions:

--- Paul Harrison <pfh@mail.csse.monash.edu.au> wrote: > Hello, > > I am the author of the Bonk audio compression program... i've just > been > looking at your comparrison table, and i noticed bonk gets marginally > better compression than Flac on some files (actually i was > rather surprised to see bonk on the list at all, it's not exactly > high >

On Sun, Apr 27, 2003 at 07:28:48PM +1000, Paul Harrison wrote: > On Sun, 27 Apr 2003, Miroslav Lichvar wrote: > > > However, decoding will not be very fast. I think it is possible to > > speed up bonk implementation (with some additional tables), but > > probably it will never be as fast as decoding of rice codes. > > Agreed, there's too much juggling going on

On Sun, 27 Apr 2003, Josh Coalson wrote: > > Paul, cool to see you here... I thought bonk was in limbo > since I couldn't even see the homepage for a while. > There's a reason that web server is called yoyo... Bonk was a neat idea that turned out to be not too practical, so i haven't been working on it much. > > I actually did study bonk a little when I discovered

Hello, I am the author of the Bonk audio compression program... i've just been looking at your comparrison table, and i noticed bonk gets marginally better compression than Flac on some files (actually i was rather surprised to see bonk on the list at all, it's not exactly high profile :-) ). Bonk in lossless mode is a pretty naive implementation of a predictive coder, so the main

yeah the chnage is not entered in the change log.. it helps in achieving better compression for 24 bit files.. an i think it came in as a mistake cvs merge in 1.2.1 encoder .. neways i think Josh's( jcoalson ) reply on this thread is helpfull http://www.hydrogenaudio.org/forums/lofiversion/index.php/t57624.html my guess is u r not using 24 bit files thts why older decoder is able to decode

Martijn van Beurden wrote: >> And I also suggested to consider a different setting for -7 preset: >> -7 == -l 12 -b 4096 -m -r 6 -A tukey(0.5);partial_tukey(2) >> see <http://www.hydrogenaud.io/forums/index.php?s=&showtopic=106545&view=findpost&p=871797> >> >> But it will decrease decoding speed for this preset. > > Yes, that is another thing

Going in details through the FLAC format specification, I realize that there are 2 rice coding methods now supported for residual encoding. I thought I remembered in the 1.1.3 times that there was only 1 method (with 4-bit Rice parameter) [or was I drunk ? ;-)]. Going through the change log, I didn't find any reference to such an addition to the format. Now, the decoder implementation I'm

Hjalmar, I recall that many hardware decoders have a limit on the level that they can handle. At the very least, hardware encoders may only support a subset of the compression levels. As for the decoders, I cannot remember specifically whether they are all capable of decoding all compression levels (it certainly would be more convenient). My memory from discussions on this mailing list

hmm, let me ask this question, another way... which setting offer the least compression ?. Richard On Thursday 12 July 2007 3:49:07 am Brian Willoughby wrote: > Hi Rick, > > Alex already told you: All settings for FLAC give perfect quality. > No setting has any more quality than the other, because they are all > identical to the original CD. > > Brian Willoughby > Sound

I thought this had been answered before, but cannot find confirmation: if I recall correctly there's hardly any advantage (if any) to re-encoding from 1.2.1b to 1.3.0 at the highest compression level (8/best), right? --Martin

I thought this had been answered before, but cannot find confirmation: if I recall correctly there's hardly any advantage (if any) to re-encoding from 1.2.1b to 1.3.0 at the highest compression level (8/best), right? --Martin

I would also add that the "level" is only relevant to the reference encoder, as it is an alias to quickly set a number of parameters. Other encoders might make different choices. Also, I haven't looked in details at how the encoder works, but I think it is based on heuristics to decide which is the best compression method for a set of samples, and I'm not sure that it would give

what would be the best string setting for ripping in flac? only looking for highest audiophile quality possible. Thanks - Richard