PDA

View Full Version : Apple's ALAC now open source!



bjs
2011-10-27, 17:47
Interesting news:

http://www.tuaw.com/2011/10/27/apples-alac-codec-is-now-open-source/

Personally I think this is great news. I currently keep my music library in FLAC format. But we're an Apple house, and lately I've been considering converting it to ALAC so that everything works better with our iPhones, and Macs. I'm curious as to what this news may mean for Squeezebox Server, in terms of how it decodes ALAC files.

wazza
2011-10-27, 18:29
I believe ALAC has been supported by squeezebox for a while, but without the ability to seek within the track.

This is great news, and hopefully the seek feature will finally be available in the next release.

I too was wanting to convert my flac library to ALAC, simply due to the fact there's no good tools for tagging of flac files for mac, and also the added portability across IOS devices

andyg
2011-10-27, 20:17
ALAC seeking is supported. But yes this is great news, we can finally implement the official decoder.

paulster
2011-10-27, 21:20
This is great news. Even better would be Apple adding support for FLAC to their products but this is a great step forward for lossless audio!

Grumpy Bob
2011-10-27, 21:58
I believe ALAC has been supported by squeezebox for a while, but without the ability to seek within the track.

This is great news, and hopefully the seek feature will finally be available in the next release.

I too was wanting to convert my flac library to ALAC, simply due to the fact there's no good tools for tagging of flac files for mac, and also the added portability across IOS devices

I use Kid3 (http://kid3.sourceforge.net/) on my MacBook Pro for tagging audio files of many formats, including flac.

R

erland
2011-10-27, 22:18
Are there any advantages of using FLAC now when ALAC is open sourced ?
Is FLAC still better supported in Squeezeboxes ?
Is FLAC still better supported in other software/hardware players ?

The big advantage with ALAC from my perspective would be that suddenly I can use the same files both in Squeezebox and Apple ecosystem.

paulster
2011-10-27, 22:25
Are there any advantages of using FLAC now when ALAC is open sourced ?
Well, it may have been open sourced but the likes of Logitech still have to develop decoders for it allowing full use of the specification (seek, etc.) so FLAC still has the advantage for the time being.


Is FLAC still better supported in Squeezeboxes ?
See above. FLAC is natively supported on IP3K players; I don't think ALAC is even with the current decoder and I'm sure no-one at Logitech is going to try to shoehorn another decoder into what little is left of room in the IP3K firmware.


Is FLAC still better supported in other software/hardware players ?
Who is to say, but the decoder for FLAC is based on genuine specs rather than reverse-engineering in the case of non-Apple playback devices, so these are going to have to play catch up to get the current spec of ALAC decoder running.


The big advantage with ALAC from my perspective would be that suddenly I can use the same files both in Squeezebox and Apple ecosystem.
That is a big advantage if you're an Apple user. As I said in my first reply I'd be happier if Apple adopted FLAC but I guess their corporate pride is trying to keep their format afloat rather than adopt somebody else's.

Mnyb
2011-10-27, 23:17
Yes this was unnecessary , there are already to many formats would have been better if apple incorporated FLAC in their products.

But that's thinking beyond pride and short term profit .

pipe dream :

1 lossy and 1 lossless format, with a tagging/metadata system endorsed and understood by both users a record companies a true music file standard.

Everybody would benefit in the long run.

This whole market is flawed by the lack of commitment by the actual content providers . The apple ecosystem can be seen as a "proof of concept" on one way to make a music market, but to closed for me.

what if RIAA actually did their real work ;)

cliveb
2011-10-28, 00:51
Personally I think this is bad news. It is the thin end of a wedge that will see ALAC slowly surplant FLAC as the de-facto lossless codec of choice. I don't trust Apple's motives. Just because this particular release of their codec is now in the wild does not mean future versions will be. I predict that once Apple has rendered other lossless codecs obsolete, they will "improve" ALAC and keep it closed source, then extract lucrative licence fees from all the third parties who have followed the herd.

