Tagging .m4a alters CRC value produced by dBpoweramp's "Calculate Audio CRC" in some cases

I am using Mp3tag v3.00 to tag .m4a audio files and have noticed that the CRC32 of the audio data (note: I am not talking about the entire file's CRC32, I only mean the audio data which excludes the file metadata etc.) is different after tagging to what it was originally.

If it's significant, I am using dBpoweramp's "Calculate Audio CRC" encoder to calculate the checksums. I have never known this plugin to malfunction before, after thousands of uses, so I trust it.

Before tagging the .m4a files I notice that, according to Mp3tag, the contained tag before I make any alterations is "MP4 (MP4 Nero)" and after alterations it is now "MP4 (MP4)".

Regardless of how big or small the tag alteration is, or even if I select the "Optimize MP4" feature in Mp3tag without altering the tags, the resulting files all have the same audio checksum. It simply seems that any kind of change to the file changes the audio data in the same way.

I am very reluctant to proceed with tagging these files unless I am confident the audio data is unaffected. If Mp3tag is not capable of achieving this, please can someone suggest an alternative tool that will let me achieve this? If this not possible at all - with any tool - then can someone please explain why this is the case?

Thanks for any help.

I can't say for sure what is causing the CRC mismatch, but I'm fairly confident that Mp3tag doesn't change the audio data.

To give you a definite answer, I'd need to analyze this in detail. Can you please provide an example file which, when I save it in Mp3tag, shows this behavior?

My current investigation shows that there is gapless information in the original Nero tag which gets removed when Mp3tag writes the file. Please note, that this doesn't mean the audio data is modified.

When saving the tag with latest foobar2000, the Nero tag is also removed, but foobar2000 creates an ITUNSMPB field that is Apple's way of representing gapless information.

If I copy over that field to the tags of the Mp3tag tagged file, dBpowerAmp's "Calculate Audio CRC" encoder shows the same value as the original file.

This implies two things:

  1. dBpowerAmp's "Calculate Audio CRC" seems to be taking the gapless information into account when calculating the audio CRC.
  2. Mp3tag does not alter the audio data itself, but drops the gapless information from the Nero tag when removing this tag upon saving.

Very interesting, I am a little disappointed about dBpoweramp's crc check including this otherwise irrelevant data, even if only for this uncommon tag format, so I'll bear that in mind in future.

Otherwise, I suppose the matter is closed, unless you have any further ideas?

I trust your conclusion about Mp3tag not affecting the audio data, but to be on the safe side I'll continue to use the neroAacTag tool if I deal with .m4a again. I like to do CRC32 checks with pretty much any operation I perform on an audio file, so if after using Mp3Tag on an Nero encoded .m4a the checksum will change (even if not destructively) I won't know if any other unexpected error occurred.

Anyway, thanks for looking into the matter! Mp3tag is a great tool and I appreciate your helpful responses.

EDIT:

I don't suppose you know of any other tools for audio CRC32 checks, do you? Something more reliable than the dBpoweramp one.

Just to complete the picture:

dBpowerAmp's "Calculate Audio CRC" is acting as an encoder here, i.e., it gets fed the PCM audio the decoder produced. It doesn't look at the raw bits inside the file but produces the CRC based on the decoded data. This also includes any adjustments as a result of gapless playback information.

I'm not aware of any other tools for checking audio via CRC. I think FLAC has this builtin as per-frame CRCs and overall MD5 for the decoded audio, so I guess I'd use a format like that to ensure the integrity of my library. WavPack does this too, IIRC.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.