similar to: RC4/1.0 and peeling

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/

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

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

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

question: would it be possible to mess around with icecast2s' relay ability to kind of cheat a peelable streaming thing? eg: client needs a bitrate lower than what is available, client tells server this, server relays to itself, or other available server, at a required bitrate, server forwards new stream info to client and so on. <p>--- >8 ---- List archives:

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

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

Hello all, I have recently ported Vorbis to a Texas instruments DSP (TMS320C5510), The problem I have is that it is not decoding the audio in real time( about 50% of real time). Could any one give me a clue in which area I could start to optimize the code. Regards Kevin <p><p><p>--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage:

Hello everyone, I am running Ubuntu and have converted my CDs to FLACs (using all the paranoia and fixing all the tags etc.). What is the best way for me to convert all of those FLAC to ogg-Vorbis files, keeping all the tag information and the same directory structure? I am not wanting anything incredibly advanced, but was expecting something like vorbconvert /media/cd_rom/ /home/aaron/vorbis/

Hello everyone, I am running Ubuntu and have converted my CDs to FLACs (using all the paranoia and fixing all the tags etc.). What is the best way for me to convert all of those FLAC to ogg-Vorbis files, keeping all the tag information and the same directory structure? I am not wanting anything incredibly advanced, but was expecting something like vorbconvert /media/cd_rom/ /home/aaron/vorbis/

> From: Beni Cherniavsky [mailto:cben@users.sf.net] > Sent: 26 September 2003 10:35 > To: vorbis@xiph.org > Subject: Re: [vorbis] streaming > > - Vorbis is designed to allow "peeling": if you truncate packets, you > still get a legal Vorbis stream but with lower quality. This should > allow very effecient streaming of multiple bitrates from the same >

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,

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

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

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

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

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

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