This quote from the article has it completely backwards:

If more people begin adopting ALAC instead of FLAC, it'll make life a lot easier for audiophiles.
Rather than everyone else adding support for ALAC, wouldn't it just be easier for Apple to support FLAC?

Mnyb
2011-10-28, 00:58
personally i think this is bad news. It is the thin end of a wedge that will see alac slowly surplant flac as the de-facto lossless codec of choice. I don't trust apple's motives. Just because this particular release of their codec is now in the wild does not mean future versions will be. I predict that once apple has rendered other lossless codecs obsolete, they will "improve" alac and keep it closed source, then extract lucrative licence fees from all the third parties who have followed the herd.

This quote from the article has it completely backwards:

Rather than everyone else adding support for alac, wouldn't it just be easier for apple to support flac?

+++1

lucas72
2011-10-28, 01:58
The big advantage with ALAC from my perspective would be that suddenly I can use the same files both in Squeezebox and Apple ecosystem.

YESSSS. Finally.

lucas72
2011-10-28, 02:24
I don't trust Apple's motives.

It depends what you think are those motives...


I predict that once Apple has rendered other lossless codecs obsolete, they will "improve" ALAC and keep it closed source, then extract lucrative licence fees from all the third parties who have followed the herd.

This would be absurd, I don't have memory of Apple doing such a (self-defeating) move.


Rather than everyone else adding support for ALAC, wouldn't it just be easier for Apple to support FLAC?

Of course not, why a company should force their customers to convert all their audio files?! Makes much more sense that "new" customers convert their FLAC files to enter the Apple world.

Mnyb
2011-10-28, 02:36
But the fact remain no native ALAC for SB3 SB3 reciever or Boom is possible.
(well it is possible if you throw out something else, like encryption for some services... )

So server transcoding is still needed for all the old players , but now with possibly improved reliability.

Touch and Radio can now get better native support , there are issues with for example 24/96 alac or have been afiak ? now relatively bugfree support is possible if logitech can use the official decoder if it exist for all kinds of hardware and OS ? or if better third party decoder/encoder gets written.

Ideally Squeezeboxes should play your files regardless of personal preferences, but as I think there is to many formats , and it has not always been possible.

Now that it is open source wonder how long it takes before someone whines that cue+alac does not work ;)

AndrewFG
2011-10-28, 04:50
Interesting news:
http://www.tuaw.com/2011/10/27/apples-alac-codec-is-now-open-source/Unfortunately I think there is still a part of this story missing...

Apple .M4A music files consist of a raw data music stream, that is wrapped inside an ISO MPEG4 file container.

MPEG4 is an open ISO standard that defines a nestable structure of "boxes", where each such box has a name, and a predefined data payload. The ISO standard specifies some of the standard box names and their respective payloads. But the standard is extensible and allows vendors to add their own box definitions, and define their respective payloads. This works fine, because if a particular client does not understand the contents of a particular box type, it can ignore it and jump over to the next box.

One such standard MPEG4 box is the music stream box; it may contain MP3, MP4, AAC, ALAC or proprietary raw stream data. Therefore it is of course excellent news that Apple has open sourced the ALAC format, because it increases the number of public domain raw data stream payload formats that the standard MPEG4 music stream box can carry.

BUT, Apple still still uses other (proprietary) boxes to carry the track meta-data (i.e. the tags). These Apple proprietary metadata boxes obviously fit within the overall ISO format, and their names are known, and their payload structures have been reverse engineered. (So for example the SBS Scanner knows how to parse the tags). HOWEVER, so far as I know, these meta data tags have NOT been open sourced by Apple, so they could change the payload structures at whim, and thus "break" any third party applications that rely on them...

=> Dear Apple, please also open source your meta data boxes!!

Mnyb
2011-10-28, 05:10
Unfortunately I think there is still a part of this story missing...

Apple .M4A music files consist of a raw data music stream, that is wrapped inside an ISO MPEG4 file container.

