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:
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?
I can't answer your questions, only tell you what I have seen and read.
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-a5a5-c046cce8d...@b16g2000yqb.googlegroups.com, "Cristian
> 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:
> 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?
? 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.
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" <cristian.a...@gmail.com> wrote in message
> 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:
> 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?
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!
Regarding Windows Media Player 12, it seems it has OGG Metadata 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.
On Feb 22, 5:29 pm, Cristian Adam <cristian.a...@gmail.com> wrote:
> 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!
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" <cristian.a...@gmail.com> wrote in message
> 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!
> 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.
-- 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. --
<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.
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" <cristian.a...@gmail.com> wrote in message
<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.
<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:
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:
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?
<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:
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:
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?
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" <cristian.a...@gmail.com> wrote in message
> On Feb 23, 6:51 am, "zachd [MSFT]" > <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:
> 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:
> 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?
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
> 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" <cristian.a...@gmail.com> wrote in message > news:fec70630-de51-4700-902a-af814da3697d@13g2000yql.googlegroups.com... >> On Feb 23, 6:51 am, "zachd [MSFT]" >> <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:
>> 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:
>> 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?
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.
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)"
"Cristian Adam" wrote: > Regarding Windows Media Player 12, it seems it has OGG Metadata > 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.
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.
"Cristian Adam" wrote: > On Feb 23, 6:51 am, "zachd [MSFT]" > <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:
> 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:
> 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?
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" <L...@discussions.microsoft.com> wrote in message
> 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)"
> "Cristian Adam" wrote:
>> Regarding Windows Media Player 12, it seems it has OGG Metadata >> 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.
> 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
> "Cristian Adam" wrote:
>> On Feb 23, 6:51 am, "zachd [MSFT]" >> <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:
>> 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:
>> 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 the link, but that's for Windows Search. Do you think that WMP uses those property handlers too? I would have to do some more checking, but I'm already fairly sure that it doesn't.
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.
> Thanks for the link, but that's for Windows Search. Do you think that > WMP uses those property handlers too? I would have to do some more > checking, but I'm already fairly sure that it doesn't.
> zachd [MSFT] wrote: >> 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. =\
Oh, I didn't notice right away that property handlers were only 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/brows...
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.
zachd [MSFT] 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.
<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.
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).
|
