Log in

View Full Version : MediaInfo(Lib) 0.7 - Reading information about media files


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 [22] 23 24 25 26 27 28 29 30 31 32 33 34

LoRd_MuldeR
20th November 2011, 19:48
Any ideas about the 64-Bit issue yet?

Zenitram
20th November 2011, 19:59
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
20th November 2011, 20:18
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
22nd November 2011, 05:54
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
22nd November 2011, 08:31
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
29th November 2011, 03:21
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
17th December 2011, 18:34
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
17th December 2011, 18:37
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
17th December 2011, 19:29
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
18th December 2011, 22:00
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
18th December 2011, 22:51
Is there a Windows Explorer Shell extension yet (colum view,details ect) ?

Zenitram
18th December 2011, 22:57
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
18th December 2011, 23:00
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
18th December 2011, 23:01
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
18th December 2011, 23:21
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
19th December 2011, 00:17
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
19th December 2011, 12:40
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
19th December 2011, 15:36
Great :thanks:

Kurtnoise
19th December 2011, 16:02
@Zen: how to specify Image Resolution code-wise ? This is deprecated actually when I read the Image.csv file....

Zenitram
19th December 2011, 16:16
@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
19th December 2011, 16:32
I meant ppp or dpi not this one...:D

Zenitram
19th December 2011, 16:57
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
19th December 2011, 19:19
mmh, I don't like it...1st time that I heard this.

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

sheck
10th January 2012, 03:32
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
10th January 2012, 09:31
track IDs from MKV != count number

Zenitram
10th January 2012, 10:06
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
10th January 2012, 17:55
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
10th January 2012, 17:58
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
10th January 2012, 18:06
I can add this field in MediaInfo.
The issue is only for Matroska files, right?

That's correct, Matroska only.

Zenitram
10th January 2012, 18:46
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
10th January 2012, 20:01
That's correct, Matroska only.

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

sheck
10th January 2012, 20:29
I'm not sure about MP4. I mostly work with MKV files. Will have to check.

sheck
11th January 2012, 05:29
Thank you, Zenitram,

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

I appreciate it.

Zenitram
11th January 2012, 09:28
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
12th January 2012, 09:39
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
12th January 2012, 10:01
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
12th January 2012, 10:08
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
13th January 2012, 06:19
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
14th January 2012, 15:21
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
14th January 2012, 16:23
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
14th January 2012, 17:16
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
14th January 2012, 17:58
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
15th January 2012, 04:20
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
15th January 2012, 10:48
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
15th January 2012, 23:23
Now it works. Thanks. :)

SiliconKid
22nd January 2012, 11:39
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
23rd January 2012, 01:50
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
1st February 2012, 14:29
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
1st February 2012, 14:33
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
11th March 2012, 12:29
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.