[F] %_md5audio% changed when writing tags

bug-fixed
#1

I just wrote many thousand sof audio files using the technique described here:

/t/2785/1

The idea was simply disable unicode, then press CTRL+A then CTRL+S and all tags are rewritten without unicode.

Because I'm working with a whole library of music as a security I exported all tags before hand, including the %_md5audio% calculation, and again afterwards.

The idea being that the audio data should be unaffected and hence the %_md5audio% unchanged. Alas for a good many files the %_md5audio% value did change!

There are more songs affected than I can easily compare by listeningv, but a spot check reveals no audible change to the file.

Why is it that writing tags affects the MD5 hash of the audio part. I am forced to suspect that either:

  1. MP3 tag is altering the audio unintentionally!
    OR
  2. MP3 tag is calculating the MD5 hash on the audio part incorrectly.

Logic would suggest that if only the tags are altered and not the audio part, that the MD5 hash of the audio should be unchanged and this is the main aim of looking at that hash!

Is there a bug here? Or is it an interpretation problem?

#2

Sorry, I can't reproduce this here.

Best regards,
Florian

#3

That's a shame, as it's most disconcerting. I suspect it's a bug in the MD5 audio hash calc not corruption of the actual audio data as spot samples play fine.

Not sure how Ic an help tor eproduce it, except perhaps to send you one of the files affect in its before and after state. WOuld that help? if so I'll try and dig one up (I believe I can, but am not 100% sure) - I'll only go to the effort if it's useful to you Florian).

#4

Yeah, maybe a set of affected files would reveal the issue.

#5

O.K. I have two. A MP3 and WMA both displaying the symptom, just selected from a many dozens perhaps hundreds affected. I reproduced the effect reliably. It's a zip of about 5 mMB with 4 audio files and one exported .csv file to illustrate.

The two AFTER files are greted by MP3tag 2.36a by ensuring is in all field sof the Tag Panel (CTRL+Q) then exporting tags (CTRL+E). The selected tags should be obvious but the key one is the last column which is "%_md5audio%".

The only other difference bweteen the versions BEFORE and AFTER is that unicode was disabled in MP3tag between (i.e. AFTER is tagretted to be unicode free version opf BEFORE).

I hope this helps.

(ADDENDUM: Attachment failed, will upload as soon as I can or if FLorian suggest a better way to ge 5MB to him).

#6

Email or one of the free services to send files.

#7

Done! Let me know what you find Florian. I'm curious.

#8

For MP3 files, the bug was due to an ID3v2 tag which caused an internal exception. Therefore the ID3v2 tags wasn't read completely and wasn't ignored at calculating the MD5 hash.

Computing the MD5 hash for the audio part is only available for files with "trivial" tag formats (e.g. ID3v1, ID3v2 and APEv2). WMA, Vorbis, FLAC and MP4 have tagging formats specified and integrated with the file format which makes it difficult to compute the MD5 hash for the audio part.

That's why the %_md5audio% placeholder is limited to MP3, MPC, APE, TTA and WV. I'll add this information to the help file.

Thanks for reporting!

Best regards,
Florian

#9

Thank you for the diagnosis! As I suspected it's a bug in hoe the Audio
hash was calculated and not a major concern.

I noticed however by the by in those exports just before I sent them to you, that the WMA example seems to have been resampled as well (different bitrate reported). Given it was purely a CTRL-S with in all tags for a unicode strip that caught my eye. I hadn't noticed it before, and the sample rate changed from 32000 to 44100.

Is there some surreptiitous audio resampling going on? Or a fault in the WMA tag read/write process?

Also, I'm curious about how the ID3v2 tag caused an exception? Was it a bad tag at my end? Or just an aceptable tag not handled well by MP3tag? If the latter, might this have affected other files (I did this one a LOT of files and they sit there with a backup on another drive, waiting for me to say "yay, I'm happy that the unicode strip is O.K. and didn't trash some of my music ;-).

I guess it would be nice if MP3tag caught such exceptions and reported them in the GUI somehow.

Thanks again for the diagnosis!

#10

Again, I can't reproduce this (even with the two sample files you've sent me).

It was due to an empty USLT frame. I've changed the code to be more tolerant at this point.

Best regards,
Florian

#11

That's interestig. I'll try again when I'm back home (time zones mean you're catchig me at work). Would be odd to imagine it's machine specific, more likley an operational (user) error at eithe rmy end or yours in producing the result ;-). But who knows? I'll try and reproduce and let you know, and perhaps find another file exhibitig same (I have many ;-).