similar to: Re: Ogg Spec, etc.

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

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:

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

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

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

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

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

Torsdag, 10 oktober 2002, skrev du: >On the other hand, it's certainly possible that the published >specification contains errors that need to be addressed. It is not a >monolithic document written in stone. The only way we'll really be able >to sort those issues out is when people try to build stuff from scratch >using the published data, and come across discrepancies.

> And as long as the spec contains errors, it makes no sense at all > as Moritz did to claim, that everyone is free to implement their > own encoder or decoder, or as Jon did to claim that the file format > is documented. Actually, people have implemented perfectly valid Vorbis encoders and decoders before the specification was even published. I wouldn't go so far as to call other

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

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

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/

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

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

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