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

Am 16.10.24 um 15:15 schrieb Martijn van Beurden:
>
> But how should such a number be presented to the libFLAC user? You
> suggested overwriting the streaminfo total_samples number, but
> streaminfo always precedes the seektable, so the streaminfo metadata
> block is already parsed by the application before the seektable is
> even read. Also, I think it is quite hacky to not pass the actual
> streaminfo metadata block to the application but 'patch' it first.
> Furthermore, applications might rely on the total number of samples
> being 36 bits, storing the number of seconds in a 32-bit int after
> dividing it by the samplerate for example. All in all, this seems like
> a bad idea.
Yes, overwriting the streaminfo total_samples number is a bit of a hack,
but it would only affect those files with more than 2^36 samples that
contains the special seek point, so no difference for the average flac user.

Not sure how the applications actually read flac files, if they start
using the total_samples number before the seektable is parsed or if
libflac can indicate that the streaminfo is not yet complete.

The worst thing that could happen:
-An application uses the total_samples number before parsing of
seektable is done -> no difference to now
-An application uses a 32 bit number for seconds: At 40 kHz indicated
sample rate that is still more than 2^47 samples. At 40 MHz real sample
rate this is still more than 40 days.
If that's really a concern libflac could check the number first if the
seconds fit in a 32 bit int and otherwise not set it
>>
>> I'm not saying a new API call is a bug. But as this is such a niche
>> case, that I don't think many programs will incorporate that
feature,
>> because the need is not seen (and being able to open the file in an
>> audio player for quick check and random points is a great feature). If
>> libflac just returns the correct total sample value you can just
>> recompile libflac on your system and it will work.
>> Additionally I think there is one issue: there are only 31 bits for the
>> frame number, with a frame size of 4096 this is "just" 2^43
samples,
>> which maybe not enough in every case (SDR with higher sample rate?),
and
>> smaller frame sizes are possible. And for variable block length
it's
>> again 2^36.
>> Of course in combination with the last seekpoint this could work, but
>> without a seektable it's again problematic.
>>
>
> I still don't understand **why** you want FLAC files containing radio
> frequency signals to be parsable by audio applications. I get that it
> is convenient for debugging, but is there any use other than that?
> Would you like to listen to such signals as if they were audio?
>
> I'd prefer a SDR-specific metadata standard. That would mean setting
> the sample rate to 0 (which is defined by the FLAC spec to mean: does
> not contain audio), and set that samplerate in either an application
> metadata block or vorbis comment fields. That way audio players won't
> attempt to playback such non-audio files, which I think is a good
> thing.
The main reason is not listening to those files (but that's not only for
debugging, but very helpful just to quick check if there is a signal or
just silence/noise), but that you can use audio tools for inspecting
(waveform or spectrum/fft), cutting, low/high/band pass etc.

I would suspect most audio tools would refuse to work if sample rate is
set to 0 and that is definetly a bad idea, because even though the
content is not audio, it is a sampled signal with a fixed sample rate
like audio and not other kind of data, so using audio tools makes
perfect sense.

That's why I would want all audio tools to be able to work with long
flac files.

Best regards
Stefan

Op wo 16 okt 2024 om 16:25 schreef Stefan Oltmanns <stefan-oltmanns at
gmx.net>:
>
> Yes, overwriting the streaminfo total_samples number is a bit of a hack,
> but it would only affect those files with more than 2^36 samples that
> contains the special seek point, so no difference for the average flac
user.
>
> Not sure how the applications actually read flac files, if they start
> using the total_samples number before the seektable is parsed or if
> libflac can indicate that the streaminfo is not yet complete.
>
libFLAC reads a file from start to back, and returns data to the
client as soon as it is done parsing. So, it first encounters a
streaminfo metadata block, sends that to the application, then starts
on the seektable etc. In fact, for a lot of applications, the seek
table is simply ignored because libFLAC uses it internally.

I don't know how libFLAC should indicate that streaminfo isn't
complete yet, but I'd say getting applications to understand that is
more work than them just supporting a new function that returns the
total number of samples.
>
> The main reason is not listening to those files (but that's not only
for
> debugging, but very helpful just to quick check if there is a signal or
> just silence/noise), but that you can use audio tools for inspecting
> (waveform or spectrum/fft), cutting, low/high/band pass etc.
>
Fair enough.