similar to: Songs stopping early on my player

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

Hello, After more tests, I discovered a new problem in my code ( https://gist.github.com/mregnauld/3f7cdc43b02ec3bbd91641b9333ba072) while seeking in an audio file that is being downloaded. When I seek in random positions (when I call OggPlayer::seek()), while I extract audio samples (when I call OggPlayer::extract() every 5ms, in my test - basically, I just play the audio file), sometimes, I

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

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,

Can you get a backtrace that tells in which line of the code of the library it crashes? Not that you did Fuzzing using incomplete files and found a bug. Am 5. November 2018 20:46:21 MEZ schrieb Matthieu Regnauld <mregnauld at gmail.com>: >Hello, > >After more tests, I discovered a new problem in my code ( >https://gist.github.com/mregnauld/3f7cdc43b02ec3bbd91641b9333ba072)

OK, thanks for the information. > Is the overhead of closing and re-opening the handle significant on android? Not that much: I can close, reopen and seek in a file right before extracting samples to play a second audio file, while a first file is already extracting and playing, without any glitch, even on low-end device. -------------- next part -------------- An HTML attachment was

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

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()

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

I have a problem i suspect to be a bug in ogg: Assume i have a simple archive "chou_s_test1_test2.pak", created by simply concatenating binary files together: chou_s.jpg (3403 bytes) test1.ogg (5196 bytes) test2.ogg (6128 bytes) If i place the a filepointer passed to ov_open to the beginning of test1.ogg, this ogg gets opened and decoded correctly. But if i place it to the beginning

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

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 all! I've problem with playing ogg files. I'm triing to use tripple buffer method: +-------------+ +-| buffer 1 |-+ | +-------------+ | | | | +-------------+-+ | | buffer 2 | | +-------------+-+ | | | +-------------+-+

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

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

Some months ago I tried to get some answers (and didn't) for a problem I've had with ov_pcm_total for files 8kb or smaller. I have no idea whether it should make a difference, but I operate inside Visual Studio, with C++ 6.0 and MFC. The value returned by ov_pcm_total doesn't agree with ov_read. My solution had been to add 0.2 to the buffer size, so that ov_read would make it to

Why ov_open_callbacks(fd_, &vf, NULL, 0, OV_CALLBACKS_NOCLOSE) takes so long to open OGG file? The OGG file has just 210 MB. It takes a lot of time open the file. I am working on OGG audio recorder and player. Thanks in advance! With kind regards, Pavel

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