similar to: integer pcm decode patch

I was just trying to build the shared lib stuff and include it into RC4 of FreeAmp 2.1 today, but I found that the .def file for the vorbis build stuff is missing and therefore no .lib file is generated. Is there a reason for that, or is it just an omission? In any case, I will hold off on the latest and greatest vorbis stuff in FreeAmp until next week.... --ruaok Freezerburn! All else

The beta4 rpms from the vorbis.com site do not install the link to libogg.so.0: lrwxrwxrwx 1 root root 15 Mar 16 18:24 libogg.so.0 -> libogg.so.0.1.0 -rwxr-xr-x 1 root root 16269 Feb 26 04:53 libogg.so.0.1.0 The source dist does it correctly: lrwxrwxrwx 1 root root 15 Feb 27 13:03 libogg.so -> libogg.so.0.1.0 lrwxrwxrwx 1 root root

Now that a few folks of the appropriate technical background are listening (and that a couple more I'm expecting to join in a bit can grab this message from the archive), it seems prudent to start talking about where Vorbis is and what it needs. I'll assume at this point everyone knows what Vorbis is; stop me if I'm wrong ;-) More of the code is complete than the web pages might

Hi, I am interested in helping out with the project. What tasks are on the TODO list? I am one of the lead developers of the FreeAmp (www.freeamp.org) project so obviously I will create a decoder plugin for our player but I would also like to help out with the Vorbis CODEC itself. elrod --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/

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 all, While reading through various bits of libvorbis and vorbisfile, and then thinking about how to implement other features in the xmms and winamp plugins, I had some thoughts... Vorbisfile is very useful, and very easy to use. It is, however, tied to stdio - which means you can't use it for lots of other stuff where it'd be useful - like streaming, or (under win32) avoiding stdio

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

Hello: I don't usually post requests like this to mailing lists, but I've just about run out of other options. The vorbis.org and vorbis.com sites both make mention of a beta vorbis output plug-in for freeamp, but I'm blowed if I can find it anywhere. It's definitely not in the vorbis.com download section (unless it's been placed their within the last 24 hours or so), and

Hello: I don't usually post requests like this to mailing lists, but I've just about run out of other options. The vorbis.org and vorbis.com sites both make mention of a beta vorbis output plug-in for freeamp, but I'm blowed if I can find it anywhere. It's definitely not in the vorbis.com download section (unless it's been placed their within the last 24 hours or so), and

I've come full circle on the Ogg text stream format, back to arbitrary associated xml streams. What's changed? Mostly rolling the requirements around in my head, and weighting them differently. I think we've dealt with the complexity issue; this functionality can be optional for "dumb" audio players, and possibly also for dumb video players, though there it's a smaller

> 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

Hello All I have successfully run the Opus Decoder for 16-bit WAV files. However when doing the same on 8-bit, the decoder produces noise, but on 16 bit data the output is working. Both the 8 and 16 bit files are from the same source and hence except for some loss of quality on 8 bit, they are identical in total play back duration. For both 8 and 16 bit data I have used the following parameters

From: Jyri Sarha <jsarha at ti.com> I optimized Speex resampler for NEON capable ARM CPUs. The first patch should speed up resampling on any platform that can spare the increased memory usage. It would be nice to have these merged to the master branch. Please let me know if there is anything I can do to help the the merge. The patches have been rebased on top of master branch in

Hi folks, I've been dickering around again, wasting the time away.... and today Brian Zisk (chief Vorbis Evangelist among other things) said, "Hey! We need to demo to the world on the 4th of April!" Hooo boy. Time to suck it up and bang it out. The Vorbis libs are not a problem. I'm in process of checking in my new psychoacoustics (they're real pretty!) based on

OK, into the nitty-gritty, albeit a high-level version. If it sounds like I'm glossing important details, you're right. This discusses only the basic DSP; precise coding, framing, sync, etc, will be in another mail. Vorbis is a hybrid transform domain general purpose audio encoder, like MPEG in some respects (it is rooted in much of the same basic theory). For the most part, the

Speaking of Metadata, how's work going on the definition? Looking back at the list archives, there seems to be a semi-plan to use Robert Kay's DTD from http://www.cdindex.org/dtd/TrackInfo.dtd, but I'm conserned that it's too specialized for video and we'll end up having a special case for audio-only files. There are a couple of general issues here. Micheal Smith suggested on

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

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;

-----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, all, I build clang-tidy by "ninja clang-tidy", but when I run below command, I get no checks. Where is the clang-diagnostic* checkers? Thanks in advance. > $ /Users/zyg/Documents/workspace/llvm-project/llvm/cmake-build-debug/bin/clang-tidy --checks="-*,clang-diagnostic-*" --list-checks No checks enabled.