mkvtoolnix 4.1.1 released

[Thunderbolt8]

would it be possible to see support for the new HD DVD / blue-ray audio tracks, namely trueHD and dts-hd in the future?

[madshi]

@Mosu: I know all the dirty details you'd need for DTS-HD High Resolution and DTS-HD Master Audio (how to detect them etc). If you're willing to implement support for that, that'd be great! Please PM me, if you're interested in getting that information from me.

To be honest, I'm not sure if TrueHD and DTS-HD Master Audio are really all that important because we can now reencode them losslessly to FLAC. However, DTS-HD High Resolution support would be quite nice to have.

[Thunderbolt8]

from what I heard flac is not compatible to standalone receivers, it can only be used PC related in terms that you can only connect the final output with your speakers, but not to an additional receiver (at least when I understood it correctly). so its good to be able to use the full potential of those tracks currently as flac files. but for the future, when trueHD receivers and alikes become more frequent and cheaper I think for home cinema fans with really good equipment it would be great if they could use their additional non-pc surround hardware then with the original tracks and therefore to be able to mux these tracks into the .mkv

[madshi]

from what I heard flac is not compatible to standalone receivers, it can only be used PC related in terms that you can only connect the final output with your speakers, but not to an additional receiver (at least when I understood it correctly). so its good to be able to use the full potential of those tracks currently as flac files. but for the future, when trueHD receivers and alikes become more frequent and cheaper I think for home cinema fans with really good equipment it would be great if they could use their additional non-pc surround hardware then with the original tracks and therefore to be able to mux these tracks into the .mkv
You heard wrong. FLAC is not limited to PC. Most of the media player boxes out there (e.g. Tvix 5100 etc) support FLAC. They can output it over analog output or (decoded to multichannel PCM) over HDMI 1.1. Every receiver that accepts multichannel PCM over HDMI should handle that just fine.

[honai]

Yes, but I'm not aware of any PC video/soundcard that transports 5-7 channel PCM (fed from a Windows app) over HDMI, so it's still of limited use. Last news I heard is that manufacturers won't be rolling out this feature in the mid-term because of "licensing" (read: DRM) issues.

[madshi]

Yes, but I'm not aware of any PC video/soundcard that transports 5-7 channel PCM (fed from a Windows app) over HDMI, so it's still of limited use. Last news I heard is that manufacturers won't be rolling out this feature in the mid-term because of "licensing" (read: DRM) issues.
HDMI 1.3 bitstream will not come any sooner to HTPC than multichannel PCM. So that's no argument pro TrueHD/DTS-HD. Currently FLAC has an advantage over TrueHD/DTS-HD because it's already supported on HTPC and also by many external media players, while TrueHD/DTS-HD is still difficult to decode perfectly on HTPC and is not supported by *any* external media player yet. I don't really see any argument in favor of TrueHD/DTS-HD MA, unless you want to burn movies to Blu-Ray/HD DVD disc.

[honai]

Currently FLAC has an advantage over TrueHD/DTS-HD because it's already supported on HTPC

It's only "supported" in a sense that it can be losslessly decoded, but must be *lossy* encoded to AC3 (via ffdshow or AC3Filter) or DTS (on some DTS Connect soundcards) in order to be played back on a receiver - which is what most HD enthusiasts do, anyway. Transport over 5+1 analog cinch cables makes no sense because no matter how clean the copper, you'll lose audio quality.

while TrueHD/DTS-HD is still difficult to decode perfectly on HTPC and is not supported by *any* external media player yet

But TrueHD/DTS-HD is being supported by a growing number of inexpensive external audio receivers, while I didn't hear of any receiver yet that supports FLAC over HDMI.

The point I'm trying to make is that in 1-2 years lots of hardware will do realtime decoding or native transport of TrueHD/DTS-HD, but due to the lack of industry lobbying we won't see that kind of support for FLAC. And as I wrote above, FLAC to PCM over HDMI is going nowhere any time soon because we won't have PC hardware for raw PCM transport from arbitrary sources.

