FLAC Tester

[angelp1ay]

I've been ripping all my CDs to FLAC in Winamp (currently 5.531 but also a couple of earlier series 5). I've just downloaded FLAC (for Windows w/ installer) and run the app "FLAC Tester" on some of these files and for almost all of them it comes up with "Error_MD5_CHECK" - is there a good reason for this? Should I be worried? They all play fine in Winamp...

[germain47]

For simply ripping flac from Cd an md5 check is not really important. An md5 is a set of checksums that will verify exact file transfers, though the most appropriate set of checksums to use for flac are ffp. These checksums will ensure that every bit of data is transfered without error. Unfortunately the Winamp flac encoder does not create any sort of checksums when encoding. That makes Winamp encoded flac files untradable. But like I said, for ripping from CD, it really doesn't matter.

[J_Darnley]

germain47, FLAC files have an md5 has stored in them. This is what flac -t tests against.

It is a check if the decoded audio is identical to the original input audio. If they don't match then the problem is either with calculating the md5, encoding the audio or decoding it. The likely cause of it is the encoding. There were reports that flake was not lossless so before I started using it, I tested it but was unable to see this.

angelp1ay, the only thing you can do is try re-ripping the CDs. Rip just one and then see if you still get the error.

[Rocker]

mine test fine.

[angelp1ay]

Originally posted by J_Darnley
germain47, FLAC files have an md5 has stored in them. This is what flac -t tests against.

It is a check if the decoded audio is identical to the original input audio. If they don't match then the problem is either with calculating the md5, encoding the audio or decoding it. The likely cause of it is the encoding. There were reports that flake was not lossless so before I started using it, I tested it but was unable to see this.

angelp1ay, the only thing you can do is try re-ripping the CDs. Rip just one and then see if you still get the error.

Originally posted by Rocker
mine test fine.

Urgh this sounds bad. I don't see how I could really be doing anything differently, Winamp is doing it all and it's not like there's a load of options!

Is the MD5 stored in the FLAC file that of the source material to be compared to one generated for the FLAC? Could it just be that the encoder is not adding the MD5 to the FLAC? Is there any way I can check this? Is there any way I can get the MD5 of a CD track and the MD5 of one of my FLACs from scratch and manually compare?

Could the error be at the CD read? I'm running from an external drive through a (possibly suspicious) USB2 card.

I've just checked 50 tracks (3 albums) and they all gave the MD5 error...

[J_Darnley]

The md5 hash should be calculated at the time the flac file is encoded. It is calculated from the audio data it uses. flac -t decodes the audio and calculates the md5 hash of that decoded audio. If they do not match it returns "ERROR, MD5 signature mismatch". Flac tester should do the same thing but returns a different error message.

I will do some more looking but if it was a CD read error then Winamp should still produce "correct" flac files. I don't think flac files are allowed to not have an md5 hash.

[angelp1ay]

Originally posted by J_Darnley
The md5 hash should be calculated at the time the flac file is encoded. It is calculated from the audio data it uses. flac -t decodes the audio and calculates the md5 hash of that decoded audio. If they do not match it returns "ERROR, MD5 signature mismatch". Flac tester should do the same thing but returns a different error message.

I will do some more looking but if it was a CD read error then Winamp should still produce "correct" flac files. I don't think flac files are allowed to not have an md5 hash.

Ok, so pretty much the Winamp FLAC encoder is to blame? Then why is it working for Rocker?

Could it be that I'm encoding with one encoder (Winamp) and decoding with a different decoder (SourceForge FLAC) when running the tester? Am thinking all encoders should produce valid FLAC files that work with all decoders...

[Benski]

There is indeed a bug in writing the MD5 digest. It's not an indication of improper encoding, though, just writing it before it's done being calculated. It will be fixed in 5.54. In the meantime, you could use the FLAC commandline tool (same one you were using to test) to re-encode and generate a new FLAC file with a correct MD5 hash.

[angelp1ay]

Originally posted by Benski
There is indeed a bug in writing the MD5 digest. It's not an indication of improper encoding, though, just writing it before it's done being calculated. It will be fixed in 5.54. In the meantime, you could use the FLAC commandline tool (same one you were using to test) to re-encode and generate a new FLAC file with a correct MD5 hash.

