Talk:Apple Lossless Audio Codec

Furthermore, the speed at which it can be decoded makes it useful for a limited-power device such as the iPod.

hm, according to the page listed as reference, both flac and shn have a better decoding performance ... not sure, whether this phrase adds any valuable information to the article ... would propose to remove it. 85.127.84.54 (talk) 18:42, 17 January 2009 (UTC)

I don't think that FLAC or SHN having better decoding performance necessarily makes ALAC's decoding performance poor.--69.254.67.10 (talk) 16:24, 3 May 2009 (UTC)

If there's data that shows that an iDevice runs longer or uses less energy playing FLAC than common lossy formats, then this should stay. I bet the contributor assumed it would, but would the increased data reads outweigh the reduced processing? It's not an encyclopedia-worthy assumption. I'm removing it.--67.170.192.66 (talk) 18:27, 4 August 2012 (UTC)

Sorry, but the comment is not stating it's better/worse than FLAC or other lossless, so should stay accordingly, unless proven otherwise as being entirely incorrect. The rest of your comment is baseless assumptions on others actions, whilst making assumptions on facts you don't know the answer to, hence should have been left alone accordingly. Jimthing (talk) 10:33, 7 January 2013 (UTC)

Is there any source for the claim that ALAC decoding is faster or consumes less energy than decoding any other codec? Is it less energy-consuming to play ALAC files than playing uncompressed PCM audio? I did not test (and the claim is not completely implausible) but it sounds a lot like marketing speech to me that needs a source.--Regression Tester (talk) 11:58, 7 January 2013 (UTC)

Cite added from professional audio mastering handbook. So this has been dealt with. Jimthing (talk) 16:45, 15 January 2013 (UTC)

I disagree: "Compared to most other formats" does not sound very reliable (or even informative) to me... --Regression Tester (talk) 18:38, 15 January 2013 (UTC)

Since no better source and no explanation was given, I reverted the change.--Regression Tester (talk) 10:13, 29 January 2013 (UTC)

What? There is nothing to disagree with here. The cite clearly states facts perfectly well enough, "Compared to most other formats, Apple Lossless is not as difficult to decode, making it practical for a limited-power device, such as an iPod." That is perfectly informative to me and anyone else. As it's taken from a professional mastering engineering book aimed at mastering audio professionals, it's certainly reliable enough for WP, so I think we'll go with their facts on the matter, rather than a casual WP editor deciding they just don't like it for inexplained reasons. Thanks! Jimthing (talk) 00:33, 8 February 2013 (UTC)

You highlighted the wrong part of the sentence: "Apple Lossless is not as difficult to decode, making it practical for a limited-power device, such as an iPod." is fine, the problematic part is Compared to most other formats: What could most other formats be? I cannot even guess it (and I know many formats very well). Allow me to repeat: I believe it is absolutely possible that alac is particularly well suited for embedded devices but such a (definitely non-obvious) claim needs a source. The claim that it is [better] than "most other formats" is completely ambiguous and vague and is therefore insufficient as a source on WP. (And I honestly wonder what an argumentum ad hominem has to do with the power needs of alac.)--Regression Tester (talk) 12:12, 9 February 2013 (UTC)

I am not a native speaker but I think it would not be completely absurd to interpret the sentence "Compared to most other formats, Apple Lossless is not as difficult to decode" as "There are formats that are not as difficult to decode as Apple Lossless and therefore more suitable for low-power devices such as an iPod" completely contradicting your claim.--Regression Tester (talk) 12:21, 9 February 2013 (UTC)

Ignoring the ad hominem claim – it was plainly clear that my point was that most readers would trust the audio professional that wrote the audio professionals handbook we are talking about, over a WP editor's thoughts on whether the claim the professional makes is true or not (which was not in fact your point anyway, as it wasn't until your later comments above that you actually explained your de facto reasoning properly), regardless of it happening to be you or any other editor. So really, claiming this was to do with you directly, is ridiculously taking some sort of pointless offence.