And all TrueHD/DTS-HD -> PCM over HDMI solutions so far only work on a protected audio/video path, so you can't just inject your FLAC -> PCM solution there.

[madshi]

@honai, can you please tell me a specific scenario in which TrueHD would have advantages over FLAC? I mean what kind of source device are you thinking about (HTPC or external media player box or something else)? What kind of connection (HDMI 1.1 or HDMI 1.3 or something else) and what kind of receiver (decoding capabilities etc)? Just tell me one example. The best one that comes to your mind.

[honai]

I'm not sure I understand the question. But take this scenario:

* PC with software HD-DVD/Blu-ray player
* HDMI video card that does also transport of HD audio over HDMI
* a/v receiver with HDMI that decodes TrueHD (e.g. Pioneer VSX-91)

Bit-perfect transport of audio until the final decoding stage for speaker output.

How would you achieve that with FLAC? You can't, and I don't see it happening in the next few years. Bit-perfect FLAC transport over digital connections to the final decoding stage just isn't possible.

[foxyshadis]

What is the use of it if you can just losslessly re-encode back to one of these formats if a card or directshow filter supporting them ever does appear? Better to have something that plays right now than something that might play next year.

And since no video card supports multichannel pcm to the receiver right now anyway, it's all a moot point. When the chain is complete, you could translate anything back to TrueHD or Master Audio on the fly the same way we currently can for AC3, although it might use another percentage point or two of cpu.

[madshi]

I'm not sure I understand the question. But take this scenario:

* PC with software HD-DVD/Blu-ray player
* HDMI video card that does also transport of HD audio over HDMI
* a/v receiver with HDMI that decodes TrueHD (e.g. Pioneer VSX-91)

Bit-perfect transport of audio until the final decoding stage for speaker output.

How would you achieve that with FLAC? You can't, and I don't see it happening in the next few years. Bit-perfect FLAC transport over digital connections to the final decoding stage just isn't possible.
Your example would only work if both video card and receiver have HDMI 1.3. If they have HDMI 1.3 they will also support multichannel PCM transport. So FLAC can be decoded by the PC and sent as multichannel PCM to the receiver. This *is* bit perfect transport over digital connection. It doesn't matter if you transport bitstream or PCM. Audio quality is identical. So in your example FLAC has no disadvantage compared to TrueHD.

[honai]

If they have HDMI 1.3 they will also support multichannel PCM transport.

No, not in a generic way. So far all announced solutions only work on protected audio and video paths, i.e. bit-perfect transport is only enabled for certified players like PowerDVD and WinDVD which pass the audio stream directly to a DRMed a/v driver. So this will *not* work for FLAC tracks.

So in your example FLAC has no disadvantage compared to TrueHD.

It does because FLAC is not supported by any HD disc standard, and that's the only source that will be transported over HDMI 1.3 by the two major HD disc software player manufacturers.

[madshi]

No, not in a generic way. So far all announced solutions only work on protected audio and video paths, i.e. bit-perfect transport is only enabled for certified players like PowerDVD and WinDVD which pass the audio stream directly to a DRMed a/v driver. So this will *not* work for FLAC tracks.
I've no idea what you mean. What "announced solutions" are you talking about?

It does because FLAC is not supported by any HD disc standard, and that's the only source that will be transported over HDMI 1.3 by the two major HD disc software player manufacturers.
So you're claiming that PowerDVD and WinDVD will support TrueHD bitstream transport but not multichannel PCM transport? Can you please back this claim up? Because I think you're totally wrong here.

[honai]

I've no idea what you mean. What "announced solutions" are you talking about?

For example, video cards with nVidia chips that provide HDMI 1.3, i.e. a/v transport over HDMI. These have a protected BIOS (using public/private key cryptography), and only players signed against that BIOS will be able to send HD audio/video over the HDMI connection.

So you're claiming that PowerDVD and WinDVD will support TrueHD bitstream transport but not multichannel PCM transport?

