I am using MM 2.2.2.781.
After scanning my entire MP3 library, and then choosing to "synchronize tags", I discovered that all my VBR (variable bit rate) encoded mp3 files have suddenly had their bitrate tags changed to only 32!!! Furthermore, their lengths have now expanded grossly (I suspect because track length was determined by dividing file size by a now much smaller bitrate). I now realize that it was foolish for me to have run "synchronize" without fully understanding what it might do, but nevertheless, I now have a big problem: a huge library of mp3s with incorrectly tagged lengths and bitrates. Any suggestions on how I can fix this?
From reading other posts here, it seems to me that this problem was caused because MM cannot correctly read the header for VBR files (is this correct?)
Any way to fix VBR mp3's corrupted by MM?
Moderator: Gurus
Just a question, are these files downloaded from a P2P network (I have seen before that files show at 32 bits with long times, generally they don't play well), or did you rip them yourself. If you ripped them yourself, with which program did you rip?
I'm not sure if MM has a problem with VBR files in the latest release. Can you include more information about OS and MM version as well?
I'm not sure if MM has a problem with VBR files in the latest release. Can you include more information about OS and MM version as well?
Download MediaMonkey ♪ License ♪ Knowledge Base ♪ MediaMonkey for Windows 2024 Help ♪ MediaMonkey for Android Help
Lowlander (MediaMonkey user since 2003)
Lowlander (MediaMonkey user since 2003)
-
Guest
I ripped most of the files myself using a wide variety of tools, including Audiograbber. I am using MM 2.2.2.781 on Windows XP (SP 2). They *definitely* were not ripped at a constant bitrate of 32kbps. The bitrate and length tags were all correct before using MM.Lowlander wrote:Just a question, are these files downloaded from a P2P network (I have seen before that files show at 32 bits with long times, generally they don't play well), or did you rip them yourself. If you ripped them yourself, with which program did you rip?
I'm not sure if MM has a problem with VBR files in the latest release. Can you include more information about OS and MM version as well?
When you open the songs in other applications do they still report the correct bitrate and length?
Am I correct when I say that MM at one time showed the correct bitrate and length? (After syncing tags they became erroneous?)
Am I correct when I say that MM at one time showed the correct bitrate and length? (After syncing tags they became erroneous?)
Download MediaMonkey ♪ License ♪ Knowledge Base ♪ MediaMonkey for Windows 2024 Help ♪ MediaMonkey for Android Help
Lowlander (MediaMonkey user since 2003)
Lowlander (MediaMonkey user since 2003)
-
MusicToedSloth
No, when I open the mp3s in other applications (such as iTunes), they now report the wrong, lower bitrate and longer song length.Lowlander wrote:When you open the songs in other applications do they still report the correct bitrate and length?
Am I correct when I say that MM at one time showed the correct bitrate and length? (After syncing tags they became erroneous?)
I'm not sure whether MM ever showed the correct VBR rates for those tracks because I didn't have the bitrate column displayed in MM prior to running "synchronize tags".
Does anyone know if there are other tools besides MM that might be able to correctly read my track's bitrates and song lengths and add them back to the header? It would be great if MM could do this, but so far no luck . . .
I can say that MM is very good at calculating bitrate and total length of track either of CBR or VBR mp3s even in case of damaged headers. However, if VBR file has its header damaged, the correct length cannot be reported without scanning the whole file which MM doesn't (and probably no other application does).
As for damaging the mp3s, I don't think MM has done this, it is very careful in how mp3 files are processed. My best guess is that there already were ID3v2 tags present and they were somehow damaged (maybe they continued to mp3 audio data frames...). Maybe you can e-mail me some shorter track as an example so that I can try to guess what has happened.
Jiri
As for damaging the mp3s, I don't think MM has done this, it is very careful in how mp3 files are processed. My best guess is that there already were ID3v2 tags present and they were somehow damaged (maybe they continued to mp3 audio data frames...). Maybe you can e-mail me some shorter track as an example so that I can try to guess what has happened.
Jiri
Fix found!
i realize this is an old post but i did find a solution.
first of all, i don't think it's MM's fault that this is happening... but according to my research... the VBR file shows up with a very long length and a very small bit rate when the VBR header is missing or damaged.
There's a program you can use which will repair/reconstruct it, and it's worked for the handful of files that I had which had this problem. You just drag and drop the file (or folder), repair it, and MediaMonkey automatically recognizes the updated time and bit rate.... Very painless.
the name of the program is VBR Header Maker,
you can get it here.
first of all, i don't think it's MM's fault that this is happening... but according to my research... the VBR file shows up with a very long length and a very small bit rate when the VBR header is missing or damaged.
There's a program you can use which will repair/reconstruct it, and it's worked for the handful of files that I had which had this problem. You just drag and drop the file (or folder), repair it, and MediaMonkey automatically recognizes the updated time and bit rate.... Very painless.
the name of the program is VBR Header Maker,
you can get it here.