On Sat, Feb 28, 2004 at 04:32:14PM +0100, august wrote:> > > Did you try OggFLAC and MkaFLAC as alternative containers ? > > no, I didnt? would that make a difference though? > > 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 ..... > > it's certainly an option, but I would love to know why normal FLAC seeking > doesn't work. > > any hints?Native FLAC is not perfect, but it is good enough for relatively fast and reliable seeking. However, implementation in 1.1.0 is buggy. Try CVS version, maybe it will be better, i have seen there some changes. If that doesn't help, search for my patch in archives, it was mainly about speed of seeking (and making SEEKTABLE block redundant), but i remember it helped also in reliability. If that doesn't help at all, post here your code which is causing problems, and i will try to make a patch. -- Miroslav Lichvar
Hi august wrote:>>Did you try OggFLAC and MkaFLAC as alternative containers ? >> >> >no, I didnt? would that make a difference though? >Yes, i think so. Josh may tell different if i am talking rubbish, but i dont expect that FLAC's native framing has an index or the like, like matroska has, to support fast seeking, so seeking will probably mainly work on a per-sample base.>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 ..... >> >> >it's certainly an option, but I would love to know why normal FLAC seeking >doesn't work. any hints? -august. >It probably does work, but as i was assuming already, maybe to the best of its possibilities. Many native framings are not really perfectly suited for seeking, MPC and even MP3 are perfect examples for that. Vorbis is different here, its put into Ogg natively, and Ogg provides some means for better seeking like the 'granulepos', which is used to mark the Ogg pages containing the Vorbis audio streams, and can be used for enhanced seeking. matroska container will provide an index on top of that for the best possible seeking. mkvmerge/mmg ( http://mkvtoolnix.matroska.org ) can read both OggFLAC and native FLAC and will ouput a MKA file ( matroska audio ), if you want to test this. To play it on Windows, use either foobar2000 ( http://www.foobar2000.org ) or any DirectShow based player ( like WMP 6.4 ) in combination with the matroska full pack from http://packs.matroska.org . On Linux, mplayer and VLC will work for FLAC in MKA, same for MacOSX. For OggFLAC, the FLAC frontend can output it directly. Playback on Windows should work with the winamp plugin, but AFAIK there is no working DirectShow playback filter for that. Hope this was helpful Christian matroska project admin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20040229/6b095cdb/attachment.htm
> Did you try OggFLAC and MkaFLAC as alternative containers ?no, I didnt? would that make a difference though? 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 .....it's certainly an option, but I would love to know why normal FLAC seeking doesn't work. any hints? -august.
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 file. > for example, 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 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__seekable_stream_decoder_flush or >>FLAC__seekable_stream_decoder_reset on the decoder and it can sometimes >>continue, but after a while it will just run off in a seek loop, where the >>decoder state is always FLAC__SEEKABLE_STREAM_DECODER_SEEKING. >>as far as I can tell it happens at random points. I can't tell for the >>life of me what is causing it. It works and sounds fine in >>general....just that seeking is unreliable. >>any help would be appreciated. I can send the code along to look at. >>best -august.