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

I don't think you guys should worry too much about messing up old decoders, but no matter what you choose to do FLAC MUST REMAIN LOSSLESS. On Thu, Mar 14, 2013 at 5:06 PM, <flac-dev-request at xiph.org> wrote: > Send flac-dev mailing list submissions to > flac-dev at xiph.org > > To subscribe or unsubscribe via the World Wide Web, visit >

?hel kenal p?eval (neljap?ev, 14. m?rts 2013 19:02:35) kirjutas Declan Kelly: > On Wed, Mar 13, 2013 at 10:06:51PM -0400, benski at winamp.com wrote: > > Flake is a completely independent codebase. When I used it years ago, I > > remember it being not only better compression but significantly faster as > > well. I believe some of the techniques used in libflake were added to

Op 07-02-12 19:50, Ralph Giles schreef: > Basically the audio is chopped into a blocks and each block is coded > either uncompressed, as a constant value (good for silence), or with > linear predictive coding plus a rice-coded residual. I don't know how > the encoder decides where to put the block boundaries. AFAIK, FLAC uses a fixed block length so block boundaries are just put

On Wed, Mar 13, 2013 at 10:06:51PM -0400, benski at winamp.com wrote: > > Flake is a completely independent codebase. When I used it years ago, I > remember it being not only better compression but significantly faster as > well. I believe some of the techniques used in libflake were added to > libFLAC in 1.1.4. However, some of the improved compression in flake was > due to

Flake is a completely independent codebase. When I used it years ago, I remember it being not only better compression but significantly faster as well. I believe some of the techniques used in libflake were added to libFLAC in 1.1.4. However, some of the improved compression in flake was due to options that are outside the FLAC 'subset', such as larger blocksize, greater number of

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

???? ?????? wrote: > "--best" preset is designed for highest compression, not for faster > compression, isn't it? > IMHO it just means "highest reasonable", not "highest theoretically possible". And please answer to the mailing list, not to me ditectly.

Date: Sun, 19 Oct 2003 00:59:22 +0200 > On Sat, Oct 18, 2003 at 07:21:08PM +0000, Dan Stowell wrote: > > I asked a few questions about the flac format a couple of weeks ago. > > One more (if you don't mind) about the Rice coding. The Rice > > parameter "k" can't be zero (unless I'm mistaken), yet the FLAC spec > > says the Rice parameter can range

--- CHI Hongliang <hongliang.chi@enst-bretagne.fr> wrote: > hello, > > I am now develloping an embeded decoding system for flac.I have a > problem about the format of the rice coding: > > the residual begins with : 01 01 08 0C > > the first two bytes are the warmups, the prediction order is 2. and > the 080C is the following: > 00 0010 0000 001100 > >

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

hello, I am now develloping an embeded decoding system for flac.I have a problem about the format of the rice coding: the residual begins with : 01 01 08 0C the first two bytes are the warmups, the prediction order is 2. and the 080C is the following: 00 0010 0000 001100 the first two bits mean: residual coding method is partitioned rice the following four bits mean: the partition order is 2 ;

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

Hi, I asked a few questions about the flac format a couple of weeks ago. One more (if you don't mind) about the Rice coding. The Rice parameter "k" can't be zero (unless I'm mistaken), yet the FLAC spec says the Rice parameter can range from 0 to 15. I guessed, and tried adding one before using the parameter (i.e. assuming the range was really 1 to 16), and that didn't

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

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

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

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

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

Hello Is it planned someday to implement additional higher (9-12) compression modes like in Flake? http://flake-enc.sourceforge.net/ It's not very important I think. Harddrive space isn't problem today. But it preserves other indepentent work done on Flac and give room for some extra albums on harddrive. I think development of flake is stopped. I plan to test my ~20 GB flac

Hi all, I am interested in building a stand alone Rice Encoder/Decoder, using FLAC source code as a starting point. I've read the theory behind it, and I am very interested in info theory. However, I am struggling with how exactly I would implement the theory in code. I'm a newbie to computer science (only 1 year experience). I have read the format and documentation links on the FLAC