Hi! I am working on an application that reads audio data from files, and runs
it through some user defined filters. The filters basically all derive from
some base filter and have methods start(), update() and finish(). The start
routine performs any initialization required by the filter, and fi
Well, unless somebody has a brilliant idea, I am giving up on this. I don't see
how I can do what I wanted to. The slightly hacky way I thought would work, was
by guaranteeing the read_callback could read at least enough data to make
process_single() return (ie the buffer should contain at least
During my current dealings with the FLAC library I think I discovered a memory
leak. After an encoder stream has finish()'ed, I believe you are supposed to
use it again by calling init(). However, when verification is enabled, the
init() routine will create a new stream decoder (to verify the da
After some more testing, and reading the source, the finish() is indeed called
on the verification decoder when its container encoder is finished. This
correctly leaves the decoder in the FLAC__STREAM_DECODER_UNINITIALIZED state,
ready to be reinitialized (or return an error).
So, all that need
Well, I have been away a couple of days, so I don't know if I'm in time, but I
reported a memory leak and submitted a patch a couple of months ago. It would
be nice if it can make it in.
I first reported the leak here:
http://lists.xiph.org/pipermail/flac-dev/2011-August/003002.html
And the pa
es to fix them (after reviewing the patch of course).
--- On Sat, 11/19/11, Brian Willoughby wrote:
> From: Brian Willoughby
> Subject: Re: [Flac-dev] Git branch with compiling fixes for win32
> To: "Bastiaan Timmer"
> Cc: flac-dev@xiph.org
> Date: Saturday, November 19, 2
Hi! I've been using a little C++ program I've written to encode flac files. The
program does this in the usual way (I think), by inheriting a class from
FLAC::Encoder::File, and passing it chunks of raw samples through
process_interleaved()... Anyway, the program works beautifully, and I've now
Well, I have to apologize, we can disregard the most important part of my
previous mail. The code mentioned in that one does in fact work fine when
compiled against current git. I had only compiled against current (but old)
stable release when I wrote that, which suffered from a bug (commit
164
The attached patch adds the missing FLAC__metadata_object_seektable_*()
functions from FLAC's metadata object methods (FLAC/metadata.h) to FLAC++'s
SeekTable class. Of the 11 functions in the C API, only 4 are currently in the
C++ API, this patch adds the missing 7.
If this patch is ok, VorbisC
Attached is a patch that adds 5 missing FLAC__metadata_object_vorbiscomment_*
functions to the VorbisComment class. In my previous message I stated 8
functions were missing, but on closer inspection, 3 of those belong in the
VorbisComment::Entry class, and 2 of them already have equivalent funct
> While you are at it, can you check/fix the following warning
> ?
>
> metadata.cpp:812:98: warning: narrowing conversion of
> 'strlen(((const
> char*)string))' from 'size_t {aka long unsigned int}' to
> 'FLAC__uint32
> {aka unsigned int}' inside { } is ill-formed in C++11
> [-Wnarrowing]
>
>
--- On Tue, 5/8/12, Erik de Castro Lopo wrote:
> Honestly, I really doubt this is a bug in valgrind :-). How
> were you testing
> this?
Well, I've read that there have been bugs in valgrind, were SSE optimized
versions of strlen() do guaranteed safe overreads of memory, but valgrind
wasn't awa
--- On Tue, 5/8/12, Bastiaan Timmer wrote:
> From: Bastiaan Timmer
> Subject: Re: [flac-dev] [PATCH] Add missing functions to VorbisComment class
> + a few other things
> To: flac-dev@xiph.org
> Date: Tuesday, May 8, 2012, 3:13 PM
> --- On Tue, 5/8/12, Erik de Cast
A missing '/endcode' tag in include/FLAC/metadata.h causes the FLAC__bool
FLAC__metadata_object_cuesheet_set_track() method to not appear in the docs,
and the next method (insert_track) to get the documentation of set_track. It
also creates a broken link to set_track in the FLAC++ docs.
Attache
Hi! I think this patch adds the last of the libFLAC metadata functions to the
correct classes in libFLAC++. This is 4 CueSheet member function and 1 Picture
function. If I haven't looked properly and more functions are still missing,
let me know.
Next I would like to maybe add a few convenience
Hi! Attached is a tiny patch adding a convenience function to create a
Metadata::Padding object with a certain size in one statement. In a
previous message I mentioned writing some more convenience functions, but on
closer inspection they would either be inefficient or very difficult
to imple
d_comment(). It all
just seems too much trouble for what it's worth.
Bas
- Original Message -
From: Martin Leese
To: flac-dev@xiph.org
Cc:
Sent: Tuesday, September 11, 2012 9:25 PM
Subject: Re: [flac-dev] Patch for Metadata::Padding
Bastiaan Timmer wrote:
...
> In a
Well, I sent this earlier this week, but I guess it's stuck in the spam filter,
so I'll send it again split up in several
parts. First the full source, if this one arrives I'll reply with the patch.
Ok, so I ended up creating 2 versions of this. The first one is what I
mentioned earlier, pret
The patch...
- Original Message -
From: Bastiaan Timmer
To: "flac-dev@xiph.org"
Cc:
Sent: Saturday, September 15, 2012 9:27 AM
Subject: [flac-dev] New C++ file encode example
Well, I sent this earlier this week, but I guess it's stuck in the spam filter,
so I'll
Full source of the second version.
The difference in the second version is that the metadata objects are no longer
heap-allocated. This is more in line with the concept of RAII,
and removes the need to keep setting and checking the 'ok' bool, which
in the first version needs to be done from th
And a patch for the 2nd version.
encode_example_ver2.patch
Description: Binary data
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
Ok, so I ended up creating 2 versions of this, I hope the attachments aren't
too big.
The first one is what I mentioned earlier, pretty much a line-for-line
translation of the original example. The c++-style casts made the (already
ugly) lines with casts even uglier by the way...
The differenc
Hi, I was just messing around with a metadata modifier in flac (using the C++
api) and found something strange.
When iterating over a chain and calling FLAC::Metadata::Iterator::get_block(),
it seems a newly constructed ProtoType* is returned (the source says "return
local::construct(::FLAC__me
Some more possibly interesting information:
1. With me, both flac 1.2.1 and 1.3.0 fail to produce a flac file at all. They
both end with:
snippet6.wav: 35% complete, ratio=0,781
snippet6.wav: ERROR during encoding
state = FLAC__STREAM_ENCODER_FRAMING_ERROR
This is after my entire
> pcm[i] = (FLAC__int32)buffer[3*i+2];
> pcm[i] <<= 8;
> pcm[i] |= (FLAC__int32)buffer[3*i+1];
> pcm[i] <<= 8;
> pcm[i] |= (FLAC__int32)buffer[3*i];
(I might be mistaken but) I think you should realize the 24 bit sample has a
sign bit in the last of the bytes. Casting the FLAC__byte from the bu
25 matches
Mail list logo
