similar to: Peeling (was RE: streaming)

Not vorbis-related, just I think I found a similar technique being used... The description of the MPEG-2/SVCD plugin on the nero site says that it can encode exacty to the size of the CD (to maximize quality given a size restriction). It also says (in a separate point) that it uses two-pass VBR compression. >From that I guess they do something like encoding a bigger-than needed file and then

Given all this talk of peeling lately, I thought I'd try out a method I've been thinking about for a while now. It goes something like this: * Peeling is achieved by dropping some of the residue. * The encoder indicates how much of the residue to retain (e.g a number of stages, 3 bits in the stream per packet, non-standard!). * The decoder (peeler) copies the contents of packets except

>> Is bit-peeling going to be real (or just a rumor forever)? > Apparently the RC3 streams are capable of being bit peeled, however the > tool to do so was looking likely to be quite complex. I believe the plan > was to have RC4 produce streams that left better hints for the peeling > tool, so as to make the tool simpler and faster, but I doubt we'll see it > until

Hi All, Let me ask this question of the group: When bit rate peeling becomes available, how will the quality of the peeled Vorbis file compare to a file encoded at the target quality directly from the original? So, for: a.wav --> b.ogg (at q6) --> c.ogg (at q2) a.wav --------------------> d.ogg (at q2) how are c.ogg and d.ogg likely to compare in terms of audio

Hi all, First up, this is not a proposal on how to do it, but rather on how to get it done. In the latest thread it was mentioned that it was most likely that either Monty or Segher would be the most likely people to implement this code. It was also stated that this is not their priority at the moment. I can only see two solutions to this problem: 1. Find someone else with the knowledge and

first, congrats to monty and the whole crew for getting this close to 1.0. it's a monumental achievement reflecting a huge amount of hard work -- kudos! econd, i know the bitrate peeling feature has been pushed back until after 1.0 is out. but i'm wondering -- will oggs created with a 1.0 encoder be peelable with an as-yet-unreleased utility, or do "peelable oggs" have to be

Hello all, Just a quick note to let you all know that I have placed a bounty on Lauchpad to get bitrate peeling added to Vorbis. It is a feature that I think we would all like to have, and would probably pay something to get, but it hasn't been done. My request to you is to add to the bounty. I have seeded it with US$20, which is not enough to motivate a developer to get it done, but I am a

Hi everybody: Here is this week's Ogg Traffic with all new updates on recent activities in the world of Xiph.org. The HTML version is up at http://www.vorbis.com/ot/20030415.html. Enjoy! -Carsten <p>Ogg Traffic for Tuesday, April 15, 2003 [1]Carsten "Purple" Haese April 15, 2003 _________________________________________________________________ Table of

I was up late last night, and i had a thought on peeling that would probably provide 100% accurate peeling data to a decoder, but take a maximum of 1101 times normal time to encode (taking into account the range from q-1 to q10 ). ay you want to encode a track at q10, but you want it to be peelable. the 1101 encoder would encode from the source at every quantifiable level (since there are 2

Hi all, I recently started to study the Ogg Vorbis codec and found an interesting feature called bitrate peeling [1]. Do you know where I can find more information on this topic? E.g., how is the actual peeling being implemented, what are the performance results in terms of resulting quality, what are the requirements for bitrate peeling (can it be applied to any ogg vorbis stream), ...? Also,

After reading http://mp3.radified.com/mp3.htm I sent Rad an explanation of some things as I understand them. He liked it and posted it on his site (still unlinked, use the URL below). Can somebody with better understanding of psycho-acoustic terms and the vorbis model check it and comment on it? In particular I didn't know how vorbis handles quantization noise. If you reply with

Monty, You helped me out quite a bit the other day, but I just wanted to make sure I understand something. The "ideal" way to do bit rate peeling is to have the encoder set the file up to be conducive to the peeling process, and the streamer would be the device that actually does the peeling. Am I correct in assuming, then, that the decoder would think that the file it is

Hey, Maybe you guys remember us, I'm from the Neuros forums. I've got to say, having a player that supports Ogg Vorbis has really turned things around for everybody. We're still struggling with higher bitrate Vorbis streams, but that is only because of our terribly underpowered DSP. Anyway, to the point of my email. Recently the discussion of bitrate peeling has been floating

After reading the recent thread [http://www.xiph.org/archives/vorbis/200211/0057.html] on the vorbis list about bitrate peeling, I was wondering if it would be possible for xiph.org to post a specification, outline, flowchart, or a drawing on a napkin of what the basic operations of bit peeling would entail. If there was some sort of starting point, then it may be a little more inviting for

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello vorbis, Wasn't really answered in my first post about this subject (although people did convince me to do a debian/rules binary, which i've done and am VERY impressed with RC3 (played a -q3 file to a mp3 dude secretly, and he says "whoa! 112kbits! give me your new mp3 encoder" (winamp3 doesn't show the changing

I just read some of the discussion on the list about 'bitrate peeling' and remembered an interview of Monty that I have read recently. In it he says that Vorbis uses MCDTs <sp> and that these are theoretically reversable. And now, I learn that theoretically we can use bitrate peeling to make smaller files from larger ones, and that leads to my question. Could I theoretically

Hi all, [For the uninitiated: a "peeler" is a program that transforms a Vorbis stream into a smaller, (somewhat) lower quality Vorbis stream, and does so quickly, by just throwing out some data.] After having prototyped several peelers that aim to peel to a certain filesize, or to a certain quality, with mixed success, I've now taken a different route: a peeler that aims for the

Hi all, [For the uninitiated: a "peeler" is a program that transforms a Vorbis stream into a smaller, (somewhat) lower quality Vorbis stream, and does so quickly, by just throwing out some data.] After having prototyped several peelers that aim to peel to a certain filesize, or to a certain quality, with mixed success, I've now taken a different route: a peeler that aims for the

After reading the documentation on the different types of channel coupling I began to wonder what effects this might have on bit peeling. Say for instance an audio file is encoded at a rather high bit rate with channel coupling type "X". Later on the same file is streamed, and is peeled down to a much lower bit rate in the process. However at this lower bit rate, channel coupling type

Hi all, I'm looking into congestion control for Vorbis RTP and I'm wondering if it's not too early to define a mechanism which would help bitrate peeling. The client can send a standard receiver report stating the interarrival jitter and packets loss. Once a certain jitter/loss point is reached the server peels off a pre-determined bitrate fraction from the stream, eg 128k would