Vorbis issueshttps://gitlab.xiph.org/xiph/vorbis/-/issues2020-06-12T23:53:11Zhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1327libvorbis-1.2.0\win32\VS2005\libvorbis: missing static build configuration2020-06-12T23:53:11ZOlafvdSpeklibvorbis-1.2.0\win32\VS2005\libvorbis: missing static build configurationHi,
libvorbis-1.2.0\win32\VS2005\libvorbis is missing static build configurations. The VS6 project file does include those configurations, but they're missing from the VS7 and VS8 project files.Hi,
libvorbis-1.2.0\win32\VS2005\libvorbis is missing static build configurations. The VS6 project file does include those configurations, but they're missing from the VS7 and VS8 project files.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1324[PATCH] seek ver slow -> numeric overflow in ov_pcm_seek_page2017-04-08T10:59:27Zxiph-mueller[PATCH] seek ver slow -> numeric overflow in ov_pcm_seek_pageFor large streams or on platforms that do not support 64 bit integers this will effectively result in a _linear search_ which of course make *seeks extremly slow*.
In the successive approximation search of ov_pcm_seek_page() the express...For large streams or on platforms that do not support 64 bit integers this will effectively result in a _linear search_ which of course make *seeks extremly slow*.
In the successive approximation search of ov_pcm_seek_page() the expression
```
bisect=begin +
(target-begintime)*(end-begin)/(endtime-begintime) - CHUNKSIZE;
```
may cause an integer overflow, because it _multiplies_ the stream length by the stream size.
I recommend to use floating point arithmetics for this purpose since it is an approximation anyway. Changing the code as follows cures the problem.
```
bisect=begin
+ (ogg_int64_t)((double)(target-begintime)*(end-begin)/(endtime-begintime))
- CHUNKSIZE;
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1291[PATCH] Mark all the constant tables as constant2017-04-08T10:58:44ZDiego Elio Pettenò[PATCH] Mark all the constant tables as constantThe current status of libvorbis (and especially of libvorbisenc) is not one of the best for shared libraries, as it contains a lot of static and non-static non-constant tables, which are never ever modified.
I'm attaching a patch that m...The current status of libvorbis (and especially of libvorbisenc) is not one of the best for shared libraries, as it contains a lot of static and non-static non-constant tables, which are never ever modified.
I'm attaching a patch that marks all the tables as constant, so that they can be moved to .rodata and thus reduce the memory occupation of libvorbis and libvorbisenc. In particular, libvorbisenc had over 1.5MB of non-constant tables, which are now all constant.
The patch applies fine over current SVN trunk, although it cause an huge amount of warnings at the moment because a lot of structures request a "foo*" rather than "const foo*" even when they don't modify the content. Also functions don't always request "const foo*", so there are quite a few warnings thrown in for that too.
I fixed quite a few of them, but I just couldn't fix all of them at once, the size of the patch is already massive, and I risked to have it fail on SVN if I started fixing all of them. Please don't reject the patch for that, as it would be nitpickery against a fix that's very much useful.
If you want, after you applied this patch I can prepare a new one to shut up the warnings.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1290[PATCH] Remove unused static seq variable2017-04-08T10:58:44ZDiego Elio Pettenò[PATCH] Remove unused static seq variableThere are two static seq variables in floor1.c, one is totally unused, the other is only ever written to. The attached patch gets rid of them to avoid copy-on-write.There are two static seq variables in floor1.c, one is totally unused, the other is only ever written to. The attached patch gets rid of them to avoid copy-on-write.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1274ftell2017-04-08T10:59:27ZGitlab Botftellftell is not working...showing first time use in the functionftell is not working...showing first time use in the functionMonty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1265libvorbis-1.2.0 won't build under OS X 10.52017-04-08T10:58:44ZJeff Lyonlibvorbis-1.2.0 won't build under OS X 10.5libvorbis-1.2.0 won't build under OS X 10.5:
$ ./configure
checking build system type... powerpc-apple-darwin9.1.0
checking host system type... powerpc-apple-darwin9.1.0
checking target system type... powerpc-apple-darwin9.1.0
checking ...libvorbis-1.2.0 won't build under OS X 10.5:
$ ./configure
checking build system type... powerpc-apple-darwin9.1.0
checking host system type... powerpc-apple-darwin9.1.0
checking target system type... powerpc-apple-darwin9.1.0
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for gcc... gcc
checking for C compiler default output file name...
configure: error: C compiler cannot create executables
See `config.log' for more details.
file config.log was not created, so no further information in this error is available.
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1263Add filter support to vorbis decoding2017-04-08T10:58:44ZwilliampoetraAdd filter support to vorbis decodingWHAT:
Support for specifying a filter function when decoding a vorbis stream. The filter function can do anything to the stream, like for example applying ReplayGain.
WHEN:
Done. Had been sitting on my disk for a couple of months no...WHAT:
Support for specifying a filter function when decoding a vorbis stream. The filter function can do anything to the stream, like for example applying ReplayGain.
WHEN:
Done. Had been sitting on my disk for a couple of months now.
WHY:
I wanted to add ReplayGain (VorbisGain) support to ogg123, and found that everything could be made remarkably simpler if we can have a filter function available.
HOW:
See attached patch. It's quite simple, actually: Just create a function ov_read_filter() with the same parameters as ov_read() except that ov_read_filter() takes two extra arguments: a pointer to the filter function (filter()) and a pointer to the data to be passed to the filter function (filter_param).
The filter function takes four arguments: 1. pointer to buffer containing the pcm samples in floating point format, 2. the number of channels, 3. the number of samples, and 4. the data (filter_param). The data passed in filter_param can be anything and is to be decided by the application. In my case, I used it to implement ReplayGain in ogg123 (the implementation is basically a much stripped-down version of vgplay).
WHO:
Me. williampoetra at gmail dot com
I would love to see this patch merged. Comments and suggestion please.
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1261ov_fopen export missing2017-04-08T10:59:27ZGitlab Botov_fopen export missingov_fopen export missing in Exports.def in libvorbisfile in VS2003/2005 in the last downloadable stable version 1.2.0
add simply
LIBRARY libvorbisfile
EXPORTS
ov_clear
ov_open
ov_open_callbacks
ov_fopen //add this one here
;
thanks f...ov_fopen export missing in Exports.def in libvorbisfile in VS2003/2005 in the last downloadable stable version 1.2.0
add simply
LIBRARY libvorbisfile
EXPORTS
ov_clear
ov_open
ov_open_callbacks
ov_fopen //add this one here
;
thanks for this great lib!
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1258Add defines to exclude encoder specific parts from library2017-04-08T10:58:44ZGitlab BotAdd defines to exclude encoder specific parts from librarySeveral things can be removed from the library at compile time by using #defines if only a vorbis decoder is needed. These include, but are not limted to:
* Floor packer + Floor forward function
* Residue packer + Residue forward func...Several things can be removed from the library at compile time by using #defines if only a vorbis decoder is needed. These include, but are not limted to:
* Floor packer + Floor forward function
* Residue packer + Residue forward function
* Mapping packer + Mapping forward function
* Codebook packer/encoder
* Bitrate management (bitrate.c)
* vorbis_block_internal and functions that deal with it.
* Envelope code (envelope.c)
* Psychoaucostic model code (psy.c)
* Analysis file (analysis.c)
* info packers (info.c)
* smallft.c
This reduces the size of the generated code from >100kb to ~60kb.
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1251Status of integrating autuv work into vorbis?2020-06-23T17:18:12Zj.w.r.degoedeStatus of integrating autuv work into vorbis?Hi,
I'm the Fedora maintainer of the ogg / vorbis / theora stack in Fedora. While cleaning up old bugs I encountered this one:
https://bugzilla.redhat.com/show_bug.cgi?id=204280
This is a request by an end user to include the aotuv rel...Hi,
I'm the Fedora maintainer of the ogg / vorbis / theora stack in Fedora. While cleaning up old bugs I encountered this one:
https://bugzilla.redhat.com/show_bug.cgi?id=204280
This is a request by an end user to include the aotuv release 1 patch in our libvorbis packages. I've noticed that aotuv beta2 was integrated in libvorbis-1.1.x are there any plans to integrate the improvements made by aotuv past beta2?
If not why not? Are the known problems with aotuv release 1? Does it produce 100% compatible ogg files?
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1241Floating point error on encoding PCM sample file2017-04-08T10:59:08ZscratFloating point error on encoding PCM sample fileThe procedure fit_line in floor1.c consistently throws a floating point error: divide by zero with the attached sample file.
The problem seems to be in "double denom=1./(an*fx2-fx*fx);"
I changed it to:
double denom = 1.;
double a;
d...The procedure fit_line in floor1.c consistently throws a floating point error: divide by zero with the attached sample file.
The problem seems to be in "double denom=1./(an*fx2-fx*fx);"
I changed it to:
double denom = 1.;
double a;
double b;
a = an*fx2-fx*fx;
if (a > 0.) denom= 1. / a;
This fixes the FP error, but it probably screws up something else. Have seen
this bug for a while in various releases.
Compiled the vorbis-static + vorbis_enc_static + vorbisfile_static libraries with
MS VC++ 6.0 using the .bat files in the v1.20 distribution. Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1236vorbisfile.h causes compiler warnings in client code2017-04-08T10:59:27ZGitlab Botvorbisfile.h causes compiler warnings in client codeAny code that includes vorbisfile.h, is compiled with warnings turned on but doesn't actually use the structs defined in the header file will generate warnings. The code which causes this is the static ov_callbacks structs: OV_CALLBACKS_...Any code that includes vorbisfile.h, is compiled with warnings turned on but doesn't actually use the structs defined in the header file will generate warnings. The code which causes this is the static ov_callbacks structs: OV_CALLBACKS_DEFAULT, OV_CALLBACKS_NOCLOSE, OV_CALLBACKS_STREAMONLY and OV_CALLBACKS_STREAMONLY_NOCLOSE.
Many developers like to compile with warnings turned on and many even like to use -Werror (which turns warnings into errors) during development. However, any code that includes <vorbisfile.h> cannot be commpiled with -Werror.
Monty's comment in the file says that these structs are defined as static as a workaround required on windows. Supporting windows is a good thing, but the current solution is not good enough.
One possible solution would be to enclose the definitions of these structs inside:
```
#ifdef EXPOSE_OV_CALLBACKS
#endif
```
People who use these structs can then define EXPOSE_OV_CALLBACKS before including vorbisfile.h.
It would be interesting to hear from windows developers who might be able to come up with other possible solutions to this problem.
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1232[PATCH] Add -Wdeclaration-after-statement to CFLAGS2017-04-08T10:58:44Zmle[PATCH] Add -Wdeclaration-after-statement to CFLAGSgcc-4.1 seems to default to conforming to the C99 standard which allows declarations after statements, ie
```
void whatever (int param)
{
if (param == 0)
return ;
int a = 10 ;
return a ;
}
```
The above is reported as...gcc-4.1 seems to default to conforming to the C99 standard which allows declarations after statements, ie
```
void whatever (int param)
{
if (param == 0)
return ;
int a = 10 ;
return a ;
}
```
The above is reported as an error in compilers which conform to earlier C standards.
The problem is that anyone working with a C99 compiler can accidentally commit code that breaks the compile for some other compilers.
The solution (at least for C99) is to compile with the -Wdeclaration-after-statement CFLAG, but not all versions of gcc recognise that flag. Fortunately its possible to detect whether gcc accepts this CFLAG at configure time.
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1229Vorbis encoding bug on amd642017-04-08T10:59:08ZGitlab BotVorbis encoding bug on amd64I have a very simple floating point WAV file (mono, 2048 samples, 16kHz sample rate) that gets really screwed up when encoded with libvorbis on an amd64 CPU. The problem does not exist on ia32.
The bug does exist both in SVN head and wi...I have a very simple floating point WAV file (mono, 2048 samples, 16kHz sample rate) that gets really screwed up when encoded with libvorbis on an amd64 CPU. The problem does not exist on ia32.
The bug does exist both in SVN head and with oggenc v1.0.2 although it isn't an oggenc bug because it manifests itself with using libogg/libvorbis/libvorbisenc directly.
I'll attached the file (vorbis_enc_bug_on_amd64.wav) after submitting the bug.
Reproducing the bug with oggenc can be done as follows:
oggenc vorbis_enc_bug_on_amd64.wav -o a.oga
oggdev a.oga a.wav
Now compare the original with WAV file with the output and you will notice that the output has a bunch of grabage (noise) at the start of the file. I'll attach an image of input and output as well.
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1228[Patch] Const correct tags functions2017-04-08T10:58:44Zmle[Patch] Const correct tags functionsI tend to compile my code with all GCC warnings turned on. However,
when I do this :
vorbis_comment_add_tag(&vdata->vc,"ENCODER","libsndfile");
I get the following warning messages:
warning: passing argument 2 of 'vorbis_comme...I tend to compile my code with all GCC warnings turned on. However,
when I do this :
vorbis_comment_add_tag(&vdata->vc,"ENCODER","libsndfile");
I get the following warning messages:
warning: passing argument 2 of 'vorbis_comment_add_tag' discards
qualifiers from pointer target type
warning: passing argument 3 of 'vorbis_comment_add_tag' discards
qualifiers from pointer target type
The problem is that string literals like "ENCODER" are be const
char * while vorbis_comment_add_tag is prototyped as having char *
pointers, even though the strings pointed to are not modified.
The following patch (against SVN head) makes the libvorbis const
correct.
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1204bad quality2017-04-08T10:58:44Zselindosbad qualityAt decoding ogg in wav and then coding in ogg very bad quality. Please correct a mistakeAt decoding ogg in wav and then coding in ogg very bad quality. Please correct a mistakeMonty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1159floor 0 decode specification refers to undefined omega2017-04-08T11:08:16Zsean2floor 0 decode specification refers to undefined omegaSection 6.2.3 of the vorbis specification, step 2 of the LSP output synthesis, uses the value 'cos(w)' (omega), but never defines omega anywhere (I think). Difficult to search for omega in the document, as it probably only appears in ima...Section 6.2.3 of the vorbis specification, step 2 of the LSP output synthesis, uses the value 'cos(w)' (omega), but never defines omega anywhere (I think). Difficult to search for omega in the document, as it probably only appears in images. (And difficult to google for it to see if it has a common LSP meaning, too.)
I can't check the source since I'm writing a clean-room implementation.https://gitlab.xiph.org/xiph/vorbis/-/issues/1158impossible validation case in specification of floor02017-04-08T11:08:16Zsean2impossible validation case in specification of floor0(I'm not sure if this is the right component to assign specification bugs to, but there is no separate component for them.)
Section 6.2.1, floor header decode, says:
```
7) if any of [floor0_order], [floor0_rate], [floor0_bark_map_size...(I'm not sure if this is the right component to assign specification bugs to, but there is no separate component for them.)
Section 6.2.1, floor header decode, says:
```
7) if any of [floor0_order], [floor0_rate], [floor0_bark_map_size], [floor0_amplitude_bits],
[floor0_amplitude_offset] or [floor0_number_of_books] are less than zero, the stream is not decodable
```
This is not meaningful; all the variables listed above are indicated in the previous lines to be read as _unsigned_ values from the stream, so they couldn't possibly be less than 0.
https://gitlab.xiph.org/xiph/vorbis/-/issues/1142Vorbis encoder segfault2017-04-08T10:58:44ZrowenVorbis encoder segfaultI am getting an access violation from libvorbis while encoding. I'm using libvorbis-1.1.2, but I have tried the latest subversion code (as of 3/5/07) without any improvement. Unfortunately, I can't duplicate the problem with the debug ...I am getting an access violation from libvorbis while encoding. I'm using libvorbis-1.1.2, but I have tried the latest subversion code (as of 3/5/07) without any improvement. Unfortunately, I can't duplicate the problem with the debug build of the library, so I can't give a full backtrace.
Here are the details that I have:
The error is an access violation reading 0x00FCD818
My code is based on the encoder example included with libvorbis, with some light modifications - the largest being that a fixed bitrate is used instead of vbr. With my code built in debug mode, but the libraries built in release mode, I can trace the access violation to the vorbis_analysis function - which I think is kind of a dispatch function, so thats probably not much help.
I'm building on Windows XP Pro SP2 with VC++ express edition 2005 (8.0.507727.42). I'm using the win32/build_vorbis_dynamic.bat and the other included .bat files to build DLLs for vorbis, vorbisenc, vorbisfile, and ogg.
I have built a stand-alone executable that can duplicate the problem with some test audio data. The stand-alone program is also based off of encoder_example.c and simply encodes some test audio data in a similar way to what my application does.
There are two audio streams used in my test program:
One is raw 16-bit PCM audio data with a sample rate of 44100.
The other is the same audio stream, resampled to 22050 samples per second (still 16-bit PCM).
The bug only seems to occur if the 44100 sample is encoded with a bit rate of 48, and then the 22050 sample is encoded twice with a bit rate of 32.
I don't see a way to attach files to a ticket, so send me an email and I can send you the test app and test data.Monty MontgomeryMonty Montgomeryhttps://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 Montgomery