similar to: ov_read_float vs. ov_read

Greetings, I'm having some sort of problem using ov_read_float(). Everything looks good to me, but I'm trashing memory somehow, so clearly I'm screwing something up. What confuses me is why it takes a ***float for the buffer. I call it like so: float **buffer bytes_read = ov_read_float(&vf, &buffer, 0) memcpy (b, *buffer, 0); This compiles fine, but after a few reads,

Hi, in ov_read_float.html there is a small mistake: long ov_read(OggVorbis_File *vf, float ***pcm_channels, int *bitstream); hould read: long ov_read_float(OggVorbis_File *vf, float ***pcm_channels, int samples, int *bitstream); It seems this function has been changed (compared to the RC3). Anything else worked fine for me with the 1.0 release. Olaf <p>--- >8 ---- List archives:

Hello, hope you're fine. And hopefully someone can help me. I wrote a short demonstration to show you my problem (see below). I'm asking always for 64 samples. When "ov_read_float()" is finished, I want to seek back to sample 1, and ask immediately for the next 64 samples. But when I run this small app, I get an totally high CPU load. Is there a way to it speed up? Or do I

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.

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. I noticed that when reading data with ov_read_float(), you can get values outside [-1..1] when the stream is encoded at lower quality, but with higher quality, the values trim down to inside [-1..1]. Looking at the plot from -q10, the data from ov_read_float seems clipped. I've made some plots of encoding the start of Rammsteins Feuer from the xXx soundtrack (it's a pretty loud

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

How do I seek back to the beginning of a stream using ov_pcm_seek()? ov_pcm_seek(0) doesn't seem to do anything, though ov_pcm_tell() returns 0 right after opening the stream. I'm now using ov_pcm_seek(1) which seems to work, but I'm not sure if that's really right. Are PCM offsets meant to be 0 or 1 based? Is this a bug? Frank -- Frank Heckenbach, frank@g-n-u.de

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

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'm seeing some inconsistency in returned timestamps using vorbisfile. I open a file, read some data (grabbing timestamps with ov_pcm_tell), then seek back with ov_pcm_seek(vf, 0) and read it again. The seek lands back on 0, but on the second read through, there's a gap in the timestamps: they jumps up by 2112 frames. This causes my vorbisfile code to insert silence to maintain sync (as

I think I have bumped into the small file error, or I''m doing something stupid. The files are short audio effects for a game (embedded in our own data format). Sample info: Vorbis packets: 1 (4 kb) Samples: 28672 Samplerate: 22 kHz Channels: 2 This is what I''m doing when I want to get a number of bytes from the stream: The problem is that ov_pcm_tell always returns 0. And so

Subj!. Kind Regards, Michail. _________________________________ Michail A.Baikov, Linderdaum Team http://www.gamedot.ru http://linderdaum.gamedot.ru <p><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 'vorbis-dev-request@xiph.org' containing only the word

The sound file is played correctly for the first time, then when rewind to the initial position. then copy PCM to buffer, the OpenAL report an error. It seems like the OpenAL doesn't recognize the PCM data. The OpenAL error number : AL_INVALID_VALUE 0xA003 void Buffer::PCMData (ALuint id, ALenum eFormat, ALvoid *data, ALsizei size, ALsizei freq) { // Copy

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 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,

Hey all, I'm having trouble synchronising pieces of audio with an already-playing stream. I have a common background track is always playing, then themes that can mix with this track at arbitrary points. The theme and background tracks are all the same length, so the plan is that themes will start playing at a position that corresponds with that of the background track. Currently when I

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