compatability concerns? .avi w/parts w/different bitrates

[coyote2]

If parts of an .avi file have different audio bitrates, will the file have compatibility issues with playback devices?

The whole .avi file is CBR (MPEG-1 Layer 3 48000 Hz Joint Stereo), but one part's audio is 128 kbps and the other part's audio is 160 kbps.

This is because I joined two .avi files to create it. Then I edited the audio (in mp3DirectCut) and remuxed the edited audio with VirtualDubMod 1.5.10.2 which gave me a warning because it thought it ("appears to contain a MP3 VBR stream") VBR. (I suppose because there were two regions with different CBR bitrates.)

Avidemux didn't mind when I originally did the join. And the joined file plays perfectly on all *my* players and boxes. But I wonder if other players would have issues, so maybe I should rejoin after recoding one file's audio bitrate to match the other?
http://coyote3.net/VirtualDubMod.jpg
In case you can't read the image above, here's the rest of the VirtualDubMod message: "The current preference is to rewrite the audio header with standard CBR values during processing for better compatibility. This may introduce up to 33256 ms of skew from the AVI video stream. If this is unacceptable, (re)compress with a constant bitrate encoder. (bitrate 129.3 +-6.2kbps) Do you still want to rewrite the header? (only matters when saving to AVI)?" Then I clicked "No" and saved the .avi

[hello_hello]

You've taken two CBR MP3s, joined them using mp3DirectCut and resaved them as a single file. In order to do so mp3DirectCut has created the new file with a VBR header. I can't see why that's not perfectly valid, even if in this case the bitrate only changes once.
As an experiment I just joined a CBR 120k MP3 to a CBR 160k MP3 using mp3DirectCut and when playing the joined file in foobar2000 it just sees it as a VBR MP3.

