<div dir="ltr"><div class="gmail_quote"><br></div><div class="gmail_quote">Another SDR user here. It was me who reported the bug where total samples wraps around on overflow.</div><div class="gmail_quote"><br></div><div class="gmail_quote">FLAC performs extremely well on SDR samples, both speed and compression ratio. In my testing it outperforms any other free lossless codec by a large margin, being 20% smaller and 10% faster than the next best (which was ffv1). The problem is the metadata, and not just total samples. We also can't put true values in the sample rate field because it doesn't have enough bits (I have files with 35468950MHz nominal sample rate for example), and there is no way to record that samples have been padded eg from 10 bits to 16 bits, which seems to be very common in SDR applications. These are just two examples off the top of my head - there are probably more.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">The problems around total samples and seek table allocation could be 
alleviated by using multiple files as mentioned previously, but that 
introduces a new problem: how do you know if you have the full set of 
files? How do you know which file contains the nth sample? This would 
still require extra metadata somewhere.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">I would like to see this kind of thing put into a secondary metadata 
block aimed specifically at SDR. This could be completely 
ignored by regular audio players - these files are not meant to be 
listened to anyway. I could probably figure out how to 
implement that, I even started looking into it once, but I realised that
 1. nobody would adopt it if it is 
just me behind it and 2. I don't know enough to make it suitable for all
 use cases. So I cannot and should not do this alone, as it would just 
be yet another half-baked adhoc "standard" that causes more problems 
than it solves. For example I had not even considered the idea of using multiple files.<br></div><div class="gmail_quote"><br></div><div>On the topic of seeking, it is also a problem for my specific use case. I am interested in digital signals (teletext) hidden in analog video (CVBS samples), and they just aren't sequential in the same way that audio and video usually are. I need to seek to an arbitrary video line as fast as possible, preferably in constant time. A line is usually 2048 samples but can vary between 1000 and 3000 samples long (always fixed size within a given file, but can vary depending on the hardware used to record). A typical recording will have 32 lines per frame (because the picture has already been discarded), 25 frames per second, and be up to 12 hours long = 35 million lines and 70 billion samples. That would result in a ~700MB seek table. And making the block size = 1 line also has a negative effect on compression ratio. Finally since the files are huge I am storing them on cheap USB HDDs which have terrible seek and read times to begin with. Note though that very high resolution seeking is not really necessary for most SDR uses and is mainly a quirk of the fact that teletext was one of the earliest attempts at digital data transmission and has very small and fixed size data packets that map directly to video lines. As such this would probably be best handled with a custom, app-specific seek table in a separate file, built on-demand and possibly stored on a faster disk.<br></div><div><span class="gmail_signature_prefix"><br></span></div><div><span class="gmail_signature_prefix">-- </span><br></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>