Super-Paranoia: FLAC to WAV Options

[The Legioneer]

Given that FLAC is a lossless format:

I'm in the process of archiving my Audio CDs through EAC digital extraction. Once I have the WAV files from EAC, they're converted to FLAC, and the WAV files are deleted.

Now suppose down the road, something better than FLAC emerges, and I have to decode these FLAC files back to WAV files. Will the new WAVs, converted from FLAC, be bit by bit identical to the old WAVs, extracted by EAC?

Sorry if my English is broken, it is not my native tongue.

[pdq]

The audio content will be bit-for-bit identical. Metadata, such as tags, is a different story.

[The Legioneer]

Thanks for the reply. What would be the best way to verify that the two WAV files are, in fact, identical?

I was thinking that if I make an MD5 of the WAVs before I convert them, then I could save the MD5 and use it to verify that the new WAVs I converted from FLAC were perfect copys of the original rips from EAC. But if the meta data is different, this would not work, would it?

[Mangix]

if you use foobar2000, you can use the bitcomparer plugin from the optional components page on the foobar2000 homepage. theoretically, it should work.

[greynol]

flac files contain an md5 checksum of the raw pcm data. You can use this checksum for verification. Also, flac.exe is capable of stdout, which means that you can convert them to other formats without having to create a pcm file.

As an example, I often transcode flac files to ape files. I've heard horror stories about how Monkey's Audio can create corrupt files so in my paranoia, I verify each and every transcode. It goes something like this:

flac.exe -d -c -s %1 | mac.exe - "%~dpn1.ape" -c3000

This creates an ape file directly from a flac file without ever creating a wave file.

metaflac --show-md5sum %1 > "%~dpn1.flac.md5"

This extracts the md5 checksum of the decompressed raw pcm data of the flac file.

mac "%~dpn1.ape" - -d 2>nul | sox -t wav - -t raw - | md5sum > "%~dpn1.ape.md5"

This decodes the newly-created ape file and generates an md5 checksum of the raw pcm data which is directly compared to the md5 checksum extracted from the flac file. If they are the same then the transcode was lossless.

Unfortunately sox is not able to losslessly create a raw file from a wave file if the wave file does not end on a frame boundary. I should probably use shntool instead of sox and md5sum but there is a slight decrease in speed using shntool. It is rare that I deal with files that don't end on frame boundaries however, and I like being alerted when a file does not end on one.

This post has been edited by greynol: Nov 7 2006, 07:49

[jcoalson]

see also http://flac.sourceforge.net/faq.html#general__lossless_trust

if you're archiving, paranoid is good... in addition to using the -V option when encoding, you should be able to add a step that decodes the FLAC to another WAV file and then compare the two WAVs in an automatic way. if you can make sure EAC generates canonical form (1 fmt chunk, 1 data chunk only) then you can just use 'cmp /b' to compare.

Josh

[$char(9836)]

I was thinking that if I make an MD5 of the WAVs before I convert them, then I could save the MD5 and use it to verify that the new WAVs I converted from FLAC were perfect copys of the original rips from EAC. But if the meta data is different, this would not work, would it?

You could actually do that because WAV files cannot have any metadata.

[j7n]

Metadata can be placed in the INFO chunk (aka "LIST" chunk with a list type of "INFO") associated with all RIFF files. Additional metadata is a feature of the bext (Broadcast Audio Extension) associated with WAVE_LPCM_BWF (Broadcast WAVE Audio File Format); additional data is defined for the CART/Audio Delivery Extension to BWF proposed to the Audio Engineering Society.

No metadata is written by Foobar and most other tools but could be.