Quote:
Originally Posted by manolito
It does not have to. All I would like to see is a behavior which is consistent with the behavior of other software for the identical task.
Let's not talk about the peculiarities of captured transport streams, let's also forget about StaxRip. Let's break it down to a very common task which I need to perform frequently (and other users probably too).
I have a clip in an MKV container, MediaInfo reports a certain audio delay. I need to "beautify" the audio. So I need to extract the audio track, decompress to WAV, do all my nasty tricks in WaveLab (or any advanced WAVE editor), save the WAV and convert it to AAC. The last step is to import this audio track into the original MKV, disable the original audio track and remux it into a new MKV. Very simple...
If I do this using gMKVExtractGUI and MKVToolnixGUI then the result will be out of sync, because the audio delay value is written into the file name of the extracted audio track. All following operations will preserve the filename with the embedded delay value. Remerging it back into the original MKV will honor the delay value, and this results in a sync error.
I will not get sync problems if I use FFmpeg or AviDemux for this task. The reason is simple, this other software does not care for audio delay values. Remuxing the "beautified" audio back into the original MKV will give out a new MKV in perfect sync.
So all I am asking for is consistent behavior. It is too bad that Pashin stopped maintaining his MKVExtractGUI2 software, IIRC the last supported MKVToolnix version was v. 20.
Cheers
manolito
|
I am sorry manolito, but if your usage scenario involves reencoding the extracted audio track, then it certainly can involve renaming the file!
Extracting audio tracks with the exact delay is and will stay the default action since if this information is lost, then the user can't re-merge the original tracks without losing sync.
If someone uses the extracted track for something more complicated than that, then simply renaming the extracted track's filename will suffice.
In the next version, I will add a custom filename creation mode, in order for the user to choose how the extracted filenames are generated.
I guess you can then change the filename generation rule and your problem will be solved.
