mkvtoolnix 1.6.5 is out

[Booji Boy]

There may be a bug or maybe I'm just doing something wrong here: when I join two videos in one first go and in the second run I mux the single video again but add the subtitles of both parts (I do append the subtitles of the second video in the list), then afterwards the subtitles will disappear in the second half of the movie. When I mux everything at once (both two videos and two subtitles) the subtitles show up during the whole movie... what am I doing wrong? I noticed this when I used some other tool for joining two videos and wanted to add the subtitles with mkvmerge+mmg.

And I also noticed that the second half of subtitles joined by mkvmerge and those joined by Subtitle Workshop differ by a few milliseconds, why is that?

[Tima]

Bugs in mkvmerge GUI:
When I stretch an AC3 track e.g. by factor 1001/960, after trying to start muxing I get this:
---------------------------
mkvmerge GUI: error
---------------------------
The stretch setting for track nr. 0 in file 'E:\DVD\VTS_06_1 T02 2_0ch 256Kbps DELAY 0ms.ac3' is invalid.
---------------------------
ОК
---------------------------
The generated commandline is following:
"mkvmerge" -o "C:\Дневной Дозор.mkv" --priority lower --language 1:rus --default-track 1 --display-dimensions 1:720x298 -d 1 -A -S E:\DVD\Pr_DayWatch\project.mkv --language 0:rus --sync 0:0,1001/960 -a 0 -D -S "E:\DVD\VTS_06_1 T02 2_0ch 256Kbps DELAY 0ms.ac3" --language 0:rus --sync 0:0,1001/960 --compression 0:zlib -s 0 -D -A E:\DVD\Pr_DayWatch\project.sub.rus.idx --track-order 0:1,1:0,2:0 --title "Дневной Дозор" --split size:795 --split-max-files 2 --link
When i execute this commandine manually, it works ok.

[Warpman]

i tried to mux with that
"mkvmerge" -o "TESTENC1.mkv" -d 1 -A -S "TESTENC1.mp4" -a 1 -D -S "neu3.mp4" --track-order 0:1,1:1

mmg crash at the begin of the muxing

log-->
mkvmerge v1.6.5 ('Watcher Of The Skies') built on Dec 7 2005 18:53:31
'TESTENC1.mp4': Using the Quicktime/MP4 demultiplexer.
'neu3.mp4': Using the Quicktime/MP4 demultiplexer.
/log
Error ->Muxing FAILED Return code -1073741676

One mp4 is a mp4 stream created by x264 build 438 (works in mpc) build by cronocross
And the other is a LC-AAC File created by Nero Soundtrax (works in mpc)

Someone know whats going wrong there?

EDIT: Yamb did mux both streams into 1mp4 without a problem ... plays fine too

[Mosu]

There may be a bug or maybe I'm just doing something wrong here: when I join two videos in one first go and in the second run I mux the single video again but add the subtitles of both parts (I do append the subtitles of the second video in the list), then afterwards the subtitles will disappear in the second half of the movie.[quote]

Hmmm that could be a peculiarity of how mkvmerge appends subtitles. You should always append the subtitles at the same time that you append the video tracks in order to achieve proper subtitle synchronisation. The reason is that subtitle files don't have a "duration" for the whole subtitle file stored in them, so mkvmerge doesn't know by how much to shift the timecodes of the second subtitle file.

An example. Your first movie track is 50 minutes long, the second one 55 minutes. Your first subtitle file contains its last entry at 45 minutes, and the second subtitle file's first entry is at 2 minutes. Now where should mkvmerge put that "2 minutes" entry in the resulting file? At 52 minutes, obviously, but mkvmerge cannot know that if it doesn't have access to the first movie track source file.

[quote]When I mux everything at once (both two videos and two subtitles) the subtitles show up during the whole movie... what am I doing wrong? I

Nothing; this is normal mkvmerge behaviour. Unfortunately this isn't documented anywhere... I have to do that on of these days.

And I also noticed that the second half of subtitles joined by mkvmerge and those joined by Subtitle Workshop differ by a few milliseconds, why is that?

Same reason as above. If you use a subtitle editor and join the two subtitle files that I've used in the example then the "2 minutes" entry would be at "47 minutes" and not at the expected "52 minutes" because a subtitle file's duration can differ a lot from the corresponding movie's duration.

