Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > New and alternative a/v containers

Reply
 
Thread Tools Search this Thread Display Modes
Old 8th November 2019, 17:40   #521  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
Ah right; the source file stores information such as the the encoder used or the channel layout in Vorbis comment packets (what other containers call "tags"). mkvmerge doesn't support converting Vorbis comments to Matroska tags and back at the moment. I might work on that some day. If you want me to, please open an issue over on GitLab; otherwise chances are I'll forget about it again.
__________________
Latest MKVToolNix is v83.0

If I ever ask you to upload something, please use my file server.
Mosu is offline   Reply With Quote
Old 8th November 2019, 17:47   #522  |  Link
redbtn
Registered User
 
redbtn's Avatar
 
Join Date: Jan 2019
Location: Russia
Posts: 105
Quote:
Originally Posted by Mosu View Post
Ah right; the source file stores information such as the the encoder used or the channel layout in Vorbis comment packets (what other containers call "tags"). mkvmerge doesn't support converting Vorbis comments to Matroska tags and back at the moment. I might work on that some day. If you want me to, please open an issue over on GitLab; otherwise chances are I'll forget about it again.
Thank you very much for the explanation. I'll open an issue on github. Will the file without this information be played correctly?
redbtn is offline   Reply With Quote
Old 8th November 2019, 17:55   #523  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
That I cannot answer.
__________________
Latest MKVToolNix is v83.0

If I ever ask you to upload something, please use my file server.
Mosu is offline   Reply With Quote
Old 9th November 2019, 10:36   #524  |  Link
john33
Registered User
 
Join Date: Apr 2002
Location: UK
Posts: 68
The channel mapping info is contained in the opus header and, by default, is the same as for vorbis files. It would be reasonable to expect any self-respecting decoder/player to map the output correctly but clearly there are no guarantees.
john33 is offline   Reply With Quote
Old 9th November 2019, 11:06   #525  |  Link
Abs62
Registered User
 
Join Date: Jul 2010
Posts: 14
When I set .mkv file as source, v39.0.0 GUI make destination filename from "Title" field instead of source filename as in previous versions. How to return old behaviour?
Abs62 is offline   Reply With Quote
Old 9th November 2019, 11:37   #526  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
Quote:
Originally Posted by Abs62 View Post
When I set .mkv file as source, v39.0.0 GUI make destination filename from "Title" field instead of source filename as in previous versions. How to return old behaviour?
See this issue.
__________________
Latest MKVToolNix is v83.0

If I ever ask you to upload something, please use my file server.
Mosu is offline   Reply With Quote
Old 9th November 2019, 11:38   #527  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
Quote:
Originally Posted by john33 View Post
The channel mapping info is contained in the opus header and, by default, is the same as for vorbis files. It would be reasonable to expect any self-respecting decoder/player to map the output correctly but clearly there are no guarantees.
Yeah. Even when I'll implement converting Vorbis comments to Matroska tags, I will likely not keep any tags regarding channel mapping for Opus files as the format itself specifies the channel mapping.
__________________
Latest MKVToolNix is v83.0

If I ever ask you to upload something, please use my file server.
Mosu is offline   Reply With Quote
Old 9th November 2019, 14:09   #528  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
MKVToolNix v40.0.0 released

Hey y'all,

there's been quite a lot of feedback on the changes in v39, and due to it I decided to make two of the new features configurable: the dark mode for Windows & deriving the file name from the file title. Combine that with an easy-to-trigger regression in the MP4 handling in v39, and I've decided to get a new release out sooner rather than later. So here it is, v40.0.0 is out.

Here are the usual links: the MKVToolNix home page, the Windows installer/portable version & macOS DMG & Linux AppImage and the source code.

The Windows and macOS binaries as well as the Linux AppImage are available already. The other Linux binaries are still being built and will be available over the course of the next couple of hours.

Here are the NEWS since the previous release:

Version 40.0.0 "Old Town Road + Pony" 2019-11-09
New features and enhancements
  • mkvmerge: MP4 reader: added support for BMP covert art images.
  • MKVToolNix GUI: multiplexer: added an option to disable deriving the destination file name from the file title. Implements #2648.
  • MKVToolNix GUI: multiplexer: the content of the "stereoscopy" combo box has been simplified making the box's minimum width much smaller, allowing the user to resize the GUI's whole window to a much smaller width.
  • MKVToolNix GUI: multiplexer: whenever the user changes the "aspect ratio" or "display dimensions" controls, the corresponding radio button will be activated automatically. Implements #2651.
  • MKVToolNix GUI: Windows: added a setting in the preferences to disable the GUI's dark color mode even if Windows's app color mode is set to dark. Implements #2646.
  • MKVToolNix GUI: Windows: replaced the dark mode introduced in v39 with another dark mode that's less wasteful with space between widgets.

