[Antony6555]

If they want to push alac that's fine, but why not flac too (in recognition that not all of us want to be tied to alac)? Also, I think decoding efficiency depends on the OS (I'm not certain on this). In conclusion, how is having more choices (and control over a product you purchased) bad?
Quote:

Looking around on the web it looks like Apple developed ALAC due to its advantages for decoding. While it takes the same computational power to encode FLAC and ALAC, the ALAC offering can be decoded much more easily, making it more suited to a battery-constrained portable device. Apple has very valid reasons for not supporting Linux - if you want to use their products, use their platforms. If you don't want to use their platforms, then you can use one of the many other offerings.
 
Apple's greatest strength is understanding who their target audience is, and catering to them. Sadly I don't know that you, or indeed many others are their target audience. There is support for ALAC on Linux via FFMpeg, however Apple doesn't officially support that, just like other non-Linux software vendors who allow cross-platform codec development don't support Linux explicitly, they just allow others to support it.
 

 

[sparktography]

Quote:

If they want to push alac that's fine, but why not flac too (in recognition that not all of us want to be tied to alac)? Also, I think decoding efficiency depends on the OS (I'm not certain on this). In conclusion, how is having more choices (and control over a product you purchased) bad?

I think the decoding efficiency metric being measured here is a hardware one. ALAC is designed to be easier to decode on hardware (i.e. on a device, rather than in an OS).
 
I suspect Apple doesn't allow FLAC because it would cause battery life concerns on the iPod and they want to make sure their consumers think of an iPod as something that plays for many hours. FLAC would also cost them money to implement for a minimal gain - most users don't know what FLAC is, let alone use it.
 

 

[aimlink]

Quote:

I think the decoding efficiency metric being measured here is a hardware one. ALAC is designed to be easier to decode on hardware (i.e. on a device, rather than in an OS).
 
I suspect Apple doesn't allow FLAC because it would cause battery life concerns on the iPod and they want to make sure their consumers think of an iPod as something that plays for many hours. FLAC would also cost them money to implement for a minimal gain - most users don't know what FLAC is, let alone use it.
 

Refreshing.  

 Words bereft of emotional content, but instead, containing a pragmatic analysis, are often true, though admittedly painful/annoying for those who suffer as a result of falling victim to the truth in it. Great comments sir.
 
The good thing is that there's choice, but so few of us exercise it.  If I needed to or preferred using FLAC, I'd definitely not be using an iPod.
 
I don't use an iPhone.  Neither do I want one.  It's feature set simply doesn't suite my needs and I haven't yet written to Apple complaining about their forgetting my needs.  I'm clearly not within their market segment when it comes to mobile phone technology and I am fully aware that they have a large enough market that they'll not particularly care about my needs.  While it's good to voice your disadvantages with a particular device, it's another thing entirely to somehow discredit simply because it doesn't work for you.
 
I buy a lot of online music in FLAC format.  I just use a converter to change them to ALAC.  
 
While I have sympathy for the ignorant on these matters in that they may not like their iPods but aren't aware of the alternatives, poster here should find it very easy to discover options out there other than iPods.  In fact, if I found an iPod a pain, I'd be motivated to use an alternative for the very reason that I have to support the choices that go better with my needs.  The last thing I'd want is a monopoly.

 

[Ham Sandwich]

We can speculate.
 
Apple created ALAC so they could put their own custom container around it that can support DRM.  Same reason Apple made their own custom container for AAC.  So they could add DRM.
 
Same reason Microsoft developed WMA Lossless and WMA.  They need a format they can control and add DRM to.
 
I'm sure there's also a bit of "not invented here" going on as well.  Don't want to rely on tech and formats that weren't invented here.
 
The FLAC site has some benchmarks for CPU use for decoding.  FLAC does better than ALAC there.  There's other issues when putting a codec on a portable device, but just from that table FLAC does well and ALAC seems to suffer.
 