Back to the actual issue. The cited sentence reads, "Compared to most other formats, Apple Lossless is not as difficult to decode, making it practical for a limited-power device, such as an iPod". There is nothing wrong with this statement. It doesn't claim that it is the best or worst format in the world ever for limited power devices, it simply claims it's better than "most other formats" which is factually true, if you accept the audio professional would know what he is talking about (which we do, unless evidence states otherwise, hence it's a valid source). This statement doesn't claim to explain which formats, nor does it have to under WP guidelines. The statement "Furthermore, the speed at which it can be decoded makes it useful for limited-power devices such as iOS devices" I have tightened-up accordingly, to be more directly as per the cite; "Furthermore, compared to many other formats, it is not as difficult to decode, making it practical for a limited-power device, such as iOS devices." This is certainly a point of interest, as those using the format or considering doing so, may want to know if it will heavily impact their battery usage on "limited-power devices", hence being worthy of inclusion. Jimthing (talk) 21:45, 9 February 2013 (UTC)

2022 and the claim still stands. It is outright misleading. Go to the source cited where it is actually measured, and compare with other lossless formats. ALAC measures as two to eight times as CPU-hungry as FLAC. Worse than the highest WavPack mode tested. Test includes iPod. The best thing you can say about ALAC is that it isn't as intensive as a well-known notorious CPU hog - that doesn't make ALAC any efficient at all. — Preceding unsigned comment added by 193.90.163.192 (talk) 12:44, 2 January 2022 (UTC)

It currently reads as "ALAC has been measured to require around four times as much CPU power to decode than FLAC does,^[1] [...]". This is technically true, but the citation only compares the decoding performance with one single song. Since codecs perform differently with different tracks, I think it's unwarranted to conclude with "with implications for battery life on limited-power devices" or use this result to imply a refutation of the other source. 128.130.96.2 (talk) 15:39, 22 July 2024 (UTC)

The compression attempt can backfire. I just compressed a 19 kbps WAV file (~500KB) with ALAC (with iTunes 10.6), and the result is a 217 kbps file. So I see there are no sanity checks in the implementation.--67.170.192.66 (talk) 18:27, 4 August 2012 (UTC)

"Sanity checks in the implementation" what's that supposed to mean? Little to no proper explanations in your comments. Explain much further please, if you're gonna bother to edit info on here. Jimthing (talk) 10:27, 7 January 2013 (UTC)

WAV is a container, ALAC a codec. Typical WAV files contain PCM audio with a bitrate araound a magnitude higher than 217 kbps. Your wav file already contains compressed (lossy) audio, there is no lossless codec that can compress already compressed audio further, the same is true for video codecs. (This of course depends on the definition of "already compressed" but it is at least true for common - including older - codecs like mp3, wma, mpeg2video.)--Regression Tester (talk) 11:51, 7 January 2013 (UTC)

Why should the format have such "sanity checks" which it doesn't claim to have, nor that it should need to have. There's an old saying in audio engineering (often evident in other fields too) "shit in, shit out" – it sounds like that's what has happened here. Given CD audio in WAV is 1411kbps, ALAC isn't aimed at handling such low quality WAV's; it's aimed at relatively high quality CD audio and higher, at those levels the term lossless then becomes valid, which it certainly wouldn't be at the kbps level you used here. Jimthing (talk) 22:14, 9 February 2013 (UTC)

I removed two questions that asked for assistance with using Apple Lossless. As it states, this is not a help forum nor a place to ask for technical assistance.

Deepcloud (talk) 09:05, 12 March 2009 (UTC)

09:05, 12 March 2009 (UTC)

Is there actually any reason why Apple "created" this format, since codecs like Flac and Shorten already exist? It seems to me that the *only* reason Apple created this format was so it could have an Apple name. Basically, Apple just added a lossless format that's actually technically inferior to ie. Flac, just because it could.

Imagine every company that makes MP4 players made their own format.. there's no real rational reason why this format is any good; therefore, I am forced to conclude that Apple only looks at their own interests, and doesn't care about the people.

Prove me wrong, please. Please. —Preceding unsigned comment added by SeriousWorm (talk • contribs) 00:11, 4 June 2009 (UTC)

I think that apple simply wanted to provide a lossless option optimized for its hardware in the absence of any established de facto standard. Killakittens (talk) 21:30, 6 September 2009 (UTC)

It was my understanding that FLAC was unsuitable for streaming (such as Airtunes) or reading big chunks sequentially from storage (remember early iPods had little hard drives, so any time the drive was powered, the battery life would shorten). What about chapter marks for audiobooks? Also, can FLAC be tagged with metadata, artwork, lyrics, ratings, etc? Apple Lossless is exactly like an MP3/AAC track in that regard. --68.103.141.28 (talk) 01:09, 25 September 2009 (UTC)

I doubt metadata had much to do with it. FLAC does support metadata and in any case I'm pretty sure the metadata of Apple Lossless is a function of the MP4 container not the codec. I don't know much about FLAC, but from the little I know see no reason why it would be intrinsically unsuitable for streaming or big chunks sequentially and I believe people do stream FLAC. I suspect other factors had more to do with it, probably not so much Apple's desire to have their name but more to have a format they control. Microsoft also has WMA lossless after all. While I can find some sources , I don't know whether there's much merit to mention any of this in the article in which case this discussion is OT Nil Einne (talk) 12:24, 25 September 2009 (UTC)

All of the above and more. My reading on the background to ALAC is they didn't want any potential patent issues, as the development and ownership of the FLAC codec was unclear at the time. However FLAC has since emerged clear of any of these issues; but of course that's with the benefit of hindsight, and Apple clearly wouldn't have known that when they needed a lossless codec for their products, so had to pursue their own highly similar codec instead. As for being "futile", far from it. Apple now have the upper hand in the lossless game after open sourcing the ALAC codec, as it can be used on not only their own iDevice/iTunes products, but also all other manufacturers can add the reference version of the codec (instead of the unlicensed reverse engineered libavcodec) to their supported formats without legal or possible technical issues, whereas Apple will never add FLAC natively into their iDevice/iTunes product ecosystem. Thus both better ALAC compatibility with external docking device manufacturers, and ALAC audio file format sales through the iTMStore seem ever more likely in the future. --Jimthing (talk) 07:03, 1 December 2011 (UTC)

It was definitely about the fear of patent trolls coming after them; and this applies both to Apple and to Microsoft. (It's not about the actual ownership of FLAC, but rather that it may have used certain techniques that are patented. No one will go after a bunch of free software people; there's no money in it. But if Apple or Microsoft started using them, then there would be a target.) They both created their own lossless formats for this reason. Tossing out the old "control" canard doesn't really apply to a format that isn't widely used, but the point aout FLAC streaming could be true. (Though I have heard that, internally, the iTunes Store uses FLAC to store masters.) But I don't think any of this is germane to the article. Kirkmc (talk) 09:47, 1 December 2011 (UTC)

I don't think that's factually correct. I don't believe Apple stores on its server computers so-called "masters", as such objects are the responsibility and ownership of the content owners themselves (record companies, content owners, etc.), or even higher-quality encodes of any content formats (in ALAC/FLAC or anything else). Content owners have to encode and format content into Apple's approved format standards, then upload to Apple using tools Apple provide to do so. Apple have two main methods for content providers to upload content in Apple's approved standards through their iTunes Connect service. If you're big enough and can sell minimum sales amounts (earning thresholds in each territory), then according to this link (http://www.apple.com/itunes/content-providers/music-faq.html ) Apple provide music indie content owners with a piece of software called "iTunes Producer" in which to format their content into music files sellable through the store and in order to upload to iTunes (they can alternatively get an encoding house to do the required encoding), or alternatively they can use an approved aggregator (aggregators: https://itunesconnect.apple.com/WebObjects/iTunesConnect.woa/wa/displayAggregators?ccTypeId=3 ) to do all this on their behalf; especially required if they do not meeting minimum sales thresholds anyway. Certain music-related file types (music videos, ringtones, concert films, and iTunes LP) they sell will require an Apple-approved encoding house to be engaged to so such formatting. It is a similar process for other media types (books, films, apps, etc.). --Jimthing (talk) 23:12, 6 December 2011 (UTC)

...FYI, it looks like Apple are asking for masters now, currently limited for use as their Mastered For iTunes (MFI) specifically mastered 256 kbps AAC sales, but hopefully lossless sales will arrive as Apple can presumably re-encode these MFI-provided masters they will already have into lossless files (or whatever format is needed for adaptive streaming usage. See: http://www.guardian.co.uk/technology/2012/feb/28/apple-audio-file-adaptive-streaming ). Sounds positive, but we'll see! Ref: "Provide High Resolution Masters" section here http://images.apple.com/itunes/mastered-for-itunes/docs/mastered_for_itunes.pdf --Jimthing (talk) 07:41, 11 March 2012 (UTC)

Eleven or so months later, and here we still are. None of the above has exactly happened. A re-read of that MFI pdf doc makes it sound like lossless is a distant concept — given 'bandwidth', 'storage', 'battery-life', and even 'CPU' are still considerations. Further patience looks to be inevitable, as unfortunately technology has not moved on enough to seemingly allow most of the above to be relevant. Apple's market aims are difficult to tell, and still open to a lot of interpretation (certainly in the media, for sure!). Jimthing (talk) 01:45, 10 February 2013 (UTC)

Coming back to this a long time later, I don't know if I'd agree that 'patent trolls' is a separate issue from 'format you control'. A format you control means you have the ability to control what techniques etc you use in it, to ensure that there are none that you believe may violate some patent. Remember contrary to what was said above, knowledge of the development of FLAC is only of limited benefit in assessing whether there are any possible patents issues. We are talking about patents after all, not copyright. You could come up with something completely by yourself but if it's covered by someone's patent your screwed. And it's not like there's some magic way to avoid patent problems, the best you can do is hire fancy lawyers to find all the possibly relevant patents you can and do your best to stay well clear of them. Something which could after all also have happened for FLAC, if anyone wanted to except perhaps by the time anyone cared the bitstream was already frozen so if you found anything of concern you're SOL. (By comparison, a properly implemented clean room engineering of ALAC for example, should only be affected by Apple patents. The fact that whoever implemented it by some definitions didn't come up with anything by themselves is moot. In such cases you do want to know about the history to ensure there's no risk of copyright violation not because of patent concerns.) Nil Einne (talk) 17:37, 15 January 2019 (UTC)

I'm attracted to Apple Lossless because it's smaller than raw AIFF/WAV, can be tagged with metadata, and it's very easy to use with iTunes/Pod/Phone. But I'm concerned for the future. I know I can re-rip Lossless into other formats, but "what if" some day there's no more iTunes or Apple? --68.103.141.28 (talk) 01:04, 25 September 2009 (UTC)

This isn't really the place for such questions. I suggest you try the WP:RDC for factual questions. However no one can predict the future so this isn't a factual question. However it isn't necessary to rerip, simple conversion programs exist which can convert Apple Lossless into other formats such as uncompressed PCM wave or AIFF or some other lossless compresion like FLAC. As mentioned in the article, this includes open source utilities. So it's likely you will be able to decode and convert Apple Lossless in the future, even if no program supports it, if you are able to modify the existing code or willing to pay someone else to do it, to work on whatever modern platforms existthen. Alternatively you can use either an uncompressed format like PCM wave or other lossless compression format, perhaps one like FLAC which is widely supported by the open source community and so may be more likely to survive into the future. A final possibility would be to use Apple Lossless for now, but reevaluate every 3 or 5 years in the future or something of that sort whether it's still prudent to use it and if not, mass convert all your files to whatever format you feel is best then. BTW as far as I'm aware both FLAC is capable of support metadata as mentioned in the article, as is RIFF wave of course. --Nil Einne (talk) 12:15, 25 September 2009 (UTC)

(under "Futility of the format?" topic above, see my "All of the above and more..." comment.) Basically the future's a lot brighter now the original reference version has been open sourced by Apple ;-) --Jimthing (talk) 07:10, 1 December 2011 (UTC)

Hello fellow Wikipedians,

I have just added archive links to one external link on Apple Lossless. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

• Added archive https://web.archive.org/20120620124229/http://craz.net:80/programs/itunes/alac.html to http://craz.net/programs/itunes/alac.html

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

Y An editor has reviewed this edit and fixed any errors that were found.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 19:15, 7 January 2016 (UTC)

With Apple Music beginning to offer lossless audio, it is very likely that Apple have applied DRM to these. I've found one Reddit post on this:

• Apple Music has converted a lot of my iTunes library to lossless

If what the post states is true, this would contradict the statement "ALAC also does not use any DRM scheme." I have yet to find a reliable source on this, but it shouldn't be very hard. -- NasssaNser - T 16:00, 13 February 2022 (UTC)

The entire sentence is correct. ALAC is purely and audio codec. DRM is applied to the MP4 container.

ALAC also does not use any DRM scheme;^{[dubious – discuss]} but by the nature of the MP4 container, it is feasible that DRM could be applied to ALAC much in the same way it is applied to files in other QuickTime containers.` 2600:1700:5040:7950:F93D:178C:AEE5:5131 (talk) 03:42, 22 July 2022 (UTC)

Why is it worth pointing out that it "does not use any DRM scheme"? Are there any codecs that do?

I feel like this just creates confusion for people that don't understand the relationship between codecs, containers, and DRM. 24.222.18.26 (talk) 14:39, 20 November 2023 (UTC)

Reading about a specific audio codec is inherently a nerdy/technical thing to do IMO, so I think that anyone reading this would be able to deal with some nuance here. We could say something like "The ALAC codec itself does not use any DRM scheme. However, since it is often stored within an MP4 container, DRM could be applied to it in the same way as to other MP4 media." Asyncadr (talk) 16:52, 12 March 2024 (UTC)

Some references to coding issues surrounding DRM removal of ALAC lossless files on Apple Music seem to indicate that Apple is actively using Fairplay as a DRM on their lossless ALAC files in Apple Music:

• Download lossless (ALAC)? — Preceding unsigned comment added by 97.117.27.106 (talk) 18:54, 19 September 2023 (UTC)