Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: "Fix VBR MP3 Header" on CBR files? (Read 21271 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

"Fix VBR MP3 Header" on CBR files?

The verify file integrity tool gives me a lot of "Warning: Reported length is inaccurate" results on my mp3 files. This is strange because I encoded most of them myself and maintain a checksum database of all my files, so I know corruption is not the issue. I'm assuming it was an old version of the LAME encoder which caused the problem.

I am aware of the "Fix VBR MP3 Header" utility to repair this issue, however, many of the files being flagged are CBR, not VBR. I've also read about a lot of issues with this feature in general (fixing the lengths in foobar but breaking them in another player, etc). I'm just wondering if there are any known problems with using a VBR utility to repair a CBR file, and any other information about what exactly this feature does would be helpful.

"Fix VBR MP3 Header" on CBR files?

Reply #1
I would try to use MP3val on those files instead and see what shows in fb2k afterwards... Should be OK then.
lame -V 0

"Fix VBR MP3 Header" on CBR files?

Reply #2
How about Rebuild MP3 stream?

"Fix VBR MP3 Header" on CBR files?

Reply #3
I would try to use MP3val on those files instead and see what shows in fb2k afterwards... Should be OK then.


Thanks, I'll give this program a try. Scanning the files gives slightly different results, but probably more accurate since it's dedicated to mp3 errors.


How about Rebuild MP3 stream?


I am considering trying this out too, but I'm curious what exactly it does (how the file is affected) and I haven't been able to find much information yet.

"Fix VBR MP3 Header" on CBR files?

Reply #4
CBR files can have VBR headers; it doesn't hurt to "fix" those that don't. Then they'll have one, and the duration will actually be written into the file, rather than being guessed.

"Reported length" is the length reported by fb2k. For a CBR file without a VBR header, this number will be an estimate based on (I think) the file size (minus tags) and the parameters of the first frame. If this estimate is wrong, or if some frames are actually undecodable, then the reported length is going to be deemed "inaccurate" by the verifier.

Some experimentation reveals that the estimate will be always be wrong in this situation (CBR file, no VBR header), because fb2k apparently doesn't account for the 529 samples of decoder delay that it strips during decoding. I consider this to be a bug in foobar2000. It should be reporting durations 529 samples smaller than what it is actually reporting.

That's not to say there maybe aren't other problems with your files

"Fix VBR MP3 Header" on CBR files?

Reply #5
How about Rebuild MP3 stream?
I am considering trying this out too, but I'm curious what exactly it does (how the file is affected) and I haven't been able to find much information yet.
As noted in the status-bar description of the menu option, it just strips everything except the audio stream from the file and then rewrites it with a new header and recreated ID3 tag(s). Try it on one or a few files or copies thereof if you’re unsure, but I’m confident it won’t/can’t cause anything negative.

"Fix VBR MP3 Header" on CBR files?

Reply #6
Thanks for the information guys, I've managed to clean up all but two of the files which will have to be re-encoded again from scratch.

Some experimentation reveals that the estimate will be always be wrong in this situation (CBR file, no VBR header), because fb2k apparently doesn't account for the 529 samples of decoder delay that it strips during decoding. I consider this to be a bug in foobar2000. It should be reporting durations 529 samples smaller than what it is actually reporting.


This explains a lot. After some testing, I realized foobar always reports the length as being inaccurate for some files, even if other programs find no errors. The only way to "fix" the length is to use the "fix VBR header" which then causes other programs to detect errors. Hopefully this bug will be fixed eventually.

"Fix VBR MP3 Header" on CBR files?

Reply #7
Some experimentation reveals that the estimate will be always be wrong in this situation (CBR file, no VBR header), because fb2k apparently doesn't account for the 529 samples of decoder delay that it strips during decoding. I consider this to be a bug in foobar2000. It should be reporting durations 529 samples smaller than what it is actually reporting.

It's not correct to think that the encoder delay is always 529, in fact it varies between different encoders.

(I'll posit though the reason the length is inaccurately reported on an otherwise error-free mp3 is related to the either encoder and/or padding. A fun exercise would be cropping the encoder delay and/or padding of an mp3 with the length error and seeing if the remaining length matches the reported length.)

I have mp3s like this and I don't bother fixing them, the error is merely cosmetic AFAIC, foobar2000 decodes the file the same either way.

"Fix VBR MP3 Header" on CBR files?

Reply #8
How about Rebuild MP3 stream?


I am considering trying this out too, but I'm curious what exactly it does (how the file is affected) and I haven't been able to find much information yet.


Beware that if the file is corrupted, then foobar2000 might crop away the corrupted part (or the rest of the file). I would guess you won't notice if playing back with foobar2000 – my experience is that fb2k does the same as it would when playing. However, other players may react differently (corrupted mp3's are, techically, not mp3's – there is no standard way to handle them, one player might handle a certain error better or worse than another, and I have no idea whether fb2k is any more or less clever than any other).

There is a tool I sometimes use, namely mp3packer: http://wiki.hydrogenaudio.org/index.php?title=MP3packer
It repacks the mpeg stream, losslessly, and can also convert losslessly between VBR and CBR.  Using brute-force compression it can sometimes even reduce your mp3's with a few percents. Which saves you a few cents worth of storage ... hardly worth it, unless your portable player is just a coupe of percent too small for your collection. But I've found it instructive just to see how (in)efficient CBR 320 is. Those files often compress down to 290 to 300 VBR.


But ... what harm does an inaccurately reported length really do? OK, I've downloaded (oops, did I say that?) bootleg recordings with extremely wrong lengths (like, many times the true length), and of course it might be annoying to see Cage's 4'33" displayed as 4:32 ... but AFAIK, foobar2000 will play them the same?

"Fix VBR MP3 Header" on CBR files?

Reply #9
But ... what harm does an inaccurately reported length really do? OK, I've downloaded (oops, did I say that?) bootleg recordings with extremely wrong lengths (like, many times the true length), and of course it might be annoying to see Cage's 4'33" displayed as 4:32 ... but AFAIK, foobar2000 will play them the same?


Absolutely. I've concluded that it's best to simply ignore the inaccurate length warning. "Fixing" it seems to cause more problems than it solves.

"Fix VBR MP3 Header" on CBR files?

Reply #10
It's not correct to think that the encoder delay is always 529, in fact it varies between different encoders.

Encoder delay is the delay added by the encoder. Like padding, encoder delay is silence (or junk) samples actually encoded into the MP3. It's not normally removed during playback or conversion, unless the # of samples is written into a LAME tag.

But I was talking about decoder delay, the delay added by the decoder to the output stream as the MP3 is processed. The decoder used by foobar2000 has a 529-sample delay, and foobar2000 always strips these samples during playback or conversion. When estimating the duration of CBR files, though, it's not subtracting those samples.

"Fix VBR MP3 Header" on CBR files?

Reply #11
It's not correct to think that the encoder delay is always 529, in fact it varies between different encoders.

Encoder delay is the delay added by the encoder. Like padding, encoder delay is silence (or junk) samples actually encoded into the MP3. It's not normally removed during playback or conversion, unless the # of samples is written into a LAME tag.

But I was talking about decoder delay, the delay added by the decoder to the output stream as the MP3 is processed. The decoder used by foobar2000 has a 529-sample delay, and foobar2000 always strips these samples during playback or conversion. When estimating the duration of CBR files, though, it's not subtracting those samples.


Sorry I missed that. Have you raised the issue with Peter?

"Fix VBR MP3 Header" on CBR files?

Reply #12
This being the fb2k support forum, I assumed he was paying attention.

"Fix VBR MP3 Header" on CBR files?

Reply #13
So who do I contact about this, exactly?

To restate—

Bug: Headerless CBR MP3 duration estimate off by 529 samples

Description: foobar2000 properly strips decoder delay (529 samples) from MP3s during playback, but for certain CBR files, foobar2000 doesn't strip these samples from the duration estimate as shown in the properties window. The affected files are CBR files without a VBR header, or, I assume, those with a VBR header that contains no duration info. Where this is most easily noticed is in the file integrity verifier, which compares the estimated duration to the actual playback duration. For these CBR files, the comparison is always unequal (off by 529 samples), so they're misreported as problematic.

Proposed solution: I believe if fb2k were to simply reduce the estimated duration of this class of CBR files by 529 samples, the problem would be solved.

"Fix VBR MP3 Header" on CBR files?

Reply #14
Changed in version 1.3.9 beta 4, please test.
Microsoft Windows: We can't script here, this is bat country.

"Fix VBR MP3 Header" on CBR files?

Reply #15
Thanks!

Well, it's weird. With some files it's better now, with others it's actually worse.

I have a 192 kbps MP3 with 3516593 bytes, 5617 complete frames + 1 incomplete frame at the end. There are no tags. It was encoded by the FhG ACM in 2001. There are no header errors, and the last frame is actually valid (per mp3guessenc) but is only 351 bytes instead of 626.

The entire file decodes and converts to WAV with no errors showing in the console. The WAV has 6470255 samples, i.e. 5617 complete frames minus 529 samples. My expectation is that foobar's duration estimate will match this.

foobar 1.3.7 is estimating the duration based on 5617 complete frames. foobar 1.3.9b4 is estimating the duration based on 5609 complete frames minus 529 samples. If I add 275 zero bytes to the end to fill up the truncated frame, 1.3.9b4 estimates the duration based on 5610 complete frames minus 529 samples.

So it seems you are losing 8 frames somewhere in the new calculation.

"Fix VBR MP3 Header" on CBR files?

Reply #16
I would try to use MP3val on those files instead and see what shows in fb2k afterwards... Should be OK then.

Tested with this tool and three podcasts, 1.3.8 shows all three wrong, 1.3.9 beta 4 shows only the last one wrong, same as MP3val.

"Fix VBR MP3 Header" on CBR files?

Reply #17
The old version presumes that in a CBR file all frame sizes are equal - which seems to be valid for FhG ACM case.

The new version presumes that in a CBR file, total bitrate of the file matches the nominal bitrate of the first encountered frame; actual frame sizes vary +-1 byte. This is valid for the file I was testing on, apparently encoded by iTunes.

Determining MP3 file duration essentially requires reading through the whole file to be sure. Or using a precalculated value stored in a header.
Microsoft Windows: We can't script here, this is bat country.

"Fix VBR MP3 Header" on CBR files?

Reply #18
Ah, I didn't realize some encoders don't pad out frames as needed.

The problem though is that the file integrity verifier is saying there's something wrong with these files. I think it should do the old & new calculation and consider the file OK if it matches either one.