search for: seeks

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

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 illegal to wear hijabs, but not against Saudi Arabia for making it illegal not to

--- 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

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 questions have

...ntinuous codecs like CMML or Kate, you won't, you'll just seek on the video (or audio) stream, or you'd spend your time looking for a packet blindly, since the vast majority of packets will be video or audio, and a binary search would be rather inefficient. So, you still have to do two seeks: one to find a CMML packet at roughly the right time, and then seek to the previous clip. You can only do it then, since you just learnt the granulepos of the "current" packet, and thus the granulepos of the previous one. The only other alternative (short of having a convenient index of a...

Tony Plate wrote: > ligges@statistik.uni-dortmund.de wrote: > >> tplate@blackmesacapital.com wrote: >> >> >>> I've noticed that seek(con, 0, "end", rw="r") on a file 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

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 please point me to some example/code of how can i seek with

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

tplate@blackmesacapital.com wrote: > I've noticed that seek(con, 0, "end", rw="r") on a file 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

Did you try OggFLAC and MkaFLAC as alternative containers ? For OggFLAC you need libogg, the Xiph documentation should be describing how to seek in the file. But i dont know if using another container than native FLAC framing is an option for you ..... Christian matroska project admin august wrote: > sorry to bother again, > but I can narrow down my problem to certain parst of my flac

...y-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 radically speed up seeks. I should point out a SEEKTABLE is optional; FLAC doesn't need it to seek but they can help. And 1% resolution within a stream only costs 1808 bytes. Josh __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail....

??????? 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

http://www.xiph.org/ogg/doc/oggstream.html says: "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.

I've upgraded to FLAC 1.1.3, and now I have some streams where seek does not work anymore, but they used to work before. After a bit of debugging, it looks 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

ligges@statistik.uni-dortmund.de wrote: > tplate@blackmesacapital.com wrote: > > >>I've noticed that seek(con, 0, "end", rw="r") on a file 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

<PRAISE> First, thanks to everyone for their contributions to flac. It is obviously a significant piece of work with very good performance. For me, the open-source and anti-copy-protection principals of the project make it the best choice among lossless compressors even if there are closed-source projects with marginally better compression. I firmly believe that the open-source process