similar to: ov_read bugfix (fwd)

I have a wav file which has been converted to an ogg file with libvorbis via ffmpeg. However I've tested a few files just to make sure. I run a standard while loop to using ov_read to pull all the data out of ogg file. Using 4096 as the size to read each call. Watching my debug logs it is reading 2048 bytes each call. When I load the wav file the data chunk for the pcm data is 167680

I am trying, for the first time, to decode and play an ogg file with two buffers. My audio is choppy and I can't see a problem on the wavOutxxx end of things. So I am wondering about how I call ov_read. From my TRACE statements, the read seems to work perfectly, eventually returning zero. Is it a simple matter of making the same call to ov_read, aside from changing the buffer and

Hi! I solved the problem using ov_read_float instead ov_read. Still do not know why ov_read returned garbage, but ov_read_float works fine! Thanks! El 17 de julio de 2011 10:41, Juan Miguel Mart?n Mu?oz <jmcubo at gmail.com>escribi?: > Hi, thanks for your replies! > > ogg.k, I'm sure MACOSX is defined. When I'm debugging line by line the > program runs into ov_read.

Hi, I have this code to decode ogg data: unsigned long PSS_OggStream::DecodeOggVorbis(OggVorbis_File *psOggVorbisFile, char *pDecodeBuffer, unsigned long ulBufferSize, unsigned long ulChannels) { int current_section; long lDecodeSize; unsigned long ulSamples; short *pSamples; unsigned long ulBytesDone = 0; while (true) { #ifdef WIN32 lDecodeSize = ov_read(psOggVorbisFile,

Ok here is the breakdown. I am trying to impliment streaming into our game using openAL and ogg-vorbis. In the non-streaming function when I call ov_read on the file I should be streaming the buffer gets filled with the correct data. However, when I run ov_read on the same OggVorbis_File when I read the buffer gets filled with 0's. The buffer has not been zero'd and starts filled

Hi, I've ditched the idea of calling the oggvorbis .dlls, and I'm compiling the 1.0beta3 source into my own dll. After opening as "rb" instead of "r", the ov_open() call works. However, ov_read() seems to consistently read less data than I ask for. My buffer is enough to hold two seconds of data, 16 bit 44k mono, that's 176400 bytes. The first call to ov_read()

Hi, I'm new to mailing lists, so don't argue if I do sth wrong... I'm coding on a C++ game with Vorbis- and 5.1-Surround-compatibily. For two channels (stereo), everything's fine, but when I try to read a 6-channel-ogg, ov_read returns -131 (OV_EINVAL). That's strange, because as the specification says, it only returns OV_HOLE or OV_EBADLINK as errors [1]. Have I missed

Has anyone had experience using ov_read in a thread with streaming directsound buffers? i have tried the following, but it just produces a repeating garbage noise. i would appreciate some help. notes: test.ogg in my code was a song that i converted to the vorbis format (Gorillaz - Cling Eastwood) pcmData is defined like this: char pcmData[4096]; the ogg file and the directsound buffer

When I call ov_read ( ) I cannot get more then 1024 bytes decoded even when the buffer size is 4K. The function only decodes 1024 bytes max even when I tell it to decode 4096 bytes. Does anyone has an idea what is going on. <p><p>--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to

When I am using vorbisfile on a disk file, ov_read does not always (in fact - most of the time) read the number of bytes I request. It doesn't seem to be dependent on the number I ask for, and the ratio between what I request and what is read varies. Can somebody tell me what's going on here? TIA Lance --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage:

Hello, Am I missing something? float** pcm_channels; int bitstream; int where = ov_pcm_tell(&vf); -> The Result is "0"; ov_read_float(&vf, &pcm_channels, 1, &bitstream); -> pcm_channels[0][0] is "0.000338580" ov_pcm_seek(&vf, 0); char* buffer = new char[2]; ov_read(&vf, buffer, sizeof(buffer), 0, 2, 1, &bitstream); short temp =

How does one deal with the case when an fread callback doesn't have any more data but is going to get more data in the future? In particular, this is an issue when reading an incoming Ogg stream from a socket (icecast2, in this case). The issue is that the fread can't return 0 (that signals EOF and hoses everything), and it doesn't have a negative code that says come back later

Hi All, I am trying to program the 'Tremor' decoder onto an array of Processors. I am using four Processors. I did this experiment: I split the while(!eof){} in the main() in to four tasks using if(!eof) statements. In this modification, each if() decodes one packet of data at-a-time, sequentially. Then, I ran the code on a single Processor and the decoding was successful. The

The documentation for ov_read states: "ov_read() will decode at most one vorbis packet per invocation". Can I increase the packet size in my encoder so my decoder makes fewer calls to ov_read? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/vorbis-dev/attachments/20131103/d334e7d2/attachment.htm

Hi all, Perhaps a stupid question, but I just need pieces of audio from a file. I know I have to use vorbisfile, and the example compiles, but I don't know how to read the buffer. In fact, it's not even documented (or I'm looking at the wrong place). I assumed it was a interleaved buffer containing unsigned shorts, but that didn't work. I also tried the normal decode example,

Is there any particular reason why ov_read() packs floats to integer PCM inline, rather than being implemented in terms of ov_read_float() and a separate packing fucntion? There are obviously many advantages doing audio manipulation on the floats before packing, but right now you have to reinvent the packing stage yourself - in a replaygain backend that I'm working on, I ended up copying

Here's a patch to vorbisfile.c in libvorbis that splits the float to integer pcm packing out of ov_read into it's own function. The good stuff: - ov_pack_pcm can be used by folks who decode to float pcm with ov_read_float to do various sound manipulations (eg, preamp, fades, replaygain). No more need to roll your own, which will really begin to pay off when 24 bit output gets

I've been experimenting with the ideas of Replay Gain[1] and find that ogg123 doesn't have a way of specifying the scaling applied to replayed samples (like -f in mpg123). Looking at libvorbisfile, I see no function exactly matching this possibly desirable behaviour. ov_read() scales by either 128 (byte output) or 32768 (word output), but there's nothing in between. ov_read_float()

Hello Martin, > how a number of samples with no defined size is translated into 8, 16, or 32 bit values in my buffer Although I do not know in detail about the actual implementation of libvorbis, most of the decoders should internally produce single-precision (32bit) floating point values, or 32bit integers as the result of PCM decoding. They are downcast to PCM samples with 8bit, 16bit, or

I'm working on an application where I need to record the current playing position and return to it later. and I need this to be done the most efficient way, so I used ov_raw_tell() and ov_raw_seek() because the documentation says they are the best when speed is a concern. but the problem is that sometimes ov_raw_tell returns the same value before and after calling ov_read; here's an