[Mosu]

Bugs in mkvmerge GUI:
When I stretch an AC3 track e.g. by factor 1001/960, after trying to start muxing I get this:

I'll fix this some day. Thanks for reporting.

Please note that the "stretch" option only changes the timecodes, not the contents. So depending on the decoders/player/filter chain this might or might not work out alright.

[Mosu]

i tried to mux with that
"mkvmerge" -o "TESTENC1.mkv" -d 1 -A -S "TESTENC1.mp4" -a 1 -D -S "neu3.mp4" --track-order 0:1,1:1

mmg crash at the begin of the muxing

Nah, it's mkvmerge, not mmg that's crashing ;)

Anyway. Looks like you found a bug in mkvmerge's MP4 handling code. Please download http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-1.6.5-build20060203-1.rar and unpack it into your installation directory. Then re-run your muxing job.

If it still crashes then I'll need the file itself in order to find the problem. If you want you can upload the file to my FTP server (see my signature).

[Warpman]

Nah, it's mkvmerge, not mmg that's crashing ;)

Anyway. Looks like you found a bug in mkvmerge's MP4 handling code. Please download http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-1.6.5-build20060203-1.rar and unpack it into your installation directory. Then re-run your muxing job.

If it still crashes then I'll need the file itself in order to find the problem. If you want you can upload the file to my FTP server (see my signature).
ok the avc stream seems to the problem ...
muxing the lc aac alone into mkv works
muxing the avc alone failed
but if i generade a new mp4 with the same command line it works

i could upload the avc stream but it is 150mb big... that ok ?
uploaded it.. filename :"not possible to mux into mkv.mp4"

edit: your new build makes no change...
but it could be that mp4 output in x264 is borked again...

[DiMiTRiH]

Hey,

I have exacly the same problem.

I'm using:
Mkvtoolnix 1.6.5 (+the new build)
x264 rev439
Megui 0.2.3.2090

I did encode in Megui by x264.exe intro .mp4 format. It took me 12h of encoding btw. After that i tried to mux that into .mkv with audio, two subs and external font. Problem is the same, mkvmerge crash at begin. The wierd thing is that when i encoded into .mp4 by Nero Recode2 (Nero Digital H264) it worked fine even on mkvmerge 1.4.2 version. And now the wierd part. My Friend took the same encode in Megui with one difference. He made not .mp4 file in ouput but .mkv. Thats weird cause it somehow had to be muxed in mkvmerge. And the thing is his muxing while encoding the whole thing didn't crash. I used exacly the same specs on x264 cfg for the encode and mkv merge crashing at me =/

When I add the file in mmg its showed as:
avc1
But when i open my friend's mkv in mmg it shows the video as
V_MPEG4/ISO/AVC

Anyone got any ideas how to crack this thing ? Without making another encode in megui to .mkv instead of .mp4 ?

[Warpman]

could be possible that mp4 output of large files of x264 is borked again... so mmg cannot mux it or crashes ...

maybe mosu can clear things up here ;)

[bond]

the only recent change in gpac i know was that jeanlf experimented with setting the duration after the ctts values and not after stts (difference because of the b-frames delay)
but this has been reverted to the old way of handling it again (after stts, not taking the delay into account)

no idea if mkvmerge cares about the duration value in mp4 tough...

[Warpman]

hm well yamb can mux the mp4 file maybe no problem of gpac?

[bond]

whats the framerate of the mp4? maybe mkvmerge also has problems handling 64bit mdhd atoms?

[Mosu]

i could upload the avc stream but it is 150mb big... that ok ?
uploaded it.. filename :"not possible to mux into mkv.mp4"

Ok thanks. I'll take a look at it when I find the time.

[Mosu]

whats the framerate of the mp4? maybe mkvmerge also has problems handling 64bit mdhd atoms?

Possible. I know why mkvmerge crashes, but I'm not sure how to fix it.

What is the layout of 64bit mdhd atoms? At the moment i use this structure:

typedef struct PACKED_STRUCTURE {
uint8_t version;
uint8_t flags[3];
uint32_t creation_time;
uint32_t modification_time;
uint32_t time_scale;
uint32_t duration;
uint16_t language;
uint16_t quality;
} mdhd_atom_t;

