Ogg issueshttps://gitlab.xiph.org/xiph/ogg/-/issues2017-08-26T14:29:54Zhttps://gitlab.xiph.org/xiph/ogg/-/issues/1845ogg_int64_t incorrect on 64/32bit multilib systems2017-08-26T14:29:54ZJonathan Hamiltonogg_int64_t incorrect on 64/32bit multilib systemsOn a x86_64 system, the autoconf created header config_types.h is used to define ogg sized types, including 'ogg_int64_t' as 'long'.
This causes 32bit compilers using this header to break, as 'long' is only 32 bits using such a compiler...On a x86_64 system, the autoconf created header config_types.h is used to define ogg sized types, including 'ogg_int64_t' as 'long'.
This causes 32bit compilers using this header to break, as 'long' is only 32 bits using such a compiler.
This can be recreated simply with the attached C program.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/1454Failed to build libogg on OpenSolaris2017-08-26T14:29:54Zbrian.luFailed to build libogg on OpenSolarisFailed to build libogg on OpenSolarisFailed to build libogg on OpenSolarisMonty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/1353Discordant playback with Watershed2017-08-26T14:29:55ZplmDiscordant playback with WatershedEncoded K.D Lang's Watershed CD to OGG format at a quality setting of 8.1 using the Winamp 5.53 and the Ogg-Vorbis 1.1 encoder. Playback under Windows Winamp 5.53 sounds find. The same audio files playing back under Linux libogg 1.1.3-74...Encoded K.D Lang's Watershed CD to OGG format at a quality setting of 8.1 using the Winamp 5.53 and the Ogg-Vorbis 1.1 encoder. Playback under Windows Winamp 5.53 sounds find. The same audio files playing back under Linux libogg 1.1.3-74 with ogg123, xmms, amorok, etc, the playback is incredibly distorted. (Note this is same computer, same speakers, volume..)
Encoding the audio under Linux with Grip or KaudioCreator results in the same discord when played.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/1329BITWISE.C integer types , bugs when compiling, typedef's2017-08-26T14:29:55ZGitlab BotBITWISE.C integer types , bugs when compiling, typedef'sFrom BITWISE.C:
```
/* Read in bits without advancing the bitptr; bits <= 32 */
long oggpackB_look(oggpack_buffer *b,int bits){
unsigned long ret;
int m=32-bits;
bits+=b->endbit;
if(b->endbyte+4>=b->storage){
/* not the ma...From BITWISE.C:
```
/* Read in bits without advancing the bitptr; bits <= 32 */
long oggpackB_look(oggpack_buffer *b,int bits){
unsigned long ret;
int m=32-bits;
bits+=b->endbit;
if(b->endbyte+4>=b->storage){
/* not the main path */
if(b->endbyte*8+bits>b->storage*8)return(-1);
}
ret=b->ptr[0]<<(24+b->endbit);
if(bits>8){
ret|=b->ptr[1]<<(16+b->endbit);
if(bits>16){
ret|=b->ptr[2]<<(8+b->endbit);
if(bits>24){
ret|=b->ptr[3]<<(b->endbit);
if(bits>32 && b->endbit)
ret|=b->ptr[4]>>(8-b->endbit);
}
}
}
return ((ret&0xffffffff)>>(m>>1))>>((m+1)>>1);
}
```
```
/* bits <= 32 */
long oggpackB_read(oggpack_buffer *b,int bits){
long ret;
long m=32-bits;
bits+=b->endbit;
if(b->endbyte+4>=b->storage){
/* not the main path */
ret=-1L;
if(b->endbyte*8+bits>b->storage*8)goto overflow;
}
ret=b->ptr[0]<<(24+b->endbit);
if(bits>8){
ret|=b->ptr[1]<<(16+b->endbit);
if(bits>16){
ret|=b->ptr[2]<<(8+b->endbit);
if(bits>24){
ret|=b->ptr[3]<<(b->endbit);
if(bits>32 && b->endbit)
ret|=b->ptr[4]>>(8-b->endbit);
}
}
}
ret=((ret&0xffffffffUL)>>(m>>1))>>((m+1)>>1);
overflow:
b->ptr+=bits/8;
b->endbyte+=bits/8;
b->endbit=bits&7;
return(ret);
}
```
The stuff seems to be very unstable ... in works with some compilers but not with other ones (fails self-test) :-(
1. Why does the upper function use UNSIGNED, but the lower one SIGNED INT32 for "ret" ? Wouldn't all integers UNSIGNED do the job better ? In my tests YES ...
2. Why do the bit counters (seem to allow values 0...32 only) use an SIGNED INT32 rather than an UINT8 ?
3. What is the difference between "long" and "int" ? Why aren't the TYPEDEF's from OS_TYPES.H used ?
```
typedef short ogg_int16_t;
typedef unsigned short ogg_uint16_t;
typedef int ogg_int32_t;
typedef unsigned int ogg_uint32_t;
typedef __int64 ogg_int64_t;
```
4. "ret&0xffffffffUL" vs "ret&0xffffffff" (no "UL") - intentional ?
5. x=(a>>b)>>c can be done better: x=a>>(b+c) ... except for b=c=16 ... but then 0 is returned :-( Is it useful to pick 0 bits ? If for some reason YES, it might be better to "short-circuit" return 0 for 0 bits, rather than process the complete magic.
6. What exactly is it supposed to do ? Some more detailed comments would be appreciated, "endbit" meaning ... Seems the sophisticated stuff does not do much more than just ONE (!) ASM instruction SHLD/SHRD ;-) So I could replace it with cca 5 lines of inline ASM.
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/1118libogg Version: 1.1.3-2ubuntu1 crash when decoding fuzzed file2007-05-28T08:28:38Zensoniclibogg Version: 1.1.3-2ubuntu1 crash when decoding fuzzed fileAs sam pointed out in his blog
http:||sam.zoy.org/blog/2007-01-16-exposing-file-parsing-vulnerabilities
there is a crash when decoding a fuzzed ogg file in gstreamer.
The related gstreamer report is at
http:||bugzilla.gnome.org/show_bug...As sam pointed out in his blog
http:||sam.zoy.org/blog/2007-01-16-exposing-file-parsing-vulnerabilities
there is a crash when decoding a fuzzed ogg file in gstreamer.
The related gstreamer report is at
http:||bugzilla.gnome.org/show_bug.cgi?id=397229
Unfortunately I don't get a decent backtrace here. The last function called is
ogg_stream_pagein()
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/694Could not find or load the file &#34;ELIB.LIB&#34; for target &#34;WINSCW UDE...2007-06-17T08:39:21ZsenthilashokCould not find or load the file "ELIB.LIB" for target "WINSCW UDEB" for project "ogg.mcp".Hi,
I am getting the error, when i tried to compile this example program.
Please help me.
Thanks
SenHi,
I am getting the error, when i tried to compile this example program.
Please help me.
Thanks
Senhttps://gitlab.xiph.org/xiph/ogg/-/issues/653[PATCH] incorrect use of LIBS and CFLAGS in vorbis.m4 and ogg.m42009-04-19T20:23:36ZJulien Cristau[PATCH] incorrect use of LIBS and CFLAGS in vorbis.m4 and ogg.m4Hi,
the autoconf documentation explains that the variable LIBS should
contain "`-l' options to pass to the linker". For `-L' options,
LDFLAGS should be used instead. This breaks compilation of other
software using libogg/libvorbis (and t...Hi,
the autoconf documentation explains that the variable LIBS should
contain "`-l' options to pass to the linker". For `-L' options,
LDFLAGS should be used instead. This breaks compilation of other
software using libogg/libvorbis (and the XIPH_PATH_OGG/XIPH_PATH_VORBIS
macros) when running "./configure --prefix=foo" if {OGG,VORBIS}_LIBS are
assumed to contain only `-l' options.
Moreover, header file search directory options (`-IDIR') belong in
CPPFLAGS, not CFLAGS.
Patches are available at http://perso.ens-lyon.fr/julien.cristau/ogg.m4.diff
and http://perso.ens-lyon.fr/julien.cristau/vorbis.m4.diff
Regards,
Julien CristauMonty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/646green screen2017-04-08T00:51:34ZGitlab Botgreen screenwhen i start to watch anime on DivX,it works. then out of nowhere,randomly, the entire screen turns green. what do i have to do.when i start to watch anime on DivX,it works. then out of nowhere,randomly, the entire screen turns green. what do i have to do.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/645ogg problems2017-04-07T17:11:03ZGitlab Botogg problemswhen i watch mostly anything on DivX. randomly the entire screen will turn green.why does it do this? is this my mistake?when i watch mostly anything on DivX. randomly the entire screen will turn green.why does it do this? is this my mistake?https://gitlab.xiph.org/xiph/ogg/-/issues/549sync-to-sync data loss2004-07-24T01:52:49ZArc Rileysync-to-sync data loss```
I believe there to be a bug in sync.c's buffer handling whereas it doesn't
appear to be incrementing the buffer size when pages that come from one
ogg_sync_state object are passed into another. In the tests I've run, using
Vorbis...```
I believe there to be a bug in sync.c's buffer handling whereas it doesn't
appear to be incrementing the buffer size when pages that come from one
ogg_sync_state object are passed into another. In the tests I've run, using
Vorbis files to test with, I've been getting between 30% to 40% of the page
data I put in.
The data comes out unmangled but "short" in length. ogginfo shows the output
to be a normal Vorbis file, only shorted than it should be and lacking EOS.
I have only seen this error by using py-ogg2 and have not attempted to
replicate this with a C program, however I looked trough py-ogg2's sync.c and
saw nothing that could cause a bug such as this. It's really just glue code
between Python and libogg2, and it seems to work fine for full encoding and
decoding.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/548sync-to-sync data loss2004-07-24T01:53:10ZArc Rileysync-to-sync data loss```
I believe there to be a bug in sync.c's buffer handling whereas it doesn't
appear to be incrementing the buffer size when pages that come from one
ogg_sync_state object are passed into another. In the tests I've run, using
Vorbis...```
I believe there to be a bug in sync.c's buffer handling whereas it doesn't
appear to be incrementing the buffer size when pages that come from one
ogg_sync_state object are passed into another. In the tests I've run, using
Vorbis files to test with, I've been getting between 30% to 40% of the page
data I put in.
The data comes out unmangled but "short" in length. ogginfo shows the output
to be a normal Vorbis file, only shorted than it should be and lacking EOS.
I have only seen this error by using py-ogg2 and have not attempted to
replicate this with a C program, however I looked trough py-ogg2's sync.c and
saw nothing that could cause a bug such as this. It's really just glue code
between Python and libogg2, and it seems to work fine for full encoding and
decoding.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/374libxmms-flac.so references undefined plt symbol2007-06-17T08:42:16Zrretzlaflibxmms-flac.so references undefined plt symbol```
During build of src/plugin_xmms following messages are produced, the
resulting libxmms-flac.so contains undefined reference to plt
FLAC__plugin_common__init_dither_context which is reported when xmms attempts to load the plugin.
Al...```
During build of src/plugin_xmms following messages are produced, the
resulting libxmms-flac.so contains undefined reference to plt
FLAC__plugin_common__init_dither_context which is reported when xmms attempts to load the plugin.
All up looks like libtool suckage
$ libtool --version
ltmain.sh (GNU libtool) 1.4a (1.641.2.255 2001/05/22 10:39:30)
../../libtool-disable-static --mode=link gcc -I../.. -I./include -I../../includ
e -O3 -DNDEBUG -fomit-frame-pointer -funroll-loops -finline-functions -Wall -W -
Winline -DFLaC__INLINE=__inline__ -g -O2 -I/usr/pkg/include -I/usr/pkg/include/
xmms -I/usr/pkg/include/gtk-1.2 -I/usr/pkg/include/glib/glib-1.2 -I/usr/pkg/lib/
glib/include -I/usr/X11R6/include -o libxmms-flac.la -rpath /usr/pkg/lib/xmms
/Input -module -avoid-version charset.lo configure.lo plugin.lo wrap_id3.lo fil
einfo.lo ../../src/plugin_common/libplugin_common.a ../../src/share/grabbag/lib
grabbag.a ../../src/share/gain_analysis/libgain_analysis.a ../../src/share/utf
8/libutf8.a ../../src/libFLAC/libFLAC.la -L../../src/libFLAC/.libs -L/usr/pkg
/lib -L/usr/pkg/lib -Wl,-R/usr/pkg/lib -Wl,-R/usr/X11R6/lib -L/usr/X11R6/lib -L/
usr/X11R6/lib -lgtk -lgdk -lgmodule -lglib -lintl -lXi -lXext -lX11 -lm -lxmms
mkdir .libs
*** Warning: This library needs some functionality provided by ../../src/plugin_common/libplugin_common.a.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
*** Warning: This library needs some functionality provided by ../../src/share/grabbag/libgrabbag.a.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
*** Warning: This library needs some functionality provided by ../../src/share/gain_analysis/libgain_analysis.a.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
*** Warning: This library needs some functionality provided by ../../src/share/utf8/libutf8.a.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have.
```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/ogg/-/issues/94100189582017-04-07T21:51:41Zgumboot10018958```
ogg123 links against /usr/lib/libvorbis.so (which fails because it's out of date) despite there being a /usr/local/lib/libvorbis.so present. This is done explicity in the command issued by make:
gcc -O20 -ffast-math -fsigned-char...```
ogg123 links against /usr/lib/libvorbis.so (which fails because it's out of date) despite there being a /usr/local/lib/libvorbis.so present. This is done explicity in the command issued by make:
gcc -O20 -ffast-math -fsigned-char -o oggenc oggenc.o audio.o encode.o \
platform.o /usr/lib/libvorbis.so -L/lib /usr/lib/libvorbisenc.so -lm \
/usr/lib/libogg.so ../share/libutf8.a ../share/libgetopt.a
```Michael SmithMichael Smith