Xiph.Org issueshttps://gitlab.xiph.org/groups/xiph/-/issues2008-09-01T11:26:07Zhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/643Clicks / Snaps during channel shuffle2008-09-01T11:26:07ZJani AverbachClicks / Snaps during channel shuffleI hear quite loud and clear clicks / snaps at the beging of the
Dire Straits' "Telegraph Road" and "Private Investigations", especially at the beging of "Private Investigations". These clicks are happening during channel shuffle.
It is ...I hear quite loud and clear clicks / snaps at the beging of the
Dire Straits' "Telegraph Road" and "Private Investigations", especially at the beging of "Private Investigations". These clicks are happening during channel shuffle.
It is ogg123 (playback) which is causing these because
wav ->> ogg ->> wav is fine.
```
Ogg Vorbis stream: 2 channel, 44100 Hz
Vorbis format: Version 0
Bitrate hints: upper=-1 nominal=224000 lower=128 window=0
Encoded by: Xiph.Org libVorbis I 20040629
ogg123 from vorbis-tools 1.0.1
libogg.so.0.5.2
libvorbis.so.0.3.0
libvorbisfile.so.3.1.0
libao.so.2.1.3
```
The OS is Linux/2.6.11.6, with alsa drivers.
And the OGG file was created with following options:
`--min-bitrate 128 -q 7`
IvoIvohttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/639ogg123: remote .m3u playlist files2018-01-22T04:18:37ZGitlab Botogg123: remote .m3u playlist filesIt seems silly to me that Icecast will generate .m3u files dynamically for.ogg mountpoints but ogg123 can't make use of them.It seems silly to me that Icecast will generate .m3u files dynamically for.ogg mountpoints but ogg123 can't make use of them.Gitlab BotGitlab Bothttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/638Better handling of invalid/missing streams in OGG1232018-01-22T04:18:37ZGitlab BotBetter handling of invalid/missing streams in OGG123I'd like to see better handling of error messages for streams. Right
now the user has no idea why it failed, only that it did.
If it was an HTTP error, printing this should be sufficient. If it wasn't
an ogg vorbis file, the MIME type...I'd like to see better handling of error messages for streams. Right
now the user has no idea why it failed, only that it did.
If it was an HTTP error, printing this should be sufficient. If it wasn't
an ogg vorbis file, the MIME type really should say so (assuming it's
being checked) and ogg123 shouldn't ever have to try opening it, unless we
want to try streams regardless of mime type.Gitlab BotGitlab Bothttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/629setbinmode not defined if using MinGW (and MSYS)2005-03-10T23:51:40Zdjvsetbinmode not defined if using MinGW (and MSYS)MinGW does not, for obvious reasons, define _MSC_VER
so when trying to compile oggenc one gets an error due to undefined setbinmode.
The easiest way to fix this is to use the following patch:
----
```
--- oggenc/platform.c.orig Wed Mar ...MinGW does not, for obvious reasons, define _MSC_VER
so when trying to compile oggenc one gets an error due to undefined setbinmode.
The easiest way to fix this is to use the following patch:
----
```
--- oggenc/platform.c.orig Wed Mar 9 17:12:05 2005
+++ oggenc/platform.c Wed Mar 9 17:14:12 2005
@@ -38,7 +38,7 @@
}
#endif
-#if defined(__WATCOMC__) || defined(__BORLANDC__)
+#if defined(__WATCOMC__) || defined(__BORLANDC__) || defined(__MINGW32__)
void setbinmode(FILE *f)
{
setmode(fileno(f), O_BINARY);
```
----
You can also use the patch below but that may well break things with Watcom and/or Borland:
----
```
--- oggenc/platform.c~ Wed Sep 3 10:58:04 2003
+++ oggenc/platform.c Sat Jan 1 16:50:42 2005
@@ -23,7 +23,7 @@
#include <time.h>
#endif
-#if defined(_WIN32) && defined(_MSC_VER)
+#if defined(_WIN32) //&& defined(_MSC_VER)
void setbinmode(FILE *f)
{
```
----
Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/623oggenc 1.0.1 -m and -M options when -q is specified, fail to multiply them by...2007-06-17T09:32:07ZJoe Robackoggenc 1.0.1 -m and -M options when -q is specified, fail to multiply them by 1000oggenc -b 128 -m 96 -M 225 foo.wav produce:
```
Nominal bitrate: 128.000000 kb/s
Upper bitrate: 225.000000 kb/s
Lower bitrate: 96.000000 kb/s
```
oggenc -q 3 -m 96 -M 225 produces:
```
Nominal bitrate: 112.000000 kb/s
Upper bitrate: 0...oggenc -b 128 -m 96 -M 225 foo.wav produce:
```
Nominal bitrate: 128.000000 kb/s
Upper bitrate: 225.000000 kb/s
Lower bitrate: 96.000000 kb/s
```
oggenc -q 3 -m 96 -M 225 produces:
```
Nominal bitrate: 112.000000 kb/s
Upper bitrate: 0.225000 kb/s
Lower bitrate: 0.096000 kb/s
```
looking @ vorbis-tools-1.0.1/oggenc/encode.c
oe_encode()
```
if(opt->quality_set > 0){
ai.bitrate_hard_min=opt->min_bitrate; // which opt->min_bitrate == (int) 96
ai.bitrate_hard_max=opt->max_bitrate; // which opt->max_bitrate == (int) 225
...
} else {
if(vorbis_encode_setup_managed(&vi, opt->channels, opt->rate,
opt->max_bitrate>0?opt->max_bitrate*1000:-1,
opt->bitrate*1000,
opt->min_bitrate>0?opt->min_bitrate*1000:-1)){
}
...
}
```
If quality is set, it fails to multiply by 1000;
If I do:
oggenc -q 3 -m 96000 -M 225000 produces:
```
Nominal bitrate: 112.000000 kb/s
Upper bitrate: 225.000000 kb/s
Lower bitrate: 96.000000 kb/s
```
Not sure if this was by design, but its certainly not indicated in the man page. :)
Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/613oggenc's flac decoding ignores audible errors in decoding2018-01-22T04:18:37Zjhammjohnsonoggenc's flac decoding ignores audible errors in decodinghi,
I recently converted some flac's to oggs on a system that has hardware problems that produceds sig11's and such. when decoding the flac's to wav using flac itself, flac would sometimes fail due to such errors. When converting the ...hi,
I recently converted some flac's to oggs on a system that has hardware problems that produceds sig11's and such. when decoding the flac's to wav using flac itself, flac would sometimes fail due to such errors. When converting the flac's to ogg's directly using oggenc, or when playing the flac's with ogg123, when such errors occured there would often be bery loud audible noise inserted into the results. oggenc ought to catch such errors just as Flac does and abort encoding with an error that the user can catch and retry. As it stands, even though I am getting some better hardware, I am going to have to decode my flac's into wav and re-encode into vorbis rather than using oggenc's automagical functions, because I don't trust that oggenc will catch any errors if they do somehow occur.
here's some version info btw:
hurl:/data/gimp/jason/attacking_self# dpkg -l|grep vorbis
ii libvorbis0a 1.1.0-0.0 The Vorbis General Audio Compression Codec
ii libvorbisenc2 1.1.0-0.0 The Vorbis General Audio Compression Codec
ii libvorbisfile3 1.1.0-0.0 The Vorbis General Audio Compression Codec
ii vorbis-tools 1.0.1-1.2 Several Ogg Vorbis Tools
-JaredMichael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/608vorbis-tools/ogg123/speex_format.c:22 speex.h: No such file or directory2005-07-11T10:44:19ZGitlab Botvorbis-tools/ogg123/speex_format.c:22 speex.h: No such file or directoryquick patch is above.
If vorbis-tools should support an old header files of Speex, configure.in might have to be corrected, I guess.
```
--- vorbis-tools.orig/ogg123/speex_format.c Thu Dec 23 11:51:51 2004
+++ vorbis-tools/ogg123/spe...quick patch is above.
If vorbis-tools should support an old header files of Speex, configure.in might have to be corrected, I guess.
```
--- vorbis-tools.orig/ogg123/speex_format.c Thu Dec 23 11:51:51 2004
+++ vorbis-tools/ogg123/speex_format.c Sun Jan 23 05:44:02 2005
@@ -19,10 +19,10 @@
#include <stdlib.h>
#include <string.h>
#include <ctype.h>
-#include <speex.h>
-#include <speex_header.h>
-#include <speex_stereo.h>
-#include <speex_callbacks.h>
+#include <speex/speex.h>
+#include <speex/speex_header.h>
+#include <speex/speex_stereo.h>
+#include <speex/speex_callbacks.h>
#include <ogg/ogg.h>
#include "transport.h"
#include "format.h"
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/605oggenc time selection2008-08-31T18:34:01ZGitlab Botoggenc time selectionOggenc has AFAIK no options what part of the song should be encoded, as --max-length=60s or --skip=43s which could be very important for
users with graphical frontends, rippers, sound editors etc.Oggenc has AFAIK no options what part of the song should be encoded, as --max-length=60s or --skip=43s which could be very important for
users with graphical frontends, rippers, sound editors etc.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/603oggenc overflow on large enocodes2008-02-16T00:45:25Zlsd-25oggenc overflow on large enocodesHi, I often use oggenc in linux to record directly from line in on my soundcard, on large files there seems to be an integer overflow as shown below. The encode completes succesfully and files are fine.
.....
Done encoding file "My Fil...Hi, I often use oggenc in linux to record directly from line in on my soundcard, on large files there seems to be an integer overflow as shown below. The encode completes succesfully and files are fine.
.....
Done encoding file "My File.ogg"
File length: -585m -38.0s
Elapsed time: 1037m 22.0s
Rate: -0.5645
Average bitrate: -254.2 kb/s
# ogginfo -v My\ File.ogg
Processing file "My File.ogg"...
New logical stream (#1, serial: 05b8e791): type vorbis
Vorbis headers parsed for stream 1, information follows...
Version: 0
Vendor: Xiph.Org libVorbis I 20040629
Channels: 2
Rate: 44100
Nominal bitrate: 128.000000 kb/s
Upper bitrate not set
Lower bitrate not set
Vorbis stream 1:
Total data length: 1116537201 bytes
Playback length: 1037m:33s
Average bitrate: 143.483649 kbps
Logical stream 1 ended
Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/601bug reporting information missing in vorbis-tools README2005-07-23T20:19:34Zclockbug reporting information missing in vorbis-tools READMEbug reporting information missing in vorbis-tools 1.0.1 README.bug reporting information missing in vorbis-tools 1.0.1 README.Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/588Updated fr.po file2005-07-11T10:42:54ZGitlab BotUpdated fr.po fileUpdated fr.po file for vorbis-tools-1.0.1 (never used trac before, how can I
attach my patch ?)Updated fr.po file for vorbis-tools-1.0.1 (never used trac before, how can I
attach my patch ?)Manuel LoraManuel Lorahttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/578Encoding large number of files in one go crashes system2007-06-17T08:51:57ZGitlab BotEncoding large number of files in one go crashes system```
I am running Windows XP with Service Pack 2 and the Vorbis 1.0.1 Tools.
When I was trying to run a large batch query converting standard WAV files (14
GB in 255 Files (21 CDs) in a single directory) to Vorbis using OggDropXP
(Qual...```
I am running Windows XP with Service Pack 2 and the Vorbis 1.0.1 Tools.
When I was trying to run a large batch query converting standard WAV files (14
GB in 255 Files (21 CDs) in a single directory) to Vorbis using OggDropXP
(Quality: 6, no special options), the whole system reproducibly froze (3x) after
approximately 1 GB of source data had been processed.
Suspecting OggDrop, I generated a batch file that individually called oggenc for
each one of the remaining 200 files. Running the batch file in turn reproducibly
led (4x) to a blue screen (IRQL_NOT_LESS_OR_EQUAL variety). The crash once again
occured after about 1 GB of source data.
I have just finished encoding all files by dropping the remaining 100 files into
OggDrop *one CD at a time* without incident.
I do not think that the actual file content has anything to do with the problem,
as the files affected by crashes were all handled without problems when I
subsequently resumed encoding with the exact same file.
My system is stable and I think I can rule out completely unrelated causes for
the crashes, which occurred exactly, and only, when I used OggDrop/OggEnc. I had
extensively used OggDrop before without any problems, but only for one CD at a
time.
Of course, it is possible or even probable that the actual fault does not lie
with OggEnc/OggDrop, but the Windows Kernel/Explorer and was merely triggered
through the interaction with OggEnc. Still, I find my system's behavior quite
bizarre. While I could at least in principle imagine how a large number of files
could crash OggDrop, I have no idea why OggEnc should be affected by being run
50 times in a row.
I know this bug report is only partially helpful - if I can reproduce the blue
screen one more time, I will add the detailed information (especially which
module caused it).
```Michael SmithMichael Smithhttps://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/565Ogginfo bitrate display is inconsistent2008-02-16T00:49:12ZKyungjoon LeeOgginfo bitrate display is inconsistent```
Nominal bitrate, upper bitrate, lower bitrate is shown in units of kb/s, with a
slash. Average bitrate is shown in units of kbps, with the letter p.
``````
Nominal bitrate, upper bitrate, lower bitrate is shown in units of kb/s, with a
slash. Average bitrate is shown in units of kbps, with the letter p.
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/559oggenc bails out early on some flac files2008-09-01T00:07:13Zjs.lebacqoggenc bails out early on some flac files```
when I want to make an ogg file from a flac file, oggenc doesn't work properly
Example :
jsl@sedentaire:~/mp3/Brian May/another world$ oggenc -q 7 *.flac
Ouverture avec le module flac : FLAC file reader
Encodage de "01-space-Br...```
when I want to make an ogg file from a flac file, oggenc doesn't work properly
Example :
jsl@sedentaire:~/mp3/Brian May/another world$ oggenc -q 7 *.flac
Ouverture avec le module flac : FLAC file reader
Encodage de "01-space-Brian May.flac"
en "01-space-Brian May.ogg"
à la qualité 7,00
Fin de l'encodage du fichier « 01-space-Brian May.ogg »
Longueur de fichier : 0m 00,0s
Temps écoulé : 0m 00,1s
Taux: 0,0000
Débit moyen : inf kb/s
Ouverture avec le module flac : FLAC file reader
Encodage de "02-business-Brian May.flac"
en "02-business-Brian May.ogg"
à la qualité 7,00
[ 75,7%] [ 0m06s restant] /
Fin de l'encodage du fichier « 02-business-Brian May.ogg »
Longueur de fichier : 3m 52,0s
Temps écoulé : 0m 19,0s
Taux: 12,2593
Débit moyen : 208,6 kb/s
[...]
As you can see (sorry for the french version of the output), oggenc stop before 100% with the
second file, and simply don't start with the first... I had the same problem with Mandrake 10.0
(AMD64), 10.1beta1(x86), and now with Debian Sarge (so, it's not a distribution-specific
problem).
I must say I have the same problem with another flac files (from magnatune if you want to
know), wich I was able to oggenc with a previous Mandrake (9.2) and another computer
(i386). So, I can't say if it's a platform-specific problem (AMD64 ?) or a new problem with new
versions of oggenc.
Regards, JSL.
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/555move common build setup stuff to a common directory to use2018-01-22T04:18:38ZGitlab Botmove common build setup stuff to a common directory to use```
There are build issues that would need to be fixed across all modules. Also,
various modules have slightly different build setups (compare autogen.sh). The
nice way to fix this is to put everything that can be shared in a "common"
s...```
There are build issues that would need to be fixed across all modules. Also,
various modules have slightly different build setups (compare autogen.sh). The
nice way to fix this is to put everything that can be shared in a "common"
subtree that gets pulled in by each of the subprojects.
Doing this would allow me to refine and solve various issues, like the
mkinstalldirs problem for gettext, and making autogen.sh a bit smarter.
```Gitlab BotGitlab Bothttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/540Crash when resampling using oggenc2008-05-29T23:35:35ZtommrobinsonCrash when resampling using oggenc```
Hi, im getting a problem when using oggenc with resampling from flac.
e.g. oggenc --resample 32000 --downmix --output=test.ogg "c:\flac\#various\twin
peaks - fire walk with me\angelo badalamenti - the pink room.flac"
The file is s...```
Hi, im getting a problem when using oggenc with resampling from flac.
e.g. oggenc --resample 32000 --downmix --output=test.ogg "c:\flac\#various\twin
peaks - fire walk with me\angelo badalamenti - the pink room.flac"
The file is successfully created, but at the end I get an error
message "oggenc.exe has encountered a problem and needs to close...". This
doesnt seem to happen if i leave out the --resample part.
Im pretty new to oggenc etc so sorry if its a problem with my setup somehow.
Keep up the good work
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/522segfault with ridiculously low resample rates2004-05-06T06:01:47ZGhost Usersegfault with ridiculously low resample rates```
The following segfaults.
oggenc -q -1 --resample 1000 foo.wav
It's a silly thing to ask for, but it shouldn't crash. :)
``````
The following segfaults.
oggenc -q -1 --resample 1000 foo.wav
It's a silly thing to ask for, but it shouldn't crash. :)
```Michael SmithMichael Smithhttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/502compatability - mpg123 - rate option2018-01-22T04:18:38Zjrollysoncompatability - mpg123 - rate option```
This is a feature request to implement the -r (output rate) option, in order to
provide drop in compatability with mpg123 for various applications including
telephony applications (which normally require a 8000 Hz sample rate)
``````
This is a feature request to implement the -r (output rate) option, in order to
provide drop in compatability with mpg123 for various applications including
telephony applications (which normally require a 8000 Hz sample rate)
```Stan SeibertStan Seiberthttps://gitlab.xiph.org/xiph/vorbis-tools/-/issues/46332-bit float input broken2006-06-12T11:20:05ZTimothy B. Terriberry32-bit float input broken```
When support for 24-bit integer .wav files was added, it broke existing 32-bit
float support, since the check for sample size is applied regardless of the
format type.
--- audio.c,v1.34
+++ audio.c
if( format.align == format.chann...```
When support for 24-bit integer .wav files was added, it broke existing 32-bit
float support, since the check for sample size is applied regardless of the
format type.
--- audio.c,v1.34
+++ audio.c
if( format.align == format.channels*samplesize &&
format.samplesize == samplesize*8 &&
(format.samplesize == 24 || format.samplesize == 16 ||
- format.samplesize == 8))
+ format.samplesize == 8 ||
+ (format.samplesize == 32 && format.format == 3)))
{
/* OK, good - we have the one supported format,
now we want to find the size of the file */
```Michael SmithMichael Smith