MKVToolNix v99.0 released

[lvqcl]

Software development is not just a 'technical' thing. Often 'non-technical' issues matter much more than 'technical' ones.

[Liisachan]

@Mosu
Don't worry. Practically, that won't be a problem. I generally avoid the bleeding-edge (too new) versions anyway for actual encoding, after having experienced a lot of unexpected breaking changes, intentional or otherwise.

That said, testing new versions and creating sample test clips was fun in a way, arguably helpful for other users too, spotting potential issues if any. Maybe I can't personally do that actively anymore, but I'm sure you'll keep getting a lot of bug reports from many users... I hope there will be no hard feelings for anyone :)

Just asking for a clarification:

Which is the last MKVToolNix version which runs without issues under Win7 ? Although 66 seems to work for me, you don't necessarily need to use the last version that supports Win7. Unless you're doing something rather exceptional, any version (20, 30, 40, 50, etc.) works equally, essentially writing the bit-identical MKV files, if unessential meta-data is ignored.

For GUI-users in general (not only Win7 users), I'd recommend Version 57 or before (e.g. 56.1), if you ever use font attachments, are not too familiar with the subtlety of the font mime issues, and you'd like to support both old and new players. Starting from 58, GUI writes (without any warnings) an MKV file which older players don't understand - potentially a serious disadvantage (without any practical advantages). This happened due to a combination of unfortunate circumstances, not a bug but by design.

58+ too can optionally write an MKV file understandable by both old and new players, if you manually set the mime types. This compatibility mode is opt-in, disabled by default, though.

If you're creating an MKV file personally and you know you only use new players that support the new mime types, there won't be any problems at all either way. MPC-HC (clsid) and MPC-BE are good examples, where newer mime types are fully supported, but not the last version of "official" MPC-HC.
mpv seems fine too (at least for common cases).

VLC is not yet fully supporting the new mime types, but it has a fail-safe mechanism where the attachment file extension is checked when it doesn't understand the mime type (meaning, superficially it works in most cases, though the new mime types may not be fully supported explicitly). Btw, currently VLC (v3.0.0–v3.0.16) can't play MKV with Vorbis or Opus audio correctly, so don't use Vorbis in MKV if your target player is VLC!

PS
Even if you're fine with the newly standardized font mime types, Versions 58, 59 must be avoided. These are experimental versions, where new mime types were introduced, but are not yet stable one way or another. Version 60+ should work fine.

To make MKV files that both old and new players understand using v58+, you'll need to check "Use legacy MIME types for font attachment" in Preference | GUI | General Options. Enabling this option has no bad side effects; for backward compatibility, legacy mime types are written internally instead of the newly standardized ones, so this may not be your option if you're a "standard compliance" geek. The good news is, the Matroska specs now say a player should try to support both legacy and new font mime types, so basically these legacy types are guaranteed to work forever (so MKV written by v57 and before will always play okay too).

If not enabling this option: newer players are fine; older players before 2020 don't load the attached font files for subtitles. If the viewer is lucky, subtitles are still readable with some system default fonts, but they may be garbled if subtitles really require attached font files: e.g. if the language is not well supported by the system fonts. Without the intended fonts, also sign-subs may be shown in weird positions and fancy karaoke effects will be obviously broken.

While this situation is a nightmare for a SSA/ASS user/typesetter, if you don't use styled subtitles with font attachments at all, then these considerations are irrelevant for you.

Edit (2022-04-23)
As mentioned, VLC v3.0.0–v3.0.16 has vorbis/opus bugs; which was fixed in v3.0.17 (released around March, 2022). Changelog (NEWS) says:

Changes between 3.0.16 and 3.0.17:
----------------------------------
[...]
* Fix missing audio start of Opus audio in MKV/WebM

[manolito]

Thanks a lot Liisachan for this very useful information...

I was still using version 56.1 (32bit), now I switched to version 57 (also 32bit) without experiencing any problems. Looks like this will become my final MKVToolNix version...

Thanks again
Manolito

[hubblec4]

Possible solution to get rid of the CreateDXGIFactory2 dependency:
https://forum.qt.io/topic/78380/entry-point-not-found-the-procedure-entry-point-createdxgifactory2-could-not-be-located-in-the-dynamic-link-library-dxgi-dll

Is this a solution for Mosu or for the Win7 users?

For me it looks to complicate.

[Mosu]

That article is about compilation, so probably intended for me. But as stated earlier, I don't support Windows 7, therefore I won't spend time on such endeavors.

[hubblec4]

I can fully understand you, you won't support this "old" OS WIN7.
But on the other hand I can also understand the users (like me). WIN7 is the last Windows what I want to use.

Install a VM with Win10/11 is also not a solution, and change the OS to Linux is fine but there is no good Matroska player like MPC-HC/BE all other players are bad Matroska players.

