Rehuff for Vorbis

[TheXung]

There is an interesting utility for vorbis which optimizes the huffman tables so that a vorbis file is losslessly ~3% smaller. As we speak the discussion rages over at xiph http://www.xiph.org/archives/vorbis-dev/200207/0210.html

I've been playing with it a little and it indeed does work. However, when the optimized vorbis file muxed into video, it results in the same file size as the unoptimized file. I was wondering if this is a problem with oggmux, oggDS or just the nature of muxing.

I had to go through the trouble of downloading the ogg headers to compile it, so I figure I might as well attach the exec for people to try out.

[Neo Neko]

Interesting. We shall have to give this some play. :D

[Jon Ingram]

(this thread is a crosspost from http://forum.doom9.org/showthread.php?s=&threadid=30491 )

[DSPguru]

i copied this thread in here 'cause it relevant for both forums (vorbis belongs to audio forum, oggmux belongs in here).

[Koepi]

~2 years ago this rehuff tool was startzed. Back then it finally destroyed your OGG files.

Does it work properly now?

Regards,
Koepi

[DSPguru]

Originally posted by Koepi
Does it work properly now? i did a brief test to BeSweet 1.4RC6 and it seems to actually do the job.

[TheXung]

Is anyone else experiencing how an optimized vorbis will mux w/ video into the same size as an un-optimized vorbis?

[DSPguru]

i made a test with a 100mins track. before rehuff the bitrate was 77kbps, after - 76kbps. (space saved=1MB)
not much..

[kxy]

According to Sepher.

"a codeword length of zero is actually quite fine if it's the only codeword in the codebook; but Vorbis takes a length of zero to mean "not allocated". So let's waste a bit on those cases..."

Can anyone confirm that it indeed doesn't affect the quality and it is code optimization? :sly:



diff -ur rehuff/recode-headers.c rehuff-new/recode-headers.c
--- rehuff/recode-headers.c Wed Jul 31 02:09:23 2002
+++ rehuff-new/recode-headers.c Fri Aug 2 10:11:41 2002
@@ -275,11 +275,11 @@
recode_residue(&ob_in, &ob_out, headers->residue + i);

oggpack_copy(&ob_in, &ob_out, 6);
- for (i = 0; i < headers->mappings; i++);
+ for (i = 0; i < headers->mappings; i++)
recode_mapping(&ob_in, &ob_out, headers->mapping + i,
headers);

oggpack_copy(&ob_in, &ob_out, 6);
- for (i = 0; i < headers->modes; i++);
+ for (i = 0; i < headers->modes; i++)
recode_mode(&ob_in, &ob_out, headers->mode + i);

oggpack_copy(&ob_in, &ob_out, 1);
diff -ur rehuff/recode.c rehuff-new/recode.c
--- rehuff/recode.c Wed Jul 31 01:54:03 2002
+++ rehuff-new/recode.c Fri Aug 2 12:55:24 2002
@@ -118,7 +118,7 @@
if (heap.n) {
for (i = 0; i < 2*book->n-1; i++)
length[i] = -1;
- length[heap.x[1]] = 0;
+ length[heap.x[1]] = (heap.x[1] < book->n ? 1 : 0);
}

book->new_length = malloc(book->n * sizeof(*book->new_length));
[ Part 2: "Unknown Document" ]

diff -ur rehuff/recode-headers.c rehuff-new/recode-headers.c
--- rehuff/recode-headers.c Wed Jul 31 02:09:23 2002
+++ rehuff-new/recode-headers.c Fri Aug 2 10:11:41 2002
@@ -275,11 +275,11 @@
recode_residue(&ob_in, &ob_out, headers->residue + i);

oggpack_copy(&ob_in, &ob_out, 6);
- for (i = 0; i < headers->mappings; i++);
+ for (i = 0; i < headers->mappings; i++)
recode_mapping(&ob_in, &ob_out, headers->mapping + i,
headers);

oggpack_copy(&ob_in, &ob_out, 6);
- for (i = 0; i < headers->modes; i++);
+ for (i = 0; i < headers->modes; i++)
recode_mode(&ob_in, &ob_out, headers->mode + i);

oggpack_copy(&ob_in, &ob_out, 1);
diff -ur rehuff/recode.c rehuff-new/recode.c
--- rehuff/recode.c Wed Jul 31 01:54:03 2002
+++ rehuff-new/recode.c Fri Aug 2 12:55:24 2002
@@ -118,7 +118,7 @@
if (heap.n) {
for (i = 0; i < 2*book->n-1; i++)
length[i] = -1;
- length[heap.x[1]] = 0;
+ length[heap.x[1]] = (heap.x[1] < book->n ? 1 : 0);
}

book->new_length = malloc(book->n * sizeof(*book->new_length));

[Acaila]

On a 176 min audio track it saved me a whole 2 MB.

And add to that the fact that PowerDivX choked on the final file and I'd say this program is far from ready. The idea seems very good though.

[unplugged]

Concerning my experience, using the exe utility reuff.exe the result of my 60 Mb audio track is NOT at all seekable with Winamp 2.80 + latest vorbis plugin 1.2.
Starting from half part the player reaches immediately the end. Not playable from that point :(