MKVToolNix v24.0.0 released

[nautilus7]

I've uploaded a sample (m2ts file) where mkvmerge can't detect the video stream inside.

[Mosu]

Hey,

I've released mkvtoolnix v5.0.0. It's a release with a lot of small bug fixes, but it also features support for MPEG transport streams.

Change for package maintainers: Building against external versions of libEBML and libMatroska is possible again. libEBML 1.2.2 (http://dl.matroska.org/downloads/libebml/) and libMatroska 1.3.0 (http://dl.matroska.org/downloads/libmatroska/) are required. If they're not found or too old then the internal versions will be used and linked statically.

Here are the usual links: the home page (http://www.bunkus.org/videotools/mkvtoolnix/), the source code (http://www.bunkus.org/videotools/mkvtoolnix/sources/mkvtoolnix-5.0.0.tar.bz2) and the Windows installer (http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-5.0.0-setup.exe) and 7zip archive (http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-5.0.0.7z).

All of the binaries (http://www.bunkus.org/videotools/mkvtoolnix/downloads.html) that I provide myself are already available.

Here's the full ChangeLog (http://www.bunkus.org/videotools/mkvtoolnix/doc/ChangeLog) since release 4.9.1:

2011-09-24 Moritz Bunkus <moritz@bunkus.org>
* Released v5.0.0.
* build system: libEBML 1.2.2 and libMatroska 1.3.0 are required for building. If external versions are not found or if they're too old then the included versions will be used as a fallback.

2011-09-21 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The "writing application" element will not be localized but always be written in English.

2011-09-20 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: MPEG TS: mkvmerge will extract the track languages from a corresponding clpi (clip info) file. That file is searched for in the same directory and in ../CLIPINF and must have the same base name but with the ".clpi" extension.
* mkvmerge: enhancement: Added new stereo mode options to match the current specs. The new options are "anaglyph_green_magenta" (12), "both_eyes_laced_left_first" (13) and "both_eyes_laced_right_first" (14).
* mkvmerge: The --stereo-mode named option "anaglyph" was renamed to "anaglyph_cyan_red" to match the specs. The numerical value (10) remains unchanged.

2011-09-18 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: bug fix: Fixed attachment number displayed during extraction. Fix for bug 663 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=663).
* mkvmerge: enhancement: MPEG TS: Added support for HDMV PGS subtitles.
* mkvmerge: enhancement: MPEG TS: Added support for DTS HD Master Audio tracks.

2011-09-17 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: MPEG TS: Streams that are mentioned in the PMT but do not actually contain data are neither reported during identification nor muxed.

2011-09-14 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: MPEG TS: Added support for reading the language code.

2011-09-13 Moritz Bunkus <moritz@bunkus.org>
* mmg: enhancement: Added MPEG transport streams to the "add file" dialog file selector.
* mkvmerge: new feature: MPEG TS: Added support for normal DTS tracks.
* mkvmerge: Tons of fixes and additions to the MPEG transport stream demuxer.

2011-09-10 Moritz Bunkus <moritz@bunkus.org>
* build system: configure will accept external versions of libEBML and libMatroska again. Minimum required versions are libEBML 1.2.1 and libMatroska 1.1.0.

2011-09-07 DenB <denb10@free.fr>
* All: Updated the French translation with a complete set by DenB (see AUTHORS).

2011-09-05 Cosme Domínguez <cosme.ddiaz@gmail.com>
* mmg: mmg respects the XDG Base Directory Specification regarding its configuration files (environment variable $XDG_CONFIG_HOME/mkvtoolnix if set, otherwise ~/.config/mkvtoolnix).

2011-08-24 Moritz Bunkus <moritz@bunkus.org>
* all: Added an Lithuanian translation by Mindaugas Baranauskas (see AUTHORS).

2011-08-14 Massimo Callegari <massimocallegari@yahoo.it>
* mkvmerge: new feature: Implemented a MPEG transport stream demuxer.

2011-08-02 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: When looking for MPEG files with the same base name as a source file mkvmerge will be stricter what it accepts. The file name must consist of at least one char followed by "-" or "_" followed by a number. That will match VTS_01_1.VOB but not e.g. "some_series_s03e10.mpg".

2011-07-31 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Opening MPEG files with numbers in their name from folders with e.g. Cyrillic names failed on Windows.
* mkvmerge: bug fix: Several elements are not written when creating WebM compliant files. In the segment headers: SegmentUID, SegmentFamily, ChapterTranslate, PreviousSegmentUID, NextSegmentUID. In the track headers: MinCache, MaxCache and MaxBlockAdditionID.

2011-07-19 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: Sped up file identification by caching read operations.
* mkvmerge: bug fix: Fixed identifying QuickTime/MP4 files that start with a 'skip' atom.

2011-07-13 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed a crash when reading AVI files with DTS audio tracks that do not contain valid headers in the first couple of packets. Fix for bug 646 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=646).

Have fun.

[Inspector.Gadget]

I've released mkvtoolnix v5.0.0.

:thanks::thanks::thanks:

[b66pak]

thanks a lot...
_

[Lincoln Burrows]

People,
I have a Matroska file, extracted from my DVD. It has a spanish subtitle (the only available), and it's some american production. However, I understand english (not my native language), but I don't want this subtitle to be loaded when I open the file with MPC-HC. I mean, I want the subtitle track to be there, but I want it to be disabled by default, so we have to select in MPC to be displayed.

Can you tell me which option should I choose?

Default track flag:

1) Default
2) Yes
3) NoAnd what about "Forced track flag - yes or no?" what is this thing?

