Metadata from OGG, FLAC and zero duration
Cristian Adam
I'm the current maintainer of Directshow Filters for Ogg Vorbis,
Speex, Theora and FLAC, and I would like to improve the Windows Media
Player user experience when it comes to these file formats.
Alex Zambelly wrote back in 2003 (http://tinyurl.com/bama4j)
"I believe getting the metadata promotion to work correctly might
require
a more WMP-friendly plugin, as opposed to just a DirectShow filter.
I'm
actually surprised no one in the Ogg development community has looked
into that yet."
I have dumped all the interfaces that Windows Media Player 11 queries
for the FLAC source filter:
INFO: NonDelegatingQueryInterface: {56A86895-0AD4-11CE-
B03A-0020AF0BA770}, [IBaseFilter]
INFO: NonDelegatingQueryInterface: {56A868A6-0AD4-11CE-
B03A-0020AF0BA770}, [IFileSourceFilter]
INFO: NonDelegatingQueryInterface: {8E1C39A1-DE53-11CF-
AA63-0080C744528D}, [IAMOpenProgress]
INFO: NonDelegatingQueryInterface: {F90A6130-B658-11D2-
AE49-0000F8754B99}, [IAMDeviceRemoval]
INFO: NonDelegatingQueryInterface: {0000010C-0000-0000-
C000-000000000046}, [IPersist]
INFO: NonDelegatingQueryInterface: {FA2AA8F5-8B62-11D0-
A520-000000000000}, [IAMNetShowExProps]
INFO: NonDelegatingQueryInterface: {3C43D14F-25B3-4E34-A36C-
F575DEEA29C0}, [Unknown GUID Name]
INFO: NonDelegatingQueryInterface: {56A868FE-0AD4-11CE-
B0A3-0020AF0BA770}, [IAMPlayList]
INFO: NonDelegatingQueryInterface: {DFDFD197-A9CA-43D8-
B341-6AF3503792CD}, [IMFVideoRenderer]
INFO: NonDelegatingQueryInterface: {56A868B5-0AD4-11CE-
B03A-0020AF0BA770}, [IBasicVideo]
INFO: NonDelegatingQueryInterface: {81A3BD32-
DEE1-11D1-8508-00A0C91F9CA0}, [IMixerOCX]
INFO: NonDelegatingQueryInterface:
{095CAB33-2B11-46F7-8107-6B67D4065CD6}, [IWMPVideoNodeInternal]
INFO: NonDelegatingQueryInterface: {36B73880-
C2C8-11CF-8B46-00805F6CEF60}, [IMediaSeeking]
INFO: NonDelegatingQueryInterface: {56A868B2-0AD4-11CE-
B03A-0020AF0BA770}, [IMediaPosition]
INFO: NonDelegatingQueryInterface: {2DD74950-A890-11D1-
ABE8-00A0C905F375}, [IAMFilterMiscFlags]
INFO: NonDelegatingQueryInterface: {56A868B4-0AD4-11CE-
B03A-0020AF0BA770}, [IVideoWindow]
INFO: NonDelegatingQueryInterface: {56A868B3-0AD4-11CE-
B03A-0020AF0BA770}, [IBasicAudio]
INFO: NonDelegatingQueryInterface: {B8E8BD60-0BFE-11D0-
AF91-00AA00B67A42}, [IIPDVDec]
INFO: NonDelegatingQueryInterface: {C1960960-17F5-11D1-
ABE1-00A0C905F375}, [IAMStreamSelect]
INFO: NonDelegatingQueryInterface: {B45DD570-3C77-11D1-
ABE1-00A0C905F375}, [IID_IMpegAudioDecoder]
INFO: NonDelegatingQueryInterface: {5738E040-B67F-11D0-
BD4D-00A0C911CE86}, [IPersistMediaPropertyBag]
INFO: NonDelegatingQueryInterface: {0BB53976-978F-41F9-A66B-
A29CC318A817}, [Unknown GUID Name]
INFO: NonDelegatingQueryInterface:
{55272A00-42CB-11CE-8135-00AA004BB851}, [IPropertyBag]
There are two unknown interfaces {3C43D14F-25B3-4E34-A36C-
F575DEEA29C0} and {0BB53976-978F-41F9-A66B-A29CC318A817}, are they
responsible for querying metadata? maybe, maybe not.
This metadata should be added by somebody in the database, like Jim
Travis suggested on this
thread http://tinyurl.com/c3aqur by using IWMPMedia::setItemInfo. Is
there a possibility that Windows Media Player would ask somebody about
the metadata?
WMP Tag Support Extender (http://wmptagext.sourceforge.net/) project
has created a Windows Media Player plugin which spies on events and
adds the metadata, is this the only way to add metadata for 3rd
parties? by creating an Windows Media Player plugin?
Windows Media Player 10 Mobile uses information acquired from
IAMMediaContent interface - http://tinyurl.com/abpvhe is this an
accident?
Another problem I'm facing is that if I try to play a FLAC file
directly from the Library the duration is set to 00:00 and seeking is
not possible.
If I play the file directly by invoking "%programfiles%\windows media
player\wmplayer.exe" file duration is determined correctly, seeking
works.
If I have made a playlist and play the file from there the duration is
set correctly and seeking works.
How can I overcome this problem?
Many thanks,
Cristian.
John Lockwood
1. All the third-party directshow filters I have seen result in WMP showing
a duration of zero seconds until you start playing the track
2. Articles I have seen suggest Microsoft's position is that it is the
directshow filter at fault for not providing the correct information to WMP
3. The only music format I have tried and seen correctly work was MP3 using
the built-in MP3 directshow filter provided by Microsoft (I have never used
WMA but would expect that to work as well for the same reason)
My conclusions would be
1. Microsoft have designed a crappy API for directshow filters to make this
so troublesome
2. Microsoft have failed to document how to do this properly or provide
examples showing how to do it properly, they could have done this by
providing a fully documented copy of their MP3 (or WMA) directshow filter
with freely available source code
While I find this annoying from a cosmetic point of view, it has not
impacted on my use since I don't seek through tracks other than by dragging
the timebar in WMP which works for me.
Note: I exclusively use Apple Lossless format tracks in WMP, Apple Lossless
is stored in MPEG4 .m4a file format and uses MPEG4 meta-tags for which I use
the wmptagext plugin you refer to. This does result in the zero duration
problem you describe but they otherwise work for me.
On 20/2/09 01:11, in article
fe8eea80-cf30-46e4...@b16g2000yqb.googlegroups.com, "Cristian
zachd [MSFT]
? Doesn't this same scenario work fine with the various OGG, MP4, and other
filters out there?
Developing anything in the software world can be complex, and bugs can
accidentally happen. I'd follow up with the plug-in vendor first here, as
pushing it off to MS seems contextually inaccurate and is probably the
longer path to solution.
--
Speaking for myself only.
See http://zachd.com/pss/pss.html for some helpful WMP info.
This posting is provided "AS IS" with no warranties, and confers no rights.
zachd [MSFT]
I heard a rumor that the start time on every sample from one FLAC filter was
0 - I'd double-check that if I were you. GetCurrentPosition should not
always be 0 - that would imply that the track is indeed 0:00 duration.
Note again that I'm speaking for myself only, and I haven't personally
looked into this at all.
--
Speaking for myself only.
See http://zachd.com/pss/pss.html for some helpful WMP info.
This posting is provided "AS IS" with no warranties, and confers no rights.
--
"Cristian Adam" <cristi...@gmail.com> wrote in message
news:fe8eea80-cf30-46e4...@b16g2000yqb.googlegroups.com...
Cristian Adam
Thanks for reading this post, from you answer I understand that I
should talk with the author
of WMP Tag Support Extender, because this is the safest way to manage
metadata for
a 3rd party.
Luckily WMP Tag Support Extender is an opensource project and I can
find out how he
implemented that.
I have created a small test program which uses de Windows Media SDK to
add metadata
for a media file. I have managed to add all the important metadata
(Artist, Album, Title, Genre, Year),
except album picture.
Album picture is related to every media data by it's "TrackID", this
TrackID is generated by Windows
Media Player, and you cannot change it programatically. The picture
for this TrackID resides in
c:\Documents and Settings\<USER NAME>\Local Settings\Application Data
\Microsoft\Media Player\Art Cache\LocalMLS\
If you decide to click on "Find Album Info" Windows Media Player will
generate other
metadata values for "WM/WMCollectionGroupID" and "WM/WMCollectionID",
and two files
in the directory where your media file resides, AlbumArt_{GUID}
_Large.jpg and AlbumArt_{GUID}_Small.jpg
The upper two metadata fields are readonly, you cannot change them
programatically.
The only way to display the album art is by getting the TrackID of the
media file and then
generate the jpg file in the LocalMLS folder, a bit hackish but it
will work.
The problem with seeking is due to the fact that the following
metadata fields are
not set: "Duration" and "Bitrate", so the fact that Windows Media
Player
doesn't rely on metadata do determine the length of a song it's a LIE.
These two fields
are readonly!
So I don't know what to do in order to enable seeking! Microsoft has
ensured that only
MP3 and WMA will have the seek capability in Windows Media Player.
It's so easy
to blame the 3rd party developers for "mal praxis" when you know that
they will never get it right!
Unfortunately I cannot prove this by manually modifying the database
(CurrentDatabase_360.wmdb)
in order to change Duration and Bitrate fields.
A DirectShow source filter can add its metadata to Windows Media
Player only if it uses
IWMPMedia::setItemInfo, in order to get a IWMPMedia object it has to
create a WindowsMediaPlayer
object and then query for an IWMPMediaCollection object and then
calling add function can
give access to an IWMPMedia object.
The problem with the above scenario is that it takes time to create an
media player object and add
metatadata. On my system it was on average 1.3 seconds to add metadata
for a media file.
Therefore a DirectShow filter should add its metadata on a separate
thread, or risk having a few seconds
of silence before the start of the song.
In summary it would have been nice if Microsoft would:
1. provide a mechanism for querying metadata when files were added to
the library.
2. provide a mechanism to load / save metadata from a DirectShow
filter
3. give access for 3rd parties to Advanced Tag Editor
IPersistMediaPropertyBag would have been the right interface to load /
store metadata.
All of that can be achieved if Microsoft would provide an A to Z
sample of how to add a new type
of media file to Windows Media Player, a variation of a WAV format, or
something really simple.
I wonder what changed from this point of view in Windows Media Player
12, Windows 7 would
have a chance of fixing all these problems!
Cheers!
Cristian Adam
support! But the seeking problem is still present! Length is 00:00 and
Bitrate -
The support is readonly and it gets information from the internet, I
didn't added any composer, but Windows Media Player displayed the
composers.
This support is a bit useless without the seeking capability.
Cristian Adam
>
> This support is a bit useless without the seeking capability.
I meant that without an extension capability this support is useless.
As a codec developer I would have wanted to have some support in order
to add that metadata into WMP database.
WMP librarian knows about OGG metadata now, what about FLAC and other
media files?! I guess we'll have to wait until Windows Media Player
"lucky" 13 will come.
Seeesh!
Give us developers proper support!
zachd [MSFT]
I'll quote myself:
===
I heard a rumor that the start time on every sample from one FLAC filter was
0 - I'd double-check that if I were you. GetCurrentPosition should not
always be 0 - that would imply that the track is indeed 0:00 duration.
Note again that I'm speaking for myself only, and I haven't personally
looked into this at all.
===
-- did you look into that? =)
Reminder: I'm here as a friend on my free time and NOT here as a Microsoft
Representative. If you want to pursue developer support, you should go
there. But the above information I already supplied probably points you in
the right direction anyways. =)
Kind regards,
-Zach
--
Speaking for myself only.
See http://zachd.com/pss/pss.html for some helpful WMP info.
This posting is provided "AS IS" with no warranties, and confers no rights.
--
"Cristian Adam" <cristi...@gmail.com> wrote in message
news:af45c0e5-9457-4945...@g38g2000yqd.googlegroups.com...
zachd [MSFT]
> The problem with seeking is due to the fact that the following
> metadata fields are
> not set: "Duration" and "Bitrate", so the fact that Windows Media
> Player
> doesn't rely on metadata do determine the length of a song it's a LIE.
> These two fields are readonly!
Yeah, you're trying to hack the system. Don't do that. Those fields should
come from the file properties, not the metadata.
> So I don't know what to do in order to enable seeking! Microsoft has
> ensured that only
> MP3 and WMA will have the seek capability in Windows Media Player.
That comes as a huge surprise to me. Do you have any basis for this notion,
or are you just making accusations out of left field based upon frustration?
I suspect the latter. I'm willing to have conversations with intelligent
people: if we're going to jump to frustrated conclusions, that kind of is
boring to me, as it would be if you were in my shoes. =\
I had a friend look into this issue: he specifically said the FLAC filter
was buggy.
> It's so easy
> to blame the 3rd party developers for "mal praxis" when you know that
> they will never get it right!
I thought I pointed out previously the apparent source bug for this issue in
the file filter?
As far as I'm aware, there's other file filters that work fine here in the
player.
> Unfortunately I cannot prove this by manually modifying the database
> (CurrentDatabase_360.wmdb)
> in order to change Duration and Bitrate fields.
Yes, as noted that would be highly inappropriate.
> All of that can be achieved if Microsoft would provide an A to Z
> sample of how to add a new type
> of media file to Windows Media Player, a variation of a WAV format, or
> something really simple.
I'm here as a friend. I've got a zillion things to do. I think most of
this data exists, but the call for it is usually rare enough that I don't
know if anybody has specifically put together an A-Z doc.
So: yeah, I like your idea, if it isn't already done, I'm just not in a
position at this point to chase something like this when I've got other
stuff you want me doing anyways. ;-) This kind of request from my point of
view probably works better *after* releases when I'm not working nights and
weekends. =) If I don't have free time, I can't rightly help much on the
secondary ideas like this.
Cristian Adam
<za...@nomailplz.online.microsoft.com> wrote:
> I'll quote myself:
> ===
> I heard a rumor that the start time on every sample from one FLAC filter was
> 0 - I'd double-check that if I were you. GetCurrentPosition should not
> always be 0 - that would imply that the track is indeed 0:00 duration.
>
> Note again that I'm speaking for myself only, and I haven't personally
> looked into this at all.
> ===
>
> -- did you look into that? =)
>
> Reminder: I'm here as a friend on my free time and NOT here as a Microsoft
> Representative. If you want to pursue developer support, you should go
> there. But the above information I already supplied probably points you in
> the right direction anyways. =)
>
Thanks for the help. You also helped with another issue regarding
missing file filters in Windows Media Player
when opening the file open dialog.
Working with closed source software can, sometimes, cause frustration.
I have tested your suggestion and it seams it's not working, I will
continue to find a solution to this problem,
it might be something really simple.
Cheers.
zachd [MSFT]
I'm not saying it's the be-all end-all solution, mind you - merely that when
this was looked into, it probably could not have worked against that based
upon the codec/file filter handing back bad data. That would be one of the
first steps in the chain of getting this to work.
If you put breakpoints inside your filter, you should find that you're
getting called by the player - have you already debugged through your
support of IMediaSeeking and etc?
I'm largely talking out of my hat here: I've been way off working on other
things. The problem I noted was simply noted in a quick review.
--
Speaking for myself only.
See http://zachd.com/pss/pss.html for some helpful WMP info.
This posting is provided "AS IS" with no warranties, and confers no rights.
--
"Cristian Adam" <cristi...@gmail.com> wrote in message
news:ea278dc9-30fd-4401...@m42g2000yqb.googlegroups.com...
Cristian Adam
<za...@nomailplz.online.microsoft.com> wrote:
> I'm not saying it's the be-all end-all solution, mind you - merely that when
> this was looked into, it probably could not have worked against that based
> upon the codec/file filter handing back bad data. That would be one of the
> first steps in the chain of getting this to work.
>
> If you put breakpoints inside your filter, you should find that you're
> getting called by the player - have you already debugged through your
> support of IMediaSeeking and etc?
>
I have traced all the IMediaSeeking functions with their arguments and
the return value.
My test was done like so:
1. start media player and play file
2. seek in the middle of the file
3. close media player
First I have tested to play a song of 5:17 seconds from the Library:
==8<==========================================
IMediaSeeking::IsFormatSupported([in] {7B785574-8C82-11CF-
BC0C-00AA00AC74F6}) -> 0x0
IMediaSeeking::GetCapabilities([out] 3f) -> 0x0
IMediaSeeking::IsUsingTimeFormat([in] {7B785574-8C82-11CF-
BC0C-00AA00AC74F6}) -> 0x0
IMediaSeeking::GetDuration([out] 00:05:16:813) -> 0x0
IMediaSeeking::GetRate([out] 1) -> 0x0
IMediaSeeking::SetRate([in] 1) -> 0x80004001
IMediaSeeking::GetRate([out] 1) -> 0x0
IMediaSeeking::SetRate([in] 1) -> 0x80004001
IMediaSeeking::IsFormatSupported([in] {7B785574-8C82-11CF-
BC0C-00AA00AC74F6}) -> 0x0
IMediaSeeking::GetCapabilities([out] 3f) -> 0x0
IMediaSeeking::GetRate([out] 1) -> 0x0
Pause
IMediaSeeking::GetRate([out] 1) -> 0x0
IMediaSeeking::GetRate([out] 1) -> 0x0
IMediaSeeking::IsUsingTimeFormat([in] {7B785574-8C82-11CF-
BC0C-00AA00AC74F6}) -> 0x0
IMediaSeeking::GetPreroll([out] 00:00:00:000) -> 0x0
IMediaSeeking::IsUsingTimeFormat([in] {7B785574-8C82-11CF-
BC0C-00AA00AC74F6}) -> 0x0
IMediaSeeking::GetStopPosition([out] 00:05:16:813) -> 0x0
Run: 02:13:55:451
Pause
IMediaSeeking::IsUsingTimeFormat([in] {7B785574-8C82-11CF-
BC0C-00AA00AC74F6}) -> 0x0
IMediaSeeking::SetPositions([in, out] 00:00:00:000, [in] 9, [in, out]
00:00:00:000, [in] 0) -> 0x0
IMediaSeeking::IsUsingTimeFormat([in] {7B785574-8C82-11CF-
BC0C-00AA00AC74F6}) -> 0x0
IMediaSeeking::GetPreroll([out] 00:00:00:000) -> 0x0
IMediaSeeking::IsUsingTimeFormat([in] {7B785574-8C82-11CF-
BC0C-00AA00AC74F6}) -> 0x0
IMediaSeeking::GetStopPosition([out] 00:05:16:813) -> 0x0
Run: 02:13:59:010
Pause
Stop
IMediaSeeking::IsUsingTimeFormat([in] {7B785574-8C82-11CF-
BC0C-00AA00AC74F6}) -> 0x0
IMediaSeeking::SetPositions([in, out] 00:00:00:985, [in] 9, [in, out]
00:00:00:000, [in] 0) -> 0x0
==8<==========================================
Notice that although WMP gets the StopPosition correctly the seek in
the middle of the song
instructs the codec that it happened at 00:00:00:000 (first
SetPositions call). After the song
was stopped curiously WMP instructs the codec to seek at a postion
different than 0 (the
last line traced, the second SetPositions call)
The second test was to play the same media file directly with
wmplayer.exe:
==8<==========================================
IMediaSeeking::IsFormatSupported([in] {7B785574-8C82-11CF-
BC0C-00AA00AC74F6}) -> 0x0
IMediaSeeking::GetCapabilities([out] 3f) -> 0x0
IMediaSeeking::IsUsingTimeFormat([in] {7B785574-8C82-11CF-
BC0C-00AA00AC74F6}) -> 0x0
IMediaSeeking::GetDuration([out] 00:05:16:813) -> 0x0
IMediaSeeking::GetRate([out] 1) -> 0x0
IMediaSeeking::SetRate([in] 1) -> 0x80004001
IMediaSeeking::GetRate([out] 1) -> 0x0
IMediaSeeking::SetRate([in] 1) -> 0x80004001
IMediaSeeking::IsFormatSupported([in] {7B785574-8C82-11CF-
BC0C-00AA00AC74F6}) -> 0x0
IMediaSeeking::GetCapabilities([out] 3f) -> 0x0
IMediaSeeking::GetRate([out] 1) -> 0x0
Pause
IMediaSeeking::GetRate([out] 1) -> 0x0
IMediaSeeking::GetRate([out] 1) -> 0x0
IMediaSeeking::IsUsingTimeFormat([in] {7B785574-8C82-11CF-
BC0C-00AA00AC74F6}) -> 0x0
IMediaSeeking::GetPreroll([out] 00:00:00:000) -> 0x0
IMediaSeeking::IsUsingTimeFormat([in] {7B785574-8C82-11CF-
BC0C-00AA00AC74F6}) -> 0x0
IMediaSeeking::GetStopPosition([out] 00:05:16:813) -> 0x0
Run: 02:24:00:324
IMediaSeeking::GetRate([out] 1) -> 0x0
IMediaSeeking::GetRate([out] 1) -> 0x0
IMediaSeeking::GetRate([out] 1) -> 0x0
IMediaSeeking::GetRate([out] 1) -> 0x0
IMediaSeeking::GetRate([out] 1) -> 0x0
Pause
IMediaSeeking::IsUsingTimeFormat([in] {7B785574-8C82-11CF-
BC0C-00AA00AC74F6}) -> 0x0
IMediaSeeking::SetPositions([in, out] 00:02:22:488, [in] 9, [in, out]
00:00:00:000, [in] 0) -> 0x0
IMediaSeeking::IsUsingTimeFormat([in] {7B785574-8C82-11CF-
BC0C-00AA00AC74F6}) -> 0x0
IMediaSeeking::GetPreroll([out] 00:00:00:000) -> 0x0
IMediaSeeking::IsUsingTimeFormat([in] {7B785574-8C82-11CF-
BC0C-00AA00AC74F6}) -> 0x0
IMediaSeeking::GetStopPosition([out] 00:05:16:813) -> 0x0
Run: 02:24:03:049
Pause
Stop
IMediaSeeking::IsUsingTimeFormat([in] {7B785574-8C82-11CF-
BC0C-00AA00AC74F6}) -> 0x0
IMediaSeeking::SetPositions([in, out] 00:02:23:209, [in] 9, [in, out]
00:00:00:000, [in] 0) -> 0x0
==8<==========================================
The seek in the middle of the file instructed the codec to seek at
00:02:22:488.
The only difference between both of the log files is a bunch of
additional IMediaSeeking::GetRate
calls. The rest is identical, except the Run times and Seek positions.
Seeking should also work when the media file was played from the
Library, the same
data was given by the codec, why does it work when played directly?
Thanks for taking this into consideration.
Cheers!
Cristian Adam
<za...@nomailplz.online.microsoft.com> wrote:
> I'm not saying it's the be-all end-all solution, mind you - merely that when
> this was looked into, it probably could not have worked against that based
> upon the codec/file filter handing back bad data. That would be one of the
> first steps in the chain of getting this to work.
>
> If you put breakpoints inside your filter, you should find that you're
> getting called by the player - have you already debugged through your
> support of IMediaSeeking and etc?
>
I have traced all the IMediaSeeking functions with their arguments and
zachd [MSFT]
Stepping sideways for a moment:
You don't set the local file association MIME type - HKCR\.flac ,
ContentType
The verbs are set up broken - HKCR\WMP.FlacFile\shell\*\* are both set to be
REG_SZ but contain REG_EXPAND_SZ values. They won't work.
Why is Open default under HKCR\wmp.flacfile\shell ?
You're blindly setting shellex values yourself, which will likely fail on
Windows 7 where these values change. If you really want to guess at these
yourself, you may want to copy from another key(?).
Under HKLM\Software\Microsoft\Multimedia\WMPlayer\Extensions
you should set Extension.Handler
you should set MediaType.Icon
you should not set AlreadyRegistered
it would be useful to add yourself to
HKCR\Applications\wmplayer.exe\supportedtypes
(for shell open with) and
HKLM\Software\Clients\Media\Windows Media Player\Capabilities
(for Set User Defaults on Vista/Win7).
That's just off the top of my head - I'm under the weather and got a bunch
of stuff going on so haven't had the most time to look into this. This is
obviously just the "configuring the system to check it out" stage. =)
--
Speaking for myself only.
See http://zachd.com/pss/pss.html for some helpful WMP info.
This posting is provided "AS IS" with no warranties, and confers no rights.
--
"Cristian Adam" <cristi...@gmail.com> wrote in message
news:fec70630-de51-4700...@13g2000yql.googlegroups.com...
zachd [MSFT]
And of course the shell verbs WMP uses actually change in Windows 7 too.
That itself is not critical, but it's part of the problem if you're trying
to roll your own WMP file associations. Potentially you could just clone
something like WMP11.AssocFile.WMA if existed and then modify it for your
own needs or something like that.
There are probably solutions I have forgotten about, but since we're talking
extremely informally without the context of a KB/MSDN article, I'll let
myself be OK with forgetting for now so can focus on other higher priority
things.
--
Speaking for myself only.
See http://zachd.com/pss/pss.html for some helpful WMP info.
This posting is provided "AS IS" with no warranties, and confers no rights.
--
"zachd [MSFT]" <za...@nomailplz.online.microsoft.com> wrote in message
news:%23TVeVd4...@TK2MSFTNGP05.phx.gbl...
jasiu
I noticed that you return 0x80004001 (E_NOTIMPL) when WMP call your
filter's SetRate method. MSDN stands that default implementation for
value of Rate set to 1 (normal) should retun S_OK (http://
msdn.microsoft.com/en-us/library/ms911617.aspx). I undestand that
filter does not suport rates different than 1 but I think it is worth
to try.
> IMediaSeeking::SetRate([in] 1) -> 0x80004001
I have lots of FLAC files, use this filter and think it is great! Tag
support and seeking would make it even better.
Marcin.
Lysy
My friend is using Windows 7 and WMP 12 and it does not read OGG.
Maybe because of windows 7 RC at play here. This was FLAC file which I
understand is using OGG metadata.
from wikipedia
"With Xiph.org incorporation, the Ogg container format, suitable for
streaming (also called Ogg FLAC)"
Tim De Baets
After having recently read this thread and understanding the problem, I
started experimenting a bit with WMP and third-party formats myself. The
zero-duration bug that Cristian Adam described seems to occur for all
third-party formats, so the DirectShow filter isn't at fault. Another proof
of this is that the bug doesn't occur when you play the file by opening it in
Explorer.
It quickly became clear to me that WMP only reads the metadata of its
default formats (mp3, wma etc.), and that these formats are hard-coded into
WMP (as extensions and mime types). This means that there's certainly no
documented API to add real metadata support for third-party formats. You
could of course set the metadata tags in the WMP library, just like WMP Tag
Support Extender does, but that's not a good solution. Read-only tags can't
be set (resulting in the zero duration), and it requires constant monitoring
of the library.
So the only way to add real third-party metadata support is to trick WMP
into thinking that it's handling a default format instead (such as mp3). I
was eventually able to do this, by hooking into WMP and intercepting the call
that compares the audio/x-other and audio/mp3 mime types. After that, WMP
would use a metadata editor object (IWMMetadataEditor) to get the metadata of
the third-party format, just like it does for mp3. Of course, this failed for
the third-party format, so I had to hook into this too, allowing me to return
any metadata I want, including tags that are read-only in the library such as
Duration. This seemed to fix the zero-duration bug and seeking worked
perfectly. WMP indeed only uses the Duration tag in the library and ignores
the duration returned by the DirectShow filter, when a file is played from
the library.
I will try to get in touch with the author of WMP Tag Support Extender and
suggest him to integrate this new (and in my opinion better) way of adding
metadata support for third-party formats. The project looks abandoned though
(no new release since 2 years), so if I can't contact him or he isn't
interested, I will probably make such a plug-in myself.
Kind regards
Tim De Baets
zachd [MSFT]
OGG and FLAC as noted are not supported in a default Windows 7 install.
There is a ton of stuff out there to do and implement.
You could use a third party filter for playback here.
--
Speaking for myself only.
See http://zachd.com/pss/pss.html for some helpful WMP info.
This posting is provided "AS IS" with no warranties, and confers no rights.
--
"Lysy" <Ly...@discussions.microsoft.com> wrote in message
news:6E2626EA-80BC-48A6...@microsoft.com...
zachd [MSFT]
I believe you actually would want to implement a property handler here(?).
I believe something like this:
http://msdn.microsoft.com/en-us/library/bb266532(VS.85).aspx
is probably an interesting starting point.
That's off the top of my head, but that may be a part of the puzzle. I've
been shellacked with other things. =\
--
Speaking for myself only.
See http://zachd.com/pss/pss.html for some helpful WMP info.
This posting is provided "AS IS" with no warranties, and confers no rights.
--
"Tim De Baets" <TimDe...@discussions.microsoft.com> wrote in message
news:920B21B3-9975-481C...@microsoft.com...
Tim De Baets
WMP uses those property handlers too? I would have to do some more
checking, but I'm already fairly sure that it doesn't.
Regards
--
Tim De Baets
http://www.bm-productions.tk
zachd [MSFT]
IIRC, WMP does use property handlers to get values such as duration & etc.
The doc covers Search in part but also gets into property handlers and I
believe is the most current iteration of documentation in that arena.
--
Speaking for myself only.
See http://zachd.com/pss/pss.html for some helpful WMP info.
This posting is provided "AS IS" with no warranties, and confers no rights.
--
"Tim De Baets" <tdeb...@nospam.com> wrote in message
news:4a578b11$0$2853$ba62...@news.skynet.be...
Tim De Baets
introduced in Vista. It makes sense that I didn't see anything related
to this, as I'm still using XP for most development and testing.
Unfortunately, it looks like WMP 11 on Vista doesn't use property
handlers either. Someone has already implemented a property handler for
m4a files, see http://www.whitebear.ch/music . I downloaded and
installed this on Vista, but when m4a files were added to the library, I
still couldn't see any m4a metadata being used. In fact, the author of
this property handler himself already asked how to support WMP:
http://groups.google.be/group/microsoft.public.windowsmedia.sdk/browse_thread/thread/8d40af8e624b348a#
To be really sure, I also used Process Monitor to monitor WMP when it
adds m4a files to the library, but the PropertyHandlers registry key is
never queried (except for lnk files, no idea why it does that). So
thanks again for the clue, but it still looks like there isn't any other
way to add metadata support, though I haven't checked with WMP 12 yet.
AJD
<za...@nomailplz.online.microsoft.com> wrote:
> IIRC, WMP does use property handlers to get values such as duration & etc.
> The doc covers Search in part but also gets into property handlers and I
> believe is the most current iteration of documentation in that arena.
I've been trying to figure out a solution to the missing duration
problem and wrote a property handler earlier to test the theory that
WMP grabbed the duration data from there. While I managed to get the
duration to be reported properly in explorer it was still not reported
in the WMP library or in the file properties inside WMP.
I just came across this thread a few minutes ago and hopefully that'll
be of some help. I'm very interested in a proper non-hack solution to
this. I'm also rather surprised that WMP does not query the shell for
all of its metadata... that seems like it'd be much easier and cleaner
than what I assume it's doing now (grabbing it manually from known
file types).
Apologies if this got posted twice; I was not aware that this was a
newsgroup thread and saw it on another site.
AJD
ajd
I've been trying to figure out a solution to the missing duration
problem and wrote a property handler earlier to test the theory that WMP
grabbed the duration data from there. While I managed to get the
duration to be reported properly in explorer it was still not reported
in the WMP library or in the file properties inside WMP.
I just came across this thread a few minutes ago and hopefully that'll
be of some help. I'm very interested in a proper non-hack solution to
this. I'm also rather surprised that WMP does not query the shell for
all of its metadata... that seems like it'd be much easier and cleaner
than what I assume it's doing now (grabbing it manually from known file
types).
--
ajd
------------------------------------------------------------------------
ajd's Profile: http://forums.techarena.in/members/114149.htm
View this thread: http://forums.techarena.in/media-player/1126795.htm
AJD
wrote:
> So the only way to add real third-party metadata support is to trick WMP
> into thinking that it's handling a default format instead (such as mp3). I
> was eventually able to do this, by hooking into WMP and intercepting the call
> that compares the audio/x-other and audio/mp3 mime types. After that, WMP
> would use a metadata editor object (IWMMetadataEditor) to get the metadata of
> the third-party format, just like it does for mp3. Of course, this failed for
> the third-party format, so I had to hook into this too, allowing me to return
> any metadata I want, including tags that are read-only in the library such as
> Duration. This seemed to fix the zero-duration bug and seeking worked
> perfectly. WMP indeed only uses the Duration tag in the library and ignores
> the duration returned by the DirectShow filter, when a file is played from
> the library.
Which call compares the mime types? I haven't been able to find it.
This seems promising as a temporary solution, and it doesn't seem like
there is any other way to do it.
Tim De Baets
> Which call compares the mime types? I haven't been able to find it.
> This seems promising as a temporary solution, and it doesn't seem like
> there is any other way to do it.
WMP calls _wcsicmp from msvcrt.dll to compare the strings. Are you
interested in writing a third-party metadata plug-in too? It's probably
unnecessary to start from scratch; Cristian Adam is already showing
interest to make such a plug-in. It will likely have pluggable tag
support (just like WMP Tag Support Extender), allowing you to write a
tag support dll for whatever third-party format you like.
AJD
> WMP calls _wcsicmp from msvcrt.dll to compare the strings. Are you
> interested in writing a third-party metadata plug-in too? It's probably
> unnecessary to start from scratch; Cristian Adam is already showing
> interest to make such a plug-in. It will likely have pluggable tag
> support (just like WMP Tag Support Extender), allowing you to write a
> tag support dll for whatever third-party format you like.
Which call is the one calling _wcsicmp?
I am interested in writing a plug-in, but not in taking the same
approach that Christian has. It would make much more sense to link
WMP's metadata/property handlers to the shell handlers so that were
one to write metadata support for the shell then WMP would also have
that support.
Tim De Baets
>
> Which call is the one calling _wcsicmp?
_wcsicmp gets called directly by wmp.dll, from within its internal
MLSDBHelper::FindMediaInStoreByURL procedure (according to the symbols).
If you view wmp.dll's imports, you will see that _wcsicmp is one of them.
>
> I am interested in writing a plug-in, but not in taking the same
> approach that Christian has. It would make much more sense to link
> WMP's metadata/property handlers to the shell handlers so that were
> one to write metadata support for the shell then WMP would also have
> that support.
That's actually an interesting idea, but property handlers are not
available on XP. Also, the only property handler I have found so far
that could be useful is the one for m4a files. As far as I know, no
property handlers for other audio formats exist.
AJD
> AJD wrote:
>
> > Which call is the one calling _wcsicmp?
>
> _wcsicmp gets called directly by wmp.dll, from within its internal
> MLSDBHelper::FindMediaInStoreByURL procedure (according to the symbols).
> If you view wmp.dll's imports, you will see that _wcsicmp is one of them.
>
I've been looking through MLSDBHelper::FindMediaInStoreByURL for a
while and have been unable to find the function responsible for
creating the object which implements IWMMetadataEditor. Though the
mime check is there the object seems to be created somewhere else
entirely.
Which functions did you hook? I'm currently using WMP12, so this may
have changed from 11.
> That's actually an interesting idea, but property handlers are not
> available on XP. Also, the only property handler I have found so far
> that could be useful is the one for m4a files. As far as I know, no
> property handlers for other audio formats exist.
Property handlers aren't particularly difficult to write, and I
currently have a FLAC property handler half-implemented (as I
mentioned in a previous post I had used this to check whether WMP
accessed them for duration info--it does not). I just don't see the
point in duplicating code for a 3rd party plug-in when I can get WMP /
and/ shell support from the same extension. I do not plan on targeting
XP, only Vista and up.
Cheers
Tim De Baets
> I've been looking through MLSDBHelper::FindMediaInStoreByURL for a
> while and have been unable to find the function responsible for
> creating the object which implements IWMMetadataEditor. Though the
> mime check is there the object seems to be created somewhere else
> entirely.
WMP calls WMCreateEditor to retrieve a reference to a metadata editor
object, I haven't checked where it does that though (that's not
important anyway).
> Which functions did you hook? I'm currently using WMP12, so this may
> have changed from 11.
_wcsicmp and WMCreateEditor. I haven't tested anything on WMP 12 yet.