Bug fixes
  • mkvmerge: MP4 reader: mkvmerge was reading eight bytes too many for cover art images. This could cause file identification to fail when the cover art was located at the end of the MP4 file. Even if it succeeded, this meant too much data present in the attachment. Fixes #2650.
  • mkvmerge: MP4 reader: covert art images with unknown image types will be skipped instead of treated as JPEG images.

Build system changes
  • Qt 5.9.0 or newer is now required for building MKVToolNix GUI.

Have fun
__________________
Latest MKVToolNix is v83.0

If I ever ask you to upload something, please use my file server.
Mosu is offline   Reply With Quote
Old 9th November 2019, 15:14   #529  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,565
Quote:
Originally Posted by redbtn View Post
Something weird happens. When I mux 7.1 channel opus file into MKV, it seems like some metadata is lost.
It doesn't have Channel layout anymore (mediainfo shows only L channel, I think WAVEFORMATEXTENSIBLE_CHANNEL_MASK=0X6 is lost) and information about encoder, maybe something else.
I get this even when encoding from 7.1 wav to 7.1 opus via OpusEnc directly (no MKVToolNix involved). Are we certain it is an MKVToolNix and not e.g. a MediaInfo issue?

Code:
General
Complete name                            : source.wav
Format                                   : Wave
File size                                : 3.66 MiB
Duration                                 : 5 s 0 ms
Overall bit rate mode                    : Constant
Overall bit rate                         : 6 144 kb/s
Writing application                      : Lavf58.33.100

Audio
Format                                   : PCM
Format settings                          : Little / Signed
Codec ID                                 : 00000001-0000-0010-8000-00AA00389B71
Duration                                 : 5 s 0 ms
Bit rate mode                            : Constant
Bit rate                                 : 6 144 kb/s
Channel(s)                               : 8 channels
Channel layout                           : L R C LFE Lb Rb Ls Rs
Sampling rate                            : 48.0 kHz
Bit depth                                : 16 bits
Stream size                              : 3.66 MiB (100%)
Code:
General
Complete name                            : encode.opus
Format                                   : Ogg
File size                                : 76.2 KiB
Duration                                 : 5 s 7 ms
Overall bit rate                         : 125 kb/s
Writing application                      : opusenc from opus-tools 0.2-3-gf5f571b

Audio
ID                                       : 10181 (0x27C5)
Format                                   : Opus
Duration                                 : 5 s 7 ms
Channel(s)                               : 8 channels
Channel layout                           : L
Sampling rate                            : 48.0 kHz
Compression mode                         : Lossy
Writing library                          : libopus 1.3-26-ge85ed772, libopusenc 0.2.1-2-g9cb17c6

https://www.sendspace.com/file/3x7564
sneaker_ger is offline   Reply With Quote
Old 9th November 2019, 16:12   #530  |  Link
redbtn
Registered User
 
redbtn's Avatar
 
Join Date: Jan 2019
Location: Russia
Posts: 105
It's not MediaInfo issue cuz I can see (in hex editor) WAVEFORMATEXTENSIBLE_CHANNEL_MASK=0X6 in source opus file and I can't see it in file after mux>demux. But since opus has only one Channel Layout for 7.1, I think it's not a big problem for decoder. But, I'll open an issue later, maybe it will be possible to save this information in MKV down the road.
Ps: I downloaded your wav file, and it was made by ffmpeg. FFmpeg doesn't save WAVEFORMATEXTENSIBLE_CHANNEL_MASK at all. You can check it, make flac (or another format) from source like TrueHD in eac3to and in ffmpeg and compare.

Last edited by redbtn; 9th November 2019 at 16:23.
redbtn is offline   Reply With Quote
Old 9th November 2019, 16:40   #531  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
There's no use for a channel configuration indication if the format's specification explicitly says what the channel configuration for a given number of channels must be. All it does is confuse users (and developers).
__________________
Latest MKVToolNix is v83.0

If I ever ask you to upload something, please use my file server.
Mosu is offline   Reply With Quote
Old 9th November 2019, 19:23   #532  |  Link
redbtn
Registered User
 
redbtn's Avatar
 
Join Date: Jan 2019
Location: Russia
Posts: 105
I was worried about the differences in the opus files before and after mux>demux. But I investigated it deeper and I found differences in headers of every frame, all other information the same. And if I convert these files to flac they are identical. So, all works perfectly. I take my hat off to Mosu

Last edited by redbtn; 9th November 2019 at 20:55.
redbtn is offline   Reply With Quote
Old 11th November 2019, 00:39   #533  |  Link
Liisachan
李姗倩 Lǐ Shān Qiàn
 
Liisachan's Avatar
 
Join Date: Nov 2002
Posts: 1,340
Thanks Mosu. I can verify the mp4 cover art 8-byte bug in 39 and fix in 40 (also BMP cover art support).

