Vorbis issueshttps://gitlab.xiph.org/xiph/vorbis/-/issues2017-11-01T04:49:44Zhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1982Switched ai and hi in vorbisenc.c2017-11-01T04:49:44ZTimothy GuSwitched ai and hi in vorbisenc.cFrom l.1089-1148 in lib/vorbisenc.c, the set function set the input argument to the default, and the GET function SET the output (NULL) to the system, i.e. the GET function is actually SET and vice versa. This should be a huge bug.
I ma...From l.1089-1148 in lib/vorbisenc.c, the set function set the input argument to the default, and the GET function SET the output (NULL) to the system, i.e. the GET function is actually SET and vice versa. This should be a huge bug.
I made this bug a "major" bug. If this is not the case, just close this ticket.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1975Segfault in libvorbisenc when passing --advanced-encode-option disable_coupli...2018-04-09T18:15:00ZaeliosheotupSegfault in libvorbisenc when passing --advanced-encode-option disable_coupling to oggencRunning this command in a shell produces a segfault:
```
oggenc -b 80 --advanced-encode-option disable_coupling -o out.ogg in.wav
```
With a libvorbisenc compiled with debug symbols, here is what gdb tells:
```
(gdb) run
Starting progr...Running this command in a shell produces a segfault:
```
oggenc -b 80 --advanced-encode-option disable_coupling -o out.ogg in.wav
```
With a libvorbisenc compiled with debug symbols, here is what gdb tells:
```
(gdb) run
Starting program: /usr/bin/oggenc -b 80 --advanced-encode-option disable_coupling -o out.ogg in.wav
Ouverture avec le module wav: WAV file reader
Encodage de "in.wav"
en "out.ogg"
au dbit approximatif de 80 kbps (encodage VBR en cours)
Setting advanced encoder option "disable_coupling"
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff791dfb0 in vorbis_encode_setup_setting (vi=0x7fffffffd640, channels=2, rate=44100) at vorbisenc.c:884
(gdb) bt
#0 0x00007ffff791dfb0 in vorbis_encode_setup_setting (vi=0x7fffffffd640, channels=2, rate=44100) at vorbisenc.c:884
#1 0x00007ffff791ed14 in vorbis_encode_ctl (vi=0x7fffffffd640, number=65, arg=0x7fffffffd84c) at vorbisenc.c:1208
#2 0x0000000000407725 in set_advanced_encoder_options (vi=0x7fffffffd640, count=1, opts=<optimized out>) at encode.c:102
#3 oe_encode (opt=0x7fffffffdf70) at encode.c:348
#4 0x0000000000403666 in main (argc=<optimized out>, argv=<optimized out>) at oggenc.c:431
(gdb)
```
I can reproduce this with any wav input file.
I'm on Ubuntu 12.04 x64, with libvorbisenc 2.0.8.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1974libvorbis-1.3.3 fails to link its tests2017-11-01T04:49:44Zheireckalibvorbis-1.3.3 fails to link its testsWhen building the tests for libvorbis-1.3.3 linking fails with the error below.
With the attached patch everything works fine.
```
make[1]: Entering directory `/var/tmp/paludis/build/media-libs-libvorbis-1.3.3-r1/work/C/64/test'
x86_64-p...When building the tests for libvorbis-1.3.3 linking fails with the error below.
With the attached patch everything works fine.
```
make[1]: Entering directory `/var/tmp/paludis/build/media-libs-libvorbis-1.3.3-r1/work/C/64/test'
x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I/var/tmp/paludis/build/media-libs-libvorbis-1.3.3-r1/work/libvorbis-1.3.3/test -I.. -I/var/tmp/paludis/build/media-libs-libvorbis-1.3.3-r1/work/libvorbis-1.3.3/include -Wall -Wextra -ffast-math -D_REENTRANT -fsigned-char -Wdeclaration-after-statement -march=native -pipe -O2 -floop-block -floop-interchange -floop-strip-mine -DUSE_MEMORY_H -c /var/tmp/paludis/build/media-libs-libvorbis-1.3.3-r1/work/libvorbis-1.3.3/test/util.c
x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I/var/tmp/paludis/build/media-libs-libvorbis-1.3.3-r1/work/libvorbis-1.3.3/test -I.. -I/var/tmp/paludis/build/media-libs-libvorbis-1.3.3-r1/work/libvorbis-1.3.3/include -Wall -Wextra -ffast-math -D_REENTRANT -fsigned-char -Wdeclaration-after-statement -march=native -pipe -O2 -floop-block -floop-interchange -floop-strip-mine -DUSE_MEMORY_H -c /var/tmp/paludis/build/media-libs-libvorbis-1.3.3-r1/work/libvorbis-1.3.3/test/write_read.c
x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I/var/tmp/paludis/build/media-libs-libvorbis-1.3.3-r1/work/libvorbis-1.3.3/test -I.. -I/var/tmp/paludis/build/media-libs-libvorbis-1.3.3-r1/work/libvorbis-1.3.3/include -Wall -Wextra -ffast-math -D_REENTRANT -fsigned-char -Wdeclaration-after-statement -march=native -pipe -O2 -floop-block -floop-interchange -floop-strip-mine -DUSE_MEMORY_H -c /var/tmp/paludis/build/media-libs-libvorbis-1.3.3-r1/work/libvorbis-1.3.3/test/test.c
make test
make[2]: Entering directory `/var/tmp/paludis/build/media-libs-libvorbis-1.3.3-r1/work/C/64/test'
/bin/sh ../libtool --tag=CC --mode=link x86_64-pc-linux-gnu-gcc -Wall -Wextra -ffast-math -D_REENTRANT -fsigned-char -Wdeclaration-after-statement -march=native -pipe -O2 -floop-block -floop-interchange -floop-strip-mine -DUSE_MEMORY_H -o test util.o write_read.o test.o ../lib/libvorbisenc.la ../lib/libvorbis.la -logg
Dequant test 1... OK
Dequant test 2... OK
Dequant test 3... OK
Dequant test 4... OK
Dequant test 5... OK
/bin/sh ../libtool --tag=CC --mode=link x86_64-pc-linux-gnu-gcc -Wall -Wextra -ffast-math -D_REENTRANT -fsigned-char -Wdeclaration-after-statement -march=native -pipe -O2 -floop-block -floop-interchange -floop-strip-mine -DUSE_MEMORY_H -o test util.o write_read.o test.o ../lib/libvorbisenc.la ../lib/libvorbis.la -logg
libtool: link: x86_64-pc-linux-gnu-gcc -Wall -Wextra -ffast-math -D_REENTRANT -fsigned-char -Wdeclaration-after-statement -march=native -pipe -O2 -floop-block -floop-interchange -floop-strip-mine -DUSE_MEMORY_H -o .libs/test util.o write_read.o test.o ../lib/.libs/libvorbisenc.so ../lib/.libs/libvorbis.so /usr/lib64/libogg.so
make[2]: Leaving directory `/var/tmp/paludis/build/media-libs-libvorbis-1.3.3-r1/work/C/64/test'
util.o:util.c:function gen_windowed_sine: error: undefined reference to 'sin'
util.o:util.c:function gen_windowed_sine: error: undefined reference to 'cos'
collect2: error: ld returned 1 exit status
make[2]: *** [test] Error 1
make[1]: *** [check-am] Error 2
make[1]: *** Waiting for unfinished jobs....
Error:
* In program cave perform install --hooks --managed-output --output-exclusivity with-others =media-libs/libvorbis-1.3.3-r1:0::media --destination installed --replacing =media-libs/libvorbis-1.3.3-r1:0::installed --x-of-y 1 of 1:
* When installing 'media-libs/libvorbis-1.3.3-r1:0::media' replacing { 'media-libs/libvorbis-1.3.3-r1:0::installed' }:
* When running an ebuild command on 'media-libs/libvorbis-1.3.3-r1:0::media':
* Install failed for 'media-libs/libvorbis-1.3.3-r1:0::media' (paludis::ActionFailedError)
libtool: link: x86_64-pc-linux-gnu-gcc -Wall -Wextra -ffast-math -D_REENTRANT -fsigned-char -Wdeclaration-after-statement -march=native -pipe -O2 -floop-block -floop-interchange -floop-strip-mine -DUSE_MEMORY_H -o .libs/test util.o write_read.o test.o ../lib/.libs/libvorbisenc.so ../lib/.libs/libvorbis.so /usr/lib64/libogg.so
make[1]: Leaving directory `/var/tmp/paludis/build/media-libs-libvorbis-1.3.3-r1/work/C/64/test'
util.o:util.c:function gen_windowed_sine: error: undefined reference to 'sin'
util.o:util.c:function gen_windowed_sine: error: undefined reference to 'cos'
collect2: error: ld returned 1 exit status
make[1]: *** [test] Error 1
make: *** [check-recursive] Error 1
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1965vorbisfile: fclose not always called by ov_clear2017-11-01T04:49:44Ztangobravovorbisfile: fclose not always called by ov_clearI don't know if this is a bug in the documentation or in the implementation.
The comment in [/browser/trunk/vorbis/lib/vorbisfile.c#L1058](../tree/master//browser/trunk/vorbis/lib/vorbisfile.c#L1058) suggests ov_test followed by ov_clea...I don't know if this is a bug in the documentation or in the implementation.
The comment in [/browser/trunk/vorbis/lib/vorbisfile.c#L1058](../tree/master//browser/trunk/vorbis/lib/vorbisfile.c#L1058) suggests ov_test followed by ov_clear should close the file, but that currently doesn't happen in the error case.
[Line 915](../tree/master//trunk/vorbis/lib/vorbisfile.c#L915) sets vf->datasource to NULL
Then whenever ov_clear is called (either in the following line, or by the user) fclose is not called due to the check in [line 975](../tree/master//trunk/vorbis/lib/vorbisfile.c#L975).
The workaround in my calling code looks like this:
```
FILE * test_file = NULL;
test_file = fopen(filename.c_str(), "rb");
if(test_file == NULL)
return false;
OggVorbis_File test_ovfile;
int res = ov_test(test_file, &test_ovfile, NULL, 0);
// ov_clear is supposed to close the file but for some ov_test code paths
// this doesn't work, as the internal file pointer is set NULL. We'll do
// the fclose ourselves to be sure
fclose(test_file);
test_ovfile.datasource = NULL;
ov_clear(&test_ovfile);
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1919Build with automake-1.13 broken2020-06-13T00:36:46ZMarko LindqvistBuild with automake-1.13 brokenAutomake-1.13 removed long obsolete AM_CONFIG_HEADER completely (
http://lists.gnu.org/archive/html/automake/2012-12/msg00038.html ) and errors out upon seeing it.
Attached patch replaces it with proper AC_CONFIG_HEADERS.Automake-1.13 removed long obsolete AM_CONFIG_HEADER completely (
http://lists.gnu.org/archive/html/automake/2012-12/msg00038.html ) and errors out upon seeing it.
Attached patch replaces it with proper AC_CONFIG_HEADERS.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1840memory leak in vorbis_commentheader_out2017-11-01T04:49:44ZGitlab Botmemory leak in vorbis_commentheader_outHello,
I have found a small memory leak in vorbis_commentheader_out.
I attach a small patch for this.
Regards.Hello,
I have found a small memory leak in vorbis_commentheader_out.
I attach a small patch for this.
Regards.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1835Configure script architecture detection inconsistent between libvorbis-1.3.2 ...2017-11-01T04:49:44ZMatthew TurnerConfigure script architecture detection inconsistent between libvorbis-1.3.2 and libogg-1.3.0Configure, make, make install of *libogg-1.3.0.tar.gz*, followed by *libvorbis-1.3.2.tar.gz* on *Mac OS X 10.7.1* (64-bit).
configure script for libogg detects machine as x86_64 (which is correct). configure script for libvorbis detects...Configure, make, make install of *libogg-1.3.0.tar.gz*, followed by *libvorbis-1.3.2.tar.gz* on *Mac OS X 10.7.1* (64-bit).
configure script for libogg detects machine as x86_64 (which is correct). configure script for libvorbis detects i386.
libogg.a is built for x86_64. When configure for libvorbis tests if Ogg is installed, compilation fails with a linker error, because it cannot link the i386 object file to the x86_64 libogg.a
Workaround was to force build target:
./configure --build=x86_64
Suggest review of configure scripts for libogg and libvorbis to ensure default architecture detection is consistent for both scripts.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1819libvorbis using undocumented optimization option "-O20" makes clang build fail2017-11-01T04:49:44ZRuben Van Boxemlibvorbis using undocumented optimization option "-O20" makes clang build failThe optimization option "-O20" is
1. Undocumented,
2. Useless, because it just equals -O3
3. Harmfull, because Clang (clang.llvm.org) doesn't recognize it.
It would be a very small change to patch the "-O20" to "-O3" with no change in ...The optimization option "-O20" is
1. Undocumented,
2. Useless, because it just equals -O3
3. Harmfull, because Clang (clang.llvm.org) doesn't recognize it.
It would be a very small change to patch the "-O20" to "-O3" with no change in the resulting build. It would remove undocumented behavior and allow Clang to build libvorbis (with all tests passed).
Thanks!Monty MontgomeryMonty Montgomeryhttps://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 Montgomery