[Mosu]

Set "default track" to "no" for all subtitle tracks. Leave "forced track" at "default" (resulting in no track having "forced" set by default).

"Default" tells the player that a track should be displayed.

"Forced" means that it must be displayed (e.g. for an English film this could be used for English subtitles tracks that only show a translation if one of the character is speaking a non-English sentence, e.g. Legolas speaking Elfish in "The Lord of the Rings").

[Lincoln Burrows]

Set "default track" to "no" for all subtitle tracks. Leave "forced track" at "default" (resulting in no track having "forced" set by default).And what if this is the only subtitle track? Should I set "Forced track flag" to no as well?

In this case, I want the player to not display the subtitle track, unless I tell otherwise, so it should be disabled by default.

[Mosu]

Like I said, leave the "forced" flag at anything but "yes".

[Chetwood]

I'm sorry but I also still don't get the difference. You say that "Default" tells the player that a track should be displayed. Now if I set the forced flag to default, would it display the sub or not. And if only yes will set the forced flag, what's the use of having the setting default? Maybe I'm confused by the way it works on DVDs where one can set a track to default but off which won't display any sub initially. but will start cycling at this particular track, once they get enabled via remote.

Also, if I mux an mkv with 2 audio and subtitle streams (de/en) and don't want any sub to be displayed upon playback, what flags do I set? Default track to default? Would it make a difference to set it to no?

And what if I do have Elvish? Do I need to set both default track and forced to "yes". Or does the forced flag override the default flag? :confused:

[Mosu]

Leaving a flag (no matter which flag) on the "default" settings means the decision whether or not it should be set is up to mkvmerge. mkvmerge usually takes the information provided by the source container into account. For some flag types (especially the "default track" flag) there are other considerations as well.

Setting a flag to "no" will force mkvmerge not to set that flag, no matter what those other considerations would have done and no matter what the source container provided for that flag.

For the "default track" flag: The special consideration is that mkvmerge will automatically set this flag to "yes" for exactly one track of each track type (audio, video, subtitles). You can only prevent this by explicitly setting the "default track" flag to "no" manually for all tracks of a kind (e.g. for all subtitle tracks).

The "default track" flag tells the player that this track should be played unless the user overrides that decision somehow. You usually mark the original audio track with "default track" and leave it off for the rest of them, e.g. for the director's commentary or some translations you don't want (e.g. Lord of the Rings, mark "English" as "default track" but not "German" and "Director's comments (English)").

