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. Regards, Gabriel On Sun, Feb 4, 2018 at 9:57 AM, Brian Willoughby <bri...@audiobanshee.com> 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 <bri...@audiobanshee.com> 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 <gabrielcorne...@gmail.com> >> 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 flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
