Am 16.10.24 um 02:40 schrieb Alistair Buxton:
On Wed, 16 Oct 2024 at 00:18, Stefan Oltmanns <stefan-oltma...@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
_______________________________________________
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
