Vorbis issueshttps://gitlab.xiph.org/xiph/vorbis/-/issues2017-11-01T04:49:44Zhttps://gitlab.xiph.org/xiph/vorbis/-/issues/2038Vorbis borks a pure 440Hz sine wave at the highest quality level2017-11-01T04:49:44ZArtem S. TashkinovVorbis borks a pure 440Hz sine wave at the highest quality levelA test case:
```
oggenc -q10 *wav
WARNING: quality setting too high, setting to maximum quality.
Opening with wav module: WAV file reader
Encoding "01_440hz Tone.wav" to
"01_440hz Tone.ogg"
at quality 10.00
[ 99.9%] [ 0...A test case:
```
oggenc -q10 *wav
WARNING: quality setting too high, setting to maximum quality.
Opening with wav module: WAV file reader
Encoding "01_440hz Tone.wav" to
"01_440hz Tone.ogg"
at quality 10.00
[ 99.9%] [ 0m00s remaining] /
Done encoding file "01_440hz Tone.ogg"
File length: 14m 42.0s
Elapsed time: 0m 09.2s
Rate: 95.4935
Average bitrate: 26.0 kb/s
```
Components versions:
```
$ rpm -qa | grep vorbis
libvorbis-1.3.4-2.el6.i686
libvorbis-devel-1.3.4-2.el6.i686
vorbis-tools-1.4.0-16.el6.i686
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/339ov_read() should default to native byte order2017-04-08T10:59:27ZMichel Daenzerov_read() should default to native byte order```
Currently, the bigendianp parameter to ov_read() only takes little or big endian
as arguments, and the documentation recommends little endian as a typical value.
In my experience though, this tends to cause problems on big endian sys...```
Currently, the bigendianp parameter to ov_read() only takes little or big endian
as arguments, and the documentation recommends little endian as a typical value.
In my experience though, this tends to cause problems on big endian systems, the
vast majority of apps need the data to be in native byte order, in particular
those that process the data after decoding.
```Monty MontgomeryMonty Montgomeryhttps://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/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/1555[PATCH] add some newline chars2017-04-08T10:58:44ZEldar[PATCH] add some newline charsMonty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/290ftell() callback uses long instead ogg_int64_t2017-04-08T10:59:27Zpeterftell() callback uses long instead ogg_int64_t```
ftell callback (see: ov_open_callbacks(), etc) returns "long" type instead
of "ogg_int64_t", preventing 2gb+ file sizes from being handled correctly.
``````
ftell callback (see: ov_open_callbacks(), etc) returns "long" type instead
of "ogg_int64_t", preventing 2gb+ file sizes from being handled correctly.
```Monty 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/527nightly snapshots not being built2017-04-08T11:08:16ZGhost Usernightly snapshots not being built```
since the server move (and possibly since the move to svn) the nightly
snapshots/builds haven't been generated.
Please sort out what all the expected links are and post them to this bug. Then
we can get them going again and possibly...```
since the server move (and possibly since the move to svn) the nightly
snapshots/builds haven't been generated.
Please sort out what all the expected links are and post them to this bug. Then
we can get them going again and possibly consolidate/rationalize a bit. Should
these all move to xiph.org? everything but icecast?
apparently there were icecast nightlies at http://xiph.org/~brendan/
```https://gitlab.xiph.org/xiph/vorbis/-/issues/1344Leak after ov_read_float2017-04-08T10:59:27Zchris.r.waltonLeak after ov_read_floatI'm on Windows, using MSVC8.
If using ov_read_float instead of ov_read on an OggVorbis_File, there are exactly 228 leaks. I can confirm that the OggVorbis_File is being ov_clear()-ed correctly. All the leaks happen in res0_look, most of...I'm on Windows, using MSVC8.
If using ov_read_float instead of ov_read on an OggVorbis_File, there are exactly 228 leaks. I can confirm that the OggVorbis_File is being ov_clear()-ed correctly. All the leaks happen in res0_look, most of them are 8 or 12 bytes, with a few larger allocations. I've attached the output of VLD which describes the leaks. Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/296[PATCH] Runtime DLL used in Debug Mode2017-04-08T10:58:44ZGitlab Bot[PATCH] Runtime DLL used in Debug Mode```
The DSP for this project is compiled against the DLL runtime library in debug. A
release build uses the static runtime library. This is at worst an annoying
inconsistency, but really should runtime use the static library as most
deve...```
The DSP for this project is compiled against the DLL runtime library in debug. A
release build uses the static runtime library. This is at worst an annoying
inconsistency, but really should runtime use the static library as most
developers (IMHO) use this under Win32.
The change is simple: "Project Settings" -> "C/C++" -> "Code Generation" and set
"Use run-time library" to "debug multithreaded" on "vorbis_static.dsp",
"vorbisenc_static.dsp" and "vorbisfile_static.dsp".
This is an update against the version in CVS on 6/12/02.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/52vorbis/lib/envelope.c causes gcc internal error2017-04-08T10:58:44Zaltair1710vorbis/lib/envelope.c causes gcc internal error```
When using gcc 2.95.3 on i686-pc-linux-gnu, vorbis/lib/envelope.c causes gcc to
emit:
"gcc:Internal compiler error: program cc1 got fatal signal 11"
This error is present in rc1, rc2 and current cvs sources.
The full command used ...```
When using gcc 2.95.3 on i686-pc-linux-gnu, vorbis/lib/envelope.c causes gcc to
emit:
"gcc:Internal compiler error: program cc1 got fatal signal 11"
This error is present in rc1, rc2 and current cvs sources.
The full command used in compile is:
/usr/bin/gcc -DPACKAGE=\"libvorbis\" -DVERSION=\"1.0rc2\" -DHAVE_DLFCN_H=1
-DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_SQRTF=1 -DHAVE_LOGF=1 -DHAVE_EXPF=1
-DHAVE_ACOSF=1 -DHAVE_ATANF=1 -DHAVE_FREXPF=1 -DHAVE_RINTF=1 -I. -I.
-I../include -O20 -ffast-math -mno-ieee-pf -D_REENTRANT -fsigned-char
-march=i686 -O3 -DUSE_MEMORY_H -c envelope.c -Wp,-MD,.deps/envelope.TPlo -fPIC
-DPIC -o .libs/envelope.lo
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/166ov_clear()2017-04-08T10:59:27Zcomrade2kov_clear()```
ov_open(), and ov_read() and then play the data for a few seconds. Call ov_clear
() -> crash!
``````
ov_open(), and ov_read() and then play the data for a few seconds. Call ov_clear
() -> crash!
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/237sound quality in high voice2017-04-08T10:58:44Zvgaborsound quality in high voice```
I have encoded more times (wav to ogg , ogg to wav). After these the high voices
increase.I use -q 4 and iterate 5 time. The difference is good audible. Lower
quality is more audible, in -q 7 iterate 10 audible too.
My libvorbis is 1...```
I have encoded more times (wav to ogg , ogg to wav). After these the high voices
increase.I use -q 4 and iterate 5 time. The difference is good audible. Lower
quality is more audible, in -q 7 iterate 10 audible too.
My libvorbis is 1.0.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/257OggEnc gives bad quality with synthetic speech2017-04-08T10:58:44ZtgirmannOggEnc gives bad quality with synthetic speech```
Ogg Vorbis introduces lots of noise into the voice. The problem is easy to hear
at -q 3 and -q 5; at -q 7 it sounds almost okay; here the biggest problem (easy
to hear in direct comparison) is that the heights got a bit louder.
I've...```
Ogg Vorbis introduces lots of noise into the voice. The problem is easy to hear
at -q 3 and -q 5; at -q 7 it sounds almost okay; here the biggest problem (easy
to hear in direct comparison) is that the heights got a bit louder.
I've tried other encoders too; at the same bit rates MP3 (LAME version 3.92 MMX)
suffers from similar problems but it sounds better (when using vbr) while
Musepack sounds almost perfectly.
(side note: when forcing LAME to 128 kbit/s the quality is really bad)
As I selected quality I want oggenc to allocate enough bits to achieve the
desired quality.
See attachment for reverence WAV and Ogg Vorbis examples.
(Yes I'm using OggEnc v1.0 (libvorbis 1.0))
```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 Montgomery