flac dev - Sep 2004 - seek problem

Hi Flac developers!

I'm using the seekable_stream_decoder API of libFLAC 1.03
and I'm stuck with a mysterious problem:
my FLAC plugin works nicely as long as the seek_absolute()
function is never used, but as soon as I seek around in a
sample (ie. call seek_absolute() with an offset != 0), I cannot
detect the end of a file anymore. decoder_get_state() never
returns FLAC__SEEKABLE_STREAM_DECODER_END_OF_STREAM in this
case.
First I thought that this might be a problem of my eofCallback,
but the last file offset where this callback is called is
0x013788f7, but the flac file is 0x01382598 bytes long (ie.
there's no reason for my callback to return true). When I don't
seek, the last offset where my eof routine is called is 0x0137b936
and decoder_get_state() properly returns END_OF_STREAM. Any ideas
whats wrong?
BTW - why does stream_decoder_finish() call the function
seekable_stream_decoder_set_defaults_() which clears all
callback pointers? In flac 1.02, I had to set the callback
pointers only once, but in 1.03 I have to set them after every
decoder_init()/decoder_finish() pair. Is this intentional or
a bug in 1.03?
BTW2 - I still think that it would be better if 
seekable_stream_decoder_seek_absolute() wouldn't call
the write callback.
And finally, a function like
seekable_stream_decoder_process_frames(decoder, numframes)
would be useful, IMHO.

   - Peter.

--- Peter Kunath <kunath@justmail.de> wrote:
> 
> Hi Flac developers!
> 
> I'm using the seekable_stream_decoder API of libFLAC 1.03
> and I'm stuck with a mysterious problem:
> my FLAC plugin works nicely as long as the seek_absolute()
> function is never used, but as soon as I seek around in a
> sample (ie. call seek_absolute() with an offset != 0), I cannot
> detect the end of a file anymore. decoder_get_state() never
> returns FLAC__SEEKABLE_STREAM_DECODER_END_OF_STREAM in this
> case.
> First I thought that this might be a problem of my eofCallback,
> but the last file offset where this callback is called is
> 0x013788f7, but the flac file is 0x01382598 bytes long (ie.
> there's no reason for my callback to return true). When I don't
> seek, the last offset where my eof routine is called is 0x0137b936
> and decoder_get_state() properly returns END_OF_STREAM. Any ideas
> whats wrong?
hmm, I glanced over the code and I don't see right away
what could be wrong.
> BTW - why does stream_decoder_finish() call the function
> seekable_stream_decoder_set_defaults_() which clears all
> callback pointers? In flac 1.02, I had to set the callback
> pointers only once, but in 1.03 I have to set them after every
> decoder_init()/decoder_finish() pair. Is this intentional or
> a bug in 1.03?
I made the new/init/flush/reset/finish/delete usage more
consistent in 1.0.3.  in each layer, ..._finish() now
returns the instance to the same state that ..._new()
does; i.e. it gives you a fresh instance without having
to ..._delete() and then ..._new() again.  if you want
to keep the settings, use seekable_stream_decoder_reset().

I am redoing the API docs with Doxygen (see CVS if curious)
and the new docs will spell this out better.
> BTW2 - I still think that it would be better if 
> seekable_stream_decoder_seek_absolute() wouldn't call
> the write callback.
this is probably a good idea... added to my list.
> And finally, a function like
> seekable_stream_decoder_process_frames(decoder, numframes)
> would be useful, IMHO.
this wouldn't be implemented any differently than a loop
around seekable_stream_decoder_process_one_frame().

Josh


__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com