IPB

Welcome Guest ( Log In | Register )

> foobar2000 Tech Support Forum Rules

Please read foobar2000 Tech Support Forum Rules before posting and comply with all the points.
Failure to provide all the information pointed out in the above document in your post is considered wasting other people's time and in extreme cases will lead to your topic getting locked without a reply.


See also: Hydrogenaudio Terms of Service.

 
Reply to this topicStart new topic
"Fix VBR MP3 Header" on CBR files?
kidnukey
post Jun 1 2012, 20:47
Post #1





Group: Members
Posts: 9
Joined: 31-May 12
Member No.: 100297



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.
Go to the top of the page
+Quote Post
psycho
post Jun 1 2012, 23:08
Post #2





Group: Members
Posts: 241
Joined: 14-October 05
Member No.: 25099



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


--------------------
lame -V 0
Go to the top of the page
+Quote Post
db1989
post Jun 2 2012, 00:45
Post #3





Group: Super Moderator
Posts: 5275
Joined: 23-June 06
Member No.: 32180



How about Rebuild MP3 stream?
Go to the top of the page
+Quote Post
kidnukey
post Jun 2 2012, 01:05
Post #4





Group: Members
Posts: 9
Joined: 31-May 12
Member No.: 100297



QUOTE (psycho @ Jun 1 2012, 23:08) *
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.


QUOTE (db1989 @ Jun 2 2012, 00:45) *
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.

This post has been edited by kidnukey: Jun 2 2012, 01:05
Go to the top of the page
+Quote Post
mjb2006
post Jun 2 2012, 05:42
Post #5





Group: Members
Posts: 860
Joined: 12-May 06
From: Colorado, USA
Member No.: 30694



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 smile.gif

This post has been edited by mjb2006: Jun 2 2012, 06:08
Go to the top of the page
+Quote Post
db1989
post Jun 2 2012, 08:54
Post #6





Group: Super Moderator
Posts: 5275
Joined: 23-June 06
Member No.: 32180



QUOTE (kidnukey @ Jun 2 2012, 01:05) *
QUOTE (db1989 @ Jun 2 2012, 00:45) *
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.

This post has been edited by db1989: Jun 2 2012, 08:56
Go to the top of the page
+Quote Post
kidnukey
post Jun 2 2012, 09:04
Post #7





Group: Members
Posts: 9
Joined: 31-May 12
Member No.: 100297



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.

QUOTE (mjb2006 @ Jun 2 2012, 05:42) *
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.
Go to the top of the page
+Quote Post
markanini
post Jun 2 2012, 13:27
Post #8





Group: Members
Posts: 555
Joined: 22-December 03
From: Malmö, Sweden
Member No.: 10615



QUOTE (mjb2006 @ Jun 2 2012, 06:42) *
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.

This post has been edited by markanini: Jun 2 2012, 13:39
Go to the top of the page
+Quote Post
Porcus
post Jun 2 2012, 22:41
Post #9





Group: Members
Posts: 1995
Joined: 30-November 06
Member No.: 38207



QUOTE (kidnukey @ Jun 2 2012, 02:05) *
QUOTE (db1989 @ Jun 2 2012, 00:45) *
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?


--------------------
One day in the Year of the Fox came a time remembered well
Go to the top of the page
+Quote Post
kidnukey
post Jun 3 2012, 00:09
Post #10





Group: Members
Posts: 9
Joined: 31-May 12
Member No.: 100297



QUOTE (Porcus @ Jun 2 2012, 22:41) *
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.
Go to the top of the page
+Quote Post
mjb2006
post Jun 3 2012, 05:20
Post #11





Group: Members
Posts: 860
Joined: 12-May 06
From: Colorado, USA
Member No.: 30694



QUOTE (markanini @ Jun 2 2012, 06:27) *
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.

This post has been edited by mjb2006: Jun 3 2012, 05:51
Go to the top of the page
+Quote Post
markanini
post Jun 5 2012, 09:52
Post #12





Group: Members
Posts: 555
Joined: 22-December 03
From: Malmö, Sweden
Member No.: 10615



QUOTE (mjb2006 @ Jun 3 2012, 06:20) *
QUOTE (markanini @ Jun 2 2012, 06:27) *
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?
Go to the top of the page
+Quote Post
mjb2006
post Jun 5 2012, 22:22
Post #13





Group: Members
Posts: 860
Joined: 12-May 06
From: Colorado, USA
Member No.: 30694



This being the fb2k support forum, I assumed he was paying attention. smile.gif
Go to the top of the page
+Quote Post
mjb2006
post Sep 7 2012, 18:01
Post #14





Group: Members
Posts: 860
Joined: 12-May 06
From: Colorado, USA
Member No.: 30694



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.

This post has been edited by mjb2006: Sep 7 2012, 18:30
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 25th December 2014 - 11:34