FLAC Situation... Suggestions?

[raintheory]

Hey all,

I am trying to use this program to convert some .wav files from a Cubase project to FLAC to save space. The .wav files are 16bit 48hz, and I ran a test and converted one of these files to FLAC then back to .wav as 16bit 48hz... However, now the CRCs and MD5 values are different from the original.

Any idea why this would be happening and how I could fix this to avoid any complications with these files in the future?

Thanks!

[LtData]

Re: FLAC Situation... Suggestions?

You might have converted to a 16-bit 44.1KHz WAV instead of a 48KHz WAV. Or you might have converted to a 44.1KHz FLAC and then back to a 48KHz wav which is 2 resamples and resampling is always lossy.

[raintheory]

Re: FLAC Situation... Suggestions?

You might have converted to a 16-bit 44.1KHz WAV instead of a 48KHz WAV. Or you might have converted to a 44.1KHz FLAC and then back to a 48KHz wav which is 2 resamples and resampling is always lossy.

I had the .WAV settings set correctly to 16bit/48hz... as for converting to FLAC, I don't see any options for 16/24bit or 44.1/48hz... Is there something I am missing?

It did cross my mind that maybe converting to FLAC defaults to 16bit 44.1, but I am a little surprised that there isn't any option to specify this...

[LtData]

Re: FLAC Situation... Suggestions?

Alright, after some testing, inputting a 48KHz file as a WAV and choosing FLAC makes a 48KHz FLAC file. The checksum and MD5 may be different but the files should sound exactly the same, as all conversions were between lossless files.

[raintheory]

Re: FLAC Situation... Suggestions?

Alright, after some testing, inputting a 48KHz file as a WAV and choosing FLAC makes a 48KHz FLAC file. The checksum and MD5 may be different but the files should sound exactly the same, as all conversions were between lossless files.

Seems strange that the checksums would be different though... I had done this same conversion previously (using different software, although dbpoweramp is much more convenient) and the resulting WAV files had the same checksums. The only real difference was that the files before were 16bit 44.1hz instead of 48hz

Initially I was thinking that it could be a tag issue, but I had no tags and option to retain tag info unchecked so it shouldn't be that.

I think as long as the FLAC file is 48hz after conversion than I shouldn't run into any problems, but I still almost feel more comfortable when the resulting checksums are identical because then I can be confident that there has been no inadvertant change to the audio information in the file. I know that with lossless formats there shoudn't be, but it's nice to be able to verify it.

EDIT: I just converted the same audio file to Monkeys Audio Format and when converted back to WAV it has different checksums as well... :(

[raintheory]

Re: FLAC Situation... Suggestions?

Thanks for your help LtData. It turns out this anomaly can be caused by a number of things (and not change the audio data at all) such as seek tables, headers, etc.

Quote from etree.org:

SPECIAL NOTE ABOUT .MD5 FILES AND FLAC: Whether or not to make an .md5 checksum file for a .flac fileset is a confusing topic!

* Why whole-file flac .md5s can be a hindrance: Under FLAC, you are allowed to change the compression ratio and add/remove meta data to .flac files without changing the actual audio. The audio may be identical, but the extra data will completely change the .md5 checksum. Checking these .md5s against the new .flac files will report failure, even though there is nothing actually wrong with the new fileset. That can cause major confusion. Going by whole-file .md5 alone can also cause confusion when trying to compare the new fileset against others in a database (similar to the current situation with nonseeking vs. seek-appended .shn files).
* Why whole-file wav md5s can be a hindrance: wav files aren't perfectly standardized. Different applications can create different wav files with the same music data. Further, flac doesn't encode everything in the headers of the wav file, only what is necessary. So the file sets that are created using a wav > flac > wav conversion have a good chance of not having identical md5s.
* Why whole-file .md5 can be a help: They can still serve as a quick "parts list" since they will have a line for each flac file that is supposed to be in the fileset. If any files are missing, you can tell quickly. They help as a quick check for integrity of the whole file (not just the data part), so you can spot simple corruptions during uploads/downloads. It's also currently a good idea to add whole-file .md5 files to .flac sets that are uploaded to archive.org; it makes the whole upload/contribution process there run smoothly at several steps.
* A whole-file .md5 is really no longer necessary, since md5check.exe checks the .ffp file and will notify the user if any files are missing from the fileset. Ideally, this functionality will be incorporated into FlacFrontend.
* Because of these competing rationales, the community is still [struggling] to reach a consensus on generating whole-file .md5s. Currently, etree.org formally discourages the practice for trading, while the [Internet Archive's Live Music Archive] encourages it for their site.

EDIT: Any chance that a future version of the FLAC encoder would have the option to create .ffp files to compare audio data? :smile2:

Definitely going on the wishlist from me.

Thanks again!

[LtData]

Re: FLAC Situation... Suggestions?

Oh, WAV files don't have any tags, though there will be some when using dMC r12.

[Spoon]

Re: FLAC Situation... Suggestions?

Different wave file headers, hodl the mouse over both wave files and dbpoweramp will tell the type of wave header (the actual data is the same though). There can be:

wave format
wave formatex
wave formate extensible

3 different headers...