Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.

Poll

which do you like?

media foundation/directshow.
[ 3 ] (20%)
proprietary foobar plug-ins.
[ 12 ] (80%)

Total Members Voted: 26

Topic: media foundation/directshow foobar or plug-in based (Read 7320 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

media foundation/directshow foobar or plug-in based

please explain about pro & cons of changing foobar core from proprietary plug-in base to media foundation, directshow host.

media foundation/directshow foobar or plug-in based

Reply #1
Aaaahahaha, if you only knew what's been going on behind the scenes...

Suffice it to say, probably not gonna happen. If you need a reason, it's because compared to foobar2000's defaults, the alternative sucks.


media foundation/directshow foobar or plug-in based

Reply #3
Let's see. Media Foundation codecs have been tested, and it's been found:

1) They only have minimal floating point output support, usually clipping the output to +/- 1.0 even though the whole point of floating point is not to clip the output.
2) The Media Foundation AAC codec doesn't even support floating point output.
3) DirectShow doesn't even guarantee floating point output, it uses whichever format the decoder wants, which is usually 16 bit integer PCM.
4) Some of these decoders even do their own file reading instead of supporting a reader and/or splitter filter, possibly supplied by the caller.
5) Developing for DirectShow and/or Media Foundation codecs would mean that the developer would need to buy and test every possible alternative decoder for every format, as different decoders would have different quirks and/or limitations.

Really, none of these hassles are worth supporting the system when bundling your own decoder affords much more control over the quality and all these programming issues.

The only "pro" that even seems to appear in that other topic is that you have the privilege of paying someone for your decoders, with the hope that something with your money and some company's alleged years of experience in the field of developing decoders which can't be any more adherent to their relevant standards than any other compliant decoder behind it gives you the warm fuzzies and foot tappety-ness every time you listen to it.

media foundation/directshow foobar or plug-in based

Reply #4
you've already asked this. :/

http://www.hydrogenaudio.org/forums/index....showtopic=86835

i'm not going to pretend i understand everything being talked about there but i don't see any "pros".


think before posting please, this thread is about pro & cons (expert opinions), not feature request.

Let's see. Media Foundation codecs have been tested, and it's been found:

1) They only have minimal floating point output support, usually clipping the output to +/- 1.0 even though the whole point of floating point is not to clip the output.
2) The Media Foundation AAC codec doesn't even support floating point output.
3) DirectShow doesn't even guarantee floating point output, it uses whichever format the decoder wants, which is usually 16 bit integer PCM.
4) Some of these decoders even do their own file reading instead of supporting a reader and/or splitter filter, possibly supplied by the caller.
5) Developing for DirectShow and/or Media Foundation codecs would mean that the developer would need to buy and test every possible alternative decoder for every format, as different decoders would have different quirks and/or limitations.

Really, none of these hassles are worth supporting the system when bundling your own decoder affords much more control over the quality and all these programming issues.


good explanation.
then why apps like mpc-hc are still directshow base?

media foundation/directshow foobar or plug-in based

Reply #5
They started as DirectShow based. Most of these issues don't even matter to most developers, especially if they started with DirectShow. DirectShow would be a step backwards for foobar2000.

media foundation/directshow foobar or plug-in based

Reply #6
then why apps like mpc-hc are still directshow base?
For the same reason that many movie rips use 128kbps VBR: sound quality isn't a huge concern.

media foundation/directshow foobar or plug-in based

Reply #7
yes but: mpc-hc's internal decoders, demultiplexers, navigators, etc are incomplete & buggy.
sometimes lags a lot with any system (low to high-end systems).
energy efficiency leven of mpc-hc is very low.
incompatible with lots of 3rd party directshow & dx plgu-ins.
design efficiency is terrible.

but i can't find any issue for foobar.
are foobar decoders, demultiplexer 100% complete?
i know foobar's aac demultiplexer  is incomplete.

media foundation/directshow foobar or plug-in based

Reply #8
MPC internal filters are direct show filters.

media foundation/directshow foobar or plug-in based

Reply #9
MPC internal filters are direct show filters.


yes of course.
you can download stand-alone pack from xvidvideo.ru

media foundation/directshow foobar or plug-in based

Reply #10
i know foobar's aac demultiplexer  is incomplete.


AAC is not a container, it is a codec. foobar2000 intentionally has limited support for AAC which is not wrapped into a container of some sort. Raw AAC files have no tagging standard, and like MP3, require fully scanning the entire file to support length detection and seeking. Although unlike MP3, Peter has chosen not to bother with that, since AAC has multiple proper container formats which already support tagging and seeking, such as MPEG-4 and Matroska.

media foundation/directshow foobar or plug-in based

Reply #11
i know foobar's aac demultiplexer  is incomplete.


AAC is not a container, it is a codec. foobar2000 intentionally has limited support for AAC which is not wrapped into a container of some sort. Raw AAC files have no tagging standard, and like MP3, require fully scanning the entire file to support length detection and seeking. Although unlike MP3, Peter has chosen not to bother with that, since AAC has multiple proper container formats which already support tagging and seeking, such as MPEG-4 and Matroska.


i agree with you.
what sdks foobar use? (official or alt sdks for decoders, demux)

media foundation/directshow foobar or plug-in based

Reply #12
MP3 format parser: Peter's own code.
MP3 decoder: All original decoder by another developer.
ID3v1, ID3v2, and APEv2 tag writing: Peter's own code.

MP4 parser: Peter's own code.
AAC decoder: FAAD2, under special license.
Nero and Apple MP4 tag writing: Peter's own code.

