Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2018-11-06T20:03:54Zhttps://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-tools/-/issues/1514oggenc crashes when I try to use --resample2018-01-22T04:18:25Zezekiel000oggenc crashes when I try to use --resampleI have a directory of wav files to convert but if I try to batch re-sample them to 32000Hz (from 22050Hz and 44100Hz) I get this:
oggenc -b 64 --resample 32000 --downmix *.wav
Opening with wav module: WAV file reader
Resampling input fro...I have a directory of wav files to convert but if I try to batch re-sample them to 32000Hz (from 22050Hz and 44100Hz) I get this:
oggenc -b 64 --resample 32000 --downmix *.wav
Opening with wav module: WAV file reader
Resampling input from 22050 Hz to 32000 Hz
WARNING: Can't downmix except from stereo to mono
Encoding "0005.wav" to
"0005.ogg"
at approximate bitrate 64 kbps (VBR encoding enabled)
[ 73.9%] [ 0m00s remaining] -
Done encoding file "0005.ogg"
File length: 0m 02.0s
Elapsed time: 0m 00.1s
Rate: 24.6719
Average bitrate: 47.9 kb/s
*** glibc detected *** oggenc: munmap_chunk(): invalid pointer: 0x0000000000405540 ***
======= Backtrace: =========
/lib/libc.so.6[0x7fa4c94d7a58]
oggenc[0x404fad]
oggenc[0x404357]
/lib/libc.so.6(__libc_start_main+0xe6)[0x7fa4c947c466]
oggenc[0x402699]
======= Memory map: ========
00400000-0040f000 r-xp 00000000 08:01 52719 /usr/bin/oggenc
0060e000-0060f000 r--p 0000e000 08:01 52719 /usr/bin/oggenc
0060f000-00610000 rw-p 0000f000 08:01 52719 /usr/bin/oggenc
0213e000-02189000 rw-p 0213e000 00:00 0 [heap]
7fa4c9246000-7fa4c925c000 r-xp 00000000 08:01 73471 /lib/libgcc_s.so.1
7fa4c925c000-7fa4c945c000 ---p 00016000 08:01 73471 /lib/libgcc_s.so.1
7fa4c945c000-7fa4c945d000 r--p 00016000 08:01 73471 /lib/libgcc_s.so.1
7fa4c945d000-7fa4c945e000 rw-p 00017000 08:01 73471 /lib/libgcc_s.so.1
7fa4c945e000-7fa4c95c7000 r-xp 00000000 08:01 7770 /lib/libc-2.8.90.so
7fa4c95c7000-7fa4c97c6000 ---p 00169000 08:01 7770 /lib/libc-2.8.90.so
7fa4c97c6000-7fa4c97ca000 r--p 00168000 08:01 7770 /lib/libc-2.8.90.so
7fa4c97ca000-7fa4c97cb000 rw-p 0016c000 08:01 7770 /lib/libc-2.8.90.so
7fa4c97cb000-7fa4c97d0000 rw-p 7fa4c97cb000 00:00 0
7fa4c97d0000-7fa4c97d5000 r-xp 00000000 08:01 9604 /usr/lib/libogg.so.0.5.3
7fa4c97d5000-7fa4c99d4000 ---p 00005000 08:01 9604 /usr/lib/libogg.so.0.5.3
7fa4c99d4000-7fa4c99d5000 r--p 00004000 08:01 9604 /usr/lib/libogg.so.0.5.3
7fa4c99d5000-7fa4c99d6000 rw-p 00005000 08:01 9604 /usr/lib/libogg.so.0.5.3
7fa4c99d6000-7fa4c9a5a000 r-xp 00000000 08:01 7774 /lib/libm-2.8.90.so
7fa4c9a5a000-7fa4c9c59000 ---p 00084000 08:01 7774 /lib/libm-2.8.90.so
7fa4c9c59000-7fa4c9c5a000 r--p 00083000 08:01 7774 /lib/libm-2.8.90.so
7fa4c9c5a000-7fa4c9c5b000 rw-p 00084000 08:01 7774 /lib/libm-2.8.90.so
7fa4c9c5b000-7fa4c9ca3000 r-xp 00000000 08:01 8862 /usr/lib/libFLAC.so.8.2.0
7fa4c9ca3000-7fa4c9ea3000 ---p 00048000 08:01 8862 /usr/lib/libFLAC.so.8.2.0
7fa4c9ea3000-7fa4c9ea4000 r--p 00048000 08:01 8862 /usr/lib/libFLAC.so.8.2.0
7fa4c9ea4000-7fa4c9ea5000 rw-p 00049000 08:01 8862 /usr/lib/libFLAC.so.8.2.0
7fa4c9ea5000-7fa4c9ec4000 r-xp 00000000 08:01 9822 /usr/lib/libvorbis.so.0.4.0
7fa4c9ec4000-7fa4ca0c3000 ---p 0001f000 08:01 9822 /usr/lib/libvorbis.so.0.4.0
7fa4ca0c3000-7fa4ca0c4000 r--p 0001e000 08:01 9822 /usr/lib/libvorbis.so.0.4.0
7fa4ca0c4000-7fa4ca0d2000 rw-p 0001f000 08:01 9822 /usr/lib/libvorbis.so.0.4.0
7fa4ca0d2000-7fa4ca0ec000 r-xp 00000000 08:01 9824 /usr/lib/libvorbisenc.so.2.0.3
7fa4ca0ec000-7fa4ca2eb000 ---p 0001a000 08:01 9824 /usr/lib/libvorbisenc.so.2.0.3
7fa4ca2eb000-7fa4ca2ec000 r--p 00019000 08:01 9824 /usr/lib/libvorbisenc.so.2.0.3
7fa4ca2ec000-7fa4ca4ab000 rw-p 0001a000 08:01 9824 /usr/lib/libvorbisenc.so.2.0.3
7fa4ca4ab000-7fa4ca4ca000 r-xp 00000000 08:01 7767 /lib/ld-2.8.90.so
7fa4ca58b000-7fa4ca58c000 rw-p 7fa4ca58b000 00:00 0
7fa4ca58c000-7fa4ca58d000 r--p 00000000 08:01 61933 /usr/share/locale-langpack/en_GB/LC_MESSAGES/vorbis-tools.mo
7fa4ca58d000-7fa4ca58e000 rw-p 7fa4ca58d000 00:00 0
7fa4ca58e000-7fa4ca5cd000 r--p 00000000 08:01 12898 /usr/lib/locale/en_GB.utf8/LC_CTYPE
7fa4ca5cd000-7fa4ca6ae000 r--p 00000000 08:01 12897 /usr/lib/locale/en_GB.utf8/LC_COLLATE
7fa4ca6ae000-7fa4ca6b1000 rw-p 7fa4ca6ae000 00:00 0
7fa4ca6b5000-7fa4ca6b6000 r--p 00000000 08:01 12942 /usr/lib/locale/en_GB.utf8/LC_NUMERIC
7fa4ca6b6000-7fa4ca6b7000 r--p 00000000 08:01 12793 /usr/lib/locale/en_GB.utf8/LC_TIME
7fa4ca6b7000-7fa4ca6b8000 r--p 00000000 08:01 12794 /usr/lib/locale/en_GB.utf8/LC_MONETARY
7fa4ca6b8000-7fa4ca6b9000 r--p 00000000 08:01 12920 /usr/lib/locale/en_GB.utf8/LC_MESSAGES/SYS_LC_MESSAGES
7fa4ca6b9000-7fa4ca6ba000 r--p 00000000 08:01 12904 /usr/lib/locale/en_GB.utf8/LC_PAPER
7fa4ca6ba000-7fa4ca6bb000 r--p 00000000 08:01 12915 /usr/lib/locale/en_GB.utf8/LC_NAME
7fa4ca6bb000-7fa4ca6bc000 r--p 00000000 08:01 12795 /usr/lib/locale/en_GB.utf8/LC_ADDRESS
7fa4ca6bc000-7fa4ca6bd000 r--p 00000000 08:01 12796 /usr/lib/locale/en_GB.utf8/LC_TELEPHONE
7fa4ca6bd000-7fa4ca6be000 r--p 00000000 08:01 12900 /usr/lib/locale/en_GB.utf8/LC_MEASUREMENT
7fa4ca6be000-7fa4ca6c5000 r--s 00000000 08:01 7563 /usr/lib/gconv/gconv-modules.cache
7fa4ca6c5000-7fa4ca6c6000 r--p 00000000 08:01 12797 /usr/lib/locale/en_GB.utf8/LC_IDENTIFICATION
7fa4ca6c6000-7fa4ca6c9000 rw-p 7fa4ca6c6000 00:00 0
7fa4ca6c9000-7fa4ca6ca000 r--p 0001e000 08:01 7767 /lib/ld-2.8.90.so
7fa4ca6ca000-7fa4ca6cb000 rw-p 0001f000 08:01 7767 /lib/ld-2.8.90.so
7fffd26aa000-7fffd26ca000 rw-p 7ffffffdf000 00:00 0 [stack]
7fffd27f4000-7fffd27f5000 r-xp 7fffd27f4000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
Aborted
I am using Ubuntu 8.10 with oggenc from vorbis-tools 1.2.0Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/1680oggenc displays useless warning even if --quiet is set2018-01-22T04:18:37ZJohn Ferlitooggenc displays useless warning even if --quiet is setReported at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538025
1. Create a wav file with sox:
$ sox source.wav -b 32 -e floating-point output.wav vol 0.5 dither
2. Encode with --quiet option:
$ oggenc --quiet output.wav
Skipping ch...Reported at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538025
1. Create a wav file with sox:
$ sox source.wav -b 32 -e floating-point output.wav vol 0.5 dither
2. Encode with --quiet option:
$ oggenc --quiet output.wav
Skipping chunk of type "fact", length 4
$
This is just a minor annoyance (I don't particularly want to redirect
stderr) and seems to be related to 32-bit floating-point WAVs created
with SoX, which seems to tag them with some metadata.
The code in question should either honour the --quiet switch, or
recognise the "fact" chunk (which seems to be a standard chunk in WAVs)
and not print a warning on encountering it.
Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/115oggenc disregards all but the first artist tag (-a)2007-05-18T05:05:08Zgtgbroggenc disregards all but the first artist tag (-a)```
oggenc tags .ogg files only with one ARTIST tag, no matter how many '-a's have
been specified. haven't checked other tags yet, might be buggy with those, too.
Tested under linux only
``````
oggenc tags .ogg files only with one ARTIST tag, no matter how many '-a's have
been specified. haven't checked other tags yet, might be buggy with those, too.
Tested under linux only
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/2137Oggenc division by zero issue2018-01-22T04:18:25ZParis ZoumpouloglouOggenc division by zero issueA crafted WAV file with number of channels set to 0 will cause oggenc to crash due to a division by zero issue at :
Stopped reason: SIGFPE
0x0804d497 in wav_open (in=0x805c368, opt=0xbffff2ec, oldbuf=0x805c4d0 "RIFF\f\002", buflen=0xc) ...A crafted WAV file with number of channels set to 0 will cause oggenc to crash due to a division by zero issue at :
Stopped reason: SIGFPE
0x0804d497 in wav_open (in=0x805c368, opt=0xbffff2ec, oldbuf=0x805c4d0 "RIFF\f\002", buflen=0xc) at audio.c:552
552 opt->total_samples_per_channel = len/(format.channels*samplesize);
Tests were performed using vorbis-tools 1.4.0Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/1242oggenc do not suport some wav.pcm files what flac actually support2013-12-13T18:38:52ZGitlab Botoggenc do not suport some wav.pcm files what flac actually supportoggenc fails with:
ERROR: Wav file is unsupported subformat (must be 8,16, or 24 bit PCM
or floating point PCM
ERROR: Input file "example.wav" is not a supported format
with files it actually should support:
AUDIO: 22050 Hz, 1 ch, s16le...oggenc fails with:
ERROR: Wav file is unsupported subformat (must be 8,16, or 24 bit PCM
or floating point PCM
ERROR: Input file "example.wav" is not a supported format
with files it actually should support:
AUDIO: 22050 Hz, 1 ch, s16le, 352.8 kbit
i do not have any problems with other aplications like flac --encode or mplayer. Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/314oggenc doesn't let me use bitrate2018-01-22T04:15:59Zaravind1001oggenc doesn't let me use bitrate```
oggenc works only if I use -q option. The options -m, -M, -b don't work at all.
They always fail with the following message. Even the examples given in the
man pages don't work.
The rpm versions are
libvorbis-1.0-1
vorbis-tools-1.0...```
oggenc works only if I use -q option. The options -m, -M, -b don't work at all.
They always fail with the following message. Even the examples given in the
man pages don't work.
The rpm versions are
libvorbis-1.0-1
vorbis-tools-1.0-1
libogg-1.0-1
for RedHat 8.0
$ oggenc -M 20 -o m.ogg m.wav
Enabling bitrate management engine
Skipping chunk of type "PEAK", length 24
Opening with wav module: WAV file reader
Encoding "m.wav" to
"m.ogg"
using bitrate management (no min, max 20 kbps)
Mode initialisation failed: invalid parameters for bitrate
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/685Oggenc doesn't properly place UTF8 comments when CHARSET is null.2009-04-19T19:20:12ZhknishinoOggenc doesn't properly place UTF8 comments when CHARSET is null.While using a script I wrote to process a flac-as-cd file into seperate tagged vorbis encoded tracks, I found that accented characters in metadata were being replaced with '#' characters despite UTF8 encoding being used at every step. Th...While using a script I wrote to process a flac-as-cd file into seperate tagged vorbis encoded tracks, I found that accented characters in metadata were being replaced with '#' characters despite UTF8 encoding being used at every step. Thanks to the very kind help at #vorbis it was narrowed down to the fact that environment variable CHARSET was set to nothing. The problem goes away when CHARSET is set to "UTF-8".
Now, I use Slackware 10.1 which may be at fault for not setting CHARSET properly with the other locale variables, so I don't really know if it's an oggenc bug here. However, this problem does not happen when using LAME instead of oggenc in the same situation**, I haven't experienced any other problems of this sort in other programs, and MikeS asked me to file it. ;)
** With amaroK set to interpet id3v1 as UTF8.
Example:
(LANG and LC_ALL are set to "en_US.UTF-8")
```
> export CHARSET=
> oggenc -q 6 -c "TITLE=J'y suis jamais allé" blah.wav
[...]
> ogginfo blah.ogg
[...]
User comments section follows...
TITLE=J'y suis jamais all##
[...]
> export CHARSET=UTF-8
> oggenc -q 6 -c "TITLE=J'y suis jamais allé" blah.wav
[...]
> ogginfo blah.ogg
[...]
User comments section follows...
TITLE=J'y suis jamais allé
[...]
```
Also, oggenc was built from a vanilla vorbis-tools-1.1.1.tar.gz with './configure --prefix=/usr'Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/678oggenc doesn't read flac-in-ogg (created with flac --ogg)2006-12-10T15:06:40Zmilletteoggenc doesn't read flac-in-ogg (created with flac --ogg)$ flac --ogg audio_05.wav
$ oggenc --output audio_05-128.ogg audio_05.ogg
Erreur : le fichier d'entrée « audio_05.ogg » n'est pas dans un format reconnu
(error: the input file is in an unknown format)
I'm using Debian/Sarge and grabbed ...$ flac --ogg audio_05.wav
$ oggenc --output audio_05-128.ogg audio_05.ogg
Erreur : le fichier d'entrée « audio_05.ogg » n'est pas dans un format reconnu
(error: the input file is in an unknown format)
I'm using Debian/Sarge and grabbed theses sources:
http://ftp.debian.org/debian/pool/main/v/vorbis-tools/vorbis-tools_1.0.1.orig.tar.gz
I also compared with the latest trunk from svn, same result.
I tried to fix it, but maybe the problem lies in flac. Here's what I did :
flac.c, line 43 :
int oggflac_id(unsigned char *buf, int len)
{
if (len < 41) return 0;
return memcmp(buf, "OggS", 4) == 0 && flac_id(buf + 37, len - 37);
}
audio.c, line 47
/* Define the supported formats here */
{oggflac_id, 41, flac_open, flac_close, "ogg", N_("Ogg FLAC file reader")},
Really not sure why, but this now lets me encode oggflac files to oggvorbis with oggenc file.ogg, meaning when I create file.ogg with "flac --ogg ..."
Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/1157oggenc doesn't seem to support converting from FLACs any more2008-01-25T15:27:12Zelliotoggenc doesn't seem to support converting from FLACs any morevorbis-tools seems to require libOggFLAC for oggenc, but flac no longer provides libOggFLACvorbis-tools seems to require libOggFLAC for oggenc, but flac no longer provides libOggFLACMichael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/1224OGGENC doesn't support 24 or 32, IEEE float with raw PCM input2009-04-19T20:39:32ZbnOGGENC doesn't support 24 or 32, IEEE float with raw PCM inputHi there,
I am using oggenc2 as provided on rarewares.org.
I would like to encode raw pcm sample data as provided by STDIN.
The raw PCM input is in IEEE float - but oggenc2 only allows 8 or 16 bit as a raw_samplesize.
So in essence ogg...Hi there,
I am using oggenc2 as provided on rarewares.org.
I would like to encode raw pcm sample data as provided by STDIN.
The raw PCM input is in IEEE float - but oggenc2 only allows 8 or 16 bit as a raw_samplesize.
So in essence oggenc2 only supports 32-bit float sample data when using a wave header with the sample data - but not with headerless raw PCM data.
It would be great, if you could add support for 32-bit IEEE float also for headerless raw PCM sample data via STDIN.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/100oggenc doesn't take in UTF-8 comments, and Gumboot hates it, too2006-06-12T11:46:26Znisharfioggenc doesn't take in UTF-8 comments, and Gumboot hates it, too```
He has debian with tcsh; I use OpenBSD with bash.
``````
He has debian with tcsh; I use OpenBSD with bash.
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/1644oggenc finish early2018-01-22T04:18:38ZGitlab Botoggenc finish earlyThe audio file converted fine, but log says that it didn't finish.
Steps to reproduce:
mkfifo audio.wav
oggenc -q 4 -o audio.ogg audio.wav 2> /tmp/ogg.log & mplayer -really-quiet -nocorrect-pts -vo null -vc null -alang eng,und -ao pcm...The audio file converted fine, but log says that it didn't finish.
Steps to reproduce:
mkfifo audio.wav
oggenc -q 4 -o audio.ogg audio.wav 2> /tmp/ogg.log & mplayer -really-quiet -nocorrect-pts -vo null -vc null -alang eng,und -ao pcm:file=audio.wav:fast "$1"Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/46oggenc generates extra output lines when the status line is wider than the te...2006-06-12T11:23:47Zjgaughanoggenc generates extra output lines when the status line is wider than the terminal```
This also occurs with vorbis tools 1.0rc2.
When oggenc is encoding file with a long filename the status line in the output
can become longer than the width of the terminal. The line becomes wrapped and
each time the status line is ...```
This also occurs with vorbis tools 1.0rc2.
When oggenc is encoding file with a long filename the status line in the output
can become longer than the width of the terminal. The line becomes wrapped and
each time the status line is updated and extra line is added to the output.
Here's an example of the output from when I was encoding a track earlier today
(using abcde as frontend):
Encoding "/home/jgaughan/ogg/abcde.4907f106/track1.ogg" [ 0.1%] [ 7m38s remaini
Encoding "/home/jgaughan/ogg/abcde.4907f106/track1.ogg" [ 0.1%] [ 5m46s remaini
Encoding "/home/jgaughan/ogg/abcde.4907f106/track1.ogg" [ 0.2%] [ 5m07s remaini
Encoding "/home/jgaughan/ogg/abcde.4907f106/track1.ogg" [ 0.2%] [ 5m01s remaini
Encoding "/home/jgaughan/ogg/abcde.4907f106/track1.ogg" [ 0.3%] [ 5m26s remaini
Encoding "/home/jgaughan/ogg/abcde.4907f106/track1.ogg" [ 0.3%] [ 5m06s remaini
```Michael SmithMichael Smithhttps://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-tools/-/issues/173oggenc ignores bitrate setting2002-03-27T06:54:03Zflifsonoggenc ignores bitrate setting```
oggenc seems to ignore the bitrate setting. I get huge .ogg files with bitrates
in the 300+ area when I specified a much lower bit rate. Here's an example.
[flifson@asgard london_calling]$ oggenc -b 128 11_wrong_em_boyo.wav
Opening...```
oggenc seems to ignore the bitrate setting. I get huge .ogg files with bitrates
in the 300+ area when I specified a much lower bit rate. Here's an example.
[flifson@asgard london_calling]$ oggenc -b 128 11_wrong_em_boyo.wav
Opening with wav module: WAV file reader
Encoding "11_wrong_em_boyo.ogg" [ 99.9%] [ 0m00s remaining] \
Done encoding file "11_wrong_em_boyo.ogg"
File length: 3m 13.0s
Elapsed time: 0m 56.9s
Rate: 3.3988
Average bitrate: 347.9 kb/s
[flifson@asgard london_calling]$ oggenc -v
OggEnc v0.8 (libvorbis rc2)
I'm using 0.8rc2. Does this not have bitrate limits enabled?
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/2276oggenc in vorbis-tools versions 1.4.0, 1.2.0, 1.1.1 suffer from DoS(infinite ...2018-01-22T04:18:25ZWang Pengoggenc in vorbis-tools versions 1.4.0, 1.2.0, 1.1.1 suffer from DoS(infinite loop) with crafted input file1. the phenomenon
# ./oggenc/oggenc exploit_1_0
output got:
Skipping chunk of type "", length -8
2. the analysis (Version 1.4.0 as an example)
audio.c:126 if(fread(buf,1,*8*,in) < 8 ) /* Suck down a chunk specifier */
(gdb)x/8xb buf
...1. the phenomenon
# ./oggenc/oggenc exploit_1_0
output got:
Skipping chunk of type "", length -8
2. the analysis (Version 1.4.0 as an example)
audio.c:126 if(fread(buf,1,*8*,in) < 8 ) /* Suck down a chunk specifier */
(gdb)x/8xb buf
0xbffff254: 0x00 0x00 0x00 0x00 0xf8 0xff 0xff 0xff
here! 0xfffffff8 == *-8*
audio.c:134 *len = READ_U32_LE(buf+4);
(gdb)p/x *len
$7 = 0xfffffff8
audio.c:135 if(!seek_forward(in, *len))
audio.c:101 if( fseek(in, length, SEEK_CUR))
(gdb)p/x length
$15 = 0xfffffff8
In conclusion, fread() forwards the file position by 8 bytes and then fseek() backwards it by 8 bytes, meaning resets it;More worse,this happens within a while(1) loop,at audio.c:124 ,which results in the infinite loop.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/1432oggenc instances started in the same second generate the same serial number2008-10-04T21:15:16Zmgoldoggenc instances started in the same second generate the same serial numberTwo copies of oggenc that start in the same second will generate output with the same serial number, which is a problem if the user wants to concatenate 2 or more of the output files (since all streams in a file must have unique serial n...Two copies of oggenc that start in the same second will generate output with the same serial number, which is a problem if the user wants to concatenate 2 or more of the output files (since all streams in a file must have unique serial numbers). These commands show the duplicate numbers:
```
$ dd if=/dev/urandom of=test.raw bs=4 count=44100
$ for x in {0..9} ; do oggenc -q5 --raw test.raw -o test$x.ogg; done
$ ogginfo test?.ogg |grep serial
```
This happens because the random number generator is only seeded using the time. XORing the time with the PID fixes this problem, though I'm not sure whether getpid() is available on all platforms.IvoIvohttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/568oggenc jumbles -N and -n2018-01-22T04:56:57Zwhitewolf_foxoggenc jumbles -N and -n```
Hi Vorbis Team!
When defining the tracknumber, oggenc shall set to a new file, you're using the
"-N #" trigger.
When defining a naming string, containing the track's number, oggenc uses "%n".
Thats confusing.
My opinion is, that yo...```
Hi Vorbis Team!
When defining the tracknumber, oggenc shall set to a new file, you're using the
"-N #" trigger.
When defining a naming string, containing the track's number, oggenc uses "%n".
Thats confusing.
My opinion is, that you should change the usage of "-N" and "-n" to "-N" for
defining a nameing string and "-n" to define the tracknumber. Further, you
should change "-G" to "-g". This prevents from doing mistakes caused by using
incorrect triggers, because ALL taging related switches are consistent lower case.
As an alternative you should make "%N" an valid naming string character.
MfG
Marc Richter
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/207oggenc man page still says RC3 in the title2002-07-19T06:25:55Zchaeseoggenc man page still says RC3 in the title```
The title of the oggenc man page still reads "Vorbis Tools release candidate 3"
You might want to change that before rolling out 1.0 :)
``````
The title of the oggenc man page still reads "Vorbis Tools release candidate 3"
You might want to change that before rolling out 1.0 :)
```Michael SmithMichael Smith