Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2017-04-08T10:58:44Zhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1123libvorbis does not respect includedir2017-04-08T10:58:44Zschizolibvorbis does not respect includedirlibvorbis hardcodes $(prefix)/include/vorbis rather than respecting $(includedir)
I will attach a patch which corresponds to the Makefile.am by Tollef Fog Heen in Debian bug #249695.libvorbis hardcodes $(prefix)/include/vorbis rather than respecting $(includedir)
I will attach a patch which corresponds to the Makefile.am by Tollef Fog Heen in Debian bug #249695.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1091Strange sounds when encoding at 64kbps.2017-04-08T10:58:44ZGitlab BotStrange sounds when encoding at 64kbps.When encoding at quality level 0 there is a strange sound that appears in the background.
It sounds sort of like the sound you would get using an older format such as MP3 at a low bitrate. At lower quality settings (-1), this problem doe...When encoding at quality level 0 there is a strange sound that appears in the background.
It sounds sort of like the sound you would get using an older format such as MP3 at a low bitrate. At lower quality settings (-1), this problem does not exist.
The problem is specific to Vorbis and does not exist in the AAC encoder of iTunes, Windoze Media, or any other competing codec (Although those codecs do have bugs of their own...).
The song I found it in first was Burnout by Green Day.
Also, I am listening on headphones.
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/925[PATCH] libvorbisfile: multiplexed bitstreams2017-04-08T10:59:27ZGitlab Bot[PATCH] libvorbisfile: multiplexed bitstreamscurrenly libvorbis cannot parse a ogg stream containing additional logical stream other than a vorbis bitstream. So it cannot work with a vorbis+skeleton bitstream.currenly libvorbis cannot parse a ogg stream containing additional logical stream other than a vorbis bitstream. So it cannot work with a vorbis+skeleton bitstream.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/922[PATCH] Patch to support ELF symbols visibility2017-04-08T10:58:44ZDiego Elio Pettenò[PATCH] Patch to support ELF symbols visibilityThe patch I'll (try) to attach allows libvorbis to make use of ELF symbols visibility. Basically it removes from the final .so files the symbols that are not exported by public APIs.
There's one exception for _analysis_output_always that...The patch I'll (try) to attach allows libvorbis to make use of ELF symbols visibility. Basically it removes from the final .so files the symbols that are not exported by public APIs.
There's one exception for _analysis_output_always that has to be exported or libvorbisfile.so won't be complete.
Also, vorbis_window was being used by libvorbisfile.so but was defined in libvorbis.so, I've moved the function, but this way I also had to move _vorbis_window_get function in window.h instead of .c, with also the tables (that are constantised so that the compiler can optimise them.
HTH,
Diego "Flameeyes" Pettenò <flameeyes@gentoo.org>Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/884building libvorbis in mingw stops with undefined references2017-04-08T10:59:27Zjohansson_fredricbuilding libvorbis in mingw stops with undefined referencesTrying to build libvorbis after configuring it with:
./configure --prefix=/mingw --with-ogg=/mingw/bin --with-ogg-libraries=/mingw/lib
ends with a lot of undefined references during the linking of libvorbisfile.dll.a like
.libs/vorbisfil...Trying to build libvorbis after configuring it with:
./configure --prefix=/mingw --with-ogg=/mingw/bin --with-ogg-libraries=/mingw/lib
ends with a lot of undefined references during the linking of libvorbisfile.dll.a like
.libs/vorbisfile.o:vorbisfile.c:(.text+0x64): undefined reference to `ogg_sync_pageseek'
I found out that it skipped trying to link to libogg.a(?)/-logg
In the libs/Makefile -logg wasnt added to
libvorbisfile_la_LIBADD = libvorbis.la
which it apparently should.
Someone suggested that there was something wrong in the autotools which made the package and that I should bug this hereMonty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/853vorbisfile is still deadlockable with I/O callback failures2017-04-08T10:59:27ZGitlab Botvorbisfile is still deadlockable with I/O callback failuresMy automated I/O failure scenario tester reliably deadlocks vorbisfile. Multiple callback return value checks are missing from the code, e.g. in _seek_helper; in particular case I've backtracked, _get_prev_page() enters infinite loop whe...My automated I/O failure scenario tester reliably deadlocks vorbisfile. Multiple callback return value checks are missing from the code, e.g. in _seek_helper; in particular case I've backtracked, _get_prev_page() enters infinite loop when seeking/reading fails. Let alone the fact that detection of seekable/nonseekable streams is a huge hack abusing seek callback return value rather rather than letting caller control it properly.Monty MontgomeryMonty Montgomeryhttps://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 Montgomery