similar to: GCC 2.95.2(Win32/Mingw32) build

I've put together a first cut for a Win32 DLL using the BladeEnc interface. Right now, it's just a drop-in replacement for BladeEnc.dll that ignores all encoding parameters passed to it and uses the info_A vorbis_info struct (same as the encoder_example). It's not particularly useful as of yet, but you can rename it to BladeEnc.dll and use it with any number of rippers out there

Hi all, I've just posted another version of vorb_enc.dll (w/source code) at http://xtractor.sourceforge.net/vorbdll-20000626.zip It will still work as a drop-in replacement for bladeenc.dll (just rename the files that your ripper creates from MP3 to OGG), but will also accept info for the ogg comment header in the vorb struct in the format union of the BE_CONFIG struct. I'll be

>Win95. Unfortunately, the encoder_example segfaults. I get the same >results from Cygwin as well. Problem solved! (Or rather, worked around...) The problem with the segfault appears to have indeed been with alloca. There is a function _alloca in libgcc.a that comes with the mingw32 distribution of gcc-2.95.2. After examining the generated assembly code from envelope.c (and others),

LLVM's typedefs for int32_t etc. under MSVC (in Support/DataTypes.h) conflict with those used by other third-party libraries. Instead of these: #ifdef _MSC_VER typedef __int64 int64_t; typedef unsigned __int64 uint64_t; typedef signed int int32_t; typedef unsigned int uint32_t; typedef short int16_t; typedef unsigned short uint16_t; typedef signed char int8_t; typedef unsigned char uint8_t;

This is all happening on a box with: Win 2k SP3 512K RAM 1.2 GHZ Celeron The PC has noother load...all its doing is downsampling an MP3 stream to lower bitrates. I'm using the LAME_ENC.DLL with streamTranscoder. There is no version number tagged on the lame_enc.dll, but the file is dates July 2002. When I refer to "skipped and popped and dropped" I am referring to your

> Dave Yeo wrote: >> Yes that makes sense. Requiring a C99 compliant compiler seems quite reasonable. > Well I'm actually going to be even more reasonable than that. The only bits of C99 that flac will really require is header file > with C99 standard width integers (int8_t, uint8_t, int16_t etc). Erik I would recommend including with the distribution a file for windows

Hi, Looking at the language reference, vscale is an integer. This might pose a problem for fractional vscale. Furthermore, I believe that vscale is constant throughout the life of the program; so if RISC-V vscale can vary from instruction to instruction that may also be problematic unless you can just commit to one specific value of vscale. Also, I had a question about your table. Based

I have Oddsock loaded and it will not complete the connecto to the server. I have been trying it in MP3 first before I move to Ogg to be sure I am understanding all I need to know. And it will connect and the eye candy will go let to right and the server will show that there is a connection, but the thing never sends data and a media player like WinAMP will will tell me that there is no ICY

(i hope this is correct m.list) Hi, there is a small compiling problem for mingw when compiling on libogg.. in include/ogg/os_types.h : ogg_int64_t, ogg_int32_t, etc are defined correctly on cygwin and MSVC/Borland but not on mingw... i have attached a patch that will fix this problem (i hope it attaches correctly) thx, Nehal --- os_types.h.old Fri Jul 19 02:25:52 2002 +++ os_types.h Tue

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09.02.2012 21:41, Ben Allison wrote: >>> Dave Yeo wrote: >>>> Yes that makes sense. Requiring a C99 compliant compiler >>>> seems quite >> reasonable. >>> Well I'm actually going to be even more reasonable than that. >>> The only >> bits of C99 that flac will really require is

Hi, In RISC-V v-extension, operations could operate on a group of vector registers; we called it LMUL. If LMUL equals 2, it means we could operate on 2 vector registers at the same time. So, we have the following combinations of types. LMUL = 1 LMUL = 2 LMUL = 4 LMUL = 8 int64_t | vscale x 1 x i64 | vscale x 2 x i64 | vscale x 4 x i64 | vscale x 8

Martin.Rottler at nuernberger.de wrote: > I have problems compiling openssh-3-7-1p2 on Reliant UNIX. > (same problem with 3-7-1p1) > > first error was: > ../defines.h 144: [error] CFE1101 "int8_t" has already been declared in the > current scope > typedef char int8_t; The configure test tests for int8_t, int16_t and int32_t before defining HAVE_INTXX_T. Does your

Okay, everything as the first large one I sent today, with a few extra mods. _PATH_MAILDIR is only used in sshd.c, that I can see, so moved the #ifdef from config.h.in to there. several files had __progname defined in the middle of the code, as well as at the top of the code, so cleaned those out. all the fixes for u_int32_t -> uint32_t and u_int16_t -> uint16_t, plus added appropriate

On Mon, Sep 23, 2019 at 12:05:11PM -0500, Eric Blake wrote: > > + int nbdkit_parse_long (const char *what, const char *str, long *r); > > + int nbdkit_parse_unsigned_long (const char *what, > > + const char *str, unsigned long *r); > > Do we really want to encourage the use of parse_long and > parse_unsigned_long? Those differ between

Hi, I'm working on writing a FLAC encoding plugin for a personal cd ripping project of mine which uses paranoia for the raw audio extraction. My basic setup which follows gets me oddly high pitched audio with lots of noise (although the music IS somewhat recognizable). #include <FLAC/stream_encoder.h> FLAC__StreamEncoder *encoder; FILE *output_file_descriptor; encoder =

Hi! I've spent the last few nights digging into the Vorbis source and working to implement a vorbis_synthesis_pcmout_int() function that kicks out interleaved int16_t pcm data. I think its important to have this function available to make the job for people using the codec a little easier. This function abstracts out the conversion to int16_t and removes the extra overhead of moving the pcm

I think the example in the comment has a '-' that shouldn't be there (line 108): /********************************************************************* Encoding using a VBR quality mode. The usable range is -.1 (lowest quality, smallest file) to 1. (highest quality, largest file). Example quality mode .4: 44kHz stereo coupled, roughly 128kbps VBR ret =

Hi. Has anyone tried http://svn.xiph.org/branches/theora-mmx this code on Win32 ? I can compile it with very small modification, 304c304 < ogg_int16_t *const temp= (ogg_int16_t*)align_tmp; --- > ogg_int16_t *const temp= (int16_t*)align_tmp; but outputs seem terribly broken. -> ex. http://mycomputer.cc/temp/mmx-out.ogg GCC version is 3.4.2. $ gcc --version gcc.exe (GCC) 3.4.2

Seeing the discussion on using vorbis as a benchmark has prompted me to post a few results that I have. Times are as reported by oggenc. I used track 8 on Stereolab's Dots and Loops album. It's 334 seconds long. Tests on windows machines used the windows oggenc binary from www.vorbis.com Tests on unix machines used oggenc compiled on that machine. Compaq PIII - WinNT (1000 MHz) - 91

Hello, Scott. > Checking the assembly from llc, the first alloca call is to allocate > local vars in _main. Is this just the state of the code at 2.0 when > built with vs.net, or is there something that I've managed to > mis-build locally? _alloca is used to probe the stack, if you asks for locals of size more that 4k. This is pretty ugly, but the names of this functions differs