similar to: about libFLAC/metadata_object.c

Hi all! I have a problem to get _all_ images from flac file. I have flac file with 3 images inside ( FLAC__METADATA_TYPE_PICTURE ) How to get _all_ images with bool FLAC::Metadata::get_picture() func? This function is wrapper FLAC__bool FLAC__metadata_get_picture(). flac-1.2.1/src/libFLAC/metadata_iterators.c: ... 285 FLAC_API FLAC__bool FLAC__metadata_get_picture(const char *filename,

> Should these be wrapped in HAVE_KATE? Same with the definition of the > functions on oggplay.c? If I'm not building with Kate support it would > prevent dead code from being around. They could, but would change the API, and the implementation just returns a "not implemented" error currently if HAVE_KATE is undefined, (and a couple checks for validity) so it's not much

Hi, the attached patch adds rendering of Kate streams using libtiger. To do so, it adds a new type of RGBA video. One can request the incoming video (in YUV) to be sent in RGBA (ie, asking liboggplay to do the conversion in the first place). The large changes in the GLUT player also include fixes for crash-on-no-sound, mono sound, and locking fixes (I *think* - at least it works fine for me

Hey! So, I'm clearly doing something wrong, because I've written a program to view and modify the comment tags in a FLAC file, which appears to be embedded an Ogg stream. This particular file also has ID3 headers at the beginning, but I was planning on ignoring those and fixing them up using some ID3 code later on ... Now, to read the comments is quite simple:

Hi ogg.k ogg.k, some drive by comments on the patch from a quick look. Should these be wrapped in HAVE_KATE? Same with the definition of the functions on oggplay.c? If I'm not building with Kate support it would prevent dead code from being around. -----------------8<--------------------------- OggPlayErrorCode oggplay_get_kate_category(OggPlay *me, int track, const char** category);

Hi, the patch below fixes function prototypes/defintions with void argument to shut up the heartful warnings by recent gcc :) It doesn't cover all places, e.g. test directories. The patch is to 1.1.2. Takashi --- src/metaflac/operations.c-dist 2005-05-25 16:20:02.000000000 +0200 +++ src/metaflac/operations.c 2005-05-25 16:20:09.000000000 +0200 @@ -26,7 +26,7 @@ #include <stdlib.h>

Erik de Castro Lopo wrote: > Working on a fix for this and re-visiting some of this realloc() > stuff. I noticed that your patch removes the call to vorbiscomment_entry_array_delete_() in FLAC__metadata_object_vorbiscomment_resize_comments() function, and I think that it reintroduces one place of a potential memory leak: 'object->data.vorbis_comment.comments' is a pointer to an

libFLAC has several places like this: if(0 == (ptr = realloc(ptr, size))) return false; which results in memory leaks if realloc fails (the old value of ptr is lost). The patch should fix this. -------------- next part -------------- A non-text attachment was scrubbed... Name: realloc_memleak_fix.patch Type: application/octet-stream Size: 6272 bytes Desc: not available Url :

Here's a patch to allow flac and metaflac handle files with malformed vorbiscomment metadata block. -------------- next part -------------- diff --git a/src/libFLAC/metadata_iterators.c b/src/libFLAC/metadata_iterators.c index d50df39..39cb276 100644 --- a/src/libFLAC/metadata_iterators.c +++ b/src/libFLAC/metadata_iterators.c @@ -78,7 +78,7 @@ static FLAC__Metadata_SimpleIteratorStatus

On 26.9.2014 15:21, Erik de Castro Lopo wrote: > Janne Hyv?rinen wrote: > >> Patch v2, now handles more malformed cases. Original patch was for a >> file for which I had a sample from a user but this allows handling some >> manually broken test cases. > > Err, I'm getting warning messages on that patch: > > CC metadata_iterators.lo >

Janne Hyv?rinen wrote: > Patch v2, now handles more malformed cases. Original patch was for a > file for which I had a sample from a user but this allows handling some > manually broken test cases. Err, I'm getting warning messages on that patch: CC metadata_iterators.lo metadata_iterators.c: In function ?read_metadata_block_data_vorbis_comment_cb_?:

Patch v2, now handles more malformed cases. Original patch was for a file for which I had a sample from a user but this allows handling some manually broken test cases. On 25.9.2014 21:53, Janne Hyv?rinen wrote: > Here's a patch to allow flac and metaflac handle files with malformed > vorbiscomment metadata block. > > > _______________________________________________ >

Hi List, I recently was assigned a task to port FLAC Encoder to our embedded platform. Thanks to OO-like design of the libFLAC and throught documentation, that porting went like a charm. I had some problems with chmod/chown like routines while porting but I was able to safely remove that piece of code without any trouble. I have observed that the my application FLAC Encoder failes in

Hi all, recently I tried to add cover art to flac files and have dfficulties in doing so. FLAC__Metadata_Chain *chain = FLAC__metadata_chain_new(); if(0 == chain) return; if(!FLAC__metadata_chain_read(chain, filename)) return; FLAC__StreamMetadata *picture = FLAC__metadata_object_new(FLAC__METADATA_TYPE_PICTURE); FLAC__Metadata_Iterator *iterator = FLAC__metadata_iterator_new(); if(0 ==

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__metadata_simple_iterator_get_block(iterator_));"), if one does not delete this pointer, the