How do I know that the mdhd is a 64bit one?

[DiMiTRiH]

The only way to get working x264 encode in .mkv is to use MeGUI and encode directly to .mkv. After the encode you can simply use mmg to add own subs,fonts,chapters etc... Remuxing will not cause a crash

[bond]

the layout is the same. 64bit values for the times and duration are signalled by setting the version to 1

btw the specs are freely available here (http://standards.iso.org/ittf/PubliclyAvailableStandards/c041828_ISO_IEC_14496-12_2005(E).zip)

[Warpman]

whats the framerate of the mp4? maybe mkvmerge also has problems handling 64bit mdhd atoms?
framerate: 23,976 fps

[bond]

framerate: 23,976 fpsif you used avisynth as source that propably triggered the 64bit mdhd

avisynth devs work at changing the way avisynth signals 23.976, but i dunno the status:
http://forum.doom9.org/showthread.php?t=104681

[Egh]

Best way to have avc in mkv -- use Nero :p

Never had any problems with high-profile streams from nero and mkvmerge for ages. Well, apart from appending problems since for some reasons fragments encoded with same settings might have different codecprivate. For that I'm waiting Mosu to implement that advanced switch. But, apart from that, no problems at all.

And those who suggested encoding straight in mkv in x264: i think that in some builds of x264, at least, that's probably worst solution :) Once i had my 10-12h encode screwed up by that, I never used that option. IIRC it's recomended to encode into raw h264 streams to avoid possible bugs.

[Warpman]

if you used avisynth as source that propably triggered the 64bit mdhd

avisynth devs work at changing the way avisynth signals 23.976, but i dunno the status:
http://forum.doom9.org/showthread.php?t=104681
right the source is a avs-script....

i want x264 output to mkv but unfornatly i forget to change it to mkv... :(

[Mosu]

The MP4 problems with 64bit MDHD atoms and some timecode overflow issues should be solved in http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-1.6.5-build20060227-2.rar

[Warpman]

Mosu you make my day ^^ thanks ^^ :D

[Mosu]

Mosu: any key to disable strict check on AVC streams merge? I mean when codec private data is same length but different content.

1.6.0 older builds mux everything fine, and since last build for 1.6.0 and 1.6.5 mkvmerge fails to merge those.

Well, I've changed mkvmerge's bahaviour -- again :) Now it will refuse to concatenate streams with differing parameters (think "number of channels" or "picture width/height"), but it'll allow differing codec private contents. In the latter case it will print a big fat warning message, and I might chose not to give support for playback issues with such files.

But then again there are cases where it should "just work".

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-1.6.5-build20060227-3.rar

[Egh]

Well, I've changed mkvmerge's bahaviour -- again :) Now it will refuse to concatenate streams with differing parameters (think "number of channels" or "picture width/height"), but it'll allow differing codec private contents. In the latter case it will print a big fat warning message, and I might chose not to give support for playback issues with such files.