No. I'm saying that PowerDVD and WinDVD can certify to the protected video path that they're secure, and they can honor the DRM flags in the source. So if you're playing a DRMed HD disc with either TrueHD or PCM over HDMI it will work, but it won't for arbitrary PCM streams. PCM over HDMI is not something that is "just there" in the system. You need a specific player software, a specific driver setup, and a specfic video card BIOS (because HD audio over HDMI is routed through the video card) for all of this to work.

[madshi]

For example, video cards with nVidia chips that provide HDMI 1.3, i.e. a/v transport over HDMI. These have a protected BIOS (using public/private key cryptography), and only players signed against that BIOS will be able to send HD audio/video over the HDMI connection.
Do you have a link? I think you have that backwards. It would be a big step down for any nVidia card user if people couldn't even output unprotected movies over HDMI (and that's what you're claiming). E.g. all the Microsoft VC-1 demos you can download from Microsoft's homepage wouldn't play. No recorded HDTV broadcast would play. That simply cannot be true.

[honai]

That's not what I intended to express. Let me clarify:

For example, video cards with nVidia chips that provide HDMI 1.3, i.e. a/v transport over HDMI. These have a protected BIOS (using public/private key cryptography), and only players signed against that BIOS will be able to send HD audio/video from HD-DVD/Blu-ray discs over the HDMI connection.

In other words, of course you can send arbitrary video over HDMI (i.e. the DVI part of it), but if I recall correctly the current implementations of HDMI 1.3 on video cards don't provide a system-wide audio driver at all, i.e. you won't be able to send arbitrary audio samples over HDMI at all - unless you run a specific player which directly communicates with the (nVidia) video card protected BIOS, in which case you *can* send TrueHD/PCM over HDMI.

[Thunderbolt8]

another thing, it would also be great if .evo and . m2ts container as input could be supported!

[madshi]

For example, video cards with nVidia chips that provide HDMI 1.3, i.e. a/v transport over HDMI. These have a protected BIOS (using public/private key cryptography), and only players signed against that BIOS will be able to send HD audio/video from HD-DVD/Blu-ray discs over the HDMI connection.

In other words, of course you can send arbitrary video over HDMI (i.e. the DVI part of it), but if I recall correctly the current implementations of HDMI 1.3 on video cards don't provide a system-wide audio driver at all, i.e. you won't be able to send arbitrary audio samples over HDMI at all - unless you run a specific player which directly communicates with the (nVidia) video card protected BIOS, in which case you *can* send TrueHD/PCM over HDMI.
You're wrong. The video cards do provide a system-wide audio driver. At least the ATI cards do. And it can be used from MPC.

[honai]

You're wrong. The video cards do provide a system-wide audio driver.

A system-wide audio driver that acts as a renderer and actually transports multi-channel PCM over HDMI? Do you have documentation for that or screenshots?

[madshi]

A system-wide audio driver that acts as a renderer and actually transports multi-channel PCM over HDMI? Do you have documentation for that or screenshots?
I didn't say that it transports multichannel PCM over HDMI. Right now it seems that it only supports multichannel AC3 transport or 2 channel PCM transport. But it does seem to be an audio "target" you can speak to from a normal media player. You can check out the ATI 2x00 owners thread on avsforum. They're discussing it there. Search for "PCM" in that thread.

[honai]

Well, but that's the argument here. 2-channel PCM transport (presumably over SPDIF) is useless for HD audio since the limit is 640kbps/1536kbps. Multi-channel PCM transport over HDMI is the issue, and I stand by my argument: it's only possible by way of special player applications which only support TrueHD/DTS-HD/PCM from HD disc sources, not FLAC or any other DirectShow-bridged format.

[madshi]

Well, but that's the argument here. 2-channel PCM transport (presumably over SPDIF) is useless for HD audio since the limit is 640kbps/1536kbps. Multi-channel PCM transport over HDMI is the issue
You're missing the point. I never claimed that the ATI card would do multichannel PCM transport. It doesn't. Nor does it do TrueHD nor DTS-HD. Neither from MPC nor from PowerDVD nor from WinDVD. I mentioned the ATI card because you claimed that there'd be no system-wide audio driver for the audio part of a HDMI enabled video card - and you're clearly wrong there.

