search for: ov_einv

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 sth? Reguards, Matthias Brandt [1] http://xiph.org/vorbis/doc/vorbisfile/ov_read.html

I found a problem with ov_raw_seek function in oggvorbis win32sdk 1.0. When i called this function it returned OV_EINVAL immediatelly. I solved the issue by replacing the ov_raw_seek by ov_pcm_seek, which worked perfectly, but i would like to use the raw variant due to performace reason . Is anybody aware of this strange behaviour ? Martin Cesky <p><p>--- >8 ---- List archives: http://www.xiph...

...te is: %d\n",vf.ready_state); ov_clear(&vf); return(0); } } <p><p>Maybe i wrong understand docs and idea of ov_test() / ov_test_open() ? Src of ov_test_open: int ov_test_open(OggVorbis_File *vf){ if(vf->ready_state!=PARTOPEN)return(OV_EINVAL); return _ov_open2(vf); } It returns OV_EINVAL when i run upper example: # ./a.out fail in ov_test_open(), reason: -131 vf.ready_state is: 3 When i use ov_open directly, it works. -- Mariusz Gniazdowski. --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: h...

...a sample within the first second of the stream (i.e. < 44100 samples) fail. Seeks to samples beyond this 44100 limit are fine. It appears to be associated with vorbis_file trying to read the preceding page (odd for the beginning of the file), attempting an ov_raw_seek, then bombing out with an OV_EINVAL. Before diving any further into the code I thought I would ask if this was a known (and hopefully resolved) issue? - or if I'm missing something:) Many thanks, Paul <p><p><p>--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xi...

I've been playing around with using ov_test and ov_test_open as an alternative to ov_open in the xmms plugin's vorbis_check_file function. xmms never bothers to cache the result of a file check, so it tends to happen rather a lot. Unfortunately ov_test_open returns OV_EINVAL because ov_test seems to have left vf->ready_state to OPEN rather than PARTOPEN. I'm presuming this is a bug in libvorbisfile-1.0 - has it been fixed in 1.0.1? On another matter, what would be the best way to find out if a given logical stream is valid vorbis? ov_test and ov_open will...

...but for now I'll just pull out relevant lines: //BEGIN PSEUDO CODE OggVorbis_File vorbis; vorbis_info *info; if(ov_open(infile, &vorbis, NULL, 0) != 0) error(); if((info = ov_info(&vorbis, -1)) == NULL) error(); if((availible_chunks[tint]->len = ov_pcm_total(&vorbis, -1)) == OV_EINVAL) error(); while((tulong = ov_read(&vorbis, tuint8p, 4096, endian, 2, 1, &bitstream)) != 0) dothings_withdata(); //While not end. if(ov_clear(&vorbis) != 0) error(); //SEGFAULT! //END PSEUDO CODE Now, I realize that I haven't given much in the line of an example here, but I do h...

...g OV_EFAULT (from ov_pcm_seek_page). I think this must be a bug, because seeking to 0 seconds *should* be OK. Another thing, when ov_time_seek fails with OV_EFAULT, you cannot continue playing (because of the goto seek_error). This is not clear from the documentation at all, after a OV_ENOSEEK or OV_EINVAL error it seems to me that you can continue decoding. This had me bugged for quite some time, it caused a floating point divide by zero in ov_time_tell (causing it to return -INF), because vf->vi[link].rate is apparently set to zero in the seek_error part. I think the documentation definite...

...UTF-8.html Please note that my understanding of the inner workings of libvorbis is quite limited and the documentation is not exactly overwhelming, so the integration of this functionality could be done much better by someone familiar with the code (please be my guest). I have for example used the OV_EINVAL return value to indicate that the given vorbis_comment structure contains invalid strings. I don't know if this is a good idea. It would be nice to provide some cleartext error message. The patch is against libvorbis-1.0beta4. cheers/daniel ps. One thing that would be very helpful is some...

...st second of the stream (i.e. < > 44100 samples) fail. Seeks to samples beyond this 44100 limit are fine. > > It appears to be associated with vorbis_file trying to read the > preceding page (odd for the beginning of the file), attempting an > ov_raw_seek, then bombing out with an OV_EINVAL. > > Before diving any further into the code I thought I would ask if this > was a known (and hopefully resolved) issue? - or if I'm missing > something:) > This should work fine (seeking is well-tested). Could you send us a) your code, and/or b) an ogg vorbis file this fails...

Hey guys, I've finished my work on reading vorbis files (straight reading at either PCM sample lengths, or time lengths). However, I've run across a question. When you call vorbis_synthesis_read, I assume that increments the internal ptrs so you don't get the same data twice. The question is, what happens if you call vorbis_synthesis and vorbis_synthesis_blockin? Does the next call

Thanks for your answer. But as I said, I don't have any problem seeking in a local file. Also, I have full control on the ogg file I play, since I encode it by myself. I first would like to know if the code I provided ( https://gist.github.com/mregnauld/3f7cdc43b02ec3bbd91641b9333ba072) is good practice when it comes to extracting and seeking in a file that is being downloaded. Thanks.

Hi, While testing ReplayGain (so it could be related to a bug), I noticed the following gain comments for a file: RG_PEAK=1.71580 RG_RADIO=-7.91 dB RG_AUDIOPHILE=-6.72 dB I've never seen such a large peak. Not that I've looked much, nor have I analyzed the file further. I just thought I should mention it. :) The file is the track Board Burner by Mixmaster Mike, available at: