Since the topic of OS X audio players and collaboration has been brought up here and here, and since I've been contacted by the author of Cog, I've decided I might as well spill some details about what I've been working on.

I've been working on a player called Euphonos, which is basically going to be setup like foobar2000, except for Mac OS X. I'll just list some of the current bits that I've been toying with so far:

- Written primarily in Objective-C/Cocoa. Some portions will be coded in pure C and make use of the CoreFoundation API, but this will only happen in the few areas where Foundation does not expose the same functionality. Stuff from CoreAudio, and a few isolated parts of the CoreData and Spotlight functionality may be this way.

- Uses CoreData for media library. The player will most likely use the sqlite method of coredata storage, which should allow effecient access to a library with hundreds of thousands of entries without a massive memory overhead.

- Uses Spotlight for all metadata handling (requires writing importers for Ape2 tags, Vorbis comments, and other currently unsupported tags). This will allow for easy searching of the media library (both within and outside of the player), as well as automatic synchronization of the media resource entries in the library with changes made to the file outside of the player. Mass tagging, smart playlists, etc., should become trivial to implement.

- Uses xml/xsl/javascript for playlist formatting. Basically, metadata from an audio resource is exposed as an xml node. To format information from the audio resource into a useful (or cool looking, whatever) entry in a playlist, you write an xslt skin that reformats the information in this node into xhtml, which is then rendered via safari's webkit. Programmatic aspects of the playlist formatting and dynamic behavior (mouseovers, animation, whatever) are handled with javascript. This essentially allows an extremely powerful, extremely flexible, and theoretically efficient approach to complex playlist formatting, yet while still relying on standardized technologies and languages. Anything that is possible via xhtml/css/javascript (dhtml in other words) is possible in the playlist view. In fact, even more can be done through the use of the canvas tag that webkit (and firefox) supports (it basically allows 2d quartz like drawing -- see here). It would also be possible to implement a javascript <-> objective-c bridge to allow lower level control of the program internals through the skinning, although if this is done it will probably be disabled by default due to security concerns. For those that are familiar with the Colloquy IRC client, this process is very similar to how it renders its chat transcript views (i.e., it uses xslt and webkit).

- Uses the plugin architecture for easy addition of extra functionality. The player will end up being modular in quite a similar fashion to how fb2k currently works.

- Uses CoreAudio, specifically newer audio api's introduced in OS X 10.4. Additional codec support would eventially (if not initially) be added through the AudioCodec API, which would have the side effect of allowing these formats to be used elsewhere in the OS. All of the modular DSP stuff will be handled this way.

- Will support Applescript (and probably other less annoying scripting languages ) -- Since the player will be able to do things like format conversions or mass tagging, it would be beneficial to allow people to interact with the program through other interfaces, and Applescript should allow this. This should also allow for supporting automator.

There's more, but I can't think of it all off the top of my head right yet. What I have as of now is not a complete player, but mostly bits and pieces of various components. Most of my time recently has been spent familiarizing myself with the new api's in OS X 10.4 and running small experiments to see how well certain ideas I've had might or might not work. I'm not certain when an initial release will roll around either, though that could conceivably be sped up if there is serious interest on both the user and developer side. Right now, there's quite an incredible amount of functionality that I have planned for the player, but only so much time to program it in...

I suppose a relatively big issue to point out is that what I'm planning on doing is only going to work on OS X 10.4. There are just too many API's that I'm relying on from that release to make a version for earlier OS releases. A significant portion of what I plan to do simply wouldn't be very practical with earlier releases unless I had a desire to reinvent the functionality provided by newer api's in my own private library (I don't).

This is basically a preview of what I have in mind or a proposal for feedback. I hadn't planned on bringing much of anything up in public until I'd reached the point of an initial release, but since the topic has come up, it seems somewhat relevant.

Sounds great. I'm not on macs too often, but when I am, I wish I had somethign like fb2k.

Sounds excellent so far. Perhaps you'd be interested to know about Apples microprocessor choice before you get started.

PPC vs. Intel doesn't matter much as long as Apple's IDE (Xcode) is used for development, future versions should make the transition pretty seamless (too bad for the CodeWarrior folks). Great featurelist btw, hope to see something come out of it. 10.4 shouldn't really be a serious issue, by the time a release rolls around the installed base should be better.

This sounds really great. I especially like this bit:



The second most requested feature would be an EAC-like ripper, but I guess xACT will do.

Pretty much all of the code that would be optimized for specific platforms (ppc or x86) will be done through the use of Apples Accelerate framework and the vDSP API. This should allow transparent optimization for either ppc or x86 since Apple will handle that part under the hood of the framework.

It wouldn't really be hard to make a plugin for ripping that used cdparanoia or something like that, but I don't plan on focusing too much on that sort of functionality initially.

Wow. Not that I use Macs at all, but this sounds really awesome! Even in the middle of the recent activity of OSX audio players development.

Oh, and by the way… So you're not an MPC developer anymore?

Sounds excellent!

So does this mean you will be working with the author of Cog, or not?

Meanwhile this sounds great. I guess I better get Tiger while I still have my education discount.

Sounds excellent. I'll definitely look forward to having a Foobar-like player for OS X, as iTunes just doesn't do much for me. Sign me up if you need testers!

No. At least not initially.

The author of Cog is more interested in working on a simpler player for now. He feels that it is necessary to make a basic player for OS X that supports many of the formats which are used around here and have it done sooner rather than later. I can't really disagree with his choice either -- my plans are certainly going to take awhile to come to something usable.

I haven't done much work on mpcenc lately. I decided that I'd rather get some sort of good audio player working before worrying about improving audio format ports.

Besides, the recent announcement that Apple will be switching to x86 has made me reconsider whether or not I should spend as much effort on ppc optimization as I was previously doing...

We'll see what happens, but for now my main focus is going to be this.

Will it be open or closed source?

Sounds great. A decent, non-iTunes, music player is the one thing the Mac really needs I think. Something that covered most of what Foobar does would be extremely useful.

Sounds like it will allow a lot of scripting, might this lead to security problems?

Anyway good luck with this project Dibrom.

Almost all OSX apps are heavily scriptable so it shouldn't pose much risk if done right.

And all Mac audio fanatics rejoiced!

Sounds cool even though I don't have a Mac.

I don't really disagree with this, but I think a good, secure audio CD ripper is needed as much, if not more so. I like iTunes well enough for managing and playing my music, but it just doesn't cut it for CD ripping, even with "use error correction" turned on. xACT, through its use of cdda2wav, is better, but it lacks many of the features of a ripper like EAC or CDex.

Yup. iTunes is good for music organizing/playback, but ripping is its major weak point right now.

If someone made an EAC-like app for OSX it would become incredibly popular.

This is great news!

We really need an alternative player for OS X.
I like iTunes, but it just don't play my Ogg Vorbis so a foobar-like player sounds great!

Thanks,

The greatest feature of this player would be the CoreAudio dependency, meaning that we could have Global codec's that can be used by any programs that use CoreAudio properly A further feature would be to release a Codec pack that add's support for the lesser audio codec's out there such as Ogg Vorbis and FLAC and such.

This should be interesting

Jan

Ogg Vorbis support has been out there for a long time via a Quicktime plug-in that somebody/some people made. Not sure if it still works with QT7 and Tiger, but it was out there. If iTunes had full read/write support of all the codecs that Foobar makes use of, then I'd agree that we'd have little use for a new player, so to speak. However, if this new player were to be more streamlined for the one thing that we're all actually interested in (playing music!), then I say go for it (and knowing that Dibrom is doing this, I have great faith--more faith than I have in that crazy and/or brilliant Steve Jobs).

As far as I understand there's been an Ogg Vorbis plugin for a long time, but it never supported Vorbis streams, which makes it sound somewhat crippled to me....

The Ogg Vorbis QT plugin is broken with QT7. I released a patch to stop the plugin from crashing whenever an Ogg Vorbis file was played. It is located here: http://forum.phucknut.net/index.php?showtopic=420

However, it just outputs silence atm. I think it's totally borked, and thats why a new implementation as a CoreAudio codec is needed

Thanks

Jan

Well, there's Whamb that does Vorbis files and streams, but it doesn't support many other formats.

Agreed 100%.

No, it does not anymore. I am still running iTunes4.7 with QT6.5.2, so I can listen to my beloved Ogg's with that plugin.

Well, I've been using a MacMini for 5 weeks or so, and the only thing I miss from my old W2K is foobar.
Sooo... keep going and make me happy, lad!

Quick update:

About ripping -- I'm not going to be focusing on this, at least initially. I'm not as interested in coding something like this as I am a general audio player. I personally think the need to playback more formats than itunes is capable, and with far greater flexibility to boot, of is more important right now than secure ripping, especially when secure ripping is already possible even if not as easily or as nicely as EAC does it. Of course, people are free to disagree, but they can take up the coding for that project if they like

About euphonos -- As I'd mentioned in the Spotlight Importer thread, I was going to wait awhile to release another update to polish things up. Well, it's going to be longer than a few days now. The metadata libraries I was using before just ended up being too inflexible and non-idiomatic for my tastes, so I've started writing my own from scratch in Cocoa.

The new metadata library uses the io code from Euphonos now, which is pretty general and 100% stream based rather than file based. This means that it'll be possible to reuse the metadata library for efficiently reading metadata off streamed files, files on a filesystem, or files in any arbitrary container format for which a reader is provided (.zip for instance).

The readers are provided in the form of descriptors which are sent bytes from the io controller, and in turn respond with messages telling the io controller what to do next. Eventually this process leads to a complete media resource description (properties and metadata), which is available for use for other purposes (playback, population of metadata fields in other applications, editing and rewriting, etc.).

The descriptors are implemented as either generic media resource descriptions (playlists, etc.), generic container format descriptions, or codec descriptions, and understand which fields to read from a stream (byte locations, types, etc.) and associated actions to perform upon encountering these. Some descriptors can invoke others for flexibility in dealing with complex nested media types.

This basically allows for decoupling of container and codec so that things like Ogg Flac or arbitrary formats embedded in MP4 or Matroska are handled easily. Supporting Ogg properly was something that was not very pretty through the previous spotlight importer (it was working eventually but required hacks), and one of the reasons I decided to write my own library from scratch.

Since the descriptors are kept apart from the decoders, it should be easy to add support for reading properties and metadata tags from formats for which decoders do not exist yet (essentially what I was doing with the spotlight importer already -- this will just allow me to do it easier) or do not apply (playlists, etc.), but for which the container format, bitstream, or general layout is well known and documented. It also allows for cleaner decoder implementations that don't have to be cluttered with other io tasks.

This is just a really rough overview of how things are shaping up right now. Things are a little more complex in code of course and don't work quite exactly how I explained them, but it's close enough . What this means feature-wise is that:

- Reading from and writing to arbitrary locations and media types will be possible through streams and descriptors. This includes easy network streaming, casting, format conversion, etc.
- Generic container formats will be supported from the beginning as a design decision rather than an afterthought which requires hacks and massive redesigns.
- The metadata library for euphonos should be easily reusable in other cocoa projects, which should hopefully help to improve the quality of other audio tools on os x.

Have you considered implimenting some of the foobar SDK in order to make porting plugins easier? Obviously things like GUI plugins would be useless, but DSPs/decoders/ipod/tagging might be much easier to develope if foobar's plugin's could be used as a starting point.

I thought briefly about trying to copy some of the SDK stuff early on, but it wouldn't work well for a few reasons. The biggest reason is that I'm using Objective-C and Cocoa, and Peter is using C++ and win32 API's. The two are just so different that this sort of thing wouldn't work. You can use something called Objective-C++ which lets you mix syntax from both languages, but it's kind of messy and I think would promote poor design overall, and it wouldn't solve the API problem, only the language one. (This isn't to say that people can't write plugins for Euphonos unless they use Objective-C by the way, it just means that the code at the plugin layer will either need to be written in Objective-C, or will need to make use of Core Foundation and the "toll-free bridged" C counterparts for Foundation classes).

Most of the underlaying player structure is ending up different enough from the way foobar2000 works (as far as I understand) to where even some of the design ideas probably wouldn't translate across as well, if the language and API issues weren't a problem.

However, for most well coded plugins, if the underlying parts (the bits not reliant on the fb2k api) are cross-platform and well designed, it shouldn't be that hard to translate them over. I do plan to probably make use of some of the code from fb2k DSP plugins and other things (where source is available and makes sense to use) that I am able to, although I will have to recode the plugin layer.

Once x86 Mac's start popping up, it might be possible to write an interface that would allow certain foobar2000 plugin binaries to be used with Euphonos, but I wouldn't count on this being a very practical feature in any case.

What I guess I'm betting my hopes on as far as getting people to make plugins and other extensions is that Euphonos will provide a clean, well documented, and easy to use API that will make writing these things quick and pleasant. Of course, who knows if that's how it will work out, but I think it's the best option. There seems to be interest from people in having this sort of media player "platform," but so far nothing for it on the Mac quite exists yet. Hopefully these same people will take advantage of it when it does arrive.

Sounds extremely well thought out, so far. Can't wait to hear more news!

You probably aren't really taking feature requests, but i thought I'd throw this out there. It's an idea that I've had toying around my head for a while now. It may be beyond the scope of the application your trying to develop, but I don't have time to even think about trying to build something like this now, and I don't have the skill.

Anyway...

Basically the concept is a client/server music system. All the music is stored in one central location, accessed only by the server. I haven't worked out all the specifics in my head yet (eg. does the server stream to the client? Does it stream decoded or undecoded data? Does it just send the location of the file?).

The advantage to using a client/server system is all in databases and tagging. By having one central location for all the music, real playback statistics can be gathered, and then stored in a database (and not in the files tags). If you use file tags to store playback statistics, you can have all your music in a central location and have communial playback statistics. But, for example in foobar, where you have each client with it's own database, playback statistics that only get stored in the database won't work (because there only stored by the client). If the server were to stream data to the client, it also would not require the client to have any file permissions on the server, only that the client/server can commuincate using TCP/IP on a specific port. This way, even network users with very limited access could listen to the music stored on the server, as long as they had the client installed.

Like I said, I've only really kicked this idea around in my head briefly. I realise it's a lot more work to do it this way. I don't have a Mac, so I'm not asking you to consider doing this for my benefit. It's just something I thought I'd post for you to think about. There are probably other advantages to using a client/server system that I haven't thought of, and some disadvantages. Something to mull over.

[Offtopic]
On the subject of Macs, if there was a program on Mac that offered the same functionailty as foobar2000, I'd switch to Mac. iTunes just isn't good enough, but my Windows apps aren't poor enough to justify switching. foobar2000 is essentially the only thing holding me back.

A question, what IDE's are available on Mac for Objective-C, or other C Style Languages? Basically is there a Visual Studio type IDE for Mac?

It actually wouldn't be very hard to do what you're talking about. I've thought a little bit about distributed playback and stuff kind of like that already, and most of it should be possible. The IO is already stream based, and most of the other parts could deal with network distribution and communication just fine. I probably wouldn't support this sort of playback model as the primary mode of use, but I don't see why it shouldn't be quite easily doable with a plugin.

As far as playback statistics are concerned, Euphonos already has an internal database apart from the metadata of individual files, similar to how foobar2000 works. Statistics on all sorts of things could be stored there without ever touching the actual files themselves. Only limited amounts of information added to the database will ever be written back out to the files (mostly user tags that map directly to a given tag for whatever tagging format the file supports).



There is XCode which is very, very good IMO. I like it quite a bit better than Visual Studio. It offers pretty much everything you would expect from an industrial grade IDE, such as syntax highlighting, code completion, user specifiable hierarchical groupings (classes, symbols, errors, files, along with smart filters, etc.), probably the best WYSIWYG user interface construction system every created (Interface builder, harkening back to the NeXT days), visual data modeling, a debugger in the form of gdm (along with fix and continue -- a form of debugging where you can modify running code and watch the change in realtime), very advanced and capable build systems which are able to manage practically every scenario you can think of, even complex scripted builds, revision management, distributed builds, etc., etc., etc.

The user interface for xcode is very non-intrusive and quite intuitive. You can use it pretty minimally or dig quite deep into the system to exploit a lot of power, but either way it remains very usable.

Oh, and it's free with OS X.

But that's just the IDE. You also get some incredibly powerful profiling tools with CHUD on OS X for free too. They let you do things like run cycle accurate models of the cpu to profile code down at the instruction level, or examine profiled output in C and asm along with platform specific optimization tips in Shark (tells you about cpu stalls, non-byte aligned loops or functions, opportunities for vectorization, LSU rejects, opportunities for invariant removal, etc.). You can see some shark examples here and here.

Hope that answers your question. I'm always a bit amazed at the Apple dev tools.. they're probably the highest quality I've ever used or seen, for pretty much any price, and they're free. They have some excellent high performance vector libraries too if you're into that kinda stuff (their fft (vDSP) is amongst the fastest around -- quite a bit faster than fftw, and certainly faster than any other free implementation).

Well when you release version of this program that offers even half the features of foobar2000, you'll have brought a new Mac user to the clan, because I will be switching.

With these apps being free, I'm surprised there isn't more mac software. I know the install base is relatively small, but these tools are impresive (at least they look impresive).

sounds kind of like slimserver (runs on OS X, linux, windows).

Josh

Well the basic idea is certainly like SlimServer. Seeing as it's a commercial product (as far as I can tell) I don't know a whole lot about it. The key to my idea is really the database information. It's all fine and good that you have all this information about your file, but we should be looking for powerful ways to exploit it. You could keep playback statistics for every person who used the system. What songs they played, what time of day they played them. I know, I know, I could sell this information on to marketing agents .

But in all seriousness, we should be so far beyond the very limited number of uses we have for this data. The two coolest things I've seen done of late are Audioscobbler (so not that recently) and the 'hotness' experiment for foobar. If more people can think outside the box like this, and exploit the vast amount of data we can collect, we can really start to see some cool applications.

slimserver is open source. it is officially supported by slim devices I think only for their hardware but there are also software clients out there.


totally agree. there has been very little foray outside of what is possible with id3v1 because it is the lowest common denominator and works acceptably for pop. anything more advanced becomes a big undertaking because of widely varying user demands. at the time I started FLAC I also had plans for such a thing (and a few other related projects) but I just don't have time. I ended up rolling my own system for what I need. when I get the time I want to try bridging it to slimserver via their plugin architecture as the squeezebox is a very neat device.

Josh

As someone who switched from Windows back to Mac OS a year and a half ago I can say the only thing I miss about my PC is Exact Audio Copy and Foobar2000 along with single FLAC files+CUE sheets. I'm looking forward to the first beta release of this. My only suggestion is the ability to have Foobar-like formatting strings. That would rule. I really like the Spotlight metadata idea too. Anyhow good work, just wanted to add my voice to the chorus of Mac users who appreciate this undertaking.

This would be great. With Whamb, Macamp Lite X, Audion, etc. out of the picture (and XMMS never particularly well implemented), this is very much welcome news. Looking forward to updates as you progress.

Same thing here! I want get off Windows forever. My next computer will be a Mac.

Offtopic, but I wonder if we'll see people running OSX illegally on Intel via stolen bios.
Nah, probably not, except for China maybe.

Thanks

The foobar2000 like formatting strings will basically be accomplished through string manipulation with javascript, at least for everything not practically accomplished with XSL. Since javascript is a full blown programming language, it wouldn't be very difficult for someone to provide a set of convenience functions mapping the general functionality of TAGZ in foobar2000. I will probably provide some sort of guide to get people started with this kind of thing.

At any rate, a whole lot of things have changed under the hood since I first announced this thing, but they're also changing so fast that I should probably wait until everything settles down a bit more before going into detail. But concerning playlist formatting, there's some very, very cool new stuff that's going to go into the player that will be unlike anything most people have seen before

I greatly look forward to releases of this project . I've come to enjoy iTunes quite a bit, but i'd be lying if I said that I didn't miss the simplicity (and scalability) of a player like foobar.

Dibrom, I have a short question regarding Euphonos:
* Do you have plans, or already implemented AirTunes support?

This would be a killer feature for me, since I stream to my AirPort Express 95% of the time. Currently iTunes is the only audio player with this feature.

Even if it isn't implemented directly you could use an app like AirFoil

Bringing XML/XSLT/JavaScript/XHTML into the picture is a brilliant approach to customization of playlists. I'm guessing if this thing works out you'll be an early adopted to an approach many will mimick.

No plans for that yet. I'm still hammering out low level design details so I haven't gotten around to higher level features like that. It is something I would like to support though, and will probably do so if I can.

If I were to support this, it would probably be in the form of a dsp plugin. All other audio outputs are currently handled in this way. The DSP system in Euphonos now makes use of AudioUnits. AudioUnits are similar to VST plugins, except they make direct use of coreaudio and are more powerful overall. Many of the applications like Logic and the like are using audiounits now for example.

So the same with any other audiounit, if someone were to make one that supported sending data to the airport express (maybe someone already has?), Euphonos could make use of it with no further modification necessary.

It shouldn't be hard at all to make an audiounit for this. There already exist ones for streaming audio between two computers remotely for example, as well as units that send output to various different hardware devices.

So someone else could add support to Euphonos for this if they wanted, but if nobody else does, perhaps I will do it myself when I get far enough along to start focusing on those type of features.

Yeah, I think this will work out pretty well. But the thing I'm working on now for playlist customization (which will be usable in conjunction with the XSLT stuff) is even better I'll give more details about it when I'm further along with it, but it's based on some really cool new stuff that came with 10.4..

Thanks a lot for the detailed reply.
Since I'm no programmer myself, I had no idea it this was a low or higher level feature. But I know now!

Cant wait to get my hands on this player when its ready for testing.
Keep on coding...