MediaInfo(Lib) 0.7 - Reading information about media files

[LoRd_MuldeR]

Sorry, yet another try :o ;)
http://pastie.org/private/zj0ks6ji33qy4f3xcjyw7w

It seems that a simple "_setmode(_fileno(stdout), _O_U8TEXT)" is sufficient to make 'wcout' output proper UTF-8 to the console (or to a redirected file).

Also, as far as I have tested, this will even handle the SetConsoleOutputCP() stuff for us, making the code even shorter!

Only problem, so far, is that the normal 'cout' will not work anymore. In "release" builds it will trigger a crash, in "debug" builds it will trigger an assertion in some CRT code.

(Not really a problem, I think, because you have those macros for string/text output. However I saw some plain cout's in debug code inside MediaInfoLib)

[Zenitram]

Only problem, so far, is that the normal 'cout' will not work anymore.

This is weird to have "official" (see source code :) ) incompatibilities with cout, ah Microsoft... Anyway: I took from your ideas but I actually have made a more global review with input/output bugs from other OS (Linux, Mac) + DLL binding issues, and I updated all packages. Please update all packages from SVN (or there is a all inclusive archive there (https://sourceforge.net/projects/mediainfo/files/development_snapshots/0.7.50%2B/mediainfo_20110928_AllInclusive.7z))

[LoRd_MuldeR]

I see. You are of course right to use _MSC_VER instead of __WINDOWS__ for the compiler-specific stuff.

However shouldn't the TEXTOUT macro use Ztring().From_ISO_8859_1() instead of Ztring().From_Local() to convert the C-string?

As far as I see, TEXTOUT is mainly used to print some hardcoded strings that look like Latin-1. The user's "local" Codepage, however, might be everything...

(I know that the ASCII characters, code 0 to 127, are identical for most Codepages. But not for all of them: e.g. Windows-932 (http://msdn.microsoft.com/en-us/goglobal/cc305152) has no backslash!)

[Zenitram]

I see. You are of course right to use _MSC_VER instead of __WINDOWS__ for the compiler-specific stuff.

Yes :) (try with CodeGear compiler... It does not like it :) )

However shouldn't the TEXTOUT macro use Ztring().From_ISO_8859_1() instead of Ztring().From_Local() to convert the C-string?

This would be same, I use it only for pure US text string. Don't focus of such quick and dirty parts of the code.

[LoRd_MuldeR]

This would be same, I use it only for pure US text string. Don't focus of such quick and dirty parts of the code.

Well, if, for example, your "US text string" contains a backslash and the user has configured Windows-932 (Japanese Shift-JIS) as its default Codepage, then we would get a Yen symbol in the Unicode output instead of a backslash symbol after piping the text through a From_Local(), I think.

[LoRd_MuldeR]

Sorry, yet another suggestion :o ;)

//Initialize terminal (to fix Unicode output on Win32)
#if defined(_MSC_VER) && defined(UNICODE)
_setmode(_fileno(stdout), _O_U8TEXT);
_setmode(_fileno(stderr), _O_U8TEXT);
if(_ftelli64(stdout) == 0I64) fwprintf(stdout, L"\uFEFF");
if(_ftelli64(stderr) == 0I64) fwprintf(stderr, L"\uFEFF");
#endif

This will prepend a proper BOM (Byte Order Mark), iff the output is redirected to (an empty) file. Some text editors need this, to recognize the file as UTF-8.
Always writing the BOM is not a good idea, because we might be redirecting to a non-empty file and we don't want the BOM somewhere in the middle of the file.
Also we don't want to write a BOM to the console, as it produces an ugly ▯ character. But this won't happen, because _ftelli64() will return -1 in that case.

[Zenitram]

This will prepend a proper BOM (Byte Order Mark)

I prefer not to force it by default (Unicode specs says "Use of a BOM is neither required nor recommended for UTF-8"), I added it as an option.

[LoRd_MuldeR]

:thanks:

[Thunderbolt8]

is there any way to deal with faster recognition of broken files?

when hovering over certain files with cursor or just selecting those with the mouse (e.g. .mkv files gotten from canceling mkvmerge muxing process or eac3to processing), then detecting takes really long and this is really annoying when just accidentally selecting such files or even trying to delete them.

[Kurtnoise]

is there any way to deal with faster recognition of broken files?

yes, solution is between your desktop and chair...

[Zenitram]

is there any way to deal with faster recognition of broken files?

I deal with broken files as for any other files.
Provide some files so I can see the reason your files are long to parse.

[Thunderbolt8]

Im not entirely sure if that problem is really due to mediainfo. but on the other hand, I dont know which other progs/tools would parse files in explorer and cause such a system lock.

providing files, doesnt really work that well, because such broken files are quite large (blu-ray sources)

[Zenitram]

Im not entirely sure if that problem is really due to mediainfo.

Esay to verify: try with MediaInfo GUI (this is the same call to the DLL)

providing files, doesnt really work that well, because such broken files are quite large (blu-ray sources)

large file from Blu-ray or blu-ray themselfs are not an issue on my side. I can provide a private FTP server for upload if needed. If you don't provide samples, I can not work this issue...

[Thunderbolt8]

does mediainfo also parse blu-ray playlist files? if not, then it might be an issue of lavsplitter or haali

[Zenitram]

does mediainfo also parse blu-ray playlist files? if not, then it might be an issue of lavsplitter or haali

Yes it does. I also had some feedback on slow parsing of Blu-rays.
I'll check next week (I am not at home this week) my few blu-rays, if I have slow parsing with one, I'll try to fix it, else I'll do nothing until I have files with issues.

[Thunderbolt8]

one example is the south pacific blu-ray (ger, BBC documentary). playlist file 00001.mpls has file 00001.m2ts listed ~240 times after another (according to eac3to), a 1 min 1080p VC-1 file. so the overall playlist length is 4 hours.

this is obviously some garbage list and not really useful for the different episodes in reality. maybe it would be possible to deactivate parsing for such playlist files which have the same .m2ts files listed a certain number of times after another. (5-10 times just to be sure? maybe still too much in case such a file should be larger though) even in case of seamless branching stuff and alike with lots of different parts, usually the same part is not even repeated once directly after another.

parsing should still take rather long in case of real seamless branching movies. but at least we would have gotten rid of parsing rather useless lists. its not really funny not to be able to get out of this parsing loop in explorer other than by task manager.

[Zenitram]

maybe it would be possible to deactivate parsing for such playlist files which have the same .m2ts files listed a certain number of times after another. (5-10 times just to be sure?

Ouch... MI will definitely hang with such file, because I did not plan such situation, and I parse 200 times the same file (and .m2ts are long to parse du to the structure of the file) and this is totally useless.

I'll try to optimize it, and parse each file only once.

[smok3]

is there a debian64bit binary?

[Zenitram]

is there a debian64bit binary?

http://mediainfo.sourceforge.net/en/Download/Debian

Note: I checked the links in order to be sure they are OK, I just saw that the 64-bit binaries for CLI and GUI package were missing (.so are OK) and nobody warned me... :(. Updated.

[smok3]

:thanks:

[forclip]

Hi Zenitram. Could you take a look at this (http://ge.tt/84ni3L9) sample please? MediaInfo (0.7.50) says that AR is 2.35:1, but shouldn't it be 16:9 instead?

[Zenitram]

MediaInfo (0.7.50) says that AR is 2.35:1, but shouldn't it be 16:9 instead?

Ah... The problem with sequence display extension... The problem about sequence display extension is that decoders don't understand the specification the same way (I understand them, I don't understand the spec myslef), and/or put weird numbers in this extension. And decoders analyze this numbers the same way.

Your file:
horizontal_size_value=704
vertical_size_value=576
aspect_ratio_information=3 (DAR=16:9)
sequence display extension, display_horizontal_size=540
sequence display extension, display_vertical_size=576

What is the meaning of display_horizontal_size and display_vertical_size for this encoder? What is the expected display aspect ratio?

Currently, I implemented something that works for most of my sample files, but it does not work for your file. I add this file to the list of files with sequence display extension, I may review the formula at some moment, but not in short term.

[Chetwood]

Another feature request: When exporting to text (or whatever format) it would be nice to have Mediainfo default to the same folder and filename and file analyzed. So if I analyze d:\movies\my.rip.mkv by pressing ALT-E would result in this text file (or as the preset desired filename): d:\movies\my.rip.txt. Thx.

[forclip]

Currently, I implemented something that works for most of my sample files, but it does not work for your file.
Thanks for the explanation about SDE, this is really something new for me.

About this file. It was recorded with Panasonic SDR-H250EE-S (not by me :) ), recorded as 16:9, and for the original MOD file MediaInfo says that it is 16:9. But other apps treat it as 4:3. So I remuxed this file in Womble Mpeg Wizard DVD, changing the AR to 16:9 (but SDE remains unaffected). And this was my sample file to you.. Now I know that SDE can be changed or removed with ReStream.

[Zenitram]

Another feature request: When exporting to text (or whatever format) it would be nice to have Mediainfo default to the same folder and filename and file analyzed. So if I analyze d:\movies\my.rip.mkv by pressing ALT-E would result in this text file (or as the preset desired filename): d:\movies\my.rip.txt. Thx.

Good idea, but I'll not implement it immediately, so please add such request on the official tracker (http://sourceforge.net/tracker/?group_id=86862&atid=581184) else I may forget.

[Thunderbolt8]

mediainfo still seems to have problems with seamless branching playlists. either parsing takes way too long and then start again as soon as you click elsewhere in explorer or/and explorer tries to read and read and stops reacting after a while (example: despicable me BD (US), playlist 00800 or 00300)

[Zenitram]

mediainfo still seems to have problems with seamless branching playlists.

I still did not work on it, I have deadlines for paid work, this has a much higher priority. But I don't forget, I don't like to have hangs in MediaInfo.

[Zenitram]

mediainfo still seems to have problems with seamless branching playlists.

Please try this version:
http://sourceforge.net/projects/mediainfo/files/development_snapshots/0.7.50%2B/MediaInfo_GUI_20111109_Windows_i386_WithoutInstaller.7z/download

This is not tested on real files (because nobody provided some samples...), but I expect I corrected the issue.

[Toddler Naruto]

Suggestion: Please add a "Minimize to System Tray" feature, that can be activated by clicking on Minimize or Close buttons.

[Zenitram]

Please add a "Minimize to System Tray" feature, that can be activated by clicking on Minimize or Close buttons.

Does it take so much time to right click on a file and select "MediaInfo"?

[LoRd_MuldeR]

Hello.

May I ask how it did happen that the size of the "all inclusive" package went down from ~10.4 MB to 1.6 MB? :confused:

From what I can tell, at least ZLib has been removed, but still appears to be required...

[Zenitram]

May I ask how it did happen that the size of the "all inclusive" package went down from ~10.4 MB to 1.6 MB? :confused:

Because I crashed my HDD, not all backuped :(, and the script I retrieved was missing zlib and WxWidgets (GUI). Oups, oups... I'll update it soon (you can reuse 0.7.50 parts in the meanwhile)

[LoRd_MuldeR]

Thanks for the info!

HDD crash is something like the worst case for a developer. Looking at the current HDD prices, I hope you still have a replacement HDD in your locker ;)

[Zenitram]

HDD crash is something like the worst case for a developer

This depends, if you have a good backup policy of the source files, this is OK (now, I have one :), backup is made nearly in real time on 3 other HDDs in 2 other places in the world :) )

Looking at the current HDD prices, I hope you still have a replacement HDD in your locker

Oh... prices now is not so good (Thailand issues), and... Maybe prices are low, but files from customers are big, very big (below 1 GB is rare, 10 GB of HD content capture is common, 100 GB of complete satellite/cable/terestrial capture or 4K camcorders is less and less rare), so my HDD budget is not low :)

[Chetwood]

Pretty much all muxing tools allow for cutting. Just tell those guys to send you 10 sec clips instead.

[Zenitram]

Pretty much all muxing tools allow for cutting. Just tell those guys to send you 10 sec clips instead.

ah ah... Your usage of MediaInfo is not the same as their ;-)
Some customized versions of mediaInfo can be used as a complete stream validator or a demuxer or a TS filter, I need the whole files for automated regression tests (some files have only 1 unvalid bit somewhere in the file, I must find it and verify that all other bits are not wrongly detected as invalid), not counting that some formats have "header" info everywhere in the file (e.g. MP4 Smooth Streaming).

10sec of bebin/end was nice when I started MediaInfo, no more now!

[Chetwood]

Hadn't realized how much you'd already souped up your tool. Nice.

[LoRd_MuldeR]

It seems the LAME-tag has changed slightly in v3.99[.1] and now MediaInfo won't recognize it anymore:
http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=91372&view=findpost&p=775308

[Zenitram]

It seems the LAME-tag has changed slightly and now MediaInfo won't recognize it anymore

Argh... why do they change the system??? OK, I replied in the thread.

[LoRd_MuldeR]

:thanks:


Sorry, I have yet another issue:

With v0.7.49 MediaInfo reported the duration of my Wave file just fine, while with v0.7.51 it does not :(

Above the "old" version, below the "new" version:

http://img266.imageshack.us/img266/7231/mediainfowaveissue.th.jpg (http://img266.imageshack.us/img266/7231/mediainfowaveissue.jpg)

[Zenitram]

With v0.7.49 MediaInfo reported the duration of my Wave file just fine, while with v0.7.51 it does not :(

I change this part of the code for some other issues. All my sample files have duration, so I need a sample with this problem.

[LoRd_MuldeR]

It's a simple Wave+CUE file that I extracted with EAC directly from my original CD (using "Image" mode), so it should be easy to create such file yourself.

(Can't upload such big files with my ultra-slow internet connection)

[Zenitram]

It's a simple Wave+CUE file that I extracted with EAC directly from my original CD (using "Image" mode), so it should be easy to create such file yourself.connection)

I don't have a CD player, not so easy for me... I only need the first 10 KB of the file.

[LoRd_MuldeR]

Here we go :)

(Yes, the first 4 seconds are silent, but that's not very unusual with Audio CD's, I think)

[Zenitram]

With v0.7.49 MediaInfo reported the duration of my Wave file just fine, while with v0.7.51 it does not :(

I apologize for the mess, actually I was testing with my development version, not the official version, and I already corrected it, this is the reason I was not seeing problems on my files. So: it is OK, for next version.

[LoRd_MuldeR]

Thank you once again!

(BTW: Any idea yet when the next version is to be expected?)

[Zenitram]

(BTW: Any idea yet when the next version is to be expected?)

2 weeks, I think. No big changes in the code currently, I am mainly on another (related) project for few weeks.

[LoRd_MuldeR]

Hmm, I just compiled the latest MediaInfo from SVN Trunk, but it seems there is another issue hiding somewhere:

The 32-Bit build detects the Duration of my Wave file just fine, while the 64-Bit build does not. Maybe some "32- vs. 64-Bit" data type size issue? :eek:

http://img217.imageshack.us/img217/7136/mediainfowaveissuept2jp.th.png (http://img217.imageshack.us/img217/7136/mediainfowaveissuept2jp.png)

[chaddawkins]

I appreciate MediaInfo, thank you.
I build a codec pack for myself; I recently tried to update the MediaInfo_InfoTip.dll and MediaInfo.dll files but now MediaInfo_InfoTip.dll won't register. Did you change something to not allow this?
I have been using MediaInfo_InfoTip.dll file version 0.7.8.0 and modified date is December ‎09, ‎2008. I use Inno to compile and my registry entry looks like this:

[Files]
Source: {app}\InfoTip\MediaInfo.dll; DestDir: {app}\MediaInfo; Flags: uninsrestartdelete; Check: not IsWin64
Source: {app}\InfoTip\MediaInfo_InfoTip.dll; DestDir: {app}\MediaInfo; Flags: regserver uninsrestartdelete; Check: not IsWin64
Source: {app}\InfoTip\x64\MediaInfo.dll; DestDir: {app}\MediaInfo; Flags: uninsrestartdelete; Check: IsWin64
Source: {app}\InfoTip\x64\MediaInfo_InfoTip.dll; DestDir: {app}\MediaInfo; Flags: regserver uninsrestartdelete; Check: IsWin64

BTW, these are the only files that I use; along with the correct registry entries I get the shell extension.

[Zenitram]

I recently tried to update the MediaInfo_InfoTip.dll and MediaInfo.dll files but now MediaInfo_InfoTip.dll won't register. Did you change something to not allow this?

I remember I changed something in the Windows explorer interface, but I don't remember exactly which stuff. I don't use the DLL registration directly now (I update the registry directly, more possibilities). I see that regsvr32 registration fails, registration is not something I consider as nothing, but this is not my priority to correct it. I will review the whole code some day, but no ETA.

In the meanwhile, you can update only MediaInfo.dll (no need to update MediaInfo_InfoTip.dll), the binary interface of MadiaInfo.dll has not changed since 0.7.0.0 (in 2005).

[LoRd_MuldeR]

Any ideas about the 64-Bit issue yet?

[Zenitram]

Any ideas about the 64-Bit issue yet?

No. I can reproduce the issue, but I still don't find the reason (debug version works well...)

[LoRd_MuldeR]

No. I can reproduce the issue, but I still don't find the reason (debug version works well...)

Thank you for confirming the problem! So it's definitely not a build issue on my side, at least.

[Toddler Naruto]

Does it take so much time to right click on a file and select "MediaInfo"?

That's not the point. I want MediaInfo to minimize to system tray instead of Taskbar while is it running.

[Zenitram]

That's not the point. I want MediaInfo to minimize to system tray instead of Taskbar while is it running.

That's the point. MediaInfo never "runs", it takes few seconds to analyze a file you right click, you don't have the time to minimize it (this is not a compression program taking 10 hours to run). You never said the reason you need to minimize to tray something not running, instead of only right click on the file and select "MediaInfo".

Anyway, exactly same reply than Mosu (http://forum.doom9.org/showthread.php?p=1538131#post1538131) + if you really need it and if you are not able to code it, you can buy professionnal services from me.

[chaddawkins]

I remember I changed something in the Windows explorer interface, but I don't remember exactly which stuff. I don't use the DLL registration directly now (I update the registry directly, more possibilities). I see that regsvr32 registration fails, registration is not something I consider as nothing, but this is not my priority to correct it. I will review the whole code some day, but no ETA.

In the meanwhile, you can update only MediaInfo.dll (no need to update MediaInfo_InfoTip.dll), the binary interface of MadiaInfo.dll has not changed since 0.7.0.0 (in 2005).

that works just fine, thank you

[pascalwil]

Hi there

Sorry if I missed it but I don't seem to find the answer in the previous pages.
I get a reported delay for the AAC track of an MKV of 13 ms relative to video.
And Eac3to reports the same delay. Just to mention they are in line since I've read about this issue between MediaInfo & Eac3to.
Anyway my question is what to make of this delay?
I need to convert AAC to AC3 and add new AC3 to MKV for my standalone player.
Shall I set audio delay to 13 ms (like reported for AAC) in mkvmerge? Or no delay for AC3 will do it?
Thanks

[Zenitram]

Anyway my question is what to make of this delay?

You take care to have the same delay in your converted file (so: yes, you put this value into mkvmerge corresponding field), else audio will not be in sync.

[pascalwil]

Thanks a lot Zenitram

I've done it both ways with a 13 ms delay and without any delay for the AC3
I can't tell about the audio being out of sync in the case of no delay (I guess 13 ms is too small to be spotted).
But with your clarification I know how to do it the right way using info from MediaInfo.
BTW thanks for such a good tool.
Cheers

[Zenitram]

The 32-Bit build detects the Duration of my Wave file just fine, while the 64-Bit build does not. Maybe some "32- vs. 64-Bit" data type size issue?

I wanted to work on this issue (yeah, delay was long... :( ), but all my files are OK now with the current SVN. Could you confirm it? If there are still some issues on your side, I think I need a sample file.

[CruNcher]

Is there a Windows Explorer Shell extension yet (colum view,details ect) ?

[Zenitram]

Is there a Windows Explorer Shell extension yet ?

For several years. for explorer extension, preferences->explorer extension. For explorer tooltip, install the version corresponding to your CPU then preferences->explore tooltip.

[CruNcher]

I dont mean the tooltip i mean a direct column view integration into Explorer (with selectable data source from mediainfo like codec, container, bitrate,video format,audio format bitrate, framerate, maybe some more codec specific stuff like reference frames, b-frames, gop status, gop time. interlace status ect) without needing to always open the mediainfo gui when working with several files, i wonder that no one needs that it could save time :)
Something like Microsofts own supported files integration or like from 3rd parties such as Sonys MFX, or Nerodigitals, DivX Inc Extension just more versatile and non specific Mediainfo would be best suited for this and it would save so much time not needing to always select->right click->start mediainfo and tooltip also you need to hover over dozen of files all the time :(. You could also sort Files based on Bitrate in a folder ect and additionaly get the image thumb and preview playback if needed and all that without any extra application :)
Currently i scan the files and output the data into a simple html database but its also awkward (no instant result) so i thought maybe someone feels like me and did a extension or is working on one :(

[LoRd_MuldeR]

I wanted to work on this issue (yeah, delay was long... :( ), but all my files are OK now with the current SVN. Could you confirm it? If there are still some issues on your side, I think I need a sample file.

Will make a new 64-Bit build from SVN Trunk as soon as I have time.

[Zenitram]

I dont mean the tooltip i mean a direct column view integration into Explorer without needing to always open the mediainfo gui when working with several files, i wonder that no one needs that it could save time :)

So: no, not available, and people interested in it are not interested enough to pay the developement or to do the development themselves.

[LoRd_MuldeR]

Just tried with a fresh build from SVN Trunk, but still the same bug:
http://img46.imageshack.us/img46/6374/miwavebug.png

Left side is 32-Bit build, right side 64-Bit build. Even happens with a smaller 32 MB Wave file.

Going to send you a sample file via PM.

[Zenitram]

Just tried with a fresh build from SVN Trunk, but still the same bug:

My mistake (I was testing with some other #defines rather than the SVN version, and the error comes with specific #defines).
It should be OK now! (SVN 4514)

[LoRd_MuldeR]

Great :thanks:

[Kurtnoise]

@Zen: how to specify Image Resolution code-wise ? This is deprecated actually when I read the Image.csv file....

[Zenitram]

@Zen: how to specify Image Resolution code-wise ? This is deprecated actually when I read the Image.csv file....

MediaInfo::Get(Stream_Image, 0, "BitDepth")

[Kurtnoise]

I meant ppp or dpi not this one...:D

[Zenitram]

I meant ppp or dpi not this one...:D

Resolution field is deprecated, replaced by BitDepth field.
ppp/dpi was never supported by MI (image is not my main business). This is not something I reject, only lack of time and priority.

If you are motivated to send a patch ;-), you can add something like:
DotPitch: distance, between dots/pixels, in meters, e.g. 0.000085
DotPïtch/String: distance, between dots/pixels, in meters (and dots per inch), e.g. 85 µm (300 dpi)

Note: I take the name from http://en.wikipedia.org/wiki/Dot_pitch , and I try to use the International System of Units (http://en.wikipedia.org/wiki/International_System_of_Units) instead of American-only system, for new fields, at least for raw values (without "/String")

[Kurtnoise]

mmh, I don't like it...1st time that I heard this.

I'll try something and I'll get back to you.

[sheck]

Zenitram,

Mosu changed how mkvtoolsnix handles tracks IDs in MKV files. Tracks IDs now start from 0. I was wondering if you were going to adjust your code to reflect the change in the next version of mediainfo ?

Thank you.

[Kurtnoise]

track IDs from MKV != count number

[Zenitram]

Mosu changed how mkvtoolsnix handles tracks IDs in MKV files. Tracks IDs now start from 0. I was wondering if you were going to adjust your code to reflect the change in the next version of mediainfo ?

https://www.bunkus.org/bugzilla/show_bug.cgi?id=695

Summary for lazy people: Mosu decided, for a reason I can not undertand (he explained why he must have the same number everywhere, he did not explain why TrackNumber is discarded), to use something NOT in the file to identify a track, new ID is not an ID, but it is the track order (the order in the file) starting form 0.
TrackNumber is discarded now by mkvtoolnix.

So: Track ID from mkvtoolnix is not more associated with and Identifier, this is not an identifier, this is a track order, so "ID" field from MediaInfo can not be anymore used.

It seems to be useful for some people that MediaInfo is "compatible" with mkvtoolnix, so I may add a "hidden" (you have it with "-f" option) field indicating the track order, starting form 0, for MKVs.
This is a pain, but don't complain to me, complain to Mosu not wanting to assign anymore the track number to his "Track ID" as he did in the past.

[sheck]

Zenitram,

Thank you for the reply. I was only wondering if you will update the code so I can make a decision on how to approach fixing MKVcleaver.

It would be nice if mediainfo supported Mosu's track order, but I can work around it as well.

Thank you.

[Zenitram]

It would be nice if mediainfo supported Mosu's track order, but I can work around it as well.

I can add this field in MediaInfo.
The issue is only for Matroska files, right?

[sheck]

I can add this field in MediaInfo.
The issue is only for Matroska files, right?

That's correct, Matroska only.

[Zenitram]

It would be nice if mediainfo supported Mosu's track order, but I can work around it as well.

http://sourceforge.net/projects/mediainfo/files/development_snapshots/0.7.52%2B/MediaInfo_GUI_20120110_2_Windows_i386_WithoutInstaller.7z/download

It has a new field "StreamOrder" that is expeted to meet mkvtoolnix new method.
Description is "Stream order in the file, whatever is the kind of stream (base=0)"

[Zenitram]

That's correct, Matroska only.

No need for MP4?
See http://forum.doom9.org/showthread.php?p=1548125#post1548125

[sheck]

I'm not sure about MP4. I mostly work with MKV files. Will have to check.

[sheck]

Thank you, Zenitram,

The new new build works just fine. Can you please also compile 64 bit version.

I appreciate it.

[Zenitram]

Can you please also compile 64 bit version.

http://sourceforge.net/projects/mediainfo/files/development_snapshots/0.7.52%2B/MediaInfo_DLL_20120110_2_Windows_x64_WithoutInstaller.7z/download

[Mosu]

Summary for lazy people: Mosu decided, for a reason I can not undertand (he explained why he must have the same number everywhere, he did not explain why TrackNumber is discarded), to use something NOT in the file to identify a track, new ID is not an ID, but it is the track order (the order in the file) starting form 0.

This was done in order to fix a bug in mkvmerge. It also relates to MP4 files; there another issue was cropping up which prevented mkvmerge from simply using a header field present in the source file for track identification (the MP4 case was especially pathetic: there were two tracks of different types, one audio and one video, that used the same track number/ID header field).

TrackNumber is discarded now by mkvtoolnix.

For most formats mkvmerge has never used a header field as the track ID. Especially not for stuff like Ogg streams in which those IDs are usually random 64bit numbers.

Also my documentation has always spoken about track IDs and about retrieving those by querying mkvmerge itself.

So please, everyone, stop complaining. I don't change these things in order to annoy the biggest amount of people that I can. I change them in order to fix existing bugs. Thanks.

Edit: The next release of mkvmerge will also output the track's UID (that one is actually present in the file) in the verbose identification mode allowing correlation of the information that mkvmerge provides and information that other tools output (mkvinfo, MediaInfo etc) as long as those output the UID as well. The only problem are files in which the creating application decided to be dump and used the same UID for more than one track. Yes, such files do exist, I've seen them in the wild. Luckily they're extremely rare, and it's been quite a while since I came across the last one.

[Zenitram]

Mosu,

Thank you for commenting here.
Sorry if I was a bit aggressive, this was not intentional, only some disagreements (usually, I am the one impacted by dumb files, now I am on the other side :) ).
I was a bit "flooded" (as you) by people complaining this does not work anymore between MediaInfo and mkvmerge (only for Matroska files, I did not heard of MP4 issue, maybe not used by people using MediaInfo and mkvmerge).

Also my documentation has always spoken about track IDs and about retrieving those by querying mkvmerge itself.

I understand because I have the same issue, but we also need to deal with how the users use the tools... :(. Actually, I never heard of people who combines MediaInfo and mkvmerge before your change, this is new for me, I never thought that a change on your side would have so much impact on my mailbox (not so much, ok ok... A bit!)

(the MP4 case was especially pathetic: there were two tracks of different types, one audio and one video, that used the same track number/ID header field).

ah ah... I sympathise. I did not yet saw such MP4 file, but I had same kind of issue with another format (MXF)

The next release of mkvmerge will also output the track's UID (that one is actually present in the file) in the verbose identification mode allowing correlation of the information that mkvmerge provides and information that other tools output (mkvinfo, MediaInfo etc) as long as those output the UID as well.

Do you plan to output TrackNumber too? (MediaInfo provides both TrackNumber and TrackUID, but TrackNumber is the former identifier used by mkvtoolnix, so it may be usefull for third-party software developpers)


The only problem are files in which the creating application decided to be dump and used the same UID for more than one track. Yes, such files do exist, I've seen them in the wild. Luckily they're extremely rare, and it's been quite a while since I came across the last one.

Maybe people have difficulties to understand the word "Unique"... Dumb, very dumb...

[Mosu]

Actually, I never heard of people who combines MedaiInfo and mkvmerge before your change, this is new for me, I never thought that a change on your side would have so much impact on my mailbox (not so much, ok ok... A bit!)

Same here. I've always had requests from people that used mkvinfo's output, but those usually didn't know about mkvmerge's --identify-verbose switch. But the amount of people relying on MediaInfo for the information for mkvmerge was surprising.

Do you plan to output TrackNumber too?

It's not in yet but I will add it. That's an easy one line fix :)

[sheck]

Same here. I've always had requests from people that used mkvinfo's output, but those usually didn't know about mkvmerge's --identify-verbose switch. But the amount of people relying on MediaInfo for the information for mkvmerge was surprising.
It makes more sense for me to use mediainfo. It's way faster and less resource intensive. It outputs more information as well.

Reading console output can be problematic in some cases. I do use mkvmerge --identify, normally in cases where I could not get away by using mediainfo.

[LoRd_MuldeR]

Hi.

I came across a little problem, when using the "--inform" parameter with a template file.

My template file looks like:
General;Gen_Format=%Format%\nGen_Format_Profile=%Format_Profile%\nGen_Format_Version=%Format_Version%\nGen_Duration=%Duration%\nGen_Title=%Title%\n[...]
Audio;Aud_Format=%Format%\nAud_Format_Profile=%Format_Profile%\nAud_Format_Version=%Format_Version%\nAud_Channel(s)=%Channel(s)%\n[...]

The output I get looks very nice and easy to parse :)
mediainfo.i386.exe "--inform=file://template.txt" "F:\Napo leon Solo.ogg"
Gen_Format=OGG
Gen_Format_Profile=
Gen_Format_Version=
Gen_Duration=288067
Gen_Title=Napoleon Solo
Gen_Track=Napoleon Solo
Gen_Track/Position=4
Gen_Artist=At The Drive-In
Gen_Performer=At The Drive-In
Gen_Album=In Casino Out
Gen_Genre=General Emo
Gen_Released_Date=
Gen_Recorded_Date=1998
Gen_Comment=Encoded with LameXP
Gen_Cover=
Gen_Cover_Type=
Gen_Cover_Mime=
Gen_Cover_Data=
Aud_Format=Vorbis
Aud_Format_Profile=
Aud_Format_Version=
Aud_Channel(s)=2
Aud_SamplingRate=44100
Aud_BitRate=160000
Aud_BitRate_Mode=VBR

Unfortunately things go wrong, as soon as the character sequence "\n" (not the linebreak character itself, so it's actually "\\n" in C notation) appears in, e.g., the Title! :scared:

Then I get:
Gen_Title=Just A
Little Test
Gen_Track=Just A
Little Test

Instead of:
Gen_Title=Just A \n Little Test
Gen_Track=Just A \n Little Test

How do I resolve this problem, if possible at all? If not, what would you suggest?

:thanks:

[Zenitram]

Unfortunately things go wrong, as soon as the character sequence "\n" (not the linebreak character itself, so it's actually "\\n" in C notation) appears in, e.g., the Title! :scared:

Who puts "\" in a title?
Anyway, I tried to resolve the issue in the updated code (in the SVN), could you try it and let me know if it is OK without breaking something else?

[LoRd_MuldeR]

Who puts "\" in a title?

It happens! Like tracks, e.g. from live album, that contain a "medley" two songs:
"<Song Title #1>\<Song Title #2>"

And if <Song Title #2> happens to start with a "n" :rolleyes:

Still you could argue that this case rarely happens in reality, but on the other hand I got people who complained ;)

(Do you remember? We discussed that issue earlier when I still parsed the Non-Inform mode output. Sorry I come up with issue once again ^^)

Last but not least, think about %FieldName%'s that return a path...

Anyway, I tried to resolve the issue in the updated code (in the SVN), could you try it and let me know if it is OK without breaking something else?

Great! Will give it a test as soon as possible!

:thanks:

[LoRd_MuldeR]

Seems to work for me :)

D:\SVN\Tools\MediaInfo_SVN>MediaInfo.exe --inform=file://template.txt "F:\Track11.mp3"
Gen_Format=MPEG Audio
Gen_Format_Profile=
Gen_Format_Version=
Gen_Duration=196702
Gen_Title=Just A \n Little Test
Aud_Format=MPEG Audio
Aud_Format_Profile=Layer 3
Aud_Format_Version=Version 1
Aud_Channel(s)=2

Also, in a quick test, it didn't break the Non-Inform output.

Once again: :thanks:

[sheck]

Zenitram,

I could not get 64 bit version to work. It just returns empty string. I'm using the same syntax as 32 bit.

[Zenitram]

I could not get 64 bit version to work.

Oups, the DLL was not well updated (this is an older version)
New DLL: http://sourceforge.net/projects/mediainfo/files/development_snapshots/0.7.52%2B/MediaInfo_DLL_20120115_Windows_x64_WithoutInstaller.7z/download

[sheck]

Now it works. Thanks. :)

[SiliconKid]

Zenitram,

I've downloaded the updated DLL builds and I see that StreamOrder is in the list of available fields in the custom editor now.

However, it does not appear in any of the default layouts yet and it does not come back in the default Text result block if I programmaticaly call the Inform() method from my C# application.

I have a C# parser that parses the default long Text string that is returned by your Inform() method in MediaInfo.dll and I really need StreamOrder to come back in that result string.

All help greatly appreciated and MediaInfo is awesome.

Thanks

Allan

[Zenitram]

I have a C# parser that parses the default long Text string that is returned by your Inform() method in MediaInfo.dll and I really need StreamOrder to come back in that result string.

It is hidden by default.
in C#: MediaInfo::Option("Complete", "1");
before your Inform() call.
But if you use C#, it is quicker to call MediaInfo::Get(StreamKind, StreamPos, "StreamOrder"), you directly have the value, without any need to parse the a character string.

[RNiK]

Is there any way for MediaInfo to identify VP8 Codec version?
Right now, submitting WebM YouTube videos to MediaInfo, you'll get something like this:
General
Complete name : D:\...\Full HD test #3 - Unreal (HD).webm
Format : WebM
Format version : Version 2
File size : 94.6 MiB
Duration : 4mn 12s
Overall bit rate mode : Variable
Overall bit rate : 3 143 Kbps
Writing application : google
Writing library : google

Video
ID : 1
Format : VP8
Codec ID : V_VP8
Duration : 4mn 12s
Bit rate : 2 818 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate : 1 000.000 fps
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.003
Stream size : 84.8 MiB (90%)
Language : English / English

Audio
ID : 2
Format : Vorbis
Format settings, Floor : 1
Codec ID : A_VORBIS
Duration : 4mn 12s
Bit rate mode : Variable
Bit rate : 192 Kbps
Channel(s) : 2 channels
Sampling rate : 44.1 KHz
Compression mode : Lossy
Stream size : 5.78 MiB (6%)
Language : English
Last VP8 codec version is "Duclair" (1.0.0) (http://blog.webmproject.org/2012/01/vp8-codec-sdk-duclair-released.html); can I identify which version has been used to encode the above video?

[Zenitram]

Is there any way for MediaInfo to identify VP8 Codec version?

This piece of information is inside the VP8 stream (not at the coontainer level), and there is currently no VP8 parser in MediaInfo.
This is something doable (as I do for other stream formats e.g. MPEG Video, H264, VC-1...), but very few people are currently interested in VP8 (especially no one who pays me for developing), so very very low priority.

[Emulgator]

Hi, Zenitram !
A small suggestion to extend mediainfo's fps field to some more, maybe six or eight decimals:

I just came across a strange fps setting coming straight from a MJPEG in AVI canon camera file [Software Canon MVI02]
mediainfo showed 30,000 fps, and I thought: Well, let's make use of this stream as being 30fps.

Avisynth refused to concatenate this file with a blankclip(...fps=30...) saying that framerates wouldn't match.
Deeper investigations using abcavi showed [dwMicroSecPerFrame] 33333, Framerate 30,0003 fps

33333 µs presentation time breaks indeed down to a framerate of 300000/99999 or 30.000300003.... fps, so not compatible to anything.
(Assumefps (ntsc_video) and audio stretching in SoundForge to 100,10% helped here.)

If you need a sample, let me know, I will put up one on my FTP.

[Zenitram]

Avisynth refused to concatenate this file with a blankclip(...fps=30...) saying that framerates wouldn't match.
Deeper investigations using abcavi showed [dwMicroSecPerFrame] 33333, Framerate 30,0003 fps

My point of view is that the the frame rate is 30.000000000 fps. The issue is that 30.000000000 fps = 33333 microseconds when rounded and saved into the file. So there is no reasons to display more digits, I would put 30.000000000. My point of view is that your software has a bug not "translating" 1/0.033333 to 30.00000000, its rounding system is not good: to be exact, 1/0.033333 +/-0.0000005 (the precision of the value) --> 29.99985 < real fps <= 30.00075, and 30.000000000 would be "valid" (and is the expected value from the guy who wrote the file, I think)

[ipanema]

MediaInfo does not seem to support the vprp AVI header which allows AVI files to describe the display aspect ratio of its video stream.

vprp is in the official OpenDML specs but for some reason does not seem to be well supported by many programs, which is a pity (mplayer is one that does). Nevertheless it would be useful if MediaInfo could show the display aspect ratio from the vprp header if it was present.

[Zenitram]

MediaInfo does not seem to support the vprp AVI header which allows AVI files to describe the display aspect ratio of its video stream.

I parse (for trace) all fields from the vprp chunk but I currently do not use it, I don't remember the exact reason I did not yet implement it, oops. Anyway, please provide a file + the expected DAR and it should be implemented quickly (I prefer when I have validation from someone else, and you are there ;-) ).

[SeeMoreDigital]

Anyway, please provide a file + the expected DAR and it should be implemented quickly (I prefer when I have validation from someone else, and you are there ;-) ).I'm willing to test such files in my software and hardware media players ;)

[Emulgator]

My point of view is that the the frame rate is 30.000000000 fps. The issue is that 30.000000000 fps = 33333 microseconds when rounded and saved into the file. So there is no reasons to display more digits, I would put 30.000000000. My point of view is that your software has a bug not "translating" 1/0.033333 to 30.00000000, its rounding system is not good: to be exact, 1/0.033333 +/-0.0000005 (the precision of the value) --> 29.99985 < real fps <= 30.00075, and 30.000000000 would be "valid" (and is the expected value from the guy who wrote the file, I think)

This is about Avisynth. True, a valid point.
Since the given granularity is microseconds there should be no other choice on AviSynth's side
than interpreting the AVI-tagged 33333µs as 30.00000000000fps.

And BTW, for 30000/1001 fps the interpretation of the AVI-tagged presentation time of 33367µs (1s/29.9697305721221...)
as 29.97 fps works as expected in Avisynth .

[ipanema]

I parse (for trace) all fields from the vprp chunk but I currently do not use it, I don't remember the exact reason I did not yet implement it, oops. Anyway, please provide a file + the expected DAR and it should be implemented quickly (I prefer when I have validation from someone else, and you are there ;-) ).

You can take any AVI file and convert it to an AVI file containing a vprp header using the command-line "mencoder.exe" program which comes with mplayer:

http://sourceforge.net/projects/mplayer-win32/files/MPlayer%20and%20MEncoder/revision%2034401/

Just use this command to do the conversion:

mencoder inputfile.avi -ovc copy -oac copy -o outfile.avi -force-avi-aspect 1.77777

This sets the display aspect ratio in the output file's vprp header to 16:9 (1.777). Or use 1.333 for 4:3 display aspect ratio. According to the html manual page for mplayer/mencoder you can specify any value between 0.2−3.0

[SeeMoreDigital]

You can take any AVI file and convert it to an AVI file containing a vprp header using the command-line "mencoder.exe" program which comes with mplayer:I would rather have some short .AVI files please?

[Zenitram]

I would rather have some short .AVI files please?

I would also prefer a file, in order to 1/ share the work 2/ have a real-world file with real content instead of an artificial modified file.

Anyway, I added the change, vprp display aspect ratio is supported now.

[ipanema]

Anyway, I added the change, vprp display aspect ratio is supported now.

Thanks, I'll keep any eye out for the next release.

I would also prefer a file, in order to 1/ share the work 2/ have a real-world file with real content instead of an artificial modified file.

If I provided a file it would just be the same as above - created by mencoder.

It isn't an artificially modified file. Mencoder is a general encoder - the above command creates a new AVI file from scratch. It's just that the video and audio streams are copied from another avi file (not-reencoded).

For more details of mencoder, see the manual:

http://www.mplayerhq.hu/DOCS/HTML/en/intro.html

[SeeMoreDigital]

Hmmm...

If you want us to help you, why can't you just provide us with an small .AVI file?

[ipanema]

If you want us to help you, why can't you just provide us with an small .AVI file?

Because it seemed a bit pointless when anyone could download mencoder and have as many examples files as they wanted, and be able to experiment with as many aspect ratio values as they wanted.

You just need to download mencoder from the link I provided - it is just a zipped folder. Unzip it and simply run the mencoder command I gave.

But here's an example 16:9 file if you really need one:

http://www.mediafire.com/?hh8kcqa5blcer26

[SeeMoreDigital]

You must be having a laugh... Who generates video using Microsoft Video 1. Are you wasting our time?

And no. I don't want to download mencoder!

[ipanema]

You must be having a laugh... Who generates video using Microsoft Video 1.

The codec isn't relevant. It was just a small example file that I went to the trouble of generating for you just now. The point was to demontrate the vprp header not the codec.

[SeeMoreDigital]

The codec isn't relevant. It was just a small example file that I went to the trouble of generating for you just now. The point was to demontrate the vprp header not the codec.
But by using a video format that nobody uses or is supported any-more, you don't know if the software decoder filter even supports aspect ratio signalling, let alone MediaInfo! Also your sample can't be played in any hardware media player!

If you want us to help you. Give us something "current" to work with please?

[Zenitram]

If you want us to help you. Give us something "current" to work with please?

I don't think there is a need to be so aggressive. the spec is official, the patch was 4 lines of code (else I would not have implement it now), and maybe some other person can use it in real world somewhere (I still think this is not real world because this is not someone using it every day from the creation of the file to the final user, but this is not the point).

So... Stay calm :rolleyes:

[SeeMoreDigital]

(I still think this is not real world because this is not someone using it every day from the creation of the file to the final user, but this is not the point).I agree with you in some respects... Because the "real world" video formats should be MPEG-4 Part-2, MPEG-4 Part-10 and VC-1...

Given only a numpty would place the latter two within the .AVI container, all that's left is "good old" MPEG-4 Part-2 which is very well catered for "at the video stream level" by MPEG4 Modifier and works fine with MediaInfo.

[Midzuki]

...
Because the "real world" video formats should be MPEG-4 Part-2, MPEG-4 Part-10 and VC-1...

Given only a numpty would place the latter two within the .AVI container,

Of course "AVI sucks", no discussion about this :p , but regarding VC-1 especifically, SFAIK there is only one DirectShow decoder which actually "hates VC-1 in AVI": Mainconcept.

[ipanema]

Lagarith and other lossless codecs can also be quite useful in AVI, but too big just to demonstrate a small header.

vprp is very poorly supported, its true. Some software like Premiere can use rules to interpret DAR based just on pixel dimensions. My original post was more of an observation than a plea for help. I only mentioned it in case Zenitram was interested in looking into it. Anyway, this is my last post on the subject. ;)

[LoRd_MuldeR]

I noticed that MediaInfo recently started to recognize .m3u playlist files as "HLS" files.

The info that it displays seems to be taken from the (first?) audio file on the list. This is different from the previous behavior, when MediaInfo didn't output any info for such playlist files at all.

Unfortunately this breaks my detection of playlist files:

As playlist files are just "Text" files, they are not easy to detect. So my logic has been: Let MediaInfo detect the file type. If (and only if) MediaInfo doesn't detect anything, guess playlist type be file extension.

Now I have a problem, because the info that MediaInfo returns for a .m3u file looks like it was info from some audio file. Is there a way to tell MediaInfo to ignore "redirections" to another file?

[qyot27]

I'm dealing with another date/time-related issue, in that the values I get from MediaInfo are correct, but I'm getting time skew with the other program due to DST conversion quirks.

Therefore, would it be possible to have a File_Created_Date_Local_UTC and File_Modified_Date_Local_UTC that report the local time along with the UTC offsets? So for instance:
mediainfo --inform=General;%File_Created_Date_Local_UTC% filename
UTC-4:00 2011-08-27 04:28:32.421

I would only hope that in such a case, the files have correct offsets - that files written during EST are stored with UTC-5, and files written during EDT are UTC-4.

[Zenitram]

I noticed that MediaInfo recently started to recognize .m3u playlist files as "HLS" files.

Yes, I support more and more formats, "playlists" included (actually, the goal was for HTTP Live Streaming, I did not care about "pure audio" playlist, I must put another name for them)

Now I have a problem, because the info that MediaInfo returns for a .m3u file looks like it was info from some audio file. Is there a way to tell MediaInfo to ignore "redirections" to another file?

Hum... I did not plan to add such possiblility, redirections are classic for lot of professional "containers". I could quickly add a "--ReferencedFiles=0" (for example) for command line, is it enough for your usage?

[LoRd_MuldeR]

I think it would be sufficient to indicate that the current file is a playlist file and that the audio/video info actually is from another file.

At the moment I simply ignore the file, if the general/format is "HLS". This works for the M3U files that I tested. It seems PLS files are not detected yet.

Are there any other playlist formats, in addition to "HLS", that I need to take care of?

[Zenitram]

I would only hope that in such a case, the files have correct offsets - that files written during EST are stored with UTC-5, and files written during EDT are UTC-4.

I could add the Time zone offset to the local date/time field.
But in (nearly) ISO format:
2011-08-27 04:28:32.421-04:00

Warning: DST is a piece of shit with Microsoft Windows: when there is a DST change, Windows changes the local time (funny!). And I rely on the UTC to local time function from Windows, so result is sometimes... Weird (I try to be polite :) ): depending of your DST/Not DST config (depending of the day of the year), local time will not be same.

[Zenitram]

I think it would be sufficient to indicate that the current file is a playlist file and that the audio/video info actually is from another file.

Actually, the option would disable HLS parser (and some others), so the behavior would be as before (unknown format).

At the moment I simply ignore the file, if the general/format is "HLS".

So maybe this is not the right method (I should not spend time on implementing this option).
Simply test that there is no "Source" field in Video or Audio part. If "Source" field is present, the file you are analyzing is referencing other files.

[LoRd_MuldeR]

Simply test that there is no "Source" field in Video or Audio part. If "Source" field is present, the file you are analyzing is referencing other files.

Thx. Now I need to figure out how to do that with the "--inform" method :D

[qyot27]

I could add the Time zone offset to the local date/time field.
But in (nearly) ISO format:
2011-08-27 04:28:32.421-04:00
For readability purposes, it might look better with a space separating the time and the offset. Otherwise, looks great.

Warning: DST is a piece of shit with Microsoft Windows: when there is a DST change, Windows changes the local time (funny!). And I rely on the UTC to local time function from Windows, so result is sometimes... Weird (I try to be polite :) ): depending of your DST/Not DST config (depending of the day of the year), local time will not be same.
This was actually the motivation behind my suggesting it, more precisely when trying to deal with programs that don't handle DST correctly. If there's some way of showing the discrepancy, I can manually correct for it, and I figured that by seeing the UTC offsets, that it would be fairly trivial to identify the problem.

I've witnessed the time changes when looking at the date fields in Windows Explorer, but thankfully MediaInfo reports the same date/time that Windows Explorer does, which is really all that can be asked for. My problem is with other programs that get the times 1 hour wrong in the completely opposite direction, based on whichever the current time is.

[Chetwood]

Any timeframe on this (http://sourceforge.net/tracker/?func=detail&aid=3431645&group_id=86862&atid=581184)? Just asking cause it looks like a quick fix to me (being a non-coder). Thx.

[Zenitram]

Any timeframe on this (http://sourceforge.net/tracker/?func=detail&aid=3431645&group_id=86862&atid=581184)? Just asking cause it looks like a quick fix to me (being a non-coder). Thx.

Not difficult but:
1/ I'll change the GUI (I say that for several years :( )
2/ I have hundreds of small requests. small x 1000 = not small.
3/ Honestly, this is not something very fun to code, and I am not intersted in it.

--> No time frame, not soon.

[Lotesdelere]

MediaInfo doesn't recognize the MP3 files using free format bitstream encoding.

A sample @ 512 kbps can be found here:
http://streams.videolan.org/streams/mp3/Owner-FreeFormat512k.mp3

[forclip]

+ Matroska: stream order (hidden by default), in order to provide the same numbers as mkvtoolnix 5.2+ Track ID
Any chance or future plans to add such info for other formats too? Currently I want to have it for MP4\MOV. :thanks:

[qyot27]

Any chance or future plans to add such info for other formats too? Currently I want to have it for MP4\MOV. :thanks:
It's certainly not a consolation for MediaInfo use, but mp4info (part of the old MPEG4IP package, although it's also available through the newer MP4v2 (https://code.google.com/p/mp4v2/)) has provided this for as long as I've been using it. I generally use mp4info, mp4box -info, and mediainfo in tandem for these types of reasons.

[forclip]

qyot27
Thanks for the reply. I know about other tools such MP4Box, ffmpeg\avconv e.t.c., but I want it to be possible to get this info from MI too.

[Zenitram]

MediaInfo doesn't recognize the MP3 files using free format bitstream encoding.

VLC and Winamp, the tools I have tested, don't too ;-).
On my ToDo-list, but very low priority, I never saw such stream before so I imagine it is pretty rare and the detection algorithm must be reviewed (I can not base the detection on the size of a frame)

Any chance or future plans to add such info for other formats too? Currently I want to have it for MP4\MOV. :thanks:

Implemented:
https://sourceforge.net/projects/mediainfo/files/development_snapshots/0.7.58%2B/
(at least 20120608)

[SeeMoreDigital]

VLC and Winamp, the tools I have tested, don't too ;-).
On my ToDo-list, but very low priority, I never saw such stream before so I imagine it is pretty rare and the detection algorithm must be reviewed (I can not base the detection on the size of a frame)Same here... I also tried re-muxing the .MP3 stream into other containers. That did not work either!

Out of interest... What player is used to play these streams?

[forclip]

Implemented
Thank you!

-------

Hmm.. I'm too sleepy or MediaInfo.dll from "MediaInfo_GUI_20120608_Windows_i386_WithoutInstaller.7z" still without this feature?

[StainlessS]

UK Release "Shawshank Redemption" show 2.4:1 whereas DGIndex shows correct 16:9 aspect ratio.
NOTE, Frame size 720x576, Display Size given as 540x576 in DGIndex (pan/scan).
The actual AR is about 1.85 with black borders top/bottom.
If extracted from VOB, then MI shows 16:9.

PS, MI stands for MediaInfo not "Mission Impossible".


General
Complete name : E:\DVDIN\shawshank\VIDEO_TS\VTS_02_1.VOB
Format : MPEG-PS
File size : 1 024 MiB
Duration : 27mn 14s
Overall bit rate mode : Variable
Overall bit rate : 5 256 Kbps

Video
ID : 224 (0xE0)
Format : MPEG Video
Format version : Version 2
Format profile : Main@Main
Format settings, BVOP : Yes
Format settings, Matrix : Default
Format settings, GOP : M=2, N=5
Duration : 27mn 14s
Bit rate mode : Variable
Bit rate : 4 928 Kbps
Maximum bit rate : 7 500 Kbps
Width : 720 pixels
Height : 576 pixels
Display aspect ratio : 2.40:1
Frame rate : 25.000 fps
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.475
Stream size : 960 MiB (94%)
Color primaries : BT.470-2 System B, BT.470-2 System G
Transfer characteristics : BT.470-2 System B, BT.470-2 System G
Matrix coefficients : BT.470-2 System B, BT.470-2 System G

Audio
ID : 189 (0xBD)-128 (0x80)
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Format settings, Endianness : Big
Muxing mode : DVD-Video
Duration : 27mn 14s
Bit rate mode : Constant
Bit rate : 224 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 43.6 MiB (4%)

Text
ID : 189 (0xBD)-32 (0x20)
Format : RLE
Format/Info : Run-length encoding
Muxing mode : DVD-Video

[Zenitram]

UK Release "Shawshank Redemption" show 2.4:1 whereas DGIndex shows correct 16:9 aspect ratio.

I need a sample (I only need few MB).

[StainlessS]

Simple file cutting of ~ 1.4 MB, ~ 2 secs of VOB file.
Please acknowledge DL, want to delete file.

EDIT: Link DELETED.

[Zenitram]

Please acknowledge DL, want to delete file.

Done. (private message next time ;-) )

[Zenitram]

UK Release "Shawshank Redemption" show 2.4:1 whereas DGIndex shows correct 16:9 aspect ratio.

From your file:
sequence_display:
00000008 horizontal_size_value: 720 (0x02D0)
00000004 vertical_size_value: 576 (0x0240)
00000008 aspect_ratio_information: 3 (0x03) - 9:16
sequence_display_extension:
0000001C display_horizontal_size: 540 (0x021C)
0000001D display_vertical_size: 576 (0x0240)

--> DAR = 9/16 (note: in MPEG-2 Video specs, numbers are inverted)

Specs (ISO/IEC 13818-2:1995) say: "If sequence_display_extension() is present then the sample aspect ratio may be calculated as follows:
SAR = DAR * display_horizontal_size / display_vertical_size"

Definition of SAR:
"sample aspect ratio: (abbreviated to SAR). This specifies the relative distance between
samples. It is defined (for the purposes of this specification) as the vertical displacement of
the lines of luminance samples in a frame divided by the horizontal displacement of the
luminance samples."
(warning: inverted compared to common usage)

--> SAR = 9/16 * 540/576 = 0.52734375

--> Display Aspect ratio = vertical_size_value / horizontal_size_value * SAR = 0.421875

Display Aspect Ratio in common language is 1/x (from MPEG) = 1/0.421875 = 2.37.
I round it to well known Display Aspect Ratio (I am maybe too much aggressive on the rounding...)

Conclusion: I think your file is buggy, report the bug to the DVD manufacturer (goog luck ;-) ).
On my side, I think I follow specifications, or please demonstrate where I fail to conform to specs. I don't plan to change the behavior if I don't make an error compared to specs.
Note: this is not a problem for a DVD player because the corresponding IFO say 16:9 and a DVD player must conform to DVD specs only. But for the MPEG Stream, directly, it seems to be 2.4:1...

[SeeMoreDigital]

Conclusion: I think your file is buggy, report the bug to the DVD manufacturer (goog luck ;-) ).
On my side, I think I follow specifications, or please demonstrate where I fail to conform to specs. I don't plan to change the behavior if I don't make an error compared to specs.
Note: this is not a problem for a DVD player because the corresponding IFO say 16:9 and a DVD player must conform to DVD specs only. But for the MPEG Stream, directly, it seems to be 2.4:1...
Agreed... This issue has come up a few times before. Where the video streams "aspect ratio" meta-data does not match the IFO files "aspect ratio" information.

Thankfully, the "sequence display extension" can be corrected using ReStream ;)

[Lotesdelere]

VLC and Winamp, the tools I have tested, don't too ;-).
The new upcoming VLC 2.0.2 (http://nightlies.videolan.org/build/win32/vlc-2.0.2-/) does play free format since this commit:
http://git.videolan.org/?p=vlc/vlc-2.0.git;a=commit;h=df908f831a56d50676969f787d1910ef24cf5143

;)

[forclip]

When MI provides an output like this:

Width : 1 280 pixels / 1 280 pixels
Original width : 1 280 pixels
Height : 720 pixels / 720 pixels
Original height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant / Constant
Frame rate : 23.976 fps / 23.976 fps
Original frame rate : 23.976 fps

What does it mean (I'm talking about those double-values)?

[Zenitram]

When MI provides an output like this:

What does it mean (I'm talking about those double-values)?

Double values are expected when there is a legacy stream inside a stream (e.g. "HE-AAC / AAC")
For video, is could be a scalable video in theory, but it is not supported currently. I have such field to with MOV files containing 2 video "sub-streams" inside a stream.
please provide a sample file so I can test.

[forclip]

please provide a sample file so I can test.
I will PM you..

[StainlessS]

Thankyou Zenitram for your answer, perhaps DGIndex gets it wrong then.
(putting down a little bait there, lets see if we get a bite). :)

[Guest]

Thankyou Zenitram for your answer, perhaps DGIndex gets it wrong then.
(putting down a little bait there, lets see if we get a bite). :) Can't take the bait because you deleted the sample file.

[Zenitram]

When MI provides an output like this:

What does it mean (I'm talking about those double-values)?

Corrected (due to the information being twice in the file, weird file...)
https://sourceforge.net/projects/mediainfo/files/development_snapshots/0.7.58%2B/
(minimum 20120610)

[forclip]

Corrected
Thanks!

And could you please take a look at this (http://ge.tt/5EGIzuI/v/0?c) sample? It's a MP4 with negative audio delay set to -500ms using MP4Box, but

Delay relative to video : 40s 0ms

[Zenitram]

It's a MP4 with negative audio delay set to -500ms using MP4Box, but

Corrected in version 20120611.

[forclip]

Corrected in version 20120611.
:thanks:

[Kurtnoise]

I dont mean the tooltip i mean a direct column view integration into Explorer (with selectable data source from mediainfo like codec, container, bitrate,video format,audio format bitrate, framerate, maybe some more codec specific stuff like reference frames, b-frames, gop status, gop time. interlace status ect) without needing to always open the mediainfo gui when working with several files, i wonder that no one needs that it could save time :)
I'm working on it...should be available next week for testing.

[ikuban]

MediaInfo doesn’t show the exact bitrate of DTS Tracks. It seems that MediaInfo rounds to the nearest value like 755 kbps or 1510 kbps.
There are some DTS tracks out there that have real 768 kbps, but MediaInfo shows them as 755 kbps. I found this bug, when I was testing eac3to.
eac3to shows always the correct bitrate. Also it has a nice feature, which shows DTS header infomation (-logdts). Here are two header infos of a 754.5 kbps and a 768 kbps DTS track.


- frameSize 1024
- DTS-ES -
- channelNo 5
- lfe 1
- channelDescr 5.1
- samplingRate 48000
- bitDepth 24
- bitrate 768000
- samplesPerFrame 512
- copyHistory 1



- frameSize 1006
- DTS-ES -
- channelNo 5
- lfe 1
- channelDescr 5.1
- samplingRate 48000
- bitDepth 24
- bitrate 754500
- samplesPerFrame 512
- copyHistory 1


The difference is in the framesize (and of cource in the bitrate). I also did a simple crosscheck, I divided the filesize (in bit) by the duration (in sec) and the bitrate results were the same as the eac3to it shows.
I don’t know how MediaInfo calculates the DTS bitrate, but with an existing header data the calculation is very simple:

samplingRate / samplesPerFrame * frameSize * 8 / 1000 = bitrate
48000 / 512 * 1024(byte) * 8(bit) / 1000 = 768 kbps
48000 / 512 * 1006(byte) * 8(bit) / 1000 = 754.5 kbps

Also a rate of 1510 kbps is not actual, because most BluRay Movies with »full« DTS bitrate have exact 1509.0 kbps (framesize 2012 byte). Bitrates of 1509.75 kbps (framesize 2013 byte) are very rare.

[Zenitram]

MediaInfo doesn’t show the exact bitrate of DTS Tracks. It seems that MediaInfo rounds to the nearest value like 755 kbps or 1510 kbps.

I currently use the Tables 5.7 and 5.8 of ETSI TS 102 114 v1.2.1.
"RATE specifies the targeted transmission data rate for the current frame of audio"
"Due to the limitations of the transmission medium the actual bit rate may be slightly different from the targeted bit rate,
as listed in table 5.8 for the two types of applications. The bit-rates that are not shown in the table 5.8 are not applicable
on either of these two applications."

-> I use "Transmission Bit Rate" field instead of computing from "Primary Frame Byte Size" field as you do.

If it is wrong (if there may be several real bit rates for a specific "Transmission Bit Rate" code), I can change the algorithm and use "Number of PCM Sample Blocks", "Primary Frame Byte Size", "Core Audio Sampling Frequency" instead. Please provide sample files for DTS 768 kbps / 754.5 kbps / 1509.0 kbps / 1509.75 kbps.

[ikuban]

I use "Transmission Bit Rate" field instead of computing from "Primary Frame Byte Size" field as you do.
But your "Transmission Bit Rate" values are also wrong. They have to be 768 or 1536 kbps. Page 20 → ETSI TS 102 114 v1.3.1 (2011-08) (http://www.etsi.org/deliver/etsi_ts/102100_102199/102114/01.03.01_60/ts_102114v010301p.pdf)



If it is wrong (if there may be several real bit rates for a specific "Transmission Bit Rate" code), I can change the algorithm and use "Number of PCM Sample Blocks", "Primary Frame Byte Size", "Core Audio Sampling Frequency" instead.
Yes, there are several bitrates. And again Page 20: "The targeted transmission rate may be greater than or equal to the actual bit rate."



Please provide sample files for DTS 768 kbps / 754.5 kbps / 1509.0 kbps / 1509.75 kbps.
Here you are. Download (http://www38.zippyshare.com/v/97323045/file.html)
I have trimmed all tracks exact to 10s 5.333ms (938 frames). And here is an another bug: MediaInfo shows wrong durations, because of the not exact bitrate values.

754.5 – 10s 5ms
768 – 10s 184ms
1509 – 10s 0ms
1509.75 – 10s 5ms

[Zenitram]

But your "Transmission Bit Rate" values are also wrong. They have to be 768 or 1536 kbps. Page 20 → ETSI TS 102 114 v1.3.1 (2011-08) (http://www.etsi.org/deliver/etsi_ts/102100_102199/102114/01.03.01_60/ts_102114v010301p.pdf)

OK, the updated version of the spec is more explicit than the one I used, I was wrong about how to compute the bit rate, I'll change it soon. Thank you for the explaination ans samples.

[LoRd_MuldeR]

Hi, Zenitram. Is there any change Opus (http://www.opus-codec.org/downloads/) detection can be added to MediaInfo? Would be greatly appreciated! :)

[Atak_Snajpera]

is opus finalized yet?

[LoRd_MuldeR]

The IETF has accepted it as a standard recently. The final specification is to be released as an RFC anytime soon:
http://www.heise.de/newsticker/meldung/Universal-Audiocodec-Opus-auf-dem-Weg-zum-Internet-Standard-1632291.html

Also there are listening tests that claim Oups already is superior to HE-AAC, which makes it an interesting option, at least ;)

[Zenitram]

Hi, Zenitram. Is there any change Opus (http://www.opus-codec.org/downloads/) detection can be added to MediaInfo? Would be greatly appreciated! :)

Already added in SVN (http://mediainfo.svn.sourceforge.net/viewvc/mediainfo?view=revision&revision=4912) (in both OGG and Matroska), it will be in next official version.

[LoRd_MuldeR]

Already added in SVN (http://mediainfo.svn.sourceforge.net/viewvc/mediainfo?view=revision&revision=4912) (in both OGG and Matroska), it will be in next official version.

:thanks: a lot!

[sneaker_ger]

MediaInfo reports audio delays on mp4 files (muxed with L-Smash):
https://rapidshare.com/files/2377518186/delay_sample.mp4

"Delay relative to video : -3s 337ms"
Where does that come from? There shouldn't be any delay in that file.

[Zenitram]

MediaInfo reports audio delays on mp4 files (muxed with L-Smash):
https://rapidshare.com/files/2377518186/delay_sample.mp4

"Delay relative to video : -3s 337ms"
Where does that come from? There shouldn't be any delay in that file.

Video edit list:
00812FC9 Edit List (28 bytes)
00812FC9 Header (8 bytes)
00812FC9 Size: 28 (0x0000001C)
00812FCD Name: elst
00812FD1 Version: 0 (0x00)
00812FD2 Flags: 0 (0x000000)
00812FD5 Number of entries: 1 (0x00000001)
00812FD9 Entry (12 bytes)
00812FD9 Track duration: 27352 (0x00006AD8) - 45586 ms
00812FDD Media time: 2002 (0x000007D2) - 3337 ms
00812FE1 Media rate: 65536 (0x00010000) - 1.000

Audio edit list:
008166B1 Edit List (28 bytes)
008166B1 Header (8 bytes)
008166B1 Size: 28 (0x0000001C)
008166B5 Name: elst
008166B9 Version: 0 (0x00)
008166BA Flags: 0 (0x000000)
008166BD Number of entries: 1 (0x00000001)
008166C1 Entry (12 bytes)
008166C1 Track duration: 27404 (0x00006B0C) - 45673 ms
008166C5 Media time: 0 (0x00000000) - 0 ms
008166C9 Media rate: 65536 (0x00010000) - 1.000

--> there is an indication that video starts 3337 ms after audio. Else what is the meaning of this edit list?

[sneaker_ger]

Hmm. But how does 2002 translate to 3337ms? Shouldn't it be something like 1000*2002/24000 ~= 83.417ms?
Sorry if my questions sound stupid, just trying to understand.

[VFR maniac]

Hmm. But how does 2002 translate to 3337ms? Shouldn't it be something like 1000*2002/24000 ~= 83.417ms?
Sorry if my questions sound stupid, just trying to understand.

http://forum.doom9.org/showthread.php?p=1577792#post1577792
http://mediainfo.svn.sourceforge.net/viewvc/mediainfo/MediaInfoLib/trunk/Source/MediaInfo/Multiple/File_Mpeg4.cpp?r1=4836&r2=4882

It seems the bug (that misunderstands timescale of media_time) was fixed at rev4882.

MP4/MOV has two timescale.
One is for all tracks.
Another is for each media.

In this case, media timescale = 24000, movie timescale = 600.
So, 24000/600 * 83.417 = 3336.68ms = 3s 337ms.

Anyway this is still wrong at point of 'Delay relative to video' since media_time specifies the start time of composition.
Therefore, should take account of CTS of the sample composited at the first.
(Be careful. The first sample is not always the sample composited at the first.)

[Zenitram]

It seems the bug (that misunderstands timescale of media_time) was fixed at rev4882.

Actually, yes, I forgot this issue in my quick response. The specs say it is in media time scale units, so I was wrong (I was using the movie timescale unit) and it is corrected.
2002 is 83 milliseconds if I well understood now.

Anyway this is still wrong at point of 'Delay relative to video' since media_time specifies the start time of composition.
Therefore, should take account of CTS of the sample composited at the first.
(Be careful. The first sample is not always the sample composited at the first.)

So what would be exactly the meaning of this delta?
I see that track and media duration of :
- video: 45s 587ms (1093 frames)
- audio: 45s 673ms

so a delay of 83 milliseconds is maybe logical (the end of delay+video would be the end of audio)

I don't know what is the expected synchro when there is such "edit list" :(, any help is welcome.

[VFR maniac]

So what would be exactly the meaning of this delta?
I see that track and media duration of :
- video: 45s 587ms (1093 frames)
- audio: 45s 673ms

so a delay of 83 milliseconds is maybe logical (the end of delay+video would be the end of audio)

I don't know what is the expected synchro when there is such "edit list" :(, any help is welcome.

Each edit in edit list maps a portion of media timeline to presentation timeline.
Concatenation of all edits makes overall presentation of a track in the movie.
media_time of an edit specifies start time of arbitrary portion of media.
Let's say, CTS of the first composited sample is 2002 because of B-frames reordering, and the first edit has media_time = 2002, then presentation starts from CTS=2002 so the first composited sample is displayed without composition delay derived from B-frames.

Here, the difference of duration between video and audio is accidental and trivial.
Audio is encoded with AAC, so there shall be priming samples at the start and might be remainder samples at the end.
I guess the sum of priming and remainder samples makes 83 milliseconds.

[sneaker_ger]

83ms != 45s 673ms - 45s 587ms = 86ms anyways. But yes, I did not remove the AAC encoder delay (and of course not padding at the end) during the sample creation.

[sneaker_ger]

Each edit in edit list maps a portion of media timeline to presentation timeline.
Concatenation of all edits makes overall presentation of a track in the movie.
media_time of an edit specifies start time of arbitrary portion of media.
Let's say, CTS of the first composited sample is 2002 because of B-frames reordering, and the first edit has media_time = 2002, then presentation starts from CTS=2002 so the first composited sample is displayed without composition delay derived from B-frames.

So the delay is indeed zero?

[VFR maniac]

Yes, zero if the demuxer can handle edit list correctly.

[SeeMoreDigital]

Hi Zenitram,

Is there any chance you could add support for reading Opus audio files?

If you have not got one already, here's a sample: http://www.sendspace.com/file/ezi6q3


Cheers

EDIT: I've just spotted that LoRd_MuldeR has beaten me to the request :o

[SeeMoreDigital]

Cool...

Support for reading Opus audio files has been added to MediaInfo 0.7.59

Thanks Zen :D

[Zenitram]

Support for reading Opus audio files has been added to MediaInfo 0.7.59. Thanks Zen :D

I only accepted a patch from Kurtnoise (http://forum.doom9.org/member.php?u=19312).:D

[sneaker_ger]

Don't know if it's already supposed to be fixed or still on the to-do list, but the delay of the mp4 sample shows as 83ms now with 0.7.59. Shouldn't this show as 0ms according to VFR maniac's explanation?

Here is an additional sample, this time with a negative delay of 2585 samples to compensate for the aac encoder delay:
http://www.mediafire.com/?57cha6d4yzp7h10

[Zenitram]

Don't know if it's already supposed to be fixed or still on the to-do list, but the delay of the mp4 sample shows as 83ms now with 0.7.59. Shouldn't this show as 0ms according to VFR maniac's explanation?

I did not have the time to dig a lot in the issue. The tests I have made have a problem: some files I have, with B-frames, have an edit list starting at 0. So I must first understand how all is "compatible" because with the explanation from maniac, there should be a delay in the edit list.
Is there a precise place in specs saying that it is the mandatory behavior? I saw the same kind of explanation in CFF specs, so I don't doubt it is a good explanation, but I have difficulties to understand how I can have the right delay for all the files I have.

[burfadel]

The Mediainfo 0.7.59 32-bit mediainfo.dll doesn't work properly, at least with Staxrip. Version 0.7.58 and before works fine! The issue is that the framerate info isn't being delieved properly for the AssumeFPS() function, meaning instead of say, AssumeFPS(23.976) it comes up AssumeFPS() instead, which is invalid. This is an issue only with 0.7.59.

[Zenitram]

The issue is that the framerate info isn't being delieved properly

Which format? Any? I need a sample file.

[burfadel]

Here is a sample of a file that is affected:
http://www.mediafire.com/?t62da6y8fz8gyl7

Some files work fine, other's don't. Might be something to do with multiple audio and subtitle streams?

As I said, this works fine with previous Mediainfo versions.

[Zenitram]

Here is a sample of a file that is affected

Time stamps:
Frame 0 : 0
Frame 6 : 134
Frame 2 : 50
Frame 4 : 84
Frame 10: 217
Frame 8 : 167

Reordered:
Frame 0 : 0
Frame 2 : 50 (difference = 50)
Frame 4 : 84 (difference = 34)
Frame 6 : 134 (difference = 50)
Frame 8 : 167 (difference = 34)
Frame 10: 217 (difference = 50)

Average is right (42 ms) but in this case I detect VFR and I can not be sure it will be stable during the whole file.
so now I display:

Frame rate mode : Variable --> Meaning that the container has VFR
Original frame rate : 23.976 fps --> Frame rate indicated in the H264 stream

Is there any good reason to have such time stamps in the Matroska container? Is it wanted? Any kind of 3:2 Pulldown at the Container level? (in this case, I can try to detect it)
As I said, this works fine with previous Mediainfo versions.

Previous versions were buggy, because I was testing DefaultDuration field but the developper of mkvmerge said it was wrong. I can try to open a ticket for mkvmerge developper because in your case DefaultDuration is 42 ms and it is not logical compared to time stamps.

[Brazil2]

With MediaInfo 0.7.59 the METADATA_BLOCK_PICTURE information is not reported anymore for some OGG files, in both Tree and Text views, which is the way to know if there is at least one embedded cover inside the file.

[Kurtnoise]

A sample would be good...

@Burfadel : what did you say exactly ? Forum had a bug yesterday...

[burfadel]

I was saying the sample was remuxed using the latest MkvToolNix MMG etc, and that I split the file into 5MB chunks and randomly chose one from the middle for the sample. So the timestamp etc stuff was reset with the sample?

I wasn't sure why it was doing it with that file and not others, I thought it might have been to with the multiple audio and subtitle streams.

[Selur]

Bug in MediaInfo or ffmpeg?

ffmpeg:
Stream #0:0[0x1e0]: Video: mpeg2video (Main), yuv420p, 720x576 [SAR 64:45 DAR 16:9], 4610 kb/s, 25 fps, 25 tbr, 90k tbn, 50 tbc

Stream #0:1[0x80]: Audio: ac3, 48000 Hz, 5.1(side), s16, 384 kb/s

Stream #0:2[0x1c1]: Audio: mp2, 48000 Hz, stereo, s16, 128 kb/s

mediainfo:
Kind of stream : Video
Stream identifier : 0
ID : 224 (0xE0)

Kind of stream : Audio
Stream identifier : 0
Stream identifier : 1
ID : 193
ID : 193 (0xC1)

Kind of stream : Audio
Stream identifier : 1
Stream identifier : 2
ID : 189-128
ID : 189 (0xBD)-128 (0x80)

mplayer:
==> Found video stream: 0
ID_VIDEO_ID=0
==> Found audio stream: 128
ID_AUDIO_ID=128
==> Found audio stream: 1
ID_AUDIO_ID=1

ffmpeg reports for the video 0x1E0 -> 480, mediaInfo reports 0xE0,.....
-> anyone know which one is right ?

[Zenitram]

ffmpeg reports for the video 0x1E0 -> 480, mediaInfo reports 0xE0,.....
-> anyone know which one is right ?

MediaInfo is right.

MPEG-PS specs:
PES_packet() {
packet_start_code_prefix 24 bslbf
stream_id 8 uimsbf
(...)

The packet_start_code_prefix is the bit string '0000 0000 0000 0000 0000 0001' (0x000001).
stream_id specifies the type and number of the elementary stream
Stream_id assignments
Stream_id Note stream coding
1011 1100 1 program_stream_map
1011 1101 2 private_stream_1
1011 1110 padding_stream
1011 1111 3 private_stream_2
110x xxxx ISO/IEC 13818-3 or ISO/IEC 11172-3 or ISO/IEC 13818-7 or ISO/IEC 14496-3 audio stream number x xxxx
(...)

***

ffmpeg includes the start code. It is absolutely not necessary (start code is always same, start code is not part of stream identifier)

[Kurtnoise]

With MediaInfo 0.7.59 the METADATA_BLOCK_PICTURE information is not reported anymore for some OGG files, in both Tree and Text views, which is the way to know if there is at least one embedded cover inside the file.
The current MI OGG parser doesn't have this field yet...Only COVERART. However, reading official specs, this is now deprecated. We need to add it.

@Zen : after reading the code and specs (http://wiki.xiph.org/VorbisComment#METADATA_BLOCK_PICTURE), it looks like METADATA_BLOCK_PICTURE uses Big Endian format instead Little Indian like in the FLAC block. Can we reuse it ?

A sample can be found here (http://kurtnoise.free.fr/samples/)...

[Kurtnoise]

The Mediainfo 0.7.59 32-bit mediainfo.dll doesn't work properly, at least with Staxrip. Version 0.7.58 and before works fine! The issue is that the framerate info isn't being delieved properly for the AssumeFPS() function, meaning instead of say, AssumeFPS(23.976) it comes up AssumeFPS() instead, which is invalid. This is an issue only with 0.7.59.
After reading Zen post, Staxip must be updated on this part to use MI 0.7.59+...i.e reading "Original frame rate" instead of "Frame rate mode".

[burfadel]

After reading Zen post, Staxip must be updated on this part to use MI 0.7.59+...i.e reading "Original frame rate" instead of "Frame rate mode".

Ah ok! Staxrip is kind of stalled in development, so I'll just have to stick with Mediainfo 0.7.58

[Brazil2]

The current MI OGG parser doesn't have this field yet
It works with most files, and always did before, only few files are showing the issue.

[Atak_Snajpera]

@Zenitram
MediaInfoA_Get(Handle_, 2, 0, 'BitRate', 1, 0) does not return audio bitrate for .opus files
Obviously it works fine for older audio formats.

[Zenitram]

The issue is that the framerate info isn't being delieved properly for the AssumeFPS() function, meaning instead of say, AssumeFPS(23.976) it comes up AssumeFPS() instead, which is invalid. This is an issue only with 0.7.59.

Is it possible to have the original file (the one used to mux) too? mkvmerge and me don't know yet where is the issue.
mkvmerge ticket: https://trac.bunkus.org/ticket/781

PS: for other issues, I don't have the time to take care of them this month, please be patient.

[burfadel]

Is it possible to have the original file (the one used to mux) too? mkvmerge and me don't know yet where is the issue.
mkvmerge ticket: https://trac.bunkus.org/ticket/781

PS: for other issues, I don't have the time to take care of them this month, please be patient.

Uploading it to a site now, will PM you the link when done.

[Zenitram]

The issue is that the framerate info isn't being delieved properly for the AssumeFPS() function, meaning instead of say, AssumeFPS(23.976) it comes up AssumeFPS() instead, which is invalid. This is an issue only with 0.7.59.

I got your source file.
It has the same kind of issue with time stamps / duration, something is buggy with the orignal file.
It was made with HandBrake 0.9.4 (+libmkv 0.6.4), I don't plan to dig more about this issue, it seems it is more a problem with Handbrake or how Handbrake was used, and I don't know how Handbrake was used, so it is difficult for me to open a ticket on the Handbrake tracker (I need the original file for Handbrake + how Handbrake was used)

MediaInfo only displays that there is a problem with the file if the expected frame rate is 23.976 fps, and it is the expected behavior of MediaInfo.

[burfadel]

Ah ok :) Just thought it was strange that 0.7.58 seemed to handle it fine and 0.7.59 doesn't. At least it is something of 'little concern' :)

Thanks!

[Zenitram]

Just thought it was strange that 0.7.58 seemed to handle it fine and 0.7.59 doesn't.

My point of view is a bit different ;-):
- 0.7.58 was missing to catch the issue with that file and was reporting wrong information compared to the real content (even if you expect that this information is the right one)
- 0.7.59 catchs now the issue and display it.

MediaInfo is also used to catch wrongly muxed files, so it is one on its goals to find such issue.

[Kurtnoise]

It works with most files, and always did before, only few files are showing the issue.
could you upload a file which works please ?


MediaInfoA_Get(Handle_, 2, 0, 'BitRate', 1, 0) does not return audio bitrate for .opus files
Obviously it works fine for older audio formats.
Stream Duration calculation is not implemented yet for this format...

[stax76]

@burfadel

I've committed a fix to SVN but don't have a release schedule, sometime this year I guess.

[burfadel]

@burfadel

I've committed a fix to SVN but don't have a release schedule, sometime this year I guess.

Thanks, much appreciated!

[Keiyakusha]

I broke my head trying to figure this out... can someone please look into this?
So here is mkv file (http://www.mediafire.com/?lz17pnhotgh7hpv). I encoded it with constant fps 24000/1001 but mediainfo for some reason reports it to be variable framerate. The whole file is truly constant. Something that confuses mediainfo is in the beginning of the file.
Even after I remux this file with timecodes like below, or even by patching h264 stream to be lets say 30000/1001 fps instead and then muxing it with mkvmerge - mediainfo still reports it have variable fps... or maybe this is mkvmerge problem or something?
Some files have this "issue", some not, even though I encode them in the same way...

# timecode format v1
Assume 23.976024
0,36755,23.976024

[Zenitram]

I broke my head trying to figure this out...(...) mediainfo still reports it have variable fps...

I think it is a bug from MediaInfo. Nothing else. I'll correct it soon.

[Zenitram]

mediainfo still reports it have variable fps...

Corrected in developments snapshots:
http://sourceforge.net/projects/mediainfo/files/development_snapshots/0.7.59%2B/MediaInfo_GUI_20120821_Windows_i386_WithoutInstaller.7z/download

the headache you had is due to a value roundig issue (sometimes the delta is 41 ms, sometimes 42 ms) and MediaInfo was sometimes catching the CFR, sometimes not.

[Keiyakusha]

the headache you had is due to a value roundig issue (sometimes the delta is 41 ms, sometimes 42 ms) and MediaInfo was sometimes catching the CFR, sometimes not.
Yes, this works way better! Thank you for such a quick fix! :thanks:

[Keiyakusha]

Zenitram
Hi. About the issue I reported earlier. With 24000/1001 framerates it was fixed indeed, but it looks like 60000/1001 and 15000/1001(yes I have one thing that was released on dvd and bd and have this real fps) framerates are affected too. I can make some samples, but it looks like exactly the same issue.
Edit: I'm using mediainfo 0.7.60 release version

[ikuban]

Hi Zenitram,
what about the DTS bitrate issue? Did you forget to fix it?

[Brazil2]

Two APE files with APEv2 tags, MediaInfo is showing the tags of one of the files but not for the other one, while players are showing the tags of both files. Sample files: http://www.embedupload.com/?d=6RIYCHIWRF

[Zenitram]

About the issue I reported earlier. With 24000/1001 framerates it was fixed indeed, but it looks like 60000/1001 and 15000/1001

Please provide samples, it is easier for me to find the issue.

Hi Zenitram,
what about the DTS bitrate issue? Did you forget to fix it?

Oh... Yes. Still on my ToDo-list.

Two APE files with APEv2 tags, MediaInfo is showing the tags of one of the files but not for the other one, while players are showing the tags of both files.

I see tags in both files, but the parser fails on the second file, right. i'll dig the issue.

[Keiyakusha]

Please provide samples, it is easier for me to find the issue.

Here is 3 samples: http://www.mediafire.co/?pmewtf38g1gw822
1) I expect to see constant framerate, but it shows variable. Real framerate is (should be) 15000/1001
2) Same as first case, just framerate is 60000/1001
3) New problem, it shows constant framerate but reports that container and stream framerate differ (it shows 59.880 for container). HeaderEditor from mkvtoolnix reports that container framerate is the same as in sample 2 (16683333 nanoseconds which is 59.94...). If I remux stream with mkvmerge and will manually specify container framerate 60000/1001, then mediainfo shows exact 60 fps for container. I expect it to show constant framerate 60000/1001

Hope this helps...

[Keiyakusha]

Uhh... here is 4th sample. I expect to see 24000/1001 constant fps...
http://www.mediafire.com/?i2ybcdwbgbwxy9h

[manolito]

I do not know if this was brought up before, I noticed a problem with versions 07.59 and 07.60 for MPEG2 files.

My source is a DVD compliant MPEG2 file (one video track, one AC3 audio track, nothing else). Muxing was done with either mplex or Imago. In any case MediaInfo shows a second (non-existing) MPEG audio track with a bitrate of 0 kbps.

Going back to version 07.58 fixes this issue.


Cheers
manolito


//Edit
This problem does not occur if the MPEG2 file is very small.

[Zenitram]

In any case MediaInfo shows a second (non-existing) MPEG audio track with a bitrate of 0 kbps.


I need the file (PM if you don't want to have it public)

[manolito]

I need the file (PM if you don't want to have it public)
Hi Zenitram,
this seems to be a little difficult...:eek:

As I said before, the problem only occurs for bigger files. I did some more tests to determine the size threshold, but I stopped at a file size of 1.3 GB. This file still caused no problems, but MPEG2 files at DVD-5 size (above 4 GB) always throw off Mediainfo 7.59 or 7.60.

I certainly cannot upload a file of this size (it would take more than 12 hours), but it should be easy enough to make an MPEG2 file of this size yourself.


Some more info about the offending files:

Source: PAL TV capture via DVB-T to a .ts file
Demux with ProjectX
Edit with Cuttermaran
Reencode using HCenc and Aften (audio format AC3 CBR 2-channel 224 kbps)
Demux DVD using DGIndex
Mux to MPEG2 using either mplex or Imago (made no difference).



Cheers
manolito

[Zenitram]

But it should be easy enough to make an MPEG2 file of this size yourself.

I have several TS files of more than 10 GB and I don't have this problem. I'll do nothing if I can not reproduce easily the issue.

[Kurtnoise]

Some more info about the offending files:

Source: PAL TV capture via DVB-T to a .ts file
Demux with ProjectX
Edit with Cuttermaran
Reencode using HCenc and Aften (audio format AC3 CBR 2-channel 224 kbps)
Demux DVD using DGIndex
Mux to MPEG2 using either mplex or Imago (made no difference).

could you try to use muxman as DVD muxer for your last step ?

[LoRd_MuldeR]

I have several TS files of more than 10 GB and I don't have this problem. I'll do nothing if I can not reproduce easily the issue.

AFAIK, the video files an a Video-DVD (VOB files) are muxed as Program Streams (with a few DVD-specific extensions), not Transport Streams.

Maybe that makes the difference...

[Zenitram]

AFAIK, the video files an a Video-DVD (VOB files) are muxed as Program Streams (with a few DVD-specific extensions), not Transport Streams.

Maybe that makes the difference...

The soruce is TS, I agree the format is not precise for the analyzed file (PS or TS). Anyway, without file, no correction on my side.

[manolito]

@kurtnoise
could you try to use muxman as DVD muxer for your last step ?
Muxman does not create MPEG2 files, it can only make a DVD structure. But the DVD I extracted the streams from was authored with Muxman.

@Zenitram
Anyway, without file, no correction on my side.
OK, I'll bite. Here is the link to an offending MPEG2 file. Size is 2.7 GB, smaller files did not show this issue.
http://www.sendspace.com/filegroup/fvWCq8eLY1ZF%2BxNQq3xZH4gsoHke45lca9cSHTjlQOVo8B8dQltC5v6OyjniA%2Bqyf8bkDjd0TKhgYstvgjXgwg

As I said before, Mediainfo versions up to 7.58 have no problems with this file, versions 7.59 and 7.60 report a nonexistent second MPG audio stream.


Cheers
manolito

[Kurtnoise]

Muxman does not create MPEG2 files, it can only make a DVD structure. But the DVD I extracted the streams from was authored with Muxman.

Well, I don't understand what you've done...mplex or Imago aren't dvd muxer ?

[manolito]

Well, I don't understand what you've done...mplex or Imago aren't dvd muxer ?
I needed an MPEG2 file for some testing. To mux the elementary streams (.m2v and .ac3) I used either mplex or Imago. Muxman would have been useless in this case, because it is NOT a pure dvd muxer. It muxes and authors in one step, there is no way to get an MPEG2 file out of Muxman.


Cheers
manolito

[SeeMoreDigital]

Muxman would have been useless in this case, because it is NOT a pure dvd muxer. Now I'm confused...

Muxman generates 'pure' DVD compliant muxes from compliant elementary streams and places these streams within the .VOB container. You can't get more 'DVD compliant' than this.

It muxes and authors in one step, there is no way to get an MPEG2 file out of Muxman.There are quite a few tools to get the MPEG-2 stream out of the .VOB container (as an elementary .M2V stream). There are even tools to re-mux from the .VOB container to the .MPG container.

There are also tools to re-mux from the .VOB to the .TS container, .M2TS container, .MKV container, MP4 container, .MOV container and even the .AVI container!

[manolito]

Some more info about the offending files:

Source: PAL TV capture via DVB-T to a .ts file
Demux with ProjectX
Edit with Cuttermaran
Reencode using HCenc and Aften (audio format AC3 CBR 2-channel 224 kbps)
Author DVD using Muxman
Demux DVD using DGIndex
Mux to MPEG2 using either mplex or Imago (made no difference).
We are moving in circles...
Maybe I should have added the red line in my description.

The DVD was authored with Muxman. To get an MPEG2 file from this DVD I demuxed it and muxed it again. You are not really telling me that I should have used Muxman a second time, are you ?

Kurtnoise's point seems to be that the muxer might be to blame. This is not the case. I also tried to make the MPEG2 directly from the VOBs with VOB2MPEG (uses ffmpeg), but it made no difference regardless which muxer I had used. Again: This is not a muxer issue, it is a Mediainfo issue!



Cheers
manolito

[Zenitram]

it is a Mediainfo issue!
In order to stop the conversion about something useless: I confirm it is a MediaInfo issue.

[manolito]

Thanks for the confirmation...:thanks:


Cheers
manolito

[Sjakko]

I dont mean the tooltip i mean a direct column view integration into Explorer (with selectable data source from mediainfo like codec, container, bitrate,video format,audio format bitrate, framerate, maybe some more codec specific stuff like reference frames, b-frames, gop status, gop time. interlace status ect) without needing to always open the mediainfo gui when working with several files, i wonder that no one needs that it could save time :)

I'm working on it...should be available next week for testing.

May I kindly ask if there's progress yet?

[Kurtnoise]

still in progress...my free time is limited these days.

[Zenitram]

In any case MediaInfo shows a second (non-existing) MPEG audio track with a bitrate of 0 kbps.

Corrected:
http://sourceforge.net/projects/mediainfo/files/development_snapshots/0.7.60%2B (minimum 20121012)

[manolito]

Corrected:
http://sourceforge.net/projects/mediainfo/files/development_snapshots/0.7.60%2B (minimum 20121012)
Yes, I confirm that this development version corrects the problem...:)
Thanks a lot!

Cheers
manolito

[Zenitram]

Yes, there are several bitrates. And again Page 20: "The targeted transmission rate may be greater than or equal to the actual bit rate."

Corrected in version 20121018 (http://sourceforge.net/projects/mediainfo/files/development_snapshots/0.7.60%2B/MediaInfo_GUI_20121018_Windows_i386_WithoutInstaller.7z/download).

My computing is now based on the frame size instead of the "targeted transmission rate". Thank you for the explaination and samples, they were helpful.

[Atak_Snajpera]

Since 0.7.57 version I'm getting this error message on this sample -> http://www.mediafire.com/?338otlnlo6lxl66 (http://www.mediafire.com/?338otlnlo6lxl66)

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

Last working version is 0.7.56

[Zenitram]

Since 0.7.57 version I'm getting this error message on this sample

I think it is corrected in the v0.7.61 release (from today).

[Atak_Snajpera]

I think it is corrected in the v0.7.61 release (from today).

Nope. 0.7.61 gives me the same error.

[Zenitram]

Nope. 0.7.61 gives me the same error.

With official GUI too?
I found another division by 0, with 0 byte long files, but I don't find anything else.

[Atak_Snajpera]

It crashes on this

MediaInfoA_Open(Handle_,PChar(mediapath));

[Zenitram]

Nope. 0.7.61 gives me the same error.

It is weird, it works well with the GUI but it does not work with ripbot.
The other division I found (after 0.7.61) sees to patch your crash (I tested it with ripbot directly)
New version of the DLL 20121022 (http://sourceforge.net/projects/mediainfo/files/development_snapshots/0.7.61%2B/MediaInfo_DLL_20121022_Windows_i386_WithoutInstaller.7z/download)

[Atak_Snajpera]

It is weird, it works well with the GUI but it does not work with ripbot.
Yep it works even with my MediaInfo Lite GUI but I noticed that I used

MediaInfo_Open(_handle,PWideChar(_FileName));

instead of

MediaInfoA_Open(Handle_,PChar(mediapath));

[Atak_Snajpera]

The other division I found (after 0.7.61) sees to patch your crash (I tested it with ripbot directly)
New version of the DLL 20121022

Thanks! This works ok now. :)

[Kurtnoise]

Hi Jérôme,

MI doesn't recognize (yet ?) ac3 streams at 22050Hz (http://forum.doom9.org/showthread.php?p=1597964#post1597964)...yes, not covered by the specs. :D

[Zenitram]

ac3 streams at 22050Hz (http://forum.doom9.org/showthread.php?p=1597964#post1597964)...yes, not covered by the specs. :D

Wow... Awful hack! I hope I well understood the hack (if bsid is 9 instead of 8, then I divide the sampling rate by 2?), SVN is up to date with a patch for 22.05 kHz support.

[Kurtnoise]

Cool...thank you very much.

[tmservo]

I admit, I'm struggling to make this function the way I want too.. I haven't been able to get to mediainfotab to download it (period). I've recently switched CODEC packs, and Klite seemed to have 7.7.7 (very old or faked up by them or ?) Anyway, the one really useful thing it would tell me was what was the Average BR of the video on it's own, etc. and .7.61, newest download, doesn't seem to have that info. It also doesn't seem to give me the bitrate of the HD Audio tracks, which that version offered. Are they different lines or ? Just trying to figure it out :)

[Zenitram]

the one really useful thing it would tell me was what was the Average BR of the video on it's own

Which container format? If it is Matroska with 2 VBR streams (video + audio HD), it is normal, I can provide the average bit rate, but I can not do the difference between each stream for the bit rate (no index, no metadata).

[tmservo]

Which container format? If it is Matroska with 2 VBR streams (video + audio HD), it is normal, I can provide the average bit rate, but I can not do the difference between each stream for the bit rate (no index, no metadata).

I'm looking to get the average video bit rate and audio bitrate. Hmm. I'm not sure, it always seemed to be there in that strange. I can just split the MKV into a Video and MKA for audio and get it that way I suppose

[nikosvault]

Zenitram
Hi. About the issue I reported earlier. With 24000/1001 framerates it was fixed indeed, but it looks like 60000/1001 and 15000/1001(yes I have one thing that was released on dvd and bd and have this real fps) framerates are affected too. I can make some samples, but it looks like exactly the same issue.
Edit: I'm using mediainfo 0.7.60 release version

I wonder if that bug explains why 95% of my encoded mkv videos looks like this in mediainfo:

Frame rate : 60.000 fps
Original frame rate : 59.940 fps

or

Frame rate : 59.880 fps
Original frame rate : 59.940 fps

[Zenitram]

I wonder if that bug explains why 95% of my encoded mkv videos looks like this in mediainfo:

Frame rate : 60.000 fps
Original frame rate : 59.940 fps

or

Frame rate : 59.880 fps
Original frame rate : 59.940 fps

Maybe. Please provide some sample files (few MB are enough, you can cut the files)

[Keiyakusha]

Yeah I have this issue too on some more files but haven't had time to make samples yet... will be helpful if nikosvault can do it.
Also as before sometimes simple remuxing using mkvmerge can change report from.

Frame rate : 59.880 fps
Original frame rate : 59.940 fps
to
Frame rate : 60.000 fps
Original frame rate : 59.940 fps

still, neither is right.

[nikosvault]

http://www.sendspace.com/file/nx5x6c (Frame rate : 60.000 fps, Original frame rate : 59.940 fps)

It seems that the older mkv files in my collection are more prone to show 59.880 fps, but when I cut out a small sample, the files show the same info as the clip above.

[nikosvault]

Any news?

[Selur]

when I cut out a small sample, the files show the same info as the clip above.
judging from the time codes:
...
484
500
517
534
550
567
584
600
617
634
650
667
684
700
.... content is vfr, so if you cut out a portion it is kind of expected that mediainfo will report another frame rate,...

[Reino]

MediaInfo reports 2 channels for this TAK-file (http://www.degeelebosch.nl/reino/Across the River_sample.tak), while in fact it has 4 (quad).

I have no idea, but does TAK also store the channel-mask somewhere, just like WavPack?
Channel positions : Front: L R, Back: L R

[nikosvault]

judging from the time codes:
...
484
500
517
534
550
567
584
600
617
634
650
667
684
700
.... content is vfr, so if you cut out a portion it is kind of expected that mediainfo will report another frame rate,...

Strange that it should pop up like this in mediainfo then:

File size : 4.00 GiB
Duration : 1h 9mn
Overall bit rate : 8 191 Kbps
Encoded date : UTC 2007-11-22 07:14:24
Writing application : mkvmerge v2.1.0 ('Another Place To Fall') built on Aug 19 2007 13:40:07
Writing library : libebml v0.7.7 + libmatroska v0.8.1

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1h 9mn
Bit rate : 7 800 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 59.880 fps
Original frame rate : 59.940 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.141
Stream size : 3.73 GiB (93%)
Writing library : x264 core 56 svn-682C
Encoding settings : cabac=1 / ref=3 / deblock=1:0:1 / analyse=0x3:0x113 / me=umh / fpel_cmp=sad / subme=6 / me-prepass=0 / brdo=1 / mixed_ref=1 / me_range=12 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=0 / threads=3 / nr=0 / decimate=1 / mbaff=0 / bframes=3 / b_pyramid=0 / b_adapt=1 / b_bias=0 / direct=3 / wpredb=1 / bime=1 / keyint=250 / keyint_min=25 / scenecut=40(pre) / rc=2pass / bitrate=7800 / ratetol=1.0 / rceq='blurCplx^(1-qComp)' / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=25000 / vbv_bufsize=9000 / ip_ratio=1.40 / pb_ratio=1.30
Language : English
Default : Yes
Forced : No

Audio
ID : 2
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Format settings, Endianness : Big
Codec ID : A_AC3
Duration : 1h 9mn
Bit rate mode : Constant
Bit rate : 384 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 192 MiB (5%)
Default : Yes
Forced : No

[Kurtnoise]

MediaInfo reports 2 channels for this TAK-file (http://www.degeelebosch.nl/reino/Across the River_sample.tak), while in fact it has 4 (quad).

I have no idea, but does TAK also store the channel-mask somewhere, just like WavPack?
Channel positions : Front: L R, Back: L R
Looks like MI is only compatible with the old taK API, not fully with the new one (http://wiki.multimedia.cx/index.php?title=TAK)...

[Atak_Snajpera]

@zenitram
I think that latest mediainfo incorrectly detects display aspect ratio for some .VOBs

Video
ID : 224 (0xE0)
Format : MPEG Video
Format version : Version 2
Format profile : Main@Main
Format settings, BVOP : Yes
Format settings, Matrix : Custom
Format settings, GOP : M=3, N=12
Duration : 18s 388ms
Bit rate mode : Variable
Bit rate : 4 279 Kbps
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 2.40:1
Frame rate : 29.970 fps
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.413
Stream size : 9.38 MiB (94%)
Alignment : encoded by TMPGEnc (ver. 2.524.63.181)
Title : TMPGEnc
Writing application : 2.524.63.181
Writing library : TMPGEnc 2.524.63.181
Color primaries : BT.470 System M
Transfer characteristics : BT.470 System M
Matrix coefficients : BT.601

correct DAR is obviously 16:9 .

Samples
http://www.mediafire.com/?g9n7qy2sll3zcde

http://www.mediafire.com/?rmx18kbzlmb61k2

[Zenitram]

@zenitram
I think that latest mediainfo incorrectly detects display aspect ratio for some .VOBs

Sample 1: there is a DAR change inside the stream, and I was not correcly handling it.
Sample 2: Weird, first header has the correct DAR, but the other ones have Sequence extension, and we have thisthis issue about malformed Sequence extension (http://forum.doom9.org/showthread.php?p=1577699#post1577699).

PS: for other issues, sorry guys but I have lot of work so currently I stll can not spend time on them, but I don't forget them.

[Kurtnoise]

Hi Jérôme,

It looks like that the HD recordings from the FB Révolution use m2ts container...So, Format Name in General part uses BDAV currently. May I suggest to test also the format of audio streams in this case ? I mean, if Format = BDAV && Audio Format = AAC then MPEG-TS.

What do you think ?

[Zenitram]

It looks like that the HD recordings from the FB Révolution use m2ts container...So, Format Name in General part uses BDAV currently. May I suggest to test also the format of audio streams in this case ? I mean, if Format = BDAV && Audio Format = AAC then MPEG-TS.

BDAV is not related to stream formats.
The difference between BDAV and MPEG-TS is the size of the packet: 192 for BDAV and 188 for MPEG-TS. BDAV is 4 bytes of timestamp + 188 of MPEG-TS.

So BDAV is really BDAV, this file is not MPEG-TS and an MPEG-TS only player will never be able to play it (it is not MPEG-TS standard).

[Kurtnoise]

Yeah, I saw that in the code but BDAV stands for Blu-Ray Audio/Video, correct ?

So..., it's not annoying to you that we can have, in this case, AAC streams within BDAV strictly speaking ?

[Zenitram]

Yeah, I saw that in the code but BDAV stands for Blu-Ray Audio/Video, correct

It is the acronym, yes.
It is the first usage of BDAV, yes.
But it is not the only one.

So..., it's not annoying to you that we can have, in this case, AAC streams within BDAV strictly speaking ?

It's not annoying to you that we can have, in another case, subtitles streams with AVI (Audio Video Interleave, subtitles are not planned)? ;-)
It's not annoying to you that we can have, in another case, a video stream with JPEG (Join Picture Expert Group, video is not planned)? ;-)
It's not annoying to you that we can have, in another case, home material supporting DTS (Digital Theater System, you should never have it outside of Theaters)? ;-)

It is only an unique name for a specific technical thing (the container, and only the conainer), no more. It is not written "Blu-ray compliant". BDAV is also used by camcorders and lot of other encoders now.

When a commercial name (with its limitations) is used, it is in the field "commercial name" e.g. "AVC-Intra 50", "IMX 30", "XDCAM HD 35", "XDCAM EX 35"... If I implement a test on BLu-ray specs, there would be a new line with "commercial name" = "Blu-ray".

Here, BDAV means "it is 4+188 packetized MPEG-TS". If you have a better (and accepted by other people) name for such technical thing...

[Reino]

Looks like MI is only compatible with the old taK API, not fully with the new one (http://wiki.multimedia.cx/index.php?title=TAK)...Could you have a look, Zenitram? Could you also see if you can retrieve the Channel Positions for TAK?

And about Channel Positions...while for 6ch FLAC, WV and TAK files MediaInfo correctly reports [Channel positions : Front: L C R, Back: L R, LFE], for AC3, DTS, E-AC3, TrueHD, etc, it reports [Channel positions : Front: L C R, Side: L R, LFE]. Is this an error on your hand, or is this hardcoded in the audio format itself or something, because on the other hand I've also seen [Channel positions : Front: L C R, Rear: L R, LFE] for 6ch OPUS files. http://www.hydrogenaudio.org/forums/style_emoticons/default/blink.gif

Btw, MediaInfo fails to report any information on this DTS-file (http://www.mediafire.com/?ra1939kxbndv6cx), while the muxed version (http://www.mediafire.com/?crz9xv1l7gxp9v2) it has no problem with.

[Zenitram]

Could you have a look, Zenitram? Could you also see if you can retrieve the Channel Positions for TAK?

Sorry, I am really late with some requests :(.
Some time ago, I quickly checked the Tak parser, and yes, it is buggy (old TAK format only), I tried to quickly patch it but due to lack of good specs (Multimedia.cx (http://wiki.multimedia.cx/index.php?title=TAK) is good but the bit order is not simple :( ), it is long, so I postponed the pcorrection.

still on the todo-list, but low priority because TAK is not very spread.

MediaInfo fails to report any information on this DTS-file, while the muxed version it has no problem with.

Weird, the raw dts file has padding (with zeros) between each frame. I accept now padding between frames (in SVN and future version 0.7.63)

[Kurtnoise]

Hi Zen,

The parsing of this IFO file (https://mega.co.nz/#!19shjboZ!Rb7H3Tva6ClCh1bo7qDrIRV4LY9oXIv0HW1LIeJuSPU) seems to be broken for subtitles. MI finds the same IDs (0x20). Should be 0x20, 0x21, 0x22, 0x23 instead...I cannot find something wrong in the code though.

SF website is down...I cannot create a bug report for the moment.

[Selur]

MediaInfo doesn't output any infos about: http://www.sendspace.com/file/tyi3nq from (https://forum.doom9.org/showthread.php?t=167559)

ffprobe:
Duration: 00:00:10.04, start: 0.000000, bitrate: 7914 kb/s
Stream #0:0: Video: h264 (Baseline) (AVC1 / 0x31435641), yuv420p, 1216x688,14 fps, 28.08 tbr, 14.04 tbn, 28.08 tbc
Stream #0:1: Video: h264 (Baseline) (AVC1 / 0x31435641), yuv420p, 640x480, 14 fps, 41.92 tbr, 13.97 tbn, 27.95 tbc
Stream #0:2: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 22050 Hz, 2 channels, s16, 705 kb/s
Stream #0:3: Unknown: none
and mplayer:
AVI file format detected.
ID_VIDEO_ID=0
[aviheader] Video stream found, -vid 0
ID_VIDEO_ID=1
[aviheader] Video stream found, -vid 1
ID_AUDIO_ID=2
[aviheader] Audio stream found, -aid 2
VIDEO: [AVC1] 1216x688 0bpp 14.039 fps 6309.8 kbps (770.2 kbyte/s)
Load subtitles in c:\Users\Selur\Desktop\
ID_FILENAME=c:\Users\Selur\Desktop\dual_video.avi
ID_DEMUXER=avi
ID_VIDEO_FORMAT=AVC1
ID_VIDEO_BITRATE=6309784
ID_VIDEO_WIDTH=1216
ID_VIDEO_HEIGHT=688
ID_VIDEO_FPS=14.039
ID_VIDEO_ASPECT=0.0000
ID_AUDIO_FORMAT=1
ID_AUDIO_BITRATE=705600
ID_AUDIO_RATE=0
ID_AUDIO_NCH=0
ID_LENGTH=10.04
ID_SEEKABLE=1
ID_CHAPTERS=0
on the other side do,...

[Kurtnoise]

worksforme...

General
Complete name : Q:\samples\mdr_20130401_192547_I2.avi
Format : AVI
Format/Info : Audio Video Interleave
File size : 9.48 MiB

Video #1
Format : AVC
Format/Info : Advanced Video Codec
Codec ID : AVC1
Duration : 10s 43ms
Width : 1 216 pixels
Height : 688 pixels
Frame rate : 14.039 fps
Color space : YUV
Chroma subsampling : 4:2:0

Video #2
Format : AVC
Format/Info : Advanced Video Codec
Codec ID : AVC1
Duration : 10s 19ms
Width : 640 pixels
Height : 480 pixels
Frame rate : 13.974 fps
Color space : YUV
Chroma subsampling : 4:2:0

Audio
Format : PCM
Codec ID : 1
Duration : 19s 955ms
Bit rate : 705.6 Kbps
Channel(s) : 2 channels
Sampling rate : 22.05 KHz
Bit depth : 16 bits

Text
Duration : 10s 2ms

[Selur]

Strange I'm using http://mediaarea.net/download/binary/mediainfo/0.7.62/MediaInfo_CLI_0.7.62_Windows_x64.zip on Win7pro 64bit
Redownloaded MediaInfo and the file but:
MediaInfo.exe --full c:\Users\Selur\Desktop\mdr_20130401_192547_I2.avi
still doesn't give any output, other files work fine.

-> What mediainfo version are you using?

Cu Selur

Ps.: also tried:
http://mediaarea.net/download/binary/mediainfo/0.7.62/MediaInfo_CLI_0.7.62_Windows_i386.zip -> same problem
0.7.61 -> same problem

[Kurtnoise]

The same version as yours, except this is my own compilation. I used to use also an other GUI.

NB: I'm able to reproduce this behavior with the official CLI/GUI...

[Selur]

@Kurtnoise: thanks for testing, for a moment I thought I screwed up my system somehow :)
-> created an entry in the bug tracker (https://sourceforge.net/p/mediainfo/bugs/752/)

[poisondeathray]

what is the difference between the Kurtnoise "special" version ? What accounts for the difference ?

[Selur]

@kurtnoise: could you share you mediainfo compile?

[Kurtnoise]

Why ? I told you that the problem comes from the CLI and/or the GUI, not the library...

Grab the interface from here (http://www.paehl.de/cms/dpmedia) for example and replace MediaInfo.dll by the latest one, you will have something.




Edit : my own compilation has some differences but not related to the AVI container or AVC streams.

[Selur]

ah, okay, I misinterpreted your posts :)

[Kurtnoise]

Hi Jérome,

There is a regression in the DTS parser since your refactoring in rev5298...Grab this sample (http://forum.doom9.org/showthread.php?p=1624662#post1624662) and using the last library, we get nothing.

By looking at the code, it seems that the issue comes from the FrameSynchPoint_Test() function. The sample above begins as 1FFFE80007F1 whereas you're testing 0x1FFFE80007F0LL value...

[LoRd_MuldeR]

FWIW, I have made fresh static builds of MediaInfo v0.7.63 today:
http://code.google.com/p/mulder/downloads/detail?name=MediaInfo.2013-05-19.zip&can=2&q=

And, while I was at it, also gave an overhaul to my MediaInfo GUI:
http://code.google.com/p/mulder/downloads/detail?name=MediaInfo-GUI.2013-06-01.zip&can=2&q=

[Keiyakusha]

Again me with my fps problems...

OK, here is source .h264 stream (https://dl.dropboxusercontent.com/u/110558786/Samples/Mediainfo_fps_bug.h264). Mediainfo shows:
Frame rate: 59.940 - good
After muxing it with mmg 6.2.0 (https://dl.dropboxusercontent.com/u/110558786/Samples/Mediainfo_fps_bug.mkv) mediainfo shows:
Frame rate mode : Constant
Frame rate : 60.000 fps - wrong, where this came from?
Original frame rate : 59.940 fps
If I mux the stream with the following timecode (https://dl.dropboxusercontent.com/u/110558786/Samples/Mediainfo_fps_bug_timecodes.mkv):
# timecode format v1
assume 59.9400
600,2600,29.9700
Mediainfo shows:
Frame rate mode : Constant
Frame rate : 59.880 fps
Original frame rate : 59.940 fps
:confused: I expect anything but that...

[LoRd_MuldeR]

More a cosmetic problem, but trying to analyze a blank (0 byte) file, gives the following output:
E: File read error
E: File read error
E: File read error
E: File read error
E: File read error
E: File read error
... <-- many more of these messages here
E: File read error
E: File read error
E: File read error
E: File read error
E: File read error
E: File read error
General
Complete name : D:\Avidemux 2.5\New Text Document.txt
File size : 0.00 Byte

Maybe some simple sanity check can be added, so MediaInfo will discard an "empty" file right away?

[ChiDragon]

I'm encoding animation with the goal of burning it to SD Blu-ray, so I need the --fake-interlaced flag with my progressive content.

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 5 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 2mn 30s
Source duration : 2mn 30s
Bit rate mode : Variable
Bit rate : 1 327 Kbps
Maximum bit rate : 40.0 Mbps
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 4:3
Frame rate mode : Variable
Frame rate : 23.976 fps
Original frame rate : 29.970 fps
Minimum frame rate : 14.985 fps
Maximum frame rate : 29.970 fps
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.160
Stream size : 23.7 MiB (100%)
Source stream size : 23.7 MiB (100%)
Writing library : x264 core 130 r2273 b3065e6
Encoding settings : cabac=1 / ref=6 / deblock=0:-1:-1 / analyse=0x3:0x133 / me=tesa / subme=11 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-3 / threads=6 / lookahead_threads=1 / sliced_threads=0 / slices=4 / nr=0 / decimate=0 / interlaced=fake / bluray_compat=1 / constrained_intra=0 / bframes=3 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=1 / weightp=1 / keyint=24 / keyint_min=1 / scenecut=40 / intra_refresh=0 / rc_lookahead=24 / rc=crf / mbtree=1 / crf=23.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=40000 / vbv_bufsize=30000 / crf_max=0.0 / nal_hrd=vbr / ip_ratio=1.40 / aq=1:1.00
Encoded date : UTC 2013-06-01 07:12:34
Tagged date : UTC 2013-06-01 07:25:50
Color primaries : BT.601 NTSC
Transfer characteristics : BT.601
Matrix coefficients : BT.601

I assume this is a MediaInfo bug and not x264 actually generating VFR output from my AVS file.

[wanezhiling]

http://pan.baidu.com/share/link?shareid=470086&uk=3490642413


D:\新世纪福音战士EVA Beautiful World.mp3
General
Complete name : D:\新世纪福音战士EVA Beautiful World.mp3
Format : MPEG Audio
File size : 12.4 MiB
Duration : 5mn 18s
Overall bit rate mode : Constant
Overall bit rate : 320 Kbps
Album : Eva
Track name : ÐÂÊÀ¼Í¸£ÒôսʿEVA Beautiful World
Track name/Position : 187
Performer : Óî¶àÌï¹â
Cover : Yes
Cover MIME : image/png
Lyrics : [ti:Beautiful World] / [ar:Óî¶àÌï¹â] / [al:Beautiful World / Kiss & Cry] / [by:Ðdz½µÄ°§ÉË] / / [04:09.52][04:03.83][00:06.16][00:00.00] / [00:04.44]ÖÆ×÷ Ðdz½µÄ°§ÉË / [00:09.77]it\'s only love it\'s only love / [01:50.09][00:17.51]¤â¤·¤âÔ¸¤¤¤Ò¤È¤Ä¤À¤±Ò¶¤¦¤Ê¤éÈç¹ûÖ»ÓÐÒ»¸öÔ¸ÍûÄÜʵÏÖ / [03:46.49][00:26.06]¾ý¤Î¤½¤Ð¤ÇÃߤ餻¤Æ ÄÇô¾ÍÈÃÎÒÔÚÄãÉí±ßÌñ˯ / [00:31.17]¤É¤ó¤Ê³¡Ëù¤Ç¤â¤¤¤¤¤è ÄÄÀïÒ²²»ÔÙÏëÈ¥ / [03:21.32][02:06.10][00:34.36]Beautiful world / [00:37.48]ÃԤ鷺¾ý¤À¤±¤ò¼û¤Ä¤á¤Æ¤¤¤ëÄýÊÓ׿ᶨµÄÄã / [03:29.69][02:14.43][00:42.65]Beautiful boy / [02:17.80][00:46.68]×Ô·Ö¤ÎÃÀ¤·¤µ¤Þ¤ÀÖª¤é¤Ê¤¤¤Î»¹²»ÖªµÀ×Ô¼ºµÄÃÀÂð / [02:25.38][00:53.53]It\'s only love / [00:59.63]ÇޤƤ⤵¤á¤Æ¤â ÉÙÄê¥Þ¥ó¥¬ / [01:05.30]Ãμû¤Æ¤Ð¤Ã¤« ˯×ÅÐÑ×Å ¶¼Ö»ÃμûÉÙÄÐÂþ»* / [01:08.18]×Ô·Ö¤¬ºÃ¤*¤¸¤ã¤Ê¤¤¤Î ÄѵÀËû¾Í²»Ï²»¶ÎÒÂð / [01:16.18]ºÎ¤¬Óû¤·¤¤¤« ·Ö¤«¤é¤Ê¤¯¤ÆËûÏëҪʲô ÎÒ²»ÖªµÀ / [01:20.41]¤¿¤ÀÓû¤·¤¬¤Ã¤Æ / [01:24.91]¤Ì¤ë¤¤›æ¤¬î]¤ò¤Ä¤¿¤¦ Ö»ÏëÒªÁ³¼ÕÉÏÁ÷ÌÊ×ŵÄδæµÄÀá / [01:32.68]ÑÔ¤¤¤¿¤¤¤³¤È¤Ê¤ó¤Æ¤Ê¤¤ ʲô¶¼²»Ïë˵ / [01:37.21]¤¿¤À¤â¤¦Ò»¶È»á¤¤¤¿¤¤Ö»ÏëÔÙ¼ûÒ»´ÎÃæ / [01:41.16]ÑÔ¤¤¤¿¤¤¤³¤ÈÑÔ¤¨¤Ê¤¤Ïë˵µÄÊÂÇéÈ´²»ÄÜ˵ / [01:45.05]¸ùÐԤʤ·¤«¤â¤·¤ì¤Ê¤¤Ëµ²»¶¨ÊÇûÓÐÒãÁ¦ / [01:47.77]¤½¤ì¤Ç¤¤¤¤¤±¤ÉÕâÑùËäȻҲ²»´í / [01:57.71]¾ý¤Î¤½¤Ð¤ÇÃߤ餻¤ÆÄÇô¾ÍÈÃÎÒÔÚÄãÉí±ßÌñ˯ / [02:02.59]¤É¤ó¤Ê³¡Ëù¤Ç¤â¤¤¤¤¤èÄÄÀïÒ²²»ÔÙÏëÈ¥ / [02:09.40]ÃԤ鷺¾ý¤À¤±¤ò¼û¤Ä¤á¤Æ¤¤¤ë ÄýÊÓ׿ᶨµÄÄã / [02:31.26]¤É¤ó¤Ê¤³¤È¤Ç¤â ¤ä¤Ã¤Æ¤ß¤ÆʲôÊÂÇ鶼ÊÔ×Å×ö×ö¿´ / [02:37.19]Ëð¤ò¤·¤¿¤Ã¤Æ ËäÈ»ÕâÑùµÄ½á¹ûÊdzԿ÷ / [02:40.87]ÉÙ¤·½UòYÖµ¤¢¤²¤ëµ«È´ÄÜ´ÓÖм³È¡¾*Ñé / [02:47.89]ÐÂÎŤʤ󤫤¤¤é¤Ê¤¤¸ù±¾²»ÐèҪʲô±¨Ö½ / [02:50.08]¸ÎÐĤʤ³¤È¤¬ÔؤäƤ¤¤Ê¤¤Á¬ÄÇôÖØÒªµÄÊÂÇ鶼ûÓмÇÔØ / [02:56.28]×î½üµ÷×Ӥɤ¦¤À¤¤ ×î½üµÄÆø·ÕÊÇÔõôÁË / [02:58.66]ÔªšÝ¤Ë¤·¤Æ¤ë¤Ê¤é Èç¹û»¹³äÂú¸É¾¢µÄ»° / [03:02.71]±ð¤Ë¤¤¤¤¤±¤É ÄÇÒ²»¹ºÃ°É / [03:04.65]ÆͤÎÊÀ½çÏû¤¨¤ë¤Þ¤Ç»á¤¨¤ë¤Ê¤é¡¡Èç¹ûÎÒµÄÊÀ½çÏûʧÄÇÌìÄܹ»Óö¼ûÄã / [03:12.96]¾ý¤Î¤½¤Ð¤ÇÃߤ餻¤Æ¡¡ÔÚÄãµÄÉí±ßÌñ˯ / [03:18.52]¤É¤ó¤Ê³¡Ëù¤Ç¤â½á¹¹ ÎÞÂÛÔÚʲôÑùµÄµØ·½ / [03:24.40]ƒ�¤¯¹ý¤®¤Æ¤¤¤¯ÈÕ¡©¤ÎÖÐ¤Ç ÔÚ¹ý¶ÈÐé»ÃµÄÿһÌìÀï / [03:33.13]šÝ·Ö¤Î¥à¥é¤ÏÊË·½¤Ê¤¤¤Í¡¡ ÊÀÍâÌÒÔ´²»ÊÇ°ì·¨ / [03:37.98]¤â¤·¤âÔ¸¤¤¤Ò¤È¤Ä¤À¤±Ò¶¤¦¤Ê¤é Èç¹ûÖ»ÓÐÒ»¸öÔ¸ÍûÄÜʵÏÖ / [04:11.42]Beautiful world... / [04:27.21]2007ÄêÒÔÐÂÉ趨¡¢Ð»*Ïñ¡¢Ð¹ÊÊÂÈ«Ã渴»îµÄ¡¶ÐÂÊÀ¼Í¸£Òôսʿо糡°æ¡· / [04:35.77]ÈÕÇ°¹«¿ªÁËÆ䡶EVAо糡°æ£ºÐò¡·Ö÷ÌâÇúµÄÏûÏ¢¡£ / [04:41.93]Ö÷ÌâÇúÑ¡ÖÐÁËÓî¶àÌï¹âµÄÐÂÇú¡¶Beautiful World¡·£¬ÕâÕŵ¥Çúµú½«»áÔÚ8ÔÂ29ÈÕ·¢ÊÛ / [04:53.34]ENDÖÆ×÷£ºÐdz½µÄ°§ÉË / / / / / / / / / / / /
Audio
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 3
Duration : 5mn 18s
Bit rate mode : Constant
Bit rate : 320 Kbps
Channel(s) : 2 channels
Sampling rate : 44.1 KHz
Compression mode : Lossy
Stream size : 12.1 MiB (98%)


:eek::eek::eek:


a fix chs dll:http://pan.baidu.com/share/link?shareid=511844&uk=3558042035

D:\新世纪福音战士EVA Beautiful World.mp3
常规
文件全称 : D:\新世纪福音战士EVA Beautiful World.mp3
文件格式 : MPEG Audio
文件大小 : 12.4MB
时间长度 : 5分 18秒
混合码率模式 : 恒定(CBR)
平均混合码率 : 320Kbps
专辑 : Eva
音轨 : 新世纪福音战士EVA Beautiful World
音轨/曲目号 : 187
艺术家 : 宇多田光
封面插图 : Yes
封面插图格式 : image/png
Lyrics : [ti:Beautiful World] / [ar:宇多田光] / [al:Beautiful World / Kiss & Cry] / [by:星辰的哀伤] / / [04:09.52][04:03.83][00:06.16][00:00.00] / [00:04.44]制作 星辰的哀伤 / [00:09.77]it\'s only love it\'s only love / [01:50.09][00:17.51]もしも愿いひとつだけ叶うなら如果只有一个愿望能实现 / [03:46.49][00:26.06]君のそばで眠らせて 那么就让我在你身边恬睡 / [00:31.17]どんな场所でもいいよ 哪里也不再想去 / [03:21.32][02:06.10][00:34.36]Beautiful world / [00:37.48]迷わず君だけを见つめている凝视着坚定的你 / [03:29.69][02:14.43][00:42.65]Beautiful boy / [02:17.80][00:46.68]自分の美しさまだ知らないの还不知道自己的美吗 / [02:25.38][00:53.53]It\'s only love / [00:59.63]寝てもさめても 少年マンガ / [01:05.30]梦见てばっか 睡着醒着 都只梦见少男漫画 / [01:08.18]自分が好きじゃないの 难道他就不喜欢我吗 / [01:16.18]何が欲しいか 分からなくて他想要什么 我不知道 / [01:20.41]ただ欲しがって / [01:24.91]ぬるい涙が頬をつたう 只想要脸颊上流淌着的温存的泪 / [01:32.68]言いたいことなんてない 什么都不想说 / [01:37.21]ただもう一度会いたい只想再见一次面 / [01:41.16]言いたいこと言えない想说的事情却不能说 / [01:45.05]根性なしかもしれない说不定是没有毅力 / [01:47.77]それでいいけど这样虽然也不错 / [01:57.71]君のそばで眠らせて那么就让我在你身边恬睡 / [02:02.59]どんな场所でもいいよ哪里也不再想去 / [02:09.40]迷わず君だけを见つめている 凝视着坚定的你 / [02:31.26]どんなことでも やってみて什么事情都试着做做看 / [02:37.19]损をしたって 虽然这样的结果是吃亏 / [02:40.87]少し経験值あげる但却能从中汲取经验 / [02:47.89]新闻なんかいらない根本不需要什么报纸 / [02:50.08]肝心なことが载っていない连那么重要的事情都没有记载 / [02:56.28]最近调子どうだい 最近的气氛是怎么了 / [02:58.66]元気にしてるなら 如果还充满干劲的话 / [03:02.71]别にいいけど 那也还好吧 / [03:04.65]仆の世界消えるまで会えるなら　如果我的世界消失那天能够遇见你 / [03:12.96]君のそばで眠らせて　在你的身边恬睡 / [03:18.52]どんな场所でも结构 无论在什么样的地方 / [03:24.40]儚く过ぎていく日々の中で 在过度虚幻的每一天里 / [03:33.13]気分のムラは仕方ないね　 世外桃源不是办法 / [03:37.98]もしも愿いひとつだけ叶うなら 如果只有一个愿望能实现 / [04:11.42]Beautiful world... / [04:27.21]2007年以新设定、新画像、新故事全面复活的《新世纪福音战士新剧场版》 / [04:35.77]日前公开了其《EVA新剧场版：序》主题曲的消息。 / [04:41.93]主题曲选中了宇多田光的新曲《Beautiful World》，这张单曲碟将会在8月29日发售 / [04:53.34]END制作：星辰的哀伤 / / / / / / / / / / / /
音频
文件格式 : MPEG Audio
格式版本 : Version 1
格式算法 : Layer 3
时间长度 : 5分 18秒
码率编码模式 : 恒定(CBR)
码率 : 320Kbps
声道数 : 2声道
采样率 : 44.1KHz
压缩模式 : 有损压缩
流大小 : 12.1MB (98%)

[Kurtnoise]

@wanezhiling : what is your problem ?

[wanezhiling]

@wanezhiling : what is your problem ?
MediaInfo cannot correctly recognize the mp3 (http://pan.baidu.com/share/link?shareid=470086&uk=3490642413) lyric info
http://farm4.staticflickr.com/3677/8944405419_a8624e5002_o.png

With a chs dll (http://pan.baidu.com/share/link?shareid=511844&uk=3558042035), its ok
http://farm4.staticflickr.com/3773/8945027958_fe2093108f_o.png

[Kurtnoise]

I'm not sure that's MediaInfo issue...probably mpc-hc related. I mean, how mediainfo library has been compiled.

[Keiyakusha]

Found some other weird issue with mkv.
I have mkv with 2 editions. In mkvmerge I set Title/segment name to "1st-2nd day".
If I'll add following tags to my file:
<?xml version="1.0" encoding="UTF-8"?>
<!-- <!DOCTYPE Tags SYSTEM "matroskatags.dtd"> -->
<Tags>
<Tag>
<Targets>
<EditionUID>3527066182666510771</EditionUID>
</Targets>
<Simple>
<Name>TITLE</Name>
<String>1st day</String>
</Simple>
</Tag>
<Tag>
<Targets>
<EditionUID>4757669719501998224</EditionUID>
</Targets>
<Simple>
<Name>TITLE</Name>
<String>2nd day</String>
</Simple>
</Tag>
</Tags>

Then mediainfo will show this:

Writing library : libebml v1.3.0 + libmatroska v1.4.0
TITLE : 2nd day

Why it takes name of the second edition which is not even marked as default :confused:

Edit: string marked blue I can change to whatever I want (however then it won't change the title of the actual edition) Then mediainfo will show something like this:

Writing library : libebml v1.3.0 + libmatroska v1.4.0
名前 : 2nd day
Still using 2nd tag.

[sneaker_ger]

Here's a 24/1.001 fps sample file (http://www.file-upload.net/download-7739374/mkv_to_mkv_timing_fix.mkv.html) with incorrect h.264 bitstream time scale (24000 instead of 48000 field rate), but correct mkv timecodes.
Here's what is shown:
Frame rate : 11.990 fps
Original frame rate : 11.988 fps

To my understanding, "Frame rate" should be container rate, right? I.e. it should look like that:
Frame rate : 23.976 fps
Original frame rate : 11.988 fps

I know the file is kinda borked, but I thought I'd put this here anyways. I don't really care all that much, but it caused some irritation in another discussion with that sample.

[Atak_Snajpera]

Is this normal that MediaInfoA_Get(Handle_, 1, 0, 'Codec/String', 1, 0) for UT VIDEO (ULRG) returns Ultimotion string instead of just ULRG? For example UT VIDEO (ULRA) returns just ULRA

[Zenitram]

Is this normal that MediaInfoA_Get(Handle_, 1, 0, 'Codec/String', 1, 0) for UT VIDEO (ULRG) returns Ultimotion string instead of just ULRG? For example UT VIDEO (ULRA) returns just ULRA

Ultimotion is expected to be provided for 'ULTI' 4CC.
I have in the dtabase:
ULRA --> RGBA (Ut Video)
ULRG --> RGB (Ut Video)

FYI, "Codec/String" field is deprecated for several years and will be removed in few years, you should use non-deprecated fields ("Format" or "CodecID" depending of your needs).

[Reino]

still on the todo-list, but low priority because TAK is not very spread.Have you found some time to have a look now 8 months later?

[SeeMoreDigital]

Out of interest...

When running audio files through MediaInfo is it possible to determine/report what ID tagging type and version was used?


Cheers

[LoRd_MuldeR]

Here are some fresh MediaInfo v.0.7.65 builds:

CLI: http://code.google.com/p/mulder/downloads/detail?name=MediaInfo.2013-12-06.zip&can=2&q=
GUI: http://code.google.com/p/mulder/downloads/detail?name=MediaInfo-GUI.2013-12-07.zip&can=2&q=

[Octo-puss]

But that version has been out since 20.11. I don't understand the point of your builds.

[LoRd_MuldeR]

But that version has been out since 20.11. I don't understand the point of your builds.

You know, I'm not a build bot. I have other things to do in my life than monitoring the MediaInfo project and making new builds ASAP, so there can be some delays ;)

(BTW: Those builds are merely a byproduct of my other projects, but I still think they might be useful for others too, so I decided to share them here)

[Octo-puss]

Oh nothing wrong with that :) I was just being curious whether they were any different, because official builds are being posted pretty consistently.

[LoRd_MuldeR]

I was just being curious whether they were any different, because official builds are being posted pretty consistently.

First of all there are no "static" builds on the official web-site. So their builds always depend on an external MediaInfo DLL, while mine do not. Furthermore, I have created my own MediaInfo GUI from the scratch, that is quite different from the official one. And, finally, I sometimes needed to include custom patches to make MediaInfo work as I need it - though currently I don't include any custom patches.

[Octo-puss]

Allright. Thanks for clarification :)

[shinchiro]

Is it possible to get more information about attachment from mediainfo? For example get font name...

[foxyshadis]

Out of interest...

When running audio files through MediaInfo is it possible to determine/report what ID tagging type and version was used?


Cheers

Not yet. You'd have to patch it to expose that info, although it could be done as part of the tag reading functions.

[SeeMoreDigital]

Not yet. You'd have to patch it to expose that info, although it could be done as part of the tag reading functions.
Thanks for the reply...

So far, I've only found that MP3tag can reveal such information.

[Kurtnoise]

you mean something like ID3v2 or something else ?

[SeeMoreDigital]

you mean something like ID3v2 or something else ?
Yes, that's it.

MP3tag is able to define between: ID3v1, ID3v2.3, ID3v2.4, APEv2, FLAC and maybe some others...

I've been trying to perform some meta-data recognition tests with my Oppo BDP-103 player. So it would be most useful if your application was able to display such information.


Cheers

[Zenitram]

MP3tag is able to define between: ID3v1, ID3v2.3, ID3v2.4, APEv2, FLAC and maybe some others...

I definitely have it internally, but it is not exposed (I have to find/create a specific field for Tag format and version).

On the (very long :( ) ToDo-list.

[SeeMoreDigital]

I definitely have it internally, but it is not exposed (I have to find/create a specific field for Tag format and version).

On the (very long :( ) ToDo-list.
Out of interest... What sort of 'new features' are on your 'very long' to-do list?

[Zenitram]

Out of interest... What sort of 'new features' are on your 'very long' to-do list?

Oh... Nothing definitive, I always have more "super urgent" requests when I think I may finish soon :)
Most of them do not concern viewers of this forum because they are focused on professional needs (they sponsor me, MediaInfo is my full-time job).

A small list:
- IMF (Interoperable Master Format) (http://www.imfforum.com) (specs are not final so they change often) support,
- AAF (Advanced Authoring Format) (http://en.wikipedia.org/wiki/Advanced_Authoring_Format) (pretty old but professionals have sometimes old tools) support,
- EBUCore (https://tech.ebu.ch/lang/en/MetadataEbuCore) output support,
- Native ISO 9660 (http://en.wikipedia.org/wiki/ISO_9660) and ISO 13346 (http://en.wikipedia.org/wiki/ISO_13346) (aka .iso files) support (requested for a long time and finally sponsored!),
- Support of concatenation of VOB (DVD-Video) files (requested for a long time and finally sponsored!,
- Pro Tools 10+ Session file (.ptx) support,
- More JPEG 2000 bitstream analysis
- Improved ARIB (Japanese standard) captions support (also in MXF),
- More support of directories containing 1 file per stream with "home made standardized" file names (showing the directory as 1 package),
- Optimization of MediaInfo for reading files from high latency locations (HTTP/FTP servers not on site)
- More in depth analysis of MPEG Audio, AC-3, AAC, H.264 and H.265 for bitstream syntax errors detection,
- More regression tests, CPU and memory usage optimization,
- Automation of Windows/Linux/Mac deliveries,
- Improved template support for output (not sponsored yet so low priority),
- Common GUI on all platforms, and improvements on it (not sponsored yet so low priority),
- iPhone/Android/asm.js version (not sponsored yet so low priority),
- Documentation (not sponsored yet so low priority),
- Bugs correction, consulting as Digital Media Specialist...

BTW, if theses items are not cryptic for someone and if this person is interested in doing some development on MediaInfo (he must already know its code a bit as a proof he is interested by the tool), I can pay him (but I can not offer a full time job, only partial time)

[LoRd_MuldeR]

And again some fresh MediaInfo v0.7.67 builds:
CLI: http://sourceforge.net/projects/muldersoft/files/MediaInfo%20%28CLI%2BGUI%29/MediaInfo.2014-01-11.zip/download
GUI: http://sourceforge.net/projects/muldersoft/files/MediaInfo%20%28CLI%2BGUI%29/MediaInfo-GUI.2014-01-11.zip/download

[Nexin]

Tak (takc) encoded audio files (filename.tak)

Windows XP3 Right click context menu has no integration with .tak files

After Open Mediainfo manually will show info for tak file. Though MediaInfo shows 2 channel audio for 6 channel audio (Foobar2000_Info: FL FR FC LFE BL BR - 24/96 - lossless)



Also

No MediaInfo context use with MLP audio files. Drag and drop works with MediaInfo GUI v7.66.

[wanezhiling]

I don't know if someone has same experience, it took MediaInfo 0.7.65(and later) many time to scan a file with 'fake' extension. For example:
Scaning an orginal 4GB abc.ts may need 2sec only, while if you rename it to abc.avi, then the scaning time increases to 15sec..:scared:

ps: 0.7.64 has no this symptom.

[Zenitram]

it took MediaInfo 0.7.65(and later) many time to scan a file with 'fake' extension.

When the extension is the right one, the right parser is used in priority so all other useless parsers are not launched.

ps: 0.7.64 has no this symptom.

I need the file in order to see which parser has the bug (if it reads too much data before giving up).

[wanezhiling]

I need the file in order to see which parser has the bug (if it reads too much data before giving up).
You could just simply rename any big media files (blu-ray m2ts files eg.) to any other extensions (avi/mkv/mp4...).

[Zenitram]

Windows XP3 Right click context menu has no integration with .tak files

After Open Mediainfo manually will show info for tak file. Though MediaInfo shows 2 channel audio for 6 channel audio (Foobar2000_Info: FL FR FC LFE BL BR - 24/96 - lossless)

Known issue about the support of multi-channel extension of TAK, in the (long) ToDo-list, no ETA.

Tak (takc) encoded audio files (filename.tak)

No MediaInfo context use with MLP audio files. Drag and drop works with MediaInfo GUI v7.66.

Added to the list of known extensions.

[wanezhiling]

Latest 0.7.68 crashes when trying to scan the file (http://samples.mplayerhq.hu/V-codecs/WVP2/PhotoStory3.wmv).

0.7.67 was fine.

[Kurtnoise]

From which tool you're using the last release ?

coz, it works fine for me using my own build :

General
Complete name : PhotoStory3.wmv
Format : Windows Media
File size : 6.97 MiB
Duration : 3mn 16s
Overall bit rate mode : Variable
Overall bit rate : 298 Kbps
Maximum Overall bit rate : 416 Kbps
Publisher : Photo Story 3 for Windows
Genre : Photo Story
Encoded date : UTC 2072-10-08 13:49:52 / UTC 2008-06-02 16:56:13.416
Writing application : Photo Story 3 for Windows 3.0.1115.0
Cover : Y
PRIVATE/TotalBitrate : 416076
WM/VideoHeight : 480
WM/VideoWidth : 640
WM/VideoFrameRate : 30000
WM/SharedUserRating : 25

Video
ID : 2
Format : WVP2
Codec ID : WVP2
Description of the codec : Windows Media Video 9.1 Image
Duration : 3mn 16s
Bit rate mode : Variable
Bit rate : 20.5 Kbps
Width : 640 pixels
Height : 480 pixels
Display aspect ratio : 4:3
Frame rate : 30.000 fps
Bit depth : 8 bits
Bits/(Pixel*Frame) : 0.002
Stream size : 490 KiB (7%)
Language : English (US)

Audio
ID : 1
Format : WMA
Format version : Version 2
Codec ID : 161
Codec ID/Info : Windows Media Audio
Description of the codec : Windows Media Audio 9.2 - VBR Quality 75, 44 kHz, stereo 1-pass VBR
Duration : 3mn 16s
Bit rate mode : Variable
Bit rate : 119 Kbps
Channel(s) : 2 channels
Sampling rate : 44.1 KHz
Bit depth : 16 bits
Stream size : 2.79 MiB (40%)
Language : English (US)

[wanezhiling]

official gui build

[Zenitram]

Latest 0.7.68 crashes when trying to scan the file (http://samples.mplayerhq.hu/V-codecs/WVP2/PhotoStory3.wmv)

Very weird, it crashes only when I use the old Visual C++ 2005, no crash with Visual C++ 2010 and same config.
I don't try to understand, I actually switched to MSVC 2010 (I hop there is no more Win95 users in 2014!).

Here is a Development snapshot (http://sourceforge.net/projects/mediainfo/files/development_snapshots/0.7.68%2B/MediaInfo_GUI_20140419_Windows_i386_WithoutInstaller.7z/download)

[wanezhiling]

I am using win7/win8.1.

Tested dev version, no crash now.

[LoRd_MuldeR]

FWIW, here's a set of fresh MediaInfo v0.7.69 builds, all fully static:
http://sourceforge.net/projects/muldersoft/files/MediaInfo%20%28CLI%2BGUI%29/

[manolito]

While playing around with an MPEG2 HD test clip I got a little disturbed because MediaInfo and DGIndex cannot agree on the audio delay... :confused:

DGIndex reports 12ms while MediaInfo insists on -53ms. Which one is correct?

The file is here:
http://www.w6rz.net/1080p30.zip

Visually testing lip sync doesn't work here because the audio is silent.



Cheers
manolito

[Guest]

It's hard to say which is "correct" without specifying how the demuxing is done, and where the video will start.

For example, if both apps demux the audio the same but one discards leading B frames while the other does not, then the delay will be different.

I'll have a look at your stream and see if I have any comment to make about it.

[huokok]

Just wondering is there any method to make information on the right hand side become vertical aligned in html view? (like txt view but automatically wraping to conveniently see full x264 settings)

[Zenitram]

DGIndex reports 12ms while MediaInfo insists on -53ms. Which one is correct?

Video:
Frame 0 (2 in presentation order): PTS 1.768, DTS 1.668
Frame 1 (0 in presentation order): PTS/DTS 1.702

Audio:
Frame 0 : PTS 1.715

There is a bug somewhere in MediaInfo (it takes the PTS of the frame 2 in presentation order, not good).
DGIndex is right.

[Zenitram]

Just wondering is there any method to make information on the right hand side become vertical aligned in html view? (like txt view but automatically wraping to conveniently see full x264 settings)

For the moment, nothing.
GUI work is still something I would like to create again from scratch, but sponsored features have still the priority.

[manolito]

There is a bug somewhere in MediaInfo (it takes the PTS of the frame 2 in presentation order, not good).
DGIndex is right.

Thanks for looking into it...


Cheers
manolito

[RandomDude]

I'm running a bach script for MediaInfo CLI
template="file:///volumes/video/Temp/MediaInfoPara.txt"
output="/volumes/video/Temp/MediaInfoOut.txt"

mediainfo --Version

totfiles=$(find . -name "*.mkv" -o -name "*.m4v" -o -name "*.avi" | wc -l)
echo "Number of movies to check: " $totfiles

[[ -f "$output" ]] && rm -f "$output"

find . -name "*.mkv" -o -name "*.m4v" -o -name "*.avi" | while read movie
do
counter=$((counter+1))
echo -n "$((${counter}*100/${totfiles})) % "
echo -n R | tr 'R' '\r'
mediainfo --Inform=$template "$movie" >> $output
doneAnd here (http://pastebin.com/SuSppSWB) are the parameters for the script.

Everything is imported to Excel and works great except i have problems if there are many audio tracks leading to that subtitle 1 is not always in column XYZ. Any advice how to fix my script so the result is always zyx columns and first subtitle is find in column ccc. It's ok to maximize numbers of audio tracks like max 3 or 5.

[Zenitram]

i have problems if there are many audio tracks leading to that subtitle 1 is not always in column XYZ. Any advice how to fix my script so the result is always zyx columns and first subtitle is find in column ccc. It's ok to maximize numbers of audio tracks like max 3 or 5.

This is a problem with CSV :(.
For the moment, I coded something in the Windows GUI for having a fixed count of tracks (e.g. 5 audio tracks), but it is not yet moved to the CLI. I have no idea about when I'll have time to work on such extra feature on my side (not a priority of my sponsors), you are on your own (find another tool which can transform XML to CSV?)

[RandomDude]

This is a problem with CSV :( y, is it possible to use 2 template 1 for general and only 1 video. Can I specify to only get info from Audio 1 (main)?

And then use template 2 to add x no of subtitles, then the first subtitle will always start at column xyz?

[RandomDude]

1) What is the parameter to get color primaries, this doesn't work

mediainfo --inform="Video;%Color_Primaries%" filename


2) Is it possible to separate a BluRay Remux (no encoding settings) made with eac3to from a encoded mkv with stripped/missing encoding settings useing mediainfo

[Zenitram]

What is the parameter to get color primaries, this doesn't work
mediainfo --inform="Video;%Color_Primaries%" filename

%colour_primaries%
do mediainfo -f --Language=Raw in order to get the list of internal names you need for the template.

[Zenitram]

y, is it possible to use 2 template 1 for general and only 1 video. Can I specify to only get info from Audio 1 (main)?

And then use template 2 to add x no of subtitles, then the first subtitle will always start at column xyz?

The support of templates is currently very limited, you need to use the library directly in order to do exactly what you want.

[arestarh]

Zenitram
Hello!
Updated mediainfo's Ukrainian translation (based on language files from version 0.7.69):
http://rghost.ru/57087053

Also I have some question about translation of string for Default and Forced flags for tracks:
again, these string translatable or they are for machine analyze only?
I uploaded screenshot with demonstration of what I mean:
http://www.imagebam.com/image/7272de325032714

[nekrovski]

Hi, the following post was also posted here (http://forum.doom9.org/showpost.php?p=1687938&postcount=7599)

Hello

So ok, I have a video I want to encode/compress to a smaller size using MeGUI. I encode the video from tools-> avs script creator etc etc.
Then I extract the audio. Then I finally mux them.

The problem is, when it is not muxed, Mediainfo does show the bitrate. But after muxing, Mediainfo fails to show the bitrate. Why is this and is there any fix?

[Zenitram]

The problem is, when it is not muxed, Mediainfo does show the bitrate. But after muxing, Mediainfo fails to show the bitrate. Why is this and is there any fix?

What is the source container and in which container do you mux?

[nekrovski]

What is the source container and in which container do you mux?

Hi, thanks for your reply. The source container is mp4 and I mux to a mkv container.

In the meantime, this (http://forum.doom9.org/showpost.php?p=1602172&postcount=10) workaround helped me and after converting the audio to AC-3, MediaInfo does show the bitrate of the video.

[Zenitram]

The source container is mp4 and I mux to a mkv container.

As said in the other thread: not the same container, not the same capabilities.

[nekrovski]

But why the bitrate is shown when only the video is encoded? It's not the same container in that case as well.

[Zenitram]

But why the bitrate is shown when only the video is encoded? It's not the same container in that case as well.

Matroska has no bitrate per stream. It has a global bit rate (size/duration)
In case of only 1 VBR stream, easy: stream bitrate = container bitrate minus CBR streams bitrates (easy to find, it is CBR).
In case of 2 VBR streams, it is not possible to see which stream has which part of the overall bitrate.

FYI, New Matroska files have stream size and duration information, so I'll e able to compute stream bitrate or these new files.

[nekrovski]

Thanks, it's a bit clearer now. I'm noob at this and only go by logic.

[manolito]

Sorry but I have to report that the latest version 0.7.71 does not like my machine, it crashes instantly.

WinXP SP3, CPU Intel Coppermine (MMX + SSE, no SSE2).

In the changelog I could not find anything about changed system requirements, so please clarify if WinXP and / or Non-SSE2 CPUs are no longer suported.


Cheers
manolito

[Zenitram]

In the changelog I could not find anything about changed system requirements, so please clarify if WinXP and / or Non-SSE2 CPUs are no longer suported.

I upgraded my compilers (to RAD Studio XE2 for the GUI and MSVC2013 for the DLL) but I was careful about WinXP, I configured for WinXP support and tested on a WinXP SP3 x86 in a VM.

Can you try:
- Current version with old DLL (in order to test the GUI compiler)
- Current version with old EXE (in order to test the DLL compiler)

[clsid]

MSVC2013 defaults to using SSE2.

Project properties > C/C++ > Code Generation > Enable Enhanced Instruction Set > Select SSE ("Not Set" = use defaults = SSE2)

[Zenitram]

MSVC2013 defaults to using SSE2.

Owned.
Please test this snapshot (http://sourceforge.net/projects/mediainfo/files/development_snapshots/0.7.71%2B/MediaInfo_DLL_20141111_Windows_i386_WithoutInstaller.7z/download), I rebuilt with SSE settings (replace MediaInfo_i386.dll from the install dir with MediaInfo.dll from the new package, you need to rename the file)

[manolito]

Yes, the DLL from the snapshot works fine... :thanks:

Merci beaucoup...


Cheers
manolito



//Edit
Could it be that MediaInfo_InfoTip.dll is also affected? Because the Info Tips do not work any more with this version...

[LoRd_MuldeR]

Sorry but I have to report that the latest version 0.7.71 does not like my machine, it crashes instantly.

WinXP SP3, CPU Intel Coppermine (MMX + SSE, no SSE2).

In the changelog I could not find anything about changed system requirements, so please clarify if WinXP and / or Non-SSE2 CPUs are no longer suported.


Cheers
manolito

You could also try with my static MediaInfo binaries from here:
http://sourceforge.net/projects/muldersoft/files/MediaInfo%20%28CLI%2BGUI%29/

(It's compiled with runtime CPU dispatch, so it should work on PC without SSE2)

[manolito]

Thanks MuldeR for bringing it up, but it does not work...

The software just refuses to start, no error message, nothing. Changing screen color depth from 32bit to 16bit makes no difference either. And in any case I would need the DLL for using it in other applications like AVStoDVD, StaxRip, Yamb or MP4 tool.


Cheers
manolito

[LoRd_MuldeR]

Thanks MuldeR for bringing it up, but it does not work...

The software just refuses to start, no error message, nothing. Changing screen color depth from 32bit to 16bit makes no difference either.

What operating system? Let me guess: Windows XP?

I just noticed that I used one Win32 API function that was not available until Windows Vista, so this broke the whole program on XP :rolleyes:

Anwyay, since some people may still be using this ancient Windows version, this should fix XP support:
https://mega.co.nz/#!UNlUzIxK!iDw3D_u-SVA9SlCXX7w7Hw-dNl1ajIXvC2Yrw6-7lF4

[manolito]

Anwyay, since some people may still be using this ancient Windows version, this should fix XP support:
https://mega.co.nz/#!UNlUzIxK!iDw3D_u-SVA9SlCXX7w7Hw-dNl1ajIXvC2Yrw6-7lF4

Well, ancient yes, but between 25% and 30% of all Windows users still use it, some because they are too lazy to upgrade, and others like me because they feel that XP is better than Win7 or Win8... :)

The version you linked to does work on XP, but on my machine only if I switch color depth to 16bit (like I have to do for LameXP). Something about the Qt library...


Cheers
manolito

[StainlessS]

If your software runs on XP you are not 'encouraging' users to use XP, you are enabling them to use your software, if not, then they will not use your software.
Embedded XP will get the fix for linked bug and be added to the XP SP4 which is currently being worked on by a private individual.
Internet Explorer was/is always going to be a security nightmare, what with all of the new ways to break-in that MS keeps inventing (then inventing ways to stop the new inventions from being used/exploited).
I suspect that the usage numbers for XP are substantially underestimated, there are a lot of machines out there that will not be 'on-the-books', and there
is no shortage of new machines being sold that come with this ancient OS.
I still use XP32SP3 (SP4 when stable), and no amount of 'encouragment' is gonna dissuade me, next step would probably be Ubuntu.

EDIT: And thanx Zenitram, great work.

[Brazil2]

The version you linked to does work on XP, but on my machine only if I switch color depth to 16bit (like I have to do for LameXP).
Works fine for me on XP with 32-bit colors.

Also, please, in the future avoid using Mega. There are others light and friendly hosting sites for small files like http://www.tinyupload.com ;)

[SeeMoreDigital]

Well, ancient yes, but between 25% and 30% of all Windows users still use it, some because they are too lazy to upgrade, and others like me because they feel that XP is better than Win7 or Win8... :)

Well... I'm happy to confirm that MediaInfo works fine with Windows 10 (64-bit) Technical Preview :)

[Zenitram]

Well... I'm happy to confirm that MediaInfo works fine with Windows 10 (64-bit) Technical Preview :)

MediaInfo is very versatile :)

[SeeMoreDigital]

Hi Zenitram,

I can't remember if anyone has brought this up before but currently when MediaInfo reads a media file that contains DTS audio that's been encoded with a 96/24 extension flag it's presented, like this: -

Audio
ID : 4352 (0x1100)
Menu ID : 1 (0x1)
Format : DTS
Format/Info : Digital Theater Systems
Format profile : 96/24 / Core
Mode : 16
Format settings, Endianness : Big
Codec ID : 130
Duration : 59s 861ms
Bit rate mode : Constant
Bit rate : 1 509 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 96.0 KHz / 48.0 KHz
Bit depth : 24 bits
Compression mode : Lossy
Stream size : 10.8 MiB (47%)
Language : English

Which kinda makes sense...

However, when MediaInfo reads a media file that contains DTS-HD MA audio along with a DTS core that also includes a 96/24 extension flag (as found on some Blu-ray HFPA disc's) it's presented very much the same as above, like this: -

Audio
ID : 4352 (0x1100)
Menu ID : 1 (0x1)
Format : DTS
Format/Info : Digital Theater Systems
Format profile : 96/24 / Core
Mode : 16
Format settings, Endianness : Big
Muxing mode : Stream extension
Codec ID : 134
Duration : 59s 851ms
Bit rate mode : Constant
Bit rate : 1 509 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 96.0 KHz / 48.0 KHz
Bit depth : 24 bits
Compression mode : Lossy
Stream size : 10.8 MiB (14%)
Language : English

As you can see, the above report makes no mention of the DTS-HD MA audio stream!

Admittedly, there are very few Blu-ray HFPA disc's which contain DTS-HD MA audio along with a DTS 96/24 core in circulation (I only have three). But I thought you'd like to know ;)

Here's a link to a 60 second sample: https://www.sendspace.com/file/kav88b


Cheers

[Zenitram]

As you can see, the above report makes no mention of the DTS-HD MA audio stream!

Admittedly, there are very few Blu-ray HFPA disc's which contain DTS-HD MA audio along with a DTS 96/24 core in circulation (I only have three). But I thought you'd like to know ;)

Thanks for the report.
There is definitely a problem with the way I detect DTS extensions (I keep only one).

I see both "lossless" extension "MA" and "96/24" extensions in your file.

On my ToDo-list!

[SeeMoreDigital]

Thanks for the report.
There is definitely a problem with the way I detect DTS extensions (I keep only one).

I see both "lossless" extension "MA" and "96/24" extensions in your file.

On my ToDo-list!Thanks for the confirmation...

[manolito]

Could it be that MediaInfo_InfoTip.dll is also affected? Because the Info Tips do not work any more with this version...


Thanks for the new versin 0.7.72 :thanks:

I can confirm that this version now works again with a non-SSE2 CPU. The only thing I can't get working is the info tips (WinXP).


Cheers
manolito

[EncodedMango]

With the newest MediaInfo, using the HTML display mode makes the stats appear twice, doesn't happen with the previous version.

http://puu.sh/eha9v.png

[Zenitram]

With the newest MediaInfo, using the HTML display mode makes the stats appear twice, doesn't happen with the previous version.

Doomed version.
FYI, there is also a bug with XML output (https://sourceforge.net/p/mediainfo/bugs/886/).
I'll release a new version soon.

[EncodedMango]

I see, thanks!

[hello_hello]

I'm not sure whether here is the ideal place to ask for MediaInfoXP help, but I did check on LoRd_MuldeR's website, clicked on the MediaInfoXP help and support button, and here I am......

Are there any known issues with MediaInfoXP running on XP? I don't seem to be able to convince it to. Double clicking on MediaInfoXP.exe seems to do nothing. The GUI doesn't open. Am I missing something obvious? I've only tried the version found in the zip file "MediaInfoXP-GUI.2014-11-16.Win32". I think it's 2.13.

Thanks.

[stax76]

Hello Zenitram,

thanks for MediaInfo, my app calls it all over the place, countless times.

I'd like to report two issues:

Using a m2ts file Codec/String shows 'TrueHD / AC3' but when demuxed to a thd+ac3 file with eac3to Codec/String shows only AC3.

thd+ac3

Codec : TrueHD / AC3
Codec/String: AC3

m2ts

Codec : TrueHD / AC3
Codec/String: TrueHD / AC3

Please tell me if you need the file.

Another issue is MediaInfo shows everything correct in a mkv file but after demuxing with mkvextract MediaInfo fails on the dts file.

The sample is here (https://www.dropbox.com/s/yeint16h95kj0r8/dts_issue.7z?dl=0), it includes both mkv and demuxed dts.

[Brazil2]

Are there any known issues with MediaInfoXP running on XP? I don't seem to be able to convince it to. Double clicking on MediaInfoXP.exe seems to do nothing. The GUI doesn't open. Am I missing something obvious? I've only tried the version found in the zip file "MediaInfoXP-GUI.2014-11-16.Win32". I think it's 2.13.
Latest version 2.14 MediaInfoXP-GUI.2015-01-25.Win32.zip is running fine on XP.

Although the file version of MediaInfo is 0.7.71 whilst the --version parameter returns 0.7.72, so I'm not sure about which version is really used.

[stax76]

Hi,

I wrote something about StaxRip's MediaInfo GUI, how it might be integrated into the windows explorer shell, the StaxRip executable might be used alone without all included apps or a new app might be created, it would be easy it separate if there is interest, conversion to C# would also be trivial as there are amazing conversion tools.

http://forum.doom9.org/showpost.php?p=1709820&postcount=4729

[wanezhiling]

Hi Zenitram, PotPlayer(download (https://potplayer.daum.net/)) is unable to get media infomation when using 'native dxva (http://i2.tietuku.com/71ccabf9271bc253.png) + vanilla evr (http://i2.tietuku.com/462380c8775a946a.png)' combination with MediaInfo 0.7.71 and later version.
Press 'Ctrl+F1' during playback: http://i2.tietuku.com/7be5c998ac3e8b8c.png
Well, it works fine with MediaInfo 0.7.70: http://i2.tietuku.com/e5c828ecf223bda0.png, so PotPlayer dev sticks to an old DLL file.

According to PotPlayer dev, the bug is in MediaInfo side, would you take some time to have a look? Thanks. :)

[Kurtnoise]

Zen doesn't care about your player...he would like to have a sample in order to fix this.

[Zenitram]

A bit harsh ;-).
I have some pending bugs about the XML output, maybe they use this output, so buggy. But it is in 0.7.72 only, not 0.7.71.
Anyway, something weird is "when using (...)", MediaInfo is not aware of this player configuration, so I don't see the relationship between the player config and MediaInfo.
I would appreciate some more details than "bug is in MediaInfo side", e.g. which MediaInfo output API is used and which buggy output is provided to the player.

[wanezhiling]

No need sample, it happens with all media files.

Hmmm.. PotPlayer dev didn't tell more details, he just replied," Bug is in MediaInfo.dll, I can't do anything..."

:o:o

[Zenitram]

Hmmm.. PotPlayer dev didn't tell more details, he just replied," Bug is in MediaInfo.dll, I can't do anything..."

He can (saying what is the issue with MediaInfo).

[LoRd_MuldeR]

I have some pending bugs about the XML output, maybe they use this output, so buggy. But it is in 0.7.72 only, not 0.7.71.

BTW: Is there any ETA for 0.7.73 yet?

[Zenitram]

BTW: Is there any ETA for 0.7.73 yet?

ETA is February 1st, 2015. Yes, in the past!
More seriously, even my professional users are currently complaining about delays, and I have a business trip to the US next week and 2 big projects to finish before mid-March, so don't expect a release soon.
BTW, if you are interested in being paid for fixing MediaInfo bugs, ping me.

[LoRd_MuldeR]

ETA is February 1st, 2015. Yes, in the past!
More seriously, even my professional users are currently complaining about delays, and I have a business trip to the US next week and 2 big projects to finish before mid-March, so don't expect a release soon.

Okay, I see. No problem.

BTW, if you are interested in being paid for fixing MediaInfo bugs, ping me.

Sorry, my time is fully engaged already.

[Kurtnoise]

A bit harsh ;-).
Not too harsh for a software which violates GPL licence...:)

Anyway, what about my MI patches ? :p

[Zenitram]

Anyway, what about my MI patches ? :p


Oops... Checking them now.

[spoof]

Thank you for creating this free software. There is a bug in mediainfo. I have a file that media player classic can detect wether the file containing video and/or audio but mediainfo fail to detect the file. I would like to send this file to you but I don't know the procedure. Could you tell me the procedure to send you this file ?
Thank you again for your attention.

[SeeMoreDigital]

How many MB is this file. What type of contained file is it?

[Zenitram]

I would like to send this file to you but I don't know the procedure. Could you tell me the procedure to send you this file ?

The best method is to fill a bug ticket (https://sourceforge.net/p/mediainfo/bugs/?limit=250) with an URL to the file. The file may be provided privately to info@mediaarea.net if it can not be provided publicly.

[manolito]

@ Zenitram

This new version (again) refuses to run on my WinXP system with a non-SSE2 CPU. This has already happened with the previous version 0.7.72, and you were nice enough to compile a non-SSE2 version of the DLL for me.

But with this new version neither the GUI nor the DLL work. The change log does not say anything about WinXP or if SSE2 is required. I have no problem if you decide to no longer support XP or non-SSE2 CPUs, but please state it clearly in the change log or add a system requirement statement.


Cheers
manolito

[Zenitram]

This has already happened with the previous version 0.7.72, and you were nice enough to compile a non-SSE2 version of the DLL for me.

Looks like cleaned up too much before the release and forgot to configure one lib with /SSE.
Please try This DLL (https://mediaarea.net/temp/MediaInfo_DLL_20150415_Windows_i386_WithoutInstaller.7z)
(rename it to MediaInfo_i386.dll if yo uwant to test the GUI)

I have no problem if you decide to no longer support XP or non-SSE2 CPUs, but please state it clearly in the change log or add a system requirement statement.

For the moment, no plan to ignore WinXP users.

[manolito]

Merci beaucoup... :thanks:


//EDIT//
Something is wrong with the link for the new DLL. Could you please check?

[Zenitram]

Something is wrong with the link for the new DLL. Could you please check?

Corrected

[manolito]

Thanks very much, the download is working now...

The DLL works perfectly with my non-SSE2 CPU, and the GUI also works, with the exception of MediaInfo_InfoTip.dll. I don't get info tips when hovering over a file with the mouse pointer.

My workaround is to use the GUI version 0.7.70 together with the DLL v. 0.7.73, and this combination is perfect so far...


Thanks again
manolito

[Zenitram]

with the exception of MediaInfo_InfoTip.dll.

Same issue.
New InfoTip DLL (https://mediaarea.net/temp/MediaInfo_InfoTip_20150417_Windows_i386_WithoutInstaller.7z).

This time, I commit in the SVN now so I don't miss it again next time!

[manolito]

Sorry, the link points to the Mediainfo.dll, not to the InfoTip DLL... :confused:

[Zenitram]

Sorry, the link points to the Mediainfo.dll, not to the InfoTip DLL... :confused:

I am doomed. Corrected.

[manolito]

:thanks:

[ndjamena]

I'm trying to figure out why MediaInfo refuses to see the channel layouts EAC3To places in FLAC headers...

Looking at it them a hex editor I can see something that looks like it determines the layout... of course, I haven't taken the time learn how to disassemble the FLAC headers so it may be nothing but...

This comes from a header in a FLAC file MakeMKV made, where MediaInfo CAN see the Channel Layout:


WAVEFORMATEXTENSIBLE_CHANNEL_MASK=0x63F

Channel positions : Front: L C R, Side: L R, Back: L R, LFE

This comes from a header in a FLAC file EAC3To made, where MediaInfo CAN'T see the Channel Layout:


WAVEFORMATEXTENSIBLE_CHANNEL_MASK=0X63F

[Channel Postitions Element absent from MediaInfo output]

Is it possible the upper case 'X' is preventing MediaInfo from properly recognising this element in the header? Or am I waaay off and oversimplifying things...

-Edit- it occurred to me, I'd opened the thing in a Hex Editor... and it was one byte... so I changed it to lower case and now the channel positions have magically appeared in the MediaInfo output... Problem solved.

[Zenitram]

Is it possible the upper case 'X' is preventing MediaInfo from properly recognising this element in the header?

Patched (https://sourceforge.net/p/mediainfo/code/6802).

[ndjamena]

http://forum.doom9.org/showthread.php?p=1720157#post1720157

There has been a history of confusion with 5.1 channel assignments. In theory there's a difference between 5.1(back) and 5.1(side), but in real life there really isn't. Old Windows versions used channelmask 0x3F, which is 5.1(back), newer versions are using 0x60F, which is 5.1(side). Practically, when transporting this kind of data as 5.1 via HDMI to the receiver, it ends up all the same. The FLAC spec says that the default channel order for 5.1 is "5.1(back/side)". Well, it's described in other words, but you get my meaning: The FLAC spec doesn't make a difference between side and back for 5.1 channels. And neither does eac3to. The correct format is 5.1(side). And the only proper way to handle 5.1(back) is to treat it as 5.1(side), as well.

I don't know what problem MediaInfo might have, I don't use it. Fact is, if WAVEFORMATEXTENSIBLE_CHANNEL_MASK is specified, that's the channel assignment you should use. If that WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag is missing, then the default FLAC channel assignment should be used. On the following page search for "6 channels:" to see a list of the FLAC default channel assignments:

https://xiph.org/flac/format.html

MediaInfo fails to set defaults when no WAVEFORMATEXTENSIBLE_CHANNEL_MASK is specified in FLAC.

The fisrt M$ spec about 5.1 was FL,FR,FC,LF,BL,BR (back, mask 0x003F) and match the AC3 5.1 layout L,C,R,SurroundL,SurroundR,LFE or the DTS layout C,L,R,Ls,Rs,LFE

When come the 7.1 channels FL,FR,FC,LF,BL,BR,SL,SR (back, side, mask 0x063F) the M$ 5.1 specs change (if I remember whit M$ XP) to prefer FL,FR,FC,LF,SL,SR (side, mask 0x060F) over the old FL,FR,FC,LF,BL,BR but both specs remain valid, for backward compatibility, and any players must play the same with mask 0x003F or 0x060F.

Then, in a 5.1 layout, the last channels can be named Back, Side or simple Surround at your choice. That means the FLAC back/surround channels.

Only the 6.1 layout can be problematic because in the old M$ style FL,FR,FC,LF,BL,BR,BC (0x013F) the last channels don't have the same order than the new FL,FR,FC,LF,BC,SL,SR (0x070F), then here is important the correct channel-mask and order.
Any updated soft, like eac3to, must use FL,FR,FC,LF,BC,SL,SR (0x070F) and here FLAC is clear:
7 channels: front left, front right, front center, LFE, back center, side left, side right

[ndjamena]

Just to clarify, MediaInfo doesn't show any layout at all unless it's specified in a WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag, but the tag isn't actually necessary because there are default layout values in the specs that are determined by channel count.

All the 5.1 stuff is just because I'm not sure what 5.1 is supposed to default to. I think it's side... no ones being very specific.

[Zenitram]

Sorry not to have answered.

Just to clarify, MediaInfo doesn't show any layout at all unless it's specified in a WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag

I am reluctant to show information when not present in the bitstream, especially when the spec is unclear (e.g. "side/back")

but the tag isn't actually necessary because there are default layout values in the specs that are determined by channel count.

but for this one, looks like it is well defined (there is a default mapping)

All the 5.1 stuff is just because I'm not sure what 5.1 is supposed to default to. I think it's side... no ones being very specific.

I use "side" for AC-3, so I'll use "side".

[stax76]

Zenitram, do you remember why managed application were crashing using MediaInfo in the beginning of MediaInfo? I've now a similar problem with 2 AviSynth plugins. Since you were fixing this problem MediaInfo was working rock solid since countless years.

[Zenitram]

Zenitram, do you remember why managed application were crashing using MediaInfo in the beginning of MediaInfo? I've now a similar problem with 2 AviSynth plugins. Since you were fixing this problem MediaInfo was working rock solid since countless years.

Unfortunately not specifically this issue.
there were issues about CPU (people trying to load the 32-bit version because the project is configured for 32-bit but the DLL is 64-bit and vice-versa), about strings (which were deleted but still used by the calling app, I use temporary strings now), and many others I forgot.

[mariner]

Greetings Zenitram. Many thanks for sharing this wonderful piece of work.

Have a question on how delay is dealt with.

For example, mediainfo reported a video delay of 67ms and audio delay of 70ms for an mkv clip, resulting in net a/v delay of 3ms.

Other software(s), however, reported a net a/v delay of -67ms.

Would appreciate if you could kindly explain the discrepancy.

Many thanks and best regards.

[Zenitram]

For example, mediainfo reported a video delay of 67ms and audio delay of 70ms for an mkv clip, resulting in net a/v delay of 3ms.

Other software(s), however, reported a net a/v delay of -67ms.

Would appreciate if you could kindly explain the discrepancy

It may be a bug. Without the file (at least the first MB), I can not say more.

[mariner]

It may be a bug. Without the file (at least the first MB), I can not say more.

Thanks for the kind reply, Zenitram.

Would appreciate if you could advise the proper steps to use MVVtoolNix (or other software) to cut a sample without messing up the delay info.

Many thanks and best regards.

[sneaker_ger]

Open the file using mkvmerge GUI, go to the "global" tab and select "split parts" "split by parts based on timecodes" and enter e.g. "-0:0:10" (without quotes) to cut the first 10 seconds.

[mariner]

Open the file using mkvmerge GUI, go to the "global" tab and select "split parts" "split by parts based on timecodes" and enter e.g. "-0:0:10" (without quotes) to cut the first 10 seconds.

Thanks sneaker_ger. Here's a 5sec clip.

As I suspected, delay has been altered.

[Zenitram]

Would appreciate if you could advise the proper steps to use MVVtoolNix (or other software) to cut a sample without messing up the delay info.

Use any Hexadecimal editor (example : HxD (http://mh-nexus.de/en/hxd/)), select the first MB, (example : menu edit, "select block"), copy it, create a new file, paste, save, upload on any upload website.

[sneaker_ger]

As I suspected, delay has been altered.
You mean delays changed after remuxing? That shouldn't happen AFAIK. In that case you have to follow what Zenitram said to cut.

[mariner]

Use any Hexadecimal editor (example : HxD (http://mh-nexus.de/en/hxd/)), select the first MB, (example : menu edit, "select block"), copy it, create a new file, paste, save, upload on any upload website.

Thanks Zenitram. Here's a 1MB sample.

https://www.sendspace.com/file/umdxee

[mariner]

You mean delays changed after remuxing? That shouldn't happen AFAIK. ....

Unfortunately MKVT is not consistent dealing with delays under certain conditions.

[sneaker_ger]

Thanks Zenitram. Here's a 1MB sample.

https://www.sendspace.com/file/umdxee
Mkvtoolnix says delay for video 67 ms, delay for audio 0ms.

First cluster timecode is 67ms, 70ms is the first audio timecode >67ms so maybe MediaInfo does not handle correctly negative (in relation to cluster timecode) SimpleBlock timecode or something like that? It's a signed int.

[mariner]

Use any Hexadecimal editor (example : HxD (http://mh-nexus.de/en/hxd/)), select the first MB, (example : menu edit, "select block"), copy it, create a new file, paste, save, upload on any upload website.

Greetings Zenitram. Any luck with identifying the correct audio delay?

[Zenitram]

Any luck with identifying the correct audio delay?

I quicly check and issue may be inside MediaInfo. I did not have the time yet for a deep analysis. Work in progress

[mariner]

I quicly check and issue may be inside MediaInfo. I did not have the time yet for a deep analysis. Work in progress

Greetings Zenitram.

Many thanks for looking into the issue and best regards.

[LoRd_MuldeR]

Zenitram, I'm getting this compilation error with MediaInfo 0.7.74 release:
3>..\..\..\Source\MediaInfo\File__Analyze.cpp(2323): error : identifier "Trace_Activated" is undefined
3> if (Trace_Activated)
3> ^
3>
3>..\..\..\Source\MediaInfo\File__Analyze.cpp(2325): error : identifier "Config_Trace_Format" is undefined
3> switch (Config_Trace_Format)
3> ^
3>
3>..\..\..\Source\MediaInfo\File__Analyze.cpp(2329): error : class "MediaInfoLib::File__Analyze::element_details" has no member "ToShow"
3> size_t Details_lt_Pos=Element[Element_Level].ToShow.Details.rfind(__T("<"));

I do not have MEDIAINFO_TRACE enabled :confused:


[EDIT]

Just commenting out the whole "if(Trace_Activated)" block seems to have fixed it.

Hopefully this doesn't break anything. But, AFAICT, it should be fine, since it's just some "tracing" code.

I supposed the "#ifdef" guards are missing in the code?


[EDIT 2]

Anyway, new MediaInfoXP builds (including MediaInfo 0.7.74) are available now:
https://github.com/lordmulder/mediainfo-gui/releases/tag/v2.16

[Wilbert]

@Zenitram, Is it true that MediaInfo on sourceforge is bundled with adware? One of the reviews: "project now contains what I would consider malware -- it installs the Mezaa advertising client. ...". What happened?

[Zenitram]

@Zenitram, Is it true that MediaInfo on sourceforge is bundled with adware? One of the reviews: "project now contains what I would consider malware -- it installs the Mezaa advertising client. ...". What happened?

Fixed (https://sourceforge.net/p/forge/site-support/10486/).
But actually Sourceforge is not the main download site (actually it is no more linked from my websie for years, only old links not controlled by me go to Sourforge), please use the official website (http://mediaarea.net) instead.

[stax76]

@Zenitram, Is it true that MediaInfo on sourceforge is bundled with adware? One of the reviews: "project now contains what I would consider malware -- it installs the Mezaa advertising client. ...". What happened?

http://www.infoworld.com/article/2929732/open-source-software/sourceforge-commits-reputational-suicide.html

[Zenitram]

http://www.infoworld.com/article/2929732/open-source-software/sourceforge-commits-reputational-suicide.html

FYI, for my side, it was slightly different because I was myself bundling third party offer, violating ToS of SF.
I never abandonned the account (which is a mirror, no more the main download site), and for me it was back as normal (no ads) 1 hour after I pinged them.

[SeeMoreDigital]

Another instance where MediaInfo needs "better parsing" and maybe "full parsing" options. People request that for bitrate all the time, but you could certainly make framerate more precise by parsing a few minutes of frames.It is not a thread about MediaInfo so a very quick answer: it is always a problem of performance, lot of users already complain about parsing too many frames in the default behavior (too much slow with "only" few frames, and "few minutes of frames" means sometimes few Gigabytes of data to read from HDD), and full parsing option is already implemented for some customers with specific needs with a very precise computing of lot of things.
How difficult would it be for you to offer 'full parsing' and 'basic parsing' options to your regular version of MediaInfo?

Cheers

[Zenitram]

Zenitram, I'm getting this compilation error with MediaInfo 0.7.74 release

Already fixed (https://github.com/MediaArea/MediaInfoLib/commit/522963eed6c0297de9e61b78374179464750c7c0), but not in the latest source release, right.

[Zenitram]

How difficult would it be for you to offer 'full parsing' and 'basic parsing' options to your regular version of MediaInfo?

depends of what you are looking for.
1/ just add the option in the GUI: a couple of hours. Fact is that I do not want (at least for free) to update the current GUI because I plan to trash it (yes, I say that for years...) and I am not myself interested in letting people easily complain about "ho this is not exact value if I set full parsing, despite the fact I set full parsing so you should be able to provide the right value, MI is bad", see 2/.
2/ having exact value for lot of things (e.g. you want the exact byte count for MKV): this is not implemented everywhere, I have no idea about what works and whats does not work, I need a complete test of each item, lot of test several days/months. Currently I implement full parsing improvements item per item, when a user really (= he is ready to pay for it) need a feature (and in that case, he know how to activate full parsing for having his feature).

You can already test the current behavior with CLI or DLL (" -- ParseSpeed=0" for fast parsing and " -- ParseSpeed=1" for full parsing). There is absolutely no promise that MeidaInfo will do what you expect it does.

[foxyshadis]

That's good to know, and I might start using that in a few specific instances. Also good to hear that mkv parsing is going to be expanded soon.

[NikosD]

Hello.

No MediaInfo information for this file:

https://www.sendspace.com/file/xp31p6

[manolito]

The file is broken somehow...

TSDoctor complains about a missing PMT and refuses to repair the file. Remuxing to MKV (MKVToolNix) or remuxing to another m2ts (tsMuxeR) fixes it.


Cheers
manolito

[Zenitram]

No MediaInfo information for this file:


General
ID : 0 (0x0)
Complete name : C:\Users\Jerome\Downloads\hd_thx_amazing_life_lossless.m2ts
Format : BDAV
Format/Info : Blu-ray Video
File size : 193 MiB
Duration : 44s 830ms
Overall bit rate mode : Variable
Overall bit rate : 36.2 Mbps
Maximum Overall bit rate : 48.0 Mbps

Video
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 2 frames
Codec ID : 27
Duration : 44s 44ms
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive

Audio
ID : 4352 (0x1100)
Menu ID : 1 (0x1)
Format : DTS
Format/Info : Digital Theater Systems
Format profile : MA / Core
Mode : 16
Format settings, Endianness : Big
Muxing mode : Stream extension
Codec ID : 134
Duration : 44s 43ms
Bit rate mode : Variable
Bit rate : Unknown / 1 509 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 24 bits
Compression mode : Lossless / Lossy
Delay relative to video : -7ms

if I deactivate the CRC protection.
--> bug report to the owner of the tool you used for muxing, PAT CRC is good but PMT CRC is wrong.

[NikosD]

Manolito, Zenitram thank you both for your replies.

[73ChargerFan]

I use the command line interface to prepare MI reports on my files, using a DOS batch file ( :( )

I'd like to request a feature, to report the current directory name. I use the directory name as the reader friendly primary identifier, not the file name, and merging that information from the DOS batch file is extremely difficult.

Thank you for all your hard work.

[Zenitram]

I'd like to request a feature, to report the current directory name.

current directory name?
What is the relationship with MediaInfo?
http://www.windows-commandline.com/batch-file-get-current-directory/

If you want the directory name of the file you are analyzing, you can use the full output (" -f") or put %FolderName% in hte "General" section of a template

[LoRd_MuldeR]

current directory name?
What is the relationship with MediaInfo?
http://www.windows-commandline.com/batch-file-get-current-directory/

Also, if the full path to the file you are analyzing is in variable %i (or %1) of your Batch file, you can simply use %~dpi (or %~dp1) to get only the drive+path part.

[73ChargerFan]

My goal is a create a CSV to import into Excel, where each line is the folder name (user readable) and the major stats. MediaInfo can do all this except the folder name.

%FolderName% gives the complete path, but I want only the current directory.

Currently I use %~dpi (or %~dp1) but to get it into the same text line I must use a placeholder token in the MediaInfo format string, then do a text substitution by separate program. Problem is special characters in the path mangle and foul up batch file variable substitution and delayed expansion. Basically I've got most of a day into a hack that fails silently 2% of the time. This would be so much easier in Bash...

I know this is a special use case. Thank you for the assistance and suggestions!

[Zenitram]

%FolderName% gives the complete path, but I want only the current directory.

Please provide an example because I don't understand the difference between %FolderName% and "current directory".

[foxyshadis]

My goal is a create a CSV to import into Excel, where each line is the folder name (user readable) and the major stats. MediaInfo can do all this except the folder name.

%FolderName% gives the complete path, but I want only the current directory.

Currently I use %~dpi (or %~dp1) but to get it into the same text line I must use a placeholder token in the MediaInfo format string, then do a text substitution by separate program. Problem is special characters in the path mangle and foul up batch file variable substitution and delayed expansion. Basically I've got most of a day into a hack that fails silently 2% of the time. This would be so much easier in Bash...

I know this is a special use case. Thank you for the assistance and suggestions!

Been there, done that, batch files are horrible for this. So much cleaner using sed/awk from unixtools, PowerShell, vbscript, or your favorite installed scripting language to pare the full path down to just last folder\file.

[stax76]

I wrote a small guide regarding MediaInfo and StaxRip in case somebody is interested:

http://forum.doom9.org/showthread.php?p=1726081#post1726081

[73ChargerFan]

Please provide an example because I don't understand the difference between %FolderName% and "current directory".

Sorry for the late reply.

Example (1) %FolderName% gives complete path:
"Z:\Media\Kids\Kids 2\DC Batman, Superman\DCAU\Batman Beyond\"

Example (2) Current Directory: "Batman Beyond"
is the show title, and the directory has 50 +/- episodes named by episode number & episode title, but not including the show name.

[manolito]

@ foxyshadis

I am curious how using sed/awk from unixtools, PowerShell, vbscript or any other scripting language would make it any easier to extract the string "Batman Beyond" from the full path variable compared to using a simple batch file.

Yes, I would need a loop to determine the positions of the "\" characters, but I could write the batch file in 2 minutes. Please give us an example how you would do it with any of the tools you suggested.

I do have a little experience with SED for Windows, it is a pain to learn the syntax, and the result is "Write Only", without comments it is unreadable. And the learning curve for PowerShell or VBScript is also steep for someone who grew up with Turbo Pascal, MASM and DOS Batch language.


Cheers
manolito

[LoRd_MuldeR]

I am curious how using sed/awk from unixtools, PowerShell, vbscript or any other scripting language would make it any easier to extract the string "Batman Beyond" from the full path variable compared to using a simple batch file.

Should be straight forward to get it with a regular expression.

This gives you the last (rightmost) directory part within a full path, assuming there's a trailing backslash:
\\([^\\]+)\\$

If the path may end with file name, you can use:
\\([^\\]+)\\[^\\]*$

Now please don't ask me how to translate that to proper SED syntax ;)

[ndjamena]

Powershell:

$TargetPath="Z:\Media\Kids\Kids 2\DC Batman, Superman\DCAU\Batman Beyond\Boo.txt"

[System.IO.Path]::GetFileName([System.IO.Path]::GetDirectoryName($TargetPath))

It's mostly the '\' at the end of his example that's the problem. '/' is also a valid directory separator and "\\"... unless you know exactly where the filename will be sourced from you'd need to add some error correction into the mix.

Of course as far as I'm aware MediaInfo doesn't add the extra slash to the path name so

$TargetPath="Z:\Media\Kids\Kids 2\DC Batman, Superman\DCAU\Batman Beyond"
[System.IO.Path]::GetFileName($TargetPath)

will do.

(Powershell is a PITA, I prefer to use batch when I can get away with it.)

-Edit-

$TargetPath="Z:\Media\Kids\Kids 2\DC Batman, Superman\DCAU\Batman Beyond"
[System.IO.Path]::GetFileName($TargetPath).Trim('`"').TrimEnd("/\")

[73ChargerFan]

Sorry this is so off topic, I just think it's a good idea. But this will be my last post on this.

Even with the above code, I still have to capture the 1 line output of MediaInfo into a temp file, do a text substitution (which isn't free on Windows), then append that temp file onto the text file, which is another inner loop, and ...

This is what I get from my code, which loads directly into Excel.
First field is the Current Directory, next is file name, then size, file type, classification of video (done manually), video summary, main audio stream info, then finally the directory all the movie directories are in (this last matches the name of the backup hard drive the file is copied to.)


Z:\Kids Movies\Kids 1 Movies
Thu 01/29/2015 21:06:51.52

Bedtime Stories (2008),Bedtime Stories.mkv,18.9 GiB,Matroska,1080p,AVC High@L4.1,DTS-HD / 1509 Kbps 6 Ch ,Kids 1 Movies
Bolt (2008),Bolt.mkv,18.8 GiB,Matroska,1080p,AVC High@L4.1,DTS-HD / 1509 Kbps 6 Ch ,Kids 1 Movies
Cloak & Dagger (1984),Cloak & Dagger.iso,4.19 GiB,DVD ISO,Kids 1 Movies
Coraline (2009),Coraline.mkv,14.4 GiB,Matroska,1080p,VC-1 Advanced@L3,DTS-HD / 1509 Kbps 6 Ch AC3 @ 192 Kbps 2 Ch ,Kids 1 Movies
Doctor Dolittle (1967),Doctor Dolittle.mkv,6.50 GiB,Matroska,720x480,MPEG 2,5381 Kbps,AC3 @ 448 Kbps 4 Ch AC3 @ 192 Kbps 2 Ch ,Kids 1 Movies
How to Train Your Dragon (2010),Dragon.ts,17.3 GiB,MPEG-TS,1080p,AVC High@L4.1,23.4 Mbps,AC3 @ 640 Kbps 6 Ch ,Kids 1 Movies

[qyot27]

@ foxyshadis

I am curious how using sed/awk from unixtools, PowerShell, vbscript or any other scripting language would make it any easier to extract the string "Batman Beyond" from the full path variable compared to using a simple batch file.

Yes, I would need a loop to determine the positions of the "\" characters, but I could write the batch file in 2 minutes. Please give us an example how you would do it with any of the tools you suggested.

I do have a little experience with SED for Windows, it is a pain to learn the syntax, and the result is "Write Only", without comments it is unreadable. And the learning curve for PowerShell or VBScript is also steep for someone who grew up with Turbo Pascal, MASM and DOS Batch language.


Cheers
manolito
(g)awk is more suitable for this than sed, really.

Given "Z:\Media\Kids\Kids 2\DC Batman, Superman\DCAU\Batman Beyond\", it would only take:
awk -F'\\' '{print $(NF-1)}'
Which prints the second-to-last column (Batman Beyond), determined from the \ character delimiter.

[ndjamena]

Since most people would store batman beyond as ".\Batman Beyond\Season XX\" I should think this is more of a fringe feature request in any case.

You'd need access to each layer to get the most out of it.

[Zenitram]

Example (1) %FolderName% gives complete path:
"Z:\Media\Kids\Kids 2\DC Batman, Superman\DCAU\Batman Beyond\"

Example (2) Current Directory: "Batman Beyond"
is the show title, and the directory has 50 +/- episodes named by episode number & episode title, but not including the show name.

understood.
This is a very specific request, only for very users (Episodes can be in a sub-dir and so on), I don't want to add another field in the release of MediaInfo for such specific request.

You have to use an external tool (calling MediaInfo library and you manage the Path yourself in your favorite programming language, or something from the command line)

[73ChargerFan]

Thanks for the help anyway.

[Keiyakusha]

Zenitram
Hi. Currently for audio files with tags that have multiple occurances of the same tag, mediainfo displays them like so:
Composer : FirstTagValueHere / SecondTagValueHere
... which i think is good. However in case of MKV tags, for each tag name it displays only the last one. Can it be improved to show all the tags? Or at least make it show only the first one instead, which makes a bit more sense.

<?xml version="1.0"?>
<!-- <!DOCTYPE Tags SYSTEM "matroskatags.dtd"> -->
<Tags>
<Tag>
<Simple>
<Name>TITLE</Name>
<String>FirstTagValueHere</String>
<TagLanguage>und</TagLanguage>
<DefaultLanguage>1</DefaultLanguage>
</Simple>
<Simple>
<Name>TITLE</Name>
<String>SecondTagValueHere</String> <-- only this is displayed
<TagLanguage>und</TagLanguage>
<DefaultLanguage>1</DefaultLanguage>
</Simple>
</Tag>
</Tags>

[Zenitram]

However in case of MKV tags, for each tag name it displays only the last one.

Not expected. Please provide a sample file + the intended behavior.

[Keiyakusha]

Not expected. Please provide a sample file + the intended behavior.

Here is a sample file. (https://dl.dropboxusercontent.com/u/110558786/Report/mkv-tags-test.mka)

Current output with the latest stable mediainfo release. Note that the ALBUM tag is not shown at all, I just noticed this.

...
Overall bit rate : 986 Kbps
Track name : 池田綾子 「プリズム (backtracks)」
Encoded date : UTC 2015-06-23 11:17:58
Writing application : mkvmerge v8.0.0 ('Til The Day That I Die') 64bit
Writing library : libebml v1.3.1 + libmatroska v1.4.2
TITLE : Prism (backtracks)
ARTIST : Ikeda Ayako
COMPOSER : Ikeda Ayako
DATE_RECORDED : 2007-08-29
PART_NUMBER : 4
PUBLISHER : Sony Music Records
TOTAL_PARTS : 5
_STATISTICS_TAGS : BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
...

I expect output to be consistent with other files that have tags and to look like the example below.

...
Overall bit rate : 986 Kbps
Track name : 池田綾子 「プリズム (backtracks)」
Encoded date : UTC 2015-06-23 11:17:58
Writing application : mkvmerge v8.0.0 ('Til The Day That I Die') 64bit
Writing library : libebml v1.3.1 + libmatroska v1.4.2
ALBUM : プリズム／空の欠片 / Prism／Sora no Keppen
TITLE : プリズム (backtracks) / Prism (backtracks)
ARTIST : 池田綾子 / Ikeda Ayako
COMPOSER : 池田綾子 / Ikeda Ayako
DATE_RECORDED : 2007-08-29
PART_NUMBER : 4
PUBLISHER : Sony Music Records
TOTAL_PARTS : 5
_STATISTICS_TAGS : BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
...

Edit: here is how would the same track look in case of a normal FLAC file (https://dl.dropboxusercontent.com/u/110558786/Report/mkv-tags-test.flac). Note that MKV case seem to be having confusion with "PART" tags too, while FLAC is correct.

Overall bit rate : 840 Kbps
Album : プリズム／空の欠片 / Prism／Sora no Keppen
Album/Performer : 池田綾子 / Ikeda Ayako
Part : 1
Part/Total : 2
Track name : プリズム (backtracks) / Prism (backtracks)
Track name/Position : 4
Track name/Total : 5
Performer : 池田綾子 / Ikeda Ayako
Composer : 池田綾子 / Ikeda Ayako
Producer : Sony Music Records
Recorded date : 2007-08-29

[Kurtnoise]

About your ALBUM Tag...it's not available coz it's flagged as TITLE :

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

maybe an issue w/ your xml file tags...

[Keiyakusha]

About your ALBUM Tag...it's not available coz it's flagged as TITLE :

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

maybe an issue w/ your xml file tags...

I believe it is correct. What makes it different from track or other Titles is TargetTypeValue.
Accordingly to Matroska specs, 50 means "ALBUM / OPERA / CONCERT" and 30 means "TRACK / SONG"

[Kurtnoise]

but did you try what I said ?

MI doesnt rely on TargetTypeValues...

[Aleksoid1978]

https://yadi.sk/i/wqewWfIphYJoT
MediaInfo don't see any streams in this file. MPC-BE open correct and detect 1 video + 6 audio + 5 subtitles.

[SeeMoreDigital]

https://yadi.sk/i/wqewWfIphYJoT
MediaInfo don't see any streams in this file. MPC-BE open correct and detect 1 video + 6 audio + 5 subtitles.The .m2ts stream does not contain any PAT/PID data...

[Zenitram]

https://yadi.sk/i/wqewWfIphYJoT
MediaInfo don't see any streams in this file. MPC-BE open correct and detect 1 video + 6 audio + 5 subtitles.

MPC-BE ignores CRC errors, I do not.
PMT is buggy (CRC is wrong), so ignored (and the PMT is important for the list of streams)

[Aleksoid1978]

MPC-BE ignores CRC errors, I do not.
PMT is buggy (CRC is wrong), so ignored (and the PMT is important for the list of streams)

But - we can detect streams without any PMT data. MPC-BE can do this.

Also - this file open ffmpeg/LAVSource.

[Zenitram]

But - we can detect streams without any PMT data. MPC-BE can do this.

Yes, we can.
Current policy of MediaInfo:
- if there is PAT/PMT content, consider the file as a valid TS file, expecting valid PAT/PMT. Invalid CRC means transmission errors, waiting for the next one. the PAT is valid, so it is normal to wait for a valid PMT
-if there is no PAT/PMT, autodect of PES with content.

Your file has a problem: it has a valid PAT, and PMT with invalid CRC, you need to fix the muxer, not the analyzer.
If you want to have an option (which will not be activated by default because your file is buggy, not the analyzer) for bypassing CRC checks and/or forcing the autotdetect of PES even, please add a feature request (https://sourceforge.net/p/mediainfo/feature-requests/)) but I prefer to warn: due to the fact your file is buggy, I am not willing to implement this feature for free (but I may accpet a patch).

this file open ffmpeg/LAVSource.

Each developper has his own policy for buggy files. Mine is to not ignore a CRC fail, at least by default.

[NikosD]

Hello.

Latest MediaInfo v0.7.76 x86 crashes on AthlonXP (32 bit - non SSE2 CPU) using WinXP.

"External exception C000001D"

[manolito]

The trouble with non-SSE2 CPUs started with version 0.7.71, and upon my requests Zenitram corrected this up to version 0.7.74.
http://forum.doom9.org/showthread.php?p=1699337#post1699337

Starting with 0.7.75 the issue came back again, and I am getting a little tired of nagging Zenitram for every new version. Looks like I will stick with 0.7.74 for a while... ;)


Cheers
manolito

[clsid]

It is an easy fix for him. The MSVC2013 project files for ZenLib and Zlib need to be set to SSE. I have checked and the rest is ok.

[LoRd_MuldeR]

The trouble with non-SSE2 CPUs started with version 0.7.71, and upon my requests Zenitram corrected this up to version 0.7.74.
http://forum.doom9.org/showthread.php?p=1699337#post1699337

Starting with 0.7.75 the issue came back again, and I am getting a little tired of nagging Zenitram for every new version. Looks like I will stick with 0.7.74 for a while... ;)

Try this ;)

MediaInfo v0.7.76 static build:
http://sourceforge.net/projects/muldersoft/files/MediaInfo%20%28CLI%2BGUI%29/MediaInfo-CLI.2015-08-25.zip/download

[manolito]

Thanks a lot, works well... :thanks:

But I also need the DLL...


Cheers
manolito

[stax76]

It seems there was a change which broke a feature of my app and I don't know how to get the old behavior, the code I was using is:

MediaInfo_Option(mi.Handle, "Complete", "1")
Return Marshal.PtrToStringUni(MediaInfo_Inform(mi.Handle, 0))

Same version back this was getting parameter names with underscore but now it gets friendly names without underscore, I need to know all parameter names.

[NikosD]

Thanks a lot, works well... :thanks:

But I also need the DLL...


Cheers
manolito

New 0.7.77 is working fine with SSE.

[Kurtnoise]

It seems there was a change which broke a feature of my app and I don't know how to get the old behavior, the code I was using is:

MediaInfo_Option(mi.Handle, "Complete", "1")
Return Marshal.PtrToStringUni(MediaInfo_Inform(mi.Handle, 0))

Same version back this was getting parameter names with underscore but now it gets friendly names without underscore, I need to know all parameter names.
Nothing has changed regarding this part...

Could we have an example of what you had before/after ?

[stax76]

My MediaInfo GUI feature isn't working as before, now I get this:

File size : 47948706
File size : 45.7 MiB
File size : 46 MiB
File size : 46 MiB
File size : 45.7 MiB
File size : 45.73 MiB

I don't know exactly what it was before but think something like this:

File_size/String1 : 45.7 MiB
File_size/String2 : 46 MiB
File_size/String3 : 46 MiB
File_size/String4 : 45.7 MiB
File_size/String5 : 45.73 MiB

[manolito]

New 0.7.77 is working fine with SSE.

Confirmed, thanks Nikos for the info. And thanks to Zenitram of course... :thanks:


Cheers
manolito

[manolito]

No Detection of duration and frame rate for VFR MKV files

There are some VFR files (created by HandBrake) where the current MediaInfo versions cannot detect the frame rate (not even framerate_original) and the duration.

A sample file is here:
http://www3.zippyshare.com/v/VURfwwA3/file.html

The last MediaInfo version which handles these files correctly is version 0.7.58.


Cheers
manolito

[SeeMoreDigital]

There are some VFR files (created by HandBrake) where the current MediaInfo versions cannot detect the frame rate (not even framerate_original) and the duration.What makes you think that these VFR encoded files actually contain 'the original frame rate' meta-data?

Why anybody thinks generating VFR encodes is a good idea is beyond me!

[Zenitram]

There are some VFR files (created by HandBrake) where the current MediaInfo versions cannot detect the frame rate (not even framerate_original) and the duration.

A sample file is here:
http://www3.zippyshare.com/v/VURfwwA3/file.html

The last MediaInfo version which handles these files correctly is version 0.7.58.

It is VFR, so versions before 0.7.58 were actually bug (wrong information).
I understand that the current behavior (no information) is the right one, because it is VFR.

Duration is provided at the container ("general" part) level because this is the only one available, same: it is a fix of a previous bad behavior, so the current behavior (no information at the stream level) is the right one, because such information is not known.

There are some ideas (feature requests, not bug. A bug is when a piece of information is wrong, and you did not demonstrate that a piece of information is wrong) for getting duration with probing of the end of the file, and add an option for scanning the whole file (slow!) in order to get min/avg/max framerate, but there is currently no ETA (but this is planned for maximum next year, thanks to some global funding about Matroska (http://www.preforma-project.eu/mediaconch.html))

[Zenitram]

What makes you think that these VFR encoded files actually contain 'the original frame rate' meta-data?

Hint: they do not (AVC frmea rate info is set to "no fixed frame rate").

Why anybody thinks generating VFR encodes is a good idea is beyond me!

Beside the case of concatanation of 2 stream with different frame rate, we have variable bitrate, so why not variable frame rate if global quality is improved with it?

[manolito]

It is VFR, so versions before 0.7.58 were actually bug (wrong information).
I understand that the current behavior (no information) is the right one, because it is VFR.

I disagree. The current versions of MediaInfo just say: VFR, nothing else. No frame rate, no duration.

MediaInfo 0.7.58 says: VFR, correct duration, correct frame rate. This just works.


Another indication that the frame rate and the duration in fact can be retrieved from the source file (without parsing the whole file) is that I only have to repack the MKV to MP4 using ffmpeg (-acodec copy -vcodec copy), and voilà, even the current MediaInfo suddenly detects the frame rate and the duration.


Cheers
manolito

[Zenitram]

I disagree. The current versions of MediaInfo just say: VFR, nothing else. No frame rate, no duration.

So no bug (no incorrect result, an empty field means "unknown", that's all).
Again, this is the goal (fix of some bugs with the previous algorithm, which was not good for all files, only sometimes right).

MediaInfo 0.7.58 says: VFR, correct duration, correct frame rate. This just works.

It works for this file, not for all files. And it is impossible with the old algorithm to do the difference between your correct behavior and incorrect behavior with some other files, so the only solution for not having wrong results is to disable this algorithm.

Another indication that the frame rate and the duration in fact can be retrieved from the source file (without parsing the whole file) is that I only have to repack the MKV to MP4 using ffmpeg (-acodec copy -vcodec copy), and voilà, even the current MediaInfo suddenly detects the frame rate and the duration.

Good, you just learned that MP4 has frame duration of all frames in the MP4 header. this is not the case of of MKV (it is in hte frame header of each frame).
Hint: you repacked your MKV, so FFmpeg has read the whole file, it is aware of the duration of each frame for each stream, before writing the MP4 header.

Note: if you think you can get average frame rate and duration of all streams for sure, without any error with all files I have (that means that e.g. video stream duration and audio stream duration may be different) without parsing the whole file, I am interested in a patch and/or hint about how to get it.

[manolito]

Note: if you think you can get average frame rate and duration of all streams for sure, without any error with all files I have (that means that e.g. video stream duration and audio stream duration may be different) without parsing the whole file, I am interested in a patch and/or hint about how to get it.

Sorry, all the VFR files I ever had to deal with were created by HandBrake, and for these files the older MediaInfo 0.7.58 reports the correct frame rate.

I mainly use MediaInfo from within AVStoDVD, and situations where video and audio stream durations are different do not really matter here. AVStoDVD needs a frame rate, and if MediaInfo does not report it, I can only enter a frame rate manually - I have no way to know which one.

With the old MediaInfo version I do get a frame rate. And even if this rate is not totally correct, it will still work as long as VFR is detected. If the source is VFR, AVStoDVD will open it with with the DirectShowSource parameter "convertfps=true", and this will convert the source to CFR by inserting or dropping frames (similar if FFMpegSource is used).
Since AVStoDVD creates DVDs (which do not support VFR), a conversion from VFR to CFR is mandatory at some point in the chain, so doing this right at the source filter stage makes sense.


Maybe you can provide a link to some problematic VFR files where this old algorithm does not work...


Cheers
manolito

[foxyshadis]

If no frame rate is available, or even if one is but it's nonstandard, I'd just open with DSS's convertfps=true with exactly double whatever the final framerate of the DVD is, weave the fields, and encode interlaced. That handles all VFR as optimally as possible without either blending or mo-comp.

More advanced analysis could reveal where progressive with soft pulldown is possible, but you have to parse the timecodes for that and pass the ranges on. Encoding interlaced just works.

[Zenitram]

Sorry, all the VFR files I ever had to deal with were created by HandBrake, and for these files the older MediaInfo 0.7.58 reports the correct frame rate.

Did you test on a file more than 1 minute? Your sample file is small, so MediaInfo actually parses the whole file here (it parses ~500 frames for different reasons). So the previous algorithm was OK in this specific case.
Note: actually, it was not OK, the duration of the last frame was not used, real average frame rate is 15.111, not 15.167.

Not a big difference here, but it may be a bigger one for other files.

I mainly use MediaInfo from within AVStoDVD, and situations where video and audio stream durations are different do not really matter here.

Good for you. It does matter for me. And actually, you get the duration you are looking for (in the "general" part).
I'll be direct (and arogant): and I don't develop only for you. If you pay me, I could develop a specific version for you and/or add an option for having what you are looking for, and if you don't I just release a version whose I think is best for all people and which does not take too much time for me to develop.
"I" is not a good argument here.

Maybe you can provide a link to some problematic VFR files where this old algorithm does not work...

I would provide the same link than you: your file is a good example.

Let's play with this file, some fun:

- It has no metadata for hte duration of the stream. So we know that the program duration is 12.678 seconds, we know that the last frame timestamp is 12.612, but that's all. OK, let's try and say that the last frame has a duration of 66 ms (we cheat: we consider the program duration as the video duration). there are 191 frames in it (full scan, could not be done by default for all files, too slow), so average frame rate is 15.111. old algorithm does not work here (it says 15.167).
- Let's check the audio duration: last time stamp is 12.608. Audio block duration is provided by the AAC frame, 1024 samples/32000 Hz = 32 ms so total duration is 12.640. old algorithm (and the current one too, something is wrong because duration should not be displayed, I'll fix that) reuses the program duration (12.678), obviously wrong.

Let's rewrap to MP4 with FFmpeg:
- video duration: 12.611. Ho, funny, not same as Matroska program duration, ha ha... Actually, FFmpeg forces the last frame duration to 0. I guess it is wanted, but it is wrong (but actually it is not easy to know the real duration, we can cheat and read the program duration, this is a choice, FFmpeg did not choose that). You can see that old MediaInfo does not report the same frame rate (15.146 fps), so this is obvious that there is a problem somewhere.
- audio duration: 12.640. easier to get the right duration (thanks to AAC block duration information), not same as the algo in MediaInfo for the audio track (because MediaInfo is wrong for the audio track, actually).

***

I took some time for explaining issues, I won't take more time. old algo was wrong, not usable for a general purpose, that's all.
Current behavior is the expected one (actually, I should also remove the audio duration, this is a bug).
Improvement of the old algorithm in order to provide correct information for small files without showing incoherant values for some other files and an option for parsing the whole file in order to provide such value are on the ToDo-list, but is not the priority for the moment (no sponsor for it, sponsors have higher priority).

and please, don't say that I am wrong without being able to demonstrate in the specifications of the formats (Matroska, AVC, AAC...) how to readout such pieces of information. Example with FFmpeg transcode (which may introduce issues e.g. last frame duration of 0 which is not so real) or how you specificaly use a bunch of tools are not relevant (especially when you don't read the resut of your work, you say that MediaInfo can read frame rate from a MP4 transwrap, you "forgot" to say that the numbers are not same).

TLDR; I did not remove such information because I like to remove data, I removed it because I got too many complains about wrong results and it was the quickest way for me to provide less buggy information.

[manolito]

@ foxyshadis
Thanks for the tip to encode VFR as interlaced. Very useful, I will forward it to MrC...

@Zenitram
Looks like I stepped on your feet when I used the word "Bug Report" in my initial post. What I saw was that with these files the current version did not work, but the older version did. So I called it a regression, i.e. a bug.

I had no intention to offend you, you made your point very clear that the old algo was wrong and so you removed it, so the current version has the correct behavior and the old version was buggy.

If I did offend you, I do apologize, I also edited the header of my original post.


But I will stick with my point, this whole thing looks like the typical dispute between the academic world and the real world.

You say: If I am unable to report the exact and precise data, then I will rather not report anything at all.

I say: If I can get an approximation of the data with an acceptable margin of error (acceptable depends on the context where the application is used in) then I'd much rather use this approximation than getting no data at all.

In the context of AVStoDVD the margin of error for the old algo is small enough, errors of this magnitude have no influence on the quality of the conversion results.

In the medical community there is an old saying: "Whoever heals is right". I would change this saying for the computer programming world: "Whatever works is right". So I will continue using the old MediaInfo version 0.7.58 in AVStDVD until I stumble over a VFR conversion which looks terrible because the old algo screwed things up.



Cheers
manolito

[Zenitram]

In the medical community there is an old saying: "Whoever heals is right". I would change this saying for the computer programming world: "Whatever works is right".

Exactly my point: it was not working, I fixed it with the quickest way I found, because I did not have the time to fix it better. Whatever works is right, and it works better now than in 0.7.58 for my needs (genenral purpose, and I try to receive less complains by email about buggy values), at least.
Again, you have small differences with your files but other people may have more differences.
Again, I am not against reintroducing the old algo or finding a way to detect when algo is too much wrong on request, but this is development time (option to add, code maintenance...), time is money, and I don't want to spend my money on it for the moment, and nobody else is ready to spend his money (not his time for coding) on it, that's all.

[SeeMoreDigital]

Beside the case of concatanation of 2 stream with different frame rate, we have variable bitrate, so why not variable frame rate if global quality is improved with it?
Personally speaking I don't recommend the use of VFR because it's not supported by hardware playback devices ;)

[XinHong]

@Zenitram: Is it possible to detect if a TrueHD track contains the Atmos extension ?

[Zenitram]

@Zenitram: Is it possible to detect if a TrueHD track contains the Atmos extension ?

I have some Atmos files, but I did not have yet the time to implement the detection of Atmos. On the ToDo-list with low priority.

[XinHong]

Thanks for this ultra fast reply :)

[LoRd_MuldeR]

FWIW, I recently added "fresh" static builds of MediaInfo (CLI + GUI):
https://github.com/lordmulder/mediainfo-gui/releases/tag/v2.18

[ndjamena]

I can't get the source to compile in VS2012.

At first if complains that hmac.h is missing, so I found that file and added the directory to the include list, then it complains that "unresolved external symbol _hmac_sha | C:\Projects\MediaInfo\MediaInfoLib\Project\MSVC2012\Dll\MediaInfo.lib(Reader_libcurl.obj) | MediaInfoDll"

Anyway, I'm pretty sure all you'd have to do to fix part of the Matroska Tags issue is to, in file_mk.cpp, replace this line

if (Retrieve((stream_t)StreamKind, StreamPos, General_ID)==ID)
http://sourceforge.net/p/mediainfo/code/HEAD/tree/MediaInfoLib/trunk/Source/MediaInfo/Multiple/File_Mk.cpp#l2182
https://github.com/MediaArea/MediaInfoLib/blob/master/Source/MediaInfo/Multiple/File_Mk.cpp#L2181

with

if (Retrieve((stream_t)StreamKind, StreamPos, General_UniqueID)==ID)

Then, as and addition, replace this

if (Segment_Tag_SimpleTag_TagNames[0]==__T("BPS")) return; //Useless
http://sourceforge.net/p/mediainfo/code/HEAD/tree/MediaInfoLib/trunk/Source/MediaInfo/Multiple/File_Mk.cpp#l2147
https://github.com/MediaArea/MediaInfoLib/blob/master/Source/MediaInfo/Multiple/File_Mk.cpp#L2146

with this:

if (Segment_Tag_SimpleTag_TagNames[0]==__T("_STATISTICS_WRITING_APP")) return; //Useless
if (Segment_Tag_SimpleTag_TagNames[0]==__T("_STATISTICS_WRITING_DATE_UTC")) return; //Useless
if (Segment_Tag_SimpleTag_TagNames[0]==__T("_STATISTICS_TAGS")) return; //Useless


(It doesn't check to see if they're in the correct file, but it's better than what's happening now. I can't tell if all the tags have been read by that point or how to iterate through them and compare them to the headers.)

I can't compile it to check.


-edit-

This would be even better (I think)

if (Segment_Tag_SimpleTag_TagNames[0]==__T("BPS")) {Segment_Tag_SimpleTag_TagNames[0]=__T("*Bit rate"); TagString.append(__T(" bps"));}
if (Segment_Tag_SimpleTag_TagNames[0]==__T("DURATION")) {Segment_Tag_SimpleTag_TagNames[0]=__T("*Track duration/(HH:MM:SS.NNNNNNNNN");}
if (Segment_Tag_SimpleTag_TagNames[0]==__T("NUMBER_OF_FRAMES")) {Segment_Tag_SimpleTag_TagNames[0]=__T("*Track size/(Frames)");}
if (Segment_Tag_SimpleTag_TagNames[0]==__T("NUMBER_OF_BYTES")) {Segment_Tag_SimpleTag_TagNames[0]=__T("*Track size/(Bytes)");}

if (Segment_Tag_SimpleTag_TagNames[0]==__T("_STATISTICS_WRITING_APP")) return; //Useless
if (Segment_Tag_SimpleTag_TagNames[0]==__T("_STATISTICS_WRITING_DATE_UTC")) return; //Useless
if (Segment_Tag_SimpleTag_TagNames[0]==__T("_STATISTICS_TAGS")) return; //Useless

[ndjamena]

How's this:

https://github.com/MediaArea/MediaInfoLib/blob/master/Source/MediaInfo/Multiple/File_Mk.cpp#L385



//Tags
bool Tags_Verified=false;
Ztring TagsList=Retrieve(Temp->second.StreamKind, Temp->second.StreamPos, "Security Tags List", Info_Text);
if (!TagsList.empty())
{
Clear(Temp->second.StreamKind, Temp->second.StreamPos, "Security Tags List");
Ztring WritingApp=Retrieve(Temp->second.StreamKind, Temp->second.StreamPos, "Security Writing Application", Info_Text);
Ztring WritingDate=Retrieve(Temp->second.StreamKind, Temp->second.StreamPos, "Security Writing Date", Info_Text);
if ((!WritingApp.compare(Retrieve(Stream_General, 0, "Encoded_Application", Info_Text))) && (!WritingDate.compare(Retrieve(Stream_General, 0, "Encoded_Date", Info_Text))))
{ Fill(Temp->second.StreamKind, Temp->second.StreamPos, "*Statistics Tags Varified", "True"); Tags_Verified=true; }
else
Fill(Temp->second.StreamKind, Temp->second.StreamPos, "*Statistics Tags Varified", "False");
Clear(Temp->second.StreamKind, Temp->second.StreamPos, "Security Writing Application");
Clear(Temp->second.StreamKind, Temp->second.StreamPos, "Security Writing Date");
Ztring::iterator Back = TagsList.begin();
Ztring TempTag;
while (true)
{
if ((Back == TagsList.end()) || (*Back == ' ') || (*Back == '\0'))
{
if (TempTag == __T("BPS")) { TempTag = __T("Bit rate"); }
else if (TempTag == __T("DURATION")) { TempTag = __T("Track Duration/(HH:MM:SS.NNNNNNNNN)"); }
else if (TempTag == __T("NUMBER_OF_FRAMES")) { TempTag = __T("Track Size/(Frames)"); }
else if (TempTag == __T("NUMBER_OF_BYTES")) { TempTag = __T("Track Size/(Bytes)"); }
Ztring TagValue = Retrieve(Temp->second.StreamKind, Temp->second.StreamPos, TempTag.To_Local().c_str(), Info_Text);
if (!TagValue.empty())
{
Clear(Temp->second.StreamKind, Temp->second.StreamPos, TempTag.To_Local().c_str());
Fill(Temp->second.StreamKind, Temp->second.StreamPos, __T('*') + TempTag.To_Local().c_str(), TagValue.To_Local().c_str());
}
if (Back == TagsList.end()) break;
TempTag.clear();
}
else
TempTag+=*Back;
Back++;
}
}





https://github.com/MediaArea/MediaInfoLib/blob/master/Source/MediaInfo/Multiple/File_Mk.cpp#L2146



if (Segment_Tag_SimpleTag_TagNames[0]==__T("BPS")) {Segment_Tag_SimpleTag_TagNames[0]=__T("Bit rate"); TagString.append(__T(" bps"));}
if (Segment_Tag_SimpleTag_TagNames[0]==__T("DURATION")) {Segment_Tag_SimpleTag_TagNames[0]=__T("Track Duration/(HH:MM:SS.NNNNNNNNN)");}
if (Segment_Tag_SimpleTag_TagNames[0]==__T("NUMBER_OF_FRAMES")) {Segment_Tag_SimpleTag_TagNames[0]=__T("Track Size/(Frames)");}
if (Segment_Tag_SimpleTag_TagNames[0]==__T("NUMBER_OF_BYTES")) {Segment_Tag_SimpleTag_TagNames[0]=__T("Track Size/(Bytes)");}

if (Segment_Tag_SimpleTag_TagNames[0]==__T("_STATISTICS_WRITING_APP")) {Segment_Tag_SimpleTag_TagNames[0]=__T("Security Writing Application");}
if (Segment_Tag_SimpleTag_TagNames[0]==__T("_STATISTICS_WRITING_DATE_UTC")) {Segment_Tag_SimpleTag_TagNames[0]=__T("Security Writing Date"); TagString.insert(0, __T("UTC ")); }
if (Segment_Tag_SimpleTag_TagNames[0]==__T("_STATISTICS_TAGS")) {Segment_Tag_SimpleTag_TagNames[0]=__T("Security Tags List");}

[ndjamena]

I moved the tag processing up to the top of File_MK.cpp | File_Mk::Streams_Finish() so I could try to set the tag duration as a proper duration. I have no idea if the code will work though.


Ztring Duration_Temp, Codec_Temp;

if (Tags_Verified)
{
Duration_Temp = Retrieve(Temp->second.StreamKind, Temp->second.StreamPos, "*Track Duration/(HH:MM:SS.NNNNNNNNN)", Info_Text);
if (!Duration_Temp.empty())
{
Ztring::iterator Front = Duration_Temp.begin();
Ztring Parts [4];
int CountParts = 0;
while (true)
{
if (Front == Duration_Temp.end() || *Front == __T(':') || *Front == __T('.'))
{
CountParts++;
if (Front==Duration_Temp.end() || CountParts == 4) break;
}
else if (isdigit(*Front))
Parts[CountParts]+=*Front;
Front++;
}
if (CountParts == 4)
{
int64u Hours = Parts[0].To_int64u(10);
int64u Minutes = Parts[1].To_int64u(10);
int64u Seconds = Parts[2].To_int64u(10);
Parts[3] = Parts[3].substr(0, 3);
int64u Milliseconds = Parts[3].To_int64u(10);

Duration_Temp.From_Number((((Hours * 3600) + (Minutes * 60) + Seconds) * 1000) + Milliseconds, 10);
//Fill(StreamKind_Last, StreamPos_Last, Fill_Parameter(StreamKind_Last, Generic_Duration), Duration_Temp, true);
//Clear(Temp->second.StreamKind, Temp->second.StreamPos, "*Track Duration/(HH:MM:SS.NNNNNNNNN)");
}
else Duration_Temp.clear();
}
}
if (Duration_Temp.empty())
Duration_Temp=Retrieve(StreamKind_Last, Temp->second.StreamPos, Fill_Parameter(StreamKind_Last, Generic_Duration)); //Duration from stream is sometimes false




I had to move the declaration of the tag verification Boolean outside of my if statement...

...

...

Am I missing a library somewhere or is hmac.h not actually supposed to be included?

I really want this tag business done with.

[foxyshadis]

How are you building it? Only the MSVC 2013 project is kept up to date, which has it in the MediaInfoLib project under ThirdParty/hmac, so it should always be built with the rest of the lib. Don't use the older projects unless you regenerate them from cmake first. The GNU project is also kept up to date if you use mingw/gcc.

[Zenitram]

I can't get the source to compile in VS2012.

I forgot to update it when I added HMAC support.
Fixed (https://github.com/MediaArea/MediaInfoLib/commit/954e2c6b08d8b2a10faccb64c78880675bdd9a6e)

I really want this tag business done with.

I take it, but copy/paste of code is not ideal (actually it is super difficult to understand the goal of the patch). Is it possible to fork, commit the code on your repo then do a pull request on GitHub? so we can discuss with the code directly and you can get comments directly on modified lines.

[Zenitram]

Only the MSVC 2013 project is kept up to date

This was not intentional.
But I definitely can not support indefinitely all MSVC versions, so I just trashed MSVC 2005 / 2008 / 2010 projects.
I plan to keep MSVC 2012 and 2013 projects, and also propose soon MSVC 2015 project.

[LoRd_MuldeR]

Actually all MSVC versions since VS2010 use the same Project file format. So you can just keep the VS2013 project up-to-date and still open it in VS2010/VS2012.

In my experience, VS2010 or VS2012 will complain that it doesn't support toolset "v120" when you open the VS2013 project, but you can easily fix that by changing the toolset to "v100" or "vs110" as needed. The rest usually works fine.

[ndjamena]

https://mediaarea.net/en/MediaInfo/Support/Build_From_Sources/ThirdParty/BCB/TntUnicodeControls

This link doesn't go anywhere...

[ndjamena]

Looky, a Matroska file with streams of different length!



General
Unique ID : 186503756937573924653882743356120778548 (0x8C4F512865F76243A09179B2D1FE4734)
Complete name : D:\Make\Test.mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 259 MiB
Duration : 22mn 49s
Overall bit rate : 1 584 Kbps
Encoded date : UTC 2015-11-09 03:36:45
Writing application : mkvmerge v8.5.1 ('Where you lead I will follow') 64bit
Writing library : libebml v1.3.3 + libmatroska v1.4.4

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Baseline@L3
Format settings, CABAC : No
Format settings, ReFrames : 1 frame
Codec ID : V_MPEG4/ISO/AVC
Duration : 22mn 49s
Bit rate : 1 548 Kbps
Width : 628 pixels
Height : 474 pixels
Display aspect ratio : 4:3
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.217
Stream size : 253 MiB (98%)
Language : English
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.601 NTSC
Transfer characteristics : BT.709
Matrix coefficients : BT.601
*Statistics Tags Varified : True
*Track Duration/(HH:MM:SS.NNNNNNNNN) : 00:22:49.828000000

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : A_AAC
Duration : 5mn 2s
Bit rate : 152 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Stream size : 5.49 MiB (2%)
Language : English
Default : Yes
Forced : No
*Statistics Tags Varified : True
*Track Duration/(HH:MM:SS.NNNNNNNNN) : 00:05:02.976000000

[ndjamena]

Bah! It's still showing 'unknown' for the DTS-MA bitrate. That must be hardcoded somewhere else!!!!!

[Teebeeke]

Hi,

am trying to use mediainfo to import file information, but i can't seem to get the right code for height and width of a moviefile.

these work fine:

Dim temp_FileName As String = MI.Get_(StreamKind.General, 0, "FileName")
Dim temp_FileSize As String = MI.Get_(StreamKind.General, 0, "FileSize")
Dim temp_FileOverallBitRate As Decimal = MI.Get_(StreamKind.General, 0, "OverallBitRate")
Dim temp_FileDuration As Integer = MI.Get_(StreamKind.General, 0, "Duration")

but here i kinda am lost when i want height / width

Dim temp_Filewidth1 As String = MI.Get_(StreamKind.General, 0, "Width_Original")

Dim temp_FileWidth2 As String = MI.Get_(StreamKind.Video, 0, "Width")

Dim temp_FileWidth3 As String = MI.Get_(StreamKind.Video, 1, "Width_Original")

Dim temp_FileWidth4 As String = MI.Get_(StreamKind.Video, 0, "Width/string")

Dim temp_FileWidth5 As String = MI.Get_(StreamKind.Video, 1, "Width/string")


i'm a bit confused, where am i going wrong? (hope someone can/will help)


file info:

General
UniqueID/String : 262114971647940602408317479032599003676 (0xC53181DCE616FD46A51C09EE1152C21C)
CompleteName : D:\testfile.hevc.x265.mkv
Format : Matroska
Format_Version : Version 4 / Version 2
FileSize/String : 262 MiB
Duration/String : 55mn 1s
OverallBitRate/String : 666 Kbps
Movie : Test File made for testing mediainfo import
Encoded_Application/String : Lavf56.40.101
Encoded_Library/String : Lavf56.40.101
DESCRIPTION : testfile

Video
ID/String : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format_Profile : Main@L3.1@Main
CodecID : V_MPEGH/ISO/HEVC
Width/String : 1 280 pixels
Height/String : 720 pixels
DisplayAspectRatio/String : 16:9
FrameRate_Mode/String : Variable
FrameRate_Original/String : 23.976 fps
ColorSpace : YUV
ChromaSubsampling : 4:2:0
BitDepth/String : 8 bits
Encoded_Library/String : x265 1.7+399-cbdefdfca877:[Linux][GCC 4.9.3][64 bit] 8bit
Encoded_Library_Settings : deleted (too big)
Default/String : Yes
Forced/String : No
DURATION : 00:55:01.736000000

Audio
ID/String : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format_Profile : LC
CodecID : A_AAC
Duration/String : 55mn 1s
Channel(s)/String : 2 channels
ChannelPositions : Front: L R
SamplingRate/String : 48.0 KHz
Compression_Mode/String : Lossy
Encoded_Library/String : Lavc56.57.100 aac
Default/String : Yes
Forced/String : No
DURATION : 00:55:01.749000000

[Zenitram]

but here i kinda am lost when i want height / width

You don't say why you are lost: no result or no knowledge of which field is good for you.

for 99% of people, MI.Get_(StreamKind.Video, 0, "Width") is the only one needed.

[ndjamena]

InString = MI.Get(Stream_Video, a, L"Width_Original", Info_Text);
if (InString.empty())
{
InString = MI.Get(Stream_Video, a, L"Width", Info_Text);
}

[Teebeeke]

using .net (VS2012)

When i use MI.Get_(StreamKind.Video, 0, "Width") it doesnt give me a result, it stays empty.

[Zenitram]

Bah! It's still showing 'unknown' for the DTS-MA bitrate. That must be hardcoded somewhere else!!!!!

It is also filled by the DTS parser, and I guess there is a conflict between parsers.

I don't have a file with DTS-HD and statistic tags, please provide one.

[foxyshadis]

using .net (VS2012)

When i use MI.Get_(StreamKind.Video, 0, "Width") it doesnt give me a result, it stays empty.

MediaInfo can parse the width out of mkv, but not raw HEVC. Your file name shows you running it against the raw, not the muxed file.

Edit: Actually, I take that back, it looks like MediaInfo should be able to run against raw HEVC too now. What file format is your test file being detected as?

[Teebeeke]

This is all the information i get:

Format : HEVC
Format/Info : High Efficiency Video Coding
Format/Url : http://www.itu.int
Commercial name : HEVC
Format profile : Main@L3.1
Internet media type : video/H265
Codec ID : V_MPEGH/ISO/HEVC
Codec : V_MPEGH/ISO/HEVC
Codec : V_MPEGH/ISO/HEVC
Codec profile : Main@L3.1



Open


Inform with Complete=true
General
Count : 285
Count of stream of this kind : 1
Kind of stream : General
Kind of stream : General
Stream identifier : 0
Unique ID : 262114971647940602408317479032599003676
Unique ID : 262114971647940602408317479032599003676 (0xC53181DCE616FD46A51C09EE1152C21C)
Count of video streams : 1
Count of audio streams : 1
Video_Format_List : HEVC
Video_Format_WithHint_List : HEVC
Codecs Video : V_MPEGH/ISO/HEVC
Video_Language_List : English
Audio_Format_List : AAC
Audio_Format_WithHint_List : AAC
Audio codecs : AAC LC
Complete name : D:\testfile.hevc.x265.mkv
Folder name : D:
File name : testfile.hevc.x265
File extension : mkv
Format : Matroska
Format : Matroska
Format/Url : http://packs.matroska.org/
Format/Extensions usually used : mkv mk3d mka mks
Commercial name : Matroska
Format version : Version 4 / Version 2
Codec : Matroska
Codec : Matroska
Codec/Url : http://packs.matroska.org/
Codec/Extensions usually used : mkv mk3d mka mks
File size : 274728718
File size : 262 MiB
File size : 262 MiB
File size : 262 MiB
File size : 262 MiB
File size : 262.0 MiB
Duration : 3301749
Duration : 55mn 1s
Duration : 55mn 1s 749ms
Duration : 55mn 1s
Duration : 00:55:01.749
Overall bit rate : 665656
Overall bit rate : 666 Kbps
Title : testfile.hevc.x265
Movie name : testfile.hevc.x265.mkv
File creation date : UTC 2015-11-09 08:53:25.743
File creation date (local) : 2015-11-09 09:53:25.743
File last modification date : UTC 2015-11-09 08:55:38.124
File last modification date (local) : 2015-11-09 09:55:38.124
Writing application : Lavf56.40.101
Writing library : Lavf56.40.101
Writing library : Lavf56.40.101
DESCRIPTION : Testfile

Video
Count : 278
Count of stream of this kind : 1
Kind of stream : Video
Kind of stream : Video
Stream identifier : 0
StreamOrder : 0
ID : 1
ID : 1
Unique ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format/Url : http://www.itu.int
Commercial name : HEVC
Format profile : Main@L3.1
Internet media type : video/H265
Codec ID : V_MPEGH/ISO/HEVC
Codec : V_MPEGH/ISO/HEVC
Codec : V_MPEGH/ISO/HEVC
Codec profile : Main@L3.1
Width : 1280
Width : 1 280 pixels
Height : 720
Height : 720 pixels
Pixel aspect ratio : 1.000
Display aspect ratio : 1.778
Display aspect ratio : 16:9
Frame rate mode : VFR
Frame rate mode : Variable
Original frame rate : 23.976
Original frame rate : 23.976 fps
Resolution : 8
Resolution : 8 bits
Colorimetry : 4:2:0
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8
Bit depth : 8 bits
Delay : 0
Delay : 00:00:00.000
Delay, origin : Container
Delay, origin : Container
Writing library : Lavc56.57.100 libx265
Writing library : Lavc56.57.100 libx265
Language : en
Language : English
Language : English
Language : en
Language : eng
Language : en
Default : Yes
Default : Yes
Forced : No
Forced : No
DURATION : 00:55:01.736000000

Audio
Count : 223
Count of stream of this kind : 1
Kind of stream : Audio
Kind of stream : Audio
Stream identifier : 0
StreamOrder : 1
ID : 2
ID : 2
Unique ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Commercial name : AAC
Format profile : LC
Format settings, SBR : No (Explicit)
Format settings, SBR : No (Explicit)
Codec ID : A_AAC
Codec : AAC LC
Codec : AAC LC
Codec/Family : AAC
Duration : 3301749
Duration : 55mn 1s
Duration : 55mn 1s 749ms
Duration : 55mn 1s
Duration : 00:55:01.749
Channel(s) : 2
Channel(s) : 2 channels
Channel positions : Front: L R
Channel positions : 2/0/0
ChannelLayout : L R
Sampling rate : 48000
Sampling rate : 48.0 KHz
Samples count : 158483952
Resolution : 32
Resolution : 32 bits
Compression mode : Lossy
Compression mode : Lossy
Delay : 0
Delay : 00:00:00.000
Delay, origin : Container
Delay, origin : Container
Delay relative to video : 0
Video0 delay : 0
Writing library : Lavc56.57.100 aac
Writing library : Lavc56.57.100 aac
Default : Yes
Default : Yes
Forced : No
Forced : No
DURATION : 00:55:01.749000000

[SeeMoreDigital]

This is all the information i get:
Video
Count of stream of this kind : 1
Kind of stream : Video
ID : 1
Unique ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format/Url : http://www.itu.int
Format profile : Main@L3.1
Internet media type : video/H265
Codec ID : V_MPEGH/ISO/HEVC
Codec profile : Main@L3.1
Width : 1 280 pixels
Height : 720 pixels
Pixel aspect ratio : 1.000
Display aspect ratio : 1.778
Display aspect ratio : 16:9
Frame rate mode : VFR
Frame rate mode : Variable
Original frame rate : 23.976 fps
Resolution : 8 bits
Colorimetry : 4:2:0
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
I wonder why the HEVC video stream has been encoded with a 'variable' frame rate

[Zenitram]

I wonder why the HEVC video stream has been encoded with a 'variable' frame rate

VFR/CFR detection in Matroska is sometimes buggy, I would not rely too much on it. having less false positives is on the ToDo-list.

Here, the frame rate is also filled in the HEVC bitstream, I would rely more on it.

[Teebeeke]

But does that explain why MI.Get_(StreamKind.Video, 0, "Width") gives me 0 results?

If i use:
MI.Option_("Complete")
To_Display += MI.Inform()

which gives above info, it shows the width, but if i use MI.Get it shows no value.

[Zenitram]

But does that explain why MI.Get_(StreamKind.Video, 0, "Width") gives me 0 results?

If i use:
MI.Option_("Complete")
To_Display += MI.Inform()

which gives above info, it shows the width, but if i use MI.Get it shows no value.

No, issue is somewhere else, and I can not explain it for the moment (without testing it myself, but I don't have time for the moment).

[Kurtnoise]

I would try :

Dim temp_FileWidth As String = MI.Get_(StreamKind.Video, 1, "Width/String")

[Zenitram]

I would try :

Dim temp_FileWidth As String = MI.Get_(StreamKind.Video, 1, "Width/String")

0 for the 1st stream. (0-based number).
and that does not change the issue with "Width" :(.

[ndjamena]

Is Width_Original empty?

[foxyshadis]

But does that explain why MI.Get_(StreamKind.Video, 0, "Width") gives me 0 results?

If i use:
MI.Option_("Complete")
To_Display += MI.Inform()

which gives above info, it shows the width, but if i use MI.Get it shows no value.

You have Option Explicit Off and On Error Resume Next in your project, don't you? In the default VB project, it's StreamKind.Visual, not StreamKind.Video (perhaps a typo, perhaps intentional); if you change it to StreamKind.Visual -- or change Visual to Video in MediaInfoDLL.vb -- it should just start working. You would have noticed it wasn't just width if you'd looked for any other video properties.

With Option Explicit Off, VB will just ignore any typos you make, which makes IntelliSense much less useful. Use the tools you have!

[Teebeeke]

Yes, i noticed it too last night when i was looking into mediainfo_dll.vb, and i added video in there myself, but that didnt work. When i tried visual it showed the correct value.

Option Explicit was On btw.

[Kurtnoise]

0 for the 1st stream. (0-based number).
and that does not change the issue with "Width" :(.
mmh, yes...I thought it was the ID but it's the Stream identifier actually that should be taken into account.


@Teebeeke : you should put a sample file somewhere just to check out on our side...


@ndjamena : I would suggest to put "*Statistics Tags Verified : Yes/No" into the General Part, not for each streams...it's confusing for me.

[Zenitram]

When i tried visual it showed the correct value.

Argh... Very bad thing, there is an incoherency in the API.
I changed "Visual" to "Video"
Fixed (https://github.com/MediaArea/MediaInfoLib/commit/277564258e2ff1a005f88deb44d97dd9e1c225f6), with support of legacy StreamKind.Visual (considered as deprecated).

Something I don't understand is that your code was not detected as buggy (no "StreamKind.Video") when you ran your program (compiler indicates an error on my side).

[Zenitram]

@ndjamena : I would suggest to put "*Statistics Tags Verified : Yes/No" into the General Part, not for each streams...it's confusing for me.

the statistics writing app is provided by track, so he needs to test per track and provides this piece of information per track.

[foxyshadis]

Argh... Very bad thing, there is an incoherency in the API.
I changed "Visual" to "Video"
Fixed (https://github.com/MediaArea/MediaInfoLib/commit/277564258e2ff1a005f88deb44d97dd9e1c225f6), with support of legacy StreamKind.Visual (considered as deprecated).

Something I don't understand is that your code was not detected as buggy (no "StreamKind.Video") when you ran your program (compiler indicates an error on my side).

Sounds like he added Video without realizing that adding a value instead of replacing an old one won't work. Messing with enums has to be done carefully....

[Teebeeke]

yes, that was initially my fault. Once i replaced visual with video it worked. I was going to post this morning, but you beat me to it.

[ndjamena]

@ndjamena : I would suggest to put "*Statistics Tags Verified : Yes/No" into the General Part, not for each streams...it's confusing for me.

I'd be quite happy to remove all trace of the tags from sight, but it's not my place to make executive decisions like that.

The purpose of the "*Statistics Tags Verified" field being visible is to allow any unknown tags that have been encountered to be listed and shown and shown to be, in fact, verified.

It's preliminary, apparently Jerome doesn't like the idea of adding asterisks to the beginnings of unknown statistics tags to identify them.

I've left everything on the table, things need to be worked out from here.

(Did you download my dll or did yo compile your own?)

[Zenitram]

I'd be quite happy to remove all trace of the tags from sight, but it's not my place to make executive decisions like that.

I updated code with info visible only if there is a difference between muxer app name/date and stats app name/date because it is a source of problem as ndjamena pointed out.

The purpose of the "*Statistics Tags Verified" field being visible is to allow any unknown tags that have been encountered to be listed and shown and shown to be, in fact, verified.

The current policy in MediaInfo is to extract data wherever it comes from, without showing the source. In the future I could add information about the source but this is a long term feature and it will not be visible by default.

I modified the patch accordigly.

[73ChargerFan]

I'm glad to see MediaInfo will recognize HDCD; now I can script a test for it and mark such albums in my collection. Thanks.

https://upload.wikimedia.org/wikipedia/en/thumb/4/4f/HDCD_logo.svg/148px-HDCD_logo.svg.png

[salam2009]

Hey guys,
Is it possible to open MediaInfo of any file using a keyboard shortcut instead of going through its context menu ??
Thanks for any tip!
Cheers,
Salaam

[nekrovski]

Hey guys,
Is it possible to open MediaInfo of any file using a keyboard shortcut instead of going through its context menu ??
Yes.
Just press Shift + F10 + M + Enter

[salam2009]

Yes.
Just press Shift + F10 + M + Enter

lol, the mouse would be much easier than that :D
I meant something like opening the properties by Alt+Enter, if it has its own.
Anyway, thanks for stopping by!

[LoRd_MuldeR]

Hi Zenitram,

I'm trying to build v0.7.82 from the "AllInclusive" source package, but I noticed that the solutions (VS2013 and VS2015) contain a missing project called "zlibstat" :confused:

There is only the project "zlib" included, but it is missing from the solution. Furthermore, "zlib" only has a project file for VS2013, not for VS2015.

[Zenitram]

I'm trying to build v0.7.82 from the "AllInclusive" source package, but I noticed that the solutions (VS2013 and VS2015) contain a missing project called "zlibstat" :confused:

There is only the project "zlib" included, but it is missing from the solution. Furthermore, "zlib" only has a project file for VS2013, not for VS2015.

Argh, the script uses an old version of zlib package.
I'll update it soon.
New zlib package with VS2015 project (in /contrib/vstudio/vc14) is at https://github.com/MediaArea/zlib
New "All Inclusive" Git repo is at https://github.com/MediaArea/MediaInfo-AllInOne

[LoRd_MuldeR]

Thanks, I have now cloned the "All Inclusive" Git repo. VS2013 solution now contains "zlibstat" project, but VS2012 still contains the missing "zlib". VS2015 solution doesn't seem to exist in Git at all.

However I now stumbled upon a new strange issue, with the "ZenLib" project:

If I change any properties of the "ZenLib" project, then those changes do not apply to the .cpp files contained in the "ZenLib" project! For example, if I change "Enable Enhanced Instruction Set" from "Streaming SIMD Extension" to "No Enhanced Instructions" in the project properties, then the "Enable Enhanced Instruction Set" for the individual .cpp files still remains at "Streaming SIMD Extension". Very dangerous, because that is easy to miss! The strange thing is, that the "Enable Enhanced Instruction Set" property for the .cpp files are not showing in bold, so Visual Studio seems to believe it is inheriting these settings from the project properties. But it is very wrong! How is that even possible? Any clue what's up? :confused:

There appears to be no such problem with the "MediaInfoCLI" and "MeidaInfoLib" projects, as far as I can tell. But I'll have to do some more checks...

_________________

Side note: The pre-processor definitions for MediaInfoLib's "Release/Win32" and "Release/x64" configurations differ as follows, is that intentional?

Win32: WIN32;NDEBUG;MEDIAINFO_DVDIF_ANALYZE_NO;MEDIAINFO_MPEGTS_DUPLICATE_NO;MEDIAINFO_TRACE_NOx;MEDIAINFO_LIBMMS_NO;MEDIAINFO_LIBCURL_DLL_RUNTIME;%(PreprocessorDefinitions)
x64: WIN32;NDEBUG;MEDIAINFO_ADVANCED2;%(PreprocessorDefinitions)

[clsid]

The MSVC2015 MediaInfoLib.sln references the MSVC2013 ZenLib project. Maybe that causes your problem.

Also don't forget to adjust the platform toolset option if you want XP compatibility.

[LoRd_MuldeR]

The MSVC2015 MediaInfoLib.sln references the MSVC2013 ZenLib project. Maybe that causes your problem.

I cloned from the Git "All Inclusive" repo, which currently doesn't include MSVC2015 solution/project files. The problem showed up using the MSVC2013 solution.

Also don't forget to adjust the platform toolset option if you want XP compatibility.

Yes!

[foxyshadis]

Argh, the script uses an old version of zlib package.
I'll update it soon.
New zlib package with VS2015 project (in /contrib/vstudio/vc14) is at https://github.com/MediaArea/zlib
New "All Inclusive" Git repo is at https://github.com/MediaArea/MediaInfo-AllInOne

You're on github now! Awesome! I still had the old SVN base, and keeping a local copy of all those branches was pretty ugly. Getting the new repo now!

[LoRd_MuldeR]

Thanks, I have now cloned the "All Inclusive" Git repo. VS2013 solution now contains "zlibstat" project, but VS2012 still contains the missing "zlib". VS2015 solution doesn't seem to exist in Git at all.

However I now stumbled upon a new strange issue, with the "ZenLib" project:

If I change any properties of the "ZenLib" project, then those changes do not apply to the .cpp files contained in the "ZenLib" project! For example, if I change "Enable Enhanced Instruction Set" from "Streaming SIMD Extension" to "No Enhanced Instructions" in the project properties, then the "Enable Enhanced Instruction Set" for the individual .cpp files still remains at "Streaming SIMD Extension". Very dangerous, because that is easy to miss! The strange thing is, that the "Enable Enhanced Instruction Set" property for the .cpp files are not showing in bold, so Visual Studio seems to believe it is inheriting these settings from the project properties. But it is very wrong! How is that even possible? Any clue what's up? :confused:

There appears to be no such problem with the "MediaInfoCLI" and "MeidaInfoLib" projects, as far as I can tell. But I'll have to do some more checks...

_________________

Side note: The pre-processor definitions for MediaInfoLib's "Release/Win32" and "Release/x64" configurations differ as follows, is that intentional?

Win32: WIN32;NDEBUG;MEDIAINFO_DVDIF_ANALYZE_NO;MEDIAINFO_MPEGTS_DUPLICATE_NO;MEDIAINFO_TRACE_NOx;MEDIAINFO_LIBMMS_NO;MEDIAINFO_LIBCURL_DLL_RUNTIME;%(PreprocessorDefinitions)
x64: WIN32;NDEBUG;MEDIAINFO_ADVANCED2;%(PreprocessorDefinitions)

Okay, my bad. If forgot to update all sub-modules after cloning the "All Inclusive" repo - which apparently is required.

Now I have the MSVC2015 solutions/projects. Also the problem with "ZenLib" seems to be fixed for whatever reason. But now "zlibstat" has the problem that "ZenLib" had previously (project settings don't effect the .cpp files in that project) :confused:

Something really is not kosher with those solution/project files...

[Brazil2]

General
Complete name : G:\XTC.mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : isom (isom)
File size : 7.78 MiB
Duration : 4mn 13s
Overall bit rate mode : Variable

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 4mn 13s
Bit rate mode : Variable
Bit rate : 254 Kbps
Nominal bit rate : 96 bps
Maximum bit rate : 265 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 44.1 KHz
Frame rate : 43.066 fps (1024 spf)

Erm, 43 FPS for an audio only file ? WTH ?

[Zenitram]

Thanks, I have now cloned the "All Inclusive" Git repo. VS2013 solution now contains "zlibstat" project, but VS2012 still contains the missing "zlib". VS2015 solution doesn't seem to exist in Git at all.


OK, bugs...
VS2012 will be abandonned soon but I'll try to give it a try with a merge of old zlib package with the new one.
for VS2015 it should be OK, at lest with a git submodule update --remote

However I now stumbled upon a new strange issue, with the "ZenLib" project:

If I change any properties of the "ZenLib" project, then those changes do not apply to the .cpp files contained in the "ZenLib" project!

Weird and not expected because I set "no instruction" in my release on purpose.
the project file is very light, I don't expect that.
Anyway, I see a lot of discrependencies in the projects so I may do another pass soon in order to have something more homogeneous.

Side note: The pre-processor definitions for MediaInfoLib's "Release/Win32" and "Release/x64" configurations differ as follows, is that intentional?

Not intended. definitely need to sleep more :(
I'll review that too when I am back at home (I am currently at FOSDEM (https://fosdem.org/2016/schedule/event/mediaconch/) ;-) )

[LoRd_MuldeR]

Weird and not expected because I set "no instruction" in my release on purpose.
the project file is very light, I don't expect that.
Anyway, I see a lot of discrependencies in the projects so I may do another pass soon in order to have something more homogeneous.

Not intended. definitely need to sleep more :(
I'll review that too when I am back at home (I am currently at FOSDEM (https://fosdem.org/2016/schedule/event/mediaconch/) ;-) )

Thanks for looking into this!

(BTW: I know about the sleep problem at this kind of events. Didn't really sleep for ~4 days at recent 32C3 ;))

[Nico8583]

Hi,
I'm searching how to list chapters timecode and name with MediaInfo.dll (and displays it like MediaInfo GUI) from MKV file ? I'm using Delphi XE2, the DLL is working fine but I can't find how to list it.
Thank you !

Edit : It's OK, I've found the solution :
FirstChap:=StrToInt(MediaInfo_Get(Handle, Stream_Menu, 0, 'Chapters_Pos_Begin', Info_Text, Info_Name));
LastChap:=StrToInt(MediaInfo_Get(Handle, Stream_Menu, 0, 'Chapters_Pos_End', Info_Text, Info_Name));

for i:=FirstChap to LastChap-1 do
begin
Chapter:=MediaInfo_GetI(Handle, Stream_Menu, 0, i, Info_Name)+' '+MediaInfo_GetI(Handle, Stream_Menu, 0, i, Info_Text);
Memo1.Lines.Add(Chapter);
end;

[WeaponX]

Explorer tooltip is not showing up in windows 10 pro (64 bit). I already enabled Explorer Tooltip in mediainfo's preferences window. Whenever I mouse over a media file (.avi,.mp4,.mp3,etc.) , only the default explorer information is displayed (size,length, and availability). This is is a new computer with windows 10 already installed, which I bought last month, and I'm using the latest 64 bit mediainfo 0.7.83.

Strangely, the explorer tooltip shows up normally in my old computer which runs windows 7 ultimate (64 bit).

Anyone else have problems with mediainfo's explorer tooltip not showing up in windows 10?

[manolito]

Reporting a regression after version 0.7.81

With the Explorer tool tips turned on MediaInfo crashes Explorer when I mouse over an MP3 which has a cover included.

Vollständiger Name : H:\Patrice Rushen - Best Of\22 Watch Out.mp3
Format : MPEG Audio
Dateigröße : 7,47 MiB
Dauer : 5min 25s
Modus der Gesamtbitrate : konstant
Gesamte Bitrate : 192 Kbps
Album : Haven't You Heard: Best of
Album/Künstler : Patrice Rushen
Track-Name : Watch Out
Track-Name/Position : 14
Künstler : Patrice Rushen
Genre : Soul
Cover : Yes
Cover-Typ : Cover (front)
Cover-MIME : image/jpeg
File type : audio/mp3


After removing the cover information with a tag editor the crashes are gone. This issue started with version 0.7.82



My setup:

WinXP SP3 32bit
MediaInfo GUI version 0.7.70 (the last one with working tool tips)
MediaInfo.dll taken from later versions and renamed accordingly.



Cheers
manolito

[manolito]

The latest version 0.7.84 does crash under WinXP (non-SSE2 CPU) again...

It seems to be the DLL, not the GUI


Cheers
manolito

[Zenitram]

The latest version 0.7.84 does crash under WinXP (non-SSE2 CPU) again...

Argh.
Please test again (same link or this link (http://mediaarea.net/temp/NoSSE.exe) for avoiding potential file caching issue)

[manolito]

Sorry, no luck. Still getting this:

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

I did use the NoSSE.exe from your link. After testing and uninstalling it I also found that the tool tips from my previous installation were gone. Had to fix it by removing all MediaInfo Shell Extension entries from the Registry...


Cheers
manolito

[clsid]

Probably a dependency issue.

The project files should use RuntimeLibrary = MultiThreaded instead of MultiThreadedDLL to get a proper static build.

[LoRd_MuldeR]

A dependency issue wouldn't give you STATUS_ILLEGAL_INSTRUCTION (0xC000001D) error code though.

Looks more like something didn't get re-compiled with /arch:SSE, but still used SSE2 (default) or even higher. I had some strange issued with MediaInfo project/solution files before!

(Sometimes settings you set for the project simply won't apply properly to individual files in that project, for whatever reason!)

[Zenitram]

Looks more like something didn't get re-compiled with /arch:SSE, but still used SSE2 (default) or even higher. I had some strange issued with MediaInfo project/solution files before!


I'll apply again the settings tomorrow and we check again.
This time, it will be in the Git repository so we don't hear of this issue anymore.
(/MT will be not because default config used by other developers is /MD so I have /MD by default now, but I apply a patch for having /MT before I build, and as LoRd_MuldeR said this is not the source of the issue here).

[stax76]

There is a tool in StaxRip to show MediaInfo for all files in a folder including sub folders, it was a little bit improved in the last test build.

http://oi67.tinypic.com/10hlpc6.jpg

https://github.com/stax76/staxrip/wiki/Test-Build

[Zenitram]

After testing and uninstalling it I also found that the tool tips from my previous installation were gone. Had to fix it by removing all MediaInfo Shell Extension entries from the Registry...

Allways lot of delay... :(
I run automatic scripts now, instead of manual (and always buggy) processing of the release in order to distribute a version compatible with WinXP (I don't want to put it by default in the repo), please test again, both non-SSE and tooltip.

[Zenitram]

WinXP SP3 32bit
MediaInfo GUI version 0.7.70 (the last one with working tool tips)
MediaInfo.dll taken from later versions and renamed accordingly

I tested MediaInfo 0.7.85 on a clean install of WinXP SP3 32-bit (in a VM, but should be same), and I have the tooltip. So I can not reproduce this issue.

[Zenitram]

Explorer tooltip is not showing up in windows 10 pro (64 bit).

I got the same issue during testing after installation of 0.7.85, I uncheck the box, OK, reopen the preference windows, check the option, OK, Win+E (this part is not my fault, the explorer is not dynamicly updated), and it was working.
I don't know yet the reason it is failing the first time, but doing this methd is the current work around.

[manolito]

Thanks Zenitram for the new version...

The DLL 0.7.85 now works again under all my software which uses it. (Same old machine, WinXP SP3, non-SSE2 CPU).

I tested MediaInfo 0.7.85 on a clean install of WinXP SP3 32-bit (in a VM, but should be same), and I have the tooltip. So I can not reproduce this issue.

I still do not get tooltips with the new version, but maybe it's my configuration. I disabled the tray icon balloon tips using TweakUI, maybe this prevents the MediaInfo GUI versions later than 0.7.70 to display the tooltips. Registering the InfoTip.DLL with regsvr32 results in the error "module not found".

Whatever, I can live with using older versions for the GUI, no problem.


Thanks again
manolito

[frmys]

Thanks for this good tool.

Can you please add these to gui :

Grid lines for better visibility
Icons for audio and video and other types
Bold text for left column until ":"
Seperated info for General - Video- Audio- Text
Also these parts can be collapsable for those who need brief info
Configurable options for background color , fonts etc

[Zenitram]

Can you please add these to gui

Honnestly, don't expect improvements in the GUI in the next months/years, I have already a lot to do with the "core" of the tool for the moment. UI part will be strongly modified when I have free time, and I don't have free time for years :(.

But this is open source, I hope that someone else can fit such need.

[foxyshadis]

Thanks for this good tool.

Can you please add these to gui :

Grid lines for better visibility
Icons for audio and video and other types
Bold text for left column until ":"
Seperated info for General - Video- Audio- Text
Also these parts can be collapsable for those who need brief info
Configurable options for background color , fonts etc

Which format do you generally use? This is all much easier in HTML mode than anything else.

[Zenitram]

Which format do you generally use? This is all much easier in HTML mode than anything else.

There is a templating mecanism in MediaInfo, but is currently not really advanced. One can try with "custom" view and edit the examples, but be aware that the HTML viewer is also very basic (not a complete engine) and I am not willing to embed a complete browser in MediaInfo (I already embed a complete HTML browser in e.g. MediaConch (https://mediaarea.net/MediaConch/) for exactly this purpose in the future, and the binary is huge).

[raffriff42]

My XSLT (https://en.wikipedia.org/wiki/XSLT) is really rusty, but using it, it is possible to transform one of MediaInfo's XML formats ("XML", "PBCore", "EBUCore", ...) to HTML, as pretty as you please.

[LoRd_MuldeR]

Zenitram,

I'm trying to build MediaInfo CLI from "mediainfo_0.7.85_AllInclusive.7z", but the VisualStudio solution (MediaInfo.sln) contains a missing project "zlibstat". Not much surprising, build fails with:
4>MediaInfo-Static.lib(File_Ibi.obj) : error LNK2019: unresolved external symbol _uncompress
referenced in function "private: void __thiscall MediaInfoLib::File_Ibi::CompressedIndex(void)" (?CompressedIndex@File_Ibi@MediaInfoLib@@AAEXXZ)

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

(BTW: I can create a build by manually adding the "zlib" project to the solution and then fixing the project "references")

[Zenitram]

I'm trying to build MediaInfo CLI from "mediainfo_0.7.85_AllInclusive.7z", but the VisualStudio solution (MediaInfo.sln) contains a missing project "zlibstat".

Exact, a directory is missing, weird.
The directory is there:
https://github.com/MediaArea/zlib/tree/master/contrib

I'll check the reason it is not present.
Thanks for the report.

[LoRd_MuldeR]

Thanks for looking into this.

Yes, the directory "zlib" is in the 7z package. But the solution file is referring to a non-existing project "zlibstat", rather than existing "zlib" project. I think that is the problem.

Also I noticed that, in "MediaInfoLib" project, the Pre-Processor flags differ between "Release/Win32" and "Release/x64" configuration. Is that intentional?

Win32:
MEDIAINFO_DVDIF_ANALYZE_NO
MEDIAINFO_MPEGTS_DUPLICATE_NO
MEDIAINFO_TRACE_NOx
MEDIAINFO_LIBMMS_NO
MEDIAINFO_LIBCURL_DLL_RUNTIME

x64:
MEDIAINFO_LIBCURL_DLL_RUNTIME
MEDIAINFO_ADVANCED2

[Zenitram]

I'm trying to build MediaInfo CLI from "mediainfo_0.7.85_AllInclusive.7z", but the VisualStudio solution (MediaInfo.sln) contains a missing project "zlibstat".

Fixed (https://github.com/MediaArea/MediaArea-Utils/commit/79df9b89addec7a7339ee2690cfa6f9bb7a99d6f)

Should be OK in the release today

Also I noticed that, in "MediaInfoLib" project, the Pre-Processor flags differ between "Release/Win32" and "Release/x64" configuration. Is that intentional?

The MSVC2015 is correct and is the one used for release, and the MSVC2013 will die so I am lazy to change it.
There is no fundamental difference with the flags you show.

[NikosD]

There is an issue with MediaInfo, even in latest 0.7.86 version, of not recognizing the framerate of 120fps clips and because of that, it doesn't report the duration too, using MediaInfo.dll

[Zenitram]

not recognizing the framerate of 120fps clips

I need a sample file.

[NikosD]

Here you are:
https://www.sendspace.com/file/g874fg

[Zenitram]

Here you are:
https://www.sendspace.com/file/g874fg

Having timestamp like (in milliseconds):
20
28
36
40
45
53
60
61
78
80
86

is not something I call 120 fps (sometimes 1 ms of difference so 1000 fps, sometimes 17 ms so 60 fps!)
MediaInfo says "VBR", which looks like the right answer.

Note :the AVC stream was created with 120 fps metadata, but I trash this value when I detect VFR at the Matroska level.

Please provide a real (not only at the AVC stream level, but also the timestamps of each frame) 120 fps file.

[NikosD]

All of my CFR 120fps are recognized as such.

All of my VFR 120fps do not report a framerate.

I have seen a lot of times MediaInfo reporting a framerate, even for VFR.

Have you changed something and all VFR clips aren't reported with a framerate by Mediainfo anymore or 120fps is a special case ?

[Zenitram]

All of my CFR 120fps are recognized as such.

You said that your 120 fps files were not recognized...

All of my VFR 120fps do not report a framerate.

I have seen a lot of times MediaInfo reporting a framerate, even for VFR.

Have you changed something and all VFR clips aren't reported with a framerate by Mediainfo anymore or 120fps is a special case ?

For Matroska, there is no metadata for the average frame rate.
As the AVC stream provides different time stamps compared to the Matroska layer and MediaInfo detects VFR for the Matroska layer, for the moment I clear the frame rate provided by the AVC stream (not trustable: it says CFR and the container says VFR).
I may later (no ETA) display the AVC stream framerate, but it will not be in the "Frame rate" field as this real value is not known without parsing the whole file (so: we don't know it the frame rate).

[NikosD]

Thanks for the detailed reply.

[romulous]

Has anything changed in recent versions regarding command line handling? Just noticed that with .87, a file passed on the command line to MediaInfo will open the MediaInfo window, but the window will then be blank - you just see a message that you need to load a file. Command line used to work (ie MediaInfo would open and would display information on the file), but I don't know what version where this may have changed

[raffriff42]

Has anything changed in recent versions regarding command line handling? Just noticed that with .87, a file passed on the command line to MediaInfo will open the MediaInfo window, but the window will then be blank - you just see a message that you need to load a file.Downloaded 7.87 and tried it - it works for me. However, if I type an invalid file path, I get the message you do.

[romulous]

Yep, I have just managed to work out what was going wrong. The command line is being passed by another program, and the documentation for that program does say to include quote marks - to handle paths with spaces in them presumably - but the documentation is wrong in where it says to put the quote marks. As I was following the documentation, I too got it wrong. Moving the opening quote mark - the ending quote mark was fine - to another position fixes the problem (the path and filename both had spaces in them) and MediaInfo now opens with the file that is being passed to it.

[Blight]

Which thread priority does mediainfo use and is it somehow controllable? (I want to use it in idle thread priority so it has the least affect on UI performance)

[filler56789]

Hi Zenitram,

¿don't you think the "descriptive string" «Convenient unified display etc Etc ETC» is too long and annoying?

¿Why not say simply 'MediaInfo'? :confused:

http://forum.videohelp.com/attachments/38062-1470616418/mediainfo-sucking.png

[SeeMoreDigital]

Hi Zenitram,

¿don't you think the "descriptive string" «Convenient unified display etc Etc ETC» is too long and annoying?

¿Why not say simply 'MediaInfo'? :confused:

http://forum.videohelp.com/attachments/38062-1470616418/mediainfo-sucking.png
Or even 'MediaInfo: Media file meta-data analyzer'

[filler56789]

^ Never mind, just use Resource Hacker :devil: for the win :D

http://forum.videohelp.com/attachments/38453-1472797248/MediaInfo-FIXED.png

[Groucho2004]

Hi Zenitram,

¿don't you think the "descriptive string" «Convenient unified display etc Etc ETC» is too long and annoying?

¿Why not say simply 'MediaInfo'? :confused:

http://forum.videohelp.com/attachments/38062-1470616418/mediainfo-sucking.png
Similar issue here (http://forum.doom9.org/showthread.php?p=1777101#post1777101). Few devs know that Windows pulls the text from "FileDescription" instead of "ProductName".

[LoRd_MuldeR]

New MediaInfo builds (version 0.7.88), CLI and GUI, are now available:
https://github.com/lordmulder/mediainfo-gui/releases/tag/v2.21

[Brazil2]

New MediaInfo builds (version 0.7.88), CLI and GUI, are now available:
https://github.com/lordmulder/mediainfo-gui/releases/tag/v2.21
Thanks :)

[ggtop]

Hi LoRd_MuldeR,

something I observed using 2.21 on Win7 x64:
Everytime MediaInfo is started I have a new entry MediaInfoXP in Windows Explorer context menu though it is disabled in preferences. I have to enable and disable it for removal. MediaInfoXP is started from a portable drive.

Thanks for looking into the behavior in advance

ggtop

[Brazil2]

using 2.21 on Win7 x64:
Everytime MediaInfo is started I have a new entry MediaInfoXP in Windows Explorer context menu though it is disabled in preferences. I have to enable and disable it for removal.
Yes same for me and it behaves the same on Windows XP so it's not OS related.

[StainlessS]

I have basically always found it necessary to toggle Explorer preferences on/off/on in any version of MediaInfo (XP32SP3).
(with gui close between toggles, that though is to switch something on, not off)

[StainlessS]

MediaInfo v7.88, Access Violation on mp3 (XP32SP3):- EDIT: LINK REMOVED

With Settings, Explorer Tooltip enabled, hover over pretty much any mp3 file and get Access Violation.
I ended up have to delete original faulting mp3 via command line as just kept crashing explorer when approaching with mouse.
Going to any old mp3 folder, hovering over the 2nd of many mp3's, same again, so example mp3 is probably not really necessary.

EDIT: Disable Tooltip and no Access Violations.
@Zenitram, please say when taken sample file, so I can delete.

EDIT:

General
Complete name : C:\TEMP\Test.mp3
Format : MPEG Audio
File size : 1.72 MiB
Duration : 2 min 30 s
Overall bit rate mode : Constant
Overall bit rate : 96.0 kb/s
Album : Something Something Something
Track name : Something
Track name/Position : 48
Performer : Somebody
Genre : Pop
Recorded date : 2002
Cover : Yes
Cover MIME : image/jpg
MusicMatch_Situation : Background
MusicMatch_Mood : Morose

Audio
Format : MPEG Audio
Format version : Version 2
Format profile : Layer 3
Mode : Joint stereo
Mode extension : Intensity Stereo + MS Stereo
Duration : 2 min 30 s
Bit rate mode : Constant
Bit rate : 96.0 kb/s
Channel(s) : 2 channels
Sampling rate : 22.05 kHz
Compression mode : Lossy
Replay gain : -0.06 dB
Replay gain peak : 0.480973
Stream size : 1.72 MiB (100%)
MP3Gain, Min/Max : 135,180


EDIT: I know, its difficult, hard, impossible, to use MusicMatch after(And I think including) IE7. (I tag with W2K OS and MusicMatch, nothing I like better for that)

[manolito]

For me this only happens when the meta data of the MP3 contain cover information. See this post:
http://forum.doom9.org/showthread.php?p=1759773#post1759773

The last MediaInfo version without this issue is 0.7.81.


Cheers
manolito

[StainlessS]

Cheers Mani, love that smile :) [You should be in movies]

[manolito]

He still has a very nice smile, doesn't he?
http://www.henrydarrow.com/

[StainlessS]

He still has a very nice smile, doesn't he?
http://www.henrydarrow.com/

Yep.
Also from your link
He was also the lead guest star on a still-beloved program called "Bonanza", produced by the man who would later give us "The High Chaparral"


Seems that Gavino is right, even when he thinks he is wrong:- http://forum.doom9.org/showthread.php?p=1574331#post1574331

EDIT: Deleting given mp3 link in about 24 hours.

[LoRd_MuldeR]

In latest "All inclusive" package there still is a weird problem with the zlibstat project:

No matter what I do, the individual source code files in that project simply don't apply the settings (e.g. /MT vs. /MD switch) that I have set up in the "main" project properties - even if I explicitly apply "inherit from project defaults" :confused:

Had to remove the zlibstat project from the MediaInfo solution and add the normal zlib project instead, which seemed to fix this weirdness. Not sure why they exist both, anyway...

[manolito]

The latest MediaInfo v 0.7.91 fixes the issue from this post:
http://forum.doom9.org/showthread.php?p=1781741#post1781741

Thanks Zenitram... :thanks:

Cheers
manolito

[stax76]

here is a new MediaInfo cmdlet for PowerShell:

https://forum.doom9.org/showthread.php?t=174267

[LoRd_MuldeR]

MediaInfoXP v2.24 (MediaInfo v0.7.93)
* https://github.com/lordmulder/mediainfo-gui/releases/tag/v2.24
* https://sourceforge.net/projects/muldersoft/files/MediaInfo%20%28CLI%2BGUI%29/
* https://www.mediafire.com/folder/wpsz22gf8k8qv/MediaInfo

[manolito]

Thanks for the new version 0.7.94...

For the 32-bit CLI executable I found a small cosmetic bug (running under WinXP). For every file I throw at it I get this STDERR output:
E: File read error
E: is the drive where Windows is installed, MediaInfo.exe is called from a different drive. So this new version seems to try reading a file on the OS drive which probably does not exist... :confused:

The STDOUT output seems to be be correct, and since the error message does not cause a crash, I consider it cosmetic. The previous version had no problem. Also the 32-bit DLL 0.7.94 works fine.

Cheers
manolito

[Telion]

For the 32-bit CLI executable I found a small cosmetic bug (running under WinXP). For every file I throw at it I get this STDERR output:
E: File read error
Confirming this (also on XP), but I have no drive E: in my system. I've monitored file system activity with Sysinternal's Process Monitor - it shows no attempts to access anything with E: in a path, if that matters. I've also compared file access patterns of 0.7.93 and 0.7.94 versions, filtering out all successful results, and haven't found any differences except one thing. At the very beginning of an execution (unfiltered log entry ~10, before accessing any dependent dll) there are some QueryDirectory operations that enumerate files in several folders (one with MediaInfo.exe, system32, WinSxS), starting from the root and all the way down to them. And in 0.7.94 right after these queries there is one more enumeration of the tree down to a folder with a media file passed as a parameter - something that the previous version didn't do. So maybe that is somehow relevant to this issue?

[Aleksoid1978]

Latest version is hang when open .mpls from some 3D BD.
We have infinity loop here https://github.com/MediaArea/MediaInfoLib/blob/master/Source/MediaInfo/Video/File_Avc.cpp#L2265, TemporalReferences_Reserved = 0.

I made patch(for MPC-BE) - it's here https://sourceforge.net/p/mpcbe/code/2499/#diff-2
and more accurate fix - https://sourceforge.net/p/mpcbe/code/2500/#diff-1

[stax76]

here is a list of the known parameters: https://pastebin.com/e3U5dtpi

programmers might want to bookmark it

[LoRd_MuldeR]

Confirming this (also on XP), but I have no drive E: in my system. I've monitored file system activity with Sysinternal's Process Monitor - it shows no attempts to access anything with E: in a path, if that matters. I've also compared file access patterns of 0.7.93 and 0.7.94 versions, filtering out all successful results, and haven't found any differences except one thing. At the very beginning of an execution (unfiltered log entry ~10, before accessing any dependent dll) there are some QueryDirectory operations that enumerate files in several folders (one with MediaInfo.exe, system32, WinSxS), starting from the root and all the way down to them. And in 0.7.94 right after these queries there is one more enumeration of the tree down to a folder with a media file passed as a parameter - something that the previous version didn't do. So maybe that is somehow relevant to this issue?

I can confirm the "E: File read error" problem on my side as well. This happens for me on Windows 10.

BTW: I'm pretty sure "E:" is simply the prefix MediaInfo prepends to error messages:
void Log_0 (struct MediaInfo_Event_Log_0* Event, struct UserHandle_struct* UserHandler)
{
String MessageString;
if (Event->Type>=0xC0)
MessageString+=__T("E: ");

[Zenitram]

For every file I throw at it I get this STDERR output:

It is corrected, will be OK in next release or snapshots (https://mediaarea.net/download/snapshots/binary/mediainfo/).

[Zenitram]

I can confirm the "E: File read error" problem on my side as well.

It is corrected, will be OK in next release or snapshots (https://mediaarea.net/download/snapshots/binary/mediainfo/).

BTW: I'm pretty sure "E:" is simply the prefix MediaInfo prepends to error messages

Right.

[Zenitram]

here is a list of the known parameters: https://pastebin.com/e3U5dtpi

programmers might want to bookmark it

or help menu in GUI, "mediainfo --info_parameters" CLI, or source code (https://github.com/MediaArea/MediaInfoLib/tree/master/Source/Resource/Text/Stream).
If you want to see parameters for your files, "mediainfo -f -Language=raw FileName".

And yer, We need a better documentation...

[stax76]

Thanks, I didn't know about Language=raw, I've enabled it now in my GUI which I also use for windows file explorer: staxrip.exe -mediainfo sourcefile

[LoRd_MuldeR]

It is corrected, will be OK in next release or snapshots (https://mediaarea.net/download/snapshots/binary/mediainfo/).

Right.

:thanks:

I can confirm that it is fixed in the "snapshot" version.

[stax76]

Zenitram, there is a issue maybe you can take a look at: https://forum.doom9.org/showthread.php?p=1804785#post1804785

[sneaker_ger]

There's an extra byte added by mkvmerge 11 but I don't know what that means. I asked Mosu.
Sample if anyone wants: https://www.sendspace.com/file/2ja1kx

https://github.com/mbunkus/mkvtoolnix/issues/1958

[sneaker_ger]

@Zenitram @stax76
Was fixed in mkvmerge just now.

[stax76]

@Zenitram @stax76
Was fixed in mkvmerge just now.

Thanks for the help.

[stax76]

I thought typo but maybe it's a text encoding problem, any ideas?


Channel(s)/String : 6 channel3
ChannelPositions : Front: L C R, Side: L R, LFE
SamplingRate/String : 48.0 KHz
FrameRate/String : 46.875 fps3 (1024 spf)


I see this problem in staxrip only in the encoded output file but not on the input file and only with following option:

MediaInfo_Option(mi.Handle, "Language", "raw")

[stax76]

I'm getting crazy with this, it's returned from MI but arbitrary, I thought it might be due to language change on the thread but it's always German. When I start my app it's fine but after I re-encode the problem appears, it happens only with Language raw.

edit:


after startup:

Channel(s) : 2 / 1 / 1
Channel(s)/String : 2 channels / 1 channel / 1 channel


after re-encoding:

Channel(s) : 2 / 1 / 1
Channel(s)/String : 2 channel2 / 1 channel1 / 1 channel1

[Zenitram]

I'm getting crazy with this, it's returned from MI but arbitrary, I thought it might be due to language change on the thread but it's always German. When I start my app it's fine but after I re-encode the problem appears, it happens only with Language raw.

the first time you set Language raw after Open(), the second time it was before (from the first file, the option is global).
"channel3" and so on is the raw data (inside MI), before translation (even to English).

Language raw is to be used mostly for debugging (getting field names), what are you trying to do? set language to "raw" or any language before opening a file for more coherency. Or better: do not use it in production, this is not the goal (I actually don't see the reason you use it, I suggested it for having field names for MediaInfo::Get(), nothing else).

[Zenitram]

Thanks, I didn't know about Language=raw, I've enabled it now in my GUI which I also use for windows file explorer: staxrip.exe -mediainfo sourcefile

This is not an option intended for default mediainfo output, please let the default in that case.
what are you trying to do with that option I advised for getting field names but you use it for default output in your tool?

[stax76]

OK, I use default den.

[Selur]

Small question, when does MediaInfo report something other than 'vbr' as overall bitrate mode?
(tried using bit rate stuffing with tsMuxeR but I always get vbr and a max bitrate of 35MBit/s, which seems kind of odd for a ~500kbit/s stream)

Uploaded a small file to my google drive (https://drive.google.com/drive/folders/0B_WxUS1XGCPAUTlILW54VThMTFU?usp=sharing) as strange.7z.

Cu Selur

[Zenitram]

Small question, when does MediaInfo report something other than 'vbr' as overall bitrate mode?

When it is not VBR ;-).
I have tons of files with CBR overall bitrate mode, mostly dump of satellite or from pro customer preparing to send the TS stream to satellite (or cable, both need CBR TS files)

(tried using bit rate stuffing with tsMuxeR but I always get vbr and

I need to add a big tolerance (30% = NOK, 50% = OK) with " --MpegTs_VbrDetection_Delta=0.5" (hidden feature, default is 0 = no tolerance) for flagging it it as CBR.

a max bitrate of 35MBit/s, which seems kind of odd for a ~500kbit/s stream)

Note my choice, ask to the developer of the software you used for the reason "peak_rate" field is filled with a so high value (lazy default?)
"ETSI EN 300 468 v.1.14.1 - Specification for Service Information (http://www.etsi.org/deliver/etsi_en/300400_300499/300468/01.15.01_60/en_300468v011501p.pdf)":
peak_rate:
The maximum momentary transport packet rate (i.e. 188 bytes divided by the time interval between start
times of two succeeding TS packets). At least an upper bound for this peak_rate should be given. This 22-bit field is
coded as a positive integer in units of 400 bit/s.

0178 0x001F - DVB - selection_information_section (188 bytes)
0178 Header (4 bytes)
0178 sync_byte: 71 (0x47)
0179 transport_error_indicator: No
0179 payload_unit_start_indicator: Yes
0179 transport_priority: No
0179 pid: 31 (0x001F) - (13 bits)
017B transport_scrambling_control: 0 (0x0) - (2 bits)
017B adaptation_field_control (adaptation): No
017B adaptation_field_control (payload): Yes
017B continuity_counter: 1 (0x1) - (4 bits)
017C File Header (1 bytes)
017C pointer_field: 0 (0x00)
017D DVB - selection_information_section - Version=0 - Section=0 (28 bytes)
017D Header (3 bytes)
017D table_id: 127 (0x7F)
017E section_syntax_indicator: Yes
017E private_indicator: Yes
017E reserved: 3 (0x3) - (2 bits)
017E section_length: 25 (0x019) - (12 bits)
0180 DVB_reserved_for_future_use: 65535 (0xFFFF)
0182 reserved: 3 (0x3) - (2 bits)
0182 version_number: 0 (0x00) - (5 bits)
0182 current_next_indicator: Yes
0183 section_number: 0 (0x00)
0184 last_section_number: 0 (0x00)
0185 DVB_reserved_for_future_use: 15 (0xF) - (4 bits)
0185 transmission_info_loop_length: 10 (0x00A) - (12 bits)
0187 Descriptors (10 bytes)
0187 DVB - partial_transport_stream_descriptor (10 bytes)
0187 Header (2 bytes)
0187 descriptor_tag: 99 (0x63)
0188 descriptor_length: 8 (0x08)
0189 DVB_reserved_future_use: 3 (0x3) - (2 bits)
0189 peak_rate: 88750 (0x015AAE) - (22 bits)
018C DVB_reserved_future_use: 3 (0x3) - (2 bits)
018C minimum_overall_smoothing_rate: 4194303 (0x3FFFFF) - (22 bits)
018F DVB_reserved_future_use: 3 (0x3) - (2 bits)
018F maximum_overall_smoothing_buffer: 16383 (0x3FFF) - (14 bits)
0191 0001 (4 bytes)
0191 service_id: 1 (0x0001)
0193 DVB_reserved_future_use: Yes
0193 running_status: 0 (0x0) - (3 bits) -
0193 service_loop_length: 0 (0x000) - (12 bits)
0195 CRC32: 874440526 (0x341EE74E)

[stax76]

Can somebody point me to a sample containing:

MaxCLL - Maximum Content Light Level
MaxFALL - Maximum Frame-Average Light Level

[LoRd_MuldeR]

MediaInfoXP v2.27 (MediaInfo v0.7.99):
https://sourceforge.net/projects/muldersoft/files/MediaInfo%20%28CLI%2BGUI%29/MediaInfo-GUI.2017-10-29.zip/download

* MediaInfo updated to v0.7.99 (2017-09-11)
* Build environment upgraded to Visual Studio 2017 (15.4)

[StainlessS]

Praise the Lord
Thanx :)

[Atak_Snajpera]

It looks like that method of numbering versions has been changed to YEAR.MONTH
https://sourceforge.net/projects/mediainfo/files/binary/mediainfo/

[Emulgator]

Hi Zenitram !
Many thanks for your continued work !
While going through my testfiles I found mediainfo recognising multichannel MPEG Audio Layer 2 streams
(I got 4-CH, 5-CH, 6-CH as 5.1, up to 8 shall be possible) as 2 channel streams.
I can supply some testfiles, if needed.

[LoRd_MuldeR]

Hi Zenitram !
Many thanks for your continued work !
While going through my testfiles I found mediainfo recognising multichannel MPEG Audio Layer 2 streams
(I got 4-CH, 5-CH, 6-CH as 5.1, up to 8 shall be possible) as 2 channel streams.
I can supply some testfiles, if needed.

AFAIK, MPEG Audio Layer II only supports channel modes "Stereo" (00), "Joint Stereo" (01), "Dual Channel" (10) and "Single Channel" (11). Same for Layer III, by the way.
https://web.archive.org/web/20150208104604/http://www.mpgedit.org/mpgedit/mpeg_format/mpeghdr.htm

The so-called "MPEG Multichannel" extension uses a “channel matrixing scheme, where the additional channels are mixed into the two backwards compatible channels”, similar (but apparently not compatible to) Dolby Pro Logic.

So, technically, this would still be a Stereo file, just with the signals for the additional "sourround" channels mixed into the actual two (Stereo) channels...

[Emulgator]

Ah, thank you, that clears it up and at the same time explains why these multichannel files can be decoded with a stereo decoder.
I found Center mixed 50/50 into L/R, SL into L, SR into R.

[Atak_Snajpera]

What are string codes for these items?

Mastering display color primaries : R: x=0.680000 y=0.320000, G: x=0.265000 y=0.690000, B: x=0.150000 y=0.060000, White point: x=0.312700 y=0.329000
Mastering display luminance : min: 0.0050 cd/m2, max: 4000.0000 cd/m2
Maximum Content Light Level : 1529 cd/m2
Maximum Frame-Average Light Level : 380 cd/m2

I'm checking list of parameters in documentation (Developers\List_Of_Parameters\Video.csv) and I can't find anything related to above items.

[Zenitram]

What are string codes for these items?

Mastering display color primaries : R: x=0.680000 y=0.320000, G: x=0.265000 y=0.690000, B: x=0.150000 y=0.060000, White point: x=0.312700 y=0.329000
Mastering display luminance : min: 0.0050 cd/m2, max: 4000.0000 cd/m2
Maximum Content Light Level : 1529 cd/m2
Maximum Frame-Average Light Level : 380 cd/m2

I'm checking list of parameters in documentation (Developers\List_Of_Parameters\Video.csv) and I can't find anything related to above items.

they are currently not MediaInfo "standard" (they could in the future, maybe slightly modified). Field names can be seen with command line and " --Language=raw" or XML output in the GUI, e.g.:

<MasteringDisplay_ColorPrimaries>R: x=0.680000 y=0.320000, G: x=0.265000 y=0.690000, B: x=0.150000 y=0.060000, White point: x=0.312700 y=0.329000</MasteringDisplay_ColorPrimaries>
<MasteringDisplay_Luminance>min: 0.0050 cd/m2, max: 4000.0000 cd/m2</MasteringDisplay_Luminance>
<MaxCLL>10000 cd/m2</MaxCLL>
<MaxFALL>111 cd/m2</MaxFALL>

[Atak_Snajpera]

What is equivalent of

Transfer characteristics : PQ

in x265 settings

--transfer <string> Specify transfer characteristics from bt709, unknown, reserved, bt470m, bt470bg, smpte170m,
smpte240m, linear, log100, log316, iec61966-2-4, bt1361e, iec61966-2-1,
bt2020-10, bt2020-12, smpte2084, smpte428, arib-std-b67. Default undef

According to this I'm guessing that smpte2084.
http://i.cubeupload.com/cSkXcy.png

[Zenitram]

What is equivalent of

Transfer characteristics : PQ

in x265 settings


smpte2084 (https://en.wikipedia.org/wiki/High-dynamic-range_video#Perceptual_Quantizer)

[Atak_Snajpera]

It would be much easier for user if you used well known values like in x264/x265 documentation. In this case smpte2084 instead of PQ,
bt2020nc, bt2020c instead of BT.2020 non-constant/constant.

--colorprim <string> Specify color primaries from bt709, unknown, reserved, bt470m, bt470bg, smpte170m,
smpte240m, film, bt2020, smpte428, smpte431, smpte432. Default undef
--transfer <string> Specify transfer characteristics from bt709, unknown, reserved, bt470m, bt470bg, smpte170m,
smpte240m, linear, log100, log316, iec61966-2-4, bt1361e, iec61966-2-1,
bt2020-10, bt2020-12, smpte2084, smpte428, arib-std-b67. Default undef
--colormatrix <string> Specify color matrix setting from undef, bt709, fcc, bt470bg, smpte170m,
smpte240m, GBR, YCgCo, bt2020nc, bt2020c, smpte2085, chroma-derived-nc, chroma-derived-c, ictcp. Default undef

[Zenitram]

It would be much easier for user if you used well known values like in x264/x265 documentation. In this case smpte2084 instead of PQ,
bt2020nc, bt2020c instead of BT.2020 non-constant/constant.

I am in good mood, so let's go.

Sure, as soon as you can prove that what x264/x265 do is "well known" for all people involved with colors.
Spoiler: you won't be able to prove that, as I already had the opposite complain ("please use PQ wording, please use well know values, instead of this crazy SMPTE number") during some beta version.

Ho, BTW, please hint x265 people to change their name, because they do HEVC, look at the URL here https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding , "265" is not known by everyone, look it is not in the URL of Wikipedia English (but it is in the French version, funny isn't it?), why do they mislead people with "265" thing? (I use "HEVC" word, sorry "H.265" people)

(A bit) more seriously, please don't do assumption that x265 people have the "real truth", they are not the center of the universe and they don't represent the industry as a whole (because the industry is not a whole), and in the case of "PQ" it is the "well known value" used by one of my sponsor, a lot known in this industry, and actually my policy is to try to avoid SMPTE number (side note: this is "SMPTE ST 2084", not "SMPTE 2084") when I can because they are difficult to memorize (and are less known than the BT ones), beside prioritizing American names (MPEG ones: AVC, HEVC...) other ITU names (H.264, H.265) when it is a joint venture with only different names in their respective standard bodies.
Warning, in the next release there is a change in order to meet this policy, as I was not aware of "well known names" (remark: someone complained about the exact opposite of your remark when he indicated new names, because I was using SMPTE numbers, the ones used by x265, and not "well known names" from his point of view, he wanted me to replace by his "well known values"), I used SMPTE numbers 431-2 and 432-1 (funny isn't it that such numbers are difficult to differentiate? Worse, one is "RP" and the other is "EG" and 431 alone does not exist, it is 431-2) only because I was not aware of "well known names" and I'll replace them by "DCI P3" and "Display P3" (https://www.google.de/search?q="Display+P3") (commit (https://github.com/MediaArea/MediaInfoLib/commit/afd79f679ace1b27be429a4eb186c1cd383ca839#diff-5f9a9b29a1d4637c8efbb1291b6e0db6)).

summary: your "well known values" are not the "well known values" of some other people, and whatever I choose, someone will complain, this is not the first time and it will not be the last time, as MediaInfo is used by a lot of very different people in this industry, each "community" having different "well known value", when I choose a name I am sure another "community" will complain. I may add option "choose your community" in the future if people are crazy enough for paying for seeing their "well known values" instead of the ones I chose.

PS: bt2020nc means exactly "BT.2020 non-constant", I just show something more "readable", why should I limit the display to a limitation of the command line? I may use "codes" (short names without spaces) internally in the future, but nothing says that I would use x264/x265 choices vs other tools choices.

PPS: in an ideal world, everyone would speak the same language and everyone would use the same "well known values", unfortunately we are not in this ideal world so if you don't do any "translation", someone else will do the same remark about his need to have a translation between your values and his values.

[Atak_Snajpera]

Do you have a full list of "your well known codes" so I could translate them to "my well known codes" for x264/x265 use?
I just need to know that I pass correct codes to encoder. That's all.

[Zenitram]

Do you have a full list of "your well known codes" so I could translate them to "my well known codes" for x264/x265 use?
I just need to know that I pass correct codes to encoder. That's all.

Here (https://github.com/MediaArea/MediaInfoLib/blob/c4e2a397b924ed92302788eaf1c9a0b5571fde0e/Source/MediaInfo/Video/File_Mpegv.cpp#L33-L98) for MPEG related value, Here (https://github.com/MediaArea/MediaInfoLib/blob/b108dc5210607cda2232186df08930a5e5883115/Source/MediaInfo/Image/File_Dpx.cpp#L143-L180) for DPX values.

but right, definitely a need of better doc (not in code)

[Kurtnoise]

#MediaInfo users, we need some testers of #MediaInfoOnline technology preview.

MediaInfo in your browser, without installing any software and everything stays on your machine.

mediaarea.net/MediaInfoOnline

[Q-the-STORM]

#MediaInfo users, we need some testers of #MediaInfoOnline technology preview.

MediaInfo in your browser, without installing any software and everything stays on your machine.

mediaarea.net/MediaInfoOnline

what kind of testing do you need? Testing various files and comparing to local mediainfo output, or testing with various browsers, OS, etc...

Text output slightly differs from v17.12 in this line:

v17.12
Format settings, RefFrames

online
Format settings, ReFrames

[Zenitram]

what kind of testing do you need? Testing various files and comparing to local mediainfo output, or testing with various browsers, OS, etc...

testing with various browsers and report if something does not work, ideas for improvement...

Text output slightly differs from v17.12 in this line:

v17.12
Format settings, RefFrames

online
Format settings, ReFrames

Hum... old bug, should not be there anymore, we'll work on that, thanks.

[Q-the-STORM]

I tested a few more files just to see if I could find more differences, only found two:

I got an old folder with 8 calibration mp4s.
Online doesn't show x264 settings and nominal bitrate on 7 of them
https://www.diffchecker.com/oUUJHGmc
the 8th does correctly show x264 settings and nominal bitrate, it's the only one of them that is larger than 1MB, the rest are smaller than 1MB.

This one doesn't show source duration and Source stream size online
https://www.diffchecker.com/cgPO4RsV
though in this case source duration and duration are the same so it doesn't matter much, though it would be nice to have the exact same output online if possible.

I tested old youtube downloads, some old xvids, vobs from DVDs, some more recent x264 mkvs, hevc hdr video, TV recordings, and some more unusual video like vfr cellphone video, unusual framerates, various containers (mp4, mkv, ts, flv, m2ts), also besides video, some flac, mp3, png, gif and some other files, all had the same output as 17.12.

btw I'm using Win 10 + chrome x64

[Zenitram]

I tested a few more files just to see if I could find more differences, only found two

Thank you for the test, it is useful. Is it possible to get the file?

(...) though it would be nice to have the exact same output online if possible.

We agree! It is the goal.

[Q-the-STORM]

I sent you a PM with a link.

[Selur]

Small question about 'MasteringDisplay_ColorPrimaries', what to use for R, G, B, WP, when it only reports 'Display P3'?

[Atak_Snajpera]

Good question because there are two variants! Older version was reporting values for DCI-P3 D65. Now the same file is being detected as Display P3.

DCI-P3 D65 0.3127 0.3290 0.680 0.320 0.265 0.690 0.150 0.060
DCI-P3 Theater 0.314 0.351 0.680 0.320 0.265 0.690 0.150 0.060

[kolak]

These are 2 different standards.
1 is P3 with D65 white point, another is P3 DCI standard with different white point (this is rather not to be used with TVs, but DCI projectors).
It's either one or another in reality, they can't be both :)

[Selur]

Hoping that Zenitram can tell :)

[Zenitram]

These are 2 different standards.
1 is P3 with D65 white point, another is P3 DCI standard with different white point (this is rather not to be used with TVs, but DCI projectors).
It's either one or another in reality, they can't be both :)

This is what (D65 not associated with DCI) I understood too :)
There is definitely some debate about naming, and I guess it is not a closed topic, but what I understood is that "DCI-P3 D65" was misleading for some people (critisism of older version of MediaInfo), as DCI is associated to theaters (DCI = Digital Cinema Initiatives) and theater don't (IIUC) use D65.

So "Display P3", name used by Apple (https://developer.apple.com/videos/play/wwdc2017/821/), was prefered.

DCI-P3 D65 = SMPTE EG 432-1 = MPEG value 12 = Display P3 = Used by e.g. Apple
DCI-P3 Theater = SMPTE RP 431-2 = MPEG value 11 = "original" DCI P3 = used in theaters

values of R/G/B/WP for both were indicated by Atak_Snajpera, D65 (MPEG value 12) being used by "Display P3" in MediaInfo, the theater version (MPEG value 11) being "DCI P3" in MediaInfo.

[Selur]

D65 (MPEG value 12) being used by "Display P3" in MediaInfo, the theater version (MPEG value 11) being "DCI P3" in MediaInfo.
Thanks for that info!

[Atak_Snajpera]

There is definitely some debate about naming, and I guess it is not a closed topic,
Again. I would definitely prefer neutral SMPTE names being used everywhere if possible instead of names associated with some specific company (apple). They haven't invented this standard so why do we promote them?

[Zenitram]

They haven't invented this standard so why do we promote them?

I already answered (https://forum.doom9.org/showthread.php?p=1827770#post1827770).
Seriously, doing the difference between 431-2 and 432-1 is not fun for people. and SMPTE didn't invented it too (EG = Engineering Guidelines, RP = Recommanded Practice. None is ST = STandard, so your sentence is wrong when you use "standard").
It is not about Apple, it is about what users can easily read (also 1 of the reasons I prefer AVC/HEVC over H264/H265) and use (the choice was made from a discussion with users).

I will always have some people angry with naming, whatever I choose, this time it is your turn, that's all.

If there are enough people angry with such naming and ready to sponsor the option, I have no problem to develop an option (or config file) for outputting different names (not only for colors, also for e.g. formats, I have such kind of discussion from day 1 of MediaInfo) or just technical things (for colors: the formulas or raw coordinates?).

Note that I don't close the discussion, but I listen to all arguments (not only the ones here), I need more convincing arguments for changing back / modifying default output.

[nevcairiel]

It is not about Apple, it is about what users can easily read

If thats your primary motiviation, then using "Display P3" is utterly pointless. I'm a user and I have no idea that this refers to (since I don't interact with Apple at all, I also don't know their odd choices in naming) what I know as DCI P3 D65. Why not call it "DCI P3 D65" and "DCI P3 Theater", that clearly communicates the two different DCI P3 variants.

[Atak_Snajpera]

"Display P3" means nothing if I can't easily find color space parameters like with "DCI P3 D65". You are trying hard to invent a wheel again with those "friendly commercial names" (apples's Display P3). x265 documentation also uses "P3 D65" name.


--master-display <string>

SMPTE ST 2086 mastering display color volume SEI info, specified as a string which is parsed when the stream header SEI are emitted. The string format is “G(%hu,%hu)B(%hu,%hu)R(%hu,%hu)WP(%hu,%hu)L(%u,%u)” where %hu are unsigned 16bit integers and %u are unsigned 32bit integers. The SEI includes X,Y display primaries for RGB channels and white point (WP) in units of 0.00002 and max,min luminance (L) values in units of 0.0001 candela per meter square. Applicable for HDR content.

Example for a P3D65 1000-nits monitor, where G(x=0.265, y=0.690), B(x=0.150, y=0.060), R(x=0.680, y=0.320), WP(x=0.3127, y=0.3290), L(max=1000, min=0.0001):

G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)

Note that this string value will need to be escaped or quoted to protect against shell expansion on many platforms. No default.

[Zenitram]

(...) with some specific company (apple). They haven't invented this standard so why do we promote them?

Having arguments based on "alternative facts" does not help to convince, it actually makes some people like me (liking real facts) angry when such error is discovered.
https://developer.apple.com/documentation/coregraphics/cgcolorspace/1408916-displayp3
"The name of the Display P3 color space, created by Apple Inc. This color space uses the DCI P3 primaries, a D65 white point, and the same gamma curve as the sRGB color space."

Looking for DCI documents (not Wikipedia links) indicating that this is "standadized" on DCI side.

If thats your primary motiviation, then using "Display P3" is utterly pointless. I'm a user and I have no idea that this refers to

Sorry but you are not my only user and some other don't know "DCI P3 D65", if I make you happy I make others unhappy, why should I prioritize you and not others?
This is not an argument, if you want to convince please argue in a better way, less centered on 1 person only.

x265 documentation

I already answered to such argument (summary: x265 is one side, there are others), and you don't take in account my answers, so it is a bit frustrating and does not help.

I stop here as this is not a constructive debate.

[nevcairiel]

Sorry but you are not my only user and some other don't know "DCI P3 D65", if I make you happy I make others unhappy, why should I prioritize you and not others?
This is not an argument, if you want to convince please argue in a better way, less centered on 1 person only.

The only important argument is that this is the official name. DCI-P3 D65, as defined by the Digital Cinema Initiatives, and standardized/published by SMPTE. Any other names are aliases invented by specific vendors.

The argument you listed with how people were confused with the old name is also quite "me" centric on those users, isn't it? Double standards? Its a simple fact that both are called DCI-P3, one for D65 and one for Theater. There is no confusion.

[Atak_Snajpera]

I already answerd to such argument (summary: x265 is one side, there are others), and you don't take in account my answers, so it is a bit frustrating and does not help.

Yeah let's forget about huge base of users using x264/x265/ffmpeg libraries with those well recognized names.
http://i.cubeupload.com/UA1noc.png

Having arguments based on "alternative facts" does not help to convince, it actually makes some people like me (liking real facts) angry when such error is discovered.
https://developer.apple.com/document...8916-displayp3
"The name of the Display P3 color space, created by Apple Inc. This color space uses the DCI P3 primaries, a D65 white point, and the same gamma curve as the sRGB color space."

Just another alias for DCI-P3 D65. That's it! Has apple contributed to DCI-P3 specification? It looks like another corporation trying to promote own fancy names. Nothing new here.

[Zenitram]

Yeah let's forget about huge base of users using x264/x265/ffmpeg libraries with those well recognized names.

Again "alternative facts" with "well recognized names"...
You think that x264/x265/FFmpeg are the center of the universe, this is your right to lie to yourself, I just inform you that arguing with such mistake (e.g I already said that "PQ" was requested by a sponsor from the industry who uses this wording and not the SMPTE number whose he does not understand) will not help to convince me that you suggest the right names to use in MediaInfo (MediaInfo is used by a lot of users who have never heard about x264/x265/FFmpeg). Note also that MediaInfo can live only due to sponsoring and sponsors have a priority (not a veto right, but I also listen to them) and most of sponsors really don't care at all of a "it is used by FFmpeg" argument.

BTW, you did not source your arguments, and I did not find something about "P3" in DCI specs (http://dcimovies.com/specification/DCI_DCSS_v12_with_errata_2012-1010.pdf) (and erratas (http://www.dcimovies.com/specification/index.html)), as you know that it is DCI I think it would be easy for you to link to the corresponding docs and pages, it would help in an objective debate.

If you are interested in being constructive, please argue in an objective manner, respecting different points of view, instead of just trolling without listen to arguments from people not agreeing with you and not having the same priorities as you.
I spent too much time in trying to explain that there are different communities using MediaInfo and that you are not the only ones, if such fact is not accepted I don't see a reason to keep trying to debate based on wrong assumptions (here I spent most of my time to explain basic things like communities, which prevents to focus on a good debate)

[Atak_Snajpera]

Just use DCI-P3 D65 and Theater for god sake! Why do you have to ride on apples's d$%k in this case? Was that also a sponsored decision to use "Display P3"?
If yes then i'm ok with your decision.

[wiggaz]

Are we still with this Display P3 nonsense ? :(

[Zenitram]

Are we still with this Display P3 nonsense ? :(

"nonsense" for you does not mean nonsense for other people.
Are we still with such "argument"?

[wiggaz]

The previous method was clear, all the values were display and understandable. If necessary, they were usable to who encodes and who doesn't. Now we should take reference to other documents to acknoledge them.
I really don't understand the benefit of this.

[PCU]

please support this format too: Bink Video - The Video Codec for Games
http://www.radgametools.com/bnkmain.htm

[LoRd_MuldeR]

I'm using MediaInfo with XML output to analyze media files and extract the cover artwork.

But, unfortunately, I noticed that latest MediaInfo (v18.03.1) does not output <Cover_Data> tag anymore, even with --Full option set :eek:

I suspect this has something to do with:
Attachments: do not provide anymore attachments content in XML by default, reducing XML output size

What CLI option do I have to set to get the cover data again? :confused:

:thanks:

[Zenitram]

I'm using MediaInfo with XML output to analyze media files and extract the cover artwork.

But, unfortunately, I noticed that latest MediaInfo (v18.03.1) does not output <Cover_Data> tag anymore, even with --Full option set :eek:

I suspect this has something to do with:


What CLI option do I have to set to get the cover data again? :confused:

:thanks:

Right, I removed the presence of cover data by default, as it is not often used and make MediaInfo creating big XML files and with some (little) performance impact by default.

But it definitely lacks of documentation about how to active it, [documentation is on my ToDo-list](https://mediaarea.net/Vote/Mediainfo-Usage-Documentation-127).

Magic hidden setting: add " --Cover_Data=base64" (or MediaInfo::Option("Cover_Data", "base64").

As usual when there are lot of users, a change in default value has some impact on a couple of users :(, sorry for that.

[LoRd_MuldeR]

But it definitely lacks of documentation about how to active it, [documentation is on my ToDo-list](https://mediaarea.net/Vote/Mediainfo...umentation-127).

Yeah, writing documentation is pain. Not only it takes a whole lot of time (if you want to do it properly), it tends to be outdated the very next day ;)

Magic hidden setting: add " --Cover_Data=base64" (or MediaInfo::Option("Cover_Data", "base64").

Thanks for the quick reply. That works like a charm! :)

As usual when there are lot of users, a change in default value has some impact on a couple of users :(, sorry for that.

No problem. I understand why the "new" default makes sense for most use-cases. And with the "magic setting" all is good for my use-case.

[Selur]

@Zenitram: Small follow-up question regarding 'Mastering display color primaries'. :)
So far we know that

'Display P3' <> 'DCI-P3 D65' <> 'R(x=0.680, y=0.320), G(x=0.265, y=0.690), B(x=0.150, y=0.060), White point(x=0.3127, y=0.3290)'
'DCI P3' <> 'DCI-P3 Theater' <> 'R(x=0.680, y=0.320), G(x=0.265, y=0.690), B(x=0.150, y=0.060), White point(x=0.314, y=0.3510)'

But now I encountered a source where 'Mastering display color primaries' just states 'BT.2020'.
What values does this refer to?
Also are there other constants used?

Cu Selur

[Zenitram]

But now I encountered a source where 'Mastering display color primaries' just states 'BT.2020'.
What values does this refer to?

From H.265 specs:
Rec. ITU-R BT.2020-2
primary x y
green 0.170 0.797
blue 0.131 0.046
red 0.708 0.292
white D65 0.3127 0.3290

Also are there other constants used?

For the moment, no more values are mapped, but hypothetically all values from H.265 (and more) could be mapped.

[Selur]

Thanks! :)

[Murvel]

Thanks for a great app.

I use it sometimes to compare different edits of the same clip, and I think it would be helpful if the app would always report the exact duration of a clip, down to seconds or even frames. As of now, you see duration in seconds for shorter clips only, whereas hours and minutes is all you see for longer clips.

Thanks again.

[LoRd_MuldeR]

Thanks for a great app.

I use it sometimes to compare different edits of the same clip, and I think it would be helpful if the app would always report the exact duration of a clip, down to seconds or even frames. As of now, you see duration in seconds for shorter clips only, whereas hours and minutes is all you see for longer clips.

Thanks again.

Try with options --Full and --Language=raw, which should give you output like this:
.\mediainfo.i686.exe --Full --Language=raw "C:\Path\to\Movie.mkv"
General
[...]
Duration : 5764920
Duration/String : 1h 36mn
Duration/String1 : 1h 36mn 4s 920ms
Duration/String2 : 1h 36mn
Duration/String3 : 01:36:04.920
Duration/String4 : 01:36:04:23
Duration/String5 : 01:36:04.920 (01:36:04:23)
[...]

Or, alternatively, use --Output=XML option:
.\mediainfo.i686.exe --Output=XML "C:\Path\to\Movie.mkv"
<?xml version="1.0" encoding="UTF-8"?>
<MediaInfo
xmlns="https://mediaarea.net/mediainfo"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="https://mediaarea.net/mediainfo https://mediaarea.net/mediainfo/mediainfo_2_0.xsd"
version="2.0">
<creatingLibrary version="18.05" url="https://mediaarea.net/MediaInfo">MediaInfoLib</creatingLibrary>
[...]
<FileSize>4334673157</FileSize>
<Duration>5764.920</Duration>
[...]

[Zenitram]

Dear MediaInfo users (and developers!),

Due to the increasing complexity, while keeping compatibility with legacy decoders, of audio formats, the way MediaInfo was displaying audio related information was worse and worse.
This was actually becoming difficult when we implement a better support of E-AC-3 in Bluray (mixed with core AC-3) and also Atmos (can be in E-AC-3, or TrueHD, TrueHd may be mixed with AC-3 or alone...), and DTS-HD features were not well displayed enough.

We change how we display formats with support of legacy decoders:
- the Format line in the text output contains now the name of the base format + list of features needed for outputting the best result.
- the "Format" field in XML or API (or "full" text output) contains the base format, "Format_AdditionalFeatures" field in XML or API contains the list of features, "Format/String" for the sum of both.
- Note that there are sometimes some differences between "Format/String" and the 2 other fields for commercial reasons.
- "Profile" field has changed for AAC, now contains the profile/level as found in MP4_IOD_Tag MP4 descriptor.
- We don't display anymore by default information about how legacy decoders would play the file.
- We change the way we display channel layout, with a list of channels. The previous method was not sustainable with the incoming 3D audio (16 or 24 channels). Note that issue with having channel names is that each format stipulates different channel names, we listed the mapping we do at https://mediaarea.net/AudioChannelLayout . Channel layout names will be in MediaInfo 18.08 and above, with a list ordered by the expected output order from the decoder, the former method is still available with "full" text, XML or API (list is ordered by "layer" so comparison is doable between formats, but similar channels have the same name and/or it is not well implemented, be careful with this field if you work with 16- or 24-channel content)
- We do the difference between technical name and the marketing name, e.g. "E-AC-3 JOC" for Dolby Atmos in E-AC-3, "MLP FBA" for TrueHD and "MLP FBA 16ch" for Atmos in TrueHD.
- We support now the channel configuration and the count of objects in an Atmos stream, either in E-AC-3 or TrueHD. But we don't "merge" the Atmos channels in the core channel count, we display Atmos channel info in separate fields.

Example of new output with a Dolby Atmos "9.1.4" stream with 1 dynamic object:


Audio
Format : E-AC-3 JOC
Format/Info : Enhanced AC-3 with Joint Object Coding
Commercial name : Dolby Digital Plus with Dolby Atmos
Bit rate mode : Constant
Bit rate : 448 kb/s
Channel(s) : 6 channels
Channel layout : L R C LFE Ls Rs
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Compression mode : Lossy
Service kind : Complete Main
Number of dynamic objects : 1
Bed channel count : 14 channels
Bed channel configuration : L R C LFE Ls Rs Lb Rb Tfl Tfr Tbl Tbr Lw Rw

Most of changes are reversible through options (" --File_HighestFormat=0 --File_ChannelLayout=0 --LegacyStreamDisplay=1" on the command line) but I hope that these option are used not so much.

We would like that you test the development snapshots at https://mediaarea.net/download/snapshots/binary/mediainfo-gui/ and also check the channel layout mapping at https://mediaarea.net/AudioChannelLayout ; due to sponsors behind these changes (they have priority), we will not change a lot the output but we would like to anticipate issues and bugs for advanced users like people here before we do a more public release.

[manolito]

As already announced by Zenitram, the latest version 18.08 breaks compatibility with most (if not all) third party software which uses MediaInfo. AVStoDVD for example can neither recognize video nor audio formats with this latest version.

This means that software which is still maintained will have to be updated to become compatible with the new MediaInfo output. For older applications which are no longer developed users have no choice but sticking with version 18.05.


Cheers
manolito

[Zenitram]

For older applications which are no longer developed users have no choice but sticking with version 18.05.

If there is some demands I could release a specific version of the DLL with the old behavior activated by default so new formats and bug fixes can be used with old apps, else for the lazy developers it is just the options above (but I recommend to adapt the tool to the new fields as it is a more detailed nd more future proof).

AVStoDVD for example can neither recognize video nor audio formats with this latest version.

Wondering a bit how the API was used, as most old fields stay as is (maybe except for AAC) when called from the API e.g. "Format" field for AC-3, E-AC-3 or DTS are same. Anyway, true that this is possible, apologizes for this but this is really something I don't do often, and here it was something I had to do at some point for making some sponsors happy and prepare the future (I bet that this will be even more complex formats and hacks in the formats).

[manuelin]

Hello Zenitram, thank you very much for the new version with so many changes.

One question, would it be possible for the next version to re-enable all the parameters that show information about all the audios and not only the main one?
I explain:

Before:
Audio #1
ID : 2
Formato : DTS
Formato/Info : Digital Theater Systems
Formato del perfil : MA / Core
ID códec : A_DTS
Duración : 1 h 26 min
Tipo de tasa de bits : Variable / Constante
Tasa de bits : 2 860 kb/s / 1 509 kb/s
Canal(es) : 8 canales / 6 canales
Posiciones del canal : Front: L C R, Side: L R, Back: L R, LFE / Front: L C R, Side: L R, LFE
Velocidad de muestreo : 48,0 kHz
Velocidad de fotogramas : 93,750 FPS (512 SPF)
Profundidad bits : 16 bits
Modo de compresión : Sin pérdida / Lossy
Tamaño de pista : 1,72 GiB (4%)
Título : Castellano DTS-HD MA 7.1 @ 2860 Kbps
Idioma : Español
Default : Sí
Forced : No

Now:
Audio #1
ID : 2
Formato : DTS XLL
Formato/Info : Digital Theater Systems
Nombre comercial : DTS-HD Master Audio
ID códec : A_DTS
Duración : 1 h 26 min
Tipo de tasa de bits : Variable
Tasa de bits : 2 860 kb/s
Canal(es) : 8 canales
Channel layout : C L R LFE Lb Rb Lss Rss
Velocidad de muestreo : 48,0 kHz
Velocidad de fotogramas : 93,750 FPS (512 SPF)
Profundidad bits : 16 bits
Modo de compresión : Sin pérdida
Tamaño de pista : 1,72 GiB (4%)
Título : Castellano DTS-HD MA 7.1 @ 2860 Kbps
Idioma : Español
Default : Sí
Forced : No

I have marked in bold two examples, although there are more, but I think those 2 are some of the most important.


In short, before you could see the information of the main audios and also the core/embedded, now only the main.

And that previously worked very well to be able to see if the audio contained core/embedded, and also to be able to see its corresponding bitrate.


Thank you very much!
Regards ;)

[Zenitram]

One question, would it be possible for the next version to re-enable all the parameters that show information about all the audios and not only the main one?


In the last years I got lot of complains about the presence of too much information, now I have a request to provide more information :).
I was liking to provide info about the core stream but some sponsors (in addition to several users complaining about a non understandable output) were disliking that and they have priority. Maybe in the future such information will come back by default (in a different display? Possible, the previous one is considered too weird by several people).

For CLI and DLL, this is possible to revert to previous behavior by using the options (in the post above).
For GUI, we plan to have options but this is not the priority right now, you can vote for prioritizing options in the GUI (https://mediaarea.net/Vote/Mediainfo-Gui-Display-Options-184)

[Megalith]

If MediaInfo doesn't show a field regarding dialnorm, is it safe to assume the audio track/s do not have dialnorm applied? I thought that dialnorm couldn't be removed from DTS-HD MA tracks, though...

[Zenitram]

If MediaInfo doesn't show a field regarding dialnorm, is it safe to assume the audio track/s do not have dialnorm applied? I thought that dialnorm couldn't be removed from DTS-HD MA tracks, though...

No.
It is safe to assume that the field is not present in the stream or that analysis is not implemented.

For dialnorm in DTS / DTS-HD MA, it is the second possibility.

[Murvel]

Try with options --Full and --Language=raw, which should give you output like this:
.\mediainfo.i686.exe --Full --Language=raw "C:\Path\to\Movie.mkv"
General
[...]
Duration : 5764920
Duration/String : 1h 36mn
Duration/String1 : 1h 36mn 4s 920ms
Duration/String2 : 1h 36mn
Duration/String3 : 01:36:04.920
Duration/String4 : 01:36:04:23
Duration/String5 : 01:36:04.920 (01:36:04:23)
[...]

Or, alternatively, use --Output=XML option:
.\mediainfo.i686.exe --Output=XML "C:\Path\to\Movie.mkv"
<?xml version="1.0" encoding="UTF-8"?>
<MediaInfo
xmlns="https://mediaarea.net/mediainfo"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="https://mediaarea.net/mediainfo https://mediaarea.net/mediainfo/mediainfo_2_0.xsd"
version="2.0">
<creatingLibrary version="18.05" url="https://mediaarea.net/MediaInfo">MediaInfoLib</creatingLibrary>
[...]
<FileSize>4334673157</FileSize>
<Duration>5764.920</Duration>
[...]

Thanks for the suggestion, but I know of no way to accomplish this for the following (and most common?) scenario: The way I launch MediaInfo is I use Windows Explorer, in which I browse to the video file, right-click it, and in the context menu I click MediaInfo. The program launches and displays the properties for the video in question. If there's a way to inject your options to there, that would be a done deal, but I'd like to know how.

[Zenitram]

If there's a way to inject your options to there

Not yet implemented in the GUI. You can prioritize the feature if you are interested in it (https://mediaarea.net/Vote/Mediainfo-Gui-Display-Options-184) .

[Selur]

Small question latest version shows Width, Height, Stored_Width, Stored_Height, Sampled_Width, Sampled_Height, what is their relationship and how does it relate to the 'old' 'Original Width' and 'Original Height'?

[Zenitram]

Small question latest version shows Width, Height, Stored_Width, Stored_Height, Sampled_Width, Sampled_Height, what is their relationship and how does it relate to the 'old' 'Original Width' and 'Original Height'?

"Original XXX" is for when there is a conflict between 2 info which should be same but are not (container vs stream).

For the others, they are completely different values. in short:
- "Stored XXX" is what is stored in the stream i.e. before cropping, usually different than XXX when you use non multiples of 16 (e.g. AVC can not compress 1080 lines, it compresses 1088 lines and crop 8 lines, so height is 1080 and stored height is 1088. Stored height is very important for hardware limits, because in that case the HW mus support 1088 lines even if only 1080 are shown). Some streams are a bit crazy, e.g. they are encoded with 1120 lines with cropping to 1080, and an HW limited to 1088 lines will fail to decode this "fake" 1080 line stream.
- "Sampled XXX" was a tentative for something from 1 customer, not relevant, discard it for the moment (I may remove it in the future, nobody would cry for this field IMO). Should be now more or less similar to "XXX" alone (was more useful when there was no "clean aperture" metadata).
- "Clean aperture XXX" is the clean aperture size i.e. what is expected to be good enough, just a piece of metadata from the container relevant to people who know what clean aperture is.

[qyot27]

There seems to be some kind of character limit/buffer issue in the CLI when trying to display --info-parameters:

E:\Documents\MediaInfo_CLI_18.08.1_Windows_x64>mediainfo --version
MediaInfo Command line,
MediaInfoLib - v18.08.1

E:\Documents\MediaInfo_CLI_18.08.1_Windows_x64>mediainfo --info-parameters | grep colour
colour_range : Colour range for YUV colour space
colour_description_presen : Presence of colour description
colour_primaries : Chromaticity coordinates of the source primaries
colour_description_presen : Presence of colour description
colour_primaries_Original : Chromaticity coordinates of the source primaries
colour_description_presen : Presence of colour description
colour_primaries : Chromaticity coordinates of the source primaries
colour_description_presen : Presence of colour description
colour_primaries_Original : Chromaticity coordinates of the source primaries
There's no way to be able to know what those fields are supposed to be, because of the truncation. Also, why are those HDR-related fields in lower-case? Does that mean they're not supposed to be public options?

I've seen this occur with both the official build, but with my own (GCC 8.2.0, MinGW-w64 6.0.0) build as well.

[danissimo]

Is it possible to add Escape key as the shortcut for closing MediaInfo window?
Thank You.

[Selur]

mediaarea.net/MediaInfoOnline <- any plans to show 'full' data?

Any plans to support HDR-10+ HEVC files?
(I can create HDR10+ files using x265 and verify that the file contains HDR-10+ metadata using hdr10plus_parser, sadly mediainfo doesn't show any hints about the HDR-10+ data atm.)

Cu Selur

[Zenitram]

mediaarea.net/MediaInfoOnline <- any plans to show 'full' data?

I didn't think it is useful and I saw no interest on my side, but if it is it should not be long to implement (note: at some point I may decide to offer options only to MediaArea members (https://mediaarea.net/SupportUs/Individual)).

Any plans to support HDR-10+ HEVC files?

Provide files please.
I was not finding HDR10+ specs, but as hdr10plus_parser is open source it should be easy to understand the new metadata parts.

[Selur]

Provide files please.
My GoogleDrive (https://drive.google.com/open?id=1-PymgpSkhvYs2XmiAbX82ySLdknMPaGC) contains a HDR-10+ mp4 file I created from another file and HDR-10+ json data, hope that helps.

[Zenitram]

Any plans to support HDR-10+ HEVC files?

OK, I was motivated, I started something (https://github.com/MediaArea/MediaInfoLib/pull/1088), without being sure about what would be interesting to show e.g. only HDR10+ presence?

For the moment (work in progress, can change in the future), MediaTrace (https://mediaarea.net/MediaTrace) dump is

0006733 sei (62 bytes)
0006733 Header (6 bytes)
0006733 size: 58 (0x0000003A)
0006737 nal_unit_type: 39 (0x27) - (6 bits)
0006737 nuh_layer_id: 0 (0x00) - (6 bits)
0006738 nuh_temporal_id_plus1: 1 (0x1) - (3 bits)
0006739 sei message - user_data_registered_itu_t_t35 - SMPTE ST 2094 App 4 (51 bytes)
0006739 sei message header (2 bytes)
0006739 payload_type_byte: 4 (0x04)
000673A payload_size_byte: 49 (0x31)
000673B itu_t_t35_country_code: 181 (0xB5)
000673C terminal_provider_code: 60 (0x003C)
000673E terminal_provider_oriented_code_message_idc: 1 (0x0001)
0006740 application_identifier: 4 (0x04)
0006741 application_version: 1 (0x01)
0006742 num_windows: 1 (0x1) - (2 bits)
0006742 targeted_system_display_maximum_luminance: 0 (0x0000000) - (27 bits)
0006745 targeted_system_display_actual_peak_luminance_flag: No
0006745 window (38 bytes)
0006745 max_luminance_r: 0 (0x00000) - (17 bits) - 0.00000 cd/m2
0006747 max_luminance_g: 0 (0x00000) - (17 bits) - 0.00000 cd/m2
000674A max_luminance_b: 0 (0x00000) - (17 bits) - 0.00000 cd/m2
000674C avg_luminance: 233 (0x000E9) - (17 bits) - 0.00233 cd/m2
000674E num_distribution_maxrgb_percentiles: 9 (0x9) - (4 bits)
000674E distribution_maxrgb - 1 (0x1) - 0 (0x0) (3 bytes)
000674E distribution_maxrgb_percentile: 1 (0x01) - (7 bits)
000674F distribution_maxrgb_data: 0 (0x00000) - (17 bits)
0006751 distribution_maxrgb - 5 (0x5) - 6886 (0x1AE6) (3 bytes)
0006751 distribution_maxrgb_percentile: 5 (0x05) - (7 bits)
0006752 distribution_maxrgb_data: 6886 (0x01AE6) - (17 bits)
0006754 distribution_maxrgb - 10 (0xA) - 88 (0x58) (3 bytes)
0006754 distribution_maxrgb_percentile: 10 (0x0A) - (7 bits)
0006755 distribution_maxrgb_data: 88 (0x00058) - (17 bits)
0006757 distribution_maxrgb - 25 (0x19) - 0 (0x0) (3 bytes)
0006757 distribution_maxrgb_percentile: 25 (0x19) - (7 bits)
0006758 distribution_maxrgb_data: 0 (0x00000) - (17 bits)
000675A distribution_maxrgb - 50 (0x32) - 146 (0x92) (3 bytes)
000675A distribution_maxrgb_percentile: 50 (0x32) - (7 bits)
000675B distribution_maxrgb_data: 146 (0x00092) - (17 bits)
000675D distribution_maxrgb - 75 (0x4B) - 412 (0x19C) (3 bytes)
000675D distribution_maxrgb_percentile: 75 (0x4B) - (7 bits)
000675E distribution_maxrgb_data: 412 (0x0019C) - (17 bits)
0006760 distribution_maxrgb - 90 (0x5A) - 858 (0x35A) (3 bytes)
0006760 distribution_maxrgb_percentile: 90 (0x5A) - (7 bits)
0006761 distribution_maxrgb_data: 858 (0x0035A) - (17 bits)
0006763 distribution_maxrgb - 95 (0x5F) - 1583 (0x62F) (3 bytes)
0006763 distribution_maxrgb_percentile: 95 (0x5F) - (7 bits)
0006764 distribution_maxrgb_data: 1583 (0x0062F) - (17 bits)
0006766 distribution_maxrgb - 99 (0x63) - 4170 (0x104A) (3 bytes)
0006766 distribution_maxrgb_percentile: 99 (0x63) - (7 bits)
0006767 distribution_maxrgb_data: 4170 (0x0104A) - (17 bits)
0006769 fraction_bright_pixels: 0 (0x000) - (10 bits)
000676B mastering_display_actual_peak_luminance_flag: No
000676B window (0 bytes)
000676B color_saturation_mapping_flag: No

and MediaInfo output is:
Format : HEVC
Format/Info : High Efficiency Video Coding
Commercial name : HDR10+
Format profile : Main 10@L5@Main
Codec ID : hev1
Color range : Limited
Matrix coefficients : BT.709
HDR_Format : SMPTE ST 2094 App 4 version 1

With Dolby Vision, SL-HDR, HDR10, and now HDR10+, it becomes messy and not coherent (no common field name for the same stuff, too many lines dedicated to HDR), I am thinking to how I can improve the output for having something coherent between all HDR formats.

[Selur]

don't forget HLG :)
HDR-10, HDR-10+, Dolby Vision and HLG are probably the HDR formats to encounter.

[XinHong]

I'm trying to get the audio "Commercial name" field through the MediaInfo dll with this file: https://we.tl/O0BfDADZbu

MediaInfo gives me:

ID : 2
Format : MLP FBA
Format/Info : Meridian Lossless Packing FBA
Commercial name : Dolby TrueHD
Codec ID : A_TRUEHD
Duration : 11 s 11 ms
Bit rate mode : Variable
Maximum bit rate : 6 423 kb/s
Channel(s) : 8 channels
Channel layout : L R C LFE Ls Rs Lb Rb
Sampling rate : 48.0 kHz
Frame rate : 1 200.000 FPS (40 SPF)
Compression mode : Lossless
Language : English
Default : Yes
Forced : No


But when I check the "Commercial Name" field I have only "TrueHD" instead of "Dolby TrueHD"

I'm using this request, is it right ?
MediaInfo_Get(Handle, Stream_Audio, StreamID, 'Format_Commercial', Info_Text, Info_Name)

Thanks

[Selur]

@Zenitram: When does MediaInfo report an jpg as Video and when as Image?
I got a folder with 431 images and when I analyse for example image 00001.jpg it's reported as Video, same for 00401.jpg but 004009.jpg and upwards is only reported as Image.
-> this really is a pain, is there a way to force detecting jpg always as Image or Video ?

[Zenitram]

Any plans to support HDR-10+ HEVC files?

Suffering a bit with all the HDR metadata I have to handle.
Now moving to a dedicated line for HDR format.

Below are some examples of the expected line for HDR10 (actually SMPTE ST 2086), HDR10+ (actually SMPTE ST 2094-40 with lot of restrictions, I finally got the specs so I have the exact restrictions), Dolby Vision, SL-HDR (1&2), any potential issues you see?

HDR format : SMPTE ST 2086, HDR10 compatible
HDR format : SMPTE ST 2094-40, Version 1, HDR10+ Profile A compatible
HDR format : Dolby Vision, Version 1.0, dvhe.04.06, BL+EL+RPU
HDR format : SL-HDR1, Version 1.0, Parameter-based, constant
HDR format : SL-HDR1, Version 1.0, Parameter-based, non-constant
HDR format : SL-HDR2, Version 0.0, Parameter-based


Notes:
- HLG is not listed as it is not additional metadata, "just" a specific transfer characteristics.
- HDR10 & HDR10+ are actually commercial names, but other HDR formats have no difference between technical and commercial name (SL-HDR is listed in ETSI 103-433 but they stipulate the name in specs as they do with e.g AC-3 in ETSI 102-366) so I think it is not good to add a new line for HDR format commercial name, to be debated.
- HDR10 & HDR10+ are listed also if other constraints are met e.g. PQ transfer characteristics.
- I have constraints from sponsors so I'll not able to accept all advice even if I want to.

[Zenitram]

But when I check the "Commercial Name" field I have only "TrueHD" instead of "Dolby TrueHD"

I have it fine when I test with latest DLL and the C++ interface (C++ interface should not change the content of the field compared to the programming language you use) so I don't plan to investigate more.

[Zenitram]

@Zenitram: When does MediaInfo report an jpg as Video and when as Image?

IIRC 24 images with file names in a sequence (001, 002... 024), still activated by default because lot of my sponsors use that in their video workflow (yeah, 1 file per frame...) and more and more camera stops to use such file naming and replace them by the date/time. For the moment there is no decision to change the default behavior.

is there a way to force detecting jpg always as Image or Video ?

MediaInfo --File_TestContinuousFileName=0 YourFileName.ext
(doable also with API with MediaInfo::Option())

[Selur]

Thanks for the info :)

[stax76]

@Zenitram

I just want to let you know that I use MediaInfo in my recent project mpv.net (a media player for Windows) and there wasn't any problems and I don't remember any problems using it in staxrip all the years, it's fast and reliable. In staxrip it's used in countless locations, in mpv.net it is used to show some on screen info and to show info in the context menu.

https://postimg.cc/t1NGJF1z

https://github.com/stax76/mpv.net#context-menu

https://github.com/stax76/mpv.net#architecture

thanks, danke, merci! :thanks:

[mariner]

HLG support

Greetings.
The Japan Geographic youtube channel is now playing ARIB STD-B67 encoded streams. Other channels use PQ encoding. But mediainfo only show vp92 for the downloaded clips. Can such info be added in future versions?
Many thanks and best regards,

[Aleksoid1978]

HLG support

Greetings.
The Japan Geographic youtube channel is now playing ARIB STD-B67 encoded streams. Other channels use PQ encoding. But mediainfo only show vp92 for the downloaded clips. Can such info be added in future versions?
Many thanks and best regards,

Can you give a link for this channel.

[mariner]

JAPAN GEOGRAPHIC
https://www.youtube.com/channel/UCoqBrV0_SEIUbwdAfYnAk2g/videos

[Selur]

Since when and why did mediainfo change reporting TrueHD combi stream as
Format : TrueHD / AC-3
and switched to:
Format : AC-3
and how to know whether a stream is 'AC-3' or 'TrueHD / AC-3' ?

Cu Selur

[stax76]

Since when and why did mediainfo change reporting TrueHD combi stream as

It probably happened when the major version changed from 18 to 19.

[Asmodian]

and how to know whether a stream is 'AC-3' or 'TrueHD / AC-3' ?


Unlike a DTS core the AC-3 tracks in these streams are simply AC-3 tracks, there is nothing different about them. It really is just a second audio track muxed into the file along with the TrueHD one so it is better to report them that way. You can rip the AC-3 out and only have the TrueHD track or vice-versa.

[Zenitram]

Since when and why did mediainfo change reporting TrueHD combi stream as
Format : TrueHD / AC-3
and switched to:
Format : AC-3
and how to know whether a stream is 'AC-3' or 'TrueHD / AC-3' ?


There was a big change last year in how to present AC-3 / E-AC-3 / TrueHD streams.

For pure TrueHD, they are listed now as:


Format : MLP FBA
Format/Info : Meridian Lossless Packing FBA
Commercial name : Dolby TrueHD


"MLP FBA" is the technical name preferred by Dolby Inc for naming this technology, and we list "TrueHD" as the commercial name now.

For interleaved TrueHD / AC-3, looks like we forgot this case while moving to the new display, I need to find a good way for displaying it. At whatever is the outcome, one thing sure is that MLP FBA should be displayed, the "best" stream should be listed for sure (here MLP FBA over AC-3 because lossless is better than lossy).

[Zenitram]

ARIB STD-B67 [...] PQ [...] But mediainfo only show vp92 for the downloaded clips

vp92 is not on the same line as ARIB STD-B67 or PQ, so misleading report.
I guess that you mean that "vp92" files (actually "VP9" content, I guess, and vp92 is just not recognized by MediaInfo so displayed as is) don't have transfer_characteristics related info.

Please provide a file (not a link to a youtube channel page).
If I read well the VP9 spec (https://www.webmproject.org/vp9/#hdr10-metadata-handling), HDR10+ info is in the container (WebM) and it would be relevant for me to support that (WebM still used by Google), currently it is not supported (looks like they don't use the same method than Matroska), but if it is in the VP9 bitstream I would be less motivated (VP9 is abandoned in favor of AV1...)

[SeeMoreDigital]

"MLP FBA" is the technical name preferred by Dolby Inc for naming this technology, and we list "TrueHD" as the commercial name now.I wonder why Dolby went for that?!

I recently found this Dolby TrueHD high-level bitstream description - Dolby Developer (https://developer.dolby.com/globalassets/technology/dolby-truehd/dolbytruehdhighlevelbitstreamdescription.pdf) [.pdf file] documentation but I can't seem to find out what FBA stands for...

[Zenitram]

I can't seem to find out what FBA stands for...

You see in that doc "referred to in this document as the FBA syntax." ;-)

FBA and FBB are the last 12 bits of the magic sync value (0xF8726FBA / 0xF8726FBB).
IIUC FBB syntax is the first one (before Dolby buys Meridian Audio (https://en.wikipedia.org/wiki/Meridian_Audio) related technology) then Dolby updated the bistream syntax and has set FBA instead of FBB in the magic value for their version.

I don't have access to Meridian FBB spec, so difficult to know the exact purpose of the modified bit (was it planned or not? ...), but I was said that technical people working on MLP use the "FBA" term for speaking about the Dolby version.

[-QfG-]

Small question about 'MasteringDisplay_ColorPrimaries', what to use for R, G, B, WP, when it only reports 'Display P3'?

The only solution i know for100% correct values is to index the file with DGIndexNV and look at the MASTERING Line. Problem, you need a Nvidea GTX 1050 or higher.

[mariner]

vp92 is not on the same line as ARIB STD-B67 or PQ, so misleading report.
I guess that you mean that "vp92" files (actually "VP9" content, I guess, and vp92 is just not recognized by MediaInfo so displayed as is) don't have transfer_characteristics related info.

Please provide a file (not a link to a youtube channel page).
If I read well the VP9 spec (https://www.webmproject.org/vp9/#hdr10-metadata-handling), HDR10+ info is in the container (WebM) and it would be relevant for me to support that (WebM still used by Google), currently it is not supported (looks like they don't use the same method than Matroska), but if it is in the VP9 bitstream I would be less motivated (VP9 is abandoned in favor of AV1...)
Thanks for the kind reply, Zenitram.
Both PQ and HLG are now reported correctly for these vp92 clips. Many thanks and best regards,

[Atak_Snajpera]

Why DTS-MA is reported as DTS instead of DTS XLL?
MediaInfoA_Get(Handle_, streamkind, 0, PChar('Format'), 1, 0)

[stax76]

Post full media of that file.

[Atak_Snajpera]

Post full media of that file.

General
ID : 1 (0x1)
Complete name : E:\_Video_Samples\m2ts\Wanted_DTSMA.m2ts
Format : BDAV
Format/Info : Blu-ray Video
File size : 102 MiB
Duration : 33 s 200 ms
Overall bit rate mode : Variable
Overall bit rate : 25.7 Mb/s
Maximum Overall bit rate : 35.5 Mb/s

Video
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings : CABAC / 4 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 4 frames
Codec ID : 27
Duration : 32 s 616 ms
Bit rate mode : Variable
Maximum bit rate : 32.3 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

Audio
ID : 4352 (0x1100)
Menu ID : 1 (0x1)
Format : DTS XLL
Format/Info : Digital Theater Systems
Commercial name : DTS-HD Master Audio
Muxing mode : Stream extension
Codec ID : 134
Duration : 32 s 853 ms
Bit rate mode : Variable
Channel(s) : 6 channels
Channel layout : C L R Ls Rs LFE
Sampling rate : 48.0 kHz
Frame rate : 93.750 FPS (512 SPF)
Bit depth : 24 bits
Compression mode : Lossless
Delay relative to video : 3 ms
Language : English



However MediaInfoA_Get returns just DTS string.

[stax76]

It's because 'Format' shows the format family name. Take a look at the raw view:

https://i.postimg.cc/2j4kT4J9/Untitled.png

[stax76]

The raw text summary has a column width limit of 32 characters, larger parameters are trimmed:


MasteringDisplay_ColorPrimaries_ : Stream
MasteringDisplay_Luminance_Sourc : Stream


I would like to request the removal of this limit by increasing the column width from 32 to 40 like in normal view:


MasteringDisplay_ColorPrimaries_Source : Stream

[Selur]

Small request: Would be nice if MediaInfo would report the rotation flags of mkv files.
I created a file using:
mkvmerge --ui-language en -o "E:\Output\source with rotation flag.mkv" --global-tags "E:\Temp\source with rotation flag_08_56_54_1010__06.xml" -d 0 --default-track 0:yes --projection-type 0:0 --projection-pose-roll 0:90 --track-name 0:"VideoHandle" --language 0:en --default-duration 0:2984100/100000fps --aspect-ratio-factor 0:1/1 --fourcc 0:MP4V --no-chapters --compression -1:none --forced-track 0:yes --no-audio --no-subtitles --timecodes 0:"E:\Temp\timecodeV2_08_56_54_1010.tc" "E:\Temp\08_56_54_1010_03.264"
'--projection-type 0:0 --projection-pose-roll 0:90' adds the rotation info, but MediaInfo doesn't report the rotation like it does for mp4.

Cu Selur

[jriker1]

So I'm finding a weird thing iwth the latest version of Premiere Pro 2020 on Windows. Encoding:



HEVC (H.265)

Match Source

Software Encoding

Profile: Main 10

Level: 6.2

Tier: High

Check Rec 2020 Color Primaries

Check High Dynamic Range

Check Include HDR10 Metadata

Color primaries: Rec2020

Luminance Min: 0.005

Liminance Max: 4000

Constant Light Levels Maximum: 4000

Constant Light Levels Average: 1166

CBR encoded



OK so that's the settings for both encodes. One is the full hour and a half movie that returns in MediaInfo:



Video
Count : 378
Count of stream of this kind : 1
Kind of stream : Video
Kind of stream : Video
Stream identifier : 0
StreamOrder : 0
Inform : English, 20.0 Mb/s, 3840*1600 (2.40:1), at 23.976 (24000/1001) FPS, HEVC (Main 10@L6.2@High)
ID : 1
ID : 1
Format : HEVC
Format : HEVC
Format/Info : High Efficiency Video Coding
Format/Url : http://www.itu.int
Commercial name : HEVC
Format profile : Main 10@L6.2@High
Internet media type : video/H265
Codec ID : hvc1
Codec ID/Info : High Efficiency Video Coding
Codec ID/Url : http://www.itu.int/
Duration : 5262257
Duration : 1 h 27 min
Duration : 1 h 27 min 42 s 257 ms
Duration : 1 h 27 min
Duration : 01:27:42.257
Duration : 01:27:43;14
Duration : 01:27:42.257 (01:27:43;14)
Bit rate : 19998744
Bit rate : 20.0 Mb/s
Width : 3840
Width : 3 840 pixels
Height : 1600
Height : 1 600 pixels
Sampled_Width : 3840
Sampled_Height : 1600
Pixel aspect ratio : 1.000
Display aspect ratio : 2.400
Display aspect ratio : 2.40:1
Rotation : 0.000
Frame rate mode : CFR
Frame rate mode : Constant
Frame rate : 23.976
Frame rate : 23.976 (24000/1001) FPS
FrameRate_Num : 24000
FrameRate_Den : 1001
Frame count : 126168
Color space : YUV
Chroma subsampling : 4:2:0
Chroma subsampling : 4:2:0
Bit depth : 10
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.136
Stream size : 13154829406
Stream size : 12.3 GiB (100%)
Stream size : 12 GiB
Stream size : 12 GiB
Stream size : 12.3 GiB
Stream size : 12.25 GiB
Stream size : 12.3 GiB (100%)
Proportion of this stream : 0.99988
Language : en
Language : English
Language : English
Language : en
Language : eng
Language : en
Encoded date : UTC 2021-01-05 12:22:00
Tagged date : UTC 2021-01-05 12:22:00
colour_description_present : Yes
colour_description_present_Source : Stream
Color range : Full
colour_range_Source : Stream
Color primaries : BT.2020
colour_primaries_Source : Stream
Transfer characteristics : PQ
transfer_characteristics_Source : Stream
Matrix coefficients : BT.2020 non-constant
matrix_coefficients_Source : Stream
Codec configuration box : hvcC

Go back to Media Encoder and use the same settings just reset the project and encode a brief duration. This returns in MediaInfo:



Video
Count : 378
Count of stream of this kind : 1
Kind of stream : Video
Kind of stream : Video
Stream identifier : 0
StreamOrder : 0
Inform : English, 20.0 Mb/s, 3840*1600 (2.40:1), at 23.976 (24000/1001) FPS, HEVC (Main 10@L6.2@High), HDR10
ID : 1
ID : 1
Format : HEVC
Format : HEVC
Format/Info : High Efficiency Video Coding
Format/Url : http://www.itu.int
Commercial name : HEVC
Format profile : Main 10@L6.2@High
HDR format : SMPTE ST 2086
HDR format : SMPTE ST 2086, HDR10 compatible
HDR_Format_Commercial : HDR10
HDR_Format_Compatibility : HDR10
Internet media type : video/H265
Codec ID : hvc1
Codec ID/Info : High Efficiency Video Coding
Codec ID/Url : http://www.itu.int/
Duration : 131131
Duration : 2 min 11 s
Duration : 2 min 11 s 131 ms
Duration : 2 min 11 s
Duration : 00:02:11.131
Duration : 00:02:11;04
Duration : 00:02:11.131 (00:02:11;04)
Bit rate : 20008316
Bit rate : 20.0 Mb/s
Width : 3840
Width : 3 840 pixels
Height : 1600
Height : 1 600 pixels
Sampled_Width : 3840
Sampled_Height : 1600
Pixel aspect ratio : 1.000
Display aspect ratio : 2.400
Display aspect ratio : 2.40:1
Rotation : 0.000
Frame rate mode : CFR
Frame rate mode : Constant
Frame rate : 23.976
Frame rate : 23.976 (24000/1001) FPS
FrameRate_Num : 24000
FrameRate_Den : 1001
Frame count : 3144
Color space : YUV
Chroma subsampling : 4:2:0
Chroma subsampling : 4:2:0
Bit depth : 10
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.136
Stream size : 327964146
Stream size : 313 MiB (100%)
Stream size : 313 MiB
Stream size : 313 MiB
Stream size : 313 MiB
Stream size : 312.8 MiB
Stream size : 313 MiB (100%)
Proportion of this stream : 0.99986
Language : en
Language : English
Language : English
Language : en
Language : eng
Language : en
Encoded date : UTC 2021-01-05 17:06:57
Tagged date : UTC 2021-01-05 17:06:57
colour_description_present : Yes
colour_description_present_Source : Stream
Color range : Full
colour_range_Source : Stream
Color primaries : BT.2020
colour_primaries_Source : Stream
Transfer characteristics : PQ
transfer_characteristics_Source : Stream
Matrix coefficients : BT.2020 non-constant
matrix_coefficients_Source : Stream
Mastering display color primaries : BT.2020
MasteringDisplay_ColorPrimaries_Source : Stream
Mastering display luminance : min: 0.0050 cd/m2, max: 4000 cd/m2
MasteringDisplay_Luminance_Source : Stream
Maximum Content Light Level : 4000 cd/m2
MaxCLL_Source : Stream
Maximum Frame-Average Light Level : 1166 cd/m2
MaxFALL_Source : Stream
Codec configuration box : hvcC

So you will see on the short one there is HDR_Format info where the other there isn't. Also the short one has all the light level and liminance info but the long one doesn't. Identical encodes. Even the same source, just the duration encoded is different. Anyone know what's going on?

[PCU]

Why does MediaInfo not show the Bink Video info?

[kuchikirukia]

Can we get a new listing for whether the Original MKV track flag is set?

https://matroska.org/technical/notes.html

This is going to be important moving forward as the changes to the Default flag mean it cannot be used to differentiate between the original and dubs as they all count as Default tracks. The Original flag is the correct way to mark the original track.

[shae]

Any suggestions for a GUI which handles full-scanning best, hopefully including scan progress indication?

MediaInfoGUI doesn't do it well, and appears to read the whole file into memory.

MediaInfo.NET is okay but very minimalistic.

[filler56789]

current version = 22.09

Changelog:
Version 22.09, 2022-10-04
-------------
+ Italian language update
+ USAC: IOD and sampling rate coherency checking
+ ADM: support of nested objects and complementary objects
+ AC-4: Display of Custom downmix targets
+ IAB: Parsing of IAB bitstream and ADM-like output
+ Frame rate: store FrameRate_Num/Den also for integer values
+ MPEG-4/MOV: support of time codes >30 fps
+ MOV/MPEG-4: List of QuickTime time code discontinuities
+ Dolby Vision: add info about more profiles
x Text streams: show stream frame rate if not same as container frame rate
x CDP: fix rounding of frame rate
x SCC: fix of CEA-608 FirstDisplay_Delay_Frames
x SCC: fix TimeCode_Last
x MPEG-4/MOV: last time code value for all kind of QuickTime time codes
x MOV/MPEG-4: Fix frame count for NDF non-integer frame rates
x JSON: fix invalid output in some corner cases
x Several other parsing bug/crash fixes (thanks to fuzzing by users)

(source: https://www.videohelp.com/software/MediaInfo )

[-QfG-]

Is it possible to add Auro3D classification on DTS-HD MA streams?

ID : 4
Format : DTS XLL
Format/Info : Digital Theater Systems
Commercial name : DTS-HD Master Audio
Codec ID : A_DTS
Duration : 1 h 58 min
Bit rate mode : Variable
Bit rate : 4 562 kb/s
Channel(s) : 8 channels
Channel layout : C L R LFE Lb Rb Lss Rss
Sampling rate : 48.0 kHz
Frame rate : 93.750 FPS (512 SPF)
Bit depth : 24 bits
Compression mode : Lossless
Stream size : 3.77 GiB (5%)
Title : Deutsch DTS-HD MA 7.1 (UHD Blu-ray)
Language : German
Default : No
Forced : No

For example, this is a valid Auro3D stream.

[tormento]

Is there a way to change text output font? I have tried with ResourceHacker but can't find the place.

[war59312]

AV1 Netflix samples:

http://download.opencontent.netflix.com/?prefix=AV1/Chimera/

Would be sweet if MediaInfo supported the .obu files.

[-QfG-]

I wrote this to the support but i do it here, too:

In version 22.12 the entry under video "BitsPixel_Frame" is changed to "Bits-Pixel_Frame". I use a PHP script to read via a JSON file all video informations. But the "-" is a problem in PHP, this will be called as an function :(.

Example (older version)

$json["bitrate"] = $video[0]->BitRate_String." => ".$video[0]->BitsPixel_Frame." Bits/(Pixel*Frame)";

works fine.

Example (v22.12)

$json["bitrate"] = $video[0]->BitRate_String." => ".$video[0]->Bits-Pixel_Frame." Bits/(Pixel*Frame)";

crashing, because the "-"

Is there any chance to rallback to "BitsPixel_Frame" in JSON output?

[oniiz86]

I wrote this to the support but i do it here, too:

In version 22.12 the entry under video "BitsPixel_Frame" is changed to "Bits-Pixel_Frame". I use a PHP script to read via a JSON file all video informations. But the "-" is a problem in PHP, this will be called as an function :(.

Example (older version)

$json["bitrate"] = $video[0]->BitRate_String." => ".$video[0]->BitsPixel_Frame." Bits/(Pixel*Frame)";

works fine.

Example (v22.12)

$json["bitrate"] = $video[0]->BitRate_String." => ".$video[0]->Bits-Pixel_Frame." Bits/(Pixel*Frame)";

crashing, because the "-"

Is there any chance to rallback to "BitsPixel_Frame" in JSON output?
@-QfG- I was wondering if you were able to confirm if this issue has been fixed in the latest v23.04 release?

@-QfG- It looks to have been fixed with the v23.03 MediaInfo release, according to the changelog, https://mediaarea.net/MediaInfo/ChangeLog
x JSON/XML: Remove minus sign from element names

[Lan4]

Are there versions of MediaInfo with normal text scaling for modern operating systems? Now the text is very small, or the text is blurry when scaling.

[hajj_3]

Are there versions of MediaInfo with normal text scaling for modern operating systems? Now the text is very small, or the text is blurry when scaling.

https://github.com/stax76/MediaInfo.NET/releases

[Lan4]

https://github.com/stax76/MediaInfo.NET/releases
Thank you. This is a quality app and good job!

[Thunderbolt8]

is there any update for mediainfo v22.04?

[Perenista]

is there a way to...

1) Open more than one file at the same time, to gather the informations about it

and

2) Remove the file path, or just leave its name, on the result?