10x! I think in most cases that would work if encoding settings (like b-frames, h264 deblocking preset and so on) are same. For my purposes they ARE same, but codecprivate is different (the only setting i'm changing for different fragments is bitrate). I'll try the new version when I need to append avc fragments next time (working on xvid project atm, where no such issues arise, of course).

[Mosu]

10x! I think in most cases that would work if encoding settings (like b-frames, h264 deblocking preset and so on) are same.

I agree. However, mkvmerge simply discards the second and all following CodecPrivates. The warning is simply present so that users don't think that mkvmerge can actually perform magic ;) and fixes the CodecPrivate or the bitstream.

I'll try the new version when I need to append avc fragments next time (working on xvid project atm, where no such issues arise, of course).

Let me know how it works out for you.

[Egh]

Hello!

Now im trying to tame notorious "Ordeal chapters" in mkv :P

It's probably most sophiscated shaman tribe-dance with mkv i performed so far.

So, in order for the segments to be merged by haali splitter on playback, they have to satisfy many (imo FAR too many!) conditions, amongst those would be bit-to-bit IDENTICAL codecprivate parts for each and every track in each segment.

That said, it's seems to be easy. But, matroska uses a hack :P to store additional fields for ssa/ass tracks. So e.g. if you mux .ass files straight from aegisub, codecprivate will be different cause there're additional fields like video/audio files used and other subeditor-specific info. And styles section is written into CP as well.

That could still be reasonable. But ... taking Events section is a step too far :P It writes Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text line and THEN it writes next TWO commented lines which follow (whatever they are, and iirc even using empty line didn't help, those commented lines were still taken...).

So I'd say the latter is a bug, right? What's the point in writing comments lines which are in events section of the ass into codecprivate? :confused: (but happy with myself that i discovered that behaviour, using mkvinfo -g and hex editor :P)

[Mosu]

So I'd say the latter is a bug, right? What's the point in writing comments lines which are in events section of the ass into codecprivate? :confused:

Not really. This was done due to user requests which complained that comments inside the events were completely removed when stored in a mkv file. They can't be stored in the entries either, so I put them into CodecPrivate.

[Egh]

Not really. This was done due to user requests which complained that comments inside the events were completely removed when stored in a mkv file. They can't be stored in the entries either, so I put them into CodecPrivate.

Gosh, another hack :) So how many entries are saved that way? Is it only two lines or more? Cause iirc i had more commented lines but only 2 were saved in codecprivate.

Oh! New idea for a advanced switch :) Some kind of simplified codecprivate, to ensure more chance for compatibility between different segments. Practical releases with ordered chapters are now really being rolling out, and quite soon will become rather common for top groups, i guess. What is certain i'm not the only one who does release using those atm :)

[Calculon]

I have a question that maybe someone can answer. On my system, if I use the unicode build of mkvtoolnix, I usually have to wait about 2 seconds for mkvmerge GUI to open. If I use the non-unicode build it opens instantly. Is there a problem? My system is a dual core Opteron 165 @ 2.4GHz with 1.5GB of RAM on a DFI Nforce 4 board with XP Professional x64. It doesn't bother me much, but is there an advantage to using unicode or non-unicode?

[LeMoi]

I think Mosu already talked about it, it was about widgets introduced in some older version which may slow down the launching f the GUI :)

[Mosu]

I have a question that maybe someone can answer. On my system, if I use the unicode build of mkvtoolnix, I usually have to wait about 2 seconds for mkvmerge GUI to open. If I use the non-unicode build it opens instantly. Is there a problem?

LeMoi is correct. The GUI toolkit I'm using (wxWidgets) changed the layout code between two versions, and that change slowed the initial GUI creation down quite a bit. Unfortunately the Unicode support in the earlier (and faster) versions was buggy, so I couldn't go back.

The Unicode build uses the newer and slower and the non-Unicode version uses the older but faster version of wxWidgets.

It doesn't bother me much, but is there an advantage to using unicode or non-unicode?

The Unicode enabled version supports Unicode, obviously. Meaning that you cannot use charsets that use more than one byte for a char (all of the Asian languages for example) with the non-Unicode enabled version. However, if you only use English characters or one of the other usual charsets (like German) then you should be OK with the non-Unicode version. Your mileage may vary.

[Calculon]

Thank you. I don't deal with much that isn't in English since most of my Matroska stuff is made from my own tv captures, so I'll just use the non-unicode build.

[issa]

Lastest CVS/SVN build with msvc (unicode),

URL: http://rapidshare.de/files/14893466/mkvtoolnix-1.6.5-20060307-unicode-msvc.7z.html

[Egh]

@Mosu: new idea for great new option in mkvmerge :)

Dealing with the Ordeal chapters, I found out that the good thing would be Segment UID manual override. i.e. I want it to be created only once (during initial mux) and then each time i remux it the UID should remain unchanged.

the switch "no variable data" doesn't work that way, it always creates zero UID, which is not good for my purposes.

[Mosu]

@Mosu: new idea for great new option in mkvmerge :)

Dealing with the Ordeal chapters, I found out that the good thing would be Segment UID manual override. i.e. I want it to be created only once (during initial mux) and then each time i remux it the UID should remain unchanged.

That's what the "--segmentinfo" switch is for. With that you can write a XML file specifying stuff in the "segment info element" including the segment UID. Granted, this option is not documented so far (it's only used by Robux4's menu tool and by a couple of developers), but the functionality does exist.

