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

[brianw]

Many hardware and software developers allow the user to set a maximum file size. When a live recording reaches this limit, a new file is created to continue the recording without losing a single sample. Note that many software programs allow multiple files to be concatenated without any gap. I have been able to use these techniques reliably for years to make extended recordings that last several hours.

Typical maximum sizes are 4 GB, 2 GB, or even 1 GB. The 4 GB and 2 GB limits come from old file seek API that have those limits. The 1 GB option is probably just to make files more manageable, or to allow a compressed file to be expanded and still fit within 2 GB.

Although this standard practice does not directly solve your problems, I think it would help if you avoid creating large files. You mention that the 36-bit field limits you to 30 minutes, but what size file would that correspond to? Just limit your file to that size, use the full 36-bit field, and then skip to the next file with gapless, sample-accurate recording.

Brian Willoughby


On Oct 13, 2024, at 3:09 PM, Stefan Oltmanns wrote:
> I think there is another major issue for me: In
> METADATA_BLOCK_STREAMINFO the field for the length is only 36 bit,
> that's not even half an hour at 40 MHz sample rate, resulting in that
> the encoder sets it to 0 for longer captures. In the seekpoint the
> sample number is 64 bit, which is more than enough.
> But how does the decoder handle the seektable when the total number of
> samples is unknown? Or does the seektable override the info from
> METADATA_BLOCK_STREAMINFO?
> 
> I used this functions now to add seekpoints, but all remain placeholders
> according to metaflac:
> 
> FLAC__metadata_object_new
> FLAC__metadata_object_seektable_template_append_placeholders
> FLAC__stream_encoder_set_metadata
> (encoder init & loop)
> FLAC__metadata_object_seektable_template_sort
> 
> Best regards
> Stefan