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

[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. :)


>
> A new metadata block could solve the issue. But for bit depth it is not
> needed, libflac allows 4 to 32 bit per sample, with all values in between.
> Total samples and sample rate are the only fields I can think of.
>

I didn't know that. I thought it was just standard C types. Another reason
why I shouldn't be the one writing the spec for this.


>
> If you want to seek to sample 1200, it looks for the seekpoints before
> and after that value, let's say sample 1000 at offset 50000 and sample
> 2000 at offset 70000. It will then calculate the theoritical position
> based on the seektable offsets: 54000 and look for frame header there.
> The frame header contains the frame/sample number, so the decoder knows
> if it needs to scan forward or backward from there.
>
> I would assume that the bitrate for SDR applications is quite constant
> compared to normal music, as the signal level doesn't change that much
> and the modulation doesn't change (of course only if you don't have
> dropouts in the singal)


VBI lines can contain anything from noise floor/silence to full range white
noise and the interesting signals are non-return-to-zero, so that
assumption is absolutely not valid for my use case.

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.

-- 
Alistair Buxton
a.j.buxton at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/flac-dev/attachments/20241016/9198d13e/attachment-0001.htm>