it's only possible by way of special player applications which only support TrueHD/DTS-HD/PCM from HD disc sources, not FLAC or any other DirectShow-bridged format.
Have you found a link to backup this claim in the meanwhile? I believe you're wrong.

[honai]

because you claimed that there'd be no system-wide audio driver for the audio part of a HDMI enabled video card

Well, it doesn't take much creativity to interpret my claim correctly: There's no system-wide audio driver for transporting HD audio over HDMI.

Actually, that's what I wrote:

but if I recall correctly the current implementations of HDMI 1.3 on video cards don't provide a system-wide audio driver at all, i.e. you won't be able to send arbitrary audio samples over HDMI at all

[Brother John]

Humble question, madshi, honai. How is your discussion over the last 10-15 posts relevant to MVKToolnix? Actually I have a hard time figuring that out. And if it was not relevant, wouldn’t it be better to continue this in a separate thread?

[madshi]

@Brother John, the discussion was about the question whether it's worth adding TrueHD muxing support to mkvtoolnix. But you're right that it got too much OT, so I'll stop discussing now.

[Tima]

I have an issue with MMG -- it's not possible to remux an existing mkv (in my case it's avc + ac3) with different frame rate -- the field for fps is grey.

Waiting for a fix if it's possible. :)

[foxyshadis]

You have to use a timecode file for that. The only format fps is enabled for is raw h.264 (afaik), and only because mkvmerge isn't capable of reading the real framerate out of it. (Since it can in all other formats, the option is disabled.)

My understanding is that forcing timecodes keeps people from screwing up their sync all the time, but I'm not mosu.

[Mosu]

another thing, it would also be great if .evo and . m2ts container as input could be supported!

.evo is accepted, but I think that mmg's "open file" dialog doesn't list it. But drag & drop should work, as should selecting "all files" in the "open file" dialog and then selecting the .evo.

Transport streams (m2ts) are not supported and will probably not be supported in the near future.

[Mosu]

I have an issue with MMG -- it's not possible to remux an existing mkv (in my case it's avc + ac3) with different frame rate -- the field for fps is grey.

Waiting for a fix if it's possible. :)

That's not a bug. mkvmerge's "--default-duration" parameter (which is the one that is used for this particular field in mmg) only works with a select number of formats, especially with those that do not contain timecode/FPS information in them. The example foxyshadis has pointed out is the usual case where'd you use this parameter. Raw h264 tracks only contain the frames itself, but neither a timecode for each frame nor a frame rate in general. But for most of the other container/raw formats mkvmerge can actually derive the timecodes from them. Therefore the control is disabled in mkvmerge.

Note that in Matroska you don't simply have a FPS field in a header that you can simply change as you have in an AVI file. In Matroska each frame has its own timecode. Therefore changin the FPS always requires remuxing the whole file.

If you definitely must change all the timecodes then you have to use timecode files, just as foxyshadis has pointed out.

[ssjkakaroto]

Hi there Mosu, I'm having a issue with v2.1.0 here:

Whenever I try to convert a OGM file (doesn't matter which) to MKV the file is unplayable, Haali Splitter+MPC report the file having 00:00.

If I convert the files using v2.0.2 (build 20070426) the MKV files work fine.

As I said this happens with any OGM file here but I can upload one to you if needed.

[Tima]

Raw h264 tracks only contain the frames itself, but neither a timecode for each frame nor a frame rate in general. But for most of the other container/raw formats mkvmerge can actually derive the timecodes from them. Therefore the control is disabled in mkvmerge.

Note that in Matroska you don't simply have a FPS field in a header that you can simply change as you have in an AVI file. In Matroska each frame has its own timecode. Therefore changin the FPS always requires remuxing the whole file.

I understand, but in my case it's raw AVC track inside mkv, if I understand correctly. So for me there seems no problem to REmux it with another framerate.

[KoD]

Tima, use a timecode file. Just go to Start -> All Programs -> MKVtoolnix -> Documentation -> Command Line Reference -> mkvmerge CLI reference and read the chapter on External Timecode Files. You'll see that it's really simple and you don't have to use the CLI either, the GUI can do it too.

In your case, just make a text file, write something like # timecode format v1
assume 23.970
inside it, and then remux your file using that timecode for the video track. How to do it in the mkvmerge GUI should be easy to figure out.

Note:
1. change 23.970 with whatever fps value you want.
2. if your h264 video is vfr though, you can't do anything since you most likely don't know the timestamps for each frame.

[Rectal Prolapse]

KoD, actually the value should be 23.976. 24/1.001 = 23.976. :)