As a lot of users don't want subtitles shown by default they tell mkvmerge not to set the "default track" flag for any subtitle track.

Now on to the "forced display" flag, in short "forced". If this is set to "on" then this track must be played/shown no matter what the user selected for his preferences or what the player would normally chose to show/play. This is used seldom, e.g. only for a subtitle track that only contains the English translation whenever Legolas is talking Elbish.

"Forced" has nothing to do with "default track". If "forced" is set the player must play that track no matter what "default track" is set to. In fact normally a track that has "forced" set does not have "default track" set, though it is neither invalid nor undefined behavior.

[Chetwood]

Leaving a flag (no matter which flag) on the "default" settings means the decision whether or not it should be set is up to mkvmerge. mkvmerge usually takes the information provided by the source container into account.
Ok, but since I'm using demuxed streams as source there is no container and thus no information provided. How will mmg decide then?

For the "default track" flag: The special consideration is that mkvmerge will automatically set this flag to "yes" for exactly one track of each track type (audio, video, subtitles).
Always for the first audio and the first subtitle stream or how does mmg decide?

You can only prevent this by explicitly setting the "default track" flag to "no" manually for all tracks of a kind (e.g. for all subtitle tracks).
Right, so if I have subs but don't want them to be displayed automatically, I'd set the "default track" flag not to "default" but to "no".

The "default track" flag tells the player that this track should be played unless the user overrides that decision somehow.
Which can also be overwritten by the player's setting.

You usually mark the original audio track with "default track" and leave it off for the rest of them, e.g. for the director's commentary or some translations you don't want (e.g. Lord of the Rings, mark "English" as "default track" but not "German" and "Director's comments (English)").
So the "default track" flag is set to "yes" for the original audio track and set to "no" for the director's commentary? Sorry, this double "default" is strangely confusing to me :o

"Forced" has nothing to do with "default track". If "forced" is set the player must play that track no matter what "default track" is set to. In fact normally a track that has "forced" set does not have "default track" set, though it is neither invalid nor undefined behavior.
I always thought setting the "default track" flag to yes would only be reinforced by the "forced" flag. But if one track is default and another is forced, the latter will be displayed.

[Mosu]

Ok, but since I'm using demuxed streams as source there is no container and thus no information provided. How will mmg decide then?

First, it's not mmg that decides but mkvmerge.

Second, if the source container does not provide that information then it is ignored.

Always for the first audio and the first subtitle stream or how does mmg decide?

Video as well. The algorithm is a bit more complex. For each track the decision is made somewhat like this:

1. Is "no" set on the command line? Set flag to "no".
2. Is "yes" set on the command line? If so and if no previous track of this kind has been set to "yes" from the command line then set flag to "yes". Otherwise continue in the evaluation process.
3. Does source container provide "no"? Set flag to "no".
4. Does source container provide "yes"? If so and if no previous track of this kind has been set to "yes" either from the command line or from its source container then set flag to "yes". Otherwise continue in the evaluation process.
5. Has the flag NOT been set to "yes" for any other track of this kind encountered so far? Set flag to "yes".
6. Set flag to "no".

Right, so if I have subs but don't want them to be displayed automatically, I'd set the "default track" flag not to "default" but to "no".
...
Which can also be overwritten by the player's setting.
...
So the "default track" flag is set to "yes" for the original audio track and set to "no" for the director's commentary? Sorry, this double "default" is strangely confusing to me :o

Correct.

I always thought setting the "default track" flag to yes would only be reinforced by the "forced" flag. But if one track is default and another is forced, the latter will be displayed.

Not really. You're assuming that only one track can be displayed for each track type. This is not the case in general. Therefore the Matroska specs don't say "if one track has 'forced' set then only display this track". They only say that this track must be displayed; they don't prohibit another track of its kind of being displayed at the same time.

[Chetwood]

Thanks for clearing that up. Another question: how can I determine whether an MKV was muxed with header compression set to on? I've muxed two test files, one with this setting on, the other off. Both have the same size. I'm trying to determin, why some muxed files playback on DVBViewer and others have no sound.