MPEG4 is an open ISO standard that defines a nestable structure of "boxes", where each such box has a name, and a predefined data payload. The ISO standard specifies some of the standard box names and their respective payloads. But the standard is extensible and allows vendors to add their own box definitions, and define their respective payloads. This works fine, because if a particular client does not understand the contents of a particular box type, it can ignore it and jump over to the next box.

One such standard MPEG4 box is the music stream box; it may contain MP3, MP4, AAC, ALAC or proprietary raw stream data. Therefore it is of course excellent news that Apple has open sourced the ALAC format, because it increases the number of public domain raw data stream payload formats that the standard MPEG4 music stream box can carry.

BUT, Apple still still uses other (proprietary) boxes to carry the track meta-data (i.e. the tags). These Apple proprietary metadata boxes obviously fit within the overall ISO format, and their names are known, and their payload structures have been reverse engineered. (So for example the SBS Scanner knows how to parse the tags). HOWEVER, so far as I know, these meta data tags have NOT been open sourced by Apple, so they could change the payload structures at whim, and thus "break" any third party applications that rely on them...

=> Dear Apple, please also open source your meta data boxes!!

Ok this means that this "open" support is basically useless we have to rely on reverse engineered stuff anyway .

or *shrug* some one will use this knowledge and use alac with some nonstandard tagging scheme :-/

AndrewFG
2011-10-28, 05:15
Ok this means that this "open" support is basically useless we have to rely on reverse engineered stuff anyway.No. Apple already made a good step in the right direction. -- They just need to finish the journey...

aubuti
2011-10-28, 05:44
Rather than everyone else adding support for ALAC, wouldn't it just be easier for Apple to support FLAC?
Of course not, why a company should force their customers to convert all their audio files?! Makes much more sense that "new" customers convert their FLAC files to enter the Apple world.
Quite the contrary: No one said anything about Apple withdrawing ALAC, so Apple adding support for FLAC would not force anyone to do anything. But it would allow people to use a popular open source codec (FLAC) on Apple devices.

lucas72
2011-10-28, 05:57
Quite the contrary

True 'course. Sorry too much beer today.

netchord
2011-10-28, 07:26
correct me if i'm wrong, but i believe the transporter does not support HW decoding for alac. for this reason, and because i use iTunes for library management, i've kept my library as AIFF. sure, takes up more space, but hard drives are cheap.

the other reason being i can hear the difference between alac coverted to flac on the server, and native aiff playback. i assume there is no firmware upgrade possible for the transporter that would provide HW decoding for alac.

that said, i'm no longer using the analog outputs on the transporter- it now connects digitally to a meridian G61 processor. i suppose i should do some listening to see if there's still an audible difference between aiff/alac in my system.

Mnyb
2011-10-28, 07:32
correct me if i'm wrong, but i believe the transporter does not support HW decoding for alac. for this reason, and because i use iTunes for library management, i've kept my library as AIFF. sure, takes up more space, but hard drives are cheap.

the other reason being i can hear the difference between alac coverted to flac on the server, and native aiff playback. i assume there is no firmware upgrade possible for the transporter that would provide HW decoding for alac.

that said, i'm no longer using the analog outputs on the transporter- it now connects digitally to a meridian G61 processor. i suppose i should do some listening to see if there's still an audible difference between aiff/alac in my system.

I recomend that, I have a G68 It is very source agnostic if it can lock and dejitter and process it's done :) if you also use the RC and some digital speakers there are several layers of buffering resampling jitter removing processing and whatnot

maggior
2011-10-28, 07:36
Unfortunately I think there is still a part of this story missing...

Apple .M4A music files consist of a raw data music stream, that is wrapped inside an ISO MPEG4 file container.

MPEG4 is an open ISO standard that defines a nestable structure of "boxes", where each such box has a name, and a predefined data payload. The ISO standard specifies some of the standard box names and their respective payloads. But the standard is extensible and allows vendors to add their own box definitions, and define their respective payloads. This works fine, because if a particular client does not understand the contents of a particular box type, it can ignore it and jump over to the next box.

