Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2018-11-06T20:03:53Zhttps://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 Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1557[PATCH] DESTROY ALL TRAILING BLANKS2017-04-08T10:58:44ZEldar[PATCH] DESTROY ALL TRAILING BLANKSDestroy all trailing blanks from libVorbis source files.Destroy all trailing blanks from libVorbis source files.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1556[PATCH] surround _analysis_output() with #if 0..#endif preprocessor directives2017-04-08T10:58:44ZEldar[PATCH] surround _analysis_output() with #if 0..#endif preprocessor directivesreopened, because added a small patch, to change preprocessor directive from #if 0 to #ifdef ANALYSISreopened, because added a small patch, to change preprocessor directive from #if 0 to #ifdef ANALYSISMonty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1555[PATCH] add some newline chars2017-04-08T10:58:44ZEldar[PATCH] add some newline charsMonty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1549Vorbis floor0 lsp optimization impacts precision2017-04-08T10:58:44ZSiarhei SiamashkaVorbis floor0 lsp optimization impacts precisionIt might be a good idea to have better precision for those few
floor0 vorbis files that are available in the wild.
Additionally, if the primary purpose of libvorbis is to be a
good reference implementation, having code that produces res...It might be a good idea to have better precision for those few
floor0 vorbis files that are available in the wild.
Additionally, if the primary purpose of libvorbis is to be a
good reference implementation, having code that produces results
similar to any other correct vorbis decoder, developed by strictly
following vorbis specification can prevent some confusion.
This problem with precision was discovered when testing ffvorbis decoder.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1548output of vorbis 'decoder_example' is inconsistent with 'oggdec'2017-04-08T10:58:44ZSiarhei Siamashkaoutput of vorbis 'decoder_example' is inconsistent with 'oggdec'Conversion from float to int in 'decoder_example' is quite different from what is used in 'vorbis_ftoi' function. It's better to fix this inconsistency. Patch is attached.Conversion from float to int in 'decoder_example' is quite different from what is used in 'vorbis_ftoi' function. It's better to fix this inconsistency. Patch is attached.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1547vorbis_fpu_setround is broken2017-04-08T10:58:44ZSiarhei Siamashkavorbis_fpu_setround is broken'vorbis_fpu_setround' from 'os.h' does something weird. At least it does not do anything useful. It would probably make sense to have "andw" instruction instead of "orw" (to force rounding to nearest), but considering that the code was i...'vorbis_fpu_setround' from 'os.h' does something weird. At least it does not do anything useful. It would probably make sense to have "andw" instruction instead of "orw" (to force rounding to nearest), but considering that the code was in a broken state for ages and nobody cared, does it even have any sense to have this function at all?
There is also SSE2 code and it does not have vorbis_fpu_setround counterpart (that would be only a problem if it is really needed of course).
Additional information to consider is that FPU performs rounding to nearest, but ties to even (for example, 0.5 is rounded to 0). It means that code 'return (int)floor(f+.5)' from the generic path is not completely identical to x87/SSE2 optimized versions.
A testcase attached.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1541libvorbis: cleanup Vorbis_I_spec.tex2017-04-08T11:08:16ZMax Hornlibvorbis: cleanup Vorbis_I_spec.texThis patch cleans up doc/Vorbis_I_spec.tex, adds lots of comments, and tweaks the build rules to ensure Vorbis_I_spec.cfg is honored. It also changes the link color from red to blue, as requested by Monty :).This patch cleans up doc/Vorbis_I_spec.tex, adds lots of comments, and tweaks the build rules to ensure Vorbis_I_spec.cfg is honored. It also changes the link color from red to blue, as requested by Monty :).https://gitlab.xiph.org/xiph/vorbis/-/issues/1526vorbis encoder fails on ARM EABI systems - different output for same binary r...2017-04-08T10:59:08ZGitlab Botvorbis encoder fails on ARM EABI systems - different output for same binary run on different systemsPackage: libvorbis
Version: 1.2.0
The vorbis encoder does not work on ARM EABI systems, producing short .ogg files which are the right length in time, but decode to all zeros (silence).
Worse, the same binaries run on different ARM mac...Package: libvorbis
Version: 1.2.0
The vorbis encoder does not work on ARM EABI systems, producing short .ogg files which are the right length in time, but decode to all zeros (silence).
Worse, the same binaries run on different ARM machines produce different-length files of such garbage.
See http://bugs.debian.org/515949
Debian ARM EABI systems are available at the GCC compile farm, or I run a public-access one at n2100.martinwguy.co.uk - accounts on request to martinwguy@yahoo.it
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/1523Patch to fix vorbis docbook compilation on trunk2017-04-08T10:58:44ZMax HornPatch to fix vorbis docbook compilation on trunkCurrently, building the docs on trunk is broken. The attached patch corrects this. First off, I replace some PNGs with recompressed versions (I used advpng -z4; if you want, you can just run that on all PNG files in doc/ instead of copyi...Currently, building the docs on trunk is broken. The attached patch corrects this. First off, I replace some PNGs with recompressed versions (I used advpng -z4; if you want, you can just run that on all PNG files in doc/ instead of copying the ones I attached).
Then I changed Makefile.am to use fop instead of pdfxmltex to build the PDF file. This works pretty well (with the exception of the PNG weirdness I mentioned).
As far as I can tell, this is one of the major blockers for new libvorbis 1.2.x releases.Monty MontgomeryMonty Montgomery