Vorbis issueshttps://gitlab.xiph.org/xiph/vorbis/-/issues2017-11-01T04:49:44Zhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1848Warnings in libvorbis/libvorbisfile2017-11-01T04:49:44ZAndrew ChurchWarnings in libvorbis/libvorbisfileThe attached patch against SVN r18145 corrects a number of compiler warnings with "gcc -Wall -Wempty-body -Wmissing-declarations -Wpointer-arith -Wsign-compare -Wstrict-prototypes" on GCC 4.6.1:
- Adds a new header lib/block.h to hold t...The attached patch against SVN r18145 corrects a number of compiler warnings with "gcc -Wall -Wempty-body -Wmissing-declarations -Wpointer-arith -Wsign-compare -Wstrict-prototypes" on GCC 4.6.1:
- Adds a new header lib/block.h to hold the declaration of vorbis_window(), #includes it in block.c and vorbisfile.c, and removes the declaration of that function from vorbisfile.c.
- Adds "static" to internal functions which don't have it: res[012]_*() in res012.c and _make_words() and run_test() in sharedbook.c.
- Changes () to (void) in function definitions so they are proper prototypes: main() (for tests) in sharedbook.c and host_is_big_endian() in vorbisfile.c.
- Deletes the unused function _vi_gpsy_free() from psy.c.
- Deletes the unused variable lastdelta from Laguerre_With_Deflation() in lsp.c.
- Propagates "const" up from the vwin64/vwin128 arrays in window.c through _vorbis_window_get() to its callers (and onward).
- Fixes a constant in info.c which was one digit too long (0x7ffffffff).
I can split this out into separate patches if desired, but I've bundled the changes together since they don't change any functionality.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/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/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/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/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/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/328Low level residue decode pseudo code makes no sense2017-04-08T11:08:16ZjripleyLow level residue decode pseudo code makes no sense```
I can't get a direct implementation of the pseudo code to work at all. There's
obvious problems with it such as:
20. if ([classword_count] is less than [classvals_per_codeword]) AND
([partition_count] is less than [partitions_to_r...```
I can't get a direct implementation of the pseudo code to work at all. There's
obvious problems with it such as:
20. if ([classword_count] is less than [classvals_per_codeword]) AND
([partition_count] is less than [partitions_to_read) then continue at step 11
which loops to the wrong point so that classword_count is only ever used as
value 0. In the end I worked out what the implementation in vorbis/lib/res0.c
does and reimplemented it.
The handling of format 2 isn't documented well. The information is there but
it's all implied and not put into pseudo code. Subtle things like the
do_not_decode_flags specifics for format 2 aren't in code.
It's not all bad - this is actually the only part of the entire documentation
I've found unusable.
```Monty MontgomeryMonty Montgomery