So far I have used mp3val to find and fix errors in my MP3s. Now I've scanned them with MP3 Diags and a lot of them have the "bc" error.
Here is what MP3 Diags says:
MPEG-1 Layer III, Stereo, 44100Hz, 320000bps, CRC=no;
3:04, MPEG-1 Layer III, Stereo, 44100Hz, 297329bps VBR, CRC=no, frame count=7066; last frame located at 0x69d6b0
And here is what mp3val says:
7067 MPEG frames (MPEG 1 Layer III), +ID3v1+ID3v2+APEv2, Xing header
If it is off then it is always off by exactly one frame (MP3 Diags seems to always have one more than mp3val). I have no idea who is correct or if this is important but it's hurting my OCD that I can "fix" the file in one program only to show up as problematic in the other :)
I didn't file an issue because I don't know if there are just two different ways to count and none of them is "more correct" than the other.
I can provide you with example files if you like.
Anyway: Thanks for your continued work on this marvelous piece of software!
It would be best if you could provide a file that has this issue, so I don't have to guess. (Put it somewhere on the web or mail it to email@example.com )
I got the file and I think MP3 Diags does the right thing. I'm not 100% sure, because there seem to be no official specifications. I used reverse engineering to determine what to do in this case and in some other cases.
The question is whether to include the Xing header in the frame count. AFAIK, it should not be included, so I report a mismatch in this case. This decision was made based on the fact that most MP3s that I've seen are like this.
I'm not aware of any serious consequence of this mismatch, so you probably could just hide this note in MP3 Diags. (However VBR Repair / Rebuild transformations will still change the frame count if they think they should.)
If somebody does more research on this issue and it turns out that the frame count is wrong, I might add some options to deal with this. However, LAME is one of the most used encoders, and LAME's way is to exclude the header, so this has to be supported as well, even if it's wrong.
(The most relevant page that I've found on this topic is .)
Thank you very much for your analysis and detailed report. I suspected it to be something like that. Well I guess it's time to dump mp3val in favor of MP3 Diags anyway :)
LOL!! "it's hurting my OCD" … mine too!
MP3 Diags and foobar seem handle in the same manner so I've voted mp3val out.
ciobi07 - thanks for the great utility.
If you repair the files with foobar2000 (right click \ utilities \ fix vbr mp3 header)
Both programs seem to pass the check. so maybe foobar2000's method is ideal? (also it doesnt remove the ripper profile like v0 or v2 doing it this way, which mp3diags does on some of the transforms)
The reason MP3 Diags removes the ripper profile and everything else in the Xing header is that if the frame count is wrong then other things might be wrong as well, and it doesn't bother to check if it is so. Something a bit smarter could be implemented (e.g. if the frame count is off by 1, it's quite likely that the other fields are correct) but it doesn't have a high priority on my "to do" list (well, it currently isn't even on the list, but I might add it if more people want it.)
If your files have the "ae" note ("Incomplete MPEG frame at the end of an MPEG stream") you may want to try applying "Pad truncated audio", which in some cases will get rid of the mismatch as well.
Log in to post a comment.