And it seems that also for me, the last MTX version will be 66.

[Mosu]

That's totally your choice, and I don't really care what you do with your time & your devices (nor should I).

You (and everyone else insisting they'll never use anything else than Win7) won't stick with that choice forever anyway. One day you'll find yourself in the situation of needing or wanting a new computer, and you realize that your new hardware just doesn't work with Win7 anymore. Or your other favorite application besides MTX doesn't work with Win7 anymore, but you cannot justify not updating it anymore, e.g. because there's a new codec out there you want to use and it's only supported by that new version of the program that doesn't run on 7 anymoire. Or any other reason, really. Y'all can put it off, probably for quite a while, but y'all will have to upgrade or migrate to something else one day.

[hubblec4]

Yes I fully agree with that.
The time will be come, where is no way out to upgrade.

But I hope not in this decade :-)

[clsid]

It not only means dropping Windows 7, but also Windows 8.0, which together are about 15% of Windows users worldwide.

Fixing the current issue might take you an hour. Dealing with complaints much longer over time. But your choice. It is an unnecessary requirement for functionality in Qt that you don't use.

[Mosu]

You're actually wrong in your assumption. Always taking the easier route instead just in order to avoid having to deal with complaints would have led to MKVToolNix being abandoned ten years ago or even earlier. Complaints are always loud, people often hate & change and the ones that really hate it complain very loudly. You know what I really, really loath wrt. programming? Having to deal with legacy technology. This includes, but isn't limited to, having to cater to operating systems that even their main provider doesn't support anymore.

Back when I rewrote mmg to MKVToolNix GUI I mostly did it because I was completely demotivated to continue working with a) the old code base and even more so b) wxWidgets' extremely prickly design & idiosyncrasies. You probably remember how loudly and strongly people objected to the new GUI. Well, I could have just taken the easier route, but that one would have been to cede working on MKVToolNix (the whole project) altogether. That was my decision back then: "either I'm doing this not only to improve life for my users, but also for myself, or I'm walking away".

[hubblec4]

Hi Mosu

For me is all fine with your decisions and I will follow your way's.
There is no reason why you change your programming direction for a small amount of user's.

Keep on all your good and hard work. We all love it.

[Perenista]

For some reason the last MKVTOOLNIX version seems to disable partially dark mode from Windows 11 (last version, too). If you close and reopen the program it will work again.

Randomly it is disabling for no reason.

I took a screenshot from right now, showing this bug.

https://i.postimg.cc/PJkWJHGn/X1.jpg
https://i.postimg.cc/5yqwFr1Y/X2.jpg

And this is what we see if we close and reopen:

https://i.postimg.cc/wMSS77qT/SEMERRO1.jpg
https://i.postimg.cc/WpCR9fGL/SEMERRO2.jpg

Due to the nature of this problem I can't reproduce again. I don't know what is causing it. It wasn't like that in previous versions.

[clsid]

You're actually wrong in your assumption. Always taking the easier route instead just in order to avoid having to deal with complaints would have led to MKVToolNix being abandoned ten years ago or even earlier. Complaints are always loud, people often hate & change and the ones that really hate it complain very loudly. You know what I really, really loath wrt. programming? Having to deal with legacy technology. This includes, but isn't limited to, having to cater to operating systems that even their main provider doesn't support anymore.But this is not about using old or legacy code. It is a matter of excluding some parts of the Qt6 codebase. Parts that you probably aren't using (d3d12).

[Mosu]

But this is not about using old or legacy code. It is a matter of excluding some parts of the Qt6 codebase. Parts that you probably aren't using (d3d12).

If it's really as easy as adding -no-feature-d3d12 when building Qt 6, I may actually do that once the multi-display issues in Qt 6 have been ironed out.

[Mosu]

Looks like a bug caused by the transition to Qt 6 is the fact that the main MKVToolNix GUI window always opens on display 1, even if it was previously opened/closed on display 2 (assuming display 1 is to the left of display 2). Additionally, opening any context menus while the UI is on display 2 causes them to open on display 1.

