MKVToolNix v24.0.0 released

[ndjamena]

Is anyone else having this problem with the new 8.6.0 build?

When I drag 'n drop an MKV file that has previously been written to by Haali Matroska Writer b0 (which is what Simple x264/x265 Launcher uses when encoding directly to an mkv file (x264 codec)), MKVToolnix 8.6.0 takes an extremely long time to recognize the file (locks up for around 30 seconds+, then lets me continue), but 8.5.2 recognizes it immediately.

Apparently your file doesn't have a seek head, so MKVMerge goes looking for one...

hmmmmm.

[Mosu]

When I drag 'n drop an MKV file that has previously been written to by Haali Matroska Writer b0 (which is what Simple x264/x265 Launcher uses when encoding directly to an mkv file (x264 codec)), MKVToolnix 8.6.0 takes an extremely long time to recognize the file (locks up for around 30 seconds+, then lets me continue), but 8.5.2 recognizes it immediately.

This is most likely due to the following change:

* mkvmerge: enhancement: if no seek head is found before the first
cluster when reading Matroska files then mkvmerge will attempt a
deeper scan of all elements in the file in order to find track
headers, attachments, chapters and tags located at the end of the
file. See #1513 for the rationale.

I wasn't aware this had such a negative impact on a common kind of file. Looks like I'll have to disable that functionality again or implement it some other way…

