similar to: metaflac bug

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

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. > > > _______________________________________________ >

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

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:

Hopefully the last patch from me to UTF-8 issues. Metaflac can now print all console supported characters from tags on the screen. It also fixes metaflac to be able to import its own exports back without non-ascii characters getting mutilated. And --no-utf8-convert now works properly with import and export commands. I updated my Windows binary archive with these changes for any interested

--- Joshua Kwan <joshk@triplehelix.org> wrote: > Well, I'm quite frankly stumped. I'm writing a program that recurses > into directories and reads (among others) FLAC files and should be > able > to read the vorbis comments ARTIST and TITLE from the file. > > A while back, I was popen()ing to metaflac, because I didn't want to > mess with libFLAC. But now,

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 calling FLAC__metadata_object_new(FLAC__METADATA_TYPE_VORBIS_COMMENT) will create the comment, but I

On Tue, Jul 08, 2003 at 10:11:49PM +0200, Miroslav Lichvar wrote: > On Tue, Jul 08, 2003 at 11:07:09AM -0400, Matt Zimmerman wrote: > > severity 200435 normal > > thanks > > > > I received this bug report from a Debian user. I can't think of any reason > > offhand why the command line tool would work while the xmms plugin would > > fail. > ... >

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 >

Hi, Here's a patch to add support for streaming HTTP transport to the xmms plugin. Most of the code (in particular, http.c) is taken from the xmms mpg123 input plugin. You'll need to make a three-line change to the xmms mpg123 input plugin to get streaming to work. The mpeg plugin currently handles all http urls itself unless they end in an ogg or real audio extension (which means flac

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

severity 200435 normal thanks I received this bug report from a Debian user. I can't think of any reason offhand why the command line tool would work while the xmms plugin would fail. ----- Forwarded message from Stephan Niemz <st.n@gmx.net> ----- Date: Tue, 8 Jul 2003 10:24:57 +0200 From: Stephan Niemz <st.n@gmx.net> Resent-From: Stephan Niemz <st.n@gmx.net> To: Debian

Well, I'm quite frankly stumped. I'm writing a program that recurses into directories and reads (among others) FLAC files and should be able to read the vorbis comments ARTIST and TITLE from the file. A while back, I was popen()ing to metaflac, because I didn't want to mess with libFLAC. But now, it's the weekend, so I can mess around with this. Here's the code in question:

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_?:

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