Recompressing MKV audio

[Jorpho]

Short version:
What's the most reliable way to recompress the audio track of an MKV?

Long version:
After much struggle I finally found a reliable way to capture video from my old tuner card on my old computer: with the Matroska-enabled build of VirtualVCR. While there are dropped frames, the audio constantly stays in sync, presumably because of the variable frame rate.

The problem is that the resulting files are huge, particularly because the audio track is uncompressed PCM WAV. I've tried to recompress the audio track by using mkvextract to extract the audio, using LAME to compress the extracted track (at 320 kbps cbr), and then using MKVmerge to mux the original video track and the compressed audio. This trick works fine with short videos, but there's a noticeable amount of desynchronization at the end of long videos.

Is there a better way of doing this than what I have described? I don't mind keeping the videos as MKV, and I suspect the desynchronization will get even worse if I try any fancy conversion anyway.

[Baldrick]

I think you have to manually set the framerate in mkvmerge when you remux. Did you set it correctly? Or maybe not if you are using the original mkv...

Have you compared the new mp3 audio runtime and the video runtime? are they same?

[Jorpho]

Thanks for replying. I am indeed using the original mkv. I have no idea what the framerate might be doing. (Am I incorrect in my assumption that VirtualVCR-Matroska deals with skipped frames by constantly shifting the frame rate?)

Anyway, according to VirtualDubMod, the two mkvs (one with uncompressed audio, one with compressed audio) both have video runtimes of exactly the same length. However, the uncompressed audio somehow ended up with 167,950,877 samples (1:03:28.41), while the compressed audio's length is 167,980,826 samples (1:03:29.08).

Is LAME really the best tool for this?

[MysticE]

You might try Avidemux. You can use copy for the video then under Audio try one of the various options. Under Format choose MKV and when you save use a complete filename, xxxx.mkv.

[guns1inger]

Xvid4PSP can read and write MKV files. Make sure you set video to copy and you can re-encode the audio to whatever you need to.

[Jorpho]

Xvid4PSP can read and write MKV files. Make sure you set video to copy and you can re-encode the audio to whatever you need to.

Hmm. The result is almost exactly the same size as what I produced manually with LAME. Even the audio stream is the same length and the same number of samples. And it seems to be just as badly out of sync at the end, if not worse.

Avidemux won't do anything differently, I reckon. (Actually, for some reason it says that it can't find an audio decoder, and that "Save (A+V) will generate bad AVI" !)

[Jorpho]

Hmm. Seems even a splitting operation executed with mkvmerge GUI - with no re-encoding - is enough to throw things off!

[poisondeathray]

I'm not familiar with virtualvcr, but if what you say is true:

with the Matroska-enabled build of VirtualVCR. While there are dropped frames, the audio constantly stays in sync, presumably because of the variable frame rate.

then using mkvextract , then mkvmerge without timecodes will cause sync errors. You can get around this by using the original mkv, use mkvmergegui to add in the 2nd audio track, uncheckmark the 1st audio track instead of using mkvextract at all. Also, any delay offset is lost when you use mkvextract, compounding the sync issues - another reason not to use mkvextract. By leaving the original mkv structure intact, the timecodes should be intact, and sync should be fine using this method

Another method if you wanted to use the extracted streams is to mux a new mkv, but using the timecodes sheet. You can get the timecodes file from using mkv2vfr (included in the haali media splitter package), the syntax is:

mkv2vfr input.mkv output.avi timecodes.txt

[Jorpho]

By "splitting" I mean using the "Global" tab in mkvmerge GUI and splitting the original mkv after a certain duration, without doing any audio or video extraction. Would that cause the timecodes to be lost as well? (What are these "timecodes" exactly, anyway? Is there somewhere I can read more about them?)

[poisondeathray]

I don't know if splitting will cause loss of timecodes. I don't even know if your video is compliant to modern mkv standards, I think virtualvcr is pretty old and the mkv container has had changes.

I do know if your .mkv is truly vfr, you won't keep sync unless you do what was suggested above

The timecodes specify different points where the frame rate changes. The intervals specified by these timestamps that vary with VFR video, instead of being a constant rate in the case of CFR. On playback, it tells the player to display at different speeds, according to the timestamps.

Unfortunately, the information is scattered all over, on anime sites, Doom9, you have to do some searching .... I don't know of any great concise place where all the info is documented. You can check the avisynth site for "vfr", there is quite a bit there as well

[Jorpho]

I tried extracting the timecodes from one of my original mkvs and from an mkv derived from that original, with re-encoded audio. The resulting text files each had over 100,000 lines - but they were completely identical.

[Midzuki]

How about opening the "bad" MKV file in Graphedit and
posting a screenshot of the result? Just a wild guess ---
--- perhaps the MP3 audio is being decoded by a "wicked" filter which
does not interact very well with the Matroska splitter.


\\\\\

[Jorpho]

(Hmm, someone needs to fix the "Author Site" link before someone thinks he needs to download the 450MB DirectX SDK.)

[Jorpho]

Okay, the difference is that the uncompressed audio is going directly to the default DirectSound device, but the compressed audio is going through the ffdshow Audio Decoder first. In either case the ffdshow Video Decoder is used for the video.

Files that were only split (duration-wise) also have audio that go directly to the default DirectSound device.

[poisondeathray]

If the timecodes show constant intervals, you can say with certainty it's not vfr.

Did you try the 1st method? i.e. mux the lame converted mp3 into the original mkv, and uncheckmark the pcm ?

If you convert to AAC or vorbis, is the audio duration the same as the lame MP3 converted file?

Are you using CLI version of lame? which one? If you use another version of lame, or a different encoder e.g. eac3to, does the audio duration remain the same ?

[buzzqw]

have you tryed ffmpeg ?

ffmpeg -i mymovie.mkv -vcodec copy -acodec libmp3lame -ab 128k mymovie2.avi

BHH

[Baldrick]

(Hmm, someone needs to fix the "Author Site" link before someone thinks he needs to download the 450MB DirectX SDK.)

Where can I find graphedit on microsofts site then?

[Delta2]

there is none, GraphEdit is part of Platform SDK now