[Flac-dev] Help upgrading to 1.1.3 (MD5 sum issues, album art corrupts files)

Stephen F. Booth me at sbooth.org
Thu Jan 18 00:24:08 PST 2007


Hi Josh,

Thanks for the response!

> I took a quick look and it seems fine, but I'm assuming some
> things about the format of the incoming samples.  the way samples
> are passed to the encoder has not changed in flac-1.1.3 so if the
> same code worked before it should still work.
This is the main source of my consternation, because my previous code  
did not generate files with MD5 warnings.  The incoming samples are  
packed, big-endian signed integers.  FWIW, the output files play fine  
and contain the correct data (see below); it's the MD5 sum that isn't  
working the way it should.

> when you decode the flac file with the 'bad md5' back to PCM,
> does it match the original?  the best way to check is to just
> feed it a file of 1 sample, then increase until you trigger
> the problem.
Decoding the files back to PCM using flac -dF produces the same audio  
data as the original, so no data was lost.  I have hosted example  
files at http://sbooth.org/files/flac/ if you care to take a look at  
an offender.  I am able to cause the problem using a file consisting  
of only one sample!  I will go over my code again- there must be a  
mistake in it somewhere.

> a couple other things that are probably not related:
> 1. you can replace a lot of the settings more reliably and get better
>    compression using FLAC__stream_encoder_set_compression_level()
>    instead, see
> http://flac.sourceforge.net/api/group__flac__stream__encoder.html#ga20
This is mainly due to my preferences interface to the encoder;  
advanced users can specify most settings individually.  I originally  
copied the settings you had for each compression level manually; this  
function should simplify the common use cases.

> 2. libFLAC does not support 32 bps yet
Thanks for pointing this out!

> that looks ok too, assuming addVorbisComment works.  the metadata
> interface also has not changed in flac-1.1.3
addVorbisComment seems to work, although I am not using your  
FLAC__metadata_object_vorbiscomment_entry_from_name_value_pair function:

void
addVorbisComment(FLAC__StreamMetadata		*block,
				 NSString					*key,
				 NSString					*value)
{
	NSString									*string;
	FLAC__StreamMetadata_VorbisComment_Entry	entry;
	
	string			= [NSString stringWithFormat:@"%@=%@", key, value];
	entry.entry		= (unsigned char *)strdup([string UTF8String]);
	NSCAssert(NULL != entry.entry, NSLocalizedStringFromTable(@"Unable  
to allocate memory.", @"Exceptions", @""));
	
	entry.length	= strlen((const char *)entry.entry);
	if(NO == FLAC__metadata_object_vorbiscomment_append_comment(block,  
entry, NO)) {
		free(entry.entry);
		@throw [NSException exceptionWithName:@"FLACException"
									   reason:[NSString  
stringWithFormat:NSLocalizedStringFromTable(@"The call to %@  
failed.", @"Exceptions", @""),  
@"FLAC__metadata_object_vorbiscomment_append_comment"]
									 userInfo:nil];
	}	
}

Is there an advantage/reason to/for using the library's function to  
do this?

> but you should use the FLAC__metadata_object_picture_set_* methods
> to set the picture data instead of altering the block directly:
> http://flac.sourceforge.net/api/ 
> group__flac__metadata__object.html#ga42
> http://flac.sourceforge.net/api/ 
> group__flac__metadata__object.html#ga43
> http://flac.sourceforge.net/api/ 
> group__flac__metadata__object.html#ga44
> that could be a source of mem corruption or leakage.
Great!  I switched to using your functions and the files are no  
longer corrupted.  Maybe this alone is reason to use  
FLAC__metadata_object_vorbiscomment_entry_from_name_value_pair :)

> that's a wierd error though.  can you send or host one of the bad
> FLAC files for me to check out?
If you're still interested in looking at a problem file I will be  
happy to upload it to my server.

> also, are you using a libFLAC you built yourself or a prebuilt one
> from sourceforge or somewhere else?
I am using an OS X framework build that I created myself.

Stephen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2409 bytes
Desc: not available
Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20070118/b55ab1ff/smime.bin


More information about the Flac-dev mailing list