I'm writing an id3v2 tagging library in python and have been using the audioSha1 field to verify that I hadn't messed up and overwrote some of the audio content in my files.

I found that in some cases I was getting two different audioSha1's even though if I decoded the files into wav's I got the exact same file.

orig file (no id3v2 or id3v1 tag)

'audioSha1': 'JXCX632A5KZZGPX3ZQ7ZHN7UUUZG9WZ2'

'vbr': 0 'length': 5410862

'first20': 'FFFB90440000029975B480C2137240E1E6901926'

'bitprint': '3YJY9MY2PSSXWGCKAI63MNH2DMZFESP7UARFARKZIJWBWVCKM65XR9CJKU2F9EF8FXHTHKS'

'duration': 339735

'samplerate': 44100

'bitrate': 128

'stereo': 1

'filename': "/artists/Crystal Method/backup/05 - Crystal Method - Comin' Back.mp3"

file with id3v2 tag

'audioSha1': '3YJY9MY2PSSXWGCKAI63MNH2DMZFESP7'

'vbr': 0

'length': 5450463

'first20': '49443303008000023527545045310000000F0000'

'bitprint': '2NDCM36PECHZMEUBS74RV8FJRJ5D2WFUHBUDGDA9P3KEVFP7HD82V8VYFMYTN3UIXQFBIPI', 'duration': 339735

'samplerate': 44100

'bitrate': 128

'stereo': 1

'filename': "/artists/Crystal Method/Vegas/05 - Crystal Method - Comin' Back.mp3"

myers

What software are you using to strip/ad the ID3 tags?

Do you know which software was initially used to create the MP3?

Our 'audioSha1' value is actually calculated by ignoring the clearly-delimited ID3 ranges inside the MP3, rather than by either (1) expanding the audio to WAV; or (2) detecting the exact ranges of valid encoded audio data inside the MP3.

(Either of those approaches would require a lot more sophistication or time from the analysis-pass.)

We've seen MP3s that have harmless junk in them that is neither ID3 info nor valid audio data; unfortunately that junk *is* included in our 'audioSha1' calculation (because only a frame-by-frame audio decode would exclude it). Such junk might cause what you're seeing, but then again, maybe not.

Can you check if this may be the case, perhaps by trying to reproduce the glitch with an MP3 you create with known encoding software?

The audio files I was having problems with all had a partial frame at the end of them.

here is a patch to fix the problem:

--- bitcollider-0.3.4/lib/mp3.c Tue Jul 31 14:49:20 2001
+++ bitcollider-0.3.4.fix/lib/mp3.c     Tue Apr 16 19:37:23 2002
@@ -287,6 +287,9 @@
       buffer = temp;
    }
 
+   if(info->skipSize > len)
+      info->skipSize = len;
+
    /* Pass the bytes we're skipping through the sha function */
    update_audio_sha1(info, buffer, info->skipSize);

Should we do a 0.3.4.1 bugfix release or a 0.3.5 relase including this patch and delirium's video plugin and/or png enhancement?