similar to: had a thought on peeling last night

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

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

Hi: A friend asked me a question that I was unable to answer, so I'm posting it here. Can files created by the beta4 encoder be peeled down when that becomes available, or is the ability to encode peelable files also not implemented? My friend wants to know if they should switch over now or hold off until this becomes possible. Geoff. --- >8 ---- List archives:

Hi all, last time I have seen discussions here about alternative encoders, or tuned versions of the encoder. Last year (sept/oct) there had been the discussion if existing streams will be peelable or if they have to be "modified" first to be peelable. Now for my question: Is it known allready if existing streams will be peelable or not ? Or, with other words: Is it known if the /can/

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

>> 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

I have run an ogg analisis using EAQUAL from -q 0 till -q 10 evaluating bitrate and quality. The results are shown in a nice graph, and can be seen here: http://audio.sinderman.com/ One thing I have found is a bug, as it is cleary shown by the blue lines. Other discoveries are written in that page, and others are still evolving in my mind :) The goals of this analisis is to help the developers

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

Hey y'all -- I heard some discussion a while back about "bitrate stripping" to reduce filesize without re-encoding ... has this gone anywhere? Too lazy to write a re-encode script, Nate <p> --- nate - nmt2002@columbia.edu cell=917 445 6830 aim=mediumnate abolishthe.us/gpgpublickey Nobody for president. --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg

Hi: I just wanted to know where exactly the problem with re-encoding in RC2 was. Was it in vorbis' ability to cope well with its own output as input, or did the first encode produce output that didn't lend itself to re-encoding? The difference is important. If it's the latter, anyone wanting to re-encode material will have to first encode it with RC3. I guess what I'm asking

Hi: How do I select different variables from a list of data frames. I have a list of 13 that looks like below. Each data frame has more variables than I need. How do I go through the list and select the variables that I need. In the example below, I need to get the variables "a", and "q10" and "q14" to be returned to two separate data frames. Thank you. Yours, Simon

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,

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

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 I was surprised with size of Theora files and thought of feedback. Following 1minute duration Theora and Xvid files were made from a y4m file. The resolution is 1280x720: 1. Xvid 17MB 2. Ogg/Theora Q7 31MB 3. Ogg/Theora Q8 38MB 4. Ogg/Theora Q9 49MB 5. Ogg/Theora Q10 61MB The Xvid file was made using mencoder by 2 passes with following options:

Hi I read in http://grahammitchell.net/writings/vorbis_intro.html > Ogg Vorbis files support "bitrate peeling", which means you can produce > a lower bitrate file from a higher bitrate file without re-encoding and > at the same quality as if you'd encoded the file directly into the lower > bitrate from the original file. No other lossy audio codec currently > supports

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

Hello everyone. I am new to R, so please bear with me. I am trying to find an easy way to export descriptive statistics and other information about my data frame to a LaTeX format. I have found the describe function in PrettyR to be very helpful in producing results in the exact format I'm looking for. However, the value of the describe function is a LIST (rather than a data frame) which I

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