VirtualDub will always do a Chicken Little impersonation when you open an AVI containing VBR MP3 audio and claim the sky is falling, even if it's a "normal" VBR MP3 audio track, rather then the type you've created. I can't remember exactly why it thinks VBR MP3 is bad, but I've got numerous AVIs containing VBR MP3 audio and never had a problem playing them on any device capable of playing AVIs.... ever. (I think VBR MP3 in an AVI was originally considered to be a "hack" by some, but it's so universally supported now even if it once was a hack it no longer matters)

If you can find someone who's experienced problems when playing AVIs with VBR MP3 audio using any device I'd be astounded. I'd be leaving the audio the way it is and ignore the VirtualDub warning. Or you can go into VirtualDub's preferences and under AVI, later versions of VirtualDub have an option to disable that warning.
I'm pretty sure VirtualDub (and VirtualDubMod) is the only program I've ever used which fusses over VBR MP3 audio in an AVI. Obviously Avidemux doesn't care.

[coyote2]

You've taken two CBR MP3s, joined them using mp3DirectCut and resaved them as a single file. In order to do so mp3DirectCut has created the new file with a VBR header. I can't see why that's not perfectly valid, even if in this case the bitrate only changes once.
As an experiment I just joined a CBR 120k MP3 to a CBR 160k MP3 using mp3DirectCut and when playing the joined file in foobar2000 it just sees it as a VBR MP3.

VirtualDub will always do a Chicken Little impersonation when you open an AVI containing VBR MP3 audio and claim the sky is falling, even if it's a "normal" VBR MP3 audio track, rather then the type you've created. I can't remember exactly why it thinks VBR MP3 is bad, but I've got numerous AVIs containing VBR MP3 audio and never had a problem playing them on any device capable of playing AVIs.... ever. (I think VBR MP3 in an AVI was originally considered to be a "hack" by some, but it's so universally supported now even if it once was a hack it no longer matters)

If you can find someone who's experienced problems when playing AVIs with VBR MP3 audio using any device I'd be astounded. I'd be leaving the audio the way it is and ignore the VirtualDub warning. Or you can go into VirtualDub's preferences and under AVI, later versions of VirtualDub have an option to disable that warning.
I'm pretty sure VirtualDub (and VirtualDubMod) is the only program I've ever used which fusses over VBR MP3 audio in an AVI. Obviously Avidemux doesn't care.
Thank you very much, hello_hello, your reply is very informative and reassuring!

[LoRd_MuldeR]

As an experiment I just joined a CBR 120k MP3 to a CBR 160k MP3 using mp3DirectCut and when playing the joined file in foobar2000 it just sees it as a VBR MP3.

In MP3 there are no "CBR" and "VBR" frames. All frames in an MP3 stream always have a fixed size! There are different fixed sizes that the encode can choose from though.

There is a table (in the specs) which assigns each nominal bitrate (like 128 kbps, 192 kbps and so on) a corresponding fixed frame size, in bytes.

By definition a "CBR" MP3 streams only contains frames of a single size, e.g. only 128 kbps frames, while a "VBR" streams mixes frames of different size (e.g. it can contain 128 kbps and 192 kbps frames).

Obviously when joining two "CBR" MP3 streams with different CBR bitrate, the result will inherently become a "VBR" stream! Also MP3 does not have a "global" header ;)

(The so-called "Xing" header, aka "VBR header", is just a propriety non-standard extension. Its sole purpose is to allow better seeking in raw "VBR" streams)

[hello_hello]

(The so-called "Xing" header, aka "VBR header", is just a propriety non-standard extension. Its sole purpose is to allow better seeking in raw "VBR" streams)

Thanks for the info....
So the "VBR header" which VirtualDub fusses over, that's the so-called "Xing" header?

I don't understand what goes on "under the hood" when muxing an AVI, but would VirtualDub have to mux VBR MP3 audio differently to CBR MP3 audio? Does it do more than just re-write the MP3 header? I vaguely remember reading somewhere VBR audio requires more overhead the CBR audio, but I don't know whether that's actually true.

I'm just curious as I know traditionally VBR MP3 audio in an AVI was considered by some to be a bad thing, however I've never really understood exactly why.
I guess I've also never really understood why VirtualDub continues to be (I assume) the only program to hold on to the "VBR MP3 is bad" philosophy when in reality VBR MP3 audio in an AVI never causes playback problems.

[GodofaGap]

I don't understand what goes on "under the hood" when muxing an AVI, but would VirtualDub have to mux VBR MP3 audio differently to CBR MP3 audio?
Yes.
Does it do more than just re-write the MP3 header?
It's not re-writing MP3 headers, it's re-writing the AVI header. MP3 doesn't have a global header.

I vaguely remember reading somewhere VBR audio requires more overhead the CBR audio, but I don't know whether that's actually true.
It depends how you mux the CBR audio.

I guess I've also never really understood why VirtualDub continues to be (I assume) the only program to hold on to the "VBR MP3 is bad" philosophy when in reality VBR MP3 audio in an AVI never causes playback problems.
Because if one were to write an AVI parser strictly by the spec, VBR MP3 wouldn't work. In the way VirtualDub is writing CBR MP3 though, neither would that.

[LoRd_MuldeR]

See also:

Myths about AVI - MP3-VBR-in-AVI is a dirty hack
This is probably the piece of disinformation most widely spread about AVI. Seeking in an MP3-VBR audio stream in DirectShow works as if it was a video stream, not an audio stream: Each chunk contains data for a constant amount of time (usually 33 or 40 ms for video, or 24 ms for MP3 audio at 48 kHz). The chunk/frame to be loaded is just [time] / [time per frame], as if it was a video stream. The way MP3-VBR is sought in is valid for AVI files. Maybe it was not intended to be used for audio streams, maybe it was, fact is, the specification doesn't limit any particular seeking strategy to any particular stream type! There is a value in the stream headers, called dwSampleSize, which is 0 in order to trigger VBR stream seeking. This is officially documented in the MSDN and not a hack, bug or whatever. The way MP3-VBR and AAC are stored in AVI are specified and completely compliant with the AVI file specification.