Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2017-11-01T04:49:44Zhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1807I dislike my fresh OGG audio file2017-11-01T04:49:44ZGitlab BotI dislike my fresh OGG audio fileI used Ubuntu 11.04 i386 to create an audio OGG file from FLAC file (SoundConverter 1.4.4). And I am really disappointed with the result. And I don't know where is a problem.
```
1) When I play file with ogg123 (1.4.0), it is OK
2) Whe...I used Ubuntu 11.04 i386 to create an audio OGG file from FLAC file (SoundConverter 1.4.4). And I am really disappointed with the result. And I don't know where is a problem.
```
1) When I play file with ogg123 (1.4.0), it is OK
2) When I play file with GNOME TOTEM player (2.32.0), it is OK
3) When I play file with VLC (1.1.9) under Ubuntu, sound is corrupted
4) When I play file with VLC under WinXP, I observe gaps in music
5) When I open file with Audacity (1.3.13beta), I hear real problem, sometimes music even oscillates between channels
6) I see warnings about discontinuity in the stream from ogginfo (1.4.0):
$ ogginfo 09_-_Don_t_Stop.ogg
Processing file "09_-_Don_t_Stop.ogg"...
New logical stream (#1, serial: 4e8d4803): type vorbis
Vorbis headers parsed for stream 1, information follows...
Version: 0
Vendor: Xiph.Org libVorbis I 20101101 (Schaufenugget)
Channels: 2
Rate: 44100
Nominal bitrate: 192.000000 kb/s
Upper bitrate not set
Lower bitrate not set
User comments section follows...
ARTIST=Cartonnage
TITLE=Don't Stop
ALBUM=I'm Not Your Computer
DATE=2011-01-01
TRACKNUMBER=9
GENRE=Electronic
WARNING: sequence number gap in stream 1. Got page 250 when expecting page 249. Indicates missing data.
WARNING: discontinuity in stream (1)
WARNING: discontinuity in stream (1)
WARNING: discontinuity in stream (1)
WARNING: discontinuity in stream (1)
WARNING: discontinuity in stream (1)
WARNING: discontinuity in stream (1)
WARNING: discontinuity in stream (1)
WARNING: discontinuity in stream (1)
Vorbis stream 1:
Total data length: 4623462 bytes
Playback length: 3m:14.771s
Average bitrate: 189.903045 kb/s
Logical stream 1 ended
```
It seems to me like encoded schema changed and older players cannot play new format correctly. This is not good...
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1805Decoding error in libvorbis when compiled on Mac OS X in i386 architecture2020-06-13T02:58:24ZShannon StewmanDecoding error in libvorbis when compiled on Mac OS X in i386 architectureI encountered a subtle and odd error in libvorbis that shows up on Mac OS X when you compile for i386 architecture.
This is for the released library libvorbis 1.3.2.
It doesn't show up when compiling for x86_64 architecture.
The sympt...I encountered a subtle and odd error in libvorbis that shows up on Mac OS X when you compile for i386 architecture.
This is for the released library libvorbis 1.3.2.
It doesn't show up when compiling for x86_64 architecture.
The symptom: ogg123 produces noise when compiled for i386 but plays the file quite normally when compiled for x86_64. After much tinkering, I finally decoded the .ogg to raw with oggdec in both i386 and x86_64 and compared the output with od:
s007% od -t xS -N 32 /tmp/oggdec_i386.out
0000000 c2b5 8000 c4ba 8000 c252 8000 c28b 8000
0000020 c7f0 8000 cb4b 8000 ce95 8000 d114 8000
d0000040
s007% od -t xS -N 32 /tmp/oggdec_x86-64.out
0000000 c2b5 d253 c4ba d4a9 c252 d4b1 c28b d7d3
0000020 c7f0 ddfe cb4b df58 ce95 de6c d114 dc79
0000040
Notice that in the i386 decoding, every other short is nonsense (x8000).
I traced the problem to the float-to-int conversion code defined in lib/os.h. IIRC, Mac OS X relies entirely on the SSE1/2/3 instruction set to perform math, and may not initialize the FPU correctly.
The problem is solved neatly by relying on the SSE2 code (which is used in the x86_64 pathway). ogg123 plays the file correctly, and the decoding matches between the i386 and x86_64 builds. This fix *should* be safe on Mac OS X; all of the Intel machines that Apple ships have the SSE2 instruction set.
I've attached a diff of my changes, which are localized to lib/os.h
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1800Use AC_CANONICAL_HOST for detecting cross-compilation environment2020-06-23T16:29:49ZMaarten BosmansUse AC_CANONICAL_HOST for detecting cross-compilation environmentAC_CANONICAL_HOST should be used instead of AC_CANONICAL_TARGET in configure.ac.
This is an issue in vorbis, theora and vorbis-tools.
The last two need a patch similar to https://trac.xiph.org/changeset/13007 and for vorbis/configure.ac...AC_CANONICAL_HOST should be used instead of AC_CANONICAL_TARGET in configure.ac.
This is an issue in vorbis, theora and vorbis-tools.
The last two need a patch similar to https://trac.xiph.org/changeset/13007 and for vorbis/configure.ac AC_CANONICAL_TARGET needs to be replaced by AC_CANONICAL_HOST
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1784Track length do not show up in audio players2019-01-28T23:42:18Zpål smievollTrack length do not show up in audio playersYes I was very happy when i found this exe that would give me ogg playback in WMP11. But I have to work around a weird problem with my ogg music files. I converted them from wave to ogg quality 7 vorbis VBR using VLC mediaplayer. Now the...Yes I was very happy when i found this exe that would give me ogg playback in WMP11. But I have to work around a weird problem with my ogg music files. I converted them from wave to ogg quality 7 vorbis VBR using VLC mediaplayer. Now the weird part: Only VLC and ( especially ) Winamp plays the ogg files flawlessly with the correct track-length and seek bar function. This is a shame since I find Ogg vorbis VBR q7 to be the most Awesome lossy format. I even heard that q 5 vbr is sufficient. I wonder if any android mobile smartphone plays VBR ? Will send VLC this report also. There is hope for vbr ogg in wmp11 because it seems to open "ogg variable bit rate files" correctly if you right click and choose open with wmp11, now that is weird. It must be something about the players inability to read the correct track length from the ogg vbr files. This may be due to the conversion process in VLC from wave to ogg vbr ? Maybe the files dont get the correct track length after convertion. But then again its weird that some player gets it right. Is there any program to edit ogg track length etc.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1783vorbis.pc.in assumes -lm, this should be detected first and then added if needed2020-06-13T00:34:33Zscottmc2vorbis.pc.in assumes -lm, this should be detected first and then added if neededNot all platforms require -lm, so instead of assuming -lm is needed, a check should be done and then add it in if needed. Perhaps change vorbis.pc.in to use ${libm}, default it to "" and change it to "-lm" There is an AC_CHECK_LIB (m, c...Not all platforms require -lm, so instead of assuming -lm is needed, a check should be done and then add it in if needed. Perhaps change vorbis.pc.in to use ${libm}, default it to "" and change it to "-lm" There is an AC_CHECK_LIB (m, cos, VORBIS_LIBS="-lm", VORBIS_LIBS="") in confirgure.ac, so perhaps it's as simple as changing the -lm in vorbis.pc.in to ${vobis_libs} or something like that.
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1759[PATCH] libvorbis* pkg-config files produce overlinking2017-11-01T04:49:44ZCristian Morales Vega[PATCH] libvorbis* pkg-config files produce overlinkingThe use of Requires/Libs instead of Requires.private/Libs.private produces overlinking. The patch fixes it.
Patch created by Cristian Rodriguez (https://bugzilla.novell.com/show_bug.cgi?id=384153
The use of Requires/Libs instead of Requires.private/Libs.private produces overlinking. The patch fixes it.
Patch created by Cristian Rodriguez (https://bugzilla.novell.com/show_bug.cgi?id=384153
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1707libvorbis does not like being compiled by a llvm backend.2020-06-13T00:38:11Zdak180libvorbis does not like being compiled by a llvm backend.I am the mac builder for [Warzone 2100](http://developer.wz2100.net/); recently I switched everything over to compile with clang but I found that warzone would [crash](http://wz2100.pastebin.com/tjD6hq2M) on start up.
I determined that ...I am the mac builder for [Warzone 2100](http://developer.wz2100.net/); recently I switched everything over to compile with clang but I found that warzone would [crash](http://wz2100.pastebin.com/tjD6hq2M) on start up.
I determined that this only happens when libvorbis has been compiled with a LLVM backend (switching it to use gcc4.2 makes it work again).
I would really like to be able to use clang to compile libvorbis, so any ideas would be useful.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1697oggenc: double free or corruption2017-11-01T04:49:44ZJohann Burkardoggenc: double free or corruptionHello,
I get this error when using oggenc 1.2.0-5 on Debian Lenny 64 bit:
```
*** glibc detected *** oggenc: double free or corruption (out): 0x00000000004052e0 ***
======= Backtrace: =========
/lib/libc.so.6[0x2b0dbc3c2928]
/lib/libc....Hello,
I get this error when using oggenc 1.2.0-5 on Debian Lenny 64 bit:
```
*** glibc detected *** oggenc: double free or corruption (out): 0x00000000004052e0 ***
======= Backtrace: =========
/lib/libc.so.6[0x2b0dbc3c2928]
/lib/libc.so.6(cfree+0x76)[0x2b0dbc3c4a36]
oggenc[0x404d8d]
oggenc[0x40418f]
/lib/libc.so.6(__libc_start_main+0xe6)[0x2b0dbc36d1a6]
oggenc[0x402559]
======= Memory map: ========
00400000-0040f000 r-xp 00000000 90:59 63508610 /usr/bin/oggenc
0060f000-00610000 rw-p 0000f000 90:59 63508610 /usr/bin/oggenc
08866000-0888c000 rw-p 08866000 00:00 0 [heap]
2b0dbb457000-2b0dbb473000 r-xp 00000000 90:59 63538592 /lib/ld-2.7.so
2b0dbb473000-2b0dbb476000 rw-p 2b0dbb473000 00:00 0
2b0dbb672000-2b0dbb674000 rw-p 0001b000 90:59 63538592 /lib/ld-2.7.so
2b0dbb674000-2b0dbb68e000 r-xp 00000000 90:59 63508066 /usr/lib/libvorbisenc.so.2.0.3
2b0dbb68e000-2b0dbb88d000 ---p 0001a000 90:59 63508066 /usr/lib/libvorbisenc.so.2.0.3
2b0dbb88d000-2b0dbba4e000 rw-p 00019000 90:59 63508066 /usr/lib/libvorbisenc.so.2.0.3
2b0dbba4e000-2b0dbba6d000 r-xp 00000000 90:59 63508064 /usr/lib/libvorbis.so.0.4.0
2b0dbba6d000-2b0dbbc6c000 ---p 0001f000 90:59 63508064 /usr/lib/libvorbis.so.0.4.0
2b0dbbc6c000-2b0dbbc7b000 rw-p 0001e000 90:59 63508064 /usr/lib/libvorbis.so.0.4.0
2b0dbbc7b000-2b0dbbcc5000 r-xp 00000000 90:59 63508319 /usr/lib/libFLAC.so.8.2.0
2b0dbbcc5000-2b0dbbec4000 ---p 0004a000 90:59 63508319 /usr/lib/libFLAC.so.8.2.0
2b0dbbec4000-2b0dbbec6000 rw-p 00049000 90:59 63508319 /usr/lib/libFLAC.so.8.2.0
2b0dbbec6000-2b0dbbf48000 r-xp 00000000 90:59 63538669 /lib/libm-2.7.so
2b0dbbf48000-2b0dbc147000 ---p 00082000 90:59 63538669 /lib/libm-2.7.so
2b0dbc147000-2b0dbc149000 rw-p 00081000 90:59 63538669 /lib/libm-2.7.so
2b0dbc149000-2b0dbc14a000 rw-p 2b0dbc149000 00:00 0
2b0dbc14a000-2b0dbc14f000 r-xp 00000000 90:59 63508056 /usr/lib/libogg.so.0.5.3
2b0dbc14f000-2b0dbc34e000 ---p 00005000 90:59 63508056 /usr/lib/libogg.so.0.5.3
2b0dbc34e000-2b0dbc34f000 rw-p 00004000 90:59 63508056 /usr/lib/libogg.so.0.5.3
2b0dbc34f000-2b0dbc499000 r-xp 00000000 90:59 63538601 /lib/libc-2.7.so
2b0dbc499000-2b0dbc698000 ---p 0014a000 90:59 63538601 /lib/libc-2.7.so
2b0dbc698000-2b0dbc69b000 r--p 00149000 90:59 63538601 /lib/libc-2.7.so
2b0dbc69b000-2b0dbc69d000 rw-p 0014c000 90:59 63538601 /lib/libc-2.7.so
2b0dbc69d000-2b0dbc6a4000 rw-p 2b0dbc69d000 00:00 0
2b0dbc6a4000-2b0dbc9e7000 r--p 00000000 90:59 63505525 /usr/lib/locale/locale-archive
2b0dbc9e7000-2b0dbc9e9000 rw-p 2b0dbc9e7000 00:00 0
2b0dbc9ef000-2b0dbca05000 r-xp 00000000 90:59 63540182 /lib/libgcc_s.so.1
2b0dbca05000-2b0dbcc05000 ---p 00016000 90:59 63540182 /lib/libgcc_s.so.1
2b0dbcc05000-2b0dbcc06000 rw-p 00016000 90:59 63540182 /lib/libgcc_s.so.1
2b0dc0000000-2b0dc0021000 rw-p 2b0dc0000000 00:00 0
2b0dc0021000-2b0dc4000000 ---p 2b0dc0021000 00:00 0
7fff94d93000-7fff94da8000 rw-p 7ffffffea000 00:00 0 [stack]
ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0 [vdso]
encode failed with exit status: 134
```
The command used was
```
nice -n 19 pacpl --to ogg -k -v --oggqual 2 --eopts -Q --outdir /tmp/media.io/3C7693E009DF8738B5EEB99FDA2A983E/out --outfile 8ab4142fea93e1f399cb12a4ee0de64622337a36 /tmp/media.io/3C7693E009DF8738B5EEB99FDA2A983E/out/tmp.wav
```
I'm attaching the WAV file (it's from the Soldat FPS if someone asks).
ThanksMonty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1663Leak when staticbook_unpack fails due to truncated packet2017-11-01T04:49:44ZMatthew GreganLeak when staticbook_unpack fails due to truncated packetWhen staticbook_unpack fails due to a truncated packet, it calls staticbook_clear on the book. This results in the entire static_codebook being memset to 0 (after freeing its resources), which results in b->allocedp being 0. The error ...When staticbook_unpack fails due to a truncated packet, it calls staticbook_clear on the book. This results in the entire static_codebook being memset to 0 (after freeing its resources), which results in b->allocedp being 0. The error handling path in unpack_books calls info_clear which calls staticbook_destroy for each allocated book. staticbook_destroy returns early if b->allocedp is 0, missing a critical call to _ogg_free.
Here's a fuzzer-generated file that triggers this: http://mxr.mozilla.org/mozilla-central/source/content/media/test/bug498855-1.ogvMonty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1658Bit allotment abnormality of the encoding in the specific condition.2018-11-06T20:03:53ZGitlab BotBit allotment abnormality of the encoding in the specific condition.In current libvorbis1.2.3(trunk), thereis the problem for an output result in 32kHz/quality "-1". It uses a bit greatly. libvorbis1.2.1 is normal.
I confirmed that the problem occurred by a change of ticket #1377 and #1493.In current libvorbis1.2.3(trunk), thereis the problem for an output result in 32kHz/quality "-1". It uses a bit greatly. libvorbis1.2.1 is normal.
I confirmed that the problem occurred by a change of ticket #1377 and #1493.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1656vorbis_analysis_headerout calls oggpack_writeclear with uninitialized ogb if ...2018-11-06T20:03:53ZChris Doublevorbis_analysis_headerout calls oggpack_writeclear with uninitialized ogb if !v->backend_stateFrom Mozilla Bug 550184:
https://bugzilla.mozilla.org/show_bug.cgi?id=550184
```
567 int vorbis_analysis_headerout(vorbis_dsp_state *v,
568 vorbis_comment *vc,
569 ...From Mozilla Bug 550184:
https://bugzilla.mozilla.org/show_bug.cgi?id=550184
```
567 int vorbis_analysis_headerout(vorbis_dsp_state *v,
568 vorbis_comment *vc,
569 ogg_packet *op,
570 ogg_packet *op_comm,
571 ogg_packet *op_code){
574 oggpack_buffer opb;
575 private_state *b=v->backend_state;
577 if(!b){
578 ret=OV_EFAULT;
579 goto err_out;
630 err_out:
631 oggpack_writeclear(&opb);
```
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1638Revew and "merge" mozilla patches against libvorbis.2018-11-06T20:03:53ZGregory MaxwellRevew and "merge" mozilla patches against libvorbis.Mozilla is still shipping two small patches against the current libvorbis for more aggressive bad data handling.
These are public patches included in the Firefox 3.6 source distribution. These really should be handled prior to the next ...Mozilla is still shipping two small patches against the current libvorbis for more aggressive bad data handling.
These are public patches included in the Firefox 3.6 source distribution. These really should be handled prior to the next libvorbis release.
BZ487519 looks pretty much directly apply-able, BZ498855 needs cleanup to get the conditionals out of the initilizers.
Both could probably use some review to ensure that there aren't nearby failure modes that the patches are not addressing.
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1635libvorbis-1.2.3 may access out of static array in 'make check'.2018-11-06T20:03:53Zlepidumlibvorbis-1.2.3 may access out of static array in 'make check'.Target version is 1.2.3.
In 'make check', vorbis_encode_compand_setup() accesses _psy_compand_8_mapping[] with index 3, but whoes array length is 3.
This bug was found using Fail-Safe C. (https://staff.aist.go.jp/y.oiwa/FailSafeC/index-...Target version is 1.2.3.
In 'make check', vorbis_encode_compand_setup() accesses _psy_compand_8_mapping[] with index 3, but whoes array length is 3.
This bug was found using Fail-Safe C. (https://staff.aist.go.jp/y.oiwa/FailSafeC/index-en.html)
```
$ uname -a
Linux hardy2-gp01 2.6.24-26-server #1 SMP Tue Dec 1 19:19:20 UTC 2009 i686 GNU/Linux
$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu4)
$ CFLAGS='-g -fno-inline' ./configure --disable-shared && make
(snip)
$ gdb test/test
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
(gdb) b vorbis_encode_compand_setup
Breakpoint 1 at 0x80499fb: file vorbisenc.c, line 373.
(gdb) run
Starting program: /home/katayama/work/libvorbis-1.2.3/test/test
vorbis_44100.ogg :
Breakpoint 1, vorbis_encode_compand_setup (vi=0xbfa14930, s=9.0000011192092888, block=0, in=0x8066560, x=0x8066920)
at vorbisenc.c:373
373 const double *x){
(gdb) c
Continuing.
Breakpoint 1, vorbis_encode_compand_setup (vi=0xbfa14930, s=9.0000011192092888, block=1, in=0x8066560, x=0x8066920)
at vorbisenc.c:373
373 const double *x){
(gdb) c
Continuing.
Breakpoint 1, vorbis_encode_compand_setup (vi=0xbfa14930, s=9.0000011192092888, block=2, in=0x8066560, x=0x8066980)
at vorbisenc.c:373
373 const double *x){
(gdb) c
Continuing.
Breakpoint 1, vorbis_encode_compand_setup (vi=0xbfa14930, s=9.0000011192092888, block=3, in=0x8066560, x=0x8066980)
at vorbisenc.c:373
373 const double *x){
(gdb) c
Continuing.
ok
vorbis_48000.ogg :
Breakpoint 1, vorbis_encode_compand_setup (vi=0xbfa14930, s=9.0000011192092888, block=0, in=0x8066560, x=0x8066920)
at vorbisenc.c:373
373 const double *x){
(gdb) c
Continuing.
Breakpoint 1, vorbis_encode_compand_setup (vi=0xbfa14930, s=9.0000011192092888, block=1, in=0x8066560, x=0x8066920)
at vorbisenc.c:373
373 const double *x){
(gdb) c
Continuing.
Breakpoint 1, vorbis_encode_compand_setup (vi=0xbfa14930, s=9.0000011192092888, block=2, in=0x8066560, x=0x8066980)
at vorbisenc.c:373
373 const double *x){
(gdb) c
Continuing.
Breakpoint 1, vorbis_encode_compand_setup (vi=0xbfa14930, s=9.0000011192092888, block=3, in=0x8066560, x=0x8066980)
at vorbisenc.c:373
373 const double *x){
(gdb) c
Continuing.
ok
vorbis_32000.ogg :
Breakpoint 1, vorbis_encode_compand_setup (vi=0xbfa14930, s=9.0000011192092888, block=0, in=0x8066560, x=0x8066920)
at vorbisenc.c:373
373 const double *x){
(gdb) c
Continuing.
Breakpoint 1, vorbis_encode_compand_setup (vi=0xbfa14930, s=9.0000011192092888, block=1, in=0x8066560, x=0x8066920)
at vorbisenc.c:373
373 const double *x){
(gdb) c
Continuing.
Breakpoint 1, vorbis_encode_compand_setup (vi=0xbfa14930, s=9.0000011192092888, block=2, in=0x8066560, x=0x8066980)
at vorbisenc.c:373
373 const double *x){
(gdb) c
Continuing.
Breakpoint 1, vorbis_encode_compand_setup (vi=0xbfa14930, s=9.0000011192092888, block=3, in=0x8066560, x=0x8066980)
at vorbisenc.c:373
373 const double *x){
(gdb) c
Continuing.
ok
vorbis_22050.ogg :
Breakpoint 1, vorbis_encode_compand_setup (vi=0xbfa14930, s=2.6000002238418576, block=0, in=0x806bc00, x=0x806bd40)
at vorbisenc.c:373
373 const double *x){
(gdb) n
374 int i,is=s;
(gdb) n
373 const double *x){
(gdb) n
374 int i,is=s;
(gdb) n
375 double ds=s-is;
(gdb) n
377 vorbis_info_psy *p=ci->psy_param[block];
(gdb) n
375 double ds=s-is;
(gdb) n
377 vorbis_info_psy *p=ci->psy_param[block];
(gdb) n
379 ds=x[is]*(1.-ds)+x[is+1]*ds;
(gdb) p is+1
$1 = 3
(gdb) p x
$2 = (const double *) 0x806bd40
(gdb) p &_psy_compand_8_mapping
$3 = (double (*)[3]) 0x806bd40
(gdb) p _psy_compand_8_mapping
$4 = {0, 1, 1}
(gdb)
```
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1624LibVorbis Comment Spelling Fixes2018-11-06T20:03:53ZChris 'Xenon' HansonLibVorbis Comment Spelling FixesWhile batch spellchecking some other code, I came across these errors and fixed them.While batch spellchecking some other code, I came across these errors and fixed them.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1614-mcpu=970 causes wrong code on powerpc-linux-gnuspe-2018-11-06T20:03:53Zbigeasy-mcpu=970 causes wrong code on powerpc-linux-gnuspe-On powerpc-unknown-linux-gnuspe SPE is used for floating point.
-mcpu=970 disables the usage of the SPU unit and enables the "normal"
floating point unit. This results either in slow code (kernel
floating point emulation) or in SIGILL...On powerpc-unknown-linux-gnuspe SPE is used for floating point.
-mcpu=970 disables the usage of the SPU unit and enables the "normal"
floating point unit. This results either in slow code (kernel
floating point emulation) or in SIGILL.
-mcpu=970 could also break powerpc-softfloat-linux-gnu but I can't
say for sure.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1602oggenc crash after encode w/resampling2018-11-06T20:03:54ZGitlab Botoggenc crash after encode w/resamplingI'm on Arch Linux 64bit using libvorbis-1.2.3
Whenever I encode to any preset with resampling from 44.1 to 48k I receive errors after encoding is completed. The file produced is just fine.
If I use WAV input a backtrace is produced (a...I'm on Arch Linux 64bit using libvorbis-1.2.3
Whenever I encode to any preset with resampling from 44.1 to 48k I receive errors after encoding is completed. The file produced is just fine.
If I use WAV input a backtrace is produced (attached below)
Using FLAC input of the same track no backtrace is produced but oggenc segfaults and this is printed in messages.log:
"kernel: oggenc[5974] general protection ip:7fad25d0d6a9 sp:7fff40135110 error:0 in libc-2.10.1.so[7fad25c98000+149000]"
As an interesting sidenote, this appears when I use aoTuV-b5.7 as well.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1593ov_fopen should be declared with const char *path2018-11-06T20:03:54ZKumar Appaiahov_fopen should be declared with const char *pathHi!
The current declaration of ov_fopen is:
```
int ov_fopen(char *path,OggVorbis_File *vf);
```
Now, the only use of the path variable is to open a file, for which fopen is used. fopen takes a const char * argument, which implies t...Hi!
The current declaration of ov_fopen is:
```
int ov_fopen(char *path,OggVorbis_File *vf);
```
Now, the only use of the path variable is to open a file, for which fopen is used. fopen takes a const char * argument, which implies that it does not muck around with the path. So, ov_fopen should also not modify path. I would, therefore, request you to modify the declaration to:
```
int ov_fopen(const char *path,OggVorbis_File *vf);
```
Since this is a style error, I take the liberty to call this a defect. Hope you don't mind. :-)
Thanks.
KumarMonty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1584changes file2018-11-06T20:03:54ZEldarchanges file* Add 'OV_EXCLUDE_STATIC_CALLBACKS' define for developers who
wish to *avoid avoid* unused symbol warnings from the static
callbacks defined in vorbisfile.h
double avoid word ))* Add 'OV_EXCLUDE_STATIC_CALLBACKS' define for developers who
wish to *avoid avoid* unused symbol warnings from the static
callbacks defined in vorbisfile.h
double avoid word ))Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1575crash (segfault) in vorbis_synthesis at synthesis.c:302018-11-06T20:03:54Zkeelerdacrash (segfault) in vorbis_synthesis at synthesis.c:30oggplay-info crashes with a segmentation fault with playing corrupted file. Instead of posting the file publicly, I've e-mailed it to xiphmont.oggplay-info crashes with a segmentation fault with playing corrupted file. Instead of posting the file publicly, I've e-mailed it to xiphmont.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1572crash (segfault) in res2_inverse at res0.c:8932018-11-06T20:03:54Zkeelerdacrash (segfault) in res2_inverse at res0.c:893oggplay-info crashes with a segmentation fault when playing a corrupted ogg vorbis file (attached).
This is using libvorbis-1.2.3.oggplay-info crashes with a segmentation fault when playing a corrupted ogg vorbis file (attached).
This is using libvorbis-1.2.3.Monty MontgomeryMonty Montgomery