[vorbis] bitpeeler

[Segher Boessenkool]

Kyle Rose wrote:
> 
> No offense, Segher, but the output quality of this thing is awful. =)
> 
> I'll disregard the fact that, at least with *my* compiler, the source
> tarball I downloaded reduces every packet to zero bytes, which isn't
> terribly interesting.

It is called apr-1.0 for a reason.  Did you happen to look at its
release date?

> I decided to set the byte reduction to something constant: I started
> by dividing each packet's size by 2 just to see what would happen.

It will sound like shit.  Even my earliest peelers (ages ago) didn't
do just that.

> The resulting ogg file was basically unlistenable.  Yes, it sounded
> like the original music, but there were *terrible* artifacts
> throughout the music, mostly sounding like constant-frequency tones
> overlaying the music, each lasting for a short fraction of a second.

You have the MDCT to blame for that -- some kinds of _conceptually_
small changes in the "compressed" domain will introduce all kinds
of awful phase-induced artifacts into your sound.  Yuck.  There is
no way to change a block without very carefully altering the
surrounding blocks as well, without suffering huge losses.

> At 2/3 of the original bitrate, the artifacts were still almost as
> bad.

Yes.  And with current libvorbis-encoded streams, peeling to 2/3
is a lowpass by an additional one or two octaves, even if the sound
artifacts would ot be there.

> By contrast, encoding the original wav file at 64 kbits produces a
> much smaller file than either of these tries, and sounds significantly
> better.

Yes, but it is a *lot* slower as well.

> I'm starting to get the impression that (excuse me while I commit what
> is probably an atrocity wrt to the Vorbis algorithm) the compression
> used by Vorbis isn't a "stable" sequence, i.e., one for which
> 
>                |S_{n+1} - S_n| < 1/k |S_n - S_{n-1}|
> 
> otherwise, I suspect that cutting out half the bits would degrade the
> sound quality significantly, but wouldn't introduce the kinds of
> artifacts I was hearing.

Taking *away* some of the sound will make the human ear hear *more*,
in most cases.  That's why perceptual audio compression is hard (much
harder than video compression) -- there is much much more "information"
in a sound recording than you can ever notice, but take some away, and
you _do_ notice it's not the same anymore (even though you most likely
will _not_ notice what was taken away).

> A utility that needs to do some inexpensive analysis of the file (or
> of each packet) to determine a nearly-optimal shorter sequence
> representing the same waveform would be much preferred to a utility
> like apr, which is essentially useless for any real-world application.

So write it.  It is hard to do, especially if it has to be (much)
faster than simply reencoding.

> Of course, if the encoder could be altered to allow the use of a
> utility as simple as apr to perform adequate bitpeeling, that would be
> even better in the long run:

This is the plan.

> but I'd still have my 10,000-strong collection of Ogg's to re-rip,

No, because you can *losslessly* reencode a Vorbis file to a
better-peelable (or easier-peelable) file, or even to a newer
version of the Vorbis format, as long as that new format still
uses the same MDCT (or something very much like it) and the same
floor curves.

> which would leave me terribly unhappy
> at the misleading carrot-on-a-stick promotion of "bitpeeling" these
> past two years.

It's not me who promised you this.  I'm only experimenting with
implementing it.  Don't shoot the messenger.

The Vorbis format *does* allow peeling, where other formats *don't*
allow it; it's just not as easy as some of us hoped.

If you care so much about it, maybe you would hire me to work on
it more than a few hours every so-many weeks?

<p>Segher

<p>--- >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-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.