One such standard MPEG4 box is the music stream box; it may contain MP3, MP4, AAC, ALAC or proprietary raw stream data. Therefore it is of course excellent news that Apple has open sourced the ALAC format, because it increases the number of public domain raw data stream payload formats that the standard MPEG4 music stream box can carry.

BUT, Apple still still uses other (proprietary) boxes to carry the track meta-data (i.e. the tags). These Apple proprietary metadata boxes obviously fit within the overall ISO format, and their names are known, and their payload structures have been reverse engineered. (So for example the SBS Scanner knows how to parse the tags). HOWEVER, so far as I know, these meta data tags have NOT been open sourced by Apple, so they could change the payload structures at whim, and thus "break" any third party applications that rely on them...

=> Dear Apple, please also open source your meta data boxes!!

Interesting. Has anybody looked at the source that was just released to see if perhaps they've included the proprietary tagging code? It seems to me that Apple opensourced the code to lay the groundwork for wider adoption of AirPlay by other vendors. Providing only half the story here makes no sense.

Steven Moore
2011-10-28, 10:36
I think it's great news, it removes most of the open source arguments at a stroke. I can't see Apple going back on this, what would be the reason?
Anyway I'll be moving to an Apple tv come Christmas if Santa is good to me. Far too much trouble running my old squeezebox 2 these days. The last update was the last straw I'm afraid.

loneagle
2011-10-28, 12:33
ALAC seeking is supported. But yes this is great news, we can finally implement the official decoder.

So is there any hope that we might see firmware updates for legacy
devices such as the Transporter or Classic so they will understand ALAC
some day?

andyg
2011-10-28, 12:41
So is there any hope that we might see firmware updates for legacy
devices such as the Transporter or Classic so they will understand ALAC
some day?

The amount of code for ALAC is actually quite small, so who knows, maybe it would be possible.

abdomen
2011-10-28, 13:31
The amount of code for ALAC is actually quite small, so who knows, maybe it would be possible.

Count one big vote from an owner of multiple SB2's and 3's!

andyg
2011-10-28, 13:43
Actually I should mention that the code Apple released doesn't appear to include any MP4 code, only code to decode raw CAF (CoreAudio Format) files, and of course basically all ALAC files are going to be in MP4. So that would require additional code...

atrocity
2011-10-28, 15:09
Are there any advantages of using FLAC now when ALAC is open sourced ?

Last time I tested, stereo FLAC files were slightly smaller than their FLAC counterparts...and mono FLAC files were a *lot* smaller.

Mnyb
2011-10-28, 17:55
The amount of code for ALAC is actually quite small, so who knows, maybe it would be possible.

Interesting and positive :) was not the memory/cpu/something in the SB3 so limited that the bridging function was sacrificed for some change in the encryption for some service
( no loss imo bridging has nothing to do with music )

paul.raulerson
2011-10-28, 19:37
Yes this was unnecessary , there are already to many formats would have been better if apple incorporated FLAC in their products.

But that's thinking beyond pride and short term profit .



You know, I hear a lot of this, but there are far more devices out there using ALAC to stream music around than anything else. Every iTunes install, every Airport Express, Apple TV, and more and more hardware from third parties too. Pioneer, Bower and Wilkens, Denon, Linn, AS400, etc.

ALAC support not only puts a product into the largest and (potentially) most profitable environment around, it also forces Apple to improve seriously on the specs. Being open now, it won't be long before hi-res ALACs are streaming around the place.

Logitech has already proven it can be done and done well. Now what happens when 30 million devices need to be upgraded to stream 24/96 or better?

We live in really interesting times. :)

-Paul

