Vorbis issueshttps://gitlab.xiph.org/xiph/vorbis/-/issues2017-04-08T10:59:27Zhttps://gitlab.xiph.org/xiph/vorbis/-/issues/552if tell_func not implemented, seek_func called infinitely2017-04-08T10:59:27ZJack Moffittif tell_func not implemented, seek_func called infinitely```
In the course of testing the vorbisfile-python module, I noticed that if
tell_func is not implemented, then seek_func is called infinitely. A minor bug,
but the error logic in vorbisfile should probably catch coorner cases like thes...```
In the course of testing the vorbisfile-python module, I noticed that if
tell_func is not implemented, then seek_func is called infinitely. A minor bug,
but the error logic in vorbisfile should probably catch coorner cases like these.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/493ov_read_float segfaults on oggflac streams2017-04-08T10:59:27Zjwmov_read_float segfaults on oggflac streams```
As ov_read doesn't check logical streams after the first, it's possible to
feed ov_read_float a physical stream that contains a non-vorbis logical stream
(such as ogg encapsulated flac). Rather than returning OV_EBADLINK, it will
...```
As ov_read doesn't check logical streams after the first, it's possible to
feed ov_read_float a physical stream that contains a non-vorbis logical stream
(such as ogg encapsulated flac). Rather than returning OV_EBADLINK, it will
segfault.
As ov_read_float and ov_read are similar, I expect the same applies for
ov_read.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/434ov_test/ov_test_open do not produce same results as ov_open2017-04-08T10:59:27Zvega_jamesov_test/ov_test_open do not produce same results as ov_open```
I first found this bug in the 1.0 release in Debian's unstable branch. I have
also confirmed that it still exists in CVS as of the filing of this bug
(08-29-2003).
Attempting to open and access an Ogg Vorbis file using ov_test() and...```
I first found this bug in the 1.0 release in Debian's unstable branch. I have
also confirmed that it still exists in CVS as of the filing of this bug
(08-29-2003).
Attempting to open and access an Ogg Vorbis file using ov_test() and
ov_test_open() does not produce the same results as using ov_open(). ov_open()
successfully opens the Ogg Vorbis file whereas ov_test_open() returns an
OV_EINVAL error.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/426ov_read() halt file descriptor2017-04-08T10:59:27Zksangho77ov_read() halt file descriptor```
ioMemFile(my class as FILE*) has ogg file in memory
after ov_read() call, ioMemFile's virtual table is null
when ov_read() call,
ov_read( &vf, ...... 0, 2, 1, (int*)pMemFile );
and..ov_read()
if(bitstream)*bitstream=vf->current...```
ioMemFile(my class as FILE*) has ogg file in memory
after ov_read() call, ioMemFile's virtual table is null
when ov_read() call,
ov_read( &vf, ...... 0, 2, 1, (int*)pMemFile );
and..ov_read()
if(bitstream)*bitstream=vf->current_link; (in vorbisfile.c, 1569 line)
vf->current_link is null and my ioMemFile's virtual table ptr set to null :(
so I cannot use ioMemFile pointer
is it a bug? or my fault? so how can solve ...plz help me..
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/339ov_read() should default to native byte order2017-04-08T10:59:27ZMichel Daenzerov_read() should default to native byte order```
Currently, the bigendianp parameter to ov_read() only takes little or big endian
as arguments, and the documentation recommends little endian as a typical value.
In my experience though, this tends to cause problems on big endian sys...```
Currently, the bigendianp parameter to ov_read() only takes little or big endian
as arguments, and the documentation recommends little endian as a typical value.
In my experience though, this tends to cause problems on big endian systems, the
vast majority of apps need the data to be in native byte order, in particular
those that process the data after decoding.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/335Linking Problems2017-04-08T10:59:27ZcaseyLinking Problems```
There are some linking problems in the win32 cvs...fix by adding the following to...
vorbisfile.def:
ov_crosslap
vorbis.def:
vorbis_synthesis_lapout
vorbis_synthesis_restart
vorbis_window
worked for the dynamic builds, at least.
``````
There are some linking problems in the win32 cvs...fix by adding the following to...
vorbisfile.def:
ov_crosslap
vorbis.def:
vorbis_synthesis_lapout
vorbis_synthesis_restart
vorbis_window
worked for the dynamic builds, at least.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/322win32 function calling convention unspecified.2017-04-08T10:59:27Zbambrywin32 function calling convention unspecified.```
All functions are declared in the .h files without calling convension. If the
code using your lib doesn't use the same default calling convension, it either
do not link or break.
This cannot be fixed by recompiling the libs with th...```
All functions are declared in the .h files without calling convension. If the
code using your lib doesn't use the same default calling convension, it either
do not link or break.
This cannot be fixed by recompiling the libs with the same calling convention
as the application, some file of vorbis.lib are not compiling under vc and
stdcall as default calling convension: callback function for qsort need to be
prefixed with cdecl. Also the callback structure should define it's own
calling convension (probably cdecl too)
You could either fix all h file to prefix the calls to what is in the lib, or
fix the compile problems of vorbis.lib to compile whatever calling convention
is used in the lib.
Beside that, i was able to compile and add ogg/vorbis support to my soft very
quickly. It's also quite fast! good work!.
Thanks
Benoit.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/306Get exception in OS Kernel when try to open a file2017-04-08T10:59:27ZandrewGet exception in OS Kernel when try to open a file```
I am the author of a freeware game that runs in Windows and I am evaluating Ogg
Vorbis as a sound file format to support in the game engine. I am trying to use
the vorbisfile API to open a .ogg file and decode it to PCM for use as ...```
I am the author of a freeware game that runs in Windows and I am evaluating Ogg
Vorbis as a sound file format to support in the game engine. I am trying to use
the vorbisfile API to open a .ogg file and decode it to PCM for use as a
DirectSound buffer. Unfortunately I fell at the first hurdle :( When I try to
use ov_open to access a file I have opened, I get an exception in kernel32.dll
The code I'm using in my test prog is:
// oggtest.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include "vorbis\vorbisfile.h"
int main(int argc, char* argv[])
{
FILE *file;
OggVorbis_File vf;
if ((file = fopen("test.ogg", "rb")) == NULL)
return -1;
if (ov_open(file, &vf, NULL, 0) < 0)
return -1;
ov_clear(&vf);
return 0;
}
I hope you can answer what the problem is or I won't be able to add this
support :/
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/304VorbisFile library crashs when ov_open/ov_test is called the 2nd time2017-04-08T10:59:27ZyuriVorbisFile library crashs when ov_open/ov_test is called the 2nd time```
There is a problem with the VorbisFile library. It only works when I open an
OGG file for
the 1st time. After I closed the file and try to open another one or the same
it crashs. It seems it applies to the use of either ov_open or ...```
There is a problem with the VorbisFile library. It only works when I open an
OGG file for
the 1st time. After I closed the file and try to open another one or the same
it crashs. It seems it applies to the use of either ov_open or ov_test
functions or their combination.
I wrote a test app that illustrates the bug. It crashs with a message
"Unmapped memory exception". It's available at
http://home.earthlink.net/~yurigulyaev/oggvorbisproject32.sit.hqx
My platform is Mac OS 9.2 and CodeWarrior 8.0. I got the same result with
CodeWarrior 7.0.
From what I read on the net I see that this bug exists on other platforms
too.
BTW, I had to compile shared libs on my own because the OggVorbis
SDK for Mac OS
comes with shared libs that don't export any functions and thus unusable.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/292ov_pcm_total(&amp;file, -1) says there's one more sample than there actually is2017-04-08T10:59:27ZAdamDobsonov_pcm_total(&file, -1) says there's one more sample than there actually is```
// Decode file to buffer
// Hardcoded for 16-bit stereo
void decode(OggVorbis_File *pFile, void *pBuffer)
{
int nLength = ov_pcm_total(pFile, -1) * 4;
int nTotalRead = 0;
int current_section;
while (nLength > 0)
{
int nBytes...```
// Decode file to buffer
// Hardcoded for 16-bit stereo
void decode(OggVorbis_File *pFile, void *pBuffer)
{
int nLength = ov_pcm_total(pFile, -1) * 4;
int nTotalRead = 0;
int current_section;
while (nLength > 0)
{
int nBytesRead = ov_read(pFile, ((char *)pBuffer) + nTotalRead,
nBytesToRead, 0, 2, 1, ¤t_section);
if (nBytesRead > 0)
{
nTotalRead += nBytesRead;
nLength -= nBytesRead;
}
else if (nBytesRead == 0)
{
OutputDebugString("EOF reached\n");
return;
}
else
{
OutputDebugString("Error in stream detected\n");
}
}
// We never get here EOF is always reached first
OutputDebugString("It worked\n");
}
This was done using the 1.0 win32 sdk (using static linked release libs) and
the files were encoded with oggdropXPd v1.1 (Compiled 20020719).
To make it work as expected I needed to change the first line to read:
int nLength = (ov_pcm_total(pFile, -1) - 1) * 4;
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/290ftell() callback uses long instead ogg_int64_t2017-04-08T10:59:27Zpeterftell() callback uses long instead ogg_int64_t```
ftell callback (see: ov_open_callbacks(), etc) returns "long" type instead
of "ogg_int64_t", preventing 2gb+ file sizes from being handled correctly.
``````
ftell callback (see: ov_open_callbacks(), etc) returns "long" type instead
of "ogg_int64_t", preventing 2gb+ file sizes from being handled correctly.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/271ov_bitrate misbehaviour with gcc3 + optimizations2017-04-08T10:59:27Zflexoov_bitrate misbehaviour with gcc3 + optimizations```
When ov_bitrate(&vf,-1) (on the whole stream) from libvorbis 1.0 compiled with
gcc3.2 (also happens with gcc 3.1) and default optimizations is called on a
seekable file it returns -2147483648 regardless of the file. (On a nonseekable...```
When ov_bitrate(&vf,-1) (on the whole stream) from libvorbis 1.0 compiled with
gcc3.2 (also happens with gcc 3.1) and default optimizations is called on a
seekable file it returns -2147483648 regardless of the file. (On a nonseekable
file getting the nominal bitrate works fine) When compiled with ``make debug''
(and so optimizations disabled) it doesn't occur.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/232access violations and divides by 0 when usint ov_time_tell() with a not seeka...2017-04-08T10:59:27Zxaviergonzaccess violations and divides by 0 when usint ov_time_tell() with a not seekable stream```
Hello, take a look at the ov_time_tell function in vorbisfile.c
double ov_time_tell(OggVorbis_File *vf){
/* translate time to PCM position and call ov_pcm_seek */
int link=-1;
ogg_int64_t pcm_total=0;
double time_total=0.f;...```
Hello, take a look at the ov_time_tell function in vorbisfile.c
double ov_time_tell(OggVorbis_File *vf){
/* translate time to PCM position and call ov_pcm_seek */
int link=-1;
ogg_int64_t pcm_total=0;
double time_total=0.f;
if(vf->ready_state<OPENED)return(OV_EINVAL);
if(vf->seekable){
pcm_total=ov_pcm_total(vf,-1);
time_total=ov_time_total(vf,-1);
/* which bitstream section does this time offset occur in? */
for(link=vf->links-1;link>=0;link--){
pcm_total-=vf->pcmlengths[link*2+1];
time_total-=ov_time_total(vf,link);
if(vf->pcm_offset>=pcm_total)break;
}
}
return((double)time_total+(double)(vf->pcm_offset-pcm_total)/vf->vi
[link].rate);
}
As you may easily notice, when the vf is *not* seekable, link = -1, and
therefore in the return, it tries to access vf->vi[-1].rate (access violation),
with the side effect of being that 0, so it also performs a divide by 0
operation and since the result value is a double, it returns a NAN -INF. So it
is clearly a bug, therefore I propose the following change:
double ov_time_tell(OggVorbis_File *vf){
/* translate time to PCM position and call ov_pcm_seek */
int link=-1;
ogg_int64_t pcm_total=0;
double time_total=0.f;
if(vf->ready_state<OPENED)return(OV_EINVAL);
if(vf->seekable){
pcm_total=ov_pcm_total(vf,-1);
time_total=ov_time_total(vf,-1);
/* which bitstream section does this time offset occur in? */
for(link=vf->links-1;link>=0;link--){
pcm_total-=vf->pcmlengths[link*2+1];
time_total-=ov_time_total(vf,link);
if(vf->pcm_offset>=pcm_total)break;
}
return((double)time_total+(double)(vf->pcm_offset-pcm_total)/vf->vi
[link].rate);
}
else
return((double)vf->pcm_offset/vf->vi->rate);
}
which basicaly moves the return in the old function inside so it is only called
if the vf is seekable and adds a new return for non seekable files which
returns the current sample / current section rate, which is, that is, the
current second. Probably it doesn't work properly if the current section is
using a different rate than an old (possible) one, but it is always nicer than
an access violation and a divide by 0 and also a more accurate result than NAN -
INF :)
Thanks
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/184ov_open use C-like FILE structure for work with files, is badly. Other langua...2017-04-08T10:59:27Zxakepov_open use C-like FILE structure for work with files, is badly. Other language (example: pascal) stop use of ov_open :(```
Sorry for bad english .. :(
ov_open function is require FILE *f in parameters for normal work.
Why ov_open don't use handle of file? Is fully compatible with any language.
What's wrong?
My program in pascal (delphi) is crashing n...```
Sorry for bad english .. :(
ov_open function is require FILE *f in parameters for normal work.
Why ov_open don't use handle of file? Is fully compatible with any language.
What's wrong?
My program in pascal (delphi) is crashing now.
Problem with interpretated of FILE structure in Delphi (Pascal). Size of FILE
(in C) is 32 byte, but size of analogue FILE structure in Pascal-like is more
than 256. GPF is correct :))
I recommend fix this problem, or help me with fix ov_open in NON C like
languages. Maybe i have curved hands? :))
Thanks for support.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/171vorbis does not work on KDE 3.02017-04-08T10:59:27Zmvogtvorbis does not work on KDE 3.0```
On Tue, Mar 19, 2002 at 07:47:20PM +1100, Michael Smith wrote:
> At 10:45 AM 3/18/02 +0100, you wrote:
> >
> >
> >Hello,
> >
> >the appended Patch makes vorbis work on KDE 3.0.(again)
> >
> >The bug is that the goto s...```
On Tue, Mar 19, 2002 at 07:47:20PM +1100, Michael Smith wrote:
> At 10:45 AM 3/18/02 +0100, you wrote:
> >
> >
> >Hello,
> >
> >the appended Patch makes vorbis work on KDE 3.0.(again)
> >
> >The bug is that the goto seek_error calls in ov_pcm_seek_page
> >do not set the return value in the error case.
> >
> Though there may be (it looks like there is) a bug here, this
> fix is definately incorrect (you've changed it to return the
> wrong error code - which in the buggy cases is better than no
> error code, admittedly). I'll take a closer look and see
> if I can fix it properly.
>
It was a quick and dirty fix, I know. But before I started
to make a cleaner one, I like to have a feedback that
its actually a bug.
> Your reasoning doesn't entirely make sense, in that the
> goto seek_error calls are never reached if the stream has
> been closed (as you say it has been in this case). Sounds
> like there's a nasty bug in your multimedia player as well.
>
I can explain the situation, it has to do with threads.
Vorbis decodes in its own thread and reads from the
callbacks the input data.
User presses "stop" in the player, then the "GUI" thread
closes the input fd. (stream is closed)
If vorbis is doing a seek this "race" occurs:
Row 1027
int ov_pcm_seek_page(OggVorbis_File *vf,ogg_int64_t pos){
int link=-1,ret=0; <- default to "success"
[...]
Row 1086
// here the stream is closed by the other thread (GUI)
result=_get_next_page(vf,&og,end-vf->offset);
// vorbis sees the "closed stream"
if(result==OV_EREAD) goto seek_error;
Row 1175
Row 1175
seek_error:
/* dump machine so we're in a known state */
vf->pcm_offset=-1;
_decode_clear(vf);
return ret; <- RETURN SUCESS !
ret has the value "0" here, although an error occured.
Because the _decode_clear(vf); frees internal structures but
does not indicate the error to the higher functions the
later code segfaults.
No, the current CVS commit:(1.60)
granulepos-=vf->pcmlengths[link*2];
---
>
> if(vf->seekable && link>0)
> granulepos-=vf->pcmlengths[link*2];
did not fix the bug.
This is my segfault:
KDE sound server:
[kde@mv kde]$ artsd -S 4096 -F 10
read on not open file want:8500
Segmentation fault
Command line KDE player:
[kde@mv lib]$ mpeglibartsplay -2 /mnt/diskD/save/ogg/Marque.ogg
cnt:0
Segmentation fault
The -2 is a stresstest to trigger the mentioned race.
You see that "read on not open file want:8500" is vorbis decode
thread, while the gui cloesed the fd.
(The "stresstest" is a common case in the kde player, thus
stresstest is a wrong name)
>Can you file this bug at http://bugs.xiph.org (bugzilla)
done.
regards,
Martin
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/166ov_clear()2017-04-08T10:59:27Zcomrade2kov_clear()```
ov_open(), and ov_read() and then play the data for a few seconds. Call ov_clear
() -> crash!
``````
ov_open(), and ov_read() and then play the data for a few seconds. Call ov_clear
() -> crash!
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/154Raw seeking in small ogg files isnt working2017-04-08T10:59:27Zd00jkrRaw seeking in small ogg files isnt working```
When using seeking_example on the test ogg-file, something goes wrong:
loading....
testing raw seeking to random places in 4148 bytes....
172 [raw position 17]...data position after seek doesn't match pcm position
In my game i...```
When using seeking_example on the test ogg-file, something goes wrong:
loading....
testing raw seeking to random places in 4148 bytes....
172 [raw position 17]...data position after seek doesn't match pcm position
In my game im using a mixer that decodes data from diff. ogg streams. I need to
be able to take a "stamp" of where i am currently in a stream, and then be able
to jump back to it later. The streams are relatively small, (about 5000 bytes in
the OggVorbis format) , Im trying to use ov_raw_seek and ov_raw_tell, but they
somehow give me wrong values. ov_pcm_tell and ov_pcm_seek work fine (but they
are too slow)
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/89ov_open can loop infinitely.2017-04-08T10:59:27Zroconnorov_open can loop infinitely.```
I created a partial Vorbis file. This file causes oggplay to go into an
infinite loop when trying to play the file.
``````
I created a partial Vorbis file. This file causes oggplay to go into an
infinite loop when trying to play the file.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/82float values aren't accesible through libvorbis2017-04-08T10:59:27Ztimjfloat values aren't accesible through libvorbis```
for synthesis apps that do their own mixing and operate on floats,
libvorbisfile does not provide any way to get at the float buffers
directly as provided by the vorbis decoder, forcing people to reimplement
the vorbisfile logic if t...```
for synthesis apps that do their own mixing and operate on floats,
libvorbisfile does not provide any way to get at the float buffers
directly as provided by the vorbis decoder, forcing people to reimplement
the vorbisfile logic if they want decoder float output.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/81CHUNKSIZE too small2017-04-08T10:59:27ZtimjCHUNKSIZE too small```
according to the spec, a vorbis page may be 255*255+header bytes
big.
_get_prev_page() only seeks backwards by CHUNKSIZE bytes, where
CHUNKSIZE is defined to be 8500 bytes.
that means, _get_prev_page() may fail to find the previous
p...```
according to the spec, a vorbis page may be 255*255+header bytes
big.
_get_prev_page() only seeks backwards by CHUNKSIZE bytes, where
CHUNKSIZE is defined to be 8500 bytes.
that means, _get_prev_page() may fail to find the previous
page eventhough it's operation on a spec conforming ogg stream.
though it's prolly inefficient for _get_prev_page() to seek
back by ~64k by default, it should be able to revert to that
much backstepping if nothing is found in the first 8500, so as
to work correctly on conforming ogg streams.
```Monty MontgomeryMonty Montgomery