On a quest to use ffmpeg to compute CRC32 checksums/hashes for audio files, I found two solutions that unfortunately produce differtent results:
> ffmpeg -i "01 - Mother And Child Reunion.flac" -vn -c:a pcm_s16le -f crc - 2>nul
> CRC=0x6a6ff88d
> ffmpeg -i "01 - Mother And Child Reunion.flac" -vn -c:a pcm_s16le -f streamhash -hash crc32 - 2>nul
> 0,a,CRC32=308ab1b1
Computing MD5 hashes with the above commands (replace crc/crc32 with md5) produce identical & correct results. I thought that both procedures were equivalent. Testing with CueTools revealed that the second one is correct:
(CRC32 = dBpoweramp's CRC, W/O NULL = EAC's CRC) Track Peak [ CRC32 ] [W/O NULL]
01 67.2 [308AB1B1] [1EAACC78]
Does anyone know where the difference comes from? Doesn't CRC testing with "-f crc" use CRC32 (since there is no "-f crc32")?
"-f crc" produces Adler-32 (https://en.wikipedia.org/wiki/Adler-32) checksum, see crc muxer (https://ffmpeg.org/ffmpeg-formats.html#crc-1). It should produce the same thing as "-f streamhash -hash adler32".
"-f streamhash -hash crc32" produces CRC-32-IEEE.
Thanks a lot for the clarification and the reference to the documentation. Much appreciated!
Had a strange case using ffmpeg. Just fooling around I wrote a script that would read the flac md5 with metaflac & compare it to the one ffmpeg produced. Out of about 5800 flacs I only had one fail.
The flac md5 was 47CC7F68A233432F2727ABD10B9A99A6 and ffmpeg's was E7D6F591C53C1673C36D3558B542D5C0. I verified the file with foobar2000 & it passed. Then I removed all tags & checked again. Same results. I converted it to wave. Same results.
Then I converted it to WavPack & checked it's internal md5. It was the same as the flacs. I've reencoded it to flac more than once & nothing changes. I also checked the wavpack file with ffmpeg & it gave the same results.
The only conclusion I can draw is not to trust ffmpeg completely.
Could it be those 5799 FLACs were 16 bit and that one that failed was different? Than that's the cause: ffmpeg calculates the md5sum of the 16-bit audio unless directed otherwise.
Got it fixed but I don't really understand what was wrong. Anyway I dropped it into audacity & then exported it as a flac. Now it has a completely different md5 DEA45A5A006F8EB7335B1417CA4FA61B but everything shows the same one. It always played ok & I never would have found it if I hadn't been playing around.
I made no changes in audacity just loaded it & then exported it. When I do a bit compare in foobar with the 2 files this is what I got.
Differences found in compared tracks.
Zero offset detected.
Comparing:
"Z:\foobarStats\m4a\_.flac"
"E:\01-Ipod Music Files\Ipod.160.Songs\_.flac"
Compared 8645626 samples.
Differences found: 17273054 values, 0:00.000021 - 3:00.117188, peak: 0.000298 (-70.51 dBTP) at 0:47.687333, 1ch
Channel difference peaks: 0.000298 (-70.51 dBTP) 0.000290 (-70.76 dBTP)
File #1 peaks: 0.440338 (-7.12 dBTP) 0.441925 (-7.09 dBTP)
File #2 peaks: 0.440208 (-7.13 dBTP) 0.441985 (-7.09 dBTP)
Detected offset as 0 samples.
Total duration processed: 3:00.117
Time elapsed: 0:00.788
228.48x realtime
They both still pass with verify integrity in foobar.
Comparing:
"Z:\foobarStats\m4a\_.flac"
"E:\01-Ipod Music Files\Ipod.160.Songs\_.flac"
Compared 8645626 samples.
Differences found: 17273054 values, 0:00.000021 - 3:00.117188, peak: 0.000298 (-70.51 dBTP) at 0:47.687333, 1ch
Channel difference peaks: 0.000298 (-70.51 dBTP) 0.000290 (-70.76 dBTP)
Just loading and re-saving in Audacity can introduce dither differences, and that's what this looks like since almost
all the samples are different.
There may be an option to turn that off, but anyway you don't want to keep
that copy.
I'm sure this is somehow a case of operator error. I probably ripped this 15 or more years ago. Who knows what I've done to it since then I don't even really like the song. It was more a puzzle to solve than caring about the results.