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).