next »

[Sam_Zen]

I've run a series of tests about the playing of most common formats, audio and video, by different apps :
http://www.xs4all.nl/~samzen/media/mediaplay.html

[Dotpitch]

XMPlay does support Real Audio.

[Pike84]

Since when?

A pre-condition for the software involved in the testing:
No install needed of external drivers, plugins, etc...

By the way, the test shows that XMPlay would support WV, which is WavPack, but I don't see it in the integration options (nor do I remember any discussion about this format). A mistake?

[Tsorovan]

http://www.un4seen.com/filez/2/xmp-wv.zip

[Dotpitch]

Since when?

xmp-ra needs the dlls from RealAlternative, but you don't have to have  RealAlternative installed. Just the files is enough.

MPC will not work if Real Alternative is not installed on the host's computer (correct me if i'm wrong!). Whereas XMPlay and Fraggie's plugin allows the Real Alternative codecs to be portable.

[Pike84]

None of these still work out of the box, so...

[Dotpitch]

None of these still work out of the box, so...

True, you're right .

[raina]

XMPlay requires external SoundFont files to produce sound out of MIDI files.

[r]

Since when?

xmp-ra needs the dlls from RealAlternative, but you don't have to have  RealAlternative installed. Just the files is enough.

MPC will not work if Real Alternative is not installed on the host's computer (correct me if i'm wrong!). Whereas XMPlay and Fraggie's plugin allows the Real Alternative codecs to be portable.

Just for reference... a link to a post I made about how to make RealAlternative portable for XMPlay:
http://www.un4seen.com/forum/?topic=5370.msg56867#msg56867

[Sam_Zen]

Pike84 has a nice expression 'work out of the box'. I didn't want any external items needed in this test.
Although I consider some XM-plugins, like Tsorovan mentioned, as internal add-ons of the native package.
2 raina
The MIDI format is a tricky one, and it heavily depends on local settings and Soundfonts, so I restricted the test
to see if any reasonable sound came out or not.
In the meantime, I've made a file with a collection of different formats in the same dir, to test a player :
http://www.xs4all.nl/~samzen/media/divmedia.7z

[Pike84]

Can't take credit for the stuff not stuffed in boxes - a pretty common expression that one .

So uh.. what about WavPack?

[Brian]

Sam_Zen: Can you just clarify what you're trying to find out with these tests, please? Also, it seems unsatisfactory to exclude certain players simply on the grounds that you don't use them.

[Jace]

Can you just clarify what you're trying to find out with these tests, please?

Maybe a differently laid out version of something like this?

[Rah'Dick]

The problem with the "out of the box" expression is, that XMPlay doesn't come in just one "box", much like your bigger IKEA furniture comes in two or three boxes all belonging to the same product.
I consider native plugins developed or at least signed by the author of the original "host" application as "part of the product". It's a modular approach, not a monolithic one.

[Brian]

Maybe a differently laid out version of something like this?

If that's what it is, it doesn't seem to be a test, more like a comparison of already known format support (which is certainly a worthwhile exercise). I had the impression that Sam_Zen was looking to find out how well the various formats actually play.

I don't think it has yet been made clear why it's desirable to focus only on native features and plugins. For example, XMPlay supports the playing of uvox AAC streams using in_mp3.dll, whereas most other players don't. That's a useful point of comparison in my book.

[Sam_Zen]

I think Brian has got the the right perspective about my publication.
I'm not trying to win from WIKI sites about this, covering every format with every player.
It's just meant as a survey of tests, checking a grid of data and apps.

In the meantime, I noticed that I will have to adjust this page, due to several reactions.
( I placed this link on four other media-forums as well, and got a lot of response there too)
So I will add some reports with other players to this page.

it's desirable to focus only on native features and plugins

Not a matter of being 'desirable'. I just wanted to test an executable as 'independent' as can be.
So I make a difference between a plugin added from the XM-site, or needing data from Adobe.

[Sam_Zen]

Made some corrections. Replaced 'Moyager' by 'SMPlayer'.
Made the page more accessible for screenreaders.

[Brian]

Thanks for the update.

If you are now including native plugins, as appears to be the case, then XMPlay supports the playing of RA, as Dotpitch pointed out. The plugin is still in beta, but it now works fine, at least on my system.

It's strange to list MPUI and SMPlayer as different players, as they are both just front-ends for MPlayer and have no format support in their own right as far as I know. However, you seem to be saying that SMPlayer supports the playing of APE whereas MPUI doesn't - I wonder how that comes about?

[Sam_Zen]

Nice, I will check out the RA plugin.... I did, and I have my doubts about it.
It's still a construction where one needs some 'alien' .dll(s), in this case RealAlternative, to get it right.

Let me clarify, that, when I started this page, I had only a faint idea about a common file MPlayer, having different front-ends.
So it could be right to consider MPUI and SMPlayer as just the same player, with a different coat.

SMPlayer supports the playing of APE whereas MPUI doesn't

I tested this again. Same result. MPUI produces harsh noise.

[Brian]

The real codecs have to be deployed to play RA, with any player whatsoever. So I would say that there's no distinction to be made between players in that respect - it's just a question of whether they provide a functioning plugin to access the codecs.