MP3-Library doesn't like some of MediaSource's ID3 t

Question

Just a tip for MP3-Library users:
On rare occasions, MediaSource 3.30.2 will produce an ID3 tag that MP3-Library doesn't like. (This is pretty rare -- out of 45 tracks I updated the tags on, 6 did this.) This results in the file being displayed as corrupted. If you select "Analyze/Fix MP3," it finds a frame or two with random specifications at the very start of the file, followed by a single bad frame, and then all good frames.
If you check all availiable fix options (delete selected frames [check the junk and bad ones], delete garbage before st frame, delete garbage after last frame), it lops about 30 bytes off the end of the tag/header and takes a few good frames off the start of the file.
According to MP3Utility and EncSpot, there's nothing wrong with the files, and they play just fine in MediaSource, Winamp, and on the Zen. The header data that was destroyed doesn't affect the ID3 data. It only seems to have removed the Xing header. (No, I don't use Xing. LAME 3.97 alpha puts Xing-compatible headers on its VBR files.)
The following are the summary data that MP3Utility shows. This is from the original file, fresh out of LAME:
<i>File size: 3,63,232 bytes
Offset to first frame header: 2,630 bytes
MPEG version .0; Layer III
Bitrate: VBR (Xing); Sample rate: 44,00 Hz
Channel mode: Joint stereo
Private: No; CRCs: No; Copyrighted: No
Original: No; Emphasis: None
Frame size: ,52 samples/frame
Frame length: 47 bytes/frame (unpadded)
Pad size: byte(s)
Estimated frames: 8,945
Estimated time: 3:54 (234 secs.)</i>
This is after importing the file into the PC Music Library and clicking "Update Tag." I didn't modify anything, just told it to re-write the ID3 tag:
<i>File size: 3,63,232 bytes
Offset to first frame header: 2,630 bytes
MPEG version .0; Layer III
Bitrate: VBR (Xing); Sample rate: 44,00 Hz
Channel mode: Joint stereo
Private: No; CRCs: No; Copyrighted: No
Original: No; Emphasis: None
Frame size: ,52 samples/frame
Frame length: 47 bytes/frame (unpadded)
Pad size: byte(s)
Estimated frames: 8,945
Estimated time: 3:54 (234 secs.)</i>
And this is after MP3-Library "fixed" it:
<i>File size: 3,629,325 bytes
Offset to first frame header: 2,600 bytes
MPEG version .0; Layer III
Bitrate: 224 kbps; Sample rate: 44,00 Hz
Channel mode: Joint stereo
Private: No; CRCs: No; Copyrighted: No
Original: No; Emphasis: None
Frame size: ,52 samples/frame
Frame length: 73 bytes/frame (unpadded)
Pad size: byte(s)
Estimated frames: 4,96
Estimated time: 2:0 (30 secs.)</i>
No, MP3-Library DIDN'T chop 04 seconds off the file. The estimated frame count and length are WRONG because the Xing header was destroyed by MP3-Library. This header would normally tell MP3Utility how long the file really is, otherwise it takes the bitrate of the first frame and extrapolates that over the file length. (Without this header, many programs' progress sliders won't be as accurate.)
So, if MP3-Library tells you a file is corrupted after going through MediaSource and the file wasn't corrupted before, DON'T fix it. You'll only make things worse. I've never seen MediaSource or my Zen actually damage a file.
(At first, I told it to fix 'em. Now I'm going through and restoring the backups it made.)

Answer 1

i have used mp3-libary many times before because it said a large amount of my collection was corrupted. but it seams to be better.as i havent used media source to import them so i think they may have actually be corrupt. but interesting findings.