Hi,

well I have a little problem, maybe someone can help me.

I used the mp3DirectCut-Tool to cut the mp3-Track

Nivana\Nevermind\12 - Something In The Way

into

1. Something In The Way
2. Silence
3. Hidden Track

Well, after that, Winamp and EncSpot showed me wrong information about the length of the tracks, Bitrate, etc. I think, the reason is a wrong Lame/Xing Header.

Is there a tool, that analyses an mp3 an creates a valid one?

Thanks in advanced

Yep, check VBRFIX 5.13.15 ... works like a charm!

[EDIT: actually it recreates the VBR-header, which will solve your problem, the problem shouldn't be related to the LAME-header]

Thank you. Problem solved! B)

I can't understand why the designers of the mp3 file structure really had no clue ? It seems to me like every feature is a hack ?

In fact there was no designers, because there is no mp3 file structure. Your mp3 files are just some raw dumps of an mp3 bitstream.
It is the same thing as if instead of using wave files for uncompressed audio you were using just .raw files.

Ok, then I meant the format - the bitstream itself. I noticed numerous practical issues.

For example, a vbr mp3 encoded with LAME 3.92 will show an incorrect playing time in both winamp and windows explorer. After processing the file with mp3trim, it will work properly in both. I think if the VBR part of the spec was more rigorous, this couldn't happen.. what do you think ?

It looks like the "Xing VBR header" is a quick hack to append information that should have been included in the bitstream in the first place... Am I wrong here ?

Maybe the design was done a bit hastily, and useful features were left out in the 1st place ? Well, after all, the mpeg-1 layer 3 was mostly advertised for outstanding sound at 96kbps and 128kbps CBR, wasn't it ?

Well, the kind of information stored into the XING header is what should be in a file header. A bitstream doesn't have such information.

At the begining, this was not an issue because mp2 and mp3 were mainly targetted to be streamed over isdn lines, not to be used as files on computers.
Only recently the mp4 container appeared, which can include mp3 bitstream.

Agreed.. but there should be room in the bitstream header for these kinds of things.. anyway

Do you mean that Xing were the first to really incorporate the bitstream into files ? I mean, didn't Fraunhofer store the pure bitstream (without additional headers) before they did ?

Yes, FhG was storing a raw bitstream dump, nothing else.
Now, they are using a VBRI header for vbr streams.

See? That's the kind of thing that harms compatibility..
It seems that few mp3 players can handle VBRI headers

Anyway, that wouldn't have have been a problem if they defined it from the start

Well, it does not harm compatibility. Those additionnal header are providing extra info, but are not necessary to play the stream.

Mad, as an example, is not using those headers at all, and is able to display correct time.
The big advantage of those headers is seeking when using hardware players.

How would one put the .mp3 bitstream into an .mp4 or .ogg container?

On topic, I've been having extreme problems with the LAME tag breaking compatibility with certain software programs. Disabling the VBR header completely, the only option available to cancel the tag, is not an acceptible solution. There should be a switch to disable the lame tag for compatibility reasons, while still writing a standard VBR tag where needed. Especially, writing a VBR tag for CBR files is a nasty nasty hack which seems to break legacy apps.