similar to: Lossless compression

Hi, We are porting the Ogg Vorbis fixed point decoder to a 24 bit fixed point precision processor. We are trying to reduce the number of cycles for MIPS optimization. In this process we observed that most of the songs do not have "maximum codeword length" greater than 24 bits. We are planning to reduce most of the double word operations (in our case 32 bit data is stored as double

Hello folks, The codebook infrastructure for Vorbis is now well underway. This is it! The last piece needed for *real* bitstreams. To that end, I have a decent VQ codebook generator running. I was originally using some farily typical merge/split algorithms and then decided that the right way to do this was to model a VQ codebook as an m-dimensional set of bubbles (like a foam). I know there

Hi, I am trying to implement ogg vorbis real time decoder on SHARC ADSP 21364 processor. I am writing my own version of the decoder using the documentation vorbis_I_spec.pdf from xiph.org. However I am facing certain hurdles in floor curve decoding during audio packet decode. In the spec it says that [cval] = read from packet using codebook number [so and so] in *scalar context*.(page no 43).

hello all, we are developing and porting vorbis1decoder on a 24 bit platform. in the process we came across somedoubts about node bytes and leaf words. from the specification we got that we are arranging the huffman codeword tree into an array. the nodebytes are the number of bytes that are required to represent a node and leafwords are the no. of bytes required to represent the leaf i.e the

hello, does anybody know whether the codewords have a special meaning? whether they have a different influence like the quantization matriy in jpeg? e.g. do lower or the first entries have a greater influence than the last or higher codewords? thanks gerald

I know this probably transcends the scope of the current aims of Ogg video, but one thing I'd consider extremely useful is a lossless video compressor. There are a few of them out there (e.g. PICVideo's lossless wavelet codec) but I've found no free ones so far. The primary use would be for storage of video clips that would be too cumbersome to store as raw frames but still require

Hi, I am a bit confused on how code-words are derived from the codeword lengths. I will appreciate if someone can point me in the correct direction. I will take the example of an actual codebook that i found in a valid vorbis encoded file as shown below. [SK] +------Codebook [0] -------- [SK] Codebook Dimensions = 1 [SK] Codebook Entries = 8 [SK] Unordered [SK] 1, 6, 3, 7, 2, 5, 4, 7, [SK] NO

Hi, From the vorbis decoder specification, it is clear that the decoder needs to have all the codebooks before decoding can actually begin. I will appreciate if someone can clear the following questions: 1. I guess the codebooks are derived from the actual input data. Probably the encoder may be making two passes through the input. The first pass finds out the frequency of different symbols

I want to analyse compressed data between VQ and Huffman coding steps. Where in source code can I access to data massive for this goal. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/vorbis/attachments/20090916/4529e42d/attachment-0001.htm

I've made a block diagram of the encoder because I tried to find out, how it works http://stoffke.freeshell.65535.net/ogg/block.html Although there are specifiation docs, that give very detailed information about single aspects of the encoding (or decoding) , I'm missing documenations that give a more general overview, about how the encoder works. (Vorbis Illuminated seems a bit

Hello Monty, Sorry for the wrong subject title last time. A little more clarification needed. When reading bit-by-bit, there is no MSb/LSb, just 'first bit' and 'last bit'. The Huffman tree is traversed from 'first bit' to last bit'. This is a conceptual layer above the bitpacker; all you need to know is what order the bits come out, which happens to be LSb-first.

Hi, I am trying to understand the building of Huffman codes from the code lengths. In the Tremor code first I see that the codewords are being generated by the function _make_words() and then sorted. After this I see some magic code and something related to unused entries. Does the code generate code words for unused entries too? Are these unused entry code words used during the decode

I'm trying to understand the residuevqtrain program, and I have some questions for Monty, Erik, or anyone that understands how it's supposed to work. I captured TRAIN_RES data from an encoding of a single track (about 4:43), producing two files, residue_0.vqd (3727 lines, = 3727 points?) and residue_1.vqd (huge). I then did a run with the parameters from the usage message

Hi radeonhd, nouveau, mesa3d developers, Firstly, thank you all very much for all the important work you do. I've been working as a part-time developer on the "Spring RTS" project (open-source game engine) which runs on linux (and other os). Some time ago I tried the engine on the open-source ATI radeonhd driver, which I understand to be partly based on mesa 3d, and all textures

Hi folks, My wife and I are taking a long weekend to celibrate our anniversary. I won't be around again until Wednesday to answer email or do anything else on Vorbis. Yeah, I know, I usually answer my email once a month anyway (so likely no one would notice me being gone), but just so folks know if anything really juicy comes up :-) I'll be merging my latest branch with mainline

I'm copying the flac-dev list to see if anyone has any feedback also... --- Juhana Sadeharju <kouhia@nic.funet.fi> wrote: > Hello again. I had time to check the paper out. I have filled the > steps given in the paper with formulae, and then written a piece of > C code. It is not complete code, but could be a reasonable start. > Maybe there is one typo in the paper -- I have

** THE RETURN ADDRESSES ON THIS LETTER HAVE BEEN SET TO PREVENT MAIL ** ** LOOPS IN THE EVENT YOU ARE RUNNING SOFTWARE WHICH AUTO-REPLIES TO ** ** INBOUND MAIL. UUNET WILL NOT SEE ANY REPLY SENT TO THIS LETTER. ** Dear Customer, We have received your message ("Re: [vorbis] bitrtate peeling and lossless compression") and forwarded it to the appropriate personnel for processing. To

During the interesting interview that binaryfreedom has made with Monty and Jack, Monty mentions cascading, a feature that will be added, quote: "Cascading is the ability to make multiple passes through the frequency spectrum, iteratively filling in more detail, like a progressive jpeg". What are the advantages of something like this - does this generally improves quality or is it used

I just read some of the discussion on the list about 'bitrate peeling' and remembered an interview of Monty that I have read recently. In it he says that Vorbis uses MCDTs <sp> and that these are theoretically reversable. And now, I learn that theoretically we can use bitrate peeling to make smaller files from larger ones, and that leads to my question. Could I theoretically

Thought I'd send an update on FlacPak a file format for compressing instrument files (although its more generically a method of compressing files containing binary and audio with most of the smarts being in the encoder file handlers). It uses zlib for compressing the binary data and FLAC (of course :) for compressing the audio. There is now a CVS tarball of libInstPatch which contains a