Gabriel Corneanu wrote:
> I am using libFLAC in a corner application, compressing *a lot* of small
> signals.
You are of course aware that this is *not* what FLAC was designed for,
> First is a general question: in our application we have signals in range
> 5-10 MHz, potentially 40MHz! Is there any potential problem with that??
No idea whatsoever. It really depends on the signal. FLAC is *designed*
and optimised for compressing audio signals, specifically music. For
cases where the FLAC compressed signal is does not actually compress
well (on example is white noise) the audio is included uncompressed.
> The
> mac sample rate is limited in flac, but it doesn't really seem to be a
> problem.
FLAC is the Free Lossless **AUDIO** codec.
> The output is stored as blob in a sqlite database, it *never *needs to be a
> valid audio file outside our application.
> In my tests, the signals are compressed very well, much better than general
> compression libraries like zlib, zstd, etc.
So regardless of the higher sample rate your signals seem to be enough
like audio for FLAC to compress them well.
> Now other small issues; I also made some tickets about them, but I thought
> asking here might be better.
>
> 1. I would like to avoid saving vorbis comment, by default ~40 bytes. Right
> now the only option is to modify stream_encoder.c, see
> "metadata_has_vorbis_comment".
Are you using the FLAC library directly or the flac command line program?
If you are using the flac command line program, please feel free to hack
that to your hearts content (as long as you abide by the very libreral
license).
> 2. Speed is very important, therefore I would like to reuse an encoder
> without re-initializing everything.
> Ideally I would like 2 (exported) functions: "flush" and "restart".
> "Flush" is self-explanatory, should properly end the encoding. I could
> split myself "flush" from "finish", it looks relatively simple.
> "Restart" should keep all current settings, generate a new stream header
> and clear everything for encoding a new signal.
> It' clear that current settings, re-creating windows, cpu-dependent
> functions, etc could be kept around.
> I was not quickly able to extract all the necessary initialization from
> "init_stream_internal_" into a new "FLAC__stream_encoder_restart" function.
I would theoretically accept a patch that allows direct access to the
functionality you seek, as long as it doesn't change the existing API.
Erik
--
--
Erik de Castro Lopo
http://www.mega-nerd.com/
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
