similar to: Rice coding parameter

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

Hi, I'm trying to write a FLAC decoder for my Java audio app. Can I ask a couple of questions to this list about the format? I think there are a couple of things not-quite-mentioned in the official spec. RICE CODING: Which order are Rice-coded numbers stored in? (a) [sign-bit][low-order bits]["k" zeroes][1] (b) [sign-bit]["k" zeroes][1][low-order bits] (c)

Thanks Miroslav, for your help - much appreciated. > > RICE PARTITION SIZE: In a zero-partition-order Rice block, the > > documentation says the number of samples in the partition is equal > > to the frame's blocksize. Surely this should be equal to the > > frame's-blocksize-minus-the-predictor-order, since we shouldn't need > > to encode residual for

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

It's a shell script #!/bin/bash IPTABLES="/sbin/iptables" # Load required modules /sbin/insmod ip_tables /sbin/insmod ip_conntrack /sbin/insmod iptable_nat /sbin/insmod ipt_MASQUERADE # Then flush all rules /sbin/iptables -F /sbin/iptables -t nat -F /sbin/iptables -P INPUT DROP /sbin/iptables -P OUTPUT ACCEPT /sbin/iptables -P FORWARD ACCEPT # In the NAT table (-t nat), Append

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

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

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

Check this out: http://rice.rubyforge.org/ Regards, Dan

As was briefly discussed on IRC, ffmpeg and mplayer currently output two somewhat incompatible YUV4MPEG streams. This meant that encoder_example could take input from mplayer, but not ffmpeg or movtoy4m (a QuickTime->Y4M tool). This is a patch that fixes this issue and should allow encoder_example to take input from either format: diff -urd xiph-cvs/theora/examples/encoder_example.c

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

Hi - I've heard that Icecast provides a fake "playlist file" along the lines of http://blahblah:8000/listen.m3u or http://blahblah:8000/playlist.pls because Quicktime can't seem to handle the stream without a playlist file to wrap it up. (There may be other reasons.) However, I can't seem to find any documentation about this, and guessing various URLs on my icecast2.0.1

I just wanted to point out that it's "stats", not "STATs". "Stats" is not an acronym! It's an abbreviation; it's short for "statistics". On Fri, 25 Feb 2005, Dan Stowell wrote: > Date: Fri, 25 Feb 2005 09:43:38 +0000 > From: Dan Stowell <danstowell@gmail.com> > To: icecast <icecast@xiph.org> > Subject: [Icecast] Re:

On 5/20/05, Dan Stowell <danstowell@gmail.com> wrote: > Hi Iain, > > It's a simple answer: > > > For example, if a box on a 128kbps upload connection is > > serving a 64Kbps stream (and not audio-on-demand) - is it limited to two > > connections > > Yes it is. > > > or is icecast somehow more efficient? > > No - icecast can't

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

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