similar to: Demultiplexer API with a static number of streams

Torsdag, 23 januar 2003, skrev Tor-Einar Jarnbjo <Tor-Einar_Jarnbjo@grosch- link.de>: >According to the format description, the coding method has to be 0. > >I've been using libFLAC 1.0.4 to encode the stream. I've checked my interpretation against "flac -a" and it seems to read 17 bits for each warmup sample. Here is its output: frame=168 blocksize=4608

Torsdag, 23 januar 2003, skrev Miroslav Lichvar <lichvarm@phoenix. inf.upol.cz>: >If input is 16 bit, side channel will be 17 bit (16bit - 16bit is >17bit number). And warmup samples will be (17 - wasted_bits) bit. Voila, this was the source of all my frustration, sync problems and who knows what. My decoder now works correctly for files encoded with the default settings. Are

Hi! I don't find any detailed information about this in the specification, so I try a question here. If two plain, unmultiplexed Ogg/Vorbis-files are chained into one file, you end up with an Ogg-file with two logical Vorbis streams. When playing this file, would it be correct for a decoder to synchronize the two streams according to the granule position of the Ogg pages (playing them

Torsdag, 23 januar 2003, skrev "Tor-Einar Jarnbjo" <Tor-Einar_Jarnbjo@grosch- link.de>: >- My implementation seems to decode fixed subframes now, but the lpc >subframes contains nothing but noise, and the bitstream is out of sync after >reading one. The source code I'm using for decoding the lpc subframe is >available here:

> -----Ursprungliche Nachricht----- > Von: Josh Coalson > > --- Tor-Einar Jarnbjo <Tor-Einar_Jarnbjo@grosch-link.de> wrote: > > Hi, > > > > have I just overseen a link, or is the format description on > > http://flac.sourceforge.net/format.html lacking information on how to > > actually decode the residual partitions to PCM sample data? > > you

The IETF passed the application/ogg MIME type some days ago. I couldn't bring you the news earlier because of the MS SQL worm that has been wreaking havoc all over my local networks. The IETF wants some clarifications in Silivias draft for the Ogg stream format, but apart from that I think it will also be passed soon. The RFC and IANA registration of this mimetype will probably be published

Hi, have I just overseen a link, or is the format description on http://flac.sourceforge.net/format.html lacking information on how to actually decode the residual partitions to PCM sample data? Tor

--- Tor-Einar Jarnbjo <Tor-Einar_Jarnbjo@grosch-link.de> wrote: > > -----Ursprungliche Nachricht----- > > Von: Josh Coalson > > > > --- Tor-Einar Jarnbjo <Tor-Einar_Jarnbjo@grosch-link.de> wrote: > > > Hi, > > > > > > have I just overseen a link, or is the format description on > > > http://flac.sourceforge.net/format.html

Fredag, 3 januar 2003, skrev du: >Ogg has always appeared to me to correspond only to the _track media_ >and _sample_ layers of a QuickTime movie. So you still need to know >what all the CODECs are and how to use them individually to >manipulate what should be general data in the file. Please, somebody >correct me if I'm wrong. I have asked the same questions here on the

Hi, I am trying to implement a Vorbis decoder in Java, and I have some problems understanding the file-format specification included with libvorbis. In the header description, there are a few obvious mistakes, which I believe to have solved, but when I try to decode the audio packets, the decoded floor and residue data doesn't seem to make sense at all, and after a few packets, my decoder

Mandag, 2 juni 2003, skrev du: >On Mon, 02 Jun 2003 21:22, Vitaly Nechyos wrote: >This is what people usually want when they say 'normalization'. AFAIK, you >can't easily tinker with the vorbis frames to add a scale factor in the same >way you can with MP3, but I could be wrong. I could be wrong too, but if I haven't overseen anything, it should be possible to

--- Tor-Einar Jarnbjo <Tor-Einar_Jarnbjo@grosch-link.de> wrote: > Torsdag, 23 januar 2003, skrev Miroslav Lichvar <lichvarm@phoenix. > inf.upol.cz>: > > >If input is 16 bit, side channel will be 17 bit (16bit - 16bit is > >17bit number). And warmup samples will be (17 - wasted_bits) bit. > > Voila, this was the source of all my frustration, sync problems

> -----Ursprungliche Nachricht----- > Von: Josh Coalson > > Miroslav's suggestion is the best right now. I probably should > hand-craft a stream that exercises a decoder as much as possible. I've already tested my decoder with the options -0 to -8 and it works, but the streams doesn't contain any verbatim or constant subframes. I guess this depends heavily on the input

Hi, is there an error in the last part of the algorithm describing how to read a floor1 header? According to point 18 and 19, the vector [floor1_class_dimensions] must have at least [floor1_partitions] elements, but when reading/computing these two values on the beginning of the header, they are not related to eachother, and my attempts to apply this algorithm to real ogg-files gives me

Fredag, 11 oktober 2002, skrev du: >Rubbish. Been there, done that (multiple times). Look at rehuff, for >example; written without looking at libvorbis (nor at the spec). And you wrote that without any knowledge about the file format? Tor <p><p>=================================================================== EASY and FREE access to your email anywhere:

Hi, it seems to me as if all vorbis-files only contain floors of type 1 and residues of type 2. Is it possible to "force" the encoder to somehow create a vorbis-file with the other floor and residue types? Tor <p><p><p>=================================================================== EASY and FREE access to your email anywhere: http://Mailreader.com/

Fredag, 31 januar 2003, skrev du: <p>>Next thing is, that I would like to clarify the difference between a codec's >latency (which I would die to know in exact figures for the vorbis codec one >day - as well as block sizes, but that's another story) and the (bandwidth) >"smoothing window" latency - call it buffering or whatever. One thing is the codec

Hi, There is something I don't understand about the page_segment and segment_table values in the documentation. As I understand it, the segment table consist of as many bytes as specified in page_segment, PLUS one trailing byte with a value between 0 and 254. I've looked at some files that has a Comment tag so large, that it is spread over two pages. Here, the first Page Header (not the

Hi, as Conrad suggested, I've made a complete list of all points in the specification, which I beleive are errors, or where the explanation is unclear, contains unneccessary steps and so on. I hope someone has time to look through the points and if and when accepting or rejecting them be so very kind and inform me about it. I will also once again try to work through the residue

Hello, I would like to "piggy-back" other data in an Ogg/Vorbis I physical stream (i.e. file) in a manner that does not conflict with specifications and existing decoders/players/editors etc. As far as I can see, I have some possible choices: 1 - Chaining a logical bistream at the end. If this is the way to go, two questions arise to begin with: q1a - How to identify this stream in a