Edit: new pre-builds 1018 (32bit)/1019 (64bit) with that feature temporarily disabled are available (https://mkvtoolnix.download/windows/pre/).

[Mosu]

When I drag 'n drop an MKV file that has previously been written to by Haali Matroska Writer b0 (which is what Simple x264/x265 Launcher uses when encoding directly to an mkv file (x264 codec)), MKVToolnix 8.6.0 takes an extremely long time to recognize the file (locks up for around 30 seconds+, then lets me continue), but 8.5.2 recognizes it immediately.

Can you please give pre-builds 1020 (32bit)/1021 (64bit) (https://mkvtoolnix.download/windows/pre/) a try? They implement a different way of checking such files and should handle file type recognition faster.

[Boulder]

Interesting. I cannot reproduce that at the moment. Can you please tell me more about your mux settings? What kind of files are involved, what's appended to where? Ideally you could send me a mux setting file or the corresponding job queue file (https://github.com/mbunkus/mkvtoolnix/wiki/mtxcfg-file-format-and-the-jobQueue). I'd also like to know how big the files in question are exactly.I had to remove the three different cases which caused the issue - I'm currently moving stuff from my backup DVDs to my external HDD attached to the media player due to a HD crash. I'll have several other cases in which the backup MKVs were split in parts when muxing so I'll try to reproduce it while processing the discs.

I'll update to the latest version to make sure the bug report's still valid.

[Jamaika]

I wanted to ask about the export function {--raw}? How can it be used? Video and audio files don't work after unpacking.

PS If the function doesn't work it can be removed.

[Mosu]

That function is there for codec IDs mkvextract knows nothing about. Whether or not the result is something that can be used depends on the content and on the application trying to read it after extraction.

[ndjamena]

Some iTunes files have a jpg "video" track containing images for the chapters, MKVMerge sees it as an actual video track and muxes it as such. If you split the file by chapters afterwards, and then extract the "track" from each resulting file using --raw you'll end up with several perfectly functional *.jpg files.

That's just one use.

[Jamaika]

I compared the function ex. with MP4Box. There raw works. It annoys me too duplication of the file information X264 / X265. I have to create an x-Info is better probably let deletes completely.
Some iTunes files have a jpg "video" track containing images for the chapters, MKVMerge sees it as an actual video track and muxes it as such. If you split the file by chapters afterwards, and then extract the "track" from each resulting file using --raw you'll end up with several perfectly functional *.jpg files.

OK. I use the "attachments" without {--raw}.

[szabi]

Hi

Today I wanted to update 8.51 to 8.60, that alert did come up.
http://abload.de/img/avast_mkvextract860nebvx.png
Any of you have this issue?

bye
szabi

[Mosu]

That's a false positive.

[szabi]

Previous versions did never have it.

[Mosu]

Oh yes they did, dating all the way back to 2.4.1. I've even got a FAQ entry (https://github.com/mbunkus/mkvtoolnix/wiki/Virus-in-installer) about this topic!

Anti virus tools are notoriously overzealous when it comes to binaries they've never seen before. And new releases of software are by their very nature binaries the scanners have never seen before.

Such false positives are, unfortunately, rather common; there's one in at least all of the releases. Mostly in the installer itself but often enough in the binaries, too.

[Boulder]

One more reason to disable the heuristic scan of the AV program. I don't know if it ever catches anything, but it'll at least produce a lot of useless false alarms over time.

[szabi]

Ok. Correction. First time I see this.
I believe you both what say so it is added to false alert list, thx.

[Mosu]

Hey,

Just one day later, another release of MKVToolNix: v8.6.1. I'm therefore including and extending the previous announcement.

The next release of MKVToolNix is available: v8.6.0. Like the previous couple of releases this one focuses on bug fixes primarily. However, it also introduces one interesting new feature with support output mkvmerge's identification result as JSON for improved scripting.

There's also an important change breaking backwards compatibility: text files created by the tools (e.g. chapters extracted with mkvextract or redirected output of any of the tools) won't start with a byte order mark (BOM) anymore, even if they're encoded in one of the UTF-* encodings. Back in the day people believed that text files would be encoded primarily in UTF in the future and that distinguishing between those formats automatically with a byte order mark seemed sensible.

Reality has shown that things turned out differently: text files are overwhelmingly encoded in UTF-8 if they originate on Linux/Unix/Mac OS and in Windows' local encoding otherwise. Writing byte order marks isn't recommended anymore anyway.

This is an experimental change in so far as I'm willing to reverse it if enough people speak out for keeping the BOMs. So if you have legitimate concerns about this then please drop me a line.

An important change for package maintainers is that gcc 4.8.0 or newer/clang 3.4 or newer is now required for compilation due to the (header-only) library used for generating the JSON output. This concerns CentOS 6 and Debian 7 "wheezy" for which I don't offer binaries anymore as a consequence.

The Windows and Mac OS binaries are available. Most of the Linux binaries are still being built and will be available in a couple of hours.

Here are the usual links: the MKVToolNix home page (https://mkvtoolnix.download/), the Windows installer and portable version (http://www.fosshub.com/MKVToolNix.html) and the source code (https://mkvtoolnix.download/source.html).

Here's the full ChangeLog (https://mkvtoolnix.download/doc/ChangeLog) since the previous release:

2015-11-29 Moritz Bunkus <moritz@bunkus.org>
* Released v8.6.1.
* mkvpropedit, GUI's chapter & header editors bug fix: in certain situations the modified file would not contain a seek head before the first cluster anymore resulting in most players not finding elements such as attachments or the index located at the end of the file anymore. Fixes #1513 (https://github.com/mbunkus/mkvtoolnix/issues/1513).
* mkvmerge: bug fix: the change to do a deeper file analysis if no seek head was found was causing huge increases in file type detection time as popular tools like x264 don't write seek heads. The way elements at the end are searched has been changed to only scan the last 5 MB of the file instead of iterating over every level 1 element from the beginning of the file.

2015-11-28 Moritz Bunkus <moritz@bunkus.org>
* Released v8.6.0.
* all: change: none of the tools will write a byte-order mark (BOM) to text files encoded any of the UTF-* schemes anymore.

2015-11-25 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: Matroska reader bug fix: the info about which packetizer is used was output twice for each HEVC track. Fixes #1522 (https://github.com/mbunkus/mkvtoolnix/issues/1522).
* MKVToolNix GUI: bug fix: implemented a workaround for a bug in Qt which caused the GUI not to start anymore due to failing to detect a stale lock file if the GUI had crashed before on a computer with a host name that included non-ASCII characters. See https://bugreports.qt.io/browse/QTBUG-49640

2015-11-22 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: a track's number of bits per audio sample wasn't output in verbose identification mode even if it was present in the file.
* mkvmerge: enhancement: if no seek head is found before the first cluster when reading Matroska files then mkvmerge will attempt a deeper scan of all elements in the file in order to find track headers, attachments, chapters and tags located at the end of the file. See #1513 (https://github.com/mbunkus/mkvtoolnix/issues/1513) for the rationale.

2015-11-21 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: header editor bug fix: the "status" description wasn't adjusting its height properly resulting in its text being cut off. Fixes #1517 (https://github.com/mbunkus/mkvtoolnix/issues/1517).
* MKVToolNix GUI: bug fix: the program changes its working directory to the user's profile/home directory on startup allowing the removal of its installation folder even if a program started by the GUI (e.g. a web browser) is still running. Fixes #1518 (https://github.com/mbunkus/mkvtoolnix/issues/1518).
* ebml_validator: bug fix: elements with an unknown size weren't handled correctly.
* build system: fixed building and linking against libEBML and libMatroska if they're installed in a non-standard location.
* mkvpropedit, MKVToolNix GUI's chapter and header editors: the tools were unable to update elements in files without a seek head present. Fixes #1516 (https://github.com/mbunkus/mkvtoolnix/issues/1516).

2015-11-15 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: fixed two issues causing mkvmerge to write invalid data when updating track headers caused by the fix for "Re-rendering track headers: data_size != 0 not implemented yet". Fixes #1498 (https://github.com/mbunkus/mkvtoolnix/issues/1498).
* all: MKVToolNix now requires gcc 4.8.0 or later or clang 3.4 or later for compilation.

2015-11-14 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: bug fix: the options for linking to the next/previous segment UID were wrong. Fixes #1511 (https://github.com/mbunkus/mkvtoolnix/issues/1511).

2015-11-10 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: added JSON as an output format for file type identification. It can be activated with "--identification-format json --identify yourfile.ext" (or their short counterparts "-F json -i yourfile.ext").

2015-11-09 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: the VC-1 handlig code was duplicating the first sequence headers with each mux. Fixes #1503 (https://github.com/mbunkus/mkvtoolnix/issues/1503).

2015-11-08 Moritz Bunkus <moritz@bunkus.org>
* build system: bug fix: configure was checking for and using libintl if --without-gettext was used. Fixes #1501 (https://github.com/mbunkus/mkvtoolnix/issues/1501).

Have fun.

[Jamaika]

Hi Mosu

However, it also introduces one interesting new feature with support output mkvmerge's identification result as JSON for improved scripting.
Do you have any examples of applications? I understand that you can change the record XML tags, chapters, attachments on JSON. Are they included any new functions supports interactive?
https://pl.wikipedia.org/wiki/JSON

[ndjamena]

Powershell has a function called "ConvertFrom-Json" so now I can load MKVMerge -I output directly into an object without needing a complicated script to disassemble it.

There are numerous JSON libraries for c++. C# can translate it natively.

Hell, if MKVMerge had been able to output in JSON or XML a year or two ago I might have actually managed to finish the new version of MyMediaBatch before my head gave out.

[cengizhan]

adding a longer subtitle to a video, makes the video longer. for example: add a 100minutes subtitle to a 50 minutes video. the output video will be 100 minutes which you cant seek after 50 minutes.
is this a bug or a normal behaviour?

[Mosu]

Hey,

Do you have any examples of applications?

Not yet, but as ndjamena said it's trivial to import mkvmerge's identification output into data structures for your preferred programming language. Here's a trivial example in Ruby that prints the language of each track:

#!/usr/bin/env ruby

require "json"

output = `mkvmerge -F json -i #{ARGV[0]}`
result = JSON.parse(output) or fail

if !result["container"]["supported"]
puts "Container format not supported, no information possible"
exit 0
end

result["tracks"].each do |track|
if track["properties"]["language"]
puts "Track ID #{track["id"]} has language #{track["properties"]["language"]}"
else
puts "Track ID #{track["id"]} does not have a language set"
end
end

I understand that you can change the record XML tags, chapters, attachments on JSON.

I… don't really understand this sentence. If you mean whether or not tags and chapters will use JSON instead of XML: no, that's way too much effort for not enough gain.

Are they included any new functions supports interactive?

I really don't understand this sentence either. I'm sorry.

[Mosu]

adding a longer subtitle to a video, makes the video longer. for example: add a 100minutes subtitle to a 50 minutes video. the output video will be 100 minutes which you cant seek after 50 minutes.
is this a bug or a normal behaviour?

That's normal, intentional and exactly how it should work. The file's duration is the difference between its maximum timestamp and its minimum timestamp. Just because players stop when the video track stop doesn't mean the file ends there.

[ndjamena]

I think this is a continuation of Jamaikas desire to add interactive tags to his files.

JSON changes NOTHING about the files themselves, it has nothing to do with the Matroska Specs. All it does is change the OUTPUT of a single command in the MKVMerge application.

MKVMerge -I file.mkv

or

MKVMerge -i file.mkv

It just makes it easier for other applications to decipher MKVMerges identification output, nothing more.

[Jamaika]

no, that's way too much effort for not enough gain.

It just makes it easier for other applications to decipher MKVMerges identification output, nothing more.
Thanks all. Now I understand everything.

[cengizhan]

That's normal, intentional and exactly how it should work. The file's duration is the difference between its maximum timestamp and its minimum timestamp. Just because players stop when the video track stop doesn't mean the file ends there.

:thanks: i thought my video was corrupted or mkvmerge is bugged until i opened the subtitle file with an editor and saw it is longer than video.

[ndjamena]

Is there a technical reason the header editor wouldn't be allowed to shuffle the positions of tracks, ie like rearranging subtitles?

I've been doing it manually, but it would be much easier if I could just drag and drop and not have to keep track of which track number was where in case I wind up duplicating one (or leaving one out, which is the same thing).

[Mosu]

That functionality hasn't been implemented yet, neither in the GUI nor in mkvpropedit. I don't know if I'll ever implement it, though it's that I'd consider sometime in the future.

[ndjamena]

I'll stick to doing it manually then.

[SeeMoreDigital]

Can someone please remind me what the final discussion was regarding to the possibility of muxing Dolby TrueHD streams and preserving the Dolby Digital core within the .mkv container? Is it technically possible now?


Cheers

[Mosu]

If you mean you want to keep both the TrueHD and the AC3 data inside the same track: mkvmerge doesn't support that. Instead it will separate that data into two independent tracks. Meaning all of the data is preserved, but mkvmerge "sees" two tracks in such a case instead of a single one. That works even when re-muxing from M2TS, not just from elementary TrueHD files (.thd+ac3).

[SeeMoreDigital]

If you mean you want to keep both the TrueHD and the AC3 data inside the same track: mkvmerge doesn't support that. Yes, I realize that mkvmerge does not support this.

What I'd like to know is, is it now technically possible to do this with the Matroska container?

[sneaker_ger]

Mkvmerge does not support it because it is regarded as non-spec-compliant. The Matroska specs have not changed in this regard. (That may not hinder other software developers (makemkv?) to ignore that or interpret the specs in a different way.)

[SeeMoreDigital]

Mkvmerge does not support it because it is regarded as non-spec-compliant. The Matroska specs have not changed in this regard. (That may not hinder other software developers (makemkv?) to ignore that or interpret the specs in a different way.)Okay, thanks for the confirmation about this!

The reason I asked is because Oppo Digital recently removed TrueHD pass-through support for .mkv contained files due to a reliably issue with the Mediatek A/V decoding chip-set.

Oppo Digital have developed a work-around by transcoding multi-channel TrueHD audio to multi-channel PCM audio. But sadly if the TrueHD stream contains Atmos, the Atmos (object based) data is completely lost.

Sufficed to say, the Mediatek A/V decoding chip-set is able to 'pass-through' a TrueHD stream just fine when it's placed within the .m2ts container.


Cheers

[nevcairiel]

Sounds like they should fix their software. When you transmit TrueHD over HDMI, then the AC3 part is no longer present. The HDMI specs are pretty strict about that.

[SeeMoreDigital]

Sounds like they should fix their software. When you transmit TrueHD over HDMI, then the AC3 part is no longer present. The HDMI specs are pretty strict about that.Yes and no. In the case of TrueHD in m2ts, the AC3 core is still present within the stream as is the AC3 flag. And you are able to select the different streams.

[nevcairiel]

Yes and no. In the case of TrueHD in m2ts, the AC3 core is still present within the stream as is the AC3 flag. And you are able to select the different streams.

Not once it reaches HDMI. What the player does in between is not really important there. Of course it can let you select the AC3 stream.

[SeeMoreDigital]

Regardless, it would still be useful if the Matroska container supported TrueHD along with the core (as it does with DTS-HD MA). As it would provide more logical support with playback devices such as Smart TV's.

It's a right pain having to go through all your Blu-ray .mkv back-ups to add the AC3 stream... Indeed, last night I fancied watching a bit of Gravity on my LG television but was greeted with an 'Audio format not supported' message.

Anyway, if it can't be done. It can't be done :(

[Mosu]

DTS-HD MA is a very different case. TrueHD and AC3 are completely independent sets of data. One can be decoded without the other. The TrueHD data can exist and be decoded alone. So can the AC3 data.

For DTS-HD MA the situation is vastly different. Here the MA part can, in general, NOT be decoded alone. Instead the DTS core is required for decoding the MA part, too.

[nevcairiel]

The only way this actually works in MPEG-TS is that it has special metadata to mark the AC3 frames as a "substream", only this way can players identify which frames belong to the TrueHD stream, and which belong to the AC3 stream. You can't just mux both together and hope for the best, it has to be muxed properly - otherwise every player is going to break.
It seems rather unlikely that inventing a new muxing scheme for such tracks would magically fix smart TVs. It seems far more likely that they are designed to deal with this MPEG-TS variant somehow, but their MKV implementation is just broken. If you have to cater to such a TV, it seems sensible to just keep your videos in MPEG-TS.

Surely it could be muxed in MKV say using BlockAdditions or something like that, just for the sake of keeping the two streams packed "together", but players would still need to handle that, so it wouldn't make any sense and wouldn't fix anything automagically.

[SeeMoreDigital]

Surely it could be muxed in MKV say using BlockAdditions or something like that, just for the sake of keeping the two streams packed "together", but players would still need to handle that, so it wouldn't make any sense and wouldn't fix anything automagically.
I guess it's like any other implementation. Until somebody comes up with a method of doing it, device manufacturers wont be able to support it. Which really should be the advantage of adopting 'open-source' software in the first place ;)

[nevcairiel]

I guess it's like any other implementation. Until somebody comes up with a method of doing it, device manufacturers wont be able to support it. Which really should be the advantage of adopting 'open-source' software in the first place ;)

You could just mux them in two distinct streams like it is today, and a device manufacturer could read it. Why it would need the AC3 stream in the first place is beyond me, however.
Screams faulty implementation to me. The AC3 stream is not required for the TrueHD stream to work.

[SeeMoreDigital]

You could just mux them in two distinct streams like it is today, and a device manufacturer could read it...Yes I know I can. And I do. But that's not what I was enquiring about ;)

[Mosu]

I think nevcairiel's point was:

Your devices manufacturer is already doing something special regarding splitting of TrueHD+AC3 tracks M2TS so that they can decode TrueHD and throw away the AC3 part (as the AC3 part is neither required nor actually used for decoding TrueHD).
Currently TrueHD in Matroska doesn't work on that device.
Putting TrueHD+AC3 together into Matroska would require special support in a device to separate later, and that support doesn't exist yet. Therefore putting TrueHD+AC3 together into Matroska wouldn't give you any advantages over the current situation.
If the device manufacturer implemented the special support mentioned in 3. then it could just as well fix proper TrueHD support in Matroska, and you wouldn't need to put AC3 together with AC3 into Matroska anymore.

No matter which way you look at it TrueHD+AC3 in Matroska would be nonsensical.

[ndjamena]

iTunes m4vs have an atom in their headers call 'fall' that tells a player that two audio streams contain identical content encoded with different codecs.

That would be the way Matroska could implement similar functionality. Then you could mux both TrueHD and it's core into a file and have the player see them as the same, or use it on any other set of codecs as well.

Physically muxing the things into the same stream would be a hair-brained way of doing it in comparison.

[Mosu]

Hmm I don't see much use for such a flag.

It seems to me that the reson why DVDs and Blu-rays put the same content encoded with different codecs onto the same disc is compatibility. The standards don't mandate that all players must support all codecs. Additionally existing hardware should be supported (AC3) while offering improved (= lossless) content for newer hardware that supports it (TrueHD).

Back to Matroska: the problem is already that players don't support certain features (TrueHD in Matroska). To me the probability that players will implement proper support for these codecs inside Matroska is much, much higher than that they will implement support for a flag that says "these two tracks are the same; for compatibility reasons we've added both, use the one you support". They'd need an update for a functionality that supposedly would make it easier for them not to need updates ;)

As the use for such a flag would be limited to these kinds of compatibility scenarios I don't see the widespread use of it at all.

Not everything MP4 does makes sens for Matroska in my opinion.

[ndjamena]

I believe the point is if there's a main and a commentary the player knows not to use the commentary/audio description as default if they don't support the main codec, and all the 'fall' tracks effectively inherit the default flag from the master track.

iTunes uses it for AC3 tracks, the AAC is muxed in first with the enabled flag set. Any player that understands the 'fall' atom will find the AC3 and play that instead if it can, the rest will just play the AAC as normal.

It is better than trying to mux them all into the same track.

[Boulder]

I had to remove the three different cases which caused the issue - I'm currently moving stuff from my backup DVDs to my external HDD attached to the media player due to a HD crash. I'll have several other cases in which the backup MKVs were split in parts when muxing so I'll try to reproduce it while processing the discs.

I'll update to the latest version to make sure the bug report's still valid.I reproduced the error, here's the job queue file: https://drive.google.com/file/d/0BzeF_1syecQwQllKbTRkSlBqUTA/view?usp=sharing

[Frechdachs]

Hi, I'd like to report that, at least for me, mkvmerge ist handling encoding delay (also known as priming) of AAC incorrectly.

I did some tests:

1. encoding with qaac --> muxing with a video file using mkvmerge; this results in a delay of -22ms relative to the source, so mkvmerge actually cuts off more than it has to.
2. encoding with NeroAacEnc --> muxing with video file using mkvmerge; this results in a delay of -10ms relative to the source, also cutting off more than it should.
3. encoding with qaac with --no-delay flag enabled --> muxing with video file using mkvmerge; this works fine, qaac itself removes the delay and mkvmerge does not cut anything off.

Can anyone confirm this results?

If I recode the AAC tracks with ffmpeg to flac (before muxing obviously), the delay gets handled properly. Muxing those flacs with mkvmerge results in no delay.

Edit: Note that I used a stereo file with a sample rate of 48KHz in this test. Also, my results could be off by +/-1ms, since I used Audacity and my eyes for testing.
Update: Old ffms2 was the culprit, not mkvmerge.

[sneaker_ger]

AAC delay handling has been tested by a number of people and should be correct. What exactly do you expect to happen in cases #1 and #2? Can you upload samples to show what's wrong? Things like sampling frequency and frame length are important to know to correctly judge this.

[sneaker_ger]

Edit: Note that I used a stereo file with a sample rate of 48KHz in this test. Also, my results could be off by +/-1ms, since I used Audacity and my eyes for testing.
Did you factor in the positive delay (look at first audio timecode) or did you just extract and open in Audacity? Mkvmerge drops every frame starting before 0ms and has to delay via timecode to make up for it in most cases. I.e. if a frame is 20ms long, the encoder delay is 10 ms, the frame would have to start at -10ms. What mkvmerge does is delete the frame and set first timecode to +10ms.

[Frechdachs]

Can you upload samples to show what's wrong?
Sure. (https://0x0.st/-VN.7z)

What exactly do you expect to happen in cases #1 and #2?
The same as in case #3.

Did you factor in the positive delay (look at first audio timecode) or did you just extract and open in Audacity?
No, can you tell me how I can look at the actual timecodes?

Here's how I tested it:
I first noticed the delay in Aegisub. It uses FFmpegSource to decode audio, so if there is a positive delay shouldn't it be taken into consideration?
Then I demuxed and encoded the track to PCM to open it in Audacity, same result.

[sneaker_ger]

No, can you tell me how I can look at the actual timecodes?
Different ways:
1. Look at delay info in MediaInfo
2. use mkvextract: mkvextract timecodes_v2 file.mkv 0:timecodes_of_first_track.txt 1:timecodes_of_second_track.txt 2:timecodes_of_third_track.txt etc.
3. use mkvinfo (GUI), show all elements (ctrl+a) and look into clusters for first timing


I first noticed the delay in Aegisub. It uses FFmpegSource to decode audio, so if there is a positive delay shouldn't it be taken into consideration?
I don't know from the top of my head. The latest "stable" Aegisub is quite old and there have been delay bugfixes in ffms2 in the meantime. Might want to check a recent trunk build (http://plorkyeran.com/aegisub/). (Maybe exchanging the ffms2 dll is also possible, have not tested)

Then I demuxed and encoded the track to PCM to open it in Audacity, same result.
When you demux to a raw format you lose all delay info so that is bound to give incorrect results.