search for: seeking

Josh Coalson wrote: > --- Erik de Castro Lopo <erikd-flac@mega-nerd.com> wrote: > > > Hi all, > > > > Is seeking working for OggFlac files? I keep on getting a > > FLAC__STREAM_DECODER_SEEK_ERROR. > > yes, it should work fine. in flac/src/test_seeking/main.c there > is an example usage of FLAC__stream_decoder_seek_absolute(). you > could try compiling it and running test_seeking on it. i...

Hi all, Is seeking working for OggFlac files? I keep on getting a FLAC__STREAM_DECODER_SEEK_ERROR. Erik -- ----------------------------------------------------------------- Erik de Castro Lopo ----------------------------------------------------------------- "Why do they protest against France for making it il...

--- Erik de Castro Lopo <erikd-flac@mega-nerd.com> wrote: > Josh Coalson wrote: > > > --- Erik de Castro Lopo <erikd-flac@mega-nerd.com> wrote: > > > > > Hi all, > > > > > > Is seeking working for OggFlac files? I keep on getting a > > > FLAC__STREAM_DECODER_SEEK_ERROR. > > > > yes, it should work fine. in flac/src/test_seeking/main.c there > > is an example usage of FLAC__stream_decoder_seek_absolute(). you > > could try compiling it and runni...

Dear all I'm aware that there have been several discussions about the seeking issue and I'm sorry to bring this up again. To solve the problem with Inter-Frame garbage, a seek to the previous keyframe has to be made. The keyframe number should be extracted from the granulepos of the frame where we want to seek to. I hope I understood the theory - unfortunately a few...

