similar to: RFC draft for Vorbis over RTP

Hi all, Below is the Vorbis RTP Internet Draft as sent to the AVT working group of the IETF. Comments and feedback is still welcomed from the Vorbis community. Cheers Phil ---------------------------8<-----------------8<------------------------ Network Working Group Phil Kerr Internet-Draft The Ogg Vorbis January 07, 2003 Community / OpenDrama

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/

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 again, after the discussion the last few days, I started doing some coding and first of all have a first very simple, quick and dirty demo client: http://www.j-ogg.de/rtp/index.html During the coding, I've run into a few problems: - I was planning to replace the identification header with appropriate entries in the SDP descriptor. However, the frame sizes are defined here (why not in

Hi all, Apologies in advance, this email is quite long. I've prepared an updated Vorbis RTP Internet Draft, which is a continuation of draft-moffitt-vorbis-rtp-00.txt which can be found below. If this new draft gets the ok I'd like to submit this to the AVT WG later this week. There are a number of changes over the original I-D, notably the changing of the M bit function in the RTP

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

Hi there In the past, i have used lame to encode high quality mp3-files (vbr 1, bitrate ~ 192kbit). I tend to switch to ogg with Quality 4 or 5, but i noticed, that many ogg-files tend to produce too much high frequencies response. In many cases, this is very noticeable. For my opinion, i cannot accept this worse frequence reponse. I have used latest version of ogg (OggEnc v1.0, precompiled

Hi there In the past, i have used lame to encode high quality mp3-files (vbr 1, bitrate ~ 192kbit). I tend to switch to ogg with Quality 4 or 5, but i noticed, that many ogg-files tend to produce too much high frequencies response. In many cases, this is very noticeable. For my opinion, i cannot accept this worse frequence reponse. I have used latest version of ogg (OggEnc v1.0, precompiled

Hi Jean-Marc, Alfred and Greg, Are you receiving the mails from IETF about draft-ietf-avt-rtp-speex The mails are not coming from AVT mailing list, but I think we are all 3 part of a minimal list (draft-ietf-avt-rtp-speex at tools.ietf.org) dedicated to latest discussion about the draft. I have answered some questions, but there are small changes and adaptation still required to the ietf

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

Hi All, Please find below an updated Vorbis-RTP Internet Draft document for review and discussion at the Xiph IRC meeting on Saturday. The changes in this version have been: Codebook caching mechanism Expanded SDP parameters Expanded MIME section Expanded introduction Packet loss section Minor tweaks and clarity changes to text There are probably some minor tweaks to the formatting needed

Hi. I got bored of writing papers last week so I decided to write an app for sending and receiving multicast vorbis streams over RTP. A first version is available here: http://www.cdt.luth.se/~rolle/vorbis/ (I use the JOrbis decoder, so you need Java 2 with Javasound, e.g. JDK1.3. Since the decoding is done in Java, you probably need at least 300-350 MHz. Works with the IBM JDK1.3 on Linux on a

Hi. I got bored of writing papers last week so I decided to write an app for sending and receiving multicast vorbis streams over RTP. A first version is available here: http://www.cdt.luth.se/~rolle/vorbis/ (I use the JOrbis decoder, so you need Java 2 with Javasound, e.g. JDK1.3. Since the decoding is done in Java, you probably need at least 300-350 MHz. Works with the IBM JDK1.3 on Linux on a

http://www.xiph.org/ogg/vorbis/doc/draft-moffitt-vorbis-rtp-00.txt This is the Internet-Draft I'll be submitting tomorrow and hopefully presenting at the March IETF meeting. If you see anything major, let me know right away, I'll be submitting this in the morning. jack. --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To

Hello again! As promised, here's a completed package of OggSplit. It's configured with autoconf and automake (use autogen.sh) and there are debian build rules. In it's current state it's quite useable, although there are certain internal things which could be improved (nothing critical however). There are of course bugs, so I encourage everyone to try breaking the tool with

Do not forget to add the "Copying conditions" to the RFC. Check http://wiki.debian.org/NonFreeIETFDocuments That page contains a section titled "Template for RFC authors to release additional rights". To follow that guideline a section like the following should be added: x. Copying conditions The author(s) agree to grant third parties the irrevocable right to

alpha. (that about sums it up) Will encode and play back via an sdp file and multicast on one computer (over the net if you transfer the sdp file over by hand). rc/rtenc3 and src/rtdec3 are in the style of encoder/decoder_example ...so this means you MUST edit it them to suit your system. For example, I specify my rtenc3 to multicast just on eth1 (to avoid pissing off my cable supplier on

Hi, I've found some more errors in the file format specification (or at least points, where the specification and actual libvorbis implementation mismatch): - Floor 1 / curve computation / step 1: amplitude value synthesis 21) vector [floor1_final_Y] element [i] = [predicted] - (([val] - 1) divided by 2 using integer division) hould be: 21) vector [floor1_final_Y] element [i] =

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