similar to: General ogg vorbis problems

during the last weeks I was playing around with Windows ACM codecs. These drivers allow the use of audio compression algorithms in Microsoft Windows Apps like Goldwave or the Microsoft Audio Tools (e.g. for streaming). At the moment this code is in a very early stage, only some houskeeping functionality is finished at the moment. But I think it should be possible to implement this thing without

Hi all, ? I have a?question about the ogg vorbis decoder.?As far as I know, there are?three?vorbis headers -- ID, Comment and Codebook. And in?ID header, I can get the sample rate, maximum bitrate, nominal bitrate and minimum bitrate. Now, I want to get the play time of the file, so I use the file length to divide the nominal bitrate, and get the play time, but it is always shorter than the real

I am trying to create a Graphical User Interface for a Vorbis Player under MS Visual C++ 6.0 I was initially trting to use the code from decoder_example.c but I keep getting linker errors. I have set up my project as told to by James Boer on this mailing list. This is as follows: This document was prepared from an email received from James Boer on the Ogg Vorbis mailing list. It gives a

Monty Montgomery wrote: > Yes. Without the first three packets (which hold all the codec > settings and all the instruction how to handle the subsequent packets) > the rest of the stream is gibberish. Vorbis can't even unpack the > bits without the codebooks packed into the third header. Curiosity man here. Is there a finite set of predetermined codebooks or is the codebook

Monty Montgomery wrote, on 7/14/2009 1:44 AM: > On Tue, Jul 14, 2009 at 1:41 AM, Erik de Castro > Lopo<mle+la at mega-nerd.com> wrote: >> Monty Montgomery wrote: >> >>> Yes. Without the first three packets (which hold all the codec >>> settings and all the instruction how to handle the subsequent packets) >>> the rest of the stream is gibberish.

Hi everybody: Here is this week's Ogg Traffic with all new updates on recent activities in the world of Xiph.org. The HTML version is up at http://www.vorbis.com/ot/20030415.html. Enjoy! -Carsten <p>Ogg Traffic for Tuesday, April 15, 2003 [1]Carsten "Purple" Haese April 15, 2003 _________________________________________________________________ Table of

--- libcelt/Makefile.am | 6 +- libcelt/bands.c | 26 +++++++++- libcelt/bands.h | 2 +- libcelt/celt.c | 23 +++----- libcelt/pgain_table.h | 133 ------------------------------------------------- libcelt/quant_pitch.c | 117 ------------------------------------------- libcelt/quant_pitch.h | 44 ---------------- 7 files changed, 37 insertions(+), 314

> > Which part? > > Well, my biggest problem is dealing with files. As you have mentioned > that fill_buffer() is obsolete, what has replaced it? ogg_sync_buffer() > didn't seem to be what I was looking for, as far as I can tell... am I > headed in completely the wrong direction? Ah, OK, I understand where you're headed now. The libvorbis API is different than

>From looking at the code, it looks like the first vorbis header in a stream is always placed in its own page. It also looks like maybe the audio data (i.e., the stuff after the headers) is maybe also supposed to begin on a new page. Is this part of the spec? I notice, though, that the second and third headers share a page, at least in one .ogg I looked at. It seems like it would be easier

The following has been committed to the Vorbis I spec as of r19445: Errata 20150226: Single entry codebooks A ?single-entry codebook? is a codebook with one active codeword entry. A single-entry codebook may be either a fully populated codebook with only one declared entry, or a sparse codebook with only one entry marked used. The Vorbis I spec provides no means to specify a codeword length of

> So if I understand correctly -- the first packet is just OggS, so that's No. The first packet is the ID header, containing information such as bitrate, sample rate, number of channels, etc. OggS is the ogg level page capture pattern. Pages encapsulate packets. > easy to replace. The second packet is the metadata, which we can lose. > It's just the third packet that needs to be

Adam Rosi-Kessel wrote, on 7/14/2009 7:55 AM: > ogg.k.ogg.k at googlemail.com wrote, on 7/14/2009 7:16 AM: >>> easy to replace. The second packet is the metadata, which we can lose. >>> It's just the third packet that needs to be reconstructed. After that, >>> you could start at any packet division in the rest of the file and it >>> would play fine? So

Hello list, We have recently introduced the codecs (optional) parameter on the Ogg media types for easier identification of encapsulated codecs in conditions were it's not feasable to examine the streams directly. I received a comment from the IESG that we should have some sort of list to describe how Ogg mapping strings translate to codec parameter strings, so I went ahead and compiled a

(crossposted to theora-dev, since I thought some folks there might be interested) Hi all, Does anyone know of a ogg based container format that would be appropriate for holding raw AV data? I'm specifically interested in PCM audio, and uncompressed YV12 and RGB32 video. Basically looking to use it as a lightweight tool interchange format, generally muxed by mencoder and read/modified by

(crossposted to theora-dev, since I thought some folks there might be interested) Hi all, Does anyone know of a ogg based container format that would be appropriate for holding raw AV data? I'm specifically interested in PCM audio, and uncompressed YV12 and RGB32 video. Basically looking to use it as a lightweight tool interchange format, generally muxed by mencoder and read/modified by

Hi all, I'm in the final stages of putting a new Vorbis RTP draft together, the new sections are below. There are a number of open questions: 1.) At present there is a 16 bit length field for the codebooks. As they are spec'd as being unbound in length, but typically around 15K, are there situations where they may be greater than 64KB? The size limit can be extended to 2MB as there

ogg.k.ogg.k at googlemail.com wrote, on 7/14/2009 7:16 AM: >> easy to replace. The second packet is the metadata, which we can lose. >> It's just the third packet that needs to be reconstructed. After that, >> you could start at any packet division in the rest of the file and it >> would play fine? So this generic restore tool that I'm positing would >> just

On 20030610: Gregory Maxwell wrote: (in reply to Ralph Giles) >> I assume you're aware of the technical documentation on dolby's site? >> (http://www.dolby.com/pro/) In particular the surround mixing guide has >> a lot of detailed guidelines. I don't have any practical experience >> with it though, so I can't vouch for it. >Yes I am. I've done a

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 all, I and a few others are trying to implement Yahoo voice chat under Linux. Since Yahoo uses the TrueSpeech codec, we are trying to load the TrueSpeech DLL directly under Linux. mplayer can play TrueSpeech files already, and it appears that it contains portions of Wine code to do so. But mplayer cannot create TrueSpeech files as far as I know. We have ripped the relevant code out