search for: rfc3533

...rg/~conrad/software/hogg/ This is the fourth public release. The focus is on correctness of Ogg parsing, production and editing. The capabilities of the hogg commandline tool are roughly on par with those of the oggz* [0] tools. HOgg supports chained and multiplexed Ogg bitstreams conformant with RFC3533[1]. HOgg can parse headers for CELT, CMML, FLAC, OggPCM, Speex, Theora and Vorbis media codecs, and can read and write Ogg Skeleton bitstreams. [0] Oggz: http://www.annodex.net/software/liboggz/index.html [1] RFC3533: http://www.ietf.org/rfc/rfc3533.txt New in this release ------------------- T...

On 15/03/07, Ralph Giles <giles@xiph.org> wrote: > On Wed, Mar 14, 2007 at 12:23:47PM +0000, Mathias Kunter wrote: > > > > In contrast to that, http://www.ietf.org/rfc/rfc3533.txt stats the following: > > "Ogg Vorbis provides the name and revision of the Vorbis codec, > > the audio rate and the audio quality on the Ogg Vorbis bos page. > > It also uses TWO additional header pages per logical bitstream."Sounds like ogg would ALWAYS use a total...

...er is fixed, this even is a fixed offset into the logical ogg stream. The spec now further stats that the comment and setup headers can together span >= 1 pages. So does this also mean that the comment header itself can be split over different pages? In contrast to that, http://www.ietf.org/rfc/rfc3533.txt stats the following: "Ogg Vorbis provides the name and revision of the Vorbis codec, the audio rate and the audio quality on the Ogg Vorbis bos page. It also uses TWO additional header pages per logical bitstream."Sounds like ogg would ALWAYS use a total of three header PAGES for its...

Hi John, I'm forwarding this email to the relevant developer lists at Xiph.Org, where the format was created and where the experts gather. I'm certain there is a design reason for putting the bos pages of all logical bitstreams together at the start. My guess is that with digital media you usually have a delay time for setting up the decoders for a specific format and by clustering

Hi John, I'm forwarding this email to the relevant developer lists at Xiph.Org, where the format was created and where the experts gather. I'm certain there is a design reason for putting the bos pages of all logical bitstreams together at the start. My guess is that with digital media you usually have a delay time for setting up the decoders for a specific format and by clustering

...org/~conrad/software/hogg/ This is the fifth public release. The focus is on correctness of Ogg parsing, production and editing. The capabilities of the hogg commandline tool are roughly on par with those of the oggz* [0] tools. HOgg supports chained and multiplexed Ogg bitstreams conformant with RFC3533[1]. HOgg can parse headers for CELT, CMML, FLAC, OggPCM, Speex, Theora and Vorbis media codecs, and can read and write Ogg Skeleton bitstreams. [0] Oggz: http://www.annodex.net/software/liboggz/index.html [1] RFC3533: http://www.ietf.org/rfc/rfc3533.txt New in this release ------------------- T...

...t; This is the fourth public release. The focus is on correctness of Ogg > parsing, production and editing. The capabilities of the hogg commandline > tool are roughly on par with those of the oggz* [0] tools. > > HOgg supports chained and multiplexed Ogg bitstreams conformant with > RFC3533[1]. HOgg can parse headers for CELT, CMML, FLAC, OggPCM, Speex, Theora > and Vorbis media codecs, and can read and write Ogg Skeleton bitstreams. > > [0] Oggz: http://www.annodex.net/software/liboggz/index.html > [1] RFC3533: http://www.ietf.org/rfc/rfc3533.txt > > > New in thi...

...ase. The focus is on correctness of Ogg parsing and production. The capabilities of the hogg commandline tool are roughly on par with those of the oggz* tools[0], although hogg does not yet provide an equivalent to oggz-validate. HOgg supports chained and multiplexed Ogg bitstreams conformant with RFC3533[1]. HOgg can parse headers for CMML, FLAC, OggPCM, Speex, Theora and Vorbis media codecs, and can read and write Ogg Skeleton bitstreams. [0] Oggz: http://www.annodex.net/software/liboggz/index.html [1] RFC3533: http://www.ietf.org/rfc/rfc3533.txt Installation ------------ I am very interested i...

...commandline tool are roughly on par with those of the oggz* [0] tools. Although hogg does not yet provide an equivalent to oggz-validate, it has subcommands for chopping out a section of a file, and for adding skeleton metadata. HOgg supports chained and multiplexed Ogg bitstreams conformant with RFC3533[1]. HOgg can parse headers for CMML, FLAC, OggPCM, Speex, Theora and Vorbis media codecs, and can read and write Ogg Skeleton bitstreams. [0] Oggz: http://www.annodex.net/software/liboggz/index.html [1] RFC3533: http://www.ietf.org/rfc/rfc3533.txt New in this release ------------------- The hog...

...commandline tool are roughly on par with those of the oggz* [0] tools. Although hogg does not yet provide an equivalent to oggz-validate, it has subcommands for chopping out a section of a file, and for adding skeleton metadata. HOgg supports chained and multiplexed Ogg bitstreams conformant with RFC3533[1]. HOgg can parse headers for CMML, FLAC, OggPCM, Speex, Theora and Vorbis media codecs, and can read and write Ogg Skeleton bitstreams. [0] Oggz: http://www.annodex.net/software/liboggz/index.html [1] RFC3533: http://www.ietf.org/rfc/rfc3533.txt New in this release ------------------- The hog...

