Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2017-04-08T10:58:44Zhttps://gitlab.xiph.org/xiph/vorbis/-/issues/851[PATCH] Files missing in tarball2017-04-08T10:58:44ZGitlab Bot[PATCH] Files missing in tarballHi I see some files are missing from the tarball created with make dist:
The more recent RTP draft are not included, even if mentioned in the 1.1.2 changelog. There also other things not included (symbian dir, doc/fish_xiph_org.png, exa...Hi I see some files are missing from the tarball created with make dist:
The more recent RTP draft are not included, even if mentioned in the 1.1.2 changelog. There also other things not included (symbian dir, doc/fish_xiph_org.png, examples/frameview.pl, lib/misc.c, many files in vq/, todo.txt, and others ...) that may be useful.
Would be nice to build also a .bz2 tarball with make dist.
The same is for Theora, ticket #852 .Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/848[PATCH] Incorrect seek time rounding in vorbisfile2017-04-08T10:59:27ZGitlab Bot[PATCH] Incorrect seek time rounding in vorbisfileWhile this is a really minor problem, it makes non-hackfixed vorbis decoder fail random access test in my new decoder validator module.
In ov_time_seek() :
ogg_int64_t target = pcm_total+(seconds-time_total)*vf->vi[link].rate;
Should ...While this is a really minor problem, it makes non-hackfixed vorbis decoder fail random access test in my new decoder validator module.
In ov_time_seek() :
ogg_int64_t target = pcm_total+(seconds-time_total)*vf->vi[link].rate;
Should be:
ogg_int64_t target = pcm_total + (ogg_int64_t)floor( (seconds-time_total)*vf->vi[link].rate + 0.5);Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/838My program crashes while calling ov_read()2017-04-08T10:59:27ZjcdMy program crashes while calling ov_read()Hello.
I have problem with function ov_read() and with libraries. I wrote some ogg player from tutorial on devmaster.net ([http://www.devmaster.net/articles/openal-tutorials/lesson8.php]). I tried to link dlls via ogg_d.lib, vorbis_d.lib...Hello.
I have problem with function ov_read() and with libraries. I wrote some ogg player from tutorial on devmaster.net ([http://www.devmaster.net/articles/openal-tutorials/lesson8.php]). I tried to link dlls via ogg_d.lib, vorbis_d.lib and vorbisfile_d.lib. But when program arrives to function 'ov_read' program crashes. I don't know any reason. When I tried to link static libs, link program ld (i think) exit with many messages:
```
Warning: .drectve `-defaultlib:LIBCMT ' unrecognized
Warning: .drectve `-defaultlib:OLDNAMES ' unrecognized
...
```
and then many messages with twxt "undefined reference" (I see the path of other computers in this messages).
I use IDE Code::Blocks with GNU tools includeing mingw32 compiler and ld linker. First i built the libraries under Visual C++, and then i tried use libs in oggvorbis-sdk... but everything stayed same.
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/730libvorbis-1.1.0 and libvorbis-1.1.1 broken2017-04-08T10:58:44Zsge1899libvorbis-1.1.0 and libvorbis-1.1.1 brokenoggenc creates distorted ogg files from wav files, when using libvorbis-1.1.0 or libvorbis-1.1.1... i now use libvorbis-1.0.1-r2, which work without a hitch....
the resulting oggfile created with above mentioned libraries sound like th...oggenc creates distorted ogg files from wav files, when using libvorbis-1.1.0 or libvorbis-1.1.1... i now use libvorbis-1.0.1-r2, which work without a hitch....
the resulting oggfile created with above mentioned libraries sound like there were byte order problems inside the file... don't know yet... just wonder, why no one seems to have that problem... actually, it is completely reproducible here... i'm usig gentoo, so i just paste you my "emerge info", which shows up possibly important things such as my CFLAGS...
Cheers,
KanneMonty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/725Compile error for libvorbis2017-04-08T10:58:44ZmhouleCompile error for libvorbisI'm trying to compile the libvorbis library on a SGI octane 2, Irix 6.5... libogg compile directly, but I got this stange error when trying to compile libvorbis.
Here is the make output :
```
ES -fsigned-char -DUSE_MEMORY_H -c -o ...I'm trying to compile the libvorbis library on a SGI octane 2, Irix 6.5... libogg compile directly, but I got this stange error when trying to compile libvorbis.
Here is the make output :
```
ES -fsigned-char -DUSE_MEMORY_H -c -o analysis.lo analysis.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I/magma/people/houlem/bin//include -O20 -D__NO_MATH_INLINES -fsigned-char -DUSE_MEMORY_H -c analysis.c -Wp,-MD,.deps/analysis.TPlo -DPIC -o .libs/analysis.o
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I/magma/people/houlem/bin//include -O20 -D__NO_MATH_INLINES -fsigned-char -DUSE_MEMORY_H -c analysis.c -Wp,-MD,.deps/analysis.TPlo -o analysis.o >/dev/null 2>&1
source='synthesis.c' object='synthesis.lo' libtool=yes \
DEPDIR=.deps depmode=gcc /bin/sh ../depcomp \
/bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I/magma/people/houlem/bin//include -O20 -D__NO_MATH_INLINES -fsigned-char -DUSE_MEMORY_H -c -o synthesis.lo synthesis.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I/magma/people/houlem/bin//include -O20 -D__NO_MATH_INLINES -fsigned-char -DUSE_MEMORY_H -c synthesis.c -Wp,-MD,.deps/synthesis.TPlo -DPIC -o .libs/synthesis.o
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I/magma/people/houlem/bin//include -O20 -D__NO_MATH_INLINES -fsigned-char -DUSE_MEMORY_H -c synthesis.c -Wp,-MD,.deps/synthesis.TPlo -o synthesis.o >/dev/null 2>&1
source='psy.c' object='psy.lo' libtool=yes \
DEPDIR=.deps depmode=gcc /bin/sh ../depcomp \
/bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I/magma/people/houlem/bin//include -O20 -D__NO_MATH_INLINES -fsigned-char -DUSE_MEMORY_H -c -o psy.lo psy.c
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I/magma/people/houlem/bin//include -O20 -D__NO_MATH_INLINES -fsigned-char -DUSE_MEMORY_H -c psy.c -Wp,-MD,.deps/psy.TPlo -DPIC -o .libs/psy.o
as: Error: /var/tmp/ccc6ZVoc.s, line 7395: Macro instruction used in branch delay slot
*** Error code 1 (bu21)
*** Error code 1 (bu21)
*** Error code 1 (bu21)
*** Error code 1 (bu21)
```
Thanks in advance for checking what it can be. If you need more information, just contact me and I'll try to get it for you....
BTW, I run both configure command with :
```
./configure --prefix=/home/houlem/bin/ --exec-prefix=/home/houlem/bin/
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/724ov_pcm_total() returns erroneous information2017-04-08T10:59:27Zmmillerov_pcm_total() returns erroneous informationit appears that there is a bug in ov_pcm_total(). it returns the value in vf->pcmlengths[i*2+1]. However, that value is too small - properly, I think it should return vf->pcmlengths[i*2+1] + vf->pcmlengths[i*2]. Otherwise, the value r...it appears that there is a bug in ov_pcm_total(). it returns the value in vf->pcmlengths[i*2+1]. However, that value is too small - properly, I think it should return vf->pcmlengths[i*2+1] + vf->pcmlengths[i*2]. Otherwise, the value returned will be too small by the pcm offset of the last packet in the first audio page (see line 381 of vorbisfile.c, where the value is stored). I can't see what it should do that; when it does, my vorbis-encoded audio gets truncated by that amount on decompression.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/682possible use of uninitialized variable in Tremor/sharedbook.c2017-04-08T10:58:44ZDaniel Stenbergpossible use of uninitialized variable in Tremor/sharedbook.cBuilding Tremor with gcc 4.0 identified this possible flaw (and the Tremor svn repo seems to still have it done this way). This change was just committed in the Rockbox project's CVS tree. (There doesn't seem to be any component in the b...Building Tremor with gcc 4.0 identified this possible flaw (and the Tremor svn repo seems to still have it done this way). This change was just committed in the Rockbox project's CVS tree. (There doesn't seem to be any component in the bug tracker for Tremor so I set it to libvorbis...)
```
--- sharedbook.c 28 Feb 2005 20:55:30 -0000 1.2
+++ sharedbook.c 7 Jul 2005 08:23:21 -0000 1.3
@@ -211,7 +211,7 @@
int indexdiv=1;
for(k=0;k<b->dim;k++){
int index= (j/indexdiv)%quantvals;
- int point;
+ int point=0;
int val=VFLOAT_MULTI(delta,delpoint,
abs(b->quantlist[index]),&point);
@@ -245,7 +245,7 @@
int lastpoint=0;
for(k=0;k<b->dim;k++){
- int point;
+ int point=0;
int val=VFLOAT_MULTI(delta,delpoint,
abs(b->quantlist[j*b->dim+k]),&point);
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/681[PATCH] psuedocode error for Floor1 description in the vorbis docs2017-04-08T11:08:16Zreinier[PATCH] psuedocode error for Floor1 description in the vorbis docs
# Location
The Floor1 description in the vorbis docs, found here:
http://www.xiph.org/ogg/vorbis/doc/vorbis-spec-floor1.html
Contains a bug in the pseudocode rendering of reading out the header (section *header decode*).
# Fragment...
# Location
The Floor1 description in the vorbis docs, found here:
http://www.xiph.org/ogg/vorbis/doc/vorbis-spec-floor1.html
Contains a bug in the pseudocode rendering of reading out the header (section *header decode*).
# Fragment
```
18) iterate [i] over the range 0 ... [floor1_partitions]-1 {
19) [current_class_number] = vector [floor1_partition_class_list] element [i]
20) iterate [j] over the range 0 ... ([floor1_class_dimensions] element [current_class_number])-1 {
21) vector [floor1_X_list] element ([j] + [floor1_values]) =
read [rangebits] bits as unsigned integer
}
22) [floor1_values] = [floor1_values] + [floor1_class_dimensions] element [i]
}
```
# Problem
Line 22 is wrong I think. The intent is to fill the floor1_X_List array with the correct number of 4-bit values. This entails increasing the value of 'floor1_values' with exactly as many values as we just read. However, the increment is:
_floor1_class_dimensions(i)_
whereas the number of 4-bit values read is equal to
_floor1_class_dimensions(floor1_partition_class_list(i))_ aka _floor1_class_dimensions(current_class_number)_.
# Background
I'm re-implementing vorbis, just a decoder, from scratch, in java, using just the docs. Whenever I find inconsistencies or confusion I 'cheat' and take a quick peek at the C sources. In this case, the C sources seem to suggest the documentation is wrong.
# Fix
Change line 22 in the pseudocode to:
```
22) [floor1_values] = [floor1_values] + [floor1_class_dimensions] element [current_class_number]
```
No further changes neccessary.
# Priority and Severity
As it's documentation, you can intrinsically work around any problems by just implementing it right. Assuming for a moment I'm the only one currently trying to hack out a new vorbis decoder from scratch, there's no rush whatsoever. Severity is medium; it's fairly easy to catch, and the free C sources available make it fairly easy to confirm the nature of this documentation bug.
https://gitlab.xiph.org/xiph/vorbis/-/issues/626Extreme low bitrates 32khz 32kbits (technical brief complaint :))2017-04-08T10:59:08ZGitlab BotExtreme low bitrates 32khz 32kbits (technical brief complaint :))I had an error when I tried compressing a .wav file to .ogg using 32kbps average bitrate. It seems .ogg isn't capable of compressing at very low (streaming) bitrates.
I wanted to compare .ogg to it's rival .wma
I know .wma is not the bes...I had an error when I tried compressing a .wav file to .ogg using 32kbps average bitrate. It seems .ogg isn't capable of compressing at very low (streaming) bitrates.
I wanted to compare .ogg to it's rival .wma
I know .wma is not the best codec in higher bitrates (64kbps and beyond); but it is untill now my best codec for the lower bitrates; 56Kbps & below.
It has by far surpassed mp3, and even mp4 on these low bitrates; with a peakquality/compression at 32Kbps/32Khz stereo (which is WMA's best quality/compression ratio) if you don't believe, try any sample out and compare it to MP3's 32Kbits-32khz stereo version, and you will see (or hear).
I heard btw real and wma, and compared them as well; And I'm sad to say, that wma is much better then real, since it uses a way more advanced stereoimage while real has the tendency to make sound appear in the center even when it is slightly panned.
=> I believe REAL has an extreme bad virtual soundfield in the lower bitrates; almost anything sounds mono, if you get what I mean.
Also wma uses better low frequencies. There where real seems to cut off low frequencies, wma keeps it.
Also the highfrequencies sounds better to me (which is a pure sense of taste).
If cymbals would resound, wma sounds artificial, and real's sound will be closer to the original, I agree on that; but on very low bitrates (32kbits-32Khz) the hissing of taperecordings, or high frequencies resounding through a song, like cymbals, will sound much more stable then mp3 or real sound. While with mp3 and real, you hear a fluxuating of the high frequency cut-off, WMA seems to keep a stable cuttoff, which is better for the ear.
This same phenomenon is there when comparing Fraunhofer's MP3 with Lame's.
On exactly the same settings, Lame's codec encodes the high frequencies slightly better then the Fraunhofer one; Only,
The Lame's codec fluxuates more, then fraunhofer.
Which results in Lame giving more clear, and brighter sound, while Fraunhofer gives more stable, almost dry sound.
I personally would prefer lame above the other, but on my AMD, lame encodes at an average of 7 to 8x; while Fraunhofer encodes at 24x
Also with playback, lame decoding require 3% more of CPU power, then Fraunhofer's.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/622warnings while compiling tremor2017-04-08T10:58:44Zdominikwarnings while compiling tremorWhile building MPlayer (which includes a copy of tremor) I've fixed some compiler warnings. The patch still applies to current trunk.
While building MPlayer (which includes a copy of tremor) I've fixed some compiler warnings. The patch still applies to current trunk.
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/618vorbis-tools/libvorbis is apparently not 64-bit clean2017-04-08T10:59:08ZBill Nottinghamvorbis-tools/libvorbis is apparently not 64-bit cleanhttps://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=149295
Using vorbis-tools-1.0.1-4, libvorbis-1.1.0-1 on Fedora Core 3, doing the following:
1. Rip some CDs to flac with sound-juicer
2. On a x86_64, run 'oggenc -q6' on the flac fil...https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=149295
Using vorbis-tools-1.0.1-4, libvorbis-1.1.0-1 on Fedora Core 3, doing the following:
1. Rip some CDs to flac with sound-juicer
2. On a x86_64, run 'oggenc -q6' on the flac files to make oggs
3. Listen to them
The x86_64 ogg file has pops, scratches, etc. If you encode the same flac
file on a 32-bit box, it sounds fine.
http://people.redhat.com/notting/oggtest/
has a source flac file, and the ogg files from running 'oggenc -q6' on
it (32.ogg is on i686, 64.ogg is on x86_64.)
Oddly, both 32.ogg and 64.ogg show the audio artifacts when played
with ogg123 on x86_64.
Initially assigning against libvorbisenc. Feel free to move it.
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/616Minor correction to documentation for "ov_pcm_total", "ov_time_total", "ov_ra...2017-04-08T11:08:16Zphil.hackettMinor correction to documentation for "ov_pcm_total", "ov_time_total", "ov_raw_total"In the Vorbisfile documentation for "ov_pcm_total", "ov_time_total", "ov_raw_total":
In the "Return Values" section, where it says "length in pcm samples of logical bitstream if i=1 to n." (or similar), it should probably read "length i...In the Vorbisfile documentation for "ov_pcm_total", "ov_time_total", "ov_raw_total":
In the "Return Values" section, where it says "length in pcm samples of logical bitstream if i=1 to n." (or similar), it should probably read "length in pcm samples of logical bitstream if i=0 to n.". This is based on my understanding that logical bitstream link values are zero based, and not one based. Having viewed the source code for this function this does seem to be the case, but then I'm a Delphi/Pascal developer, not a C developer, so don't take my word for it!https://gitlab.xiph.org/xiph/vorbis/-/issues/615ov_open_callbacks, ov_test_callbacks - documentation incorrect2017-04-08T11:08:16Zphil.hackettov_open_callbacks, ov_test_callbacks - documentation incorrectIn the Vorbisfile documentation, the function declarations in "ov_open_callbacks" and "ov_test_callbacks" both state that the "ov_callbacks" parameter is passed by value. Below this, in the "Parameters" part of the text these parameters...In the Vorbisfile documentation, the function declarations in "ov_open_callbacks" and "ov_test_callbacks" both state that the "ov_callbacks" parameter is passed by value. Below this, in the "Parameters" part of the text these parameters are stated as pointers to "ov_callbacks" structures. Obviously only one of these is true. It seems to me that the parameters in question are passed by value and not as pointers. (I speak as a Delphi/Pascal coder with a loose grasp of C!)https://gitlab.xiph.org/xiph/vorbis/-/issues/607weird clicks/noises when encoding a file2017-04-08T10:59:08ZGitlab Botweird clicks/noises when encoding a fileI used Ogg Vorbis for hundreds of files, but only now with one wave file (hopefully with this bug system I can attach it) I hear weird clicks and time shifts.I used Ogg Vorbis for hundreds of files, but only now with one wave file (hopefully with this bug system I can attach it) I hear weird clicks and time shifts.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/583Compiling libvorbis-1.1.0 with gcc-4.0.0 causes bitrate / filesize increase2017-04-08T10:59:08ZGitlab BotCompiling libvorbis-1.1.0 with gcc-4.0.0 causes bitrate / filesize increase```
Using libvorbis-1.1.0 compiled with gcc-4.0.0 (20041107 snapshot) gives an
encoded file which is about 35% larger than the same file encoded using the same
libvorbis release but compiled with gcc-3.3.2. (For the gcc-4.0.0 version, I...```
Using libvorbis-1.1.0 compiled with gcc-4.0.0 (20041107 snapshot) gives an
encoded file which is about 35% larger than the same file encoded using the same
libvorbis release but compiled with gcc-3.3.2. (For the gcc-4.0.0 version, I
get around 270kbps for a -q6 encode). Other than the bitrate / filesize
increase, the encoded files sound the same.
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis/-/issues/582[PATCH] Problem during book initialisation2017-04-08T10:58:44ZFelix Leder[PATCH] Problem during book initialisation```
The following situation can occur in _vds_shared_init (block.c) at line 224.
When calling vorbis_book_init_decode (sharedbook.c, l. 318) with a
static_codebook which has all lengthlist = 0, blocks with a size of 0 bytes are
allocated...```
The following situation can occur in _vds_shared_init (block.c) at line 224.
When calling vorbis_book_init_decode (sharedbook.c, l. 318) with a
static_codebook which has all lengthlist = 0, blocks with a size of 0 bytes are
allocated. The behaviour of malloc/calloc in that case is "implementation
dependant".
Most "implementations" return a pointer. Then everything works fine. BUT if you
have an implementation (e.g. TI DSPs) that returns NULL in case of a
calloc/malloc(0) either a segmentation fault is produced or data from memory
position 0 on is overwritten. Neither is wanted.
This overwriting happens in _book_unquantize (sharedbook.c, l. 183) in line 215
and possibly in line 235.
A fix is to replace lines 204 & 225 in this file:
< if((sparsemap && b->lengthlist[j]) || !sparsemap){
------------------
> if(b->lengthlist[j]){
This bug may be related to bug #340
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/581configure script ignores all the --with-ogg* options2017-04-08T10:58:44Zgorlikconfigure script ignores all the --with-ogg* options```
If there is a ogg version on the system configure will find it and ignore the --
with-ogg , --with-ogg-includes , --with-ogg-libraries options.
This prevents cross compiling on any system that has native ogg installed.
system detail...```
If there is a ogg version on the system configure will find it and ignore the --
with-ogg , --with-ogg-includes , --with-ogg-libraries options.
This prevents cross compiling on any system that has native ogg installed.
system details:
debian testing kernel 2.6.8-alpha and 2.6.9-i386
libvorbis-1.1.0
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/580divide by zero error2017-04-08T10:58:44Zjohnhdivide by zero error```
Encountered div by zero exception in bark_noise_hybridmp() in PSY.C caused by
the statement: D = tN * tXX - tX * tX; (don't know which one, there are 4
instances). When I prevented R = (A + x * B) / D; from being calculated if D ==
0...```
Encountered div by zero exception in bark_noise_hybridmp() in PSY.C caused by
the statement: D = tN * tXX - tX * tX; (don't know which one, there are 4
instances). When I prevented R = (A + x * B) / D; from being calculated if D ==
0, all was ok & the resultant OGG file could still be played (used winAmp).
Built v1.1 of ogg, vorbis, vorbisenc & vorbisfile with borland c++ builder v6 &
tested with builds of oggenc & oggdec on this dev. platform. Have emailed the
offending WAV file to Mike Smith - was generated by using directSound (v9) audio
capture api. Problem also occurred on a WAV decoded from an MP3 using LAME.
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis/-/issues/577[PATCH] segfault in ov_time_seek()2017-04-08T10:59:27Zi.danihelka[PATCH] segfault in ov_time_seek()```
There seems to be bug in libvorbisfile.
The bug is in lib/vorbisfile.c in function ov_time_seek().
The variable "link" can have value -1 when is passed to expression
"vf->vi[link].rate".
The for cycle ends when (link == -1) or (seco...```
There seems to be bug in libvorbisfile.
The bug is in lib/vorbisfile.c in function ov_time_seek().
The variable "link" can have value -1 when is passed to expression
"vf->vi[link].rate".
The for cycle ends when (link == -1) or (seconds >= time_total).
This could leaves variable link with value -1.
This happends when functions is called with seconds = 0.0
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/572alloca() is not portable2017-04-08T10:58:44Zjohnathanalloca() is not portable```
All calls to function "alloca()" should be removed as this function is machine
specific and not supported on all platforms or all compilers (ie. MPW for
Macintosh does not support this functionality). Even the man page for alloca()
...```
All calls to function "alloca()" should be removed as this function is machine
specific and not supported on all platforms or all compilers (ie. MPW for
Macintosh does not support this functionality). Even the man page for alloca()
states that use of this function is inadvisable.
Thanks.
```Monty MontgomeryMonty Montgomery