Something cosmetic - the GUI is no more fully DPI-aware on Windows (at least on Win7) starting from around version 25, when the default window size is initially calculated. The [Start multiplexing] button etc. are not visible when GUI opens the first time, if the DPI is higher than 96.
The image below shows the GUI versions 20 (left) and 40, on Windows 7, when 120 dpi is used.


Click to enlarge

EDIT
Verified: Jpeg/Png/BMP image in MP4 -> imported to MKV attachments bit-identically
Verified: Unrecognizable artwork in MP4 -> ignored ok
(FYI) MPC/LAV recognize Jpeg/PNG even if their flags are wrong/unrecognizable (not sure how this actually helps, but kind of impressive)
Question: Is libmpagic reliable? The registered media type of BMP seems to be image/bmp, but the GUI automatically uses image/x-ms-bmp. This lib used strange font mime types in the past too. MPC shows a BMP cover art in MP4 correctly as "image/bmp".

Last edited by Liisachan; 14th November 2019 at 03:21.
Liisachan is offline   Reply With Quote
Old 11th November 2019, 10:38   #534  |  Link
SeeMoreDigital
Life's clearer in 4K UHD
 
SeeMoreDigital's Avatar
 
Join Date: Jun 2003
Location: Notts, UK
Posts: 12,219
Quote:
Originally Posted by Liisachan View Post
Something cosmetic - the GUI is no more fully DPI-aware on Windows (at least on Win7) starting from around version 25, when the default window size is initially calculated. The [Start multiplexing] button etc. are not visible when GUI opens the first time, if the DPI is higher than 96.
The image below shows the GUI versions 20 (left) and 40, on Windows 7, when 120 dpi is used.
I can confirm much the same behaviour with Windows 10. I've been meaning to mention it
__________________
| I've been testing hardware media playback devices and software A/V encoders and decoders since 2001 | My Network Layout & A/V Gear |
SeeMoreDigital is offline   Reply With Quote
Old 14th November 2019, 16:10   #535  |  Link
Atak_Snajpera
RipBot264 author
 
Atak_Snajpera's Avatar
 
Join Date: May 2006
Location: Poland
Posts: 7,806
I've just noticed that mkvtoolnix-gui.exe can't be compressed by upx without --force switch. This is first time I had to use that option on executable. I wonder what is so unusual in that executable?
Atak_Snajpera is offline   Reply With Quote
Old 14th November 2019, 18:54   #536  |  Link
filler56789
SuperVirus
 
filler56789's Avatar
 
Join Date: Jun 2012
Location: Antarctic Japan
Posts: 1,351
Quote:
Originally Posted by Atak_Snajpera View Post
I've just noticed that mkvtoolnix-gui.exe can't be compressed by upx without --force switch. This is first time I had to use that option on executable.
I confirm that, it's been happening since various revisions ago... I never reported it though because I thought it was not an actual issue...

Quote:
I wonder what is so unusual in that executable?
Good question
filler56789 is offline   Reply With Quote
Old 14th November 2019, 23:01   #537  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
Quote:
Originally Posted by Liisachan View Post
Something cosmetic - the GUI is no more fully DPI-aware on Windows (at least on Win7) starting from around version 25, when the default window size is initially calculated.
Ugh, I hate high DPI shit. It's really, really hard getting good information how one is supposed to make all of it work correctly, including the user-defined UI scaling thingy in Windows, _and_ how to make it all work in a cross-platform way.

I will likely have to look into it again sometime in the future, but it's really one of my least favorite areas to work on. So don't expect any miracles.

On top of that note that I won't spend time on Windows 7 specific issues anymore as Windows 7 nears even the end of its extended support period (2020-01-14). No, this doesn't mean the GUI will magically stop working on W7 on that date. Yes, I did read that a Windows 10 user complained about the same thing one post after yours, and I will look into the high DPI issue, but I will only do so on W10, and if a fix works on W10 but not on W7, then it'll likely stay unfixed for W7.

Quote:
Originally Posted by Liisachan View Post
Question: Is libmpagic reliable? The registered media type of BMP seems to be image/bmp, but the GUI automatically uses image/x-ms-bmp.
I… honestly don't know. The "file" project (where libmagic comes from) is _the_ default content type recognition library on all Open Source systems; it's used in thousands of commercial/proprietary products, too. Maybe it's a backwards-compatibility thing?

Regarding MIME types for attachments from MP4 files: I don't use libmagic for them, actually, I simply use ones depending on the numeric object type present in the MP4 file. As "file --mime-type somefile.bmp" said "image/x-ms-bmp", that's what I hardcoded. I'll change it to "image/bmp".
__________________
Latest MKVToolNix is v83.0

