Looking for copy of avs2avi wrapper v0.3

[DRP]

If an audio delay is used, MediaInfo should display it, under the audio section. It'll be listed as "delay relative to video".

Have you ever seen this value expressed as a negative? I ask because I haven't. I would take a positive value as meaning the video starts before the audio and a negative value as being the audio starting before the video.

I have encountered a video with a reported 86ms delay. I added that amount to the beginning of the created AC3 file and the audio sync got even worse. Then I went the other way and cut 86ms from the beginning of the file and while the audio sync wasn't perfect, it was much improved and at least watchable.

From this experience I take it that you need to go the opposite of the reported delay to correct it. ie. if +86ms is reported, then you need to apply a -86ms correction to extracted stream to compensate. This assumes of course that MediaInfo actually distinguishes via +ve or -ve values the difference between a video vs audio delay. Anyone know for sure if this is the case?

[hello_hello]

I'd assume if the delay is negative MediaInfo would report it correctly, but I've not seen one. I think I've seen video streams with a delay though which would equate to a negative audio delay.

No muxing programs I know of apply negative audio delays by specifying a delay value, they actually truncate the appropriate amount of data from the beginning of the audio stream so it begins at the same time as the video. If ever you demux the audio stream it'll possibly be a bit shorter.... but in theory if there's no audio delay specified by MediaInfo there shouldn't be one. However....

If MediaInfo reports an audio delay it'll be a positive value which you need to apply.

Don't forget the junk data an/or padding which some audio streams may contain, which may have been used as a "pseudo" delay and may have been removed at some stage (converting?) or not compensated for correctly when muxing......

Most of the time audio delay seems to be "logical". MediaInfo displays it, you use that value, there's harmony in the world, but sometimes.... another logical step might be to adjust the audio in "frame increments" if it's a little out. I've often found moving it one or two frames back or forward does the trick (40ms for 25fps, 33ms for 29.970 etc).

I've sometimes opened the AVIs created by avs2avi after muxing the audio and it seems fairly out of sync, but after encoding all is well, so don't trust the audio sync completely till after encoding and adjust the encoded version's audio delay if need be.

If there's no logical reason you can find for an audio delay, and/or no way to find out exactly what it needs to be, I have a slightly convoluted method involving playing the source video to adjust the audio sync of the encoded version fairly accurately. Not much time now, but I can explain it later....

[DRP]

Don't forget the junk data an/or padding which some audio streams may contain, which may have been used as a "pseudo" delay and may have been removed at some stage (converting?) or not compensated for correctly when muxing......

So far I'm only dealing with AC3 files I'm making myself via DVD-lab Pro & TMPGEnc AC-3 Plug-in. DVD-lab PRO identifies the junk data and losslessly excises it from the stream to leave you with a compliant file. It also has an audio delay adjustment feature I use where you can apply +ve or -ve delay amounts and have them losslessly applied. For +ve it adds silence to the start and for -ve it just truncates the beginning of the stream.

[hello_hello]

So far I'm only dealing with AC3 files I'm making myself via DVD-lab Pro & TMPGEnc AC-3 Plug-in. DVD-lab PRO identifies the junk data and losslessly excises it from the stream to leave you with a compliant file.

Ideally, shouldn't it be replacing the junk data with silence to maintain audio sync? Assuming the audio is originally in sync and the junk data forms part of any audio delay, I think it should.
I've not used DVD-Lab Pro, but does it at least inform you of how much junk it's removing and how much of an audio delay that equates to? I'm just wondering if it's some of the reason you're having audio sync issues. If the junk data isn't being replaced with silence then you probably need to delay the audio by the amount of delay MediaInfo displays plus the required amount for junk data removal compensation.

What format is the original audio in? Are you converting AAC to AC3 or are you starting with AC3 too? As you said DVD-Lab Pro removes the junk data losslessly I assume the original audio is AC3? Maybe I'm not understanding your process exactly, but if you're starting with AC3 and ending with AC3 why not use the original AC3 "as-is"?

[DRP]

I've not used DVD-Lab Pro, but does it at least inform you of how much junk it's removing and how much of an audio delay that equates to?

Yes it does. If you try and use a non-compliant or corrupt AC-3 file, it will pop-up a warning to tell you such and advise you what's wrong with it and what it's going to do to it to correct the corruption so it can be used.

What format is the original audio in? Are you converting AAC to AC3 or are you starting with AC3 too?

Most recently I'm converting AAC to AC3. In this process, there is no junk data or corruption occuring at all. The TMPGEnc AC-3 Plug-in produces perfectly compliant files for DVD-lab PRO to deal with, so there is no problem.

As you said DVD-Lab Pro removes the junk data losslessly I assume the original audio is AC3? Maybe I'm not understanding your process exactly, but if you're starting with AC3 and ending with AC3 why not use the original AC3 "as-is"?

The only time I've experienced AC3 files that need DVD-lab's corrective capabilities, is when using the original ones already present in the AVI file, (or even in some cases as ripped from original retail DVDs).

I use GoldWave to extract AAC to WAV, then I use WavGain to losslessly apply a RadioGain volume adjustment to that WAV file, then I convert it to AC3 using the TMPGEnc Plug-in with DVD-lab PRO as the GUI frontend. That AC3 is then perfectly compliant for muxing with VDub and subsequent encoding with AutoGK.

[hello_hello]

Just some thoughts....
When you convert from one format to another, the original padding should be ignored while only the "real" audio is converted and the output file will then be padded too if it's a lossy format. The differences in padding shouldn't be enough to cause noticeable audio sync issues even if they are ignored when muxing but..... the original AAC, the wave file and the final AC3 should have exactly the same duration. They should contain the same number of samples. I'd assume, but don't know for certain, when you open an audio file with a program the duration it displays shouldn't include the encoder padding.... well I know I can convert an AAC file to wave (no padding) and then the wave to MP3 and foobar2000 will report the same duration for each down to the millisecond.....

I rarely encode to AC3 so haven't bothered investigating it much but if memory serves me correctly AC3 files tend to be endowed with more encoder padding than other lossy formats. In a perfect world the encoder would replace junk data in AC3 audio with silence and the muxing program should compensate for the padding. To be honest I've not experienced audio sync issues when using AC3 in AVIs so I'd assume VirtualDubMod is sufficiently clever..... but that's all just some info you might care to investigate if you continue to have audio sync problems.

I looked it up, but to confirm..... RadioGain? I assume it's ReplayGain's TrackGain with a new name? I guess AlbumGain is now AudiophileGain?

[DRP]

I looked it up, but to confirm..... RadioGain? I assume it's ReplayGain's TrackGain with a new name? I guess AlbumGain is now AudiophileGain?

Yeah, the algorithm is ReplayGain, but you have the option of Radio or Album analysis. The 'Radio' setting works even when there is only one file being processed. It has the effect for me of producing a consistently 'middle of the road' volume setting which doesn't clip, and which produces the effect that all encodes I do are the same average volume. It's neat because I never have to adjust the volume on my amp when playing when going from one genre or file to any other.

It is much better and preferable to simply maximising all peak audio samples to 32767 and then encoding from there.

[hello_hello]

I guess they must have changed the names at some stage. Both the programs I use which include ReplayGain (MP3Gain and foobar2000) both still refer to them as TrackGain and AlbumGain.

I try to avoid changing the volume these days, but of course if you're converting something which has already been inflicted with "normalizing" then ReplayGain certainly lets you get pretty close to un-normalizing it.

Given you mentioned "it doesn't clip" I thought I'd ask... do you know what the target volume being used when applying ReplayGain is? I ask as when mixing multichannel audio down to stereo, if you're simply combining the channels (maybe some programs automatically lower the volume first to compensate) the volume tends to increase a little and the resulting audio has a very good chance of including peaks above 0db (not clipping as such). I've pretty much decided after a bit of testing the highest they'll ever get is +6db. Not that I can hear it actually cause distortion on playback, but anyway.....

If I open an MP3 which was created using multichannel audio as the source, and especially if that multichannel audio has been normalized by someone who things normalizing is a clever idea, there's a fairly good change MP3Gain will indicate "clipping" when using it's default target volume of 89db. As a result if I'm going to use ReplayGain I use 89db for standard music tracks, but 83db for video soundtracks. I discovered later on 83db was the original target volume used by ReplayGain in line with the reference level of 83db specified by SMPTE, only it was later increased to 89db... probably due to 20db being a bit of over-kill when normalizing compressed CD type-audio. Aside from MP3Gain though, I wasn't aware of any other programs which use anything other than 89db, or for that matter any which let you change it even you wanted to. I guess if DVD-lab is designed for dealing with soundtrack audio it might use 83db. I'm just curious if it does....

Me..... these days if I'm converting multichannel audio to stereo, as long I'm converting an "original" version which hasn't been normalized, I just mix it down to stereo while getting foobar2000 to apply a 6db gain reduction as it encodes., I know the relative volume between tracks hasn't changed, the output level will sound pretty much the same as the source, I'm fairly confident the chances of peaks above 0db are almost zero, and ReplayGain scanning isn't really necessary.

[DRP]

I guess they must have changed the names at some stage. Both the programs I use which include ReplayGain (MP3Gain and foobar2000) both still refer to them as TrackGain and AlbumGain.

Yeah, TrackGain = RadioGain. Same thing, different name.

I try to avoid changing the volume these days, but of course if you're converting something which has already been inflicted with "normalizing" then ReplayGain certainly lets you get pretty close to un-normalizing it.

Well, I'm encoding broadcast TV programs which by definition have already been heavily mucked around with as far as audio compression is concerned before they've even been captured. There's no such thing as an unmolested audio track when dealing with such sources. In fact, in this day and age if you're dealing with any commercial "produced" audio/video product, it has for sure already been heavily mucked about with before you can get your hands on it. Some commercial music pop music CDs these days are absolutely horrid abortions of over-production in the race for the 'loudest' possible sound.

The best I can do is to tone down the audio to an acceptable average so that it doesn't offend my eardrums too badly.

Given you mentioned "it doesn't clip" I thought I'd ask... do you know what the target volume being used when applying ReplayGain is?

87dB works for me in literally 99.9% of cases. I have done over 10,000 lossy compressed audio tracks at 87dB. Only one of those still clips at that level. It's a very unusual track that would require reducing down to ~83dB to avoid clipping altogether. I estimate about 5% will clip at 88dB and about 15% will clip at 89dB (MP3Gain's default).

BTW, just to get a bit back OT, I've just encoded a video that MediaInfo reported a 83ms audio displacement to the video for. I encoded it with no compensation on the audio at all and the sync was watchable (just) but noticeably off. I demuxed, truncated the audio stream losslessly by 83ms (-83ms delay) and remuxed and the result in the watching is perfect.

[hello_hello]

87dB works for me in literally 99.9% of cases. I have done over 10,000 lossy compressed audio tracks at 87dB. Only one of those still clips at that level. It's a very unusual track that would require reducing down to ~83dB to avoid clipping altogether. I estimate about 5% will clip at 88dB and about 15% will clip at 89dB (MP3Gain's default).

That's interesting. Not that it's a huge difference, but I wonder why we get slightly different results?
For instance I'm in the process of converting three Bluray movies at the moment. Knight And Day, and Night At The Museum 1 & 2. So out of curiosity I mixed the DTS audio from each down to stereo while converting it to MP3 with foobar2000, then ran each through MP3Gain. According to MP3Gain, in all three cases 85db would be the maximum target volume which doesn't cause "clipping".

BTW, just to get a bit back OT, I've just encoded a video that MediaInfo reported a 83ms audio displacement to the video for. I encoded it with no compensation on the audio at all and the sync was watchable (just) but noticeably off. I demuxed, truncated the audio stream losslessly by 83ms (-83ms delay) and remuxed and the result in the watching is perfect.

What do you mean by "audio displacement to the video"? Was MediaInfo showing an 83ms delay for the video?

By the way.... nothing wrong with the way you did it, but if you simply remux a video file while specifying a negative audio delay, most muxing programs will truncate the beginning of the audio for you.

[DRP]

I wonder why we get slightly different results?

Probably to do with what settings we choose as our preferences on the audio encoding. I don't use foobar. I use EAC as the frontend GUI for LAME v3.99.5 as it is right now where I can tweak the individual switches for options as I wish. Maybe foobar allows the same thing. I don't know as I've never used it. I'm happy with using EAC because I also do alot of audio CD creation and copying for which EAC is the only tool to use, so I just use what I know for the audio in video as well.

I use -V2 -b32 switches in LAME if it matters any.

What do you mean by "audio displacement to the video"? Was MediaInfo showing an 83ms delay for the video?

It shows "Delay relative to video" as being 83ms, yes. I take that to mean the audio starts 83ms after the video has started. So in order to correct it I figured that if I was to bring the audio back by that amount, then it would be the right amount of compensation. So applying a "delay" of -83ms would work. I tried it and it did work as expected.

By the way.... nothing wrong with the way you did it, but if you simply remux a video file while specifying a negative audio delay, most muxing programs will truncate the beginning of the audio for you.

Yep, that's good to know and I understand. It's just convenient doing it through DVD-lab PRO because the audio delay tool is right there and ready for use right after I've encoded the AC3 anyway.

[hello_hello]

foobar2000 wouldn't be doing anything odd when it comes to encoder settings. For example:
-m j -V 2 -q 0 -lowpass 18.5 --vbr-new -b 32
That's the info written to the audio stream after running a standard V2 encode. Maybe it's something to do with the way the audio is mixed down to stereo? I don't have EAC installed as foobar2000 also does secure CD ripping, but next time I'm encoding some DVDs I might at least try mixing down to MP3 using both foobar2000 and MeGUI to see if the resulting MP3s look any different to MP3Gain.
One thought.... are you just mixing down to stereo or downmixing to Dolby Prologic? I'm not sure if it should make a difference, but anything's possible. In all the maybe hunders of encodes I've done using AutoGK (which downmixes to Dolby Prologic 2), I recall only once noticing something odd... a loud sound which was obviously compressed. Re-encoding the audio using foobar2000 fixed it, and even though I've only noticed a difference once, I guess it might have an effect.

If MediaInfo shows a delay relative to the video, then it should always be an actual delay, or a positive delay. So assuming there's no junk data, and forgetting about any encoder padding, if MediaInfo shows an 83ms delay then you should be adding 83ms to the beginning of the audio, not removing it.
Why it seemed to work the other way around..... it might have been co-incidence.... I'm not sure. I've almost given up trying to work it out if it's not obvious. Either it's in sync, or it's not.

Yesterday I encoded about 6 DVDs. I also made AVI copies for someone else to use so I ran them through MeGUI and AutoGK. In MeGUI's case I used the original AC3, for the AVIs I converted to MP3. According to the delay amount written to the audio streams after they were extracted, none of them required an audio delay. However after opening the first AutoGK encode the audio was obviously out. So I used my audio sync test method to compare the audio/video sync of the original vob files to each encoded version. Two of the AutoGK encodes required adjusting. One required a -80ms delay, the other a -40ms delay. Even though I kept the original audio, one of the MeGUI encodes also required a -40ms adjustment, but it was a different movie to the ones I adjusted after encoding using AutoGK.
Maybe I should have tried to work out why..... I suspect maybe the encoder drops the first frame or two sometimes.... 40ms is pretty much the duration of a single frame so it'd make sense. Normally I wouldn't even check, it's just that in this case the first encode I looked at was obviously out.

[Slipster]

...

[hello_hello]

(Slipster,
I was actually considering sending you a PM to see what you make of this, but obviously while running my test encodes and writing this post you'd already arrived. This is doing my head in a little...... Any thoughts?)

Well I just tried a few DTS 5.1 -> stereo MP3 encodes use foobar2000 and MeGUI to test for ReplayGain target volume differences and the results were almost the opposite of what I expected. Well they surprised me anyway.....

Here's the (lengthy?) highlights. Encoding to 128K CBR MP3 and V2 VBR MP3 produces slightly different ReplayGain results, all else being equal ReplayGain reports a minor volume reduction when CBR encoding is used, but under 1db so nothing significant. However......

MeGUI (without telling it to normalize) produces much quieter encodes when mixing down to stereo than foobar2000. It seems to reduce the volume of each channel to around 30% of it's original volume (by around 10.5dB, I think), then mixes them together. The ffdshow "normalize" mixer matrix does the same. I never use it as it reduces the volume too much, I just use ffdshow's standard mixer matrix, but given both MeGUI and ffdshow can mix down to stereo the same way, there must be a reason for reducing the volume to such a degree which I don't understand. Anyhow......

I tried all sorts of combinations..... MeGUI and foobar2000, each mixing down to stereo "internally", each decoding via Directshow while ffdshow downmixed etc, but no matter which way I did it the results were the same. If the volume had been reduced by 10.5dB while converting to MP3, MP3Gain reported a maximum target volume of 81dB before clipping. If the audio had been downmixed to stereo without reducing the volume, MP3Gain reported a maximum Target Volume of 86dB before clipping. Yet the peaks weren't being clipped. Without reducing the volume while encoding MP3Gain reported peaks of around +3.0dB.

Thinking I'd found some weird MP3 encoding anomaly (encoding at different volumes changing the way the audio is encoded) I ran a couple of test encodes using FLAC as the output format. I couldn't run them through MP3Gain obviously, but a ReplayGain scan reported exactly the same results as when I was encoding to MP3. The only difference was when I didn't reduce the volume while encoding, the MP3 output had peaks of roughly +1.26 (I think) whereas the FLAC version had peaks of +1.00. As the reported ReplayGain volume was identical though, I guess it means FLAC can't store values above 0dB. I never knew that.

So basically according to my little bit of test encoding, it seems to be nothing to do with the GUI or encoder being used, but the lower the volume when mixing down to stereo, the bigger the difference ReplayGain will report between the ReplayGain volume and the peak levels. I don't get it. I wonder if the same would apply to simply re-encoding stereo audio? I don't have enough energy left to test that at the moment though. I'll have to think about this some more. Or vow never to think about it again. Anyway, here's the ReplayGain results. Maybe I'm just going silly......

DST 5.1, downmix to stereo, 10.5db gain reduction while converting. Output file: Track Gain +11.42dB, Track Peak +0.673
DST 5.1, downmix to stereo, no gain reduction while converting. Output file: Track Gain +0.94dB, Track Peak +1.256

PS. I guess I should make it clear..... all the above encoding used the same DTS file as the source. I've only experimented with one audio source so far.... that's enough for today.

[DRP]

Just getting back to video conversion again, what is it about WMV files that's giving me such grief to convert them? Everytime I try to convert a WMV file which plays perfectly on the computer using the AutoGK method outlined above with the DirectShowSource calling, it comes out with significant & progressively worse audio sync issues. MediaInfo doesn't report any variable frame rate, but neither does it report a constant frame rate either.

Is there something particularly weird about WMV files? I have always had great difficulty converting these successfully and I would like to get on top of it if possible.

Cheers

[poisondeathray]

Just getting back to video conversion again, what is it about WMV files that's giving me such grief to convert them? Everytime I try to convert a WMV file which plays perfectly on the computer using the AutoGK method outlined above with the DirectShowSource calling, it comes out with significant & progressively worse audio sync issues. MediaInfo doesn't report any variable frame rate, but neither does it report a constant frame rate either.

Is there something particularly weird about WMV files? I have always had great difficulty converting these successfully and I would like to get on top of it if possible.

Cheers

The most common sync issue with WMV is VFR. It might be that you used forced wrong base rate. That's likely the case if it's progressively out of sync ( not in and out of sync, but the end is in sync. The latter would mean the AV durations match, the former would mean the AV durations do not match)

What was your script, what did mediainfo say about the source file (view=>text)?



One way to be certain about the timecodes is use wmvtimes.exe (it's a command line application)

wmvtimes input.wmv output.txt

"output.txt" will list the timecodes in v2 format. (You can use a v2 to v1 converter to read them more easily)

If it truly is VFR and very variable (large fluctuations) , then you can never get it in perfect sync without using VFR. AVI container doesn't support VFR. The convertfps method is just an approximation (it will go in and out of sync in sections)

[El Heggunte]

......

Is there something particularly weird about WMV files? I have always had great difficulty converting these successfully and I would like to get on top of it if possible.

Besides the VFR possibility, there is also the *poorly-joined audio* issue (a "feature" of the ASF container). Careless audio decompressors/converters ignore the ASF timestamps, which makes the video go out-of-sync after every "point-of-junction" that hadn't been *filled with 'zeroes'*.

"Perfect" decompression of WMA streams can be done thru the Avisynth plugin BassAudioSource(). "Acceptable" decompression is given by Lord Mulder's wma2wav.exe:

http://forum.doom9.org/showthread.php?p=1513679#post1513679

[DRP]

Besides the VFR possibility, there is also the *poorly-joined audio* issue (a "feature" of the ASF container).

Thanks guys, I think my problems are the result of a bit of both these things. I've processed the file now with the VFR converting script and that has solved the immediate audio sync problem from file beginning, but it still manages to stray out of sync after some corrupt sections (possibly joins? I don't know for sure - I haven't joined anything).

"Acceptable" decompression is given by Lord Mulder's wma2wav.exe:

Thanks for the tip, I'll try and find a copy of that for future use should I need it.


Now, just quickly getting back to the audio thing again, I concur with previous statements about clipping of tracks. I've done some testing over the last couple of days and I fully agree with the comments of others in here. For audio CD quality sound, I can get away with 87dB level and there will be no clipping at all in 99.9% of cases in my experience. However, for video soundtracks (which I would assume are by default much more "processed" and peak-compressed straight from the consumer source than are traditional music CDs), you need to be much more conservative again to avoid clipping. 83dB seems to be the equivalent butter zone for audio that accompanies video to avoid clipping at the same rate as for audio CDs at 87dB.

I have a quick opinion question if I may. I have up until this point always used AC3 @ CBR 192kbps for video audio simply for the reason that that's what you see on commercial DVDs, so I assumed it's the best/most appropriate for that type of sound. For music though I use exclusively MP3 @ ~192kbps VBR which I'm very happy with.

I now have the opportunity to use either and it's completely my own choice as to which way I go. Both require the same amount of work and effort by me to do, so one is no easier than the other.

What is the consensus opinion on which would produce the better quality sound? Very latest generation LAME v3.99.5 -V2 -b32 vs several years old but fully Dolby Digital compliant AC-3 at CBR 192kbps for 2-channel streams only?

[DRP]

I've just converted an mp4 (AVC/AAC) to XviD/mp3 using AutoGK and the method above. The audio I extracted myself and converted manually to my preferred mp3 setting the same as I do my music for iPod use, so it's good quality. When I entered the muxxed avi pointer file to AutoGK I specified that AutoGK just use the existing audio file untouched. The output AVI it's made has come out with horrible, unwatchable audio. It clicks and pops and screeches, its volume varies dramatically throughout and basically it's full of artifacts. It obviously hasn't been left completely alone by AutoGK.

When I demux the AVI of the bad audio and remux it with the mp3 I made manually in VDub (like I assumed AutoGK would have done for me automatically during the encode process), the end result is perfect as I intended.

What has AutoGK done and why has it done it when I specified for it to use original audio (and the log confirms this)?

Here's a relevant portion of the log:

[7/09/2012 8:44:42 AM] Output codec: XviD
[7/09/2012 8:44:42 AM] Audio 1: 164 Kbps CBR MP3 2ch
[7/09/2012 8:44:42 AM] Subtitles: none
[7/09/2012 8:44:42 AM] Format: AVI
[7/09/2012 8:44:42 AM] Target quality: 75%
[7/09/2012 8:44:42 AM] Custom resolution settings: maximum width of 704 pixels
[7/09/2012 8:44:42 AM] Audio 1 settings: Original
[7/09/2012 8:44:42 AM] Started encoding.
[7/09/2012 8:44:42 AM] Source resolution: 720x406
[7/09/2012 8:44:42 AM] Source fps: 29.97
[7/09/2012 8:44:42 AM] Manual aspect ratio: 16:9
[7/09/2012 8:44:42 AM] Analyzing source.

The only thing odd in that which is wrong is AutoGK identifying the mp3 I made as CBR when it very definitely is VBR.

Is AutoGK known to mishandle mp3s made by other software and then try to "correct" then to its own specs or something?

[hello_hello]

Can't say I've ever experienced that myself, although I tend to use CBR MP3 mostly, but I've used VBR MP3 plenty of times in the past without issue.
The closest I've seen to what you're experiencing with AutoGK misidentifying audio, is instead of it seeing it as CBR or VBR MP3 it sees it as something like MPEG2/3 audio and gives an unsupported audio error. In that case, and maybe in your case also, the problem seems to be there's something wrong with the MP3 header or the way the MP3 is identified as VBR (I'm not sure how that info is saved to the MP3 stream).

I'd have to run an encode to check details, but when AutoGK encodes it creates a script which it saves to the temp folder in the output directory, along with a file (I think it has a vcf extension) telling VirtualDubMod what to do. You could try opening that vcf file using notepad to see if there's anything obvious going on, but failing that I'd guess the audio hasn't been muxed correctly given it's VBR but identified as CBR in the final AVI, and therefore it's not being played back correctly.

Anyway..... for a start I'd try opening the MP3 audio using MP3DirectCut. When it's open, use CTRL+A to select all of it, then File/Save Selection to save it as a new MP3 (there's no re-encoding). Add the newly created MP3 file to your AVI and open it with AutoGK. If AutoGK then identifies it correctly as VBR MP3 and muxes it into the output AVI correctly, there's something wrong with the original MP3.

If the above doesn't fix it then I'm not sure what the solution might be...... you could probably even get AutoGK to demux the MP3 as it normally would before encoding (it'll be in the temp folder in the output directory), then compare the extracted version in the temp folder with the original copy. If they're exactly the same, which they should be, it'd confirm AutoGK hasn't "messed" with the MP3 file in any way.

If all else fails, try converting the audio to MP3 with a different program to see how AutoGK handles it. If there's no problem, then it's back to looking at what the first conversion program is doing wrong.

[DRP]

Can't say I've ever experienced that myself, although I tend to use CBR MP3 mostly, but I've used VBR MP3 plenty of times in the past without issue.
The closest I've seen to what you're experiencing with AutoGK misidentifying audio, is instead of it seeing it as CBR or VBR MP3 it sees it as something like MPEG2/3 audio and gives an unsupported audio error.

I think you're spot on here. I've done a couple more encodes just to see if I can repeat the error and yep, AutoGK is identifying the audio as MPEG 2/3 instead of MPEG 1 layer 3. For some reason it seems to think it's getting 22.5kHz or 11kHz audio instead of the 44.1 or 48kHz it actually is. Sometimes it will still do the encode anyway even though the audio it thinks it's getting is not supported. Other times it will just refuse it entirely and you cannot proceed with the encode at all. I dunno why, but it doesn't really matter much. I can live with manually muxing the audio to the soundless AVI that AutoGK creates after the fact. Doing that works perfectly no problem and as previously discussed I can incorporate any delay I need into it when doing so as well.

[hello_hello]

It seems there's more than one way for the VBR info to be saved as part of the MP3 file, and I don't really understand how it works, but some programs seem to identify MP3s one way, other programs another, and as a result some might get it right while others don't. Ideally though, if the MP3 file is "good" any program should identify it correctly.

VirtualDubMod seems more likely to get it right than AutoGK (I've actually removed the VBR header from MP3 files as a test and VirtualDubMod still sees them as VBR MP3 and muxes them correctly), but maybe you could try this using one of your encoded MP3s. Open it with MP3Tag and look to see what it displays as the sample rate, duration and bitrate type. In my experience when AutoGK sees VBR MP3s as CBR MP3s, MP3Tag will do the same, and display quite "odd" durations and bitrates. As will foobar2000 (although it still plays them correctly). If MP3Tag sees the MP3 as anything other than what it's supposed to be..... well I'm not sure I'd keep using the same program for encoding MP3s until I could make sure it was creating them "correctly".

Chances are it's a problem with the VBR MP3 header as I'm sure most programs use the header to identify MP3 as VBR. If that's the case, and you have foobar2000 installed, it also has a function for repairing VBR MP3 headers. If you run a repair on one of your MP3s, and foobar2000, MP3Tag and AutoGK all then correctly identify it as a result, then your MP3 encoding software is doing something fairly odd.

Mind you I've seen quite a few AVIs with VBR MP3 which isn't identified correctly by AutoGK but while the MP3 is muxed into the AVI, I've not had any issues with it being played correctly. Still.... if it were me I'd prefer to know there's nothing non-standard about the audio I'm adding to my AVIs in case it does cause playback problems at some stage.

One last thought...... if you put your encoded MP3 into the same directory as the AVI AutoGK creates, and if it has exactly the same name as the AVI, when you open the AVI using MPC-HC it'll automatically load and play the external MP3 audio. If doing so causes the video to play at the wrong speed, MPC-HC to show something other than the correct video duration, or the audio plays with similar problems as you've experienced before..... there's definitely something wrong with the MP3.