Hi Josh, Thanks for the response!
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.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.
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.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.
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.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
2. libFLAC does not support 32 bps yet
Thanks for pointing this out!
addVorbisComment seems to work, although I am not using your FLAC__metadata_object_vorbiscomment_entry_from_name_value_pair function:that looks ok too, assuming addVorbisComment works. the metadata interface also has not changed in flac-1.1.3
void
addVorbisComment(FLAC__StreamMetadata *block,
NSString
*key,
NSString
*value)
{
NSString
*string;
FLAC__StreamMetadata_VorbisComment_Entry entry;
string = [NSString stringWithFormat:@"[EMAIL
PROTECTED]@", 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?
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 :)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#ga44that could be a source of mem corruption or leakage.
If you're still interested in looking at a problem file I will be happy to upload it to my server.that's a wierd error though. can you send or host one of the bad FLAC files for me to check out?
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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Flac-dev mailing list [email protected] http://lists.xiph.org/mailman/listinfo/flac-dev