the switch "no variable data" doesn't work that way, it always creates zero UID, which is not good for my purposes.

"--engage no_variable_data" is meant to always produce the exact same file. I use this for regression tests (meaning "did the stuff I did today change what mkvmerge outputs"). This option has saved my butt quite often, but it is definitely the wrong option for your purpose.

[Egh]

That's what the "--segmentinfo" switch is for. With that you can write a XML file specifying stuff in the "segment info element" including the segment UID. Granted, this option is not documented so far (it's only used by Robux4's menu tool and by a couple of developers), but the functionality does exist.



Well, a bit of docs on it? :) Meaning is it enough to specify only segment UID and leave everything else for the muxer to decide?

[Mosu]

Should work, yes. Just write a XML file with contents similar to this:

<?xml version="1.0" encoding="ISO-8859-1"?>

<Info>
<SegmentUID format="ascii">AAAAAAAAAAAAAAAA</SegmentUID>
<NextSegmentUID format="hex">0x00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f</NextSegmentUID>
<PreviousSegmentUID format="hex">0f0e0d0c0b0a09080706050403020100</PreviousSegmentUID>
</Info>

You don't have to specify all three, but these are just examples of how you can enter the UID. Then add "--segmentinfo seginfo.xml" to the command line.

[Liisachan]

@Mosu,
Thank you again for your hard work.

I recently found that Gabest has been implementing an extended version of S_TEXT/ASS since around November 2005, mainly for MPC, but in essence also important for compatibility with USF (S_TEXT/USF).

