Gabriel Corneanu wrote:
> > Probably easiest as as PR against:
> >
> >https://github.com/xiph/flac/
>
> I create a PR.
> The existing API should not have been changed, all tests are passed.
Thanks. Will look at this on the weekend.
> > You can probably avoid it by using the library directly
Hi,
On Sat, Feb 3, 2018 at 10:10 AM, Erik de Castro Lopo
wrote:
> Gabriel Corneanu wrote:
>
>> Is this interesting for the project?
>
> 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.
>
>> If yes, how s
Hi,
On Sun, Feb 4, 2018 at 11:50 PM, Brian Willoughby
wrote:
> I wasn’t suggesting that you run metaflac, but that you examine its source to
> see how it creates new FLAC files without the Vorbis comment. As far as I
> know, metaflac uses the standard libFLAC and creates files without the Vorbi
I wasn’t suggesting that you run metaflac, but that you examine its source to
see how it creates new FLAC files without the Vorbis comment. As far as I know,
metaflac uses the standard libFLAC and creates files without the Vorbis
overhead.
My quick review of the source seemed to indicate that c
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 h
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
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 file
Gabriel Corneanu wrote:
> Is this interesting for the project?
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.
> If yes, how should I share it? As a patch against current git?
Probably easiest as as PR
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
Hello again,
After some time, I succeeded in splitting "flush" and "restart"
functions. A quick measurement gives me ~25% speed improvement, which
is quite a lot. Of course this optimization is specific for this use
case (many short signals).
Is this interesting for the project? I would gladly co
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
11 matches
Mail list logo