...org/~conrad/software/hogg/ This is the third public release. The focus is on correctness of Ogg parsing, production and editing. The capabilities of the hogg commandline tool are roughly on par with those of the oggz* [0] tools. HOgg supports chained and multiplexed Ogg bitstreams conformant with RFC3533[1]. HOgg can parse headers for CELT, CMML, FLAC, OggPCM, Speex, Theora and Vorbis media codecs, and can read and write Ogg Skeleton bitstreams. [0] Oggz: http://www.annodex.net/software/liboggz/index.html [1] RFC3533: http://www.ietf.org/rfc/rfc3533.txt New in this release ------------------- T...

On 3/15/07, Conrad Parker <conrad@metadecks.org> wrote: > On 15/03/07, Ralph Giles <giles@xiph.org> wrote: > > On Wed, Mar 14, 2007 at 12:23:47PM +0000, Mathias Kunter wrote: > > > > > > In contrast to that, http://www.ietf.org/rfc/rfc3533.txt stats the following: > > > "Ogg Vorbis provides the name and revision of the Vorbis codec, > > > the audio rate and the audio quality on the Ogg Vorbis bos page. > > > It also uses TWO additional header pages per logical bitstream."Sounds like ogg would ALWA...

Hi, I'm writing a little API in java that read/write ogg's comments (in the comment header), as well as reading the information header. All the "read" part is done and is working well, but I am having a little problem while coding the "write" part of the API. In the docs (I use http://www.xiph.org/ogg/vorbis/doc/Vorbis_I_spec.html#id4726648), I founded everything

...good answer. Let me just double-check one thing: > To put multiple Ogg Opus packets in an Ogg page, all you need to do is > start a new segment for each Ogg Opus packet. There can be up to 255 > segments per page. For details, see the Ogg specification: > https://tools.ietf.org/html/rfc3533 So do I understand it correctly that a decoder will interpret a page that contains multiple segments, each less than 255 bytes as a set of opus packages, each with the length determined by the specified segment length? And just to be absolutely certain: If I happen to have opus packets that are m...

Hi. I am trying to understand how to package opus-encoded data in an ogg stream to make a standards-compilant ogg/opus file. Most things are clear, but there is one thing I simply do not understand. What I do understand is that Ogg is based on pages, that each come with a fairly sizeable header (>=27 bytes). Now, I encode with a fairly low bitrate, so my opus packages are <100 bytes long.

Hi all, I am a developer for embedded system and totally new to Opus and open source audio codec. I'm now using Microchip dsPIC33 to develop a decoder for Opus. I am now using sources of libopus. The first question is for calling opus_decode(), do I need to skip the header bytes of an opus file before I can input the file data to opus_decode()? Or will libopus handle this automatically?

..../configure ; make ?&& make check && make install ; ?ls /usr/share/doc/libogg-1.3.1 ?; fish_xiph_org.png ?index.html ?multiplex1.png ? ? ?oggstream.html ?pages.png ? ?rfc5334.txt ? ?stream.png ? ? ? white-ogg.png framing.html ? ? ? libogg ? ? ?ogg-multiplex.html ?packets.png ? ? rfc3533.txt ?skeleton.html ?vorbisword2.png ?white-xifish.png ls ? /usr/include/ogg ; config_types.h ?ogg.h ?os_types.h ?ls -lR ?/usr ?| grep ?'/ogg' ?; /usr/include/ogg: /usr/local/include/ogg: /usr/local/share/doc/libogg-1.3.0/ogg: ?curl ? http://downloads.xiph.org/releases/opus/opus-tools-0....

...pages is allowed to be the same, ie. whether or not granulepos must be strictly increasing. As this question is more generally about Ogg granulepos, how about we answer it first and then get back to the discussion of Kate's granulepos ... Here is what some documents have to say: * Neither RFC3533 or http://www.xiph.org/ogg/doc/framing.html clarify this. * The seeking algorithm suggested in the (troublesome) email quoted at http://wiki.xiph.org/index.php/GranulePosAndSeeking is "find the earliest page with a granulepos less than but closest to 'x'" should be able to hand...

...tely. The vorbis spec allows the comment packet to be up to 18446744078004518921 bytes long. Of course it would be silly to use all of that, but if someone stuffs liner notes or cover art in there, it could easily be over the normal 4k page size. > In contrast to that, http://www.ietf.org/rfc/rfc3533.txt stats the following: > "Ogg Vorbis provides the name and revision of the Vorbis codec, > the audio rate and the audio quality on the Ogg Vorbis bos page. > It also uses TWO additional header pages per logical bitstream."Sounds like ogg would ALWAYS use a total of three header...

...53,255] That list specifies the segment lengths. I would have expected the eos to refer to the same packet that the granulepos refers to, ie. the segment of length 1653. However, when later reading this file via libogg, no packets in that track are marked as eos, and hence it fails oggz-validate. RFC3533 and framing.html both simply say: header_type_flag bit 0x04: set: this is the last page of a logical bitstream (eos) Is this a bug in libogg (should it assign eos to the last completed packet on the page marked eos), or in the specification (should it say that the last page must not contain any in...