Jump to content

Talk:Apple Lossless Audio Codec

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Mentions

[edit]

I could go on and on, but I can't find a single example of "Apple Lossless Encoding" mentioned on the Apple website. Funnily enough, a Google search for site:www.apple.com "lossless encoding" returns two pages that don't actually contain the phrase "lossless encoding". AlistairMcMillan 01:30, 9 Nov 2004 (UTC)

paradox?

[edit]

isn't a lossless encoder a paradox? i dont understand, nor does the article explain, how a compressed audio format could possibly be equillivant in quality to uncompressed data. any further explination would be appreciated. Cacophony 08:07, Nov 25, 2004 (UTC)

Lossless compression formats are actually quite common. See Lossless data compression. AlistairMcMillan 15:15, 2 Dec 2004 (UTC)
Thanks for the link, that is what I was looking for. I'll add it to the "see also" section. Cacophony 17:47, Dec 2, 2004 (UTC)
That page is already linked from the article under the word "lossless". AlistairMcMillan 18:35, 2 Dec 2004 (UTC)
I'm rather surprised that someone on the internet has never comes across loseless compression before. Zip? Gzip? Bzip2? Rar? Ace? 7zip? PNG? Gif? Have you really never encounter any of these before Nil Einne 16:45, 27 October 2006 (UTC)[reply]
Until lossy compression became a term with a lot of exposure, most people never though about the fact that *zip programs were lossless, that's all. — Saxifrage ✎ 17:53, 27 October 2006 (UTC)[reply]
Really: I would have thought most people knew zip is a form of compression. That's what they often use it for (okay some are primarily interested in the archiving functions)... And if it is a form of compression it doesn't take much thinking to realise it's lossless Nil Einne (talk) 11:57, 25 September 2009 (UTC)[reply]

Lossless ITMS sales?

[edit]

Can someone comment on whether or not it is possible to buy music through the iTMS in Apple Lossless format? 65.200.4.130

The music available from the iTMS is encoded in ~128 kbps AAC audio only. AFAIK lossless audio is not available. HTH, bdesham ★ 20:04, 5 November 2005 (UTC)[reply]
No, sorry. As of a few years ago iTMS has improved a little, but still currently only offers lossy *non-DRM* (previously it was DRM'd) at 256 kbps AAC audio files. This is much to the annoyance of a great many users who would like the choice hence do not buy anything there (choice is just not Apple's way of doing things though, hence another reason why rampant torrenting exists!). It's generally thought to have been chosen to be done like this because ALAC –and other lossless audio– file sizes tend to be 5x bigger, so both data transfer and data storage are issues. Storage is still a BIG issue on portable devices, with relatively very limited space on them even today (even the 160 GB on a Classic iPod is not much space if lossless is being used). Data transfer is an issue across the board. For local transfers, whether wired (though Thunderbolt deals with that now!) or wireless (wifi is still much too slow). And for wide-area internet transfers, most of the western world doesn't have fast enough connections (both downloading, but especially uploading too – large-scale data backup thus impossible currently!).
I exclusively encode manually into ALAC now though, because the amount of cheap non-portable computer-based storage available is massive now (12 TB of external Thunderbolt RAID-10 does nicely for audio [and video too]). So clearly, thinking longterm, if today storage is not an issue in the non-portable world, in a few years even in the portable world this stuff is not going to even be an issue. And data transfers will improve for both eventually. Hence, no reason to lose quality now if you're archiving content. Jimthing (talk) 06:48, 27 August 2011 (UTC)[reply]

Needs sources etc

[edit]

Quite a number of parts are in need of courses, for example:

Testers using a selection of music have found that compressed files are about 40% to 60% the size of the originals depending on the kind of music, similar to other lossless formats. 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.

Nil Einne 16:43, 27 October 2006 (UTC)[reply]

Yeah. I tagged the last sentence as needing a citation. The first could probably use one too, but since it's just corroborating a non-converserial statement by Apple, it's less of a big deal. — Saxifrage ✎ 17:54, 27 October 2006 (UTC)[reply]
Well according to the comparison referenced in the article, the decoding speed of Apple Lossless is somewhere between that of FLAC and WavPack. So while it's not as difficult to decode as some other formats, I think saying "most other formats" is too ambiguous without actually saying which formats you're comparing to. It is accurate to say that Apple Lossless is suitable for playback on the iPod, however the Rockbox software can also play FLAC, WavPack, and Shorten on iPods.[1] There isn't anything particularly special about the technology in Apple Lossless, and the fact that it can be played on iPods is mentioned in the preceeding paragraph. So I don't see any reason to keep this sentence and I'm going to remove it. --Mcoder 02:29, 5 November 2006 (UTC)[reply]