This is (oddly since it's a bug) good news. I was dreading the prospect of re-ripping all my CDs. I will greatly look forward to the new version.

If I re-encode using the command line then presumably the MD5 check will only show that the new FLAC is identical to the old FLAC, not that the new FLAC is identical to the original CD? Is there any way I can verify that my currents FLACs are valid?

[Benski]

The purpose of the MD5 is to have a quick way to verify if errors were made to FLAC file "after the fact", due to a faulty hard disk, errors in transmission while sending it over the internet, or other corruption. It doesn't verify that the contents match the CD.

[J_Darnley]

Yeah, I've just found that Winamp doesn't write correct md5 hashes to file. The good part is that the flac files made by Winamp do decode correctly and the output is exactly the same as all other encoders I tested.

There is just one case where Winamp's file didn't produce identical output but that seems to be because of padding as it is 4608 samples longer. That is really odd, because it is one block size.

[angelp1ay]

Originally posted by Benski
The purpose of the MD5 is to have a quick way to verify if errors were made to FLAC file "after the fact", due to a faulty hard disk, errors in transmission while sending it over the internet, or other corruption. It doesn't verify that the contents match the CD.

Gotcha. So the MD5 allows you to check the FLAC is the same as it was when encoded?

I guess this makes it less important for my needs - I really just want to confirm that the rips are completing successfully and giving me valid FLAC copies of the original tracks. Is there any similar way to confirm it's identical to source or is that just for granted due to the logic behind the encoder?

Originally posted by J_Darnley
Yeah, I've just found that Winamp doesn't write correct md5 hashes to file. The good part is that the flac files made by Winamp do decode correctly and the output is exactly the same as all other encoders I tested.

This is re-assuring

[germain47]

It's good to know Benski that a fix is on the way. Every file I encoded to flac using Wianmp has failed to properly decode using either flac frontend or Trader's Little Helper. The actual audio data is fine because the files will decode if decode through errors is enabled.

A point of clarification though. An md5 is a checksum that that is used to check the container format, not the actual audio data. What is written into flac files as they're encoded are ffp checksums. These checksums are a check of the actual audio data and will remain constant through all lossless conversions.

[J_Darnley]

Originally posted by germain47
A point of clarification though. An md5 is a checksum that that is used to check the container format, not the actual audio data. What is written into flac files as they're encoded are ffp checksums. These checksums are a check of the actual audio data and will remain constant through all lossless conversions.

ffp checksums? I'm not familar with that term. Oh right "flac fringerprint", thanks Google. Those are just the md5 hash from the header. Why do people create terms for things that are already well documented? "flac fingerprint" or fingerprint are not mentioned anywhere in the offical docs.

flac does have an md5 hash stored in its STREAMINO header which is is the hash of the raw input audio data. It also has CRC checksums to verify frame integrity.

[angelp1ay]

Originally posted by J_Darnley
ffp checksums? I'm not familar with that term. Oh right "flac fringerprint", thanks Google. Those are just the md5 hash from the header. Why do people create terms for things that are already well documented? "flac fingerprint" or fingerprint are not mentioned anywhere in the offical docs.

flac does have an md5 hash stored in its STREAMINO header which is is the hash of the raw input audio data. It also has CRC checksums to verify frame integrity.

So I can use the FFP checksums to verify a correct loseless rip? Does the FLAC tester check these?

And the CRC checksums verify correct FLAC wrapping around the audio? Presumably if both of these are correct I can infer the MD5 check should have passed too if it had been written correctly?

[Rocker]

I always decode the file back to source to check it.

[angelp1ay]

Originally posted by Rocker
I always decode the file back to source to check it.

I'm very new to all this stuff. I've got Windows FLAC. If I open up the frontend, select the files, and hit "decode" then I guess it makes a load of WAV files? How do you then compare this to source? What if the source is a CD?

Would it be easier to encode my CDs to FLAC from the command line and then just listen to them in Winamp?

Sorry for lots of questions - am learning huge amounts from all this!

[J_Darnley]

Originally posted by angelp1ay
I'm very new to all this stuff. I've got Windows FLAC. If I open up the frontend, select the files, and hit "decode" then I guess it makes a load of WAV files? How do you then compare this to source? What if the source is a CD?

Would it be easier to encode my CDs to FLAC from the command line and then just listen to them in Winamp?

Sorry for lots of questions - am learning huge amounts from all this!

Yes, decoding using the flac front end does create a lot of wav files. Flac compares them itself when decoding and returns a error if it doesn't match what it should be.
Technically if the hash calculated doesn't match the hash stored in the header. It is possible to have more than one lot of data match the same hash but I can't see why this would come up in this case the audio case.

To compare files your self there is no very simple way with Windows. I use the command line tool md5sum to check the decoded output to the input. I will attach the file I got after some fancy command line work.

The only differences are with track 6 and 7. 6 is because of some data on the end, the name of the track and the encoding application. 7 is the problem with lots of padding on the front.

If you want to compare a CD manually, first you would need to rip it as wav. You could use use Exact Audio Copy to make the whole process much easier.

[germain47]

Anlgelp1ay, I think maybe we are talking around you and not addressing your problem head on.

A CD has no checksums encoded within it.

When anything is encoded to flac, a set of checksums called an ffp or flac fingerprint is suppose to be written into each file.

A checksum or hash is a 32 hexadecimal string of characters. Each character will be one of the first 10 or so letters and or a numerical digit. This creates so many possible combinations that one can be safely assured that every file created will have a unique hash.

Apparently the Winamp flake encoder has a bug and the ffp isn't being written properly as the flac files are created.

This in itself does not mean any problem with the audio data itself is present, but errors will be noted if you test the files or attempt to decode them.

If you want to be assured that your rip produces bit for bit perfect encoding, use EAC (Exact Audio Copy) in secure mode to rip your CDs to flac. Ripping with Winamp is fine, but it is not as rigorous as EAC and you are less likely to get a perfectly error free rip.

If your sole purpose is to rip your CDs for personal use and your CDs are in very good condition, using Winamp to rip & encode is fine.

If you plan to transfer these files to anyone and want to be able to verify the transfer, you'll need to use EAC, at least for now. EAC will encode the ffp into the flac files.

If verifying your files is important to you, dump flac frontend and install Trader's Little Helper as your utility. TLH is far more user friendly and much more versitle.

[angelp1ay]

Originally posted by germain47
Anlgelp1ay, I think maybe we are talking around you and not addressing your problem head on.

A CD has no checksums encoded within it.

When anything is encoded to flac, a set of checksums called an ffp or flac fingerprint is suppose to be written into each file.

A checksum or hash is a 32 hexadecimal string of characters. Each character will be one of the first 10 or so letters and or a numerical digit. This creates so many possible combinations that one can be safely assured that every file created will have a unique hash.

Apparently the Winamp flake encoder has a bug and the ffp isn't being written properly as the flac files are created.

This in itself does not mean any problem with the audio data itself is present, but errors will be noted if you test the files or attempt to decode them.

If you want to be assured that your rip produces bit for bit perfect encoding, use EAC (Exact Audio Copy) in secure mode to rip your CDs to flac. Ripping with Winamp is fine, but it is not as rigorous as EAC and you are less likely to get a perfectly error free rip.

If your sole purpose is to rip your CDs for personal use and your CDs are in very good condition, using Winamp to rip & encode is fine.

If you plan to transfer these files to anyone and want to be able to verify the transfer, you'll need to use EAC, at least for now. EAC will encode the ffp into the flac files.

If verifying your files is important to you, dump flac frontend and install Trader's Little Helper as your utility. TLH is far more user friendly and much more versitle.

Good answer Germain! So to summarise:

- EAC for CD > FLAC means I can verify error free ripping
- EAC will write correct fingerprint checksums which can be checked with Trader's Little Helper to verify a file is still intact.

Sounds like I'll never be able to confirm whether my current lot of FLACs are identical to the CDs - I hadn't appreciated this before. I'm not sure whether I'll re-encode these with EAC, but I'm very picky so I might. It just seems a shame using FLAC and not knowing whether it's identical to the original CD - surely that's the point, "lossless".

Any chance Winamp will include this secure rip mode?

[germain47]

Since the CD audio files have no checksums, you can not ever be 100% certain the rip is perfect. When ripping you are creating the first set of checksums for the files. If you were to rip again, and just one bit of data were different the checksums created would be different. So your original flacs are only as good as the rip. Once the flacs are created though, the digital transfer or re-encoding to another lossless format can be verified as 100% accurate compared to the original files.

[ujay]

Verifying CD rips.

http://www.accuraterip.com/

May be of interest to you.

UJ

[angelp1ay]

Originally posted by germain47
Since the CD audio files have no checksums, you can not ever be 100% certain the rip is perfect. When ripping you are creating the first set of checksums for the files. If you were to rip again, and just one bit of data were different the checksums created would be different. So your original flacs are only as good as the rip. Once the flacs are created though, the digital transfer or re-encoding to another lossless format can be verified as 100% accurate compared to the original files.

So how does secure mode work in EAC? Several reads and comparisons?

Originally posted by ujay
Verifying CD rips.

http://www.accuraterip.com/

May be of interest to you.

UJ

Sadly I know my drive produces varying offsets. Can you get external drives that don't? If so I suppose that's a possibility :P