Hi, I have a question about seeking. In fact, it's more or less a kind of rambling and thinking aloud, circling around a question. I've been wondering how to deal with seeking in a stream, and what to do when seeking in the middle of a set of active events (eg, when several bits of text are supposed to be shown, but you seek...

...1.0 on Windows). >>> >>> [Is a call to fflush() needed inside file_seek() in main/connections.c?] >> >> >> >> >> If you have an idea where to fflush() precisely and your patch works, >> please tell it! I'll happily run some test cases where seeking matters. >> > > I couldn't see why the current code was returning a bad value under some > conditions. (That's why didn't offer anything more than a suggestion). > My suggestion to use an fflush() was a guess (hence the question mark, > but evidence for the gu...

This message relates to handling files > 2Gb under Windows. (I use 2Gb as shorthand for 2^31-1 -- the largest integer representable in a signed 32 bit integer.) First issue: truncate() is not able to successfully truncate files at a position > 2Gb. This appears to be due to the use of the Windows function chsize() in file_truncate() in main/connections.c (chsize() takes a long int

I have installed both 32-bit and 64-bit versions of R2.12.0 (2010-06-15 r52300) on my Ubuntu 10.04 64-bit system. I observe the following behavior when running the examples from base::connections. There appears to be a problem with seek() on a .gz file when using a 32-bit installation of R2.12.0, but the problem doesn't appear in the 64-bit installation. I realize that seek() has been

Hi, I'm running into more issues when reading data from a gzfile connection. If I read the data sequentially with successive calls to readBin(), the data I get looks ok. But if I call seek() between the successive calls to readBin(), I get corrupted data. Here is a (hopefully) reproducible example. See my sessionInfo() at the end (I'm not on Windows, where, according to the man page,

I need to be exposed to a way of seeking theora streams. I have repeatedly found the same question asked on a different forums but could not find an answer. I'm working on a game and started integrating video with theora, the sound works just fine with ogg/vorbis(i find it easy to seek using ov_raw_seek for audio files). Could someone...

Dear all, In R-devel (2011-09-23 r57050), I'm running into a serious problem with seek()ing on connections opened with gzfile(). A warning is generated and the file position does not seek to the requested location. It doesn't seem to occur all the time - I tried to create a small example file to illustrate it, but the problem didn't occur. However, it can be seen with a file I use for

Hey guys, I just joined the list. I've been programming an external for PureData <http://pure-data.sourceforge.net/> & <http://pure-data.org>, as well as for Max/MSP....that reads multiple sound formats. But, I've been having massive problems with getting reliable seeking with FLAC. sometimes when I call FLAC__seekable_stream_decoder_seek_absolute, I get a false returned for FLAC__seekable_stream_decoder_process_single ..and the error is of type FLAC__SEEKABLE_STREAM_DECODER_STREAM_DECODER_ERROR is there any way to recover from this? I try to do a FLAC__seek...

...connection does > not always work correctly after a write (R 2.1.0 on Windows). > > [Is a call to fflush() needed inside file_seek() in main/connections.c?] If you have an idea where to fflush() precisely and your patch works, please tell it! I'll happily run some test cases where seeking matters. Note that ?seek currently tells us "The value returned by seek(where=NA) appears to be unreliable on Windows systems, at least for text files." It would be nice if this comment could be removed, of course .... Uwe Ligges > Example (see the lines with the "***WRONG**...

...xample, when I seek to 19*44100 samples or to 81*44100 samples, the > seek callback runs off in an endless loop. > there aren't any while loops in my code, so I don't think I am causing it. > At least I cannot track it down to something I would be doing. > are there issues with seeking in FLAC? > like I said, I only get this result on specific seek points. otherwise, > everything is working honkydory. > muchas gracias -augusto. > > On Tue, 24 Feb 2004, august wrote: >>Hey guys, >>I just joined the list. I've been programming an external for PureDa...

I've checked in code that supports a new metadata block called SEEKTABLE. Basically, it is an optional, arbitrarily-long list of seek points, by sample number and stream offset. I also added command-line options to flac so you can specify seek points by specific sample number and/or a specific number of evenly-spaced seek points. The table cost about 18 bytes per seek point. This seems to

??????? I've rewritten my theora player using liboggz. I've stumbled upon a few issues though. First of all liboggz exposes oggz_read and oggz_run, but how can i read only sound data, or only video data using liboggz, say something like this: oggz_read_sound(1024), oggz_read_video(1024). ? ? ? ?? Second of all i tried using liboggz's seek function. Immediately after the seek i get some

...An index is only marginally useful in Ogg for the complexity added; it adds no new functionality and seldom improves performance noticeably. Empirical testing shows that indexless interpolation search does not require many more seeks in practice than using an index would." I am keen to see seeking code which is almost as fast as seeking with an index. Is the code used in this empirical testing online somewhere or otherwise available? Thanks, Chris P.

...ooks like those streams (created a long time ago with an old version of FLAC) have a seek table where all the entries have a stream offset of 0. The result is that in the function seek_to_absolute_sample_, on line 3076 (file stream_decoder.c), the following test returns: /* make sure we are not seeking in corrupted stream */ if (this_frame_sample < lower_bound_sample) { decoder->protected_->state = FLAC__STREAM_DECODER_SEEK_ERROR; return false; } because 'this_frame_sample' is equal to 0 (because the seek table caused the seek search to start at the beginning of the s...

...work correctly after a write (R 2.1.0 on Windows). >> >>[Is a call to fflush() needed inside file_seek() in main/connections.c?] > > > > If you have an idea where to fflush() precisely and your patch works, > please tell it! I'll happily run some test cases where seeking matters. > I couldn't see why the current code was returning a bad value under some conditions. (That's why didn't offer anything more than a suggestion). My suggestion to use an fflush() was a guess (hence the question mark, but evidence for the guess being correct was that...

...:-) I am encoding files with "-8 -r 99" (e.g. flac -8 -r 99 1.wav 1.3.flac) using version 0.6 under Linux. On one of my flac files, however, I was not able to seek exactly 2 minutes into the file due to the following error: $ flac --skip 5280000 -d 1.3.flac 1.1.wav ... 1.3.flac: ERROR seeking while skipping bytes With a little experimentation, I was able to determine that I cannot seek to samples 5278573 - 5280363. Seeking to samples before and after that yield proper results and if I seek to before that range, the output contains correct decompressed audio for the range to which I c...