similar to: changes in CVS

--- Wayde Milas <wmilas@rarcoa.com> wrote: > On Tue, 2004-01-20 at 23:44, Josh Coalson wrote: > > Miroslav did some experiments with searching for optimum blocksize. > > from what I remember it made at best a couple percent difference. > > there was a thread about it here a while back. > > > Did his changes make it in? I can think of a coupla ways to approach

On Tue, 2004-01-20 at 23:44, Josh Coalson wrote: > Miroslav did some experiments with searching for optimum blocksize. > from what I remember it made at best a couple percent difference. > there was a thread about it here a while back. > Did his changes make it in? I can think of a coupla ways to approach this and I'd like to hear about what he tried. A couple of % doesnt seem

I just released FLAC 0.5 (Solaris binaries will show up tomorrow). FLAC is now beta; see the homepage as to what that implies: http://flac.sourceforge.net This version adds a MD5 signature of the raw audio signal to the stream header, which can be compared against when decoding to test the integrity of a file. A test mode (-t) has been added to flac to do just that. There is a slight

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

Dear list, I wonder if the flac encoded file has a great amount of bits due to the residue. I mean, what percentage of the flac file has information of the residue? Is this sequence represented by more than 80% of the flac file? On the other hand, which is the value typically adopted for the parameter "n" in the Rice coder? I know these results depend on the input wav file, but I

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

After doing a lot of automated seek testing on files, it looks like the length of the sync code (currently 9 bits) is not long enough to enable a really robust AND efficient seek algorithm. Lengthening the sync code will require a format change (i.e. FLAC <0.8 streams won't play back on FLAC >0.9 decoders), so I'm sending this message out to see if there is any "NO DON'T DO

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)

I think it would be interesting to add multilanguage support to the entire site (spanish is my home language and only the front page appears translated). For example, the entries and forms for test data in the AppDB could be displayed in the language of each user, so anyone else could understand. This would increase the user base of Wine, as many non-English speakers could understand the entries

On my lists of things to do for 1.0 were 1) improve seeking; and 2) speed up both encoding and decoding. Seeking seems better now (I added the SEEKTABLE and tweaked the search algorithm). On the way, one of my encoding experiments worked. By taking advantage of a relatively unused area in the Rice parameter space, I added an escape code for switching to flat encoding within a partition.

Great to hear that things are going smoothly, Josh. My $.02 is that it is worth making 110% sure that you/we've tweaked the codec for speed/compression as much as can be done *before* 1.0, since we're really not under any kind of deadline. Sure, it would be nice to get it out the door, but why not have it rival Shorten and Monkey's right from the start? I'm *still* working on

I scanned the website with linkchecker and found quite a lot of dead links. This commit fixes or removes them. --- developers.html | 2 +- documentation_tasks.html | 2 +- download.html | 12 ++++++------ faq.html | 2 +- features.html | 2 +- feeds/feed.xml | 8 ++++++++ format.html | 8 ++++----

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

I scanned the website with linkchecker and found quite a lot of dead links. This commit fixes or removes them. --- developers.html | 2 +- documentation_tasks.html | 2 +- download.html | 14 +++++++------- faq.html | 2 +- features.html | 2 +- feeds/feed.xml | 8 ++++++++ format.html | 8 ++++----

Hi demo pages http://web.mit.edu/xiphmont/Public/theora/demo.html http://web.mit.edu/xiphmont/Public/theora/demo2.html discussed opportunity to add range coding there is already some xiph code: http://svn.xiph.org/trunk/ghost/libentcode/ and Timothy B. Terriberry wrote some time ago === I'd estimate that you'd save ~12% by switching from Huffman to something arithmetic coding-based

I'm doing some experiments with GlusterFS. Most documents online suggest to install the glusterfs-package as if it was available directly in the repo, and therefore installable via a simple "yum install". Unless I'm wrong, it appears that this package is not in the repo for CentOS 6. Does anyone know what happened to it? -- Florin Andrei http://florin.myip.org/

--- Wayde Milas <wmilas@rarcoa.com> wrote: > The reason for this post is I would like to know if I start coding > again > and releasing patches agaisnt flac in various areas, if they will be > accepted. I'm not sure if these additions fit the "focus" of what > flac > is meant to be, so I thought I'd discuss them first. Keep in mind > that I > just

> -----Ursprungliche Nachricht----- > Von: Josh Coalson > > --- Tor-Einar Jarnbjo <Tor-Einar_Jarnbjo@grosch-link.de> wrote: > > Hi, > > > > have I just overseen a link, or is the format description on > > http://flac.sourceforge.net/format.html lacking information on how to > > actually decode the residual partitions to PCM sample data? > > you

On Wed, May 13, 2015 at 12:26 PM, Tim <lists at kiuni.de> wrote: > Hey Johnny, > > firefox seems not to have multilanguage support anymore. After the > update my firefox turned from german to english. > > Regards > Tim Yes, it's a known issue. Please follow the links in this post: http://lists.centos.org/pipermail/centos/2015-May/152273.html Akemi

Hi Josh, I am noticing a problem in my application also which does realtime encoding on pocket pc. Most 24-bit music content does not compress well. But I have noticed that rectangular waves that I have encoded have compressed fairly well, so it seems to depend upon the predictibility of the content. I would also be very interested in a fix for this. Gordon --- Josh Green <josh at