similar to: libvorbis make and spec fixes

Hello, A question: Can we use uncoupled encoding in the 1.0? (current CVS) How? Because I see some uncoupled definitions (books\uncoupled\res_books_uncoupled.h), but I don't know how could I switch to it manually. Perhaps with an option in the vorbis_encode_ctl() function... Because I think so it's better if I don't use any kind of channel coupling (lossless neither) on high bitrates

Hi all, In order to get icecast working i found that i had to install libao-0.8.4 libogg-1.1 libvorbis-1.0.1 flac-1.1.0 speex-1.0.3 vorbistools-1.0.1 icecast-2.0.0 So i grapped the source files. I copied all the files to an 32-bit Intel machine, and *there* all files configured, compiled and installed OK But on the intended target machine (SUN blade server) i have a problem... libao and libogg

The autoreconf tool is provided by autoconf to do what custom autogen.sh scripts in many projects used to do. Only it is more robust and widely tested. It has been available for several years, too. No reason to rely on custom code for this. Signed-off-by: Max Horn <max at quendi.de> --- Makefile.am | 2 - autogen.sh | 168

While I'm at it here is an update to the libogg .spec-file fixing two small things. /noa <p> -- begin:vcard fn:Daniel Resare tel;cell:+46739442044 tel;work:+468332040 adr;work:Scheelegatan 36; 112 28; Stockholm; Sweden end:vcard pgp fingerprint: 8D97 F297 CA0D 8751 D8EB 12B6 6EA6 727F 9B8D EC2A -------------- next part -------------- Index: libogg.spec

This patch cleans up the vorbis-tools Makefile.am files so they work with both automake 1.4 and 1.6. Some changes to configure.in were also needed in order to get things to work (and to fix some ac 2.50 issues). Please remove config.h from cvs as it is a generated file and empty anyway. automake 1.6 isn't really incompatable with 1.4, it's just more picky about you sticking to the rules:

Hi Stuart, you are compressing it at 6kbit/s. Then, then SILK mode is probability used and the Silk mode is much faster than CELT. Do you also some figures at 64kbit/s? It is strange that Opus 1.1 got slower in the Silk mode - may the speech/voice selection adds some overhead. I would be interested in seeing the performance of the 64 kbit/s in both Opus 1.0 and Opus 1.1. With best

For my own needs I have created the .spec file needed for rpm packaging of the flac package. End users --------- If anyone is interested in the resulting rpm-files i have made them available on http://noa.tm/flac-rpms/ FLAC maintainers ---------------- I have attached the specfile along with hooks in Makefile.am and configure.in in unified diff format so that they are ready for inclusion in

I have just started trying Opus with a view to using it in a project. I am interested in embedded hardware and tried it on the Raspberry Pi using the raspbian distro. The version of libopus in the repos is 0.9.14. I installed this and tried encoding 2 minutes of speech from a librevox recording. It managed this at a respectable pace for complexity 10: Skipping chunk of type "LIST",

Resampling to 48khz speeds them both up but the disparity is about the same: 2.609 to 3.69. Best Regards, Stuart Marsden On 17 December 2013 17:04, Stuart Marsden <stuartmarsden at finmars.co.uk>wrote: > Christian, > > Complexity 0, 6kbps: > > 0.9.14 Speed 5.204 > 1.1 Speed 5.218 > > A slight win on that run but they vary enough to say about the same. At >

the attached patch against current svn brings autogen.sh in line with that in ogg/, and updates Makefile.am appropriately. (needed to build on os x and probably elsewhere) Conrad. -------------- next part -------------- Index: Makefile.am =================================================================== --- Makefile.am (revision 6517) +++ Makefile.am (working copy) @@ -1,6 +1,6 @@ ## Process

Christian, I will give 64kbit/s a try and post the figures. My own project is voice only and requires low bitrate so was hoping that it was just the way I was compiling and not an actual regression in speed for SILK. The raspberry PI is quite a cheap and handy reference platform though the ARM side is fairly underpowered but has a great GPU. It also has no audio in which is a pain for playing

I had expected that the default bitrate for the encoder would be the same as setting it to OPUS_AUTO, but I'm getting difference results: >opusenc --comp 4 sample.wav sample.opus Encoding using libopus 1.3-rc2 (audio) ----------------------------------------------------- Input: 8 kHz, 1 channel Output: 1 channel (1 uncoupled) 20ms packets, 25 kbit/s VBR Preskip: 312

- INCLUDES is deprecated, and CPPFLAGS is an user-defined variable, use the proper AM_CPPFLAGS instead - Remove FLAC__INLINE definition, providing proper replacement for MSVC compilers. - Detect if we have C99 's lround and provide a replacement for windows... --- configure.ac | 32 ++++++++-------------------- examples/c/decode/file/Makefile.am

Hi, ffmpeg2theora currently assumes that the first frame in the input file also corresponds to the first audio sample in the input file, which might not be true for many file formats. I have especially bad problems with MPEG-TS streams that I recorded via DVB-T (sync off by 0.5 seconds etc.). Encoding chapter-ranges from DVD might yield similar problems. The attached patch fixes that, using

I just recently found that opus_multistream_encode_float is returning -1 (OPUS_BAD_ARG) with the libopus 1.1 build but works just fine with the libopus 1.0.1 and libopus 1.1-beta builds. I tried using opus_multistream_encoder_create and opus_multistream_surround_encoder_create. Tried with coupled and uncoupled quadraphonic and uncoupled stereo encodes. I'm dynamically loading the libopus

I really don't know if this is the same problem that was reported by Ingo Saitz (I really couldn't say which one was 128kbit and which was the original wav when blind-testing. The original had some distortion that perhaps does somehting with my cheapo soundcard) but here's a description of what i've found: When doing some sample encoding with rc2 (rebuilt rpm with latest redhat

Sorry for the lack of reproducible data, but this seems to be a problem inherent to my dataset and I can't figure out where the issue is. I have several data frames set up as a time series with identical POSIXct date formats. If I keep the original data in data frame format and merge them using base merge- everything is perfect and everyone is happy. If I transform the data frames to zoo

Greetings, I am having some trouble when compiling libvoribis-1.0. It bombs out when compiling the examples dir. The output:: <p>gcc -O20 -ffast-math -mno-ieee-fp -D_REENTRANT -fsigned-char -O2 -march=i586 -DUSE_MEMORY_H -static -o decoder_example decoder_example.o ../lib/.libs/libvorbis.a -L/usr/lib -lm /usr//lib/libogg.a ../lib/.libs/libvorbis.a(mapping0.o): In function

I had lunch with an interesting guy who had gotten .com-money to record the whole bible professionally with good actors (in swedish and english, kjv). The idea was to sell custom made compilations of biblical texts on cd over internet. The company is now out of money (surprise!), but all the material is recorded (about 350 hours) and if anyone gets a good idea on what to use the material to, it

(Is this the right list for libao patches?) The following adds support for a sndio plugin to libao. sndio is OpenBSD's new audio API. diff -uNrp libao-0.8.8.orig/configure.ac libao-0.8.8/configure.ac --- libao-0.8.8.orig/configure.ac Thu May 24 12:51:05 2007 +++ libao-0.8.8/configure.ac Mon Dec 8 16:34:44 2008 @@ -300,6 +300,11 @@ dnl Check for Sun audio AC_CHECK_HEADERS(sys/audioio.h)