[Mosu]

This question has been asked and answered in this thread numerous times already, e.g. in http://forum.doom9.org/showthread.php?p=1514173&highlight=compression#post1514173

[Chetwood]

Right. So if Muxing mode : Header stripping means, header compression is on, I'm out of luck because this setting is not set in my new muxings and yet I don't get sound on playback with DVBViewer.

BTW, the mouseover translation of the "Wegen potenziell..." checkbox in mmg 5.0 is missing a "t" in "warnt".

[TechnoPhil]

Hi Guys,
i would like to ask if it is possible to find a .dmg version for MacOs of the new MKVToolnix version (ver.5).
I need the newer version on my Mac because it supports MPEG transport streams (.ts or .m2ts files)!

Actually this is the last version form Mac: http://jonthn.free.fr/MKVtoolnix/Mkvtoolnix-4.9.1_2011-07-22-67c1-intel-ppc.dmg

Anyone can help me? Maybe the author "j0nthn" ?

Best regards.

Filippo

[Mosu]

Speaking only for myself: I don't support Mac OS. I just link to others providing images/build scripts/whatever. Which translates into "I don't know".

The Macports project (http://www.macports.org/ports.php?by=name&substr=mkvtoolnix) seems to have updated already.

[TechnoPhil]

Thank you for your answer!
I am waiting for "j0nthn" answer, maybe he's going to publish an update for the Mac version.

I know that MacPorts is up to date, but would prefer the .dmg version!

[TechnoPhil]

Speaking only for myself: I don't support Mac OS. I just link to others providing images/build scripts/whatever. Which translates into "I don't know".

The Macports project (http://www.macports.org/ports.php?by=name&substr=mkvtoolnix) seems to have updated already.

Hi!
Can you suggest me how to contact "j0nthn"?
I tried by email and here in this forum, but i did not received an answer yet :(

[Mosu]

No, sorry.

[Lincoln Burrows]

Mosu,
is there a way to create a Matroska file with multi video streams/angles? I am sorry, but I can't find anywhere a way to do that using MKVMerge, but I am quite sure I knew.

And if there is, can we do in one sequence and then join this with the rest?

This is a case of multi-angle - the initial credits from Star Wars. A unique M2TS file with 2 minutes (the first 2 minutes) from the movie. There are other 5 or 6 files with the same content, but translated in other languages as you can see:

http://i.imgur.com/SjiTL.jpg

http://i.imgur.com/7dib6.jpg

Star Trek: TOS also have multi angle scenes in all episodes, if I recall.

One question I was going to ask is this one: will MKVMerge be able to join, for example:

- The file with multi-angle feature + the other one without multi-angle with no issues? Or they both need to be multi-angle?

[Mosu]

I have no idea; never played around with such things; never bothered reading up on multi-angle stuff.

[Lincoln Burrows]

I have no idea; never played around with such things; never bothered reading up on multi-angle stuff.Well, I tried doing the exact following here:

tsMuxerGUI to demux a m2ts file from some extra feature with no audio tracks. tsMuxerGUI to demux a m2ts from some extra feature with a single audio track.

MKVToonix > Add the first file (MPEG-4 AVC), and Add the 2nd file (also MPEG-4 AVC).

That was the result (and you can see for yourself) using Media Player Classic Home-Cinema. Please note there's a second video angle here, you can select by going to "Video Stream" in MPC options.

http://www.embedupload.com/?d=7YZEDKGSQ1

Assuming both angles have the same audio track, it won't matter if the 2nd is playing this audio track while the first is mute.

However, if I use the "Append" option to make the whole thing like that:

1st video angle ===========||||||||||||||||||||||
2nd video angle ===========|||||||||||||||||||||

||||||||||||||||| = REST OF THE MOVIE (and a single file demuxed from another m2ts)

Will be rejected, even if it's MPEG-4 AVC as well, with the following reason:

00720.track_4113.264' cannot be appended to the track number 1 from the file 'C:\Users\Q9450\Desktop\00720.track_4113.mkv'. The formats do not match.

[somms]

However, if I use the "Append" option to make the whole thing like that:

1st video angle ===========||||||||||||||||||||||
2nd video angle ===========|||||||||||||||||||||

||||||||||||||||| = REST OF THE MOVIE (and a single file demuxed from another m2ts)

Will be rejected, even if it's MPEG-4 AVC as well, with the following reason:

From my limited experience using the append function, the resolutions i.e. 1920x1080, for both files have to match exactly...one cannot be 1912x1080 while the other is 1920x1080 or you will get a similar error message...

[Lincoln Burrows]

From my limited experience using the append function, the resolutions i.e. 1920x1080, for both files have to match exactly...one cannot be 1912x1080 while the other is 1920x1080 or you will get a similar error message...But in this case both files are exactly the same. I made a copy from the demuxed file and tried to append using MKVmerge. Couldn't do that because the first MKV file had this multi-angle thing, and it seems you can't append if the 2nd file has no multi-angle in it.

Which means, you can't do this multi-angle (multiple video stream) thing with one MKV file and then try to append with another.

So in this case I have no choice? Do I need to watch, instead of a 2 hour movie, the first 2 minutes and then the next 118 in another file?

I was going to do this trick in Star Trek: TOS episodes and Star Wars, but I guess I can't do that...

[robpdotcom]

This will do what you want:

http://forum.doom9.org/showthread.php?t=160027

[Lincoln Burrows]

This will do what you want:

http://forum.doom9.org/showthread.php?t=160027Do you know for sure if this method will give me a MKV file with the entire movie but with the audio/video/subtitle streams untouched? I mean, I use MAKEMKV and MKVTOOLNIX to convert my Blu-rays (and even DVDs) into Matroska, but I don't want anything but a lossless compression:

http://en.wikipedia.org/wiki/Lossless_data_compression

So if I am not getting that from this method, it can't help me either.

(Anyway, I posted in that thread, take a look what I said).

[Chetwood]

There is no need for sperate angles cause only the crawl is separate and the rest of the movie is the same. Since you can't sort streams in MakeMKV (yet?), you can use Clown BD which in a first step will demux all files but also merge the angles. Then you can mux with MKVmerge as usual.

[TechnoPhil]

Hi,
can you suggest me a free blue-ray ripper for Mac?

[Mosu]

Hey,

I've released mkvtoolnix v5.0.1. It's a release with a few improvements/bug fixes and one important fix for a regression introduced in v5.0.0 regarding PGS subtitles.

There were no changes that concern package maintainers.

Here are the usual links: the home page (http://www.bunkus.org/videotools/mkvtoolnix/), the source code (http://www.bunkus.org/videotools/mkvtoolnix/sources/mkvtoolnix-5.0.1.tar.bz2) and the Windows installer (http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-5.0.1-setup.exe) and 7zip archive (http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-5.0.1.7z).

All of the binaries (http://www.bunkus.org/videotools/mkvtoolnix/downloads.html) that I provide myself are already available.

Here's the full ChangeLog (http://www.bunkus.org/videotools/mkvtoolnix/doc/ChangeLog) since release 5.0.0:

2011-10-09 Moritz Bunkus <moritz@bunkus.org>
* Released v5.0.1.

2011-10-08 Moritz Bunkus <moritz@bunkus.org>
* build system: Updated the Debian/Ubuntu files to debhelper v7/quilt 3.0 format.
* mkvmerge: enhancement: Implemented support for yet another way of storing EAC3 and DTS in MPEG transport streams.

2011-10-05 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo: bug fix: Track information was not reset when opening more than one file in the GUI.

2011-10-03 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The PGS subtitle output module was not outputting any packet in certain cases due to uninitialized variables.

2011-09-27 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed mkvmerge not finding any track in TS streams whose first PMT packet could not be parsed (e.g. invalid CRC).
* mkvmerge: bug fix: Fixed detection of TS streams that only contain one PAT or PMT packet within the first few KB but no others within the first 10 MB.


Have fun.

[b66pak]

thanks a lot...
_

[tebasuna51]

Thanks for you new version.

Please, can you replace the spanish translation for:
"Disable header removal compression for audio and video tracks by default"
to:
"Deshabilitar la compresión de cabeceras para audio y video por defecto"?

The actual one:
"Deshabilitar eliminador de la compresión del encabezado para audio y video predeterminadamente"
isn't clear at all.
"Deshabilitar eliminador de la compresión" can be understand like "Enable compression"

Thanks.

[Mosu]

Sure, will do.

[Chetwood]

Can you explain the bug concerning PGS subs. I had some issues with these on my WDTV Live and according to the latest firmware log they should work.

"The PGS subtitle output module was not outputting any packet in certain cases due to uninitialized variables."

Does this mean, there simply would be no PGS sub stream or that the stream would be empty or something?

[Mosu]

"The PGS subtitle output module was not outputting any packet in certain cases due to uninitialized variables."

Does this mean, there simply would be no PGS sub stream or that the stream would be empty or something?

The latter. The track headers contained an entry for the track, but there was not a single packet for it.

[mbcd]

Oh God, I`m happy with that, because I used exactly that version for remuxing all my files and it would be lots of days hard work to remux the original PGS again.

Question:
Is it possible to fix this issue by remuxing the files with further versions? Will there be a internal check to fix that? As I understood there is nothing damaged or lost, only some additional entries where no data (paket) is behind. So there are now for example 500 entries in Header, but only 200 real subtitles inside those track.

I`m asking because I mentioned those problem, because I watched a movie, activated a subtitletrack, but nothing was shown on screen. Now I am not shure if those track was only a forced subtitletrack (with very less "messages" = entries?), or a "damaged" one.

[sneaker_ger]

As far as I understand Mosu, you could be in deep trouble. Players will indicate that there is a track, but no actual "lines" (actually bitmaps for PGS) were written to the file. This would imply unrecoverable data loss, simple remuxing (or anything else for that matter) can not repair those files.

/edit:
Didn't saw any trouble muxing from mkv, m2ts and raw. Maybe Mosu can elaborate on "in certain cases"?

[Mosu]

As far as I understand Mosu, you could be in deep trouble. Players will indicate that there is a track, but no actual "lines" (actually bitmaps for PGS) were written to the file. This would imply unrecoverable data loss, simple remuxing (or anything else for that matter) can not repair those files.

This is correct. Ok here goes a longer explanation:

Prior to v5.0.0 everything was A-OK.

v5.0.0 introduced a nasty bug that only occurred if mkvmerge itself was compiled with compiler optimization turned on. As most people on this planet use pre-built binary packages this does apply to all of them as binary packages, especially the ones I provide, are almost always compiled with optimization. The reason I'm making this distinction right now is because my development builds are always compiled with optimization turned off (otherwise it makes stepping through it with a debugger really difficult). Therefore I just didn't notice that bug during development. Neither did my automated test suite fail because I usually run it from a development build, too, simply because re-compiling with optimization turned on takes a couple of minutes (and as I run the test suite quite often these minutes can add up quickly).

The bug itself resulted in the track headers being OK (they're exactly the same as they were before v5.0.0) but no pictures written at all. Yes, all the data was lost. No, there's no way to recover the data from such a file. You can only re-mux the original source file(s) with v5.0.1.

/edit:
Didn't saw any trouble muxing from mkv, m2ts and raw. Maybe Mosu can elaborate on "in certain cases"?

The "certain cases" refer to the compiler optimization being turned on or off. At the time of the release of v5.0.1 I still thought it might only have occurred when PGS subs were read from a Matroska file but not from a PGS subtitle file, but I was wrong in that. It always happens if compiler optimization was turned on.

[sneaker_ger]

It doesn't seem do happen with your win32 binary, 5.0.0, Sep 25 2011 20:33:49. Lucky that the most used binary was unaffected or am I looking at the wrong place?

[Mosu]

It is possible, though I haven't confirmed it myself, that the mingw cross-compiler (which is a gcc running on Linux compiling into Windows executables) treats this differently than my gcc on Linux.

More likely, however, is that it is more or less random. The bug itself is that a certain variable was not initialized. Without optimization gcc still initializes memory to 0 whenever memory is allocated. With optimization gcc re-uses the memory, so the variables initial value depends on what was present in the memory before the object the variable belongs to was constructed. Therefore I still believe that the Windows executable for v5.0.0 is affected.

[sneaker_ger]

"Random" lines, or always all or no lines affected?

[Mosu]

As the variable in question is only created once per track I'd say you either get all lines or none at all.

[sneaker_ger]

I see, thx.

[mbcd]

Therefore I still believe that the Windows executable for v5.0.0 is affected.

Yes :( I still have to confirm this.

I remuxed all my files with 5.0.0 by cli-batch-processing. So a new instance was created for each remux.

Now I demuxed lots of files and some are damaged.
The bug ends in empty subtitletracks. The Track is still there, but there is not a single line in it, its completely empty.
So you get a demuxed filesize of 0 Bytes for those tracks.

Fixing is happily very easy because the damaged tracks can be identified by filesize. What I figured out (until now) is, that if filesize is bigger than 0, track is Ok and bitidentical to the original one.

So the bug did not damaged single lines inside a subtitletrack but the whole track, thats "good".

Here its about 10% until now.
I can remux those damaged track (mostly only one from 3 inside one mkv) and everything is fine again.

I think those version should not have named "Die wahre Liebe", because after this at all, this version is not any more my "true love" ... :sly:

Love is a lie ... Love lies ... and my love to this version dies/died ;)

[Mosu]

Well, you got MPEG transport stream support, which counted for a lot of love all around ;)

[bernd_b]

Indeed, the mpeg-ts support is a great joy comming unearned and surprisingly - something which sounds like love to me...

:thanks::thanks::thanks:

[Lincoln Burrows]

Wait... what's going on, I am using MKVExtractGUI2 to extract one AC3 stream from a Matroska file and the resulting AC3 file has:

Duration : 8003184
Duration : 2h 13mn
Duration : 2h 13mn 23s 184ms
Duration : 2h 13mn
Duration : 02:13:23.184While inside the MKV container, MediaInfo says it's longer (with the same length from the video stream/movie):

Duration : 8045072
Duration : 2h 14mn
Duration : 2h 14mn 5s 72ms
Duration : 2h 14mn
Duration : 02:14:05.072Any idea what happened?

Edit: What the hell is this?

http://i.imgur.com/M1j0w.png

Several "Warning - This AC3 track contains X bytes of non AC3-data which were skipped. The audio/video synchronization may have been lost" messages. Why are these programs doing that? They are ruining what I was trying to do!

[Mosu]

Oh no, the programs are out to get you!

[Lincoln Burrows]

Oh no, the programs are out to get you!And it's all of them, not just yours. :p

Even converting the MKV with the AC3 into AVI/MP3 couldn't change the final length, which is always shorter.

There's no way to fix this? I also found someone indicating
http://www.videohelp.com/tools/AC3fix_GUI

But that didn't helped me either.

As long as this problem isn't solved I am going to use this solution: use Sound Forge to record the entire stream while playing in my computer.

[Mosu]

How do you expect it to be resolved? If the track contains some bytes that simply do not adhere to the AC3 specifications then that is simply garbage.

Also the track "length" inside a Matroska file is not a precise measurement. MediaInfo can only take the difference between the last and the first timecode for that track. However, it cannot take into account if there are gaps, nor does it take into account if there are packets with timecodes but with garbage as their payload.

I'm pretty sure there simply is not more (good) data available.

You may still succeed with your method, though, if the player you're using adheres to the timecodes in the file and fills gaps (caused by e.g. missing packets/gaps or garbage data) with silence (or random noise). That way you might actually end up with a track that's exactly as long as you expect it to be; just don't expect it to sound perfect 100% of the time.