Hello,
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?
Media Info:
Audio
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
Try StreamFab Downloader and download from Netflix, Amazon, Youtube! Or Try DVDFab and copy Blu-rays! or rip iTunes movies!
+ Reply to Thread
Results 1 to 15 of 15
Thread
-
-
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? -
You can either remove the delay entirely before muxing using DelayCut or, in MKVMergeGUI, highlight the audio (make it dark), hit the 'Format Specific Options' tab, and set that same delay
-
-
In MKVMergeGUI I choose which track I need, and then I'm pressing Start Muxing?
Or should I choose for all tracks, from the Extra Options tab Compress: None?
Thank you! -
Some programs can use non-audio data instead of a delay when muxing. Or they tend to add junk data. I think 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.