similar to: oggenc autonaming with bitrate and input filename.

Could someone please search and replace the msvc projectfile for oggenc: "c:\src" -> "..\.." I tried to make a patchfile but I dont know if I got it right... /Erik <HR NOSHADE> <UL> <LI>TEXT/PLAIN attachment: oggenc.dsp.diff </UL> -------------- next part -------------- A non-text attachment was scrubbed... Name: oggenc.dsp.diff Type:

Hi everybody! Yesterday I startet working with oggenc RC2, and I encountered a difference between actual and documented behaviour in oggenc. If you run oggenc myfile.wav -t MyTitle the documentation/man page says it generates myfile.ogg, but actually MyTitle.ogg is generated. From the code it looks like being intentional. In my opinion the documented behaviour makes more sense, but that's

With this patch, ogginfo will display bitrate information (upper/lower/nominal/average bitrate). It is patched against today's CVS code (main branch). I am also working on true VBR support in oggenc (the user can specify the minimum & maximum bitrate) and will send a patch when it's done. <HR NOSHADE> <UL> <LI>application/x-gzip attachment: ogginfo-diff.gz

Hello, I have found that there are some WAV files which have a "fmt" chunk size greater then 16 bytes (length indicator greater then 16). The patch is attached. What is the normal method for submiting patches? Regards, Chris Wolf <HR NOSHADE> <UL> <LI>application/octet-stream attachment: audio.c.patch </UL> -------------- next part -------------- A non-text

I was about to patch oggenc to replace '/' in the strings included in the -n format [*], but that's too platform specific. Thinking waaaaay back, I realise that it's not even Windows versus the rest of the world. How should this be handled? The Windows criteria are probably generally useful, they include nuisance characters for shells, but I wouldn't like to lose colon

Hi all, I've got a strange problem. I was just encoding a new CD I bought a couple of days ago (Muse - Hullabaloo Soundtrack) when I ran into a strange bug. After ripping track 8, CD 1 with cdparanoia under OpenBSD/alpha, I wanted to encode it with oggenc (latest version from the OpenBSD-current ports tree, (`oggenc -v` says 'OggEnc v1.0 (libvorbis 1.0)')). Here's the output :

Here is a patch that implements a check so that libvorbis complains when a comment string that is not UTF-8 is added. This patch will break oggenc without my UTF-8 patch. (http://noa.tm/oggenc-utf8.2.diff.gz) I've tested the verification algorithm on ~150k strings in various charsets (from the gnome translations) and about 0.02% of the strings that has chars with 8th bit set is valid UTF-8

oggenc -b 128 -d 1985 -N 01 -t "Black Planet" -l "First and Last and Always" -a "Sisters of Mercy" track01.cdda.wav egs in free in simple_utf8_encode. I tracked it down to a mis-calculated buffer size for malloc. I've attached the patch that fixes it (for me:). The only problem I have with the rest of the code is figuring out how the terminating 0 (null,

This is probably addressed to Michael Smith :) I have been playing with the latest oggenc and full libs from the SVN attempting to get the hard min/max limits to work with the quality settings. The way it is currently set in encode.c does not appear to work; ie., the result is the same with or without the hard limits set. However, if I amend the code such that management is NOT turned off if

I have a small feature request for oggenc: Can a command line option be added to allow the user to set the first serial number to be used for the output ogg stream? This only takes a few lines of code, actually. Rationale: it is quite helpful for debugging other encoders. If oggenc is the "reference" encoder, ensuring that your new whiz-bang encoder has diffable output to oggenc is a

Happy new millenium! Summary: I'm having a problem queueing up the ogg_packet results of vorbis_analyze() for later writing to an .ogg stream. The docs don't seem to say if this is permissable or not. Hence, I don't know if I'm using the API incorrectly, or if this is an actual bug. ----- Attached is a short patch to vorbis-tools/oggenc/encode.c (from CVS head, 01/01/01... I

Simply put: When will Oggenc accept input files with higher resolution than 16-bit? Thumbs up to all the developers - the sound quality of Vorbis just keeps amazing me! I only use Ogg Vorbis when distributing my music today. Cheers, - Tomi <p><p><p><p>--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To

The attached patches (vs CVS) allow me to build oggenc, ogginfo, and vorbiscomment on Win32. (Win64 takes a few more patches to the .dsp and build*.bat files, but I presume everyone building on Win64 knows what they are doing anyway.) Peter Harris <HR NOSHADE> <UL> <LI>application/octet-stream attachment: patch.3 </UL> -------------- next part -------------- A non-text

I'm not sure if this is an encoder bug or just a weakness in the algorithm, but I have a sample of "Time" from Dark Side of the Moon, where the clocks go off in the beginning. There's one clock in the right channel 34 seconds in just as they're winding down. In the vorbis encoding, the clock 'studders' and there seem to be some low-frequency pops. A bit like the

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! I made these nifty pythonscripts to make my ripping+encoding+sorting easier. They are designed to use in Grip. w_oggenc: Call this instead of oggenc in Grip with the command-line: "%A" "%d" "%t" "%a" "%n" "%y" "%G" "%i" Now you can put additional info in the

First of all, keep the replies on the mailing list. Are you subscribed to the mailing list? On Aug 24 09:44:56, nguyenquocthao00 at gmail.com wrote: > The file ogg is the same, I know that. So oggenc must have produced exactly the same audio. So it must be specific to the "live" playing. > And the problem is not from curl, > curl is only an example to replicate my problem.

Reported-by: Thomas K?ller Bug: https://bugzilla.redhat.com/1185558 --- oggenc/oggenc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/oggenc/oggenc.c b/oggenc/oggenc.c index ea105b2..323dedb 100644 --- a/oggenc/oggenc.c +++ b/oggenc/oggenc.c @@ -239,7 +239,7 @@ int main(int argc, char **argv) if(opt.rawmode) { - input_format raw_format = {NULL,

Attached is the manual page for OggEnc. Please proofread it and commit to CVS. Also remember to edit Makefile.in to install the man page to the appropriate location. Thanks. --- Stan Seibert .\" Process this file with .\" groff -man -Tascii oggenc.1 .\" .TH oggenc 1 "August 13, 2000" "" "Vorbis Tools" .SH NAME oggenc \- encode audio into

Hi, I think this should also go on the llvm-dev mailing list... On Sat, Jul 13, 2013 at 11:18 PM, Star Tan <tanmx_star at yeah.net> wrote: > > At 2013-07-14 02:30:07,"Tobias Grosser" <tobias at grosser.es> wrote: >>On 07/13/2013 10:13 AM, Star Tan wrote: >>> Hi Tobias, >> >>Hi Star, >> >>thanks for the update. I copied the polly

Hi, I recently noticed that a relativly short wav file loses the last second (truncated perhaps) when I ran it through oggenc. Originally the wav was 25 seconds, the ogg is 24 seconds. This happens at various quality levels, and I saved several copys of the file on a webserver at http://array26.rockefeller.edu/www/ogg/ If anyone wants to confirm my observations. The command lines were: