I apologise if this is an overly silly usage question...

I am quite keen to buy a Mac Mini (Intel Core Duo one) to use with an LCD monitor in another part of the house, and ITunes would seem to be the music player of choice on that box.

If I have my music library being served from its current (Windows) server by Firefly (and also Twonkyvision), what will be the experience of being able to play that music on the Mac using Itunes?

* Will it work at all (I am guessing the DAAP and Rendezvous implementation in Firefly will make it appear as another ITunes server to ITunes on the Mac)?

* What will happen with any WMA files that are in the library being served from Firefly (and which serve just fine to my Soundbridge)? Will the "player" copy of ITunes do an on-the-fly format conversion to MP3 when playing, will it ignore files in lists it is sent by Firefly with a .wma extension? I don't want the WMA files transcoded by Firefly because they don't need to be for use with the Soundbridge - just served as-is, but ITunes transcodes WMA files to MP3 when they are "local" to it, doesn't it?

* Is there some other player software I should use on the Mac instead which will co-exist better with a Firefly DAAP server (or Twonkyvision using UPNP AV for that matter), given my music library has more WMA files than MP3, and that isn't about to change? Rather than serving to the Mac at all from a server application, should I just map the folder on the server as a network drive on the Mac and use it "directly" - and again which player app would be most suitable for that?


Thanks,

ted.h.

Ted Harper wrote:

If I have my music library being served from its current (Windows) server by Firefly (and also Twonkyvision), what will be the experience of being able to play that music on the Mac using Itunes?

Should work over daap just fine. In fact, the version you already have works fine with FrontRow as well -- including serving m4v movies.

* Will it work at all (I am guessing the DAAP and Rendezvous implementation in Firefly will make it appear as another ITunes server to ITunes on the Mac)?

Yes, and yes.

* What will happen with any WMA files that are in the library being served from Firefly (and which serve just fine to my Soundbridge)? Will the "player" copy of ITunes do an on-the-fly format conversion to MP3 when playing, will it ignore files in lists it is sent by Firefly with a .wma extension? I don't want the WMA files transcoded by Firefly because they don't need to be for use with the Soundbridge - just served as-is, but ITunes transcodes WMA files to MP3 when they are "local" to it, doesn't it?

WMA won't play from iTunes over daap without being transcoded, so until win32 transcoding is implemented, that won't work.

* Is there some other player software I should use on the Mac instead which will co-exist better with a Firefly DAAP server (or Twonkyvision using UPNP AV for that matter), given my music library has more WMA files than MP3, and that isn't about to change? Rather than serving to the Mac at all from a server application, should I just map the folder on the server as a network drive on the Mac and use it "directly" - and again which player app would be most suitable for that?

I don't know any offhand -- I tend to think that FrontRow is probably hands down the best music/video/picture front-end around.

Maybe someone else has better ideas?

-- Ron

Thanks for the response!

I guess my question boils down to "what is the best way to use Firefly to serve (1) a Soundbridge and (2) a Mac running iTunes, where some of the files need to be transcoded (differently) for (1) vs (2)".

If there was protocol-specific (or output-plugin-specific) transcoding that would be good, wouldn't it? I mean when serving via RSP to a Soundbridge I would want to do some particular transcoding (eg Apple Lossless to something the Soundbridge likes, but WMA can be sent as-is) and when serving via DAAP to iTunes I would need some different transcoding (eg WMA to MP3, but Apple Lossless can be sent as-is).

Is support for that kind of non-trivial (but possibly quite common - eg for people with some content in various lossless formats, as well as my WMA case) scenario designed in to Firefly, even if it might not be able to be implemented in the Firefly 1.0 timeframe?


ted.h.

Ted Harper wrote:

Is support for that kind of non-trivial (but possibly quite common - eg for people with some content in various lossless formats, as well as my WMA case) scenario designed in to Firefly, even if it might not be able to be implemented in the Firefly 1.0 timeframe?

In a 1.0 timeframe, it will do transcoding generally -- all .wma files to .mp3 or .wav (your choice). The stuff is all in place to make it transcode on a per-user-agent basis, but it probably won't all get implemented by 1.0. 1.1, maybe?

-- Ron

I now have my Mac Mini (Core Duo version), and the behaviour of itunes on it when accessing my Firefly library is "as expected", but not at all wife-friendly.

That is, it sees and shows all the WMA-formatted music, but then doesn't play it (since it has no reason to think that a DAAP-presented remote music library could be serving anything that iTunes can't play directly), and unfortunately - and again understandably - doesn't give any visual indication of the format of the tracks.

That "user-agent specific transcoding" would be a Really Good Thing for this scenario of serving to both a Soundbridge and an iTunes PC (and I reckon also for people with the various non-universal Lossless formats).

If the per-user-agent transcoding isn't possible in the 1.0 timeframe, in the meantime could Firefly please at least NOT show WMA files to a player device connected via DAAP (also also suppress any other format that a "normal" DAAP client couldn't play) - with a "StrictDAAPFileTypes" switch or something in the firefly config file. Soundbridges will be using RSP, and ITunes doesn't handle unexpected media types well, so this would be a good interim measure if it could be added.


ted.h.

rpedde wrote:

In a 1.0 timeframe, it will do transcoding generally -- all .wma files to .mp3 or .wav (your choice). The stuff is all in place to make it transcode on a per-user-agent basis, but it probably won't all get implemented by 1.0. 1.1, maybe?

-- Ron

rpedde, don't forget transcoding on a "per codec" basis. A .WMA is a container. It could have WMA, which SB can play. But it can also have WMA Lossless, which it can't... and needs transcoding. (There is also WMA Pro, WMA Voice, etc. -- all not natively supported.)

Side note: Would it be possible to add an "exclude by audio codec" eventually? No point in serving content if it can't be played or transcoded. (For example, WMA Pro... I don't expect you to ever support transcoding that... unless you end up putting code in to "transcode" using the Microsoft API, which would be Windows only.)

grommet wrote:

Side note: Would it be possible to add an "exclude by audio codec" eventually? No point in serving content if it can't be played or transcoded. (For example, WMA Pro... I don't expect you to ever support transcoding that... unless you end up putting code in to "transcode" using the Microsoft API, which would be Windows only.)

Yeah, all this stuff is all doable and available in the current implementation. Right now, the codec for .wma files is "WMA", but I'll break that down into "WMA/WMAL/WMAP/WMAV", etc, and the transcoding is already done on a per-codec basis (had to, in fact for m4a aac versus m4a alac).

As soon as I finish the ffmepg transcoder, I'll start on a w32 only transcoder for wma. As you say, it won't work on non-w32 platforms, but only w32 people have wma lossless files, so it probably works out okay anyway.

I might just bolt together the ffmpeg and wma dlls and make a wma->flac converter for those people on win32 that want to serve from linux, as well.