Snowknight26, Qt 6.3.0 was just released. Can you please give this build (https://mkvtoolnix.download/windows/pre/64-bit/qt630-001/) a try wrt. to multi-display issues? It works fine on my multi-display Windows 11 system — but then again, so did release 67.0.0 (with Qt 6.2.4), meaning I currently don't have a system I can reproduce the multi-display issues on.

Thanks!

[Mosu]

But this is not about using old or legacy code. It is a matter of excluding some parts of the Qt6 codebase. Parts that you probably aren't using (d3d12).

And you're wrong about this, too:

Qt 6 doesn't support Windows 7 (https://doc.qt.io/qt-6/supported-platforms.html) anymore.
Qt 6's build system was completely rewritten. The configure tool doesn't exist anymore; therefore the "-no-feature-…" options don't apply. Looking for an equivalent "-DFEATURE_…" setting in the CMake files yields… nothing (e.g. "grep -r -i d3d12"). There simply isn't an option to disable Direct3D 12 anymore.

And that's the end of the amount of time I'm going to invest in Windows 7 support.

[Snowknight26]

Snowknight26, Qt 6.3.0 was just released. Can you please give this build (https://mkvtoolnix.download/windows/pre/64-bit/qt630-001/) a try wrt. to multi-display issues?

This build seems to have fixed all the multi-monitor issues I could find.

[Liisachan]

Windows 7 users:
To keep using Win7 is not the only options to avoid Win10. For example, you can use MKVToolnix GUI (and VLC) on Tails, just like you do on Win7. Tails is a Linux OS, designed for ordinary, privacy-oriented users. You can easily install this OS from Win7-64 into a USB stick (only taking 10 minutes, once you download the files). So I hope there will be no negative feelings for anyone... Win7 users can stop complaining and others can stop criticizing Win7, as Win7 & Tails can cleanly coexist.

In case someone is interested: To install MKVToolnix or anything personal on Tails, you'll need to unlock Persistent Storage and set up an admin password when starting Tails (which you can do easily in the login screen). Then, when it starts, open System Tools > Synaptic Package Manager, and search "mkv" to find "mkvtoolnix" and "mkvtoolnix-gui". Select them and click Apply, to install them (with dependencies).

They'll be installed in /usr/bin, so you can type this, in Terminal, to start GUI:
/usr/bin/mkvtoolnix-gui
Or to use mkvmerge:
/usr/bin/mkvmerge

The bad news is, the package installed this way (or via apt) is rather old (v31.0.0 as of writing this), though it does work. Hopefully one can get a newer version in the future.

Edit (2022-04-18): After installed, you can also start MkvtoolnixGUI via its icon under [Applications] (=something like "Start" button on Windows) -> Sound & Video. Terminal = something like "Dos box".

[Mosu]

This build seems to have fixed all the multi-monitor issues I could find.

Thanks for testing & the confirmation. I'll ask some of the other reporters for tests as well.

[jpsdr]

Sorry if it's a stupid question, but...

Is it :
a) All the files : mkvextract.exe, mkvinfo.exe, mkvmerge.exe, mkvpropedit and mkvtoolnix-gui.exe not Windows7 compatible.
b) Only mkvtoolnix-gui.exe.

If it's b), in that case, one possible solution, but not easy because it needs someone willing to do it, is "just" ;) to make another Windows7 compatible gui.
For example, there is gMKVExtactGUI made by GPower2. It works under Windows7, so finaly will the future mkvextract.exe version still be working under Windows7 ?
I don't exactly know (and so never used) what QT is, but the few i've understood (if i'm not wrong), it's just for GUI, so, only mkvtoolnix-gui is using it, so, if i'm still not wrong, the others programs should still work under Windows 7.
Correct me if i'm wrong somewhere.

Edit
Easier !!!!
If it's the case, you just have to overwrite mkvtoolnix-gui.exe of the new version with the latest working under Windows 7.
Crossing fingers... :D

[Mosu]

All programs use the Qt library. Qt 6 doesn't support Windows 7 officially. The only error I've seen so far references DirectX, though, and that one is GUI only, obviously, so the CLI tools might actually still run. If they do, it's accidental, not intentional.

[filler56789]

Sorry if it's a stupid question, but...

Is it :
a) All the files : mkvextract.exe, mkvinfo.exe, mkvmerge.exe, mkvpropedit and mkvtoolnix-gui.exe not Windows7 compatible.
b) Only mkvtoolnix-gui.exe.

Correct answer: a).

The exact error message complaining about a "procedure entry point not found" may vary, depending on how many updates your Windows 7 setup has (not) received.

Mosu thought it would be a good idea to replace the olde and goode file magic.mgc with a GUI-library which thinks ATRAC9 is Vorbis. :D
How good is that? :)

