Ogg issueshttps://gitlab.xiph.org/xiph/ogg/-/issues2021-08-17T08:18:26Zhttps://gitlab.xiph.org/xiph/ogg/-/issues/2302cwd autogen broken2021-08-17T08:18:26Zcjhih456cwd autogen brokenHello. I was using ogg install with my program.
So I was install with cwd child process.
But this error has been come.
```
configure.ac:5: installing './compile'
configure.ac:5: installing './config.guess'
configure.ac:5: installing './...Hello. I was using ogg install with my program.
So I was install with cwd child process.
But this error has been come.
```
configure.ac:5: installing './compile'
configure.ac:5: installing './config.guess'
configure.ac:5: installing './config.sub'
configure.ac:9: installing './install-sh'
configure.ac:5: error: required file './ltmain.sh' not found
configure.ac:9: installing './missing'
src/Makefile.am: installing './depcomp'
autoreconf: automake failed with exit status: 1
```
My project's informations.
- langauge: Nodejs
- child process function : exec
- os: Ubuntu 20.04.2 LTS (GNU/Linux 5.8.0-53-generic x86_64)
succeed pc
- langauge: Nodejs
- child process function : exec
- os: Ubuntu 20.04.2 LTS (GNU/Linux 5.8.0-50-generic x86_64)https://gitlab.xiph.org/xiph/ogg/-/issues/2300Check for overflow on growing buffer2020-08-09T22:44:22ZClément BœschCheck for overflow on growing bufferHi,
I came across this code while debugging an issue in libshout (https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2318), and it looked pretty unsafe to me: [0001-framing-check-for-overflow-on-growing-buffer.patch](/uploads/376286...Hi,
I came across this code while debugging an issue in libshout (https://gitlab.xiph.org/xiph/icecast-libshout/-/issues/2318), and it looked pretty unsafe to me: [0001-framing-check-for-overflow-on-growing-buffer.patch](/uploads/376286b5321247d4934f85e924bdb2be/0001-framing-check-for-overflow-on-growing-buffer.patch).
One could check that the `oy->storage<0` and similar checks are enough, but I still believe it's safer not to assign the invalid value in the first place.https://gitlab.xiph.org/xiph/ogg/-/issues/2297framing.c: overflow on left shift2019-03-06T21:34:00ZTristan Matthewsframing.c: overflow on left shiftThere's a regression since commit bc82844df068429d209e909da47b1f730b53b689:
```framing.c:239:19: runtime error: left shift of 211 by 24 places cannot be represented in type 'int'```
I found this while generating the corpus for speex wit...There's a regression since commit bc82844df068429d209e909da47b1f730b53b689:
```framing.c:239:19: runtime error: left shift of 211 by 24 places cannot be represented in type 'int'```
I found this while generating the corpus for speex with oss-fuzz:
```
git clone git@github.com:tmatth/oss-fuzz.git
cd oss-fuzz
python infra/helper.py build_image speex
python infra/helper.py build_fuzzers --sanitizer undefined speex
```https://gitlab.xiph.org/xiph/ogg/-/issues/2296docs for ogg_stream_state have wrong type on `pageno` field2019-08-13T15:58:40ZSpencer Russelldocs for ogg_stream_state have wrong type on `pageno` fieldIn the [header file](https://gitlab.xiph.org/xiph/ogg/blob/0acd32d7cabf7e41cc29ea7c2bbffde969ff1ba0/include/ogg/ogg.h#L76) the `pageno` field is a `long`, but in the [docs](https://gitlab.xiph.org/xiph/ogg/blob/0acd32d7cabf7e41cc29ea7c2b...In the [header file](https://gitlab.xiph.org/xiph/ogg/blob/0acd32d7cabf7e41cc29ea7c2bbffde969ff1ba0/include/ogg/ogg.h#L76) the `pageno` field is a `long`, but in the [docs](https://gitlab.xiph.org/xiph/ogg/blob/0acd32d7cabf7e41cc29ea7c2bbffde969ff1ba0/doc/libogg/ogg_stream_state.html#L52) it is listed as an `int`.https://gitlab.xiph.org/xiph/ogg/-/issues/2292Granulepos corruption with large/numerous packets (with test case)2018-08-08T17:39:26ZstenyakGranulepos corruption with large/numerous packets (with test case)I'm having issues when dealing with oggz streams that have certain amount of packets and/or certain packet size.
I have attached a test case.
I have reproduced the problem with:
- msvs2015 compiler
- both 32 and 64 bit
- both libog...I'm having issues when dealing with oggz streams that have certain amount of packets and/or certain packet size.
I have attached a test case.
I have reproduced the problem with:
- msvs2015 compiler
- both 32 and 64 bit
- both liboggz v1.1.1 (git `70b58a45`, from 2010-04-29) and the head of master (git `f49574ed` from 2014-04-24). Repo URL: https://git.xiph.org/liboggz.git
In the attached test case, the file writing phase seems to go OK, at least no errors are returned anywhere.
[main.cpp](/uploads/466511c90df23933511eeb891b507af7/main.cpp)
The writer code is based on the example found here: https://xiph.org/oggz/doc/group__force__feed.html#details
The reading phase is more problematic:
- Passing the file through oggz-validate.exe (as downloaded from https://xiph.org/oggz ) crashes with an Out of Memory error
- Using oggz-dump.exe instead, it seems to read all packets correctly, and output the expected granule positions
- The attached source code is unable to finish without errors though.
To verify the problem, follow these steps:
1. Compile the code as-is, in debug mode (to run all asserts). Everything should go ok. The resulting file `foo.oggz` will be around 160 megs.
2. Set `FAIL = true`, compile and run. An assert will fail, around packet #491. The granule position is corrupted now.
3. Decrease packetSize 1 byte (setting it to `packetSize = 163388`), compile and run. Granule position will be okay again, all asserts will pass.
So it seems that both amount of packets and size of packets can contribute to the corrupted granulepos.
If you need any help reproducing the issue, please let me know.https://gitlab.xiph.org/xiph/ogg/-/issues/2290liboggplay mishandles live ogg streams in Firefox2020-11-06T04:06:07ZMilesliboggplay mishandles live ogg streams in Firefox(speculation)
See the following bug on Mozilla's tracker:
https://bugzilla.mozilla.org/show_bug.cgi?id=611519
Seems pretty likely the bug is actually in liboggplay. When an audio element points to a live stream and it is played in the...(speculation)
See the following bug on Mozilla's tracker:
https://bugzilla.mozilla.org/show_bug.cgi?id=611519
Seems pretty likely the bug is actually in liboggplay. When an audio element points to a live stream and it is played in the browser, it works fine for roughly 20 minutes before severe stutter sets in. Pressing play also tends to play permanently cached audio instead of the actual stream. Is liboggplay perhaps treating this case as an infinitely large file transfer instead of a live stream?Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/2260Buffer overflow in liboggz, httpdate.c, function httpdate_parse2018-08-08T17:44:41ZhannoBuffer overflow in liboggz, httpdate.c, function httpdate_parseThe function httpdate_parse writes 4 bytes to the three byte variables wday and month. These are supposed to store a 3 byte string, however that misses that the string needs a null terminating byte. Making the variables 4 bytes fixes thi...The function httpdate_parse writes 4 bytes to the three byte variables wday and month. These are supposed to store a 3 byte string, however that misses that the string needs a null terminating byte. Making the variables 4 bytes fixes this.
Also the parser string should limit the size of the month string. See attached patch.
This bug was found with the help of address sanitizer. Can be reproduced by compiling liboggz with -fsanitize=address in CFLAGS+LDFLAGS and running make check.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/2197Ten off by one errors ?2019-08-13T16:56:04ZDavid BindermanTen off by one errors ?[timespec.c:123]: (error) Width 16 given in format string (no. 1) is larger than destination buffer 'timespec[16]', use %15s to prevent overflowing it.
[timespec.c:127]: (error) Width 16 given in format string (no. 1) is larger than dest...[timespec.c:123]: (error) Width 16 given in format string (no. 1) is larger than destination buffer 'timespec[16]', use %15s to prevent overflowing it.
[timespec.c:127]: (error) Width 16 given in format string (no. 1) is larger than destination buffer 'timespec[16]', use %15s to prevent overflowing it.
[timespec.c:131]: (error) Width 16 given in format string (no. 1) is larger than destination buffer 'timespec[16]', use %15s to prevent overflowing it.
[timespec.c:135]:
timespec.c:139
timespec.c:143
timespec.c:147
timespec.c:151
timespec.c:155Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/2043ogg-index produces multiple fisbones with the same name and role, where the i...2020-11-06T04:02:56ZNick Burchogg-index produces multiple fisbones with the same name and role, where the input has several video or audio streamsIf you use OggIndex on a file without a Skeleton stream, which has one Vorbis and one Theora stream in it, the resultant Skeleton fisbones will be correct. However, if you use it on a file with multiple Theora or Vorbis streams, it will ...If you use OggIndex on a file without a Skeleton stream, which has one Vorbis and one Theora stream in it, the resultant Skeleton fisbones will be correct. However, if you use it on a file with multiple Theora or Vorbis streams, it will generate incorrect fisbones for the second and subsequent streams of the type, as it hard codes the name and role
Instead, OggIndex should check which stream this is of a given type, and use that to assign sequential names (eg audio_1, audio_2) rather than hardcoded (eg audio_1 for everything), and flag subsequent streams of a type as alternate ones (rather than hard coded as the main one)https://gitlab.xiph.org/xiph/ogg/-/issues/2042ogg-index fails with an unhelpful error message if the file contains Speex or...2020-11-06T04:03:32ZNick Burchogg-index fails with an unhelpful error message if the file contains Speex or Opus streamsIf you try running ogg-index on a file which contains Opus or Speex streams (eg a Theora + Opus file), then you get a rather unfriendly error such as
`FAIL: Unhandled stream type, serialno=478384172 aborting indexing!`
Where the stream...If you try running ogg-index on a file which contains Opus or Speex streams (eg a Theora + Opus file), then you get a rather unfriendly error such as
`FAIL: Unhandled stream type, serialno=478384172 aborting indexing!`
Where the stream number is that of the Speex or Opus stream
Assuming it's not trivial to add support for those formats, it would be nice if ogg-index could instead give a more helpful message such as _Opus not supported (stream serialno=478384172) - aborting indexing! _https://gitlab.xiph.org/xiph/ogg/-/issues/2041ogg-index sets incorrect fisbone message header offset in the skeleton stream2020-11-06T04:05:16ZNick Burchogg-index sets incorrect fisbone message header offset in the skeleton streamAccording to http://svn.annodex.net/standards/draft-pfeiffer-oggskeleton-current.txt , in the skeleton fisbone,
> Offset to message header fields: 4 Byte unsigned integer that
> contains the number of Bytes used in this packet before t...According to http://svn.annodex.net/standards/draft-pfeiffer-oggskeleton-current.txt , in the skeleton fisbone,
> Offset to message header fields: 4 Byte unsigned integer that
> contains the number of Bytes used in this packet before the
> message header fields. For the version of the skeleton
> bitstream described in this document this number is fixed to 44.
The skeleton stream generated by things like ffmpeg2theora and speexenc set the message header offset to be 44, which is the position less the fisbone\0 header
However, ogg-index creates fisbones where the message header offset is 0x2c=52, which is the offset including the fisbone\0 header, which (based on the docs) seems to be incorrect
Note that it is only the offset that is wrong, the message headers start in the expected place at 44 bytes after the fisbone header / 52 bytes after the start of the fisbone packet datahttps://gitlab.xiph.org/xiph/ogg/-/issues/1970build fails using libtool2020-11-06T03:58:06ZJohn T. Vonachenbuild fails using libtoolWhile building libogg for use with sox, build for libogg version 1.3.1 failed with the following output:
make all-recursive
make[1]: Entering directory `/root/kalebmusic/libogg-1.3.1'
Making all in src
make[2]: Entering directory `/roo...While building libogg for use with sox, build for libogg version 1.3.1 failed with the following output:
make all-recursive
make[1]: Entering directory `/root/kalebmusic/libogg-1.3.1'
Making all in src
make[2]: Entering directory `/root/kalebmusic/libogg-1.3.1/src'
/bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../include -O20 -Wall -ffast-math -fsigned-char -g -O2 -MT framing.lo -MD -MP -MF .deps/framing.Tpo -c -o framing.lo framing.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../include -O20 -Wall -ffast-math -fsigned-char -g -O2 -MT framing.lo -MD -MP -MF .deps/framing.Tpo -c framing.c -fPIC -DPIC -o .libs/framing.o
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../include -O20 -Wall -ffast-math -fsigned-char -g -O2 -MT framing.lo -MD -MP -MF .deps/framing.Tpo -c framing.c -o framing.o >/dev/null 2>&1
mv -f .deps/framing.Tpo .deps/framing.Plo
/bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../include -O20 -Wall -ffast-math -fsigned-char -g -O2 -MT bitwise.lo -MD -MP -MF .deps/bitwise.Tpo -c -o bitwise.lo bitwise.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../include -O20 -Wall -ffast-math -fsigned-char -g -O2 -MT bitwise.lo -MD -MP -MF .deps/bitwise.Tpo -c bitwise.c -fPIC -DPIC -o .libs/bitwise.o
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I../include -O20 -Wall -ffast-math -fsigned-char -g -O2 -MT bitwise.lo -MD -MP -MF .deps/bitwise.Tpo -c bitwise.c -o bitwise.o >/dev/null 2>&1
mv -f .deps/bitwise.Tpo .deps/bitwise.Plo
/bin/bash ../libtool --tag=CC --mode=link gcc -O20 -Wall -ffast-math -fsigned-char -g -O2 -no-undefined -version-info 8:1:8 -o libogg.la -rpath /usr/local/lib framing.lo bitwise.lo
../libtool: eval: line 6444: unexpected EOF while looking for matching `''
../libtool: eval: line 6445: syntax error: unexpected end of file
make[2]: *** [libogg.la] Error 2
make[2]: Leaving directory `/root/kalebmusic/libogg-1.3.1/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/kalebmusic/libogg-1.3.1'
make: *** [all] Error 2Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/1921Build with automake-1.13 broken2019-08-13T16:36:06ZMarko LindqvistBuild with automake-1.13 brokenAutomake-1.13 removed long obsolete AM_CONFIG_HEADER completely ( http://lists.gnu.org/archive/html/automake/2012-12/msg00038.html ) and errors out upon seeing it.
Attached patch replaces it with proper AC_CONFIG_HEADERS.Automake-1.13 removed long obsolete AM_CONFIG_HEADER completely ( http://lists.gnu.org/archive/html/automake/2012-12/msg00038.html ) and errors out upon seeing it.
Attached patch replaces it with proper AC_CONFIG_HEADERS.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/1845ogg_int64_t incorrect on 64/32bit multilib systems2017-08-26T14:29:54ZJonathan Hamiltonogg_int64_t incorrect on 64/32bit multilib systemsOn a x86_64 system, the autoconf created header config_types.h is used to define ogg sized types, including 'ogg_int64_t' as 'long'.
This causes 32bit compilers using this header to break, as 'long' is only 32 bits using such a compiler...On a x86_64 system, the autoconf created header config_types.h is used to define ogg sized types, including 'ogg_int64_t' as 'long'.
This causes 32bit compilers using this header to break, as 'long' is only 32 bits using such a compiler.
This can be recreated simply with the attached C program.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/1758[PATCH] libogg & oggz configure's --docdir option are not honored2017-08-26T14:29:54ZCristian Morales Vega[PATCH] libogg & oggz configure's --docdir option are not honored./configure --help outputs:
...
--docdir=DIR documentation root [DATAROOTDIR/doc/PACKAGE]
...
But that option is ignored, using a hardcoded doc dir.
./configure --help outputs:
...
--docdir=DIR documentation root [DATAROOTDIR/doc/PACKAGE]
...
But that option is ignored, using a hardcoded doc dir.
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/1747libogg 1.2.1 contains invalid os_types.h file which causes libvorbis 1.3.1 to...2021-09-27T21:10:42ZMax Hornlibogg 1.2.1 contains invalid os_types.h file which causes libvorbis 1.3.1 to be uncompilableTrying to compile libvorbis 1.3.1 with libogg 1.2.1 results in the following compiler error on Mac OS X 10.6, 32bit mode:
```
/bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I/sw/include -I/sw...Trying to compile libvorbis 1.3.1 with libogg 1.2.1 results in the following compiler error on Mac OS X 10.6, 32bit mode:
```
/bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I/sw/include -I/sw/include -DDARWIN -fno-common -force_cpusubtype_ALL -Wall -g -O4 -ffast-math -fsigned-char -Wdeclaration-after-statement -DUSE_MEMORY_H -MT analysis.lo -MD -MP -MF .deps/analysis.Tpo -c -o analysis.lo analysis.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I/sw/include -I/sw/include -DDARWIN -fno-common -force_cpusubtype_ALL -Wall -g -O4 -ffast-math -fsigned-char -Wdeclaration-after-statement -DUSE_MEMORY_H -MT analysis.lo -MD -MP -MF .deps/analysis.Tpo -c analysis.c -fno-common -DPIC -o .libs/analysis.o
In file included from /sw/include/ogg/ogg.h:25,
from analysis.c:21:
/sw/include/ogg/os_types.h:73: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ogg_uint16_t'
/sw/include/ogg/os_types.h:75: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ogg_uint32_t'
```
Analysis: os_types.h contains this:
```
#elif (defined(__APPLE__) && defined(__MACH__)) /* MacOS X Framework build */
# include <inttypes.h>
typedef int16_t ogg_int16_t;
typedef u_int16_t ogg_uint16_t;
typedef int32_t ogg_int32_t;
typedef u_int32_t ogg_uint32_t;
typedef int64_t ogg_int64_t;
```
However, the types u_int16_t and u_int32_t are not defined by inttypes.h resp. stdint.h
Indeed, the correct names for these types as defined by the [spec for stdint.h](http://www.opengroup.org/onlinepubs/000095399/basedefs/stdint.h.html) (and by transiency for inttypes.h) are uint32_t and uint16_t. So the simple fix is to change these two lines in libogg's os_types.h.
This may affect #elif cases for other ports which incorrectly expect the u_intFOO types to be defined in stdint.h / inttypes.h
Of course the fact remains that checking for __APPLE__ and __MACH__ is a very fragile way to check for types, and that I would still recommend that os_types.h is rewritten to first try whatever types configure detected, and only fallback to such #define hackery if no configure script can be used... See the (now closed) bug + patch #849.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/1654support 64bit version of libogg and libvorbis under macosx snow leopard2020-11-06T03:59:56ZVittorio G.support 64bit version of libogg and libvorbis under macosx snow leopardI've been using the 64 bit versions from quite some time and i have no issues to report.
However it would be nice to have the sources compatible with the new architecture
for libogg you just need to remove the line
```
#include <Carbon/...I've been using the 64 bit versions from quite some time and i have no issues to report.
However it would be nice to have the sources compatible with the new architecture
for libogg you just need to remove the line
```
#include <Carbon/Carbon.h>
```
from Ogg_Prefix.pch
and in both project you need to set "gcc-4.0" as default compiler.
A further step could be to set "build type" to "universal 32/64" but i don't know how this would affect pre 10.6 build systems.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/1623Minor spelling fixes in comments2017-08-26T14:29:54ZChris 'Xenon' HansonMinor spelling fixes in commentsWhile batch spell-checking some other code, I made these fixes and wish to contribute them.While batch spell-checking some other code, I made these fixes and wish to contribute them.Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/1586[liboggz] oggz-diff unable to process files with whitespace in filename2018-08-08T17:45:36ZGArik[liboggz] oggz-diff unable to process files with whitespace in filenameoggz-diff unable to process files with whitespace in filename.
liboggz compiled from trunk on 21.08.2009 (yesterday)
oggz-diff unable to process files with whitespace in filename.
liboggz compiled from trunk on 21.08.2009 (yesterday)
Monty MontgomeryMonty Montgomeryhttps://gitlab.xiph.org/xiph/ogg/-/issues/1583[liboggz] oggz-info reports incorrect duration for chained files2018-08-08T17:46:39ZGArik[liboggz] oggz-info reports incorrect duration for chained filesHi, all
I have:
libvorbis-1.2.3
vorbis-tools-1.2.0
libogg-1.1.4
liboggz-0.9.9 installed on my system.
The problem is that oggz-info unable to detect "Content-Duration" correctly. As the result "Content-Bitrate-Average" is also incorrec...Hi, all
I have:
libvorbis-1.2.3
vorbis-tools-1.2.0
libogg-1.1.4
liboggz-0.9.9 installed on my system.
The problem is that oggz-info unable to detect "Content-Duration" correctly. As the result "Content-Bitrate-Average" is also incorrect. Also slightly different bitrate detection by ogginfo and oggz-info seems strange to me.
Here is an example:
```
lxuser@garik:~/oggz-bug$ ls
test0.ogg test1.ogg
lxuser@garik:~/oggz-bug$ LANG=C ogginfo *.ogg
Processing file "test0.ogg"...
New logical stream (#1, serial: 7f1f032f): type vorbis
Vorbis headers parsed for stream 1, information follows...
Version: 0
Vendor: Xiph.Org libVorbis I 20090624
Channels: 2
Rate: 44100
Nominal bitrate: 288.000000 kb/s
Upper bitrate not set
Lower bitrate not set
Vorbis stream 1:
Total data length: 1984900 bytes
Playback length: 0m:55.546s
Average bitrate: 285.871339 kb/s
Logical stream 1 ended
Processing file "test1.ogg"...
New logical stream (#1, serial: 7f1f0330): type vorbis
Vorbis headers parsed for stream 1, information follows...
Version: 0
Vendor: Xiph.Org libVorbis I 20090624
Channels: 2
Rate: 44100
Nominal bitrate: 288.000000 kb/s
Upper bitrate not set
Lower bitrate not set
Vorbis stream 1:
Total data length: 10962852 bytes
Playback length: 4m:07.520s
Average bitrate: 354.326180 kb/s
Logical stream 1 ended
lxuser@garik:~/oggz-bug$ oggz-info -a *.ogg
Filename: test0.ogg
Content-Duration: 00:00:55.546
Content-Length: 1.897 MB
Content-Bitrate-Average: 286.452 kbps
Vorbis: serialno 2132738863
4617 packets in 467 pages, 9.9 packets/page, 1.098% Ogg overhead
Content-Length: 1.897 MB
Content-Bitrate-Average: 286.452 kbps
Audio-Samplerate: 44100 Hz
Audio-Channels: 2
Page-Length-Maximum: 4.302 kB
Page-Length-StdDev: 230 bytes
Packet-Length-Maximum: 3.771 kB
Packet-Length-StdDev: 304 bytes
------------------------------------------------------------
Filename: test1.ogg
Content-Duration: 00:04:07.520
Content-Length: 10.459 MB
Content-Bitrate-Average: 354.455 kbps
Vorbis: serialno 2132738864
30765 packets in 2577 pages, 11.9 packets/page, 1.116% Ogg overhead
Content-Length: 10.459 MB
Content-Bitrate-Average: 354.455 kbps
Audio-Samplerate: 44100 Hz
Audio-Channels: 2
Page-Length-Maximum: 4.297 kB
Page-Length-StdDev: 111 bytes
Packet-Length-Maximum: 3.771 kB
Packet-Length-StdDev: 298 bytes
lxuser@garik:~/oggz-bug$ cat test0.ogg test1.ogg > test.ogg
lxuser@garik:~/oggz-bug$ LANG=C ogginfo test.ogg
Processing file "test.ogg"...
New logical stream (#1, serial: 7f1f032f): type vorbis
Vorbis headers parsed for stream 1, information follows...
Version: 0
Vendor: Xiph.Org libVorbis I 20090624
Channels: 2
Rate: 44100
Nominal bitrate: 288.000000 kb/s
Upper bitrate not set
Lower bitrate not set
Vorbis stream 1:
Total data length: 1984900 bytes
Playback length: 0m:55.546s
Average bitrate: 285.871339 kb/s
Logical stream 1 ended
New logical stream (#2, serial: 7f1f0330): type vorbis
Vorbis headers parsed for stream 2, information follows...
Version: 0
Vendor: Xiph.Org libVorbis I 20090624
Channels: 2
Rate: 44100
Nominal bitrate: 288.000000 kb/s
Upper bitrate not set
Lower bitrate not set
Vorbis stream 2:
Total data length: 10962852 bytes
Playback length: 4m:07.520s
Average bitrate: 354.326180 kb/s
Logical stream 2 ended
lxuser@garik:~/oggz-bug$ oggz-info -a test.ogg
Content-Duration: 00:04:07.520
Content-Length: 12.356 MB
Content-Bitrate-Average: 418.738 kbps
Vorbis: serialno 2132738863
4617 packets in 467 pages, 9.9 packets/page, 1.098% Ogg overhead
Content-Length: 1.897 MB
Content-Bitrate-Average: 64.282 kbps
Audio-Samplerate: 44100 Hz
Audio-Channels: 2
Page-Length-Maximum: 4.302 kB
Page-Length-StdDev: 230 bytes
Packet-Length-Maximum: 3.771 kB
Packet-Length-StdDev: 304 bytes
Vorbis: serialno 2132738864
30765 packets in 2577 pages, 11.9 packets/page, 1.116% Ogg overhead
Content-Length: 10.459 MB
Content-Bitrate-Average: 354.455 kbps
Audio-Samplerate: 44100 Hz
Audio-Channels: 2
Page-Length-Maximum: 4.297 kB
Page-Length-StdDev: 111 bytes
Packet-Length-Maximum: 3.771 kB
Packet-Length-StdDev: 298 bytes
```
conradconrad