AndrewFG
2011-10-29, 04:52
Actually I should mention that the code Apple released doesn't appear to include any MP4 code, only code to decode raw CAF (CoreAudio Format) files, and of course basically all ALAC files are going to be in MP4. So that would require additional code...Yes. But --alluding to my earlier post -- the function of the extra code would only be to route the contents of all boxes into the bitbucket, until it encounters the one box that contains the actual raw audio stream.

However there might be another problem; it could be that MP4 is fundamentally not live streamable to a Squeezebox type of player. Due to the aforementioned box structure, I believe you have to start reading an MP4 from the beginning of the file, because you calculate each box position as a chained offset from the previous one, and thus ultimately from the start of the file. I don't think the boxes have unique header codes to identify the beginning each box, so if you started at a random position in the file (e.g. by means of an HTTP Range Seek) you would never be able to re-sync.

Of course it is possible that the ALAC core audio stream, (what is inside the audio box), might itself have frames with unique header codes, so possibly the player could simply ignore the outer MP4 boxes entirely, and just re-synch on the internal ALAC frames. => If that would be the case, then Andy's concerns about handling the MP4 stuff would be trivial: just ignore it ;-)

mkozlows
2011-10-29, 10:49
ALAC support not only puts a product into the largest and (potentially) most profitable environment around, it also forces Apple to improve seriously on the specs.

No it doesn't. Apple doesn't have to change a thing, and there's little reason to suspect they will. ALAC has always been the "oh yeah, technically this works too" stepchild of Apple's supported codecs, and it's not likely they're going to do anything to seriously change it -- particularly if that change would make some ALAC files not operate on the existing devices out there, because who wants to explain THAT nightmare?

Mnyb
2011-10-29, 12:42
how many channels do ALAC support , can it cary multichannel discrete hirez as FLAC can ?

AndrewFG
2011-10-29, 15:10
Apple doesn't have to change a thing, and there's little reason to suspect they will.Hey guys, both ALAC and FLAC are somewhat like ZIP. It is lossless compression, and there is only so far that you can go with that. And anyway, why would anyone want to develop it further, when bandwidth and cpu cycles are steadily getting cheaper.

AndrewFG
2011-10-29, 15:20
how many channels do ALAC support , can it cary multichannel discrete hirez as FLAC can ?Well, their open source header files contain the following definitions, so it is a fairly safe bet that it can go up to 7+1 channels.

kALACChannelLayoutTag_Mono, // C
kALACChannelLayoutTag_Stereo, // L R
kALACChannelLayoutTag_MPEG_3_0_B, // C L R
kALACChannelLayoutTag_MPEG_4_0_B, // C L R Cs
kALACChannelLayoutTag_MPEG_5_0_D, // C L R Ls Rs
kALACChannelLayoutTag_MPEG_5_1_D, // C L R Ls Rs LFE
kALACChannelLayoutTag_AAC_6_1, // C L R Ls Rs Cs LFE
kALACChannelLayoutTag_MPEG_7_1_B // C Lc Rc L R Ls Rs LFEConcerning the bit depth and sample rates, I did not yet check that deeply, but found the following:

uint8_t bitDepth; // max 32
uint32_t sampleRate;The "max 32" at least implies they can go as far as 32 bits per sample...

audiomuze
2011-10-29, 16:01
I too was wanting to convert my flac library to ALAC, simply due to the fact there's no good tools for tagging of flac files for macyou've obviously not yet discovered puddletag...

Ron Olsen
2011-10-29, 17:33
I too was wanting to convert my flac library to ALAC, simply due to the fact there's no good tools for tagging of flac files for mac

you've obviously not yet discovered puddletag...
Is there a working version of puddletag for Mac OS X Lion? Installation instructions?

I've struggled (unsuccessfully) to get puddletag running on Lion.

bhaagensen
2011-10-30, 02:27
But the fact remain no native ALAC for SB3 SB3 reciever or Boom is possible.
(well it is possible if you throw out something else, like encryption for some services... )


AFAIR the ip3k-products have native support for a zillion funny codecs. I strongly suggest/hope Logitech could consider ditching some for the benefit of adding native ALAC! Seems much more useful, although I realize dropping support is bound to generate complaints for those (few???) who depend on them....

