Audio ends too soon using A-B markers in MKV

[Daniel3069]

please see above edit ^

Also I meant read in the sense that the program can open and play the file without issue.

[eumagga0x2a]

The above edit doesn't answer my question. Have I missed something?

Also I meant read in the sense that the program can open and play the file without issue.

This is not enough.

[eumagga0x2a]

64 bits MinGW builds: https://avidemux.org/nightly/win64/

[Daniel3069]

Yes I guess I had the wrong version of [2.7.1 win64 190126] ROFL
What was that other version for then? the crashing has stopped crashing now ty.

I still don't understand how?

"The origin of trouble is the Matroska demuxer in Avidemux which doesn't believe the default time increment" "and decides to force the closest default value"

Because: if the time increment in the source MKV was wrong then wouldn't video players have this same time increment issue?
And time increment issues I believe would only affect audio/sync and not video?
And time increment doesn't explain why MKV plays good, but MP4 has so many issues.

The evidence doesn't point to this file exactly being the problem, even Avidemux shows this when output is MKV.

[dosdan]

For an immediate success please use command-line ffmpeg:

Code Select Expand

ffmpeg -i 154.mkv -i 154.wav -map 0:0 -map 0:1 -map 1:0 -map 0:2 -map 0:3 -c copy 154-with-en-track-added.mkv

(edited to preserve subtitles)

eumagga0x2a, while this is an ADM forum, as a teaching aid for the useful FFMPEG, I think it would be best you showed the reported stream indices in the input files and explain how this command line assigns them in the output file. 

Dan.

I'll have a go:

Since Daniel3069 did not provide the original files, I'll work with the problematic output files.  My FFMPEG command line is:

ffmpeg  -analyzeduration 13000000 -i copy.mkv -i aac.mp4 -ss 12.6  -map 0:0  -map 1:1  -c copy -y  file_with_different_audio_stream.mkv


1. The audio appears corrupted in the approx first 12.5s. FFMPEG suggests using the analyzeduration option to work with this file. It's specified in micro-seconds. So -analyzeduration 13000000 means "analyse the clip for 13s duration". A larger value will work here like 65,0000,000.

2. We're using two input files. The order in which they are specified is significant. They are counted from zero. So -i copy.mkv is file #0 and -i aac.mp4 is file #1.

3. -ss 12.6 here means "remove the first 12.6s of garbage".  When placed in the command line after the input files it's slow but accurate. Normally it would be placed before them, but due to the difficulties with seeking in these files, I've done it the slow way. See https://trac.ffmpeg.org/wiki/Seeking#Cuttingsmallsections

4. The -map option is here using File:Stream_identifier format so, counting from zero, -map 1:0 means "From the 2nd file, take the first stream".  Here, both input files are in V/A stream order of 0/1, so -map 0:0 -map 1:1 means "from the first file, take the video stream and from the 2nd file, take the audio stream". The order they are specified in determines how the streams will be arranged in the output file. See https://trac.ffmpeg.org/wiki/Map

5. -c copy  means "copy all requested streams with re-encoding".  Alternative you could just re-encode the audio as WAV using either
-c:v copy -c:a wav
or
-vcodec copy -acodec wav
or
-codec:v copy -codec:a wav.

To remove a stream, say the audio or video stream from a file, you could use  -an or -vn. You can get fancier with this. See https://stackoverflow.com/questions/38161697/how-to-remove-one-track-from-video-file-using-ffmpeg

6. -y  means "overwrite the output file without prompting". It's handy when you're experimenting with slightly different versions of command lines.

7. file_with_different_audio_stream.mkv is the output filename. Its final position on the FFMPEG command line indicates this.

If one of the steams needs to be offset in time to correct a timing offset issue, use say -itoffset 0.5 to delay it by 0.5s. See https://wjwoodrow.wordpress.com/2013/02/04/correcting-for-audiovideo-sync-issues-with-the-ffmpeg-programs-itsoffset-switch/

Dan.

[eumagga0x2a]

Yes I guess I had the wrong version of [2.7.1 win64 190126] ROFL
What was that other version for then? the crashing has stopped crashing now ty.

So the native Windows build (using MS Visual Studio VC++ as build toolchain) crashes while the cross-build (built on Linux using MinGW) works when adding an external audio track, right?

I still don't understand how?

"The origin of trouble is the Matroska demuxer in Avidemux which doesn't believe the default time increment" "and decides to force the closest default value"

Because: if the time increment in the source MKV was wrong then wouldn't video players have this same time increment issue?

Video frames usually have two timestamps: the decode timestamp (DTS) describing the time when the frame should be decoded and the presentation timestamp (PTS) which is the time when the frame should be displayed. MKV stores only PTS so Avidemux has to derive DTS based on PTS, frame order and default time increment. Obviously, DTS may never become greater than PTS. When loading an MKV, Avidemux takes the default time increment and looks how good predicted timing based on this time increment matches the reality. If the match is not very good, it starts to guess.

If a standard FPS value turns out to be close to the value calculated from time increment, Avidemux may decide to switch to the standard value (in this case 24000/1001 FPS) which is lower than the custom value 24350/1000 FPS, i.e. DTS calculated based on this value become higher and higher WRT PTS. Remember, PTS must be >= DTS, so PTS, which are given by the MKV structures (this is why playback in Avidemux is fine), are closer together than DTS and in order to avoid DTS becoming > PTS, all PTS of the video have to be delayed --> we arrive at the incredibly high first frame delay.

[eumagga0x2a]

Now I understand what is the main problem with the 154.mkv sample. It includes a part, starting with the end credits right after the "to be continued" text, with a different frame rate, the FPS of this part is much higher (~30 FPS, likely 29.97). FPS both before and after this part is 23.976. Avidemux can't handle such cases.

As Avidemux currently won't adjust the DTS of the first frame in a MKV, there is also no easy way back to a reasonable first frame delay by saving only the first, regular part of the video in copy mode, but this might be fixable. However, I don't think the ability to handle videos consisting of segments with different FPS is going to arrive soon.

Regarding the crash in VC++ builds loading an external audio, Mean, the author of Avidemux, has fixed it. Please try the latest VC++ nightly (190130 or later).