Vorbis issueshttps://gitlab.xiph.org/xiph/vorbis/-/issues2017-04-08T11:08:16Zhttps://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...'.https://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/1609Some specification improvements2017-04-08T11:08:16ZGitlab BotSome specification improvementsMichael Scheerer has following comments on the Vorbis specification after successfully implementing a Vorbis decoder accordign to spec:
1. A not actual MDCT link.
Actual is e.g. http://www.digital-audio.net/res/docs/ps/eusipco_correct...Michael Scheerer has following comments on the Vorbis specification after successfully implementing a Vorbis decoder accordign to spec:
1. A not actual MDCT link.
Actual is e.g. http://www.digital-audio.net/res/docs/ps/eusipco_corrected.ps
2. A decoder side scaling factor described in the paper was proposed for the vorbis decoder, including following code lines:
float scale;
scale=4.f/n;
but then never used, because the scale is now done encoder sided.
This should be mentioned in the spec.
3. The residue reconstruction after the sentence:
"Packet decode proceeds as follows, matching the description offered earlier in the document."
has at least one curly bracket error in the pseudo code. A developer can't determine, which code block belongs to which curly bracket.
https://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 Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1571[PATCH] libvorbis-1.2.3: Build test/ only if "make check" is called and build...2018-11-06T20:03:54ZSamuli Suominen[PATCH] libvorbis-1.2.3: Build test/ only if "make check" is called and build examples/ only if --enable-examples is passedSummary says it all. The --enable-examples flag is identical to the --enable-docs flag, I've made it purposely identical so it'll "look good" next to the another :-)
Also, use check_PROGRAMS instead of noinst_PROGRAMS in test/ so the te...Summary says it all. The --enable-examples flag is identical to the --enable-docs flag, I've made it purposely identical so it'll "look good" next to the another :-)
Also, use check_PROGRAMS instead of noinst_PROGRAMS in test/ so the tests aren't build unwantedly since autotools happens to support that too...
Thanks!Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1566segmentation fault in vorbis_synthesis_headerin() when playing file2018-11-06T20:03:54Zkeelerdasegmentation fault in vorbis_synthesis_headerin() when playing fileThe attached ogg file (with vorbis audio inside) causes a segmentation fault in ogg123 1.2.0 (and happens to cause unbounded memory consumption when opened with firefox 3.6a1pre).The attached ogg file (with vorbis audio inside) causes a segmentation fault in ogg123 1.2.0 (and happens to cause unbounded memory consumption when opened with firefox 3.6a1pre).Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1560[PATCH] surround _ov_header_fseek_wrap() with #ifndef ov_exclude_static_callb...2017-04-08T10:58:44ZEldar[PATCH] surround _ov_header_fseek_wrap() with #ifndef ov_exclude_static_callbacks..#end tooMonty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1558[PATCH] CHANGES: removed unreleased "phantom" version 1.2.12017-04-08T10:58:44ZEldar[PATCH] CHANGES: removed unreleased "phantom" version 1.2.1Monty MontgomeryMonty Montgomery