sebp
2011-10-30, 14:32
AFAIR the ip3k-products have native support for a zillion funny codecs.
The IP3K based products only support these codecs:
MP3, FLAC, Ogg/Vorbis, WMA (lossy), AIFF, WAV.

On the lossy codecs side, I guess you couldn't remove any of them without breaking compatibility with online streaming services / webradios.

On the lossless side, well:
- try removing FLAC support and I would force you eating an iPad
- try removing AIFF/WAV support (it's a one-fits-both codec, if I remember correctly), and the audiophile people would whip you to death with thousand dollars cables

So ? ;-)

Mnyb
2011-10-30, 14:49
The IP3K based products only support these codecs:
MP3, FLAC, Ogg/Vorbis, WMA (lossy), AIFF, WAV.

On the lossy codecs side, I guess you couldn't remove any of them without breaking compatibility with online streaming services / webradios.

On the lossless side, well:
- try removing FLAC support and I would force you eating an iPad
- try removing AIFF/WAV support (it's a one-fits-both codec, if I remember correctly), and the audiophile people would whip you to death with thousand dollars cables

So ? ;-)

besides that the radio crowd would rather se AAC before ALAC any day. fact is that logitech has stated before that development on ip3k firware is basically in maintanance mode only changes to encryption in suported services and similar no new features.

bhaagensen
2011-10-30, 15:16
- try removing FLAC support and I would force you eating an iPad
So ? ;-)

Send me (a working) one, and I shall - you'll just have to trust that I actually do !

My memory was off - I thought there were native support for more esoteric codecs. I wouldn't mind losing wma, but it would create havoc for the few who are using this thing called Internet radio :)

Guess I'll have to turn to the Apple forums advocating Flac-support in iOS/OSX

andyg
2011-10-30, 16:51
Well of course we'd never remove anything just to add ALAC support. The bridging+Rhapsody issue was unfortunate, just be glad it works at all...

audiomuze
2011-10-31, 08:01
Is there a working version of puddletag for Mac OS X Lion? Installation instructions?

I've struggled (unsuccessfully) to get puddletag running on Lion.Have a look at the puddletag forum, there's a post there that sets out how to get it done without too much effort.

Ron Olsen
2011-10-31, 09:55
Have a look at the puddletag forum, there's a post there that sets out how to get it done without too much effort.

The only info I found in the puddletag forum for a Mac install is for Mac OS X Snow Leopard (10.6), not Lion (10.7):

http://sourceforge.net/apps/phpbb/puddletag/viewtopic.php?f=1&t=42&p=338

The instructions in this puddletag forum post say:

"Get python 2.7, Sip/PyQt, PIL, PyParsing, mutagen, python-musicbrainz2. They all come with straightforward instructions for their installation."

I have not been able to get this working on Lion. I have been using MacPorts to get the required packages, but not all are available. Perhaps I need to get the source for each package and build it from scratch without using MacPorts at all.

It would be great to have a prebuilt Mac OS X puddletag package that works on Snow Leopard and Lion; I hope this is something you're considering.

Having a puddletag package for Mac OS X would greatly expand the puddletag user base and make it the tagger of choice for the Mac.

Right now, it's easier to get mp3tag running on a Mac using Codeweavers Crossover or Parallels.

P.S. Sorry for the thread drift. Perhaps puddletag on Mac issues are best discussed in another thread.

audiomuze
2011-10-31, 22:25
Let's move the discussion to the puddletag forum. Bottom line is with the exception of windows file paths puddletag is OS agnostic, written in Python and dependent on a series of Python libraries to do its work. Those libraries are also OS agnostic and available for most OS', so getting puddletag running on OSX is principally a function of having a properly functioning Python environment in OSX. Unfortunately neither the dev or I have a Mac. I am, however, willing to work with you to see if we can find a simple way to get the dependencies installed on your Mac.