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.