Would be nice if the iDevices and the iTunes also supported FLAC.  Would make being interoperable with others easier.  But that's not necessarily in Apples interest.  Better to keep you in the walled garden where you have to keep buying more iDevices to stay compatible with your music library.
 
At this point you couldn't pay me to switch to ALAC.  Not even $1000 for an LCD-2.  ALAC is that unappealing to a Windows user.  In fact my current iPod Classic is very likely my last iDevice.  I have it because it is one of the few portables to do gapless properly.  When that changes and more alternatives do gapless properly I will switch to something more FLAC friendly.

 

[sparktography]

Hardware decoding isn't codec decoding. Some formats do well on generic-use processors like modern computers. When making a codec for a mobile device you ideally don't want a codec at all, but instead specific hardware capable of decoding the data stream into bitstream audio without the mobile OS being aware of what/how it's happening. Having hardware decoding makes for many times the battery effecacy of software decoding.

 

[Packgrog]

FLAC and ALAC are both designed for fast decoding, and thus are both suitable for portable devices.  They are the best lossless options for portables, actually.  The difference, as I understand it, is fairly negligible, but ALAC is preferred on Apple players because they have more control over it (likely for DRM).
 
The best info I found for doing conversions from FLAC to ALAC was here:
 
http://www.head-fi.org/forum/thread/508198/best-free-converter-program#post_6971298
 
This works great for me.  I would prefer to just use FLAC with ReplayGain, but since my iPhone 3G won't run VLC Media Player (which will probably get pulled from the App Store soon anyway), this ALAC conversion works great.

 

[Mad Max]

My ALAC library is based on my FLAC backups, so I wouldn't have any problems switching to FLAC for a different player.
Not that I have any intention on bothering to right now.  -__-
 
Also, I never buy anything from the iTunes store, so DRM is non-existent in my library, and I sure as hell would hate to have protected music unless someone finds a way to crack DRM.
 
Walled garden my @ss.  Why would you be using DRM'd music anyway?  You are not one of the average ipod users (who would be) if you are aware of and use FLAC or ALAC in the first place, so why would you not want to avoid DRM'd stuff?  As it has been said, there are alternatives to iDevices anyway.
 

 

[Ham Sandwich]

Quote:

Hardware decoding isn't codec decoding. Some formats do well on generic-use processors like modern computers. When making a codec for a mobile device you ideally don't want a codec at all, but instead specific hardware capable of decoding the data stream into bitstream audio without the mobile OS being aware of what/how it's happening. Having hardware decoding makes for many times the battery effecacy of software decoding.

Which is what I was implying by saying "There's other issues when putting a codec on a portable device".  Power issues are a big one.  One of the problems with Rockbox on many platforms is that it usually does the decoding on the CPU rather than using the special purpose decoding chip that's in the device.  That means Rockbox uses more battery power.  But FLAC decoding has been implemented on chips now from multiple vendors.  You don't need to decode FLAC on the CPU of a portable.

 

[sparktography]

Quote:

 But FLAC decoding has been implemented on chips now from multiple vendors.  You don't need to decode FLAC on the CPU of a portable.

But are those the chips Apple is using? If not putting FLAC support would require CPU decoding, or changing chip vendors. Apple makes most of their own chips in-house, so from a business perspective it makes sense that they would align their chip-design resources on their own format vs. a competing format.

 

[Ham Sandwich]

Quote:

My ALAC library is based on my FLAC backups, so I wouldn't have any problems switching to FLAC for a different player.
Not that I have any intention on bothering to right now.  -__-
 
Also, I never buy anything from the iTunes store, so DRM is non-existent in my library, and I sure as hell would hate to have protected music unless someone finds a way to crack DRM.
 
Walled garden my @ss.  Why would you be using DRM'd music anyway?  You are not one of the average ipod users (who would be) if you are aware of and use FLAC or ALAC in the first place, so why would you not want to avoid DRM'd stuff?  As it has been said, there are alternatives to iDevices anyway.
 