EDIT:
I wouldn't mind losing the GUI, but only the GUI, of the MKVtoolnix suite under Windows 7.
I wish there were alternative builds of MKVtoolnix (https://forum.videohelp.com/threads/405407-NON-OFFICIAL-Windows-builds-of-MKVtoolnix-do-they-exist), but (so far) they don't exist :-/

[jpsdr]

Ok, so the last Windows 7 accidentaly working will probably be the 67.0.0.1, because for the next build, it will be using QT6.

[filler56789]

Ok, so the last Windows 7 accidentaly working will probably be the 67.0.0.1, because for the next build, it will be using QT6.

mkvtoolnix-64-bit-67.0.0-revision-027-gdedb7da46,
thus far.

[tebasuna51]

A difference between v67 and v66 is when you select Help -> System Information:

I'm using W10 v1607 and receive the message: "No problems were found with the installation.", but there are a new section not present in v66:
## Supported audio codecs

* AAC
* AC3
* ALAC
* EAC3
* FLAC
* MP3
* WMA

## Supported file formats

* AAC
* FLAC
* MP3
* MPEG4
* Matroska
* Mpeg4Audio
* QuickTime
* WMA
* WMV
* WebM

Is it a new limit about MkvToolNix support?
What about DTS, TrueHD, PCM, ...?

[filler56789]

A difference between v67 and v66 is when you select Help -> System Information:

I'm using W10 v1607 and receive the message: "No problems were found with the installation.", but there are a new section not present in v66:

## Supported audio codecs

* AAC
* AC3
* ALAC
* EAC3
* FLAC
* MP3
* WMA

## Supported file formats

* AAC
* FLAC
* MP3
* MPEG4
* Matroska
* Mpeg4Audio
* QuickTime
* WMA
* WMV
* WebM

Weird. :confused:

Using "version 67.0.0.27" under Windows 7 x64 and there is not a word about "supported codecs and formats". :confused:
# MKVToolNix

## General

* MKVToolNix GUI version: 67.0.0.27
* mkvmerge version: 67.0.0.27
* Installation type: portable
* Installation path: B:\COMMONAPPS\MKVTOOLNIX
* INI file location: B:\COMMONAPPS\MKVTOOLNIX\mkvtoolnix-gui.ini

## Installation problems

No problems were found with the installation.

# System

## Operating system
* Name: Windows
* Version: 6.1.7601
* Pretty name: Windows 7 Version 6.1 (Build 7601: SP 1)

## Screens

### Screen 0

* Device pixel ratio: 1
* Logical DPI: 96x96
* Physical DPI: 72.0355x72.0355
* Physical size: 677x381
* Virtual size: 1920x1080
* Geometry: 1920x1080@0x0

### Desktop scaling settings

* Scaling mode (`Win8DpiScaling`): not set
* Scaling override (`DesktopDPIOverride`): not set
* System-wide scale factor (`LogPixels`): not set

## Environment variables

* `LANG=en`
* `LANGUAGE=`
* `LC_ALL=`
* `LC_CTYPE=`
* `LC_MESSAGES=en`
* `MKVMERGE_DEBUG=`
* `MKVTOOLNIX_DEBUG=`
* `MTX_DEBUG=`
* `MTX_LOGGER=`
* `QT_AUTO_SCREEN_SCALE_FACTOR=`
* `QT_DEVICE_PIXEL_RATIO=`
* `QT_SCALE_FACTOR=`
* `QT_SCALE_FACTOR_ROUNDING_POLICY=`
* `QT_SCREEN_SCALE_FACTORS=`

# Qt

* Version: 5.15.3
* Build ABI: x86_64-little_endian-llp64

# Compiler and libraries

* Compiler: g++ 11.2.0
* Boost: 1.78.0
* cmark: 0.30.2
* dvdread: 6.1.2
* EBML: 1.4.2
* FLAC: 1.3.3
* fmt: 8.1.1
* Matroska: 1.6.4
* nlohmann-json: 3.10.5
* pugixml: 1.12.0
* Vorbis: Xiph.Org libVorbis 1.3.7
* zlib: 1.2.12

[Mosu]

That section is only present for versions compiled with Qt 6. It queries Qt 6 for the container formats & audio codec it (= the Qt library) supports. I did that due to v6 supporting different playback libraries than 5 on Windows (v5 goes through DirectShow for audio playback whereas v6 goes through WMF, and the latter doesn't supports neither Vorbis nor Ogg).

There are three things to know about this:

This only affects audio playback for the "run jobs" configuration in the preferences. It has no effect whatsoever on which formats mkvmerge supports for multiplexing.
Qt v5 simply doesn't support querying that information. That's why it hasn't been there before.
The list is somewhat incomplete and/or misleading. For example, Opus-in-WebM seems to work even if Opus isn't listed in the audio section.

I can see how having that list there is misleading, especially without all the other contextual information. I mostly wanted it to have there to make debugging easier (both for the user & for me — I often ask users to simply copy & paste & send me the system information content). I'll think about removing it again given its limited value, or adding a couple of lines explaining what it's used for.

[tebasuna51]

1. This only affects audio playback for the "run jobs" configuration in the preferences. It has no effect whatsoever on which formats mkvmerge supports for multiplexing

Good to know. Thanks.

[FranceBB]

Hi there,
I'm trying to mux a DolbyE track to mkv, it says "PCM" instead of "DolbyE".


If you want a DolbyE sample muxed in .wav and ready to be muxed in .mkv, take a look here (link expires in 7 days): https://we.tl/t-rIQuYtp4Mg


Anyway, this is what I'm trying to mux instead at work (which obviously I can't share):


https://i.imgur.com/mMRMHSf.png

I'm muxing the following video:



General
Complete name : W:\00_INGEST_MAM\MMA\media.dir\UPU50006_DEMUXED_1.m2v
Format : MPEG Video
Format version : Version 2
File size : 55.2 GiB
Duration : 2 h 38 min
Overall bit rate mode : Constant
Overall bit rate : 50.0 Mb/s

Video
Format : MPEG Video
Format version : Version 2
Format profile : 4:2:2@High
Format settings : BVOP
Format settings, BVOP : Yes
Format settings, Matrix : Default
Format settings, GOP : M=3, N=12
Format settings, picture structure : Frame
Duration : 2 h 38 min
Bit rate mode : Constant
Bit rate : 50.0 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 FPS
Standard : Component
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.965
Time code of first frame : 06:14:59:13
GOP, Open/Closed : Closed
Stream size : 55.2 GiB (100%)
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709


with the following 4 audio tracks (DolbyE, DolbyE, PCM, PCM):

Track 1:

General
Complete name : W:\00_INGEST_MAM\MMA\media.dir\UPU50006_DEMUXED_2.wav
Format : Wave
File size : 2.54 GiB
Duration : 2 h 38 min
Overall bit rate mode : Constant
Overall bit rate : 2 304 kb/s

Audio #1
ID : 1
Format : Dolby E
Format settings : Little
Muxing mode : SMPTE ST 337
Codec ID : 1
Duration : 2 h 38 min
Bit rate mode : Constant
Bit rate : 1 291 kb/s
Channel(s) : 6 channels
Channel layout : L C Ls X R LFE Rs X
Sampling rate : 48.0 kHz
Frame rate : 25.000 FPS (1920 SPF)
Bit depth : 20 bits
Stream size : 1.42 GiB (56%)

Audio #2
ID : 2
Format : Dolby E
Format settings : Little
Muxing mode : SMPTE ST 337
Codec ID : 1
Duration : 2 h 38 min
Bit rate mode : Constant
Bit rate : 505 kb/s
Channel(s) : 2 channels
Channel layout : X X X L X X X R
Sampling rate : 48.0 kHz
Frame rate : 25.000 FPS (1920 SPF)
Bit depth : 20 bits
Stream size : 571 MiB (22%)



Track 2:


General
Complete name : W:\00_INGEST_MAM\MMA\media.dir\UPU50006_DEMUXED_3.wav
Format : Wave
File size : 2.54 GiB
Duration : 2 h 38 min
Overall bit rate mode : Constant
Overall bit rate : 2 304 kb/s

Audio #1
ID : 1
Format : Dolby E
Format settings : Little
Muxing mode : SMPTE ST 337
Codec ID : 1
Duration : 2 h 38 min
Bit rate mode : Constant
Bit rate : 1 291 kb/s
Channel(s) : 6 channels
Channel layout : L C Ls X R LFE Rs X
Sampling rate : 48.0 kHz
Frame rate : 25.000 FPS (1920 SPF)
Bit depth : 20 bits
Stream size : 1.42 GiB (56%)

Audio #2
ID : 2
Format : Dolby E
Format settings : Little
Muxing mode : SMPTE ST 337
Codec ID : 1
Duration : 2 h 38 min
Bit rate mode : Constant
Bit rate : 505 kb/s
Channel(s) : 2 channels
Channel layout : X X X L X X X R
Sampling rate : 48.0 kHz
Frame rate : 25.000 FPS (1920 SPF)
Bit depth : 20 bits
Stream size : 571 MiB (22%)




Track 3:


General
Complete name : W:\00_INGEST_MAM\MMA\media.dir\UPU50006_DEMUXED_4.wav
Format : Wave
File size : 2.54 GiB
Duration : 2 h 38 min
Overall bit rate mode : Constant
Overall bit rate : 2 304 kb/s

Audio
Format : PCM
Format settings : Little / Signed
Codec ID : 1
Duration : 2 h 38 min
Bit rate mode : Constant
Bit rate : 2 304 kb/s
Channel(s) : 2 channels
Sampling rate : 48.0 kHz
Bit depth : 24 bits
Stream size : 2.54 GiB (100%)




Track 4:


General
Complete name : W:\00_INGEST_MAM\MMA\media.dir\UPU50006_DEMUXED_5.wav
Format : Wave
File size : 2.54 GiB
Duration : 2 h 38 min
Overall bit rate mode : Constant
Overall bit rate : 2 304 kb/s

Audio
Format : PCM
Format settings : Little / Signed
Codec ID : 1
Duration : 2 h 38 min
Bit rate mode : Constant
Bit rate : 2 304 kb/s
Channel(s) : 2 channels
Sampling rate : 48.0 kHz
Bit depth : 24 bits
Stream size : 2.54 GiB (100%)





and it detects it as PCM instead:

https://i.imgur.com/erMlIzB.png


Don't get me wrong, the file is muxed as is, but it would be nice to show the right codec there as DolbyE rather than PCM. :)

for more samples (very very short, few seconds) which do not expire, check this:

Sample1: Link (https://user-images.githubusercontent.com/18946343/140714877-ca9ab507-b8a1-4738-af1d-0bcc61bc99df.mov)

Sample2: Link (https://user-images.githubusercontent.com/18946343/140722392-a623950a-8248-4863-9ef8-0d70b6c86236.mov)

Sample3: Link (https://user-images.githubusercontent.com/18946343/140723130-8c0ba961-a98c-41c3-a293-d6494b3a18ee.mov)

[Mosu]

Dolby E is simply not supported.

[FranceBB]

Dolby E is simply not supported.

I see... Will it be supported in the future? :)

[Mosu]

Given that it's a format that is explicitly NOT wanted on the devices of end users: unlikely.

[filler56789]

..........
Don't get me wrong, the file is muxed as is, but it would be nice to show the right codec there as DolbyE rather than PCM. :)

+1.
Unsupported formats should be detected as unsupported formats,
not misdetected as supported formats. :sly:

Maybe I should test older versions of MKVtoolnix to see if the misdetection was already present in the goode and olde magic.mgc or if it was introduced by the almighty :rolleyes: Qt.

[tebasuna51]

Here I'm with Mosu, MkvToolNix works perfectly loading these wav files like PCM, if they are like the sample upload by FranceBB: Test_DolbyE.wav

The file have a correct wav header than say:

File: D:\Temp\Test_DolbyE.wav
Size: 2730401360 bytes
---------------------------------------------- Header Info
ChunkID .....: RIFF
RiffLength ..: 2730401352
Container ...: WAVE
SubchunkID ..: JUNK (Length: 28) [filled with 0's]
SubchunkID ..: fmt (Length: 16)
AudioFormat .: 1 (Integer)
NumChannels .: 2
SampleRate ..: 48000
ByteRate ....: 288000
BlockAlign ..: 6
BitsPerSample: 24
SubchunkID ..: data (Length: 2730401280)
Offset data .: 80
Duration ....: 9480.56 sec., (2h. 38m. 0.56s.)
------------------------------------------------- End Info

This is a perfect 2h. 38m. 0.56s. of noise PCM stereo, 24 bits, 48 KHz.

I don't know how MediaInfo can detect than this is Dolby E, but can't be stored with a fake INT wave header.

Wav is a container but if the data is not PCM INT the AudioFormat can't be 0x0001
For instance for:
Dolby AC2 Audioformat: 0x0030
Dolby AC3 SPDIF Audioformat: 0x0092
Maybe we need a new one for Dolby E

[manolito]

Which is the last MKVToolNix version which runs without issues under Win7 ? I'm not asking for official Win7 support, I just want to know which version is the last one without any known Win7 problems. I have no intention to upgrade Windows to a later version than Win7, so I just want to know which MKVToolnix version will become my last version.


FWIW I just updated the older archive with the last XP compatible version of MKVToolNix with the latest Win7 compatible version (32-bit only). The download link is here:

https://files.videohelp.com/u/172211/ToolNix_XP_Win7.zip


Cheers
manolito

[filler56789]

This is a perfect 2h. 38m. 0.56s. of noise PCM stereo, 24 bits, 48 KHz.

I don't know how MediaInfo can detect than this is Dolby E, but can't be stored with a fake INT wave header.

By analyzing/probing the stream itself, I guess...

Isn't DTS-in-WAV also read as "PCM noise" by the "unaware decoders"? :confused:

FWIW:

https://wiki.multimedia.cx/index.php/DTS

AND

https://wiki.multimedia.cx/index.php/Dolby_E

[FranceBB]

Isn't DTS-in-WAV also read as "PCM noise" by the "unaware decoders"? :confused:


Yep, it is. Unaware decoders will read it as noise 'cause they're gonna believe it's PCM and will try to decode it as is.

This is the official Dolby E Document: https://developer.dolby.com/globalassets/professional/dolby-e/dolby-e-high-level-frame-description.pdf

About Mediainfo detection, see here:

https://github.com/MediaArea/MediaInfoLib/blob/d5fb067e1539aa7a74c491e8262c81214f9c8bcb/Source/MediaInfo/Audio/File_DolbyE.h

https://github.com/MediaArea/MediaInfoLib/blob/7da9e111263496185627bbfb32e654842fb8cb9b/Source/MediaInfo/Audio/File_DolbyE.cpp

https://github.com/MediaArea/MediaInfoLib/blob/75adb6f8b3dc59f521344fe81055834047d88d3b/Source/MediaInfo/Audio/File_DolbyAudioMetadata.cpp

https://github.com/MediaArea/MediaInfoLib/blob/d5fb067e1539aa7a74c491e8262c81214f9c8bcb/Source/MediaInfo/MediaInfo_Events_Internal.h

About samples, I can share as many samples as you want. :)

[Mosu]

Just to make it clear: I won't be spending any time on Dolby E.

[FranceBB]

Just to make it clear: I won't be spending any time on Dolby E.

Would a donation change your mind? You know, just saying, hypothetically... :D

[Mosu]

No, it wouldn't.

[tebasuna51]

By analyzing/probing the stream itself, I guess...

Isn't DTS-in-WAV also read as "PCM noise" by the "unaware decoders"? :confused:

For what analyze the well defined data as PCM INT?

The dts-wav files have a unique use: cheat the CD burner to create a CD Audio than some (not all) players can send like dts multichannel streams by spdif to AVR's
Correct (not "unaware decoders") must play the dts-wav's files like noise.
It's easy extract the correct .dts file (with less size also) from a dtswav and use it to play correctly with standard players.

The correct way to store a DTS in wav container is use the AudioFormat 0x0008

This is the official Dolby E Document: https://developer.dolby.com/globalassets/professional/dolby-e/dolby-e-high-level-frame-description.pdf

Nothing about store Dolby E in WAV files.

About Mediainfo detection, see here:

I'm not interesed in what MediaInfo do, it is not a audio reference for nobody. MediaInfo show wrong data with many audio files.

If we use the WAV container must follow the M$ rules, and put an AudioFormat different.

I suggest use 0xDB0E or 0x0DBE (DolBy E, like 0xF1AC is used for FLAC) not in use in 1998 RFC 2361 (https://datatracker.ietf.org/doc/html/rfc2361), also not used in last mmreg.h (https://github.com/tpn/winsdk-10/blob/master/Include/10.0.14393.0/shared/mmreg.h) I know

[tormento]

@Mosu

Talking about audio formats, why does Dolby Digital Plus is still recognized as AC-3 and not EAC-3?

Moreover, unlike AC-3, it can have a core (or not) and ATMOS metadata, such as THD. They are two different beasts on their own.

[filler56789]

@Mosu

Talking about audio formats, why does Dolby Digital Plus is still recognized as AC-3 and not EAC-3?

Moreover, unlike AC-3, it can have a core (or not) and ATMOS metadata, such as THD. They are two different beasts on their own.

I have just tested the latest GUI with a .EAC3 elementary stream and it says:

"container = AC-3, codec = E-AC-3".

For me the distinction is good enough. :)

[jpsdr]

mkvtoolnix-32-bit-67.0.0-revision-033-g39529c226-setup so far so good... ;)

[manolito]

Thanks for the heads-up...

This version still supports Win7 (only tested the 32-bit version). Nice...

[Liisachan]

Maybe we should stop annoying Mosu directly or indirectly, who had made it clear, as early as 2019, that Win7 was no more actively supported.

If your main machine is Win7 64-bit, and you want to use MKVToolnix67+, you could try Tails.


You can keep using Win7, while booting to Tails only when necessary. It's not a VM but runs on its own, so it runs on Win7 box like forever (unlike Cygwin, which will eventually stop supporting Win7).
You can install Tails in 10 minutes, very easily, once you download a big image.
Both mkvmerge (CUI) and GUI run on Tails, which is a Debian-based OS.
Tails's file manager can read/write files on your Win7 box, so basically you don't need to migrate to Linux.
If you're avoiding Win10 for privacy concerns, Tails is exactly for you.
Tails is designed for ordinary people. It's easy to use. You don't need to be a geek. You don't need to manually compile anything yourself.
Except, as of writing this, you can't install the latest version of MKVToolnix on Tails via Package Manager by default. But you're happily using Win7, a 10-year-old OS! Why a sudden attachment to the newest version of mkvmerge, when the created MKV is essentially identical even if you use an older mkvmerge? If you're ok with a slightly old version of MKVToolnix, then you can have it on Tails by just a few clicks.


https://yosei.fi/aaa/mkvtoolnix67_on_tails_sm.jpg (https://yosei.fi/aaa/mkvtoolnix67_on_tails.png)

The screen shot shows MKVToolnix 67 (GUI & CUI on terminal) on Tails, running on my Win7-64 box. Notice the file manager's "Show other locations". Click it, and you can use your files on HD/SSD, although Tails itself runs from a USB stick. Tails' i/f is basically like Windows. Since it's Debian, your Windows tools don't run on it. But you can use the same audio/video/subtitle files on your HD, so you can basically use mkvmerge just like on Windows :)
This may be a practical option in case you want to use a newer version of mkvmerge (although personally, I usually don't use too new versions, except for testing purpose).

[StainlessS]

If your main machine is Win7 64-bit, and you want to use MKVToolnix67+, you could try Tails.

Just a word of warning,
Just searching for Tails in a browser, has been known to attract attention of FBI/NSA and other nefarious nasties. [EDIT: They dont like it if they cant spy on you]

A couple of quotes from Wikipedia [which could attract unwanted attention just by visiting, I do not include the link]
Laura Poitras, Glenn Greenwald, and Barton Gellman have each said that Tails was an important tool they used in their work with National Security Agency whistleblower Edward Snowden.
Security incidents

In 2014 Das Erste reported that the NSA's XKeyscore surveillance system sets threat definitions for people who search for Tails using a search engine or visit the Tails website. A comment in XKeyscore's source code calls Tails "a comsec [communications security] mechanism advocated by extremists on extremist forums".

In the same year, Der Spiegel published slides from an internal National Security Agency presentation dating to June 2012, in which the NSA deemed Tails on its own as a "major threat" to its mission and in conjunction with other privacy tools as "catastrophic".

EDIT: But I gotta try it one day.

[Liisachan]

Just a word of warning,
Just searching for Tails in a browser, has been known to attract attention of FBI/NSA and other nefarious nasties. [EDIT: They dont like it if they cant spy on you]

Obviously, you'll only use a privacy aware search engine, e.g. MetaGer, DDG, Searx, and use it via Tor, preferably via .onion. That's the whole point of Tails.

The privacy risk is 100 times bigger if you just use Google, or Windows 10. That's why you don't like to use Windows 10 in the first place, right?

[StainlessS]

Obviously, you'll only use a privacy aware search engine
Yep, but maybe some without any of those might try to search for Tails just to see what it is.

EDIT:
I might give MetaGer a try, looks ok. [although I'm not gonna bother with the Tor stuff], and I presume that DDG is DuckDuckGo.

[StainlessS]

Further to above,
Tails is just a more privacy secure version of Linux, I dont see any reason that some other version of Linux cannot be used instead,
and still retain access to Windows 7 partitions via MkvToolNix.
I have a separate Linux [Cinnamon Mint] install on external hard drive (also have Linux on SSD alongside Windows 10), via a USB 3.0 hard drive dock [rather than flash drive].
I use it [external Linux OS] for any emergency operating system fix, or whatever purposes.
Best to disable all internal drives in firmware [EDIT: INCLUDING boot NVMe SSD if you have one] before install [to ensure that you write Grub bootloader to your removable drive],
will ensure you can boot without any other drives at all. [even if internal drive bootloader is wiped]

I only use an old slow 60GB 2.5 inch drive in my dock for linux boot drive, so is probably slower than it could be, but probably faster
than a lot of Flash Drives. The hard drive dock I use, has been seen to write up to about 180MB/s, but not on the
linux 2.5" boot drive, on some other 3TB drive in the dock.

The HDD dock I use was purchased about 2 months ago, and I am delighted with it. Supports up to 2 x 16TB drives at once
[my external boot linux OS can boot from either of the 2 dock drive bays, GPT EFI install partition, I think], although I have only tried with 2x3TB drives [max size drives I have].
Drives tested include 3 x 3TB Hitatchi and 2 x 3TB Seagate NAS drives, also works just fine with WD drives
[a lot of docks have problems with Western Digital drives, 2 of my docks will not read any WD drives I've tested]

I have 4 HDD docks, but this is defo my favourite [SATA only, 2 others also have 3.5" and 2.5" IDE],
[B]FIDECO Aluminum Hard Drive Docking Station, USB 3.0 Docking Station for 2.5 and 3.5 inch SATA HDD or SSD, Support Offline Clone and 2x 16TB Hard Drives
https://www.amazon.co.uk/gp/product/B075TZJMWW/ref=ppx_yo_dt_b_asin_image_o09_s00?ie=UTF8&psc=1
The RED USB port alongside the two Blue ports is for Charge Only [eg charge your phone, or some kind of external power], it cannot be used
for eg Flash drive.

Also, I use 2.5" hard drives for a number of other boot tools, eg System Rescue Disk, and Macrium Reflect [OS Imager], and also FoxClone,
and other tools.
I tried install of Andoid on external drive but not a great deal of success so far, too much OS crashing.