Write callback not called after seeking to frame within last block

[sbooth]

Thank you for FLAC!

I've noticed that after a seek to a sample number that is within the last block the stream decoder no longer calls the write callback. This seems contrary to the documentation for FLAC__stream_decoder_seek_absolute which states

/** 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.

As an example, I've been using the following file for testing:

METADATA block #0
  type: 0 (STREAMINFO)
  is last: false
  length: 34
  minimum blocksize: 4096 samples
  maximum blocksize: 4096 samples
  minimum framesize: 23 bytes
  maximum framesize: 5975 bytes
  sample_rate: 44100 Hz
  channels: 5
  bits-per-sample: 16
  total samples: 258048
  MD5 signature: e0aec84b52ef7ad5f9619e24fb357684

If I call FLAC__stream_decoder_seek_absolute with a sample >= (258048-4096) the function returns 1, however further calls to FLAC__stream_decoder_process_single no longer call the write callback/produce audio. I expected that the remaining samples in the file would be sent to the write callback.

I believe this may be because the stream decoder's state is FLAC__STREAM_DECODER_END_OF_STREAM following the seek but I am not familiar enough with libFLAC to understand the root cause and if this is the expected behavior.

[sbooth]

@ktmf01 Do you have any thoughts on whether this is the expected behavior?

[Alb3e3]

I dug into this and I do not think any audio is being dropped — the samples you are expecting have already been delivered by the time FLAC__stream_decoder_seek_absolute() returns.

write_audio_frame_to_client_() in src/libFLAC/stream_decoder.c handles the frame that contains the target sample while the decoder is still in seek mode: it trims the samples before the target, calls the write callback with that partial block, and only then clears is_seeking. Decoding resumes with the block after that one.

For a seek into any block but the last, the next process_single() delivers the following frame, so this is invisible. For a seek into the last block there is no following frame, so process_single() returns true without a callback and the decoder sits in FLAC__STREAM_DECODER_END_OF_STREAM.

Measured on a 258048-sample, 4096-blocksize file, counting write callbacks separately during the seek and during the following process_single():

-- seeks into earlier blocks --
seek to 245760: during_seek=1 during_process=1 first_sample=245760 blocksize=4096 state=SEARCH_FOR_FRAME_SYNC
seek to 253951: during_seek=1 during_process=1 first_sample=253951 blocksize=4096 state=SEARCH_FOR_FRAME_SYNC
-- seeks into the last block --
seek to 253952: during_seek=1 during_process=0 first_sample=253952 blocksize=4096 state=END_OF_STREAM
seek to 257948: during_seek=1 during_process=0 first_sample=257948 blocksize=100  state=END_OF_STREAM
seek to 258047: during_seek=1 during_process=0 first_sample=258047 blocksize=1    state=END_OF_STREAM

blocksize in the last-block cases is exactly the number of samples from the target to the end of the stream, so the full remainder is handed over — just from inside the seek call rather than from the next process_single().

@sbooth if your decoding loop ignores write callbacks while a seek is in flight, that is where the audio goes.

The documentation is what points the other way ("the next write callback may contain a partial block" reads as a later process_single()), so I opened #924 to spell out when that callback happens. Happy to look at changing the behaviour instead if the maintainers would rather the partial block be held back until the next process_single(), though that would change what every existing client sees during a seek.

[sbooth]

Thank you for taking the time to look into this @Alb3e3

I didn't realize that process_single() could be invoked by the seek callback, and the write callback along with it. I was flushing buffers after the seek was complete expecting that my next call to process_single() would start with the audio sample specified by the seek, so that flush was discarding valid samples.

I think the documentation update in #924 is helpful.