Which misses the point.  Whether you will ever have DRM files is not the issue.  One of the reasons ALAC is around is so that Apple could potentially add DRM to it in the future. ALAC was developed back in the days when Apple was doing DRM with AAC and iTunes.  Had to keep that option open for adding DRM to any lossless codec they used.
</drm_conspiracy>

 

[Ham Sandwich]

Quote:

But are those the chips Apple is using? If not putting FLAC support would require CPU decoding, or changing chip vendors. Apple makes most of their own chips in-house, so from a business perspective it makes sense that they would align their chip-design resources on their own format vs. a competing format.

Any embedded chip that has ALAC decoding is a custom chip just for Apple.  Apple does not license ALAC so there can be no generally available chip that does ALAC decoding.
 
There is no technical reason why Apple could not add FLAC decoding to their custom chips.  They obviously just choose not to.

 

[sparktography]

Quote:

Any embedded chip that has ALAC decoding is a custom chip just for Apple.  Apple does not license ALAC so there can be no generally available chip that does ALAC decoding.
 
There is no technical reason why Apple could not add FLAC decoding to their custom chips.  They obviously just choose not to.

And I think that hits the nail on the head. They have chosen not to, and I'm betting it's because the number of people who would appreciate that feature and thus the incremental revenue Apple would get is dwarfed by the development costs associated with adding FLAC support to the chip. With the average consumer not caring about lossless quality it's a nice bonus that Apple even supported ALAC, as opposed to supporting only MP3/AAC. I'm just happy they made the decision to support at least one lossless codec.

 

[emmodad]

Quote:

Apple created ALAC so they could put their own custom container around it that can support DRM.  Same reason Apple made their own custom container for AAC.  So they could add DRM.
 
[ snip ]

 
ummmmm....not quite.
 
yes, the concept of "music content protection" was a key background item behind the development of ALAC
 
however, apple's creation of a new lossless compression scheme was not driven by a draconian/conspiracy relationship between apple desire for control and using DRM - a "reason" that many people continue to mention
 
rather, the development was related to requirements defined by "the music industry" if the evolution of music to digital files was to move forward into distribution via personal entertainment networks
 
---
 
ALAC was not created with the *primary* development goal being to enable customers to make lossless versions of music files from their CDs; rather that was a happy byproduct of the actual reason
 
---
 
apple at the time was fully committed and engaged in implementing thier overall strategy evolution which would emphasize portability, convenience, and simple unwired connectivity -- all to serve (and leverage) customer desire (and human nature) for instant gratification in access to media and information content.
 
this had started of course with the introduction of Airport (802.11 wifi) in 1999, for internet access and file transfer between computers -- several years before ALAC capability was introduced as a component of QuickTime end-April 2004
 
by 2004, with the iTunes ecosystem taking hold (the iTunes Store was roughly a year old and quite successful, iirc 50+ million downloads and accelerating), and with 802.11 maturing in customer use, apple wanted to add untethered music streaming to their overall product feature mix ("iTunes helps organize your music.  you can find what you want fast.  now send it to your home entertainment system").
 
but there was still a huge customer base on 802.11b, not yet evolved to 802.11g
 
---
 
sending 128kbps compressed audio files over wifi doesn't take much bandwidth.  however, higher quality would be better for integration with a home entertainment system; and of course ripping CDs at full 16/44 was very typical.  hence CD bitrate of 1411kbps had to be supported
 
do a bit of research and you'll see that actual *typical* available bandwidth in a home wifi network is much lower than the quoted 11 or 54 Mbps.  often, an 802.11b network has a useable bandwidth allowing only something more like 2-3Mbps.  a CD rip at 1411kbps (= 1.411Mbps) + error correction would be a significant portion of this allowable "bit budget."
 
hence possibility for wifi network congestion and bad performance (dropouts, stutters, etc), which woud be very noticable in an audio streaming environment.  and apple does't want unhappy consumers blaming them for problems which are actually caused by wifi technology bottlenecks.
 
so, in order to make audio streaming work reliably in a typical consumer wifi environment, a solution was needed to reduce demands placed by that audio stream on the wireless network.
 
