[flac-dev] Feedback on implementation of decoding of chained streams

[Timothy B. Terriberry]

Martijn van Beurden wrote:
>> Since chained streams can have different sample rates, how would one go
>> about seeking to a specific _time_?
> 
> I assume one would first use the sample rate of the first link to
> guess the sample number, seek to that point, correct if it turns out
> one of the links that passed has a different sample rate, seek again
> etc.

The use case I am thinking of here is a standard media player with a 
scrubber that shows the current playback position and can be dragged by 
the user to seek. I don't know how many would use libFLAC for this 
directly (maybe VLC?) instead of some other media framework, but it at 
least seems like a common use case.

>> Am I reading the seeking implementation correctly that the only way to
>> seek to a future link is to scan forward through all of the file data?
> 
> Yes, that is correct.

So, to implement the above scrubber, you would have to read the entire 
file before being able to begin playback, plus maintain a bunch of 
custom code to enumerate and store the list of link durations and sample 
rates to do the conversion between sample number and time. I do not 
think a lot of people would be willing to enable chained stream support 
if that is the cost.