Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2017-11-01T04:49:44Zhttps://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/1829calling vorbis_info_clear() before vorbis_dsp_clear() causes memory leak2017-11-01T04:49:44ZAli Rahimicalling vorbis_info_clear() before vorbis_dsp_clear() causes memory leakthis is a suggestion to include a warning in the documentation.
vorbis_info_clear() clears vi->channels, so that a subsequent call to vorbis_dsp_clear() fails to free v->pcm[i] for each channel.
i ran into this problem because i calle...this is a suggestion to include a warning in the documentation.
vorbis_info_clear() clears vi->channels, so that a subsequent call to vorbis_dsp_clear() fails to free v->pcm[i] for each channel.
i ran into this problem because i called these functions in the wrong order. that was careless of me, of course, because info is initialized before dsp, and i should have clear'ed them in the reverse order. still, this is a difficult bug to track down because an ordering mismatch like this usually causes a crash, but in this case, it causes a leak.
a warning note along the lines of
"not clearing data structures in the reverse order in which they are allocated will likely result in a memory leak".https://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/1818libvorbisenc NULL dereference2017-12-31T04:26:08ZMathieu Gelilibvorbisenc NULL dereferenceHi,
I'm running mpd with vorbis streaming enabled on an ARMv5 device. mpd SEGFAULT upon startup because of libvorbisenc.so.2 as seen by this GDB log :
```
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x43d9...Hi,
I'm running mpd with vorbis streaming enabled on an ARMv5 device. mpd SEGFAULT upon startup because of libvorbisenc.so.2 as seen by this GDB log :
```
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x43d9c410 (LWP 25624)]
0x4101bd20 in vorbis_encode_setup_init () from /usr/lib/libvorbisenc.so.2
(gdb) x/16i $pc
=> 0x4101bd20 <vorbis_encode_setup_init+6420>: ldr r4, [r2, #4]
0x4101bd24 <vorbis_encode_setup_init+6424>: cmp r4, #0
0x4101bd28 <vorbis_encode_setup_init+6428>: mvneq r0, #0
0x4101bd2c <vorbis_encode_setup_init+6432>: beq 0x4101bdd4 <vorbis_encode_setup_init+6600>
0x4101bd30 <vorbis_encode_setup_init+6436>: mov r1, r11
0x4101bd34 <vorbis_encode_setup_init+6440>: mov r0, r10
[...]
```
NULL deref is here in vorbis/lib/vorbisenc.c :
```
static double setting_to_approx_bitrate(vorbis_info *vi){
[...]
r = setup->rate_mapping; // setup == NULL
[...]
}
```
setup (that is (&(&vi->codec_setup)->hi)->setup ) is changed to NULL in the following code :
```
static void vorbis_encode_floor_setup(vorbis_info *vi,int s,
const static_codebook *const *const *const books,
const vorbis_info_floor1 *in,
const int *x){
int i,k,is=s;
vorbis_info_floor1 *f=_ogg_calloc(1,sizeof(*f));
codec_setup_info *ci=vi->codec_setup;
```
If I swap the last two lines and watch (&ci->hi)->setup before and after the _ogg_calloc call I see that after it is NULL.
Any suggestions to fix that ?
Thanks !
--
Mathieu
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/1766vorbis_granule_time(): invalid integer constant2019-03-04T15:52:48ZJens Aytonvorbis_granule_time(): invalid integer constantvorbis/lib/info.c:657:
` granuleoff|=0x7ffffffff; `
This generates a warning on 32-bit and LP64 systems: “Integer constant is too large for ‘long’ type”. This is because 0x7ffffffff is a 35-bit value. I suspect 0x7fffffff is desired, ot...vorbis/lib/info.c:657:
` granuleoff|=0x7ffffffff; `
This generates a warning on 32-bit and LP64 systems: “Integer constant is too large for ‘long’ type”. This is because 0x7ffffffff is a 35-bit value. I suspect 0x7fffffff is desired, otherwise 0x7ffffffffLL.
This error is found in the 1.3.2 release and the current trunk. It was introduced in r17562.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/1693Truncated packets in ogg vorbis2017-04-08T11:08:16ZsiddarthaTruncated packets in ogg vorbisIn the ogg vorbis spec, it is mentioned that 'packets are designed that they may be truncated(padded) and remain decodable'. Are there any limitations to this truncation i.e., if the packet is truncated, is there any limitation on where ...In the ogg vorbis spec, it is mentioned that 'packets are designed that they may be truncated(padded) and remain decodable'. Are there any limitations to this truncation i.e., if the packet is truncated, is there any limitation on where the trunction can start? Or the truncation can start at any stage of encoding?
For example, truncation can only happen after floor decoding etc.,
https://gitlab.xiph.org/xiph/vorbis/-/issues/1673libvorbis installs doxygen-build.stamp2017-04-08T11:08:16ZJohn Ferlitolibvorbis installs doxygen-build.stampUpon a make install the build stamp is being installed into the system
/usr/share/doc/libvorbis-dev/html/doxygen-build.stampUpon a make install the build stamp is being installed into the system
/usr/share/doc/libvorbis-dev/html/doxygen-build.stamphttps://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/1640residue vector partition size limitation (wrong information on Vorbis docs)2017-04-08T11:08:16Zsiddartharesidue vector partition size limitation (wrong information on Vorbis docs)a) In section "8.3 residue 0", the second paragraph says the partition size should be 'even multiple' of codebook dimension which should be only 'integer multiple' as specified correctly in section "8.4 residue 1".
b) In section "8.4 re...a) In section "8.3 residue 0", the second paragraph says the partition size should be 'even multiple' of codebook dimension which should be only 'integer multiple' as specified correctly in section "8.4 residue 1".
b) In section "8.4 residue 1", the second paragraph says '...to be encoded by residue 0...' whereas it should have been '...to be encoded by residue 1...'.