Hiya, Here is the sources to my "rehuff" program. ./rehuff in.ogg out.ogg does a lossless recoding of a vorbis stream. (It generates optimal huffman codes for the particular stream). This code is meant for developers only, until someone is kind enough to provide good build and configure support for it. I won't. And no installation help questions please. There is a little patch in here, which makes stream serialno handling easier for decoder programs. This is not the right way to do it(tm); anyone with better ideas please implement. The idea is that packet level routines shouldn't have to bother with page level stuff. Oh, and you need to remove the "static" from the _vorbis_pack_XXX routines in your vorbis source to build rehuff. There is a Makefile supplied, but you'll probably need to fiddle with it a bit. Have fun, Segher. p.s. bit savings results for average streams: beta1 5% beta2 2% beta3 1.3% beta4 2% <HR NOSHADE> <UL> <LI>application/octet-stream attachment: Unknown Document </UL> -------------- next part -------------- A non-text attachment was scrubbed... Name: rehuff.tar.bz2 Type: application/octet-stream Size: 5232 bytes Desc: not available Url : http://lists.xiph.org/pipermail/vorbis-dev/attachments/20010124/8c872952/rehuff.tar-0001.obj
May I ask a question? Why is the vorbis code generating non-optimal huffman codes in the first palce? I seem to recall there is a greedy algorithim that always produces an optimal huffman tree? ... OD --- Segher Boessenkool <segher@wanadoo.nl> wrote:> Hiya, > > Here is the sources to my "rehuff" program. > > ./rehuff in.ogg out.ogg > > does a lossless recoding of a vorbis stream. (It > generates optimal > huffman codes for the particular stream). > > This code is meant for developers only, until > someone is kind > enough to provide good build and configure support > for it. > I won't. And no installation help questions please. > > There is a little patch in here, which makes stream > serialno > handling easier for decoder programs. This is not > the right way > to do it(tm); anyone with better ideas please > implement. The idea > is that packet level routines shouldn't have to > bother with page > level stuff. > > Oh, and you need to remove the "static" from the > _vorbis_pack_XXX > routines in your vorbis source to build rehuff. > > There is a Makefile supplied, but you'll probably > need to fiddle > with it a bit. > > Have fun, > > Segher. > > p.s. bit savings results for average streams: > > beta1 5% > beta2 2% > beta3 1.3% > beta4 2%> ATTACHMENT part 2 application/octet-streamx-mac-type=54455854; x-mac-creator=74747874; name=rehuff.tar.bz2 __________________________________________________ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/ --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Interesting ... thanks :) OD --- Segher Boessenkool <segher@wanadoo.nl> wrote:> > > OmegaDan wrote: > > > > May I ask a question? > > > > Why is the vorbis code generating non-optimal > huffman > > codes in the first palce? I seem to recall there > is > > a greedy algorithim that always produces an > optimal > > huffman tree? ... > > The encoder doesn't know what data it will need to > encode; > streaming wouldn't work if it needed this info. The > encoder > uses huffman books that are trained to optimally > encode a > certain big, reprresentative data set. This is not > optimal > for every stream, but close to it. Actually closer > than > I thought before I wrote rehuff; rehuff will gain > you 1-2% > on most streams, I thought it would be 5-10%. > > rehuff is still useful for people who want the last > few tiny > drops of compression gain, and for developers. > > Cheers, > > Segher > > --- >8 ---- > List archives: http://www.xiph.org/archives/ > Ogg project homepage: http://www.xiph.org/ogg/ > To unsubscribe from this list, send a message to > 'vorbis-dev-request@xiph.org' > containing only the word 'unsubscribe' in the body. > No subject is needed. > Unsubscribe messages sent to the list will beignored/filtered. __________________________________________________ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/ --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Here is a binary for Win32, although as of yet, rehuff doesn't add proper
offsets into the packets, so the output will break seeking in any player
that supports it. Stay tuned for an updated version.
http://209.197.15.3/pages/moeljbcp/kode54_net/vorbis/rehuff.exe
-Chris M.
--- >8 ----
List archives: http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'vorbis-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body. No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.
I was wondering: Is rehuff still being worked on? I'm trying to get it to work with the most recent CVS vorbis, but I don't really know what to do. Will it be included in vorbis-tools eventually, or will it always be a separate thing? Aaron Plattner --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.