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.
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.
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.
At 2/3 of the original bitrate, the artifacts were still almost as
bad.
By contrast, encoding the original wav file at 64 kbits produces a
much smaller file than either of these tries, and sounds significantly
better.
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.
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.
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: but I'd still have my 10,000-strong
collection of Ogg's to re-rip, which would leave me terribly unhappy
at the misleading carrot-on-a-stick promotion of "bitpeeling" these
past two years.
Cheers,
Kyle
--- >8 ----
List archives: xiph.org/archives
Ogg project homepage: xiph.org/ogg
To unsubscribe from this list, send a message to
'vorbis-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.
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: xiph.org/archives Ogg project homepage: xiph.org/ogg To unsubscribe from this list, send a message to 'vorbis-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.
On Tue, Apr 08, 2003 at 11:47:14PM -0400, Kyle Rose wrote:> No offense, Segher, but the output quality of this thing is awful. =)It was Segher's annual April Fools' joke. Monty --- >8 ---- List archives: xiph.org/archives Ogg project homepage: xiph.org/ogg To unsubscribe from this list, send a message to 'vorbis-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.
> -----Original Message----- > From: Sebastian Gesemann [mailto:sgeseman@uni-paderborn.de] > Sent: 14 April 2003 16:05 > Subject: Re: [vorbis] bitpeeler > > On Wed, 9 Apr 2003, Segher Boessenkool wrote: > [...] > > 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. > > ... and the same window function and this and that ... > > I'm not sure if it is possible to reencode a vorbis file to > a newer better-peelable vorbis-1 file. This implies redisign > of the (currently one-stage?) quantizing mechanism to multi-stage > VQ. - Yes, I'm aware that Vorbis supports multistage VQ. But > i have absolutely no idea how this conversion should be done > without introducing new quantizing errors. Do you ?I've been puzzling over this a little recently. I think that having the bit peeler make any decisions based on psychoacoustics entirely defeats the point - it's no longer a trivial operation. So these decisions must be made by the encoder and communicated to the peeler. The way I've always imagined a bit peeler working is as you suggest - a multistage VQ. This is probably just how everyone else has suggested, but just to recap: * One stage consisting of one or more passes of VQ is used for "peeled" quality. * A second stage (0+ residue passes) of VQ is used for "high" quality. * (More stages are used for e.g a streaming server which has 32/64/128/192kbit rates) * The encoder runs passes until it reaches "peeled" quality, and marks off how many passes it took. * The encoder then runs more passes until it gets to "high" quality. * The bit peeler simply runs through the file and rewrites the residues without the "high quality" passes. The problem is I don't see anywhere in the spec where the encoder could indicate how many passes are assigned to each stage on a per-frame basis. I guess you could add another residue format type, but I think it's orthogonal to the format type. I'm tempted to play with this idea when I have spare time (which I might have a lot of depending on what happens to SonicBlue tomorrow!) Does anyone know if there's something blatantly wrong with this method that I should know? :) - John Ripley. --- >8 ---- List archives: xiph.org/archives Ogg project homepage: xiph.org/ogg To unsubscribe from this list, send a message to 'vorbis-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.
Segher Boessenkool wrote:>Yes. But libvorbis-1.0 encoded streams are not very nicely peelable -- >that's why I losslessly reencode them, first.Am I correct in guessing that you are referring to re-huff'ing them? --- >8 ---- List archives: xiph.org/archives Ogg project homepage: xiph.org/ogg To unsubscribe from this list, send a message to 'vorbis-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.
> Segher Boessenkool replied to me: > >>Yes. But libvorbis-1.0 encoded streams are not very nicely peelable -- >>that's why I losslessly reencode them, first. > > Am I correct in guessing that you are referring to re-huff'ing them? >No. Although I rehuff 'em, too.I know I'm missing a conceptual step - in what way do you losslessly re-encode the already lossy stream? or - do you losslessy encode the original and do some kind of diff? or am I missing something else? -Myles --- >8 ---- List archives: xiph.org/archives Ogg project homepage: xiph.org/ogg To unsubscribe from this list, send a message to 'vorbis-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.
Segher wrote in a reply: (parts removed for brevity)>Let me just give a small example of how this can be done. >Where first we had a stage that encodes 0, 1, 2, 3 we change >it to two stages that encode 0+0, 0+1, 2+0, 2+1. This doesn't >take more space if you make the vectors long enough (in fact, it >almost always takes _less_ space), and it can be better peelable >if you order those new vectors in a smart way. > >Doing it exactly like this does not result in much better audio >quality for heftily peeled streams; that's where better tricks >prove useful :) > >With losslessly reencoding, I mean encoding the stream again, >with different books and modes, but representing exactly the >same data. > >Have fun, > >SegherSo, my second guess (errr, 6th guess?) you are doing a combo of rehuff (for optimim codebook entries to begin with), and re-organising the huffed data so it resembles my Nov example of Base+lowQ+medQ+highQ for easier removal the highQ. My new question: is rehuff going to do all that? or will rehuff be rolled into be an adjunct to another tool that does the re-ordering? -Myles --- >8 ---- List archives: xiph.org/archives Ogg project homepage: xiph.org/ogg To unsubscribe from this list, send a message to 'vorbis-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.