I was recently trying to track down why it was that LAME's --nogap
option implicitly disabled Xing headers. Turning them back on was
obvious, but it reintroduced a gap, which seemed odd, but which was, I
assume, why they were turned off in the first place.
In trying to figure out the cause of the reintroduced gap, I noticed
that many mp3 tools that understood Xing headers claimed that the one
generated by LAME was invalid. Upon further searching, I noticed that
they claimed that even for mp3s created by LAME without --nogap.
So I started trying to figure out why the header was invalid, and it
looks as if the Xing header that LAME generates reports one too few
frames. My thought is that it fails to take itself into account, but
maybe there's a different off-by-one error somewhere. I'm sorry to say
that I don't have the free time available to walk through the entirety
of the related code. Anyway, it would appear that the gap is being
introduced because players assume that the Xing header's information is
correct and simply don't play the last frame. Fixing the number of
frames in the header (even though that potentially slightly corrupts the
TOC) fixes the gap, at least in my test cases.
In order to test this theory for yourselves, reenable Xing headers for
nogapped files (by removing the if-clause at frontend/lame.c:668).
Create some nogapped mp3s using this new LAME. They should seem to have
a gap in some (most?) players. Then fix the Xing header by running it
through mp3tool (http://empeg-hijack.sourceforge.net/mp3tool.html), for
example. Then play it again. The gaps should be gone.
Again, if you use a tool to examine the Xing header on even non nogapped
mp3s, you should see that it's corrupt on them as well. So I believe
that Xing headers are currently broken (albeit slightly) in LAME.
Putting a `+1' in libmp3lame/VbrTag.c:910 seems to patch the problem,
but that doesn't take into account the additional frame when computing
the TOC.
If someone could take a better look at the Xing header generation code,
I'd appreciate it. Thanks.
-Bitt
___
mp3encoder mailing list
[EMAIL PROTECTED]
http://minnie.tuhs.org/mailman/listinfo/mp3encoder
