I have a .ts file from a TV Capture and I need to make an encode to .mkv
I use Handbrake 0.9.9
The audio source is mp2. How can I keep the original audio without encoding to .ac3 or .aac?
ID : 4112 (0x1010)
Menu ID : 1 (0x1)
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 2
Codec ID : 4
Duration : 1h 28mn
Bit rate mode : Constant
Bit rate : 384 Kbps
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Compression mode : Lossy
Delay relative to video : -64ms
Stream size : 244 MiB (4%)
Language : English
Our website is made possible by displaying online advertisements to our visitors. Consider supporting us by disable your adblocker or try DVDFab and copy, convert or make Blu-rays and DVDs! :)
+ Reply to Thread
Results 1 to 15 of 15
Try Auto Passthru
Auto Passthru is encoding the audio to AAC.
The audio source has a Delay relative to video : -64ms.
At warning tab of MKVMerge GUI says:
Warning: 'C:\Users\Administrator\Downloads\file.ts' track 1: This MPEG audio track contains 384 bytes of non-MP3 data which were skipped. The audio/video synchronization may have been lost.
How can adjust this to the output file?
Thank you manono!
VirtualDubMod is one of them. When you open the audio with MKVMergeGUI it removes any junk data and applies an appropriate audio delay instead. For 384 bytes I think it'd probably be close to a 20ms delay. It's not a bad thing. It's keeping the audio/video sync unchanged.
You'll probably find if the audio source was muxed while specifying a delay of -64ms, MKVMergeGUI would (in theory) remove the junk data and then the delay would be something like -44ms, but the MKV spec doesn't allow for negative delays, so MKVMergeGUI would remove as close to 44ms as it can from the beginning of the audio, and apply a small delay to make up any difference (the amount removed can rarely be exact). You might end up with something like a 15ms delay relative to the video (as an example). MKVMergeGUI tends to know what it's doing.
Applying a negative delay when muxing by removing an appropriate amount from the beginning of the audio is pretty standard and rarely a bad thing (it's generally silence anyway). The alternative is not to apply a negative audio delay, but use a positive video delay when muxing instead. MediaInfo will display it as a negative audio delay though, even though technically it's not.
PS If you open a video with MKVMergeGUI and the audio within already has a delay, you shouldn't need to specify it. For example, if you open the encoded video, the original TV capture, deselect the original video stream and save the encoded video and original audio as an MKV that way, the original audio delay (-64ms in your case) should be accounted for. If you also specify a -64ms audio delay, you'll probably end up applying a -128ms audio delay. You should only need to specify the audio delay yourself if you extract it from the original file and add it to the muxing job as an individual stream.
Last edited by hello_hello; 24th Aug 2014 at 12:23.