[Thunderbolt8]

mosu, is there any chance to have dts-hd (ma & hr) and trueHD support, in .mka or .mkv for example? would be nice to have for all those upcoming hd dvd and blue-ray remuxes ;)

[End_of_Eternity]

Hi, I am trying to use mkvmerge to split an H264 mkv file into two parts. The first part file is created without any problems, soon after the second file is created mkvmerge crashes.

I am using latest version on Windows Vista, this is the crash info that I get:

Problem Event Name: APPCRASH
Application Name: mkvmerge.exe
Application Version: 0.0.0.0
Application Timestamp: 46c82da7
Fault Module Name: msvcrt.dll
Fault Module Version: 7.0.6000.16386
Fault Module Timestamp: 4549bd61
Exception Code: 40000015
Exception Offset: 00065d45
OS Version: 6.0.6000.2.0.0.768.3
Locale ID: 1033
Additional Information 1: 98bc
Additional Information 2: 744c5eb18e59789eb9c90085a0575d9d
Additional Information 3: 87a2
Additional Information 4: 861d039c8c7d8f1f8ede4cf681494220

I tried splitting using timecodes and the "after duration" function. Both crash at the same point.

The mkv file was created using meGUI with the latest updates. I keep my system pretty clean and I don't have any spyware/crap installed.

Is there any other info I can give you guys to find out the root cause of this crash?

[Mosu]

Hi there Mosu, I'm having a issue with v2.1.0 here:

Whenever I try to convert a OGM file (doesn't matter which) to MKV the file is unplayable, Haali Splitter+MPC report the file having 00:00.

Yes, please upload a file. The OGM files I have here don't show this behaviour, so I'm not sure what could be wrong (especially as I haven't worked on the OGM reader for quite some time). Maybe uploading the first 50 MB or so should be enouh for me to check it out.

[Mosu]

mosu, is there any chance to have dts-hd (ma & hr) and trueHD support, in .mka or .mkv for example? would be nice to have for all those upcoming hd dvd and blue-ray remuxes ;)

I've just received some info from madshi regarding DTS-HD, so it should be possible for me. However, I don't do a lot of coding at the moment, so don't hold your breath.

[Mosu]

Hi, I am trying to use mkvmerge to split an H264 mkv file into two parts. The first part file is created without any problems, soon after the second file is created mkvmerge crashes.

Yeah, I know that there are a couple of problems with mkvmerge's handling of h264 splitting (not only that; the problems are more profound, it's just that h264's frame ordering can be a lot more problematic that other codec's, that's why mkvmerge's simplified assumptions work on most codecs but sometimes not on h264). I don't have an ETA for a fix.

[Thunderbolt8]

I've just received some info from madshi regarding DTS-HD, so it should be possible for me. However, I don't do a lot of coding at the moment, so don't hold your breath.
well it does not have to be done by the end of the day, but it would be nice to have it before UHD or something like that with new file systems (which would need support too), becomes a new standard :P
thanks!

[ssjkakaroto]

Yes, please upload a file.Done.

[Liisachan]

Hi, Mosu, a small thing about mmg 2.1.0 Unicode.
The 'tags' (title info etc) in Ogg (Ogg vorbis in my case) are in UTF8,
still MMG reads it as the current ACP (wrong assumption!) to fill the Track name editbox,
resulting a broken string.
If I type a text directly into the "Track name" editbox of mmg,
mmg is happy to accept a Unicode string.
It is just that it cannot 'extract' it from Ogg.
Plus, it complains:
Warning: The Ogg/OGM file ... contains chapter or title information. Unfortunately the charset used to store this information in the file cannot be identified unambiguously. mkvmerge assumes that your system's current charset is appropriate.