Musepack decoder: New adaptation of the original decoder, which was later adapted yet again by other developers into an all-C solution.
APEv2 tag writing: See above.

WavPack stream format and decoder: Official WavPack library.
APEv2 tag writing: See above.

Ogg container parser: libogg.
Ogg Vorbis decoder: libvorbis.
Ogg Speex decoder: libspeex.
Ogg Vorbis tag writing: Based on vorbiscomment.

FLAC stream format and decoder: libflac.
FLAC tag writing: Also based on vorbiscomment, I think.

Matroska parser: Peter's own code.
Matroska tag writing: Also Peter's own code.

All bundled decoders and container parsers have been thoroughly fuzzed.

media foundation/directshow foobar or plug-in based

Reply #13
what about wma?
what's difference between official & alt (peter's & others) sdks (quality, speed, stability, etc)?

media foundation/directshow foobar or plug-in based

Reply #14
WMA: Microsoft Windows Media format SDK.
WMA tag writing: Same as above.

media foundation/directshow foobar or plug-in based

Reply #15
thanks.
you forgot to answer: what's difference between official & alt (peter's & others) sdks (quality, speed, stability, etc)?

media foundation/directshow foobar or plug-in based

Reply #16
MP3 decoder quality: Follows the standard. Fast enough. Thoroughly tested for stability with bad files.
MP4 container parser: Ditto.
Matroska parser: Ditto.

If you need actual benchmark comparisons, I suggest you knuckle down and install AviSynth so you may benchmark compare your DirectSound decoders, albeit with the overhead of AviSynth.

 

media foundation/directshow foobar or plug-in based

Reply #17
no, don't want to bench.
thanks.

media foundation/directshow foobar or plug-in based

Reply #18
I know it’s a milion times repeated theme, but I want to utilize this thread, which I find quite interesting, for it and not to start something new.
This was maily about utilizing the codecs related to either dshow/mf pipeline by fb2k, and what are the (dis)advantages.
The facts about MF codecs (floating point output support, clipping etc.. ) seems strange for me, I don’t understand if its related only to some specific existing codecs (so its possible to make better ones) or because of principal MF defect, you’ve generalized it in pt. 1) (kode54)
In the point 5) you (kode54) maybe meant developing media/audio apps, that will relly on existing MF codecs (MS or third-party), but making an app together with MF codecs could solve the problem. The question: if we are talking about audio, in MF pipeline, is it possible from principle to coexist more codecs for the same format, that the audio app could choose one of them? In dshow this could mean a problem, but what’s the case of MF? (I mean if I make an MF pipeline app without codecs, I need to specify among existing codecs, or the selection is up to an app without a conflict)

Now to my main point, i address the first sentence mainly for this.
Is there a difference in resampling quality when using different higher level APIs for output? (dsound, waveout or MF). Simply I want to find out all system components, where the possible resampling takes place (because upconverting to 32bit float occurs in audio engine, it doesn't make sense converting sample rate before that, so for dsound or waveout its the same).
MF app (e.g. WMP12) calls resampler dmo (resampledmo.dll), that is clear. The conversion quality can be adjusted by a programmer of an app that calls this component, from 1 to 60, but its adjustable also for existing apps? Was this component created (doesn’t exist in XP, or?)) only to scale  protected HD content or it provides better quality, don’t know.

Thanks for clearing this.


media foundation/directshow foobar or plug-in based

Reply #19
Is there a difference in resampling quality when using different higher level APIs for output?

The only time resampling has ever been an ABX-able, yet "hidden," problem for end users was with 10-year-old soundblaster cards.
elevatorladylevitateme

media foundation/directshow foobar or plug-in based

Reply #20
Even if the floating point and clipping problems were only related to specific codecs (in this case, the ones that come with Windows 7) then you're right back to bundling codecs anyway, since you have to at least include something which doesn't suck, or else you have to tell the user they need to find and install something which doesn't suck.

media foundation/directshow foobar or plug-in based

Reply #21
Is there a difference in resampling quality when using different higher level APIs for output?

The only time resampling has ever been an ABX-able, yet "hidden," problem for end users was with 10-year-old soundblaster cards.

Thanks for comment, but i meant objective measurable quality differences resulting from using, let's say, "legacy" APIs, because different dlls are called when using either of them. The simple question is, when app uses e.g. dsound output and resampling is needed (audio driver is set to different value), where in W7 does it happen, thats all. Its quite possible, that MF rellied app calling resampler dmo component has different resampling quality than non-MF app calling e.g. dsound.dll, when resampling occurs in audio engine or elsewhere.   
It wasn't about audibility.

media foundation/directshow foobar or plug-in based

Reply #22
Even if the floating point and clipping problems were only related to specific codecs (in this case, the ones that come with Windows 7) then you're right back to bundling codecs anyway, since you have to at least include something which doesn't suck, or else you have to tell the user they need to find and install something which doesn't suck.

According to what you wrote, MS doesn't have bigger chances for wider MF pipeline usage extension among media apps developers, who care more or less about quality, its strange while it was mostly intended to commercial apps for hd playback. 
MF is here 4 years, last two years with extended codecs support, and i don't know any app except some MS apps, that uses it.
Concerning to standalone MFT codecs creation, i don't know where is the truth. People berate MS for non providing e.g. flac support among others formats, on the other side MS claims codec support is expandable by third-parties.

media foundation/directshow foobar or plug-in based

Reply #23
So adding DirectShow support for emulated formats?

ROFL.

Why?