The problem is really as I wrote:
1. Metaflac is no option for me, I use libFLAC.dll
2. There is no way (at least how I read the code) to avoid saving
comment with libFLAC; I would appreciate an extra option to avoid it,
which can default to old behavior if compatibility is important.
3. I have a high speed application, where re-initializing an encoder
is really significant. On corner cases it causes an 25% overhead! Of
course I don't expect it to be that significant in normal cases.

Thanks for all replies, but I don't have the code at home.
I will create a patch with my changes for review.


On Sun, Feb 4, 2018 at 9:57 AM, Brian Willoughby
<> wrote:
> Correction, the flac command-line does create a 40-byte Vorbis comment by 
> default. I just never noticed it before. I’ve been using —no-padding all 
> these years for minimal file sizes without realizing that I could save 
> another 40 bytes.
> Anyway, since metaflac can remove the Vorbis comment using the standard 
> library, then you should be able to create a solution without modifying 
> libFLAC.
> Brian
> On Feb 4, 2018, at 12:43 AM, Brian Willoughby <> wrote:
>> Gabriel,
>> metadata_has_vorbis_comment is a FLAC__bool which defaults to false. There 
>> should be no reason to modify stream_encoder.c, but just modify the caller.
>> The following command:
>> metaflac —remove —block-type=VORBIS_COMMENT —don’t-use-padding
>> … will remove Vorbis comments from existing files, so is must be legal 
>> without modifying the library. metaflac can clearly create a new FLAC file 
>> without the Vorbis comment.
>> I use the flac command-line, and I never get Vorbis comments in the files 
>> that I create. Perhaps you are using another tool which assumes Vorbis 
>> comments are needed.
>> The FLAC algorithm is not dependent upon sample rate. AIFF has an 80-bit 
>> floating point type for sample rate, so it should be able to handle 40 MHz. 
>> I assume that any AIFF can be converted to FLAC losslessly, but I have not 
>> tested whether certain sample rates are rejected. FLAC itself only supports 
>> sample rates up to 655,350 Hz, so you may have a problem there unless you 
>> “lie” about the sample rate when creating the file. Maybe you could just 
>> establish a private convention to divide the sample rate by 100 to make 
>> yours fit. 40 MHz would map to 400 kHz, 10 MHz would map to 100 kHz, and 5 
>> MHz would map to 50 kHz.
>> You’re probably asking for trouble if you try to reuse an encoder. It seems 
>> like there would always be some risk that details from the previous file 
>> would bleed through into the next. Have you benchmarked allocation and 
>> initialization? Is it really that slow? In order to reuse an encoder, you’ll 
>> need to overwrite all state variables, and I don’t see how that could be 
>> much faster than simply allocating them anew. Perhaps you could allocate 
>> groups of encoders at once, if that would speed the process.
>> On Feb 1, 2018, at 4:29 AM, Gabriel Corneanu <> 
>> wrote:
>>> Hello all
>>> I am using libFLAC in a corner application, compressing a lot of small 
>>> signals.
>>> 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?? The 
>>> mac sample rate is limited in flac, but it doesn't really seem to be a 
>>> problem.
>>> 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.
>>> 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".
>>> 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.
>>> Regards,
>>> Gabriel Corneanu
flac-dev mailing list

Reply via email to