This might be so for OGM, but Ogg has well-defined specs, which say Tags are written in UTF-8.
Besides, if the "Track name" editbox is used, the TITLE from Ogg is ignored, so the above warning is maybe pointless and at least confusing. Well, --chapter-charset UTF-8 does work tho...

IMHO, for texts from Ogg, UTF-8, not the Users ACP, should be assumed. Just a thought. No practical trouble at all :)
Thank you very much!

[Liisachan]

Another thing. Tags (such as Title) at the end of .wv file are dropped when muxed to MKV/MKA, with the "Warning: wavpack_reader: non-audio block found".

[dukey]

could mkvextract write the audio delay in the audio filename ?
That would be useful.

Plus, how can one tell what the audio delay is for an mkv file ?

[Isochroma]

I second that motion.

[foxyshadis]

could mkvextract write the audio delay in the audio filename ?
That would be useful.

Plus, how can one tell what the audio delay is for an mkv file ?

I don't think mmg creates a soft delay for most audio formats, it'll pad with blank frames instead.

[delacroixp]

I don't think mmg creates a soft delay for most audio formats, it'll pad with blank frames instead.
I know nothing about 'mmg and mkv' so it's gr8 to add an interesting thought to the database...


:):devil::D
Pascal

[foxyshadis]

Really? That's what this whole thread is about, mkvmerge and mmg.

What I meant by the comment is that after you mux, you no longer have any delay at all. You could demux and sync would be maintained. I'm not sure if this is the case for all formats, but definitely is for vorbis.

[J_Darnley]

foxyshadis is correct. The mkvmerge docs say:
-y, --sync
Synchronize manually, delay the audio track with the id TID by d ms. The track IDs are the same as the ones given with −−identify (see section TRACK IDS).
d > 0: Pad with silent samples.
d < 0: Remove samples from the beginning.
o/p: adjust the timestamps by o/p to fix linear drifts. p defaults to 1000 if omitted. Both o and p can be floating point numbers.
Defaults: no manual sync correction (which is the same as d = 0 and o/p = 1.0).
This option can be used multiple times for an input file applying to several tracks by selecting different track IDs each time.
The silent sample only apply to vorbis tracks for AAC, AC3, DTS and MP3 it will duplicate the first frame. The docs say this list is outdated so Mosu or someone else will need to confirm.

Basically this means that once you use mkvmerge to manually sync an audio track it will be altered to be (approximately) that much longer or shorter so that if you ever need to remux you do not need to specify a delay for that track.

[Thunderbolt8]

dont know if this has already been mentioned, but mkvmerge sometimes has not only problems with avc files, which were ran through gdsmux before, but also with some broadcasted mpeg2 files.
I remuxed about 6 of those recently and about 3-4 had a little video stutter at some frames in between. this doesnt result in sync issues though, but still looks well, not fluently when this occurs of course. its a small stop of the video 0,25-0.5 seconds, followed by a quick acceleration to have the video back in sync. this wasnt the case with the source .ts file and also not when it was remuxed with gdsmux, only after another mux with mkvmerge afterwards.
when I demux the streams with xport and then just mux them with mkvmerge then everything is fine.

[madshi]

dont know if this has already been mentioned, but mkvmerge sometimes has not only problems with avc files, which were ran through gdsmux before, but also with some broadcasted mpeg2 files.
I remuxed about 6 of those recently and about 3-4 had a little video stutter at some frames in between. this doesnt result in sync issues though, but still looks well, not fluently when this occurs of course. its a small stop of the video 0,25-0.5 seconds, followed by a quick acceleration to have the video back in sync. this wasnt the case with the source .ts file and also not when it was remuxed with gdsmux, only after another mux with mkvmerge afterwards.
when I demux the streams with xport and then just mux them with mkvmerge then everything is fine.
Have you tried rewriting the timestamps? Another thing worth trying would be demuxing audio and then muxing a new MKV, where video comes from the "bad" MKV and audio comes from the demuxed audio files. That has worked for me sometimes to fix stuttering issues.