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
_______________________________________________
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
