Cutting Off Beginning Of "MP3Packer" Processed Tracks

Post a reply

:D :) :( :o :-? 8) :lol: :x :P :oops: :cry: :evil: :roll: :wink:

BBCode is ON
[img] is ON
[flash] is OFF
[url] is ON
Smilies are ON

Topic review

Expand view Topic review: Cutting Off Beginning Of "MP3Packer" Processed Tracks

Re: Cutting Off Beginning Of "MP3Packer" Processed Tracks

by frankz » Sat Oct 22, 2016 1:38 pm

Next time I have to download something I'll give them "Original," "MP3 Packed" and "VBR Rebuit" to compare. I was more kind of hoping it would ring a bell with someone. More an annoyance at this point because I know how to get around it.

Re: Cutting Off Beginning Of "MP3Packer" Processed Tracks

by Lowlander » Sat Oct 22, 2016 1:16 pm

Cutting Off Beginning Of "MP3Packer" Processed Tracks

by frankz » Sat Oct 22, 2016 12:30 pm


Recent versions (I've tried and of MediaMonkey have developed a bug where it cuts of the first few seconds of "packed" (I'll explain) MP3 files.

When I download a MP3 file from Google or Amazon (or anywhere) that's 320kbps CBR I process it with MP3Packer to strip out unnecessary information and essentially make it into a VBR file. This saves space and had never caused a problem before. It's a lossless process. More info here:

Like I said, it's never caused a problem in MediaMonkey (or any other player / hardware) before. I've got a computer running MM and it plays these files just fine. Some time since that version, though, something changed in the decoding and now the beginnings of these songs are consistently cut off on playback. This happens no matter what special playback features (Skip Silence / Fade in / crossfade, etc) I have turned on or off.

Here's the fun part - I can correct the problem by scanning these files in MP3 Diags ( and running a "Rebuild VBR Data" job on them. After this process, they play fine in versions of MediaMonkey where the problem had previously surfaced. So it looks like the issue is in the way MediaMonkey has possibly changed the way it reads the header data. Maybe more strict than it used to be?

The trouble with this is that I've got - literally - hundreds of these types of files and no way to know which is which until they screw up on playback. I think I've fixed most of them, but I have no way to know.

If I come across a file that causes this I'll update with the header data from MP3 Diags before and after, but I'm not sure how likely that is at this point. Hopefully a developer will read this and know what changed in the interim and how to correct it.