Because of the sub-optimal one pass method, it is possible to gain some space by recompressing an Ogg Vorbis file, but space savings as dramatic as 10% could not be reproduced with the current version of the encoder. (For example, a quick test by myself resulted in a pitiful 0.2% gain on a randomly chosen file from my collection.)Segher Boessenkool is currently developing a tool that optimizes the Huffman codes for a given Ogg Vorbis file in order to shave off a few percent of the file size. He reports that the resulting space savings are normally under 5%, and typically between 1% and 2%.
I don't know if this is doable, but a 2nd pass could scan the compressed file for heavy compression damages and reencode the block with a higher bitrate. And do the same on highbitrate blocks, recompressing them on a lower bitrate.
In video, double pass is not used for saving space, but to maximize quality for a given size/bitrate. I think it should be the same for audio.
does the ogg vidoe container support the rehuff savings ?if i use ogmmux to mux avi videi and some vorbis file with rehuffis the audio still done with the rehuff savings ?
Now, having tried to encode this CD, I have indeed received files which were smaller than they used to when using OggEnc(1), but unfortunately, seeking and jumping in files has been corrupted.
EDIT: OK, now I've found out at the Doom9 Forum that this problem has been encountered in previous releases too ... unfortunately there seems to be no solution, right?
does the ogg vidoe container support the rehuff savings ? if i use ogmmux to mux avi videi and some vorbis file with rehuff is the audio still done with the rehuff savings ?
Yesterday I downloaded oggenc2.2 and tested it using the --rehuff switch; it seems that skipping and searching within a track is working correctly now.My filesize savings due to using --rehuff came to about 1 - 2 percent.Are there plans to make available an ICL7 compile optimised for Pentium 4?My thanks to john33!