|
|
| Abrazo |
| Posted: Nov 5 2010, 09:15 PM |
 |
|
Advanced Member
Group: Members
Posts: 775
Member No.: 28995
Joined: 5-November 10
|
When converting from mpeg2 to divx at 25fps and the timelength of the original video is exactly the same as that of the audio, the resulting AVI has always a few chuncks of audio more than there are frames of video (controlled with VirtualDub 1.7.8 via "File Information").
This fact has been present in version 1.7.8 (and maybe earlier versions) and it is still now... in version 1.9.10.
I compress the video to DivX 6.8.3 and the audio to MPEG Layer-3 128Kbit. The audio is interleaved every 1 frame (= 40ms) via Audio > Interleaving.
So, I would expect the number of video frames and audio chuncks to be exactly the same amount ... but there are always a few audio chuncks to much.
When I open the resulting file and save it again (via "File > Save as Avi...") with Video and Audio "Direct Stream Copy", than the number of frames and chuncks becomes equal for both and so is the timelength. (The audio chuncks that where too much are left away.)
Why does this problem bothers me ? Because when appending multiple avi segments together the audio gets out of synchronisation.
First question : Would it be possible to have a correct result from the first time ?
Second question : Why the information about the number of audio chuncks has been changed since version 1.7.8 and at what does it correspond now ?
Though I still do use an interleaving at every 1 frame, the number of audio chuncks shown in version 1.9.10 is totally different from the number of the video frames. |
|
| phaeron |
| Posted: Nov 7 2010, 08:43 PM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
Chunk counts don't matter with regard to sync, so what's important here is the length in time. In fact, it is normal for the audio chunk count to be different, as it will usually be slightly higher for normal output due to audio preloading at the start, and if the audio stream is encoded as VBR it can't be the same as the video frame count.
How much extra time are you seeing in the encode? If it's about one video frame (25ms), then it may be an artifact of the MP3 encoding, which adds difficulty here due to the overlapped transform it uses. When encoding, VirtualDub crops off the *uncompressed* input, and then writes out whatever the audio encoder produces from that. The reason for this is that VirtualDub needs to give the encoder a chance to see a clean end and flush out any partial data it has produced; cutting off encoded stream instead can result in broken packets in the output. This leads to a quandary since while the direct stream copy post pass might fix sync problems, you're likely getting a glitch at the join point. For this reason, I'd recommend doing your segment passes with video compression only, and then recompress the audio in the joined result. |
|
| Abrazo |
| Posted: Nov 8 2010, 08:43 PM |
|
|
Advanced Member
Group: Members
Posts: 775
Member No.: 28995
Joined: 5-November 10
|
Many thanks for your answer phaeron.
Given the fact that I have video at 25 frames per second and an interleaving of audio at every one frame, every audio chunck corresponds to 40ms.
I do use CBR-audiocompression (constant bitrate) and no audio preloading (0 ms).
The number of audio chuncks in my compressed avi segments (indicated in Virtualdub v1.7.8) is most of the time one or two higher than the number of video frames. The difference in length of time - compared from video to audio - is variable from 40ms to about 70ms, no matter the length of the segments (going from 3 to about 10 minutes). When multiple segments are put one after another this difference is good noticeable in fragments where people are talking.
Doing the audio compression only in the joined result is a very good recommandation. Indeed when choosing 'No compression (PCM)' for the audio-compression in the different segments, the length of time of the (uncompressed) audio rests exactly the same as that of the (compressed) video.
|
|
| phaeron |
| Posted: Nov 12 2010, 05:45 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
| QUOTE |
The number of audio chuncks in my compressed avi segments
|
Uh oh.
Are you using the "save segmented avi" command while doing audio compression, and in particular does your audio use 44KHz sampling rate? There is a quirk with MP3 compression and 44KHz sampling rate where the typical codec outputs a different rate than it is supposed to. Normally, VirtualDub detects this shortly after the compression starts and adjusts everything to match. It's possible, however, that the segmented save path doesn't do so when it needs to compute where the slice points are.
|
|
| Abrazo |
| Posted: Nov 13 2010, 10:43 AM |
|
|
Advanced Member
Group: Members
Posts: 775
Member No.: 28995
Joined: 5-November 10
|
I am not using "Save segmented AVI...". I just join together separate AVI-files with "Append AVI segment..." and save them as one file with "Save as AVI...". The audio-compression is being done with a sampling rate of 44.100 Hz at 128Kbit/sec. with Fraunhofers MPEG Layer-3 codec version 3.4.0.0.
I just wondered why Virtualdub adds extra time when compressing a pure WAVE (Microsoft 16-bit PCM audio file in stereo at 44.100Hz) to MP3. It would have been perfect if the time-length of the output of the video and the audio would have been exactly the same as that of the input. I suppose that in one way or another it must be possible to have an equal amount of video and audio peaces (chuncks) when using an audio interleave of 40ms at every one frame (at 25 frames per second) with CBR and no preload.
At this moment I only can achieve this by saving the result a second time with "Direct stream copy" for both Video and Audio. |
|
| phaeron |
| Posted: Nov 22 2010, 01:22 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
This is ultimately up to the audio codec, and unfortunately, there isn't a single behavior that works all around. You're guaranteed to have a small amount of error just because MP3 can only compress frames of 1152 PCM samples, not to mention overlap issues and any buffering in the codec. This is also complicated by the way in which the Fraunhofer codec passes back data, which obscures the actual MP3 boundaries -- meaning that a partial decode would be required in order to determine the true frame boundaries to determine a clean cut point.
|
|