While S_TEXT/SSA (Sub Station Alpha) data has the signature "ScriptType: v4.00" in it and S_TEXT/ASS (Advanced SSA) has "ScriptType: v4.00+", this new format has "ScriptType: v4.00++" and called ASS2 (MEDIASUBTYPE_ASS2) in source code (http://cvs.sourceforge.net/viewcvs.py/guliverkli/guliverkli/src/filters/parser/mp4splitter/MP4Splitter.cpp?r1=1.13&r2=1.14).

ASS2 is not very clear and probably still under construction, but it has 2 more members in each Style, and 1 more member in each Dialogue. Like USF, and unlike ASS, ASS2 can technically distinguish relative-to-screen from relative-to-frame. Exactly emulating USF's "Powerful element positioning system: Relative to window or video" ( http://usf.corecodec.org/ )...

I did a quick test and mkvmerge happens to be able to mux ASS2 into Matroska and the resulted MKV happens to work with MPC too as if it were muxed perfectly. But mkvinfo thinks this track is S_TEXT/SSA, and I'm sure this is just accidental and not an advisable MKV file.

Exactly what happens if someone (like Gabest or the author of XombieSub) extends SSA/ASS and adds extra non-standard fields to the data, and such a file is muxed into MKV by mkvmerge? If re-reading Matroska Specs ( http://www.matroska.org/technical/specs/subtitles/ssa.html ) , I feel that --

Dialogue: 0,0:00:01.00,0:00:05.00,style,,0000,0000,0000,0000,,Hi!
-- will be stored as if it had Effect "0000" and Text ",Hi!" because Mkvmerge has no idea about the extra field added (4th "0000" in this sample) and thinks what is after the 9th comma is the text data for Dialogue. The result is transparent and accidentally ok for MPC, but other players might display ",Hi!" with the preceding comma.

Something like this might happen more in the future, and I think it would be safer for mkvmerge to read the Format line:

Format: Layer, Start, End, Style, Actor, MarginL, MarginR, MarginT, MarginB, Effect, Text

to know which field is which... in this case, perhaps it would set MarginV=0 (def value) because the data doesn't contain MarginV, and maybe it would ignore MarginT and MarginB because they are unknown fields, and then it can get Text correctly after the 10th comma, not 9th.

I'd appreciate it if Matroska specs would decide the unique protocol to handle unknown fields in SSA/ASS before it is too late :)

For reference, some unofficial samples I made by guessing what ASS2 is like. These works with MPC, so basically I should be guessing right.
MEDIASUBTYPE_ASS2.ass (http://www.faireal.org/tmp/MEDIASUBTYPE_ASS2.ass) 3kb
ASS2_Test.mkv (http://www.faireal.org/tmp/ASS2_Test.mkv) 40kb, muxed by mkvmerge and accidentally working with MPC

[LeMoi]

ok, then I won't feel too bad about it ;) I'm just wondering if this is a bug in the encoder software or if '0' is actually a valid setting for ADTS AAC headers... The latter case sounds FUBAR.
In fact i DO need this option ^^, i've encoded by mistake such tracks with the "Dual Channels" preset, and know i don't have the original ac3 any more, so i can't re-encode them :s. I need to be able to mux them, because Haali splitter won't open a file with a '0 channel" track in it ^^)

[Yong]

mkvmerge(latest beta) still cant mux ogg theora directly,
theora is display as "unknown" track in mmg,
that file is created by ffmpeg2theora(svn build).

i have to transmux the ogg theora to avi with mplayer, then remux again with mkvmerge...

[Mosu]

mkvmerge(latest beta) still cant mux ogg theora directly,
theora is display as "unknown" track in mmg,
that file is created by ffmpeg2theora(svn build).

Upload such a file, please.

[Yong]

Uploaded.(file name is yong.ogg) ;)

[Mosu]

Uploaded.(file name is yong.ogg) ;)

Thanks. This build could potentially fix your problem. The resulting file looks fine regardings its timecodes, but I can't play Theora where I am at the moment, so I can't really verify proper playback. Please download

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-1.6.5-build20060317-1.rar

[Yong]

Thanks. This build could potentially fix your problem. The resulting file looks fine regardings its timecodes, but I can't play Theora where I am at the moment, so I can't really verify proper playback. Please download

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-1.6.5-build20060317-1.rar
Thanks ;)
btw, i have playback problem with theora-in-mkv too :p
mpc built-in matroska splitter, haali media splitter and mplayer ignored the video and play audio only...

EDIT: mkvextract doesnt work too, : "Error: Extraction of track number 1 with the CodecID 'V_THEORA' is not supported" ...

[Mosu]

Correct. mkvextract doesn't support Theora and might not for quite some time.

[#2]

I get very jittery play back with MPC 6.4.8.9 with either the MatroskaSplitter.ax or the in built Martoska splitter or the latest Haali splitter.

This dose not happen if I just play the video stream in the same folder as the audio stream unmuxed and MPC just has to auto load it.

MkvToolnix 1.65 (RMVB and AC3 streams)

[foxyshadis]

Well, I gave appending unlike x264 segments together a shot (the only difference was that I recompressed intro and outro much harder, via crf instead of 2-pass, I forgot to set zones initially), and all I got for my trouble was a lavc crash. :p (h264.c, line 2610, pic->data[0]) It might have something to do with all three using a custom matrix; the intro and outro merge just fine though.

I'd settle for simply including all three as tracks as long as I could have it play them sequentially, but I can't seem to manage that either; it just treats them as, well, separate tracks. At least using haali's splitter and mpc/zoomplayer.

An yway, that's my experience with the option.

[Egh]

I'd settle for simply including all three as tracks as long as I could have it play them sequentially, but I can't seem to manage that either; it just treats them as, well, separate tracks. At least using haali's splitter and mpc/zoomplayer.

An yway, that's my experience with the option.

Ordeal Chapters? But if codecprivate parts differ for separate segments, then chapters is not an option atm.

[issa]

Lastest CVS/SVN msvc unicode build,

URL: http://rapidshare.de/files/17117773/mkvtoolnix-1.6.5-msvc-unicode-20060403.7z.html

[tomos]

i'm using mkvmerge to try and mux a video with an aac audio track but every time it locks. it gives me an err sayin

Warning: AAC files may contain HE-AAC / AAC+ / SBR AAC audio. This can NOT be detected automatically. Therefore you have to specifiy '--aac-is-sbr 0' manually for this input file if the file actually contains SBR AAC. The file will be muxed in the WRONG way otherwise. Also read mkvmerge's documentation.

i've tried some different options i found in the docs like:

--aac-is-sbr
--aac-is-sbr 0
and
--engage old_aac_codecid (altho it says this is an illegal hack?)

it always just hangs with the process maxing out. have to end task it. i've searched for this here but no results for 'aac' or the err message i quoted.

is this something i'm doing wrong or something with mkvmerge?