similar to: 64-bit FLAC structure sizes and padding

Erik, thanks for the swift answer. Your right, I haven't seen any issues yet. But it a thought stroke me when implementing edit capabilities of FLAC vorbis comments. I've already implemented reading vorbis comments from FLAC files in 64-bit and it works without any issues. This now leave me a bit confused, since it should have issues(!). Using the MS 64-bit compiler on Windows 7/2008R2

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

> 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] > > > Thanks ! Yeah sure! I don't get

Hi all, As I understand there could be issues to edit/create FLAC files in 64-bit due to different structure sizes (data alignment and data structure padding added by 64-bit compilers). I don't know if this have been dealt with before in this list. I suggest the following addition to the headers (understood by most compilers) #pragma pack(push,4) FLAC_structures ... #pragma pack(pop) That

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

* Josh Coalson <xflac@yahoo.com> shaped the electrons to say... >yep, that will work too. but just writing skipping code is >pretty simple: > >is_last=0 >read 'fLaC' string >while (!is_last) { > read 1 byte metadata block type > read 3 byte metadata block length > is_last = type & 0x80 > fseek(file,length,SEEK_CUR) >}

Hello all, I get unresolved external symbol __muloti4 when attempting to compile GNU m4 for Windows commandline. See details in bug: https://bugs.llvm.org/show_bug.cgi?id=16404#c22 Looking into this, I see that some parts of compiler-rt are disabled for Windows due to the __LP64__ define. The code seem not portable as is to the MS compiler, but according to my tests the code compiles and links

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

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 >

* Josh Coalson <xflac@yahoo.com> shaped the electrons to say... >not exactly. the metadata interface won't tell you, but you >can create a decoder (say file decoder), set it up, then call > > FLAC__file_decoder_process_until_end_of_metadata(...) > FLAC__file_decoder_get_decode_position(...) > >and that will tell you. the decode position is relative to >the

Hi, I'm sorry to say that I've found the libFLAC++ interface and documentation pretty slim and baffling. What I need to do is add some application-specific metadata to a FLAC file (i'm using the FLAC++ fileencoder). It is currently just a string of characters, which doesn't need to be null-terminated. I've looked through the docs, i've looked through the tests, and

There are two functions: static void vorbiscomment_entry_array_delete_(FLAC__StreamMetadata_VorbisComment_Entry *object_array, unsigned num_comments); and static void cuesheet_track_array_delete_(FLAC__StreamMetadata_CueSheet_Track *object_array, unsigned num_tracks); which first dereference object_array and only then check it for NULL: free(object_array[i].indices);

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

Found this code: ftp://ftp.samba.org/pub/unpacked/ntdb/lib/ccan/ilog/ilog.c Tests show that it's faster to use the following code in FLAC__bitmath_ilog2_wide(): static const unsigned char DEBRUIJN_IDX32[32]={ 0, 1,28, 2,29,14,24, 3,30,22,20,15,25,17, 4, 8, 31,27,13,23,21,19,16, 7,26,12,18, 6,11, 5,10, 9 }; FLAC__uint32 v; int m;

1) FLAC supports only MSVS 2005 and newer, so (_MSC_VER >= 1400) is always true and can be removed. 2) The argument for FLAC__clz_uint32() is of FLAC__uint32 type, so FLAC__clz_soft_uint32() should have the same argument type. 3) The patch removes unnecessary parentheses around 'word' variable. 4) It also replaces "sizeof(FLAC__uint32) * CHAR_BIT - 1 -

There are following functions in bitreader.c: FLAC__bool FLAC__bitreader_read_unary_unsigned(FLAC__BitReader *br, unsigned *val); FLAC__bool FLAC__bitreader_read_rice_signed(FLAC__BitReader *br, int *val, unsigned parameter); FLAC__bool FLAC__bitreader_read_rice_signed_block(FLAC__BitReader *br, int vals[], unsigned nvals, unsigned parameter); * function FLAC__bitreader_read_rice_signed():

Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > Well first of all, none of them apply :-). I'll try to redo the necessary patches with git. > * Remove restrict definition from include/share/compat.h. Applied. BTW, I tried to use 'restrict' keyword with MSVS 2010 and 2012 and in fact they don't support it. Only --restrict is supported. > * libFLAC and

I refer to a problem that appeared on the flac list last August that was either solved off-list or abandoned. (http://lists.xiph.org/pipermail/flac/2005-August/000468.html) The problem is with using the C++ encoder classes, particularly the FLAC::Encoder::File:set_metadata function. JC said that the developers version of how to add a simple metadata block looked right, but it did not work for

This commit will break OS/2's EMX 0.9d library (GCC 2.8.1) which has been been replaced by klibc. Considering the age of EMX and lack of testing and that klibc contains so many improvements I think this is exceptable. --- include/FLAC/ordinals.h | 17 +++++++++-------- src/flac/main.c | 2 +- src/libFLAC/metadata_iterators.c | 2 +-

Ok, here is a patch waiting for new CVS :). It works fine for me, but please check it before commiting... -- Miroslav Lichvar -------------- next part -------------- --- src/libFLAC/bitbuffer.c.orig 2003-01-30 17:36:01.000000000 +0100 +++ src/libFLAC/bitbuffer.c 2003-01-30 21:53:18.000000000 +0100 @@ -51,6 +51,25 @@ */ static const unsigned FLAC__BITBUFFER_DEFAULT_CAPACITY = ((65536 - 64) *