Lossless audio coding is a huge topic for discussion. Lossless audio coding is based on 'Entropy' of the signal which actually is amount of redundant information present in audio data to be compressed. Its all involved with statistical algorithms like prediction and database creation/seach algorithm. —The preceding unsigned comment was added by 202.56.254.194 (talk) 08:42, 17 January 2007 (UTC)[reply]

Apple Lossless is based on linear predictive coding. Encoding the difference between the prediction and the actual signal is referred to as 'entropy coding'. This subject would be more appropriately addressed in the linear predictive coding article, rather than here. --Mcoder 03:50, 22 January 2007 (UTC)[reply]
[edit]

I would like to see if anyone would object to me adding the link back to our site, The Lossless Audio Blog? Our site tries to bridge the gap between the forums and the various EAC Guides by providing information on getting started with lossless audio formats as well as current news and information. Because the Wiki pages for lossless audio formats are such a great place for those learning about the various formats I feel that our site compliments this and have heard from a lot of users voicing the same opinion.

Thanks for the consideration! Windmiller 12:27, 25 January 2007 (UTC)[reply]

Link Added Windmiller 14:07, 11 February 2007 (UTC)[reply]

I visited this page and it appears to be one of those commercial sites that try to harvest clicks. There seemed to be zero information there at all, let alone a blog. Telosmachina (talk) 06:50, 3 March 2010 (UTC)[reply]

low power?

[edit]

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)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
Cite added from professional audio mastering handbook. So this has been dealt with. Jimthing (talk) 16:45, 15 January 2013 (UTC)[reply]
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)[reply]
Since no better source and no explanation was given, I reverted the change.--Regression Tester (talk) 10:13, 29 January 2013 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

References

  1. ^ "CodecPerformanceComparison". RockBox. July 28, 2013. Retrieved November 29, 2014.

worst case

[edit]

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)[reply]

"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)[reply]
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)[reply]
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)[reply]

Removed Questions

[edit]

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)[reply]

09:05, 12 March 2009 (UTC)

Futility of the format?

[edit]

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)[reply]

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)[reply]
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)[reply]
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 [2], 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)[reply]
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)[reply]
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)[reply]
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)[reply]

...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)[reply]

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)[reply]
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)[reply]

Future proofing the format

[edit]

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)[reply]

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)[reply]
(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)[reply]
[edit]

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:

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

checkY 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 IITalk to my owner:Online 19:15, 7 January 2016 (UTC)[reply]

Requested move 21 October 2021

[edit]
The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this discussion.

The result of the move request was: no participation, but moved as a BOLD move as the nomination is reasonable and apparently nobody is disputing a move. ProcrastinatingReader (talk) 14:42, 30 October 2021 (UTC)[reply]

Apple Lossless → Apple Lossless Audio Codec – "Apple Lossless" is no longer used in any primary sources, e.g.:

https://macosforge.github.io/alac/

https://support.apple.com/en-us/HT212183

https://www.apple.com/newsroom/2021/05/apple-music-announces-spatial-audio-and-lossless-audio/

(Exception: In the ReadMe.txt on the Codec's GitHub, it's still mentioned as "Apple Lossless", but the "About" section on the right still calls it the Apple Lossless Audio Codec (ALAC).)

The seems to be no persistent usage of "Apple Lossless" in third-party sources; sources usually cite the full name (Apple Lossless Audio Codec) first, and continue with the abbreviation (ALAC).

Even though the current title is slightly more concise, I think the official, full name is more appropriate, since the short term "Apple Lossless" isn't the more common name. Andibrema (talk) 15:26, 21 October 2021 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Apple Lossless with Apple Music and DRM

[edit]

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:

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)[reply]

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)[reply]
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)[reply]
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)[reply]

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:

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Apple_Lossless_Audio_Codec&oldid=1243843164"