similar to: Changes to Ogg format IETF I-D

Hi all, just letting you know that I am about to submit the final version of the Ogg 1.0 file format Internet-Draft to the IETF. It is due by today (March 3, Monday - Internet Draft final submission cut-off at 09:00 ET) for the next IETF meeting and I expect they will promote it to RFC status at the meeting. Please send any last-minute changes to me. Cheers, Silvia. <p><p>

Hi all, just letting you know that I am about to submit the final version of the Ogg 1.0 file format Internet-Draft to the IETF. It is due by today (March 3, Monday - Internet Draft final submission cut-off at 09:00 ET) for the next IETF meeting and I expect they will promote it to RFC status at the meeting. Please send any last-minute changes to me. Cheers, Silvia. <p><p>

Hi John, all, I still have at least 3 issues: 1) What are we trying to achieve with the "source-ID"? 8 [uint] Source ID (Unique amongst all OggPCM streams in the physical stream) Are we trying to separate the different channels that may be interleaved with each other inside the flat multi-channel sample stream? Interpretation 1: ----------------- So, would each channel be in a

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

On Wed, Aug 13, 2008 at 3:05 AM, ogg.k.ogg.k at googlemail.com wrote: > And that's the canonical way AFAIK. Comparing times computed from > the granpos you get from pages you get from a bsearch requires good > knowledge of the codec, whereas comparing granpos can seek within > any codec. No. it's in general impossible to calculate the granulepos that corresponds to a

Good day, FYI, I've just sent the attached email to IETF to progress our I-Ds. There are also links to updated documents in this email. Cheers, Silvia. -------- Original Message -------- Subject: New I-Ds for Ogg technologies (Vorbis over RTP, Ogg file format, Mimetypes) Date: Sun, 12 Jan 2003 01:36:31 +1100 From: Silvia Pfeiffer <Silvia.Pfeiffer@csiro.au> Organization: CSIRO To: AVT

Good day, FYI, I've just sent the attached email to IETF to progress our I-Ds. There are also links to updated documents in this email. Cheers, Silvia. -------- Original Message -------- Subject: New I-Ds for Ogg technologies (Vorbis over RTP, Ogg file format, Mimetypes) Date: Sun, 12 Jan 2003 01:36:31 +1100 From: Silvia Pfeiffer <Silvia.Pfeiffer@csiro.au> Organization: CSIRO To: AVT

Hello all, my name is Mathias, I'd like to ask about some details of the OGG format because I'm quite new to it. I'd like to write a native .NET library for reading and writing Vorbis comments. It's going to be open-sourced as soon as it's finished. So here it goes: 1) When packing (Vorbis) packets to OGG pages, does a new packet always begin on a fresh OGG page? Within the

Hello, I recently added discontinuous stream support to libogg1. The patch is attached. I also wrote Writ codec for libogg1 (based on original code by Arc), and sample Writ encoder (SubRip to Writ converter) and decoder. Is anybody interested? WBR, Roman. -------------- next part -------------- Index: include/ogg/ogg.h =================================================================== ---

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 all, Please find below an I-D for the proposed registration of MIME type audio/rtp-vorbis. All comments most welcome. Barry <p>-----------8<------------- Network Working Group Barry Short Internet-Draft The Ogg Vorbis Community / OpenDrama Expires: July 7, 2003 January 7, 2003 <p>

Hi, I was wondering what oggz_get_bos and oggz_get_eos are supposed to do, specifically are they meant to be used in oggz_read mode? The documentation says "Determine if a given logical bitstream is at [bos/eos]". However if get_bos is given a specific serialno it returns that stream's b_o_s flag which, in read mode, is set on initialisation. The serialno=-1 (for all streams)

Another spin-off discussion. The scheme used on <http://wiki.xiph.org/index.php/Metadata> was to packetize XML (split it up into packets at the root level, each of which was self contained (the terminology has temporarily abandoned me), and have the bos packet as the opening <?xml &c. stanza, the eos a </xml>. It is probably more sensible to include a magic number identifying

I suggest using the solution that CMML has come to use. The XML file is essentially the same as an unencapsulated physical bitstream. Then there is a mapping into a logical bitstream, where some of the default information - in particular the XML header - are split off and put into the bos packet - nothing really needs to go into the eos packet. There's also a magic number and a version

Hello Tim I am referring to the following file https://en.wikipedia.org/wiki/File:Sample_of_%22Another_Day_in_Paradise%22.ogg I opened the file in a HEX editor. I do not see the string OpusHead in the packet. It starts with Oggs. Also checking the occurrence of Oggs, I see that the first packet has BOS, the next all (except last) have 00 (which is not defined in the RFC as continuation) and

HOgg 0.4.0 Released ------------------- The HOgg package provides a commandline tool for manipulating Ogg files, and a corresponding Haskell library. HOgg is in hackage, or on the web at: http://www.kfish.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

Silvia Pfeiffer wrote: > Daniel, > > before you step over everything that has been done before, we need to > determine what exactly is the use case for your new specification. > > What concerns metadata, we currently have: > > * vorbiscomment - this is a header at the beginning of a logical > bitstream which has metadata that refers to the complete file; there > is

I've been looking at modifying vcedit so it will work on Ogg streams containing primarily Vorbis data (i.e. first page is the Vorbis header, most pages are Vorbis and a few are something else e.g. metadata or lyrics). I've managed to get something that works by: 1. During the header opening in vcedit_open push non-Vorbis pages onto a buffer added to vcedit_state and write them out after

I'm having trouble getting libvorbis to cut the beginning of a bitstream when I instruct it to do so with granulepos. I have constructed a file which I believe should have its beginning truncated. I have attached it to this mail. Here is a picture of what the bitstream looks like, as output by a python program that uses pyogg/pyvorbis to read the stream and print a representation: