When Stanley fixed this issue ?

[kawamoto76]

I had been using MC-Build-5280(64bit) for a long time to transcode TS(mpeg2/aac) into .m2ts(H264/ac3), because my machines employed Vista64, and the later MC versions cannot run on Vista64.
There, as I reported before("Build 5196: bad A/V sync (from TS into .m2ts(AVC))" viewtopic.php?f=28&t=11125) , when without audio-delay compensation, bad A/V sync products were always got where audio proceed than video several hundred millisecond.
However, recently I update my machines to Windows8.1(64bit) and MC-Build-5645. There I found the issue fixed away.
When Stanley fixed this issue ?

I had been compensating this A/V out-of-sync by typing audio-delay value into "Audio Delay" columb in "Sound" tab, that is a opposit of the value shown in the "Properties Window" reported by "MediaInfo". This issue had not happened in the older versions prior than Build-5160. Unfortunately, this issue had been continued from Build-5160 untill Build-5280. Now, I confirmed the reason of this issue through analysing the "audio-delay" of TS files.
Apart from PS files(i.e. .mpg, etc.), generally,"audio-delay" is not defined as to TS files. That is a conventional value to compensate A/V unsync through Codec Changer's processing. Always at GOP started TS files, "audio-delay" means the delay of PTS of the earlist appered audio packet from that of the first video frame(always not appering the earliest, such as appering I-frame(3rd),B-frame(1st),B-frame(2nd),,,in sequence ). Audio packets are placed in time order(the earliest is the first), but video packes are not. Because audio packets are placed after video packets(having corresponding PTSs to the audio) generally, audio packets corresponding the precursor GOP's video are always found at the beginning of the GOP packets. Then this "Audio-Delay" may be negative 200-500msec, and varies along with the cut out point of original stream when it is made(sampled or captured).

There, as is TSMuxer reports,
"audio-delay" = (PTS of earliest audio packet) - (PTS of first video frame)
However, other analyser(such as MediaInfo) reports the different "audio-delay" value.
MediaInfo inspect the PTS of the first actually available Video packet and Audio packet to get relative(e.g. from the first video frame) "video-delay" and "audio-delay". Then report the difference of both "delay" values as "Audio-Delay". There,
"Audio-Delay" = "Audio-Delay(TSMuxer)" - (Video-Delay)
Always TSmuxeR and Mediainfo reports different "Audio-Delay" values, it is reasonable because difinitions are different.
From my experience, MediaInfo's value is convinient for those versions of Mediacoder(x264,ffmpeg,TSMuxeR).

As to Prioer versions(Build-5158 or less) and up-to-date Versions(Build-5645), compensation with "Audio-Delay" is not necessary for conversion. At these versions, start of encodings(video and audio) seems to be accomplished with sync by referring PTS not with standing "Audio-Delay".
Unless for bad constructed TS, we must not use "Audio-Delay" compensation to convert TS input. It will give misserable result. The "Audio-Delay" input columb should be kept to "0".

If I would encode video and audio individually without considering A/V sync after simply separating A/V, I should conpensate the difference of each starting PTSs(Video and Audio), giving the "Audio-Delay" to encoders or muxers.
However, in Mediacoder, because encoding would be done with reffering PTSs of video and audios, "audio-delay" is not necessary for proper input.
Whereas, these bad versions Mediacoder Build 5160-5280 seems to miscompensate automatically with applying unnessesary "Audio-Delay" value input. Then I had to over-compensate to clear the miss-treated compensation with the opposite(+/-) of MediaInfo reported "Audio-Delay", otherwise without compensating manually, results that audio proceeds than video were always found in the products(.m2ts). By giving the proper signed "Audio-Delay" the is the opposit of MediaInfo reports, I had been getting .m2ts products with A/V sync for a long time.

Although above issue had been already fixed some time ago, I report here for remembering, and not to introduce the issue again.