liboggz issueshttps://gitlab.xiph.org/xiph/liboggz/-/issues2023-08-14T11:00:06Zhttps://gitlab.xiph.org/xiph/liboggz/-/issues/11reserved identifier violation2023-08-14T11:00:06ZMarkus Elfringreserved identifier violation:eyes: I would like to point out that identifiers like “[`__OGGZ_H__`](https://gitlab.xiph.org/xiph/liboggz/-/blob/acf142b3915bf6350fe3f8169614d9962b802391/include/oggz/oggz.h#L33 "Update candidate")” and “[`_OggzVector`](https://gitlab....:eyes: I would like to point out that identifiers like “[`__OGGZ_H__`](https://gitlab.xiph.org/xiph/liboggz/-/blob/acf142b3915bf6350fe3f8169614d9962b802391/include/oggz/oggz.h#L33 "Update candidate")” and “[`_OggzVector`](https://gitlab.xiph.org/xiph/liboggz/-/blob/acf142b3915bf6350fe3f8169614d9962b802391/src/liboggz/oggz_vector.c#L46 "Another update candidate")” [do not fit](https://wiki.sei.cmu.edu/confluence/display/cplusplus/DCL51-CPP.+Do+not+declare+or+define+a+reserved+identifier "Do not declare an identifier which is reserved for the compiler implementation.") to the expected naming convention of the C++ language standard.
:thought_balloon: Would you like to adjust your selection for unique names?https://gitlab.xiph.org/xiph/liboggz/-/issues/10support opus codec2022-04-29T00:36:54ZChristoph Anton Mitterersupport opus codecHey.
It seems the various tools have no idea about the opus codec. Would be nice if that could be supported instead of being shown as `unknown`.
Thanks,
Chris.Hey.
It seems the various tools have no idea about the opus codec. Would be nice if that could be supported instead of being shown as `unknown`.
Thanks,
Chris.https://gitlab.xiph.org/xiph/liboggz/-/issues/7Ten off by one errors?2019-08-13T16:55:34ZRalph GilesTen off by one errors?Moved from [ogg #2197](https://gitlab.xiph.org/xiph/ogg/issues/2197) reported by @dcb314.
[timespec.c:123]: (error) Width 16 given in format string (no. 1) is larger than destination buffer 'timespec[16]', use %15s to prevent overflowi...Moved from [ogg #2197](https://gitlab.xiph.org/xiph/ogg/issues/2197) reported by @dcb314.
[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:155https://gitlab.xiph.org/xiph/liboggz/-/issues/6assertion failure in oggz_close at oggz.c:218 when scanning corrupted file2018-08-08T17:46:51Zkeelerdaassertion failure in oggz_close at oggz.c:218 when scanning corrupted fileoggz-scan exits with "Assertion `oggz_dlist_is_empty(oggz->packet_buffer)' failed." when scanning a corrupted file.oggz-scan exits with "Assertion `oggz_dlist_is_empty(oggz->packet_buffer)' failed." when scanning a corrupted file.conradconradhttps://gitlab.xiph.org/xiph/liboggz/-/issues/5[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
```conradconradhttps://gitlab.xiph.org/xiph/liboggz/-/issues/4[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/liboggz/-/issues/3Buffer 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/liboggz/-/issues/1Granulepos 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/f6ad965f431dd89127c12fadeddfa357/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.