similar to: Bitrate Peeling? (again)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello vorbis, Is bitrate peeling implemented into RC3? (i'm guessing not due to the fact that none of the tools seem to have any information about that) Still, looking forward to checking out the quality improvments (once the Debian packages become available... (i've compiled it already on one of my potato boxes, but the newer

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello vorbis, uhmm... i've just installed the RC3 packages (for debian, but i'm pretty sure it's not going to matter what linux (or even *nix) you use) and the man pages for "oggenc" still says "release candidate 2" up the top of the man page. This should possibly be checked next time <grins>. The rest of

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

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

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

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

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

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

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:

Hello, I have a problem with the timing of effects. I do have a tag (with id: post1). When the link is clicked, the block "post1" must BlindUp. Then the block is updated with the new content and then the effect BlindDown is executed. Below is the source code of the link_to_remote I am using. <%= link_to_remote("Ajax Edit", :update =>

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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello vorbis, I know that hipzip/Dadio support was planned - does anyone have any idea what the status of this is due to iomega's discontinuing of the Hipzip product line? Is there any way we can add ogg support to our hipzip's in the future if Interactive Objects adds it to Dadio ? - -- Best regards, Brendan

Hello I'm trying to setup samba/linux file server , with authentification made by Netscape directory server. The steps I follow: 1 Installing Netscape DS , for now de directory server in empty . the only users are : admin and manager each one has his passwd. 2 Installing Samba2.2.8a (--with-ldapsam support) 3 modifiying smb.conf to [global] ldap server =

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

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

Fun, fun. I suggest checking the corresponding MTA configuration :) Return-Path: <David.Bear@asu.edu> Delivered-To: rohrbach@mail.webmonster.de Received: (qmail 56434 invoked by uid 801); 24 Sep 2004 15:51:37 -0000 Delivered-To: vrohrbach-karsten@rohrbach.de Received: (qmail 56429 invoked from network); 24 Sep 2004 15:51:36 -0000 Received: from post5.inre.asu.edu (129.219.110.120) by

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