hi, i found this explanation of the flac fingerprint somewhere: 'A FLAC Fingerprint is generated only for the audio data portion of the file. (Therefore, changing the filename or the tags or FlacMetadata does not change the fingerprint calculation.) In contrast, an .md5 is generated against the whole file, including header portions.' so i was wondering what advantages it could give me to make a ffp file, because there is already a internally stored md5 checksum on the decoded audio data inside the flac file? What extra advantage does a ffp file give me while only considering the need to verify the audio data. i was also wondering how files encoded by using the new --keep-existing-metadata option are verified when using -verify. Is there a separate internally stored md5 for metadata next to the md5 for decoded audio data or how is everything verified? Is making a ffp file for such files also possible for the non-audio data (so all metadata)? i hope somebody can make this more clear, because it's rather confusing. i was also wondering if there exists a GUI program for win32 to verify flac files using a ffp file (so not md5check.exe) thx in advance
i forgot to ask this important question :) why doesn't a ffp file make a md5 of the *whole* flac file, so that all non-audio data inside the file are verified too? in my opinion, now it only does the same as the internally stored md5 on the decompressed audio data, but there is still no way to verify the header of the flac file (so i mean : all non-audio data in the file) or am i forgotting something? thx 2007/10/12, Harry Sack <tranzedude@gmail.com>:> hi, > > i found this explanation of the flac fingerprint somewhere: > > 'A FLAC Fingerprint is generated only for the audio data portion of > the file. (Therefore, changing the filename or the tags or > FlacMetadata does not change the fingerprint calculation.) In > contrast, an .md5 is generated against the whole file, including > header portions.' > > so i was wondering what advantages it could give me to make a ffp > file, because there is already a internally stored md5 checksum on the > decoded audio data inside the flac file? What extra advantage does a > ffp file give me while only considering the need to verify the audio > data. > > i was also wondering how files encoded by using the new > --keep-existing-metadata option are verified when using -verify. Is > there a separate internally stored md5 for metadata next to the md5 > for decoded audio data or how is everything verified? > Is making a ffp file for such files also possible for the non-audio > data (so all metadata)? > > i hope somebody can make this more clear, because it's rather confusing. > > i was also wondering if there exists a GUI program for win32 to verify > flac files using a ffp file (so not md5check.exe) > > thx in advance >
Harry,> so i was wondering what advantages it could give me to make a ffp > file, because there is already a internally stored md5 checksum on the > decoded audio data inside the flac file?Testing the .flac file against its internally stored fingerprint lets you know that you have a properly encoded .flac file of *something*. If you also certify that internally stored fingerprint against a list of correct fingerprints in another file, then you know you have a properly encoded .flac file of the *right* audio, and that the person who sent you the .flac files didn't accidentally provide a wrong file instead. Yes, a miscreant who would intentionally switch .flac files on you would also alter the .ffp file to show the fingerprint of the wrong file instead of the right one, but that could not happen by accident. Sending a set of .flac files with an .ffp file says, "I wouldn't deliberately deceive you"; sending a set of .flac files with no checksums at all says "I never make mistakes." There are people whom I'd trust not to deceive me deliberately but nobody from whom I'd accept a claim of infallibility. Moreover, if a set of .flac files is being shared, a copy of the fingerprints can be kept at a URL distributed with them, so that everyone receiving them can make sure that the fingerprints of the files (s)he gets match those of the original set.> i was also wondering how files encoded by using the new > --keep-existing-metadata option are verified when using -verify. Is > there a separate internally stored md5 for metadata next to the md5 > for decoded audio data or how is everything verified?Until we hear from someone who knows, I'd venture to say that --verify does just what it always did, and it has nothing to do with existing metadata in the uncompressed input. As it encodes each segment of the audio, it re-decodes it and compare the result to the original input.> Is making a ffp file for such files also possible for the non-audio > data (so all metadata)?No, fingerprints are defined only for audio.> i was also wondering if there exists a GUI program for win32 to verify > flac files using a ffp file (so not md5check.exe)Yes: Trader's Little Helper at http://thor.prohosting.com/roh0205/.
Harry,> why doesn't a ffp file make a md5 of the *whole* flac file, so that > all non-audio data inside the file are verified too?Because its purpose is to confirm the integrity of the audio in situations where it's OK to change the metadata, as it usually is. Changing the compression options, even if tags and such are unchanged, also results in a different whole-file MD5 checksum, but the fingerprint is the same.> in my opinion, now it only does the same as the internally stored md5 > on the decompressed audio data, but there is still no way to verify > the header of the flac file (so i mean : all non-audio data in the > file)If the file decodes or tests without error, the header is OK.
2007/10/15, David W. Tamkin <dattier@panix.com>:> > Harry, > > > so i was wondering what advantages it could give me to make a ffp > > file, because there is already a internally stored md5 checksum on the > > decoded audio data inside the flac file? > > Testing the .flac file against its internally stored fingerprint lets > you know that you have a properly encoded .flac file of *something*. If > you also certify that internally stored fingerprint against a list of > correct fingerprints in another file, then you know you have a properly > encoded .flac file of the *right* audio, and that the person who sent > you the .flac files didn't accidentally provide a wrong file instead. > > Yes, a miscreant who would intentionally switch .flac files on you would > also alter the .ffp file to show the fingerprint of the wrong file > instead of the right one, but that could not happen by accident. > Sending a set of .flac files with an .ffp file says, "I wouldn't > deliberately deceive you"; sending a set of .flac files with no > checksums at all says "I never make mistakes." There are people whom > I'd trust not to deceive me deliberately but nobody from whom I'd accept > a claim of infallibility. > > Moreover, if a set of .flac files is being shared, a copy of the > fingerprints can be kept at a URL distributed with them, so that > everyone receiving them can make sure that the fingerprints of the files > (s)he gets match those of the original set.yes, I all understand that, but I mean advantages when you don't send those files over the internet. So just encode them and burn them to a cd. Or is a ffp file only useful when you want to upload those files?> i was also wondering how files encoded by using the new > > --keep-existing-metadata option are verified when using -verify. Is > > there a separate internally stored md5 for metadata next to the md5 > > for decoded audio data or how is everything verified? > > Until we hear from someone who knows, I'd venture to say that --verify > does just what it always did, and it has nothing to do with existing > metadata in the uncompressed input. As it encodes each segment of the > audio, it re-decodes it and compare the result to the original input.but how can you verify the metadata of the input files then if there is no check for this?> Is making a ffp file for such files also possible for the non-audio > > data (so all metadata)? > > No, fingerprints are defined only for audio.same question as above> i was also wondering if there exists a GUI program for win32 to verify > > flac files using a ffp file (so not md5check.exe) > > Yes: Trader's Little Helper at http://thor.prohosting.com/roh0205/.thx, it's exactly what i'm looking for! unfortunately the file is offline, can you maybe email the file to me if you still have it? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/flac/attachments/20071015/12d3b84f/attachment.htm