[flac-dev] C API: How to get a seektable for very long files?

[Stefan Oltmanns]

Am 16.10.24 um 02:40 schrieb Alistair Buxton:
> On Wed, 16 Oct 2024 at 00:18, Stefan Oltmanns <stefan-oltmanns at gmx.net>
> wrote:
>
>> Am 15.10.24 um 21:26 schrieb Alistair Buxton:
>>> Another SDR user here. It was me who reported the bug where total samples
>>> wraps around on overflow.
>>
>> That's a bug in the flac application. I think the correct behavior is
>> setting it to 0 if total samples > 2^36
>>
>>
> Yes, it was fixed after I reported it, three years ago. :)

I just checked, I created the file not so long ago, but with flac that
came with Mint 21.x / Ubuntu 22.04: 1.3.3 from 2019...

>
> A common workflow I have is to decimate recordings by taking every nth line
> where n is a prime number close to the number of lines in a frame (so that
> every line is represented). In an uncompressed file this gives a free n
> times speed up because reading the next nth line is one fixed length seek
> and one read and the computation I subsequently do just happens to take
> almost exactly the same time as reading the data from disk. Remember lines
> are about 2k, frames are about 32 lines (64k), and FLAC blocks are up to
> 64k. When using the seek table for a sample that isn't a seek point I
> always on average end up reading 1 block of data (half a block to find the
> block header, then assuming it is the right one, half of that block to find
> the actual sample I wanted). That means for 64k blocks I actually end up
> reading more data by using the seek table than if I just sequentially
> decoded the entire file. Which makes this kind of decimation a lot less
> effective. Unfortunately I suspect this is unavoidable while maintaining a
> decent compression ratio, at least with FLAC, and probably with any
> compression scheme.
>

Ok, that's a very specific need, you want to seek forward a very small
amount (compared to the total length) very often.

The only thing I could think off is a feature similar to "fast forward"
on a tape deck:

FLAC__stream_decoder_skip_forward (FLAC__StreamDecoder *decoder,
FLAC__uint64 samples):

The decoder will just parse enough of the bitstream to be able to get
the given number of samples forward without resync and will not actually
decode anything. Not sure how difficult it would be to implement and how
much processing power is saved after all.

For this short seeks reading from the disk is not the biggest issue, as
the OS usually reads more data anyway and stores it in a buffer to speed
up the next disk access.

Best regards
Stefan