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: ALAC and AIFF conversion getting different MD5 checksum (Read 1955 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

ALAC and AIFF conversion getting different MD5 checksum

Hi,

I'm new to this forum, as you might have guessed I'm on a Mac. I'm in the process of potentially re-importing my entire CD library back into my Mac, as I want to re-tag a few CDs. I've also started to use XLD, and I like the idea of using AccurateRip. XLD has already found a couple of discs that have read errors, and I'm wondering if my old iTunes rips from years ago might have the odd error. So to be safe, I want to start again.

Up until this point, I have just used iTunes and ALAC, as I want to have, of course, the best rip I can. As drive space is cheap now, I was thinking about just using AIFF files. You may ask, Why not just use ALAC? I did some testing, and I need someone who knows more about this than me to explain something for me.

My question is: I imported a CD track using XLD and saved as AIFF and did the following to test; note I did this with no network connection to ensure no meta DATA was embedded into the file during conversions within iTunes:

1. After importing the AIFF into iTunes, checked the file with MD5 and recorded the result.
2. Then I converted that same file to ALAC inside iTunes and did another MD5 on that ALAC file.
3. Convert the ALAC file back to AIFF and once again noted the MD5 result.

I repeated this process a few times, and what I found is that the AIFF file's always had the identical MD5 result's as I would expect; what I wasn't getting was the same MD5 result for each conversion to ALAC. Every ALAC MD5 result was different, never the same.

Can someone explain why that would be? I would assume the algorithm to create the ALAC file would be the same for each conversion. Why does it change for ALAC? Im sort of leaning even more towards using AIFF as I don't want conversion errors during playback. If iTunes can create a different file on the AIFF file during encoding, what's to say the decoding would not have an error during playback?

Or have I gotten this all wrong?

Can anyone explain what might be going on, thanks in advance.

Re: ALAC and AIFF conversion getting different MD5 checksum

Reply #1 –
That's because mp4 container saves creation time / modification time in some boxes such as mvhd or  tkhd.

Re: ALAC and AIFF conversion getting different MD5 checksum

Reply #2 –
Quote from: raymate on
I've also started to use XLD, and I like the idea of using AccurateRip. XLD has already found a couple of discs that have read errors, and I'm wondering if my old iTunes rips from years ago might have the odd error. So to be safe, I want to start again.
Re-ripping? It is possible to retro-check your rips for AccurateRip match. https://www.dbpoweramp.com/perfecttunes.htm has also been ported to macOS. (This is from the creator of AccurateRip.)
It is sometimes even possible to repair rips using CUETools, but I don't know if you can get it working on appleware. (Linux users have gotten to work under Mono.) It also applies tags with AccurateRip ID, result, and CDTOC.

(Identifying a rip presumes that iTunes rips to correct track lengths. I think it does? At least it seems possible to convert from iTunes tags to CDTOC in most cases. It is not obvious to get track lengths correct, Windows Media Player does not.)


Quote from: raymate on
1. After importing the AIFF into iTunes, checked the file with MD5 and recorded the result.
2. Then I converted that same file to ALAC inside iTunes and did another MD5 on that ALAC file.
3. Convert the ALAC file back to AIFF and once again noted the MD5 result.

I repeated this process a few times, and what I found is that the AIFF file's always had the identical MD5 result's as I would expect; what I wasn't getting was the same MD5 result for each conversion to ALAC. Every ALAC MD5 result was different, never the same.

As nu774 explained, there are "internal metadata" in the MP4 container, not viewable to you. I don't know if similar applies to CAF. (That is, what if you try to convert to ALAC-in-CAF?)

The right thing is not checksumming the file, but checksumming the audio part - and using a format that protects against errors by muting them upon playback. Sane lossless formats do offer that. FLAC by default, WavPack and TAK have good protection and optional MD5 - then Monkey's a slightly different solution. More at https://hydrogenaud.io/index.php/topic,122094.0.html , which lags a couple of flac versions and refalac versions.
Unfortunately for you, Apple is peddling a format that is not so sane - but that doesn't say uncompressed is better.

There are hacks to get audio MD5 from uncompressed or ALAC too: http://ffmpeg.org/ffmpeg-all.html#md5-1 (note, there will be issues with audio that isn't 16 bits). That won't protect your playback chain by muting, but you cannot count on that anyway.

Do you have any utility that can bit-compare audio from two formats? If so, you can keep a backup in a better format if ALAC is the only thing supported by your player application.

Re: ALAC and AIFF conversion getting different MD5 checksum

Reply #3 –
Quote from: nu774 on
That's because mp4 container saves creation time / modification time in some boxes such as mvhd or  tkhd.

Thank you; that makes sense. I wasn't thinking about other DATA being packaged with the audio, and of course, the time would be changed for each pass, thus a different MD5

Mystery solved.

Re: ALAC and AIFF conversion getting different MD5 checksum

Reply #4 –
Quote from: Porcus on
Quote from: raymate on
I've also started to use XLD, and I like the idea of using AccurateRip. XLD has already found a couple of discs that have read errors, and I'm wondering if my old iTunes rips from years ago might have the odd error. So to be safe, I want to start again.
Re-ripping? It is possible to retro-check your rips for AccurateRip match. https://www.dbpoweramp.com/perfecttunes.htm has also been ported to macOS. (This is from the creator of AccurateRip.)
It is sometimes even possible to repair rips using CUETools, but I don't know if you can get it working on appleware. (Linux users have gotten to work under Mono.) It also applies tags with AccurateRip ID, result, and CDTOC.

(Identifying a rip presumes that iTunes rips to correct track lengths. I think it does? At least it seems possible to convert from iTunes tags to CDTOC in most cases. It is not obvious to get track lengths correct, Windows Media Player does not.)


Quote from: raymate on
1. After importing the AIFF into iTunes, checked the file with MD5 and recorded the result.
2. Then I converted that same file to ALAC inside iTunes and did another MD5 on that ALAC file.
3. Convert the ALAC file back to AIFF and once again noted the MD5 result.

I repeated this process a few times, and what I found is that the AIFF file's always had the identical MD5 result's as I would expect; what I wasn't getting was the same MD5 result for each conversion to ALAC. Every ALAC MD5 result was different, never the same.

As nu774 explained, there are "internal metadata" in the MP4 container, not viewable to you. I don't know if similar applies to CAF. (That is, what if you try to convert to ALAC-in-CAF?)

The right thing is not checksumming the file, but checksumming the audio part - and using a format that protects against errors by muting them upon playback. Sane lossless formats do offer that. FLAC by default, WavPack and TAK have good protection and optional MD5 - then Monkey's a slightly different solution. More at https://hydrogenaud.io/index.php/topic,122094.0.html , which lags a couple of flac versions and refalac versions.
Unfortunately for you, Apple is peddling a format that is not so sane - but that doesn't say uncompressed is better.

There are hacks to get audio MD5 from uncompressed or ALAC too: http://ffmpeg.org/ffmpeg-all.html#md5-1 (note, there will be issues with audio that isn't 16 bits). That won't protect your playback chain by muting, but you cannot count on that anyway.

Do you have any utility that can bit-compare audio from two formats? If so, you can keep a backup in a better format if ALAC is the only thing supported by your player application.

Thank you; that gives me some things to work on. I was looking at DBpoweramp but decided to use XLD. I think moving forward I will archive in AIFF so that I can convert them to anything I like. Now that I understand the ALAC contains date and time data, I now see why my MD5 tests were flawed. Thanks again.

Re: ALAC and AIFF conversion getting different MD5 checksum

Reply #5 –
You can convert FLAC/ALAC/WavPack to anything you like, and keep the metadata ... also Monkey's and TAK if you trust ffmpeg's 3rd-party decoder. And, all those except ALAC do offer built-in checksums that will detect errors upon playback.

Uncompressed formats don't.

Going untagged? Not a good idea. You might lose the opportunity to retro-verify by the AccurateRip checksums - although, I am not sure: does XLD create EAC-style logs that CUETools can use to identify it?