If I ever ask you to upload something, please use my file server.

Last edited by Mosu; 14th November 2019 at 23:11.
Mosu is offline   Reply With Quote
Old 14th November 2019, 23:08   #538  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
Quote:
Originally Posted by Atak_Snajpera View Post
I've just noticed that mkvtoolnix-gui.exe can't be compressed by upx without --force switch. This is first time I had to use that option on executable. I wonder what is so unusual in that executable?
I really have no idea. I've never used upx, I definitely don't purposefully do anything to make upx's life harder.
__________________
Latest MKVToolNix is v83.0

If I ever ask you to upload something, please use my file server.
Mosu is offline   Reply With Quote
Old 15th November 2019, 01:36   #539  |  Link
manolito
Registered User
 
manolito's Avatar
 
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,078
Quote:
Originally Posted by Mosu View Post
On top of that note that I won't spend time on Windows 7 specific issues anymore as Windows 7 nears even the end of its extended support period (2020-01-14). No, this doesn't mean the GUI will magically stop working on W7 on that date. Yes, I did read that a Windows 10 user complained about the same thing one post after yours, and I will look into the high DPI issue, but I will only do so on W10, and if a fix works on W10 but not on W7, then it'll likely stay unfixed for W7.
I think that it is a shame that developers like you show so little regard to the privacy concerns of so many users and government authorities (German conference of "Datenschutzbeauftragte"). Here is a link from Heise which is only a few days old:
https://www.heise.de/newsticker/meld...0-4584678.html

For me Win10 is evil, I will never use it, and I am not the only one. It may make life a little easier for devs, but this is not enough to justify your decision to ignore Win7 compatibility in the near future.

Cheers
manolito
manolito is offline   Reply With Quote
Old 15th November 2019, 02:09   #540  |  Link
Liisachan
李姗倩 Lǐ Shān Qiàn
 
Liisachan's Avatar
 
Join Date: Nov 2002
Posts: 1,340
Quote:
Originally Posted by Mosu View Post
Ugh, I hate high DPI shit. It's really, really hard getting good information how one is supposed to make all of it work correctly, including the user-defined UI scaling thingy in Windows, _and_ how to make it all work in a cross-platform way.
I don't know how difficult it would be to make it cross-platform. If it were just for Windows, things would be rather trivial; e.g. when you create a logical font, you can multiply the font size by 96.0 / GetDeviceCaps( hDC, LOGPIXELSY ) and round the result to int, after that, functions like GetTextExtentPoint32 return the correct width and height of the text area in pixels, so you can place static text / GUI parts accordingly.

Quote:
Originally Posted by Mosu View Post
On top of that note that I won't spend time on Windows 7 specific issues anymore as Windows 7 nears even the end of its extended support period (2020-01-14). No, this doesn't mean the GUI will magically stop working on W7 on that date. Yes, I did read that a Windows 10 user complained about the same thing one post after yours, and I will look into the high DPI issue, but I will only do so on W10, and if a fix works on W10 but not on W7, then it'll likely stay unfixed for W7.
Fine with me
Many Windows programs don't work so well for me anyway. I have the taskbar thing at the top of my desktop, not at the bottom; a stupid program (including some tool created by Microsoft itself) always places its main window at y=0 of the desktop (below the task bar), so I can't even use its menu with mouse unless I move the window to a lower position using keyboard only. Compared with this, the problem of MKVToolNix GUI is very minor (I can just resize the main window a bit with mouse, and then that window size will be automatically used the next time).

That said, I think many people use larger and “dense” monitors these days, and higher-dpi settings are used more and more frequently. Although the problem is cosmetic and nothing urgent, I don't think it's W7-specific.

As for MIME types, since Matroska is a multimedia container where the MIME types are sometimes critically important, imho it would be safer if you manually hard-code some important MIME types (like you did for fonts). Even if libmagic is the de facto standard in the world, Matroska has its own internal (de facto) standard for historical reasons, widely supported in the multimedia world. This is mostly about font MIME types, and I know I'm paranoid; as a typesetter, the recent font mime-type related problem (fonts not loaded) was a bit traumatic, though the MIME type of BMP itself is not very important. Thanks again!

EDIT:
One can get the height of Windows GUI part this way:
Caption : GetSystemMetrics( SM_CYCAPTION )
Border : GetSystemMetrics( SM_CYSIZEFRAME )
Menu : GetSystemMetrics( SM_CYMENU ) or via GetMenuBarInfo (there may be a 1-pixel difference)
Statusbar : empirically (height of Caption) - 2, more reliably via GetWindowRect with hwndStatusbar

But like you said, the "theme" thing may confuse things even more...

Last edited by Liisachan; 15th November 2019 at 07:18.
Liisachan is offline   Reply With Quote
Reply

Tags
matroska

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 02:28.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.