similar to: seek_absolute problem

--- David Collett <jg@webone.com.au> wrote: > Hello, > I have been changing my (C++)program over to the new FLAC++ API which > > has gone relatively smoothly. > > However, the function seek_absolute() (from the FLAC::Decoder::File > class) does not seem to work. It always returns false and doesnt seek > at > all. Using gdb, I have narrowed down the problem

Nevermind, I have discovered the problem(not really a problem). I had called: set_metadata_ignore_all(); because I didnt actually need to use the metadata in my application. But it seems that with this option set, "total_samples" is not set correctly after calling init(). Upon further debugging, I discovered that the test "sample < total_samples" was what is failing in

Hello, I have been changing my (C++)program over to the new FLAC++ API which has gone relatively smoothly. However, the function seek_absolute() (from the FLAC::Decoder::File class) does not seem to work. It always returns false and doesnt seek at all. Using gdb, I have narrowed down the problem somewhat, but being the novice programmer that I am, I still don't know whats wrong. When I

Has anyone tried to build flac with the INTEGER_ONLY_LIBRARY flag set lately? I'm getting link errors on IA32 for the SSE optimizations lpc_restore_signal_16_intrin_sse2 and lpc_restore_signal_wide_intrin_sse41. Looks like a define check is missing since the implementation of these functions is only included when not building for integer. I had to exclude them at libFLAC/stream_decoder.c:408

Hi, I was wondering how much worse FLAC performance would be if it was compiled integer-only, but while trying to do so (by adding #define FLAC__INTEGER_ONLY_LIBRARY 1 to config.h, just on x86_64-linux) I got this error > ./include/private/bitmath.h:134:5: error: operator '&&' has no left > operand bitmath.h:134 is the following line > #if &&

Hello All, I would be very interested to have your ideas to port the vorbis lib ( part of lib at least) on a DSP TMS320C5409 (running @ 90Mhz). I have reviewed messages and URLs related to: - 'ivdev' Integerized Vorbis Project - Ogg-on-a-Chip Project This is very interesting. In my case I think the best approach would be , in order to shorten porting work & time, to recompile the

Ok, the patch from 2003 about improving seeking still didn't make it to CVS, so here is another try. I made some benchmarking with the test_seeking utility from flac sources to show how bad the current seeking is, especially without seektable. Track used for the experiment had about 50 minutes. In the following table is average number of seeks and number of decoded frames required for one

Hello We have a problem with Samba on AIX and clients running on Windows 2000. We have implemented printer support as described in the document 'Printing Support in Samba 2.2.x'. Environment: AIX 4.3.3 & AIX 4.2.1 with Samba 2.2.4, 2.2.5, 2.2.6 pre 2, Windows 2000 SP 3. Problem: Printer properties is not available to end users (eg. available RAM etc.). When configuring the printer

Actually, we have a integerized version of the vorbis libraries that are available, royalty free, with a simple attribution requirement. These libraries are 100% C code and run faster than real time on a cirrus 7312-74mhz processor (arm core). My guess is they should run at about 20-30% cpu utilization on a strongarm/200. Monty has this same code, but his version doesn't play b4 content real

Hi, I wonder if there is specific requirement or restriction for the decoder in order to be consider "Vorbis" compliant (or let's say, to be a "correct" vorbis decoder). I am experimenting with integerized libvorbis and the decoder delivers the audio data as following, (and compare with the floating point version below). $ tail audioout-int.txt 0290670 025e 085c 02cf 0895

Hello, I have used "MDCT_INTEGERIZED" version of mdct and the resulting bitstream is absolutely silent. Do I have to make some other changes to the source code to get it working? I mean some int->float or float->int conversion before/after call a mdct function. Thanks Rado --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage:

When I was trying to find yesterday's xmms-plugin bug, i have noticed that seeking in stream without seek-table isn't very good. With attached patch it is much better. -- Miroslav Lichvar -------------- next part -------------- --- src/libFLAC/seekable_stream_decoder.c.orig 2003-02-26 19:41:51.000000000 +0100 +++ src/libFLAC/seekable_stream_decoder.c 2003-07-09 23:49:35.000000000 +0200

Ok, here is a patch waiting for new CVS :). It works fine for me, but please check it before commiting... -- Miroslav Lichvar -------------- next part -------------- --- src/libFLAC/bitbuffer.c.orig 2003-01-30 17:36:01.000000000 +0100 +++ src/libFLAC/bitbuffer.c 2003-01-30 21:53:18.000000000 +0100 @@ -51,6 +51,25 @@ */ static const unsigned FLAC__BITBUFFER_DEFAULT_CAPACITY = ((65536 - 64) *

On Thu, 2007-04-05 at 02:27 -0700, Brian Willoughby wrote: > Josh (Green), > > Seems like the longest example in your list is a 15-second file. I > would like to see the same problem exhibited in a file that is of a > normal length. I have been recording full performances lasting > hours, and flac always compresses the files below 70% of the original > size. >

Hi vorbis-dev! I'm working with Pattara in the oggonachip project, and wondering about the implementation of mdct.c as hardware. According your recomendations about using the floating point version, I would say, we have to implement the integerized version of mdct as a core, and use the fpu only to round the input values. By doing that, you think the result would be still acceptable? How

Hi there. Just a little status update how that integerization is coming along. I am trying to limit myself to 32 bit arithmetics. That means not using any __int64 or long long datatypes at any point. I have now replaced all steps up to including the estimation of the LPC filter coefficients with integer code. That is about a quarter of the total work completed, I would say. One problem that i

The following series adds initial vector support for PowerPC64. On POWER9, flac --best is about 3.3x faster. Amitay Isaacs (2): Add m4 macro to check for C __attribute__ features Check if compiler supports target attribute on ppc64 Anton Blanchard (5): configure.ac: Remove SPE detection code configure.ac: Add VSX enable/disable configure.ac: Fix FLAC__CPU_PPC on little endian, and add

Hello, I've a problem with seeking using libFLAC++ API. The call to seek_absolute always returns with false, whatever I do. I tried many different ways, finally I tried to reduce my added code to near zero, so I used the cpp decode example in ...\flac-1.2.1\examples\cpp\decode\file\.main.cpp and added only one line: bool b=decoder.seek_absolute(1000); right before ok =

Hello, The API documentation [1] `FLAC__stream_decoder_seek_absolute` says: "Flush the input and seek to an absolute sample. Decoding will resume at the given sample. Note that because of this, the next write callback may contain a partial block." I expected that subsequent `process_single` calls would return data starting exactly from the sample I've seeked to. To my surprise

?rta: > ?rta: > > Hello, > > I've a problem with seeking using libFLAC++ API. > The call to seek_absolute always returns with false, whatever I do. > > I tried many different ways, finally I tried to reduce my added code to near zero, so I used the cpp decode example in ...\flac-1.2.1\examples\cpp\decode\file\.main.cpp and added only one line: > > bool