Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2017-04-08T10:58:44Zhttps://gitlab.xiph.org/xiph/vorbis/-/issues/189cc1 segmentation fault on compile2017-04-08T10:58:44Zjupitercc1 segmentation fault on compile```
I'm trying to compile libvorbis 1.0rc3, and cc1 segmentation faults (internal
error) when compiling lib/envelope.c
I am using gcc 2.95.3 (20010315), binutils 2.12, and gcc 2.2.5 on an i686 (2.2.18)
``````
I'm trying to compile libvorbis 1.0rc3, and cc1 segmentation faults (internal
error) when compiling lib/envelope.c
I am using gcc 2.95.3 (20010315), binutils 2.12, and gcc 2.2.5 on an i686 (2.2.18)
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/187gcc 2.95.3 chokes on -mno-ieee-fp2017-04-08T10:58:44Zdoctorkaedinggcc 2.95.3 chokes on -mno-ieee-fp```
During make, gcc 2.95.3 chokes.
I traced it to "-mno-ieee-fp" in the "PROFILE".
It does not appear in the profile for libao
or libogg, which compile OK.
``````
During make, gcc 2.95.3 chokes.
I traced it to "-mno-ieee-fp" in the "PROFILE".
It does not appear in the profile for libao
or libogg, which compile OK.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/186encoder stops when encoded file gets larger than RAM memory2002-04-22T08:56:57ZGitlab Botencoder stops when encoded file gets larger than RAM memory```
Hi,
i sometimes real-time-encode long radio streams by piping the wav-stream to
oggenc's standard input.
but for very long sessions this does not work, because the encoded file cannot
get larger than my physical RAM memory (in my c...```
Hi,
i sometimes real-time-encode long radio streams by piping the wav-stream to
oggenc's standard input.
but for very long sessions this does not work, because the encoded file cannot
get larger than my physical RAM memory (in my case 192MB ram, whitch is about
220 minutes of music).
it would be nice, if one could encode music of about 24 hours without
having 1,4 Gig of memory available.
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/icecast-libshout/-/issues/185Unconditional include of stdint.h2005-05-01T22:24:56ZnickUnconditional include of stdint.h```
I think stdint.h is a linux-ism, and certainly in the configure script,
including of this file is conditional, as follows:
#include <sys/types.h>
#ifdef HAVE_STDINT_H
# include <stdint.h>
#elif defined (HAVE_INTTYPES_H)
# include ...```
I think stdint.h is a linux-ism, and certainly in the configure script,
including of this file is conditional, as follows:
#include <sys/types.h>
#ifdef HAVE_STDINT_H
# include <stdint.h>
#elif defined (HAVE_INTTYPES_H)
# include <inttypes.h>
#endif
Although, as always, I'm never sure if this is because autoconf/libtool is
outta date on my system. I'm pretty sure they dont generally touch the contents
of .c files, so I think this is a valid bug.
Nick
```Segher BoessenkoolSegher Boessenkoolhttps://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-tools/-/issues/183memory leak2002-04-15T00:48:22ZGitlab Botmemory leak```
OggEnc v09.L seems to have a memory leak, when I encoded a 13 min
44Khz track it gradually consumed all my free memory.
I'm under Win2K SP2.
``````
OggEnc v09.L seems to have a memory leak, when I encoded a 13 min
44Khz track it gradually consumed all my free memory.
I'm under Win2K SP2.
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis/-/issues/182_vorbis_block_alloc assumes _ogg_malloc aligns to at least WORD_ALIGN2017-04-08T10:58:44ZGitlab Bot_vorbis_block_alloc assumes _ogg_malloc aligns to at least WORD_ALIGN```
To guarantee WORD_ALIGN alignment, you need to align the pointer after
calling _ogg_malloc(), or _ogg_realloc().
If you are doing cache tuning, you might want to push WORD_ALIGN fairly
high, like 16 or 32 depending on the cache ar...```
To guarantee WORD_ALIGN alignment, you need to align the pointer after
calling _ogg_malloc(), or _ogg_realloc().
If you are doing cache tuning, you might want to push WORD_ALIGN fairly
high, like 16 or 32 depending on the cache architecture.
possible patch:
*** block.c 2002/03/29 07:34:09 1.64
--- block.c 2002/04/12 11:02:00
***************
*** 115,120 ****
--- 115,122 ----
/* highly conservative */
vb->localalloc=bytes;
vb->localstore=_ogg_malloc(vb->localalloc);
+ vb->localstore=(void*)(((long)((char*)vb->localstore+
+ (WORD_ALIGN-1))) & ~(WORD_ALIGN-1));
vb->localtop=0;
}
{
***************
*** 137,143 ****
}
/* consolidate storage */
if(vb->totaluse){
! vb->localstore=_ogg_realloc(vb->localstore,vb->totaluse+vb->
localalloc);
vb->localalloc+=vb->totaluse;
vb->totaluse=0;
}
--- 139,148 ----
}
/* consolidate storage */
if(vb->totaluse){
! long tot=(vb->totaluse+vb->localalloc+(WORD_ALIGN-1)) &
~(WORD_ALIGN-1);
! vb->localstore=_ogg_realloc(vb->localstore,tot);
! vb->localstore=(void*)(((long)((char*)vb->localstore+
! (WORD_ALIGN-1))) & ~(WORD_ALIGN-1));
vb->localalloc+=vb->totaluse;
vb->totaluse=0;
}
It may be better to define a macro that does the alignment.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/181short files are encoded into empty ogg files2002-04-22T08:54:18Zretoshort files are encoded into empty ogg files```
I have a short wav file and use oggenc with no flags to encode it. It works
perfectly, except for files that are shorter than ~0.5 seconds. These will just
be blank. I am aware it may not be space effective to encode tiny sounds, but...```
I have a short wav file and use oggenc with no flags to encode it. It works
perfectly, except for files that are shorter than ~0.5 seconds. These will just
be blank. I am aware it may not be space effective to encode tiny sounds, but
want to do it for consistency
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/177oggenc >FILE creates a wrong file2019-07-01T08:51:49Zfabrice.bauzacoggenc >FILE creates a wrong file```
Let me reproduce the bugreport I sent to the Debian bug-tracking system:
Subject: oggenc: --output=FILE and >FILE have different results
Package: vorbis-tools
Version: 1.0rc3-1
Severity: important
oggenc seems to create different f...```
Let me reproduce the bugreport I sent to the Debian bug-tracking system:
Subject: oggenc: --output=FILE and >FILE have different results
Package: vorbis-tools
Version: 1.0rc3-1
Severity: important
oggenc seems to create different files depending on the style of the
commandline, whether it is
$ cat test.raw | oggenc --raw - --output=test-inputpipe.ogg
or
$ cat test.raw | oggenc --raw - > test-pipe.ogg
The big trouble is that the latter method (> FILE) produces a file
that ogg123 can read without any visible error/warning, but ogginfo
says that the integrity test fails, and vorbiscomment doesn't even
recognize the file as a Ogg file.
An example should make this clearer:
================================================================
*** First, we create the files.
$ oggenc --raw test.raw --output=test.ogg
Encoding "test.raw" to
"test.ogg" at quality 3,00
Encoding with VBR
Encoding [ 1m39s so far] -
Done encoding file "test.ogg"
File length: 1m 01,0s
Elapsed time: 1m 40,2s
Rate: 0,6183
Average bitrate: 84,1 kb/s
$ cat test.raw | oggenc --raw - > test-pipe.ogg
Encoding standard input to
standard output at quality 3,00
Encoding [ 1m48s so far] -
Done encoding.
File length: 1m 01,0s
Elapsed time: 1m 49,1s
Rate: 0,5675
Average bitrate: 84,1 kb/s
$ cat test.raw | oggenc --raw - --output=test-inputpipe.ogg
Encoding standard input to
"test-inputpipe.ogg" at quality 3,00
Encoding with VBR
Encoding [ 1m40s so far] -
Done encoding file "test-inputpipe.ogg"
File length: 1m 01,0s
Elapsed time: 1m 41,0s
Rate: 0,6132
Average bitrate: 84,1 kb/s
*** Now, we try these files:
$ ogginfo test.ogg
filename=test.ogg
serial=1963857601
header_integrity=pass
vendor=Xiphophorus libVorbis I 20011231
version=0
channels=2
rate=44100
bitrate_upper=none
bitrate_nominal=112015
bitrate_lower=none
stream_integrity=pass
bitrate_average=83060
length=61.936327
playtime=1:01
stream_truncated=false
total_length=61.936327
total_playtime=1:01
*** No problem for test.ogg.
$ ogginfo test-pipe.ogg
filename=test-pipe.ogg
header_integrity=fail
stream_integrity=fail
stream_truncated=true
serial=1478540987
header_integrity=pass
vendor=Xiphophorus libVorbis I 20011231
version=0
channels=2
rate=44100
bitrate_upper=none
bitrate_nominal=112015
bitrate_lower=none
stream_integrity=pass
bitrate_average=82533
length=61.936327
playtime=1:01
stream_truncated=false
total_length=61.936327
total_playtime=1:01
*** Trouble!
$ ogginfo test-inputpipe.ogg
filename=test-inputpipe.ogg
serial=33960753
header_integrity=pass
vendor=Xiphophorus libVorbis I 20011231
version=0
channels=2
rate=44100
bitrate_upper=none
bitrate_nominal=112015
bitrate_lower=none
stream_integrity=pass
bitrate_average=83060
length=61.936327
playtime=1:01
stream_truncated=false
total_length=61.936327
total_playtime=1:01
*** No problem. Now let's try vorbiscomment:
$ vorbiscomment test.ogg
$ vorbiscomment test-pipe.ogg
Failed to open file as vorbis: Input is not an Ogg bitstream.
$ vorbiscomment test-inputpipe.ogg
$
================================================================
-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux noon.dnsalias.net 2.4.9 #1 sam mar 2 20:48:32 CET 2002 i686
Locale: LANG=fr_FR, LC_CTYPE=fr_FR
Versions of packages vorbis-tools depends on:
ii libao2 0.8.2-1 Cross Platform Audio Output Librar
ii libc6 2.2.5-4 GNU C Library: Shared libraries an
ii libcurl2-ssl 7.9.5-2 Multi-protocol file transfer libra
ii libogg0 1.0rc3-1 Ogg Bitstream Library
ii libvorbis0 1.0rc3-1 The Vorbis General Audio Compressi
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/173oggenc ignores bitrate setting2002-03-27T06:54:03Zflifsonoggenc ignores bitrate setting```
oggenc seems to ignore the bitrate setting. I get huge .ogg files with bitrates
in the 300+ area when I specified a much lower bit rate. Here's an example.
[flifson@asgard london_calling]$ oggenc -b 128 11_wrong_em_boyo.wav
Opening...```
oggenc seems to ignore the bitrate setting. I get huge .ogg files with bitrates
in the 300+ area when I specified a much lower bit rate. Here's an example.
[flifson@asgard london_calling]$ oggenc -b 128 11_wrong_em_boyo.wav
Opening with wav module: WAV file reader
Encoding "11_wrong_em_boyo.ogg" [ 99.9%] [ 0m00s remaining] \
Done encoding file "11_wrong_em_boyo.ogg"
File length: 3m 13.0s
Elapsed time: 0m 56.9s
Rate: 3.3988
Average bitrate: 347.9 kb/s
[flifson@asgard london_calling]$ oggenc -v
OggEnc v0.8 (libvorbis rc2)
I'm using 0.8rc2. Does this not have bitrate limits enabled?
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/172Oggenc RC3 Cannot handle Very Long Pathnames2002-04-07T21:14:58ZkoranskyOggenc RC3 Cannot handle Very Long Pathnames```
I have found that Oggenc.exe does not run if the pathnames to the files are
very long. I have double checked with LAME and MPEG Plus, they run with no
problem. Very long pathnames are needed with my music collection for detailed
d...```
I have found that Oggenc.exe does not run if the pathnames to the files are
very long. I have double checked with LAME and MPEG Plus, they run with no
problem. Very long pathnames are needed with my music collection for detailed
descriptions.
```Michael SmithMichael Smithhttps://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-tools/-/issues/168%n to -n should be more flexible2002-03-22T14:45:39Zjdahlin%n to -n should be more flexible```
%n should support something like this:
%2n -> ' 1', ' 2', ..., '10', '11' (always 2 in width)
%02n -> '01', '02', ..., '10', '11' (always 2 in width, pad with zeros)
%-2n -> '1 ', '2 ', ..., '10,, '11' (always 2 in width, align lef...```
%n should support something like this:
%2n -> ' 1', ' 2', ..., '10', '11' (always 2 in width)
%02n -> '01', '02', ..., '10', '11' (always 2 in width, pad with zeros)
%-2n -> '1 ', '2 ', ..., '10,, '11' (always 2 in width, align left)
I feel that %0xN is most important of the three.
```Michael SmithMichael Smithhttps://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/ogg/-/issues/163minor problem in in_vorbis plugin and may be ...2002-02-20T07:16:24Zxakepminor problem in in_vorbis plugin and may be ...```
my own encoder of ogg (write on pascal) make test.ogg. Winamp (with in_vorbis
plugin) playing him is normal (without artefacts), but decoder from vorbis_sdk
tools make garbage-like WAV file. :(
I place my test.ogg in followed link...```
my own encoder of ogg (write on pascal) make test.ogg. Winamp (with in_vorbis
plugin) playing him is normal (without artefacts), but decoder from vorbis_sdk
tools make garbage-like WAV file. :(
I place my test.ogg in followed link, please download and test this situation.
Thanks.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/162libvorbis 1.0rc3 crashes gcc 2.95.3-2 on an i686 PC Linux 2.4.16 with glibc 2...2017-04-08T10:58:44Zfrantzlibvorbis 1.0rc3 crashes gcc 2.95.3-2 on an i686 PC Linux 2.4.16 with glibc 2.2.4```
Hi,
I have an i686 PC using Linux version 2.4.16, glibc version 2.2.4, gcc version
2.95.3 with the 2.95.3-2 patch.
I have successfuly compiled libao 0.8.2 and libogg 1.0rc3, but when trying to
compile libvorbis 1.0rc3 the compiler gi...```
Hi,
I have an i686 PC using Linux version 2.4.16, glibc version 2.2.4, gcc version
2.95.3 with the 2.95.3-2 patch.
I have successfuly compiled libao 0.8.2 and libogg 1.0rc3, but when trying to
compile libvorbis 1.0rc3 the compiler gives me the following error:
/bin/sh ../libtool --mode=compile gcc -DPACKAGE=\"libvorbis\" -DVERSION=\"1.0rc3\" -DHAVE_DLFCN_H=1 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_SQRTF=1 -DHAVE_LOGF=1 -DHAVE_EXPF=1 -DHAVE_ACOSF=1 -DHAVE_ATANF=1 -DHAVE_FREXPF=1 -DHAVE_RINTF=1 -I. -I. -I../include -O20 -ffast-math -mno-ieee-fp -D_REENTRANT -fsigned-char -Os -mcpu=i686 -march=i686 -DUSE_MEMORY_H -c envelope.c
gcc -DPACKAGE=\"libvorbis\" -DVERSION=\"1.0rc3\" -DHAVE_DLFCN_H=1 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_SQRTF=1 -DHAVE_LOGF=1 -DHAVE_EXPF=1 -DHAVE_ACOSF=1 -DHAVE_ATANF=1 -DHAVE_FREXPF=1 -DHAVE_RINTF=1 -I. -I. -I../include -O20 -ffast-math -mno-ieee-fp -D_REENTRANT -fsigned-char -Os -mcpu=i686 -march=i686 -DUSE_MEMORY_H -c envelope.c -fPIC -DPIC -o envelope.lo
gcc: Internal compiler error: program cc1 got fatal signal 11
make[2]: *** [envelope.lo] Error 1
make[2]: Leaving directory `/usr/local/src/libvorbis-1.0rc3/lib'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/local/src/libvorbis-1.0rc3/lib'
make: *** [all-recursive] Error 1
I have also tried unsetting the -Os -mcpu=i686 -march=i686 CFLAGS before the
./configure command, but the compiler continues crashing at the same point.
What can I do in order to make the libvorbis package compile correctly?
Thanks
Franco -- frantz@sitoverde.com
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/161-b -M does not fill in max bitrate field2017-04-08T10:58:44Zgreg-b -M does not fill in max bitrate field```
$ oggenc -b 128 -M 130 -o test2.ogg file.wav
$ hex test2.ogg | head -10
0x00000000: 4f 67 67 53 00 02 00 00 - 00 00 00 00 00 00 2a 0d OggS..........*.
0x00000010: 72 54 00 00 00 00 2d 01 - 74 8a 01 1e 01 76 6f 72 rT....-.t....vor
0x...```
$ oggenc -b 128 -M 130 -o test2.ogg file.wav
$ hex test2.ogg | head -10
0x00000000: 4f 67 67 53 00 02 00 00 - 00 00 00 00 00 00 2a 0d OggS..........*.
0x00000010: 72 54 00 00 00 00 2d 01 - 74 8a 01 1e 01 76 6f 72 rT....-.t....vor
0x00000020: 62 69 73 00 00 00 00 02 - 44 ac 00 00 ff ff ff ff bis.....D.......
0x00000030: 1f f4 01 00 ff ff ff ff - b8 01 4f 67 67 53 00 00 ..........OggS..
The min/max bitrate fields are still "ff ff ff ff" (-1). The nominal bitrate
field is correctly set to "1f f4 01 00" (128031).
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/160Win32 Vorbis Tools is missing documentation2002-08-09T16:22:14ZtoddWin32 Vorbis Tools is missing documentation```
I didn't even know there was any documentation for these, but I heard from
Segher Boessenkool that there are supposed to at least be man pages for each of
the tools. However, in the 1.0rc3 ZIP file, there are none. Just the
exec...```
I didn't even know there was any documentation for these, but I heard from
Segher Boessenkool that there are supposed to at least be man pages for each of
the tools. However, in the 1.0rc3 ZIP file, there are none. Just the
executables.
```Jack MoffittJack Moffitthttps://gitlab.xiph.org/xiph/libao/-/issues/156--mandir not accepted by ./configure2007-06-17T08:54:53Zkarmak--mandir not accepted by ./configure```
The standard --mandir option is not accepted by ./configure. It is overridden
via an explicit setting of MANDIR in configure.in. The following patch to the
toplevel Makefile.in makes the --mandir option take effect:
------ BEGIN 'd...```
The standard --mandir option is not accepted by ./configure. It is overridden
via an explicit setting of MANDIR in configure.in. The following patch to the
toplevel Makefile.in makes the --mandir option take effect:
------ BEGIN 'diff -u' OUTPUT ----------
--- TRANSFORM/PATCH/Makefile.in Wed Feb 13 23:41:28 2002
+++ TRANSFORM/PATCH/Makefile.in.original Wed Feb 13 23:41:16 2002
@@ -96,7 +96,7 @@
m4datadir = $(datadir)/aclocal
m4data_DATA = ao.m4
-mandir = @mandir@
+mandir = @MANDIR@
man_MANS = libao.conf.5
EXTRA_DIST = README AUTHORS CHANGES COPYING libao.spec ao.m4 acinclude.m4
+$(man_MANS)
--- END 'diff -u' OUTPUT ---
```Stan SeibertStan Seiberthttps://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 Montgomery