Hi, I have a newbie question, and a not-so-newbie one. I've just found out about Ogg, and I haven't been able to find a clear answer in the many webpages this proyect has (btw, why not create just one site instead of vorbis.com, ogg-vorbis.com...). The question is, does Ogg use perceptual coding, like mp3 does? And if so, would it be possible to build an encoder in such a way as to take one input stream and make it produce 2 different files? One file encoded at 64kb, and the other file with the information dropped from the stream that would have made the resulting encoded stream 128kb? What I mean is a way to produce 2 64kb files which could be somehow "added up" on the decoder to produce a 128kb stream. Is there a name for this kind of thing, or have I just made it up? I hope I've made myself clear enough, but if not just say so and I'll try to explain better. TIA, Alex --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.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.
"Alex Iribarren" <ogg@iribarren.com> wrote:> The question is, does Ogg use perceptual coding, like mp3 does? AndYes Ogg Vorbis is a perceptual codec.> if so, would it be possible to build an encoder in such a way as > to take one input stream and make it produce 2 different files? One > file encoded at 64kb, and the other file with the information dropped > from the stream that would have made the resulting encoded stream > 128kb? What I mean is a way to produce 2 64kb files which could be > somehow "added up" on the decoder to produce a 128kb stream. Is there > a name for this kind of thing, or have I just made it up?Ogg Vorbis supports bitrate peeling - thist means that if you have, for example a 256kbps file, you can create a 128kbps file *without* re-encoding (decoding to WAV and then encoding again at 128kbps). I think that this feature doesn't exist in any other codec. :-) There is no point in having two 64kbps streams, because using bitrate peeling you can quickly create one 64kbps from 128kbps. Bitrate peeling should be fully functional in the next release (I think it already is in the CVS). --- Aleksandar @ Vorbis Xtreme | http://solair.eunet.yu/~aldov Ogg Vorbis is the free, open source alternative to MP3 --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.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.
At 12:57 PM 6/5/01 +0200, you wrote:>Hi, >I have a newbie question, and a not-so-newbie one. I've just found >out about Ogg, and I haven't been able to find a clear answer in >the many webpages this proyect has (btw, why not create just one >site instead of vorbis.com, ogg-vorbis.com...).There are only two websites - the main one at vorbis.com, and the developer one at www.xiph.org/ogg/vorbis.>The question is, does Ogg use perceptual coding, like mp3 does? AndYes, it's a perceptual codec.>if so, would it be possible to build an encoder in such a way as >to take one input stream and make it produce 2 different files? One >file encoded at 64kb, and the other file with the information dropped >from the stream that would have made the resulting encoded stream >128kb? What I mean is a way to produce 2 64kb files which could be >somehow "added up" on the decoder to produce a 128kb stream. Is there >a name for this kind of thing, or have I just made it up? >I hope I've made myself clear enough, but if not just say so and >I'll try to explain better.Your question isn't entirely clear. However.... Vorbis has a feature called 'bitrate peeling' (note that there aren't any tools to do this currently, but the format itself is capable). This would allow you to encode a 128 kbps stream, and either decode that as-is, or 'peel' it to lower bitrates. So you could produce (without having to reencode) a 64 kbps stream from this. Michael --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.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.
"Aleksandar Dovnikovic" <aldov@EUnet.yu> wrote:> > There is no point in having two 64kbps streams, because using > bitrate peeling you can quickly create one 64kbps from 128kbps. >There is a point. Right now, when someone wants to stream audio, they usually have to encode it at differens qualities and offer several broadcasts to suit all users (broadband, modem, etc.). However, my thinking goes as follows. What if you could produce several streams out of one, in such a way that they all complemented each other? Say, for example that you could break up a 128kbps broadcast into 4 32kb streams. A user on the client side with a slow connection could connect to 2 of the streams for the maximum audio quality allowed by his connection, while some one with a DSL connection could use all 4 streams and recieve the broadcast at 128kbps. Furthermore, the process of conecting and disconecting from the 4 streams could be automated on the client side. Say I have a double channel ISDN line, and I'm listening to an internet radio station that uses this system. While surfing, the client (say, WinAmp, for example) could be connected to all 4 streams, so I listen to the radio at 128kbps quality. However, when I start to download a file and my bandwith gets divided between surfing, downloading and playing music, WinAmp could drop one of the streams to reduce the bandwith usage, and therefore the quality, to 96kb. This compares to the present buffered stream system in that the music would not skip, the quality would simply be reduced. Personally, I hate it when my music skips and to avoid it I am forced to listen to low-quality music even if the rest of the bandwidth of my connection is being wasted. Dado Colussi explained the other part of the idea very well:>Assume you're streaming a 128kbps stream in two different >streams suggested: one base 64kbps stream and the other >64kbps add-on stream. Someone capable of receiving only >64kbps would catch the base stream. Someone else capable >of receiving all of it, would catch the add-on stream >too, and decode them as one virtual 128kbps stream.>I can see benefits of this kind of technique in >multicasting: as a multicaster you would have to send >only 128kbps *total*, instead of 128 + 64. You would >still reach narrowband users and satisfy broadband >users without sending "massively" redundant data.--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.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.
Before I start, I just want to say that I know very little about audio compression or signal analysis. And I have no clue what a Lorentzian is, but I guess it must be some way of mesuring a signal. How is nonlinear compression done? If I have understood correctly both of Dr. Joerg Bergmann's messages, the technique I have suggested is impossible because there is no redundancy in a 128kbps stream and a 64kbps one, meaning that you can't extract the extra data from the 128kbps stream to reduce it to 64kbps. Is this actually true? However, if that is not possible, perhaps you can overcome the nonlinearity problem by splitting the streams before actually compressing them nonlinearly. When reducing redundancies in the sound file to encode, and when applying the perceptual filters, you could apply them in different degrees to both streams (lots of filtering for the 64kbps stream, and half the filtering for the 128kbps stream). After that, you could "substract" the 64kb stream from the 128kb one to obtain the 64kb of sound that was filtered from the original 64kb stream. Then you would actually do all the rest of the compression.> > But such thinking is invalid for nonlinear mechanisms. > I will give an explanation from my science: > Given any curve, I may fit it with a set of 5 Lorentzians > or, for more accuracy, with 10 Lorentzians. Doing so, the > resulting 10 Lorentzians _wont_ include the less accurate > 5 Lorentzians as a subset! Of course, you may construct > such a fit, but it will waste accuracy (or, in ogg: > bandwidth for the same quality). > > J"org Bergmann > email@jbergmann.deAs to what Kristoff Bonne <kristoff.bonne@skypro.be> said, I think that would simply be a matter of syncronizing the streams through buffering, not much more difficult that what is actually done now with webcasts.>Two remarks (to continue this brainstorming-session): >- One of the things you should take care of; is that both 'streams'should>have the same bitrate (or a bitrate that does not vary to much vis-a-vis>eachother). > >What I mean is this: >If the 2nd session that is started is an (additional) TCP-session;you'll>have to deal with the 'slow start'; having a quite varied bitrateat the>start of the session.--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.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.
Isn't ogg capable of cbr encoding? I thought that right now the cbr codec wasn't done, but that it would be done by version 1.0. ----- Original Message ----- From: "Merijn Vogel" <merijnv@sci.kun.nl> To: <vorbis@xiph.org> Sent: Wednesday, June 06, 2001 1:19 PM Subject: Re: [vorbis] [new?] Streaming technique> One of the problems is that ogg is an vbr-codec, the targets of theencoder> are `approximately 128kbit' and `approx 256kbit', not constantbitrates.> > The coder could make different decisions about the blocksizes,the bitrate> per block, etc. The blocks have a bit of overlap, I think it would berather> hard to do, and it could be easier to peel or to distribute different > streams.. > > just my 2 pennies, > > -- Merijn--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.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.