<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 16 Oct 2024 at 00:18, Stefan Oltmanns <<a href="mailto:stefan-oltmanns@gmx.net">stefan-oltmanns@gmx.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Am 15.10.24 um 21:26 schrieb Alistair Buxton:<br>
> Another SDR user here. It was me who reported the bug where total samples<br>
> wraps around on overflow.<br>
<br>
That's a bug in the flac application. I think the correct behavior is<br>
setting it to 0 if total samples > 2^36<br>
<br></blockquote><div> </div><div>Yes, it was fixed after I reported it, three years ago. :)<br></div><div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
A new metadata block could solve the issue. But for bit depth it is not<br>
needed, libflac allows 4 to 32 bit per sample, with all values in between.<br>
Total samples and sample rate are the only fields I can think of.<br></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<br>
If you want to seek to sample 1200, it looks for the seekpoints before<br>
and after that value, let's say sample 1000 at offset 50000 and sample<br>
2000 at offset 70000. It will then calculate the theoritical position<br>
based on the seektable offsets: 54000 and look for frame header there.<br>
The frame header contains the frame/sample number, so the decoder knows<br>
if it needs to scan forward or backward from there.<br>
<br>
I would assume that the bitrate for SDR applications is quite constant<br>
compared to normal music, as the signal level doesn't change that much<br>
and the modulation doesn't change (of course only if you don't have<br>
dropouts in the singal)</blockquote></div><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div><span class="gmail_signature_prefix">-- </span></div><div dir="ltr" class="gmail_signature">Alistair Buxton<br><a href="mailto:a.j.buxton@gmail.com" target="_blank">a.j.buxton@gmail.com</a></div></div>