---
 
enter the concept of lossless compression.
 
everyday example:  when you use lossless encoding during a CD rip, your resulting filesize drops and hence the average playback bitrate for the file drops down from 1411kbps, typically down into the range of 600-900kbps.
 
simply stated, by using a good lossless compression algorithm, a CD-quality audio stream could have the same result:  bitrate reduced by 30-60%.
 
run the original audio thru a lossless encode/decode chain 
 
 
     computer ALAC compress > wireless 802.11 transmit > air >  wireless 802.11 receive > Airport Express ALAC decompress
 
 
and communication through that over-the-air "channel" would require much less bandwidth.
 
600-900kbps put less strain on capability of a consumer wifi channel.
 
 
 
---
 
so where does "the music industry" come in to an apple plan to allow wireless music streaming as a function intimately connected to the exploding iTunes ecosystem?
 
and more specifically, with regard to lossless compression (which was needed for the data communications bandwidth issue noted above, namely, reliable CD-quality streaming functionality within the limited bandwidth of typical consumer wifi)?
 
answer:  they insisted that any of their content being transmitted out of a computer environment, over any wireless network, had to be "protected."
 
and any "software" or algorithm involved while that data was "out in the air" which looked like it could be "cracked" -- or, god forbid, which was "open" -- was not acceptable.
 
so, in addition to the obvious parallel discussion about wifi security (at that time considered reasonably good), there was this little problem:  the lossless compression algorithm had to be "protectable."
 
ie it couldn't be open source in any way.
 
---
 
FLAC:  wonderful lossless decoder, but all licensing is related to BSD and GNU GPL copyleft -- free software licenses, and with implications that any derivative works must follow same/similar licensing requirements.
 
so, no way would the content providers (music industry) allow their extracted CD-quality audio content, moving within the (wildly-successful- and seen-as-possible-industry-salvation) iTunes software/hardware ecosystem, go through any commercial-product-based wireless communications link with a non-defendable lossless compression scheme.  especially one whose licensing requirements could force (as-yet-unknown) future digital music systems to be subject to open-source-style requirements.
 
but the music industry loved the idea that music streaming a la wifi could be a factor positively motivating consumer demand for music product. (they may have been late to get it in the beginning, but by now they saw the inevitible future of consumer audio involving a computer).
 
---
 
solution:  create a lossless compression algorithm with a controllable legal & licensing lineage.
 
---
 
hence, apple had to create their own lossless compression algorithm to placate music industry fears while evolving the "computer audio" experience to integrate itunes with the environment that average consumers were familiar with:  their home entertainment systems.
 
2004 late-April:  QuickTime (and iTunes) introduces ALAC capability.  about six weeks later, introduction of the Airport Express, with seamless iTunes audio streaming as a feature.  all audio which comes out of the computer via wifi is subject to ALAC lossless compression for tramsmission.
 
---
 
apple were forced by music industry / business reasons to use a lossless compresion algorithm other than FLAC.  since ALAC lossless functionality is equivalent to FLAC lossless functionality is equivalent to algorithmXYZ lossless functionality.... well, apple have lossless functionality.  no need to support other (potentially commercially-undefendable) algorithms
 
not utilizing FLAC removes the business and legal exposure to which potential future products and software might be subject, via FLAC copyleft licensing terms.  this is why no apple products have native FLAC support.
 
kept the music industry suits happy, their heads filled with visions of revenue streams coming from the evolution of on-line music ecosystems - especially iTunes.
 
---
 
oh, and as a side benefit of this whole affair, you can store your audio files as ALAC lossless...
 
 
hopefully entertaining,
chuck
 
 
edit:  schpellink

 

[aimlink]

^ Educational post there.  Thanks for that.  Makes a lot of sense.
 
HDTracks.com has a growing  catalog of music on sale, but it's very clear that a woeful minority of mainstream music is available there because the lossless compression that they use is FLAC.

 

[sparktography]

Emmodad wins post of the day award! I love knowing some of the background of ALAC!