Vorbis issueshttps://gitlab.xiph.org/xiph/vorbis/-/issues2017-04-08T10:59:27Zhttps://gitlab.xiph.org/xiph/vorbis/-/issues/184ov_open use C-like FILE structure for work with files, is badly. Other langua...2017-04-08T10:59:27Zxakepov_open use C-like FILE structure for work with files, is badly. Other language (example: pascal) stop use of ov_open :(```
Sorry for bad english .. :(
ov_open function is require FILE *f in parameters for normal work.
Why ov_open don't use handle of file? Is fully compatible with any language.
What's wrong?
My program in pascal (delphi) is crashing n...```
Sorry for bad english .. :(
ov_open function is require FILE *f in parameters for normal work.
Why ov_open don't use handle of file? Is fully compatible with any language.
What's wrong?
My program in pascal (delphi) is crashing now.
Problem with interpretated of FILE structure in Delphi (Pascal). Size of FILE
(in C) is 32 byte, but size of analogue FILE structure in Pascal-like is more
than 256. GPF is correct :))
I recommend fix this problem, or help me with fix ov_open in NON C like
languages. Maybe i have curved hands? :))
Thanks for support.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/182_vorbis_block_alloc assumes _ogg_malloc aligns to at least WORD_ALIGN2017-04-08T10:58:44ZGitlab Bot_vorbis_block_alloc assumes _ogg_malloc aligns to at least WORD_ALIGN```
To guarantee WORD_ALIGN alignment, you need to align the pointer after
calling _ogg_malloc(), or _ogg_realloc().
If you are doing cache tuning, you might want to push WORD_ALIGN fairly
high, like 16 or 32 depending on the cache ar...```
To guarantee WORD_ALIGN alignment, you need to align the pointer after
calling _ogg_malloc(), or _ogg_realloc().
If you are doing cache tuning, you might want to push WORD_ALIGN fairly
high, like 16 or 32 depending on the cache architecture.
possible patch:
*** block.c 2002/03/29 07:34:09 1.64
--- block.c 2002/04/12 11:02:00
***************
*** 115,120 ****
--- 115,122 ----
/* highly conservative */
vb->localalloc=bytes;
vb->localstore=_ogg_malloc(vb->localalloc);
+ vb->localstore=(void*)(((long)((char*)vb->localstore+
+ (WORD_ALIGN-1))) & ~(WORD_ALIGN-1));
vb->localtop=0;
}
{
***************
*** 137,143 ****
}
/* consolidate storage */
if(vb->totaluse){
! vb->localstore=_ogg_realloc(vb->localstore,vb->totaluse+vb->
localalloc);
vb->localalloc+=vb->totaluse;
vb->totaluse=0;
}
--- 139,148 ----
}
/* consolidate storage */
if(vb->totaluse){
! long tot=(vb->totaluse+vb->localalloc+(WORD_ALIGN-1)) &
~(WORD_ALIGN-1);
! vb->localstore=_ogg_realloc(vb->localstore,tot);
! vb->localstore=(void*)(((long)((char*)vb->localstore+
! (WORD_ALIGN-1))) & ~(WORD_ALIGN-1));
vb->localalloc+=vb->totaluse;
vb->totaluse=0;
}
It may be better to define a macro that does the alignment.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/171vorbis does not work on KDE 3.02017-04-08T10:59:27Zmvogtvorbis does not work on KDE 3.0```
On Tue, Mar 19, 2002 at 07:47:20PM +1100, Michael Smith wrote:
> At 10:45 AM 3/18/02 +0100, you wrote:
> >
> >
> >Hello,
> >
> >the appended Patch makes vorbis work on KDE 3.0.(again)
> >
> >The bug is that the goto s...```
On Tue, Mar 19, 2002 at 07:47:20PM +1100, Michael Smith wrote:
> At 10:45 AM 3/18/02 +0100, you wrote:
> >
> >
> >Hello,
> >
> >the appended Patch makes vorbis work on KDE 3.0.(again)
> >
> >The bug is that the goto seek_error calls in ov_pcm_seek_page
> >do not set the return value in the error case.
> >
> Though there may be (it looks like there is) a bug here, this
> fix is definately incorrect (you've changed it to return the
> wrong error code - which in the buggy cases is better than no
> error code, admittedly). I'll take a closer look and see
> if I can fix it properly.
>
It was a quick and dirty fix, I know. But before I started
to make a cleaner one, I like to have a feedback that
its actually a bug.
> Your reasoning doesn't entirely make sense, in that the
> goto seek_error calls are never reached if the stream has
> been closed (as you say it has been in this case). Sounds
> like there's a nasty bug in your multimedia player as well.
>
I can explain the situation, it has to do with threads.
Vorbis decodes in its own thread and reads from the
callbacks the input data.
User presses "stop" in the player, then the "GUI" thread
closes the input fd. (stream is closed)
If vorbis is doing a seek this "race" occurs:
Row 1027
int ov_pcm_seek_page(OggVorbis_File *vf,ogg_int64_t pos){
int link=-1,ret=0; <- default to "success"
[...]
Row 1086
// here the stream is closed by the other thread (GUI)
result=_get_next_page(vf,&og,end-vf->offset);
// vorbis sees the "closed stream"
if(result==OV_EREAD) goto seek_error;
Row 1175
Row 1175
seek_error:
/* dump machine so we're in a known state */
vf->pcm_offset=-1;
_decode_clear(vf);
return ret; <- RETURN SUCESS !
ret has the value "0" here, although an error occured.
Because the _decode_clear(vf); frees internal structures but
does not indicate the error to the higher functions the
later code segfaults.
No, the current CVS commit:(1.60)
granulepos-=vf->pcmlengths[link*2];
---
>
> if(vf->seekable && link>0)
> granulepos-=vf->pcmlengths[link*2];
did not fix the bug.
This is my segfault:
KDE sound server:
[kde@mv kde]$ artsd -S 4096 -F 10
read on not open file want:8500
Segmentation fault
Command line KDE player:
[kde@mv lib]$ mpeglibartsplay -2 /mnt/diskD/save/ogg/Marque.ogg
cnt:0
Segmentation fault
The -2 is a stresstest to trigger the mentioned race.
You see that "read on not open file want:8500" is vorbis decode
thread, while the gui cloesed the fd.
(The "stresstest" is a common case in the kde player, thus
stresstest is a wrong name)
>Can you file this bug at http://bugs.xiph.org (bugzilla)
done.
regards,
Martin
```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/162libvorbis 1.0rc3 crashes gcc 2.95.3-2 on an i686 PC Linux 2.4.16 with glibc 2...2017-04-08T10:58:44Zfrantzlibvorbis 1.0rc3 crashes gcc 2.95.3-2 on an i686 PC Linux 2.4.16 with glibc 2.2.4```
Hi,
I have an i686 PC using Linux version 2.4.16, glibc version 2.2.4, gcc version
2.95.3 with the 2.95.3-2 patch.
I have successfuly compiled libao 0.8.2 and libogg 1.0rc3, but when trying to
compile libvorbis 1.0rc3 the compiler gi...```
Hi,
I have an i686 PC using Linux version 2.4.16, glibc version 2.2.4, gcc version
2.95.3 with the 2.95.3-2 patch.
I have successfuly compiled libao 0.8.2 and libogg 1.0rc3, but when trying to
compile libvorbis 1.0rc3 the compiler gives me the following error:
/bin/sh ../libtool --mode=compile gcc -DPACKAGE=\"libvorbis\" -DVERSION=\"1.0rc3\" -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-fp -D_REENTRANT -fsigned-char -Os -mcpu=i686 -march=i686 -DUSE_MEMORY_H -c envelope.c
gcc -DPACKAGE=\"libvorbis\" -DVERSION=\"1.0rc3\" -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-fp -D_REENTRANT -fsigned-char -Os -mcpu=i686 -march=i686 -DUSE_MEMORY_H -c envelope.c -fPIC -DPIC -o envelope.lo
gcc: Internal compiler error: program cc1 got fatal signal 11
make[2]: *** [envelope.lo] Error 1
make[2]: Leaving directory `/usr/local/src/libvorbis-1.0rc3/lib'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/local/src/libvorbis-1.0rc3/lib'
make: *** [all-recursive] Error 1
I have also tried unsetting the -Os -mcpu=i686 -march=i686 CFLAGS before the
./configure command, but the compiler continues crashing at the same point.
What can I do in order to make the libvorbis package compile correctly?
Thanks
Franco -- frantz@sitoverde.com
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/161-b -M does not fill in max bitrate field2017-04-08T10:58:44Zgreg-b -M does not fill in max bitrate field```
$ oggenc -b 128 -M 130 -o test2.ogg file.wav
$ hex test2.ogg | head -10
0x00000000: 4f 67 67 53 00 02 00 00 - 00 00 00 00 00 00 2a 0d OggS..........*.
0x00000010: 72 54 00 00 00 00 2d 01 - 74 8a 01 1e 01 76 6f 72 rT....-.t....vor
0x...```
$ oggenc -b 128 -M 130 -o test2.ogg file.wav
$ hex test2.ogg | head -10
0x00000000: 4f 67 67 53 00 02 00 00 - 00 00 00 00 00 00 2a 0d OggS..........*.
0x00000010: 72 54 00 00 00 00 2d 01 - 74 8a 01 1e 01 76 6f 72 rT....-.t....vor
0x00000020: 62 69 73 00 00 00 00 02 - 44 ac 00 00 ff ff ff ff bis.....D.......
0x00000030: 1f f4 01 00 ff ff ff ff - b8 01 4f 67 67 53 00 00 ..........OggS..
The min/max bitrate fields are still "ff ff ff ff" (-1). The nominal bitrate
field is correctly set to "1f f4 01 00" (128031).
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/154Raw seeking in small ogg files isnt working2017-04-08T10:59:27Zd00jkrRaw seeking in small ogg files isnt working```
When using seeking_example on the test ogg-file, something goes wrong:
loading....
testing raw seeking to random places in 4148 bytes....
172 [raw position 17]...data position after seek doesn't match pcm position
In my game i...```
When using seeking_example on the test ogg-file, something goes wrong:
loading....
testing raw seeking to random places in 4148 bytes....
172 [raw position 17]...data position after seek doesn't match pcm position
In my game im using a mixer that decodes data from diff. ogg streams. I need to
be able to take a "stamp" of where i am currently in a stream, and then be able
to jump back to it later. The streams are relatively small, (about 5000 bytes in
the OggVorbis format) , Im trying to use ov_raw_seek and ov_raw_tell, but they
somehow give me wrong values. ov_pcm_tell and ov_pcm_seek work fine (but they
are too slow)
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/143Memory leak2017-04-08T10:58:44ZGitlab BotMemory leak```
The function static decode_aux *_make_decode_tree(codebook *c) in the
file "SharedBook.c" has a major memory leak. It calls calloc() twice,
storing the pointers to ptr0 and ptr1. However, nowhere in the code is
there a call to fre...```
The function static decode_aux *_make_decode_tree(codebook *c) in the
file "SharedBook.c" has a major memory leak. It calls calloc() twice,
storing the pointers to ptr0 and ptr1. However, nowhere in the code is
there a call to free(). As a result, this function will leak the two blocks of
memory every time it is called.
Should be a 15 minute fix.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/134examples don't compile with C902017-04-08T10:58:44Zpapadopoexamples don't compile with C90```
Hi,
I suggest you use C90 /**/ comments instead of C99 // comments so that
vorbis compiles on older UNIX which lack a C99 compiler. Using the Sun
Workshop 5.0 compiler:
gmake[1]: Entering directory `/tmp/libvorbis-1.0rc3/examples'
...```
Hi,
I suggest you use C90 /**/ comments instead of C99 // comments so that
vorbis compiles on older UNIX which lack a C99 compiler. Using the Sun
Workshop 5.0 compiler:
gmake[1]: Entering directory `/tmp/libvorbis-1.0rc3/examples'
[..]
cc -DPACKAGE=\"libvorbis\" -DVERSION=\"1.0rc3\" -DHAVE_DLFCN_H=1
-DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DHAVE_SQRTF=1 -I. -I. -I../include
-I/usr/local/libogg/include -xO4 -fast -w -fsimple -native -xcg92 -fast
-DUSE_MEMORY_H -c encoder_example.c
"encoder_example.c", line 100: syntax error before or at: /
cc: acomp failed for encoder_example.c
```Segher BoessenkoolSegher Boessenkoolhttps://gitlab.xiph.org/xiph/vorbis/-/issues/128vibrating distortion artifact (perhaps channel coupling related)2017-04-08T10:59:08Znoavibrating distortion artifact (perhaps channel coupling related)```
I have encountered an annoying artifact in rc3 that could be described as a
pumping or vibrating distortion. In the beginning of the provided sample the
artifact is easily noticed in the left channel, but later in the sample i belive...```
I have encountered an annoying artifact in rc3 that could be described as a
pumping or vibrating distortion. In the beginning of the provided sample the
artifact is easily noticed in the left channel, but later in the sample i belive
it is somewhat to the right in the stereo image.
The artifact dissapears somewhere around quality 9.0 and it does not exist in rc2.
I use the standard rpms rebuilt on a redhat-7.2 system with full errata
(gcc-2.96-98)
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/114Clicks appear in encoded file2017-04-08T10:59:08ZchungycClicks appear in encoded file```
A lot of clicks appear when I encode this sound track I have. It starts being
noticeable below quality settings of 5.5, is quite annoying at 5 (which I've
been using as the default setting), and causes me to emit a stream of
four-le...```
A lot of clicks appear when I encode this sound track I have. It starts being
noticeable below quality settings of 5.5, is quite annoying at 5 (which I've
been using as the default setting), and causes me to emit a stream of
four-letter words by the time I lower it to 3.
I'm using the rc3 package in Debian unstable.
A two second sample of the relevant portion is available at the URL above.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/113vorbis_encode_setup_managed guesses bitrate after calculating quality factor2017-04-08T10:59:08ZGitlab Botvorbis_encode_setup_managed guesses bitrate after calculating quality factor```
Here's the patch:
=========================================================
==========
RCS file: /usr/local/cvsroot/vorbis/lib/vorbisenc.c,v
retrieving revision 1.33
diff -c -r1.33 vorbisenc.c
*** vorbisenc.c 2001/12/23 11:53:53 ...```
Here's the patch:
=========================================================
==========
RCS file: /usr/local/cvsroot/vorbis/lib/vorbisenc.c,v
retrieving revision 1.33
diff -c -r1.33 vorbisenc.c
*** vorbisenc.c 2001/12/23 11:53:53 1.33
--- vorbisenc.c 2002/01/03 08:51:44
***************
*** 914,936 ****
long nominal_bitrate,
long min_bitrate){
! double tnominal=nominal_bitrate;
! double approx_vbr=approx_bitrate_to_vbr(channels,(channels==2),
! (float)nominal_bitrate,rate);
int ret=0;
! if(approx_vbr<0)return(OV_EIMPL);
!
! if(nominal_bitrate<=0.){
! if(max_bitrate>0.){
! nominal_bitrate=max_bitrate*.875;
}else{
! if(min_bitrate>0.){
! nominal_bitrate=min_bitrate;
}else{
return(OV_EINVAL);
}
}
}
ret=vorbis_encode_setup_vbr(vi,channels,rate,approx_vbr);
if(ret){
--- 914,938 ----
long nominal_bitrate,
long min_bitrate){
! float tnominal=nominal_bitrate;
! double approx_vbr;
int ret=0;
!
! if(nominal_bitrate<=0){
! if(max_bitrate>0){
! tnominal=(float)max_bitrate*.875f;
}else{
! if(min_bitrate>0){
! tnominal=(float)min_bitrate;
}else{
return(OV_EINVAL);
}
}
}
+
+ approx_vbr=approx_bitrate_to_vbr(channels,(channels==2),
+ (float)tnominal,rate);
+ if(approx_vbr<0)return(OV_EIMPL);
ret=vorbis_encode_setup_vbr(vi,channels,rate,approx_vbr);
if(ret){
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/103Abnormal encoded average bitrate on second file when two files given2017-04-08T10:59:08ZjonofAbnormal encoded average bitrate on second file when two files given```
As can be seen in the output below. When encoding the 'main.wav' seperately, the
output average bitrate is as would be expected, but adding 'loader.wav' before
it causes the same file to dramatically lose bitrate.
D:\Download\farb-...```
As can be seen in the output below. When encoding the 'main.wav' seperately, the
output average bitrate is as would be expected, but adding 'loader.wav' before
it causes the same file to dramatically lose bitrate.
D:\Download\farb-rausch>c:\vorbis\oggenc -b 80 main.wav
Opening with wav module: WAV file reader
Encoding "main.wav" to
"main.ogg" at bitrate 80 kbps
Encoding with managed bitrates.
[100.0%] [ 0m00s remaining] -
Done encoding file "main.ogg"
File length: 11m 00.0s
Elapsed time: 2m 29.0s
Rate: 4.4308
Average bitrate: 72.6 kb/s
D:\Download\farb-rausch>c:\vorbis\oggenc -b 80 loader.wav main.wav
Opening with wav module: WAV file reader
Encoding "loader.wav" to
"loader.ogg" at bitrate 80 kbps
Encoding with managed bitrates.
[ 99.9%] [ 0m00s remaining] -
Done encoding file "loader.ogg"
File length: 3m 36.0s
Elapsed time: 0m 47.0s
Rate: 4.6005
Average bitrate: 79.7 kb/s
Opening with wav module: WAV file reader
Encoding "main.wav" to
"main.ogg" at bitrate 80 kbps
Encoding with managed bitrates.
[100.0%] [ 0m00s remaining] /
Done encoding file "main.ogg"
File length: 11m 00.0s
Elapsed time: 2m 27.0s
Rate: 4.4911
Average bitrate: 55.8 kb/s
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis/-/issues/93OpenBSD 3.0: extra parameter to vorbis/configure needed for mindless building2017-04-08T10:58:44ZnisharfiOpenBSD 3.0: extra parameter to vorbis/configure needed for mindless building```
configure, on OpenBSD, requires --with-ogg=/usr/local/ added on since
neither /usr/local/include nor /usr/local/lib are in the #include or link pool
by default.
``````
configure, on OpenBSD, requires --with-ogg=/usr/local/ added on since
neither /usr/local/include nor /usr/local/lib are in the #include or link pool
by default.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/92vorbis/autogen.sh has two unpaired quote marks diff file here2017-04-08T10:58:44Znisharfivorbis/autogen.sh has two unpaired quote marks diff file here```
--- autogen.sh Thu Aug 23 10:39:54 2001
+++ autogen.sh.new Thu Dec 20 16:33:26 2001
@@ -21,7 +21,7 @@
(automake --version) < /dev/null > /dev/null 2>&1 || {
echo
echo "You must have automake installed to compile $p...```
--- autogen.sh Thu Aug 23 10:39:54 2001
+++ autogen.sh.new Thu Dec 20 16:33:26 2001
@@ -21,7 +21,7 @@
(automake --version) < /dev/null > /dev/null 2>&1 || {
echo
echo "You must have automake installed to compile $package."
- echo "Download the appropriate package for your system,
+ echo "Download the appropriate package for your system,"
echo "or get the source from one of the GNU ftp sites"
echo "listed in http://www.gnu.org/order/ftp.html"
DIE=1
@@ -30,7 +30,7 @@
(libtool --version) < /dev/null > /dev/null 2>&1 || {
echo
echo "You must have libtool installed to compile $package."
- echo "Download the appropriate package for your system,
+ echo "Download the appropriate package for your system,"
echo "or get the source from one of the GNU ftp sites"
echo "listed in http://www.gnu.org/order/ftp.html"
DIE=1
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/89ov_open can loop infinitely.2017-04-08T10:59:27Zroconnorov_open can loop infinitely.```
I created a partial Vorbis file. This file causes oggplay to go into an
infinite loop when trying to play the file.
``````
I created a partial Vorbis file. This file causes oggplay to go into an
infinite loop when trying to play the file.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/88Serious encoding flaws with certain music2017-04-08T10:59:08ZultimaSerious encoding flaws with certain music```
I've discovered that OGG RC2 does a piss-poor job (to put it lightly) of
encoding wavs derived from SNES music files. Lame MP3, by comparison, does an
excellent job. I felt that this deserved a bug report.
Here is the URL of a ZIP...```
I've discovered that OGG RC2 does a piss-poor job (to put it lightly) of
encoding wavs derived from SNES music files. Lame MP3, by comparison, does an
excellent job. I felt that this deserved a bug report.
Here is the URL of a ZIP file which contains the 128-kbit OGG, and the 128-bit
ABR LAME MP3. I'd also upload the WAV file but I'll wait for your feedback
first, as its 5 megs and I'm on 56K.
http://ultima.unrealpc.com/oggprob.zip
The file is
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/87Access violation for 1 channel (mono) wave files2017-04-08T10:58:44ZbenAccess violation for 1 channel (mono) wave files```
I downloaded the vorbis_nightly_cvs.tar.gz on 29 Nov 2001 and built it.
running oggenc is fine for stereo wave files, but for mono, I get an exception
in file vorbis/lib/psy.c, in function:
_vp_quantize_couple(vorbis_look_psy * 0x007...```
I downloaded the vorbis_nightly_cvs.tar.gz on 29 Nov 2001 and built it.
running oggenc is fine for stereo wave files, but for mono, I get an exception
in file vorbis/lib/psy.c, in function:
_vp_quantize_couple(vorbis_look_psy * 0x007b7e80, vorbis_info_mapping0 *
0x006a8dec, float * * 0x007089f8, float * * 0x0068f6fc, float * * 0x0068f700,
int * 0x0068f708, int 0) line 1021 + 32 bytes
in the following line:
float ang,mag,fmag=max(fabs(pcmM[j]),fabs(pcmA[j]));
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/86RC2 @ 160kB/s misencodes or misdecodes one specific file2017-04-08T10:58:44ZgumbootRC2 @ 160kB/s misencodes or misdecodes one specific file```
This applies to one specific file out of >1000, and only at 160kB/s with RC2,
but I can repeat it, using the Debian packages (latest for Woody).
Sound appears further left, while the right speaker occasionally pops and
squeaks. Som...```
This applies to one specific file out of >1000, and only at 160kB/s with RC2,
but I can repeat it, using the Debian packages (latest for Woody).
Sound appears further left, while the right speaker occasionally pops and
squeaks. Sometimes, if the file is stopped at the right point the speaker will
pop again (perhaps a DC component).
Email me and tell me where to upload/email the file or a segment of the file.
```Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/vorbis/-/issues/84overflow in vorbis_staticbook_unpack()2017-04-08T10:58:44ZSegher Boessenkooloverflow in vorbis_staticbook_unpack()```
...for length ordered books. the inner (j) loop should check for overflowing
the outer (i) loop.
``````
...for length ordered books. the inner (j) loop should check for overflowing
the outer (i) loop.
```Monty MontgomeryMonty Montgomery