MediaInfo(Lib) 0.7 - Reading information about media files

[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