Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Why checksum uncompressed audio? (Read 8875 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Why checksum uncompressed audio?

FLAC and Wavpack (likely others too) use error detection codes for uncompressed audio data.
Why not for compressed?

I could find only 2 differences:
-you have to decompress the data to verify correctness, which (sometimes greatly) reduces verification performance
-you have more data to be checksumed, which slightly reduces compression / verification performance

What am I missing?

Why checksum uncompressed audio?

Reply #1
The checksum is meant to proof that the decoded data is the same as the source (e.g. wav file). A checksum of the encoded data will only proof that the file hasn't changed. Off course you could have booth.

Why checksum uncompressed audio?

Reply #2
The checksum is meant to proof that the decoded data is the same as the source (e.g. wav file). A checksum of the encoded data will only proof that the file hasn't changed. Off course you could have booth.


AFAIK (not very far) neither FLAC nor WavPack store checksums of the whole audio, but separate ones for each block.
Therefore they aren't useful for comparisons with the source.


Why checksum uncompressed audio?

Reply #4
WavPack by default uses blockbased CRC's and, if desired, an MD5 hash of the audio data.

To my knowledge The CRC's are only used for error detection in the audio stream while decoding it.
The MD5 hash is more usefull to verify the entire audiocontent. This could be used in a couple of scenario's:
  • When transcoding lossless audio the MD5 hash can be used to verify that the same audiocontent is still there (intact) after the transcode. This can be usefull to detect misbehaving software or hardware.
  • It could also be usefull to find duplicates in a large collection. When two MD5 hashes match there is very high chance that the audiocontent is the same.

I hope this is what you were asking ?

After reading your question a little bit more thoroughly I guess what you're asking is: "Why don't they keep an MD5 of the compressed audiocontent instead of the decompressed audiocontent?".

A hash of the compressed audio wouldn't be very useful because most people are much more interested in the integrity of the decompressed audio which cannot be 100% guaranteed by looking at the hash of the compressed audio. I think a hash of the decompressed audio is just much more usefull because it has more usecases and is directly linked to the audiocontent only.

Why checksum uncompressed audio?

Reply #5
OK, now I get it.
I didn't know that there are 2 kinds of EDC used simultaneously.
Yes, a checksum of whole audio data is indeed useful. Though for corruption detection (for me that's the main point of keeping checksums) a checksum for compressed data would work just as well and way faster.

Thanks a lot for the answer.

Why checksum uncompressed audio?

Reply #6
What is your goal? You don't need to decode and verify your files every now and then. If you ask me both a checksum of encoded and decoded audio is somewhat useless if you have no reference. AccurateRip is a large database that provides the ability to verify CD-rips using checksums. With CUEtools you can even store verification results to tags.
Can't wait for a HD-AAC encoder :P

Why checksum uncompressed audio?

Reply #7
Silent data corruption.
I verify my music collection once in a while. I had to resign from using WavPack because it took way too long.
I'm considering switching to TAK as soon as there's 2.0, but I'm wondering if verification time won't make it inapplicable too.

Why checksum uncompressed audio?

Reply #8
Verification time should be disk-bound. I don't think that what you are asking for would change anything, if you're not running a 386.

Why checksum uncompressed audio?

Reply #9
If it was disk bound, FLAC and WavPack would have roughly the same speed.
But WavPack was several times slower.

Why checksum uncompressed audio?

Reply #10
Just checked an old comparison. Wavpack 4 really only does about 5 MB/s on an Athlon 800. That's quite lame. I wonder if its later asymmetrical modes could improve that considerably.