L'ALAC devient open-source

Anthony Nelzin-Santos |
skitchedL'Apple Lossless Audio Codec (ALAC) est un format d'encodage musical « sans perte » créé par Apple en 2004 pour être facilement décodé par les appareils mobiles. Supporté par iTunes, QuickTime, l'iPhone, l'iPad et les iPod, l'ALAC est désormais open-source : Apple a décidé de le placer sous licence Apache. Apple a ainsi publié les sources de l'encodeur et du décodeur ALAC et de l'utilitaire de lecture/écriture CoreAudio alacconverter.

Comme les autres formats « sans perte » (FLAC, HD AAC, APE, Monkey's Audio), l'ALAC utilise un algorithme de compression qui permet de reconstituer la source originale fidèlement à partir des données compressées. Résultat : aucune donnée n'est perdue (et les fichiers sont plus lourds), contrairement à la compression avec perte d'autres formats comme le MP3 ou l'AAC. L'ALAC n'est pas le format possédant l'algorithme de compression le plus efficace, mais cette faiblesse est une force : moins complexe à décompresser, l'ALAC est plus facilement décodable par les appareils mobiles.
Tags
avatar Himax | 
Pour une fois qu'Apple ne supprime rien... Vive l'Apple lossless!
avatar PierreBondurant | 
Bonne nouvelle, ça va peut être accélérer son adoption dans les amplis Hi-Fi
avatar blueblood | 
Et les fichiers sur iTunes c est pas de l alac si ? En gros qui l utilise ??
avatar ErGo_404 | 
@blueblood : je pense que tu peux spécifier à iTunes de compresser en ALAC tes CDs plutôt qu'en m4a ou en mp3.
avatar ErGo_404 | 
Et la difficulté de compresser ou pas ne change plus grand chose niveau simplicité d'intégration, de toutes façons maintenant le décodage est matériel et ne consomme pas grand chose, quel que soit le format.
avatar Almux | 
Ceci est une excellente nouvelle, aussi pour tous les montages sous FCP (FCPX et autres) et les transferts des sonorisations entre collaborateurs!
avatar Le Chapelier | 
Très très très très très content de cette décision. En tant que mélomane, je préfère écouter du CD que du format encodé (surtout sur une chaîne HiFi d'un certain prix). Les CD que j'adore et que je ne possède pas (emprunts médiathèque, amis, etc.) , je les encode avant achat (si pas plus de 5 €, avis aux maisons de disques). Le meilleur encodage sans perte reste le FLAC (via Toast), mais non compatible avec AirPort (branché sur la chaîne en optique) ! Donc ALAC... Maintenant que l'ALAC est "open source", va-t-il se voir démocratisé et géré nativement dans plus de produits audio ? Car à part AirPort, y'a pas grand chose... Je suis déjà satisfait que ma chaîne puisse décoder le AAC...
avatar Erravid | 
Curieux de voir les implications d'une telle décision ! Toutes les applications que j'utilise régulièrement gèrent déjà l'ALAC.
avatar iDuplo | 
Question: est-qu'on entend la différence sur un iPhone entre une chanson encode en Alac (ou un autre format lossless) et un mp3? Car le son qui sort de l'iPhone (sur casque Bose) est vraiment de piètre qualité quand on compare au même mp3 sortant d'un MacBook.
avatar Le Chapelier | 
@ Erravid : "Toutes les applications que j'utilise régulièrement gèrent déjà l'ALAC." Les applications, oui, mais quid des appareils limités à un petit firmware : une platine CD par exemple ? Beaucoup de platine CD lisent le MP3 et le WMA. Très rares sont celles qui lisent le FLAC et l'AAC. Alors l'ALAC... n'en parlons pas. Puis l'ALAC étant géré nativement sous OS X , toutes les applis OS X peuvent l'exploiter sans soucis. Pas évident que cela soit actuellement le cas sous Windows ou Linux. Le fait que l'ALAC devienne "open source" peut changer cela pour nos cousins d'en face et nos appareils. @ iduplo : "est-qu'on entend la différence sur un iPhone entre une chanson encode en Alac (ou un autre format lossless) et un mp3?" Franchement, cela dépend de l'environnement. Dans le métro avec un casque pourri, aucune différence. Au calme avec un bon casque, c'est comme écouter un concerto en chambre (LL) et écouter une radio grésillante au fond d'un couloir incapable de sortir des graves et des aiguës (MP3).
avatar Oliange | 
iPod et iPhone n'ont jamais été excellents dans la restitution du son, même si le casque joue énormément, le matériel aussi. Un lecteur mp3 Cowon est de meilleure qualité par exemple. Après l'avantage de l'iPhone est de le faire en plus du reste, mais c'est vrai qu'entre un iPod et un Cowon, faut peser le pour et le contre.
avatar Monsieur Albert | 
Bravo.
avatar alan63 | 
personnellement,je prefererai ne pas écouter certains sois disant artistes que ce fusse en Alac Flac ou 78 tours brrrrrrr........
avatar t o o l | 
Vers un iTunes HD au format ALAC? Cela fait longtemps que j'attends une meilleure qualité...
avatar supermars | 
+1 !
avatar didhoc | 
Bonne nouvelle ! Malgré tout, j'aurais préféré que iTunes/quicktime gèrent le FLAC sans passer par des bidouilles…
avatar Calintz | 
Good !
avatar Xalio | 
Ca voudrait pas dire qu'apple vendre de l'ALAC sur l'itunes store? Logique non? On democratise le format, les devs l'adoptent et on vend du HD plus cher en ligne...
avatar kayabis | 
@didhoc : Pourquoi passer par des bidouilles? T'importe ton cd directement en ALAC via iTunes. Ou alors c'est que tu télécharges de la musique illégalement en FLAC... Shame on you!
avatar HAL-9000 | 
Ça vaut pas le Hi MD de Sony : format CD Plus de 88 min enregistrable sur un disque réduit x1/5 du CD.
avatar HAL-9000 | 
Soit format PCM 88min avec datas sur disque 1Go
avatar romainhc | 
Y a encore et toujours des "audiophiles" qui font la différence entre ALAC et PCM (CD). Alors qu'après décompression, vous vous retrouvez avec un fichier rigoureusement identique, bit pour bit. La seule différence possible viendrait de votre puce de décompression qui ne traiterait pas l'ALAC et un CD de la même façon. Pour une installation "audiophile" ça la foutrait mal ... Non ? Pour les autres, prenez un CD et encodez le en ALAC. Décompressez ce fichier en format Wav ou Aiff et comparez le avec un rip de votre CD en Wav ou Aiff. Importez les 2 fichier dans un éditeur audio, en mettre 1 en opposition de phase et lire les 2 titres en même temps. Résultat ? Vous n'entendrez rien ... Preuve que c'est rigoureusement la MÊME chose.
avatar Zed-K | 
Une bonne chose, maintenant j'en attends 2 autres : - le support du FLAC sur iPod/iPhone (je crois que je vais pouvoir attendre longtemps) - la possibilité de télécharger les albums sur l'ITS en ALAC (parc'que payer à peine moins cher qu'un support physique pour un album compressé, je suis pas fan) Sachant que le premier point deviendrait inutile si tous les autres fabriquants se mettaient à la compatibilité ALAC (mais j'ai peu d'espoir à ce niveau, et je peux les comprendre).
avatar Pantalon | 
J'ai décidé il y a quelques mois de ne plus acheter de musique compressée. Exit donc iTunes store... La différence au casque (un bon) sur le mac est sans comparaison avec de l'AAC ou (pire) avec du MP3. Il est assez scandaleux que l'on vende maintenant de la musique de moins bonne qualité techniquement qu'il y a 20 ans. Surtout de la part d'une entreprise comme Apple qui se positionne sur le haut de gamme! J'espère maintenant que le format ALAC va se banaliser, et j'attend maintenant une chose : Que AirPlay soit compatible avec le ALAC 24 bits qui offre une qualité surprenante, pour peu que la prise de son soit de bonne qualité. Le jour où l'Apple TV pourra lire le ALAC 24 bits, je l'achète sans hésiter !
avatar HAL-9000 | 
@romainhc Sais-tu que tout algorithme possède des marges d'erreurs ? Ta puce qui encode et décoe le format à uintervalle d'erreur de traduction de +/- quelques bits sur quelques xxxx bits... Donc tu as potentiellement une degradation de ton signal du fait de l'encodage/décodage... Donc non, ils ne SONT PAS IDENTIQUES
avatar Oliange | 
Si le FLAC pouvait se démocratiser ça serait encore mieux...
avatar Le Chapelier | 
@ Pantalon : "La différence au casque (un bon) sur le mac est sans comparaison avec de l'AAC ou (pire) avec du MP3." Sauf que les Macs, depuis le passage Intel ont des CAN/CNA de merde (du Intel, quoi). Avant c'était du très bon (de chez Texas Instrument sur PowerBook). Et franchement, écouter la musique au casque sous MacBook Pro, j'ai vraiment du mal, alors qu'avec le PowerBook, c'était agréable. La différence est audible. Sans compter les craquements sous Intel lors des coupures de sortie audio (la faute à la double connexion analogique / optique ?) Alors, certes, un ordinateur n'est pas fait pour écouter de la musique... Certains dirons qu'il est difficile de faire la différence entre un CNA et un autre. Je répondrais, que je ne suis pas le seul à savoir faire la différence entre un Burr Brown 1796 et un Wolfson 87xx. Alors un Intel...
avatar marc_os | 
@HAL-9000: Un encodage sans pertes, c'est un encodage sans pertes. S'il y a des pertes, alors l'appellation de "lossless" n'est pas appropriée. Si dans un algo on ne passe pas par des doubles ou autres types de réels, que l'on se contente d'entiers et que l'on ne fait pas d'overflow, il n'y a pas de raison qu'il y ait des pertes, que l'algo soit implémenté dans un logiciel ou "en dur" dans une puce dédiée. Des exemples concrets pour étayer ton hypothèse ?
avatar romainhc | 
@marc_os Merci
avatar punkbinturong | 
@Kinky Un "fan de musique" peut aussi rechercher l'aspect ludique dans son choix de baladeur, et avoir envie de profiter de fonction comme Genius ou d'une belle interface par exemple. Celui qui recherche la performance technique à l'écoute au détriment d'un certain fun n'est plus un "mélomane" mais un audiophile.
avatar HAL-9000 | 
Je t'invites à faire des mathématques et de l'informatique pour comprendre... Toute machine à une marge d'erreur, très très faible mais existante. Même ton propre sequençage ADN fait par tes propres cellules commet des erreurs. Plusieurs explications dans tous les cas : soit externes (dans le cas d'un CPU par exemple la hausse de température augmente les probabilités d'erreurs -c'est pourquoi l'overclock est fortement déconseillé par les fabriquants- les rayons cosmiques aussi, etc. etc.) soit internes (virgules flottantes, précision, etc.). Et chose avantageurse même : http://www.presence-pc.com/actualite/processeur-probabiliste-43017/
avatar J.M | 
Petite bourde : dans l'article, l'auteur discerne APE et Monkey's Audio mais APE c'est justement l'extension de fichier du format Monkey's Audio. Au rayon du lossless, on peut citer le Wavepack aussi qui est moins connu (extension .wv). C'est bien de la part d'Apple de rendre l'alac open source même si je doute de son adoption à court terme par les fabricants de baladeurs et autres. Le FLAC qui est pourtant plébiscité par pas mal d'audiophiles sur le web est encore inconnu de beaucoup de personnes parmi le "grand public". Bon par contre, il a l'avantage de pouvoir être lu par pas mal de baladeurs / smartphones. @ Kinky : je possède un HTC sous Android et même si le système ne gère pas l'ALAC par défaut, Poweramp (4,99 USD), gère tout un tas de formats audio : mp3, mp4/m4a (alac inclus), ogg, wma, flac, wav, ape, wv, tta
avatar MrClaye | 
Tant mieux qu'Apple ouvre un peu ce format. @kayabis : S'toi le pirate, le FLAC permet de gagner quelques Mo par rapport à l'ALAC. J'ai deux question : L'autre jour je me suis aperçu qu'iTunes avait pas super bien importé ma musique, en écoutant le CD pas de soucis mais en écoutant la version ALAC une piste sautait à un endroit bref, vous utilisez quoi pour importer votre CD en FLAC ou ALAC et est-ce que passer d'un fichier FLAC à ALAC (ou vice-versa) entraine une perte ? (j'avais test avec XLD et j'ai eu un peur en voyant un flac de 37,2 Mo passé à 35,9 Mo). Depuis quelques temps je me prend un peu la tête là dessus.
avatar Anonyme (non vérifié) | 
"Je t'invites à faire des mathématques et de l'informatique pour comprendre... Toute machine à une marge d'erreur, très très faible mais existante." il n'y a pas de rapport entre le fait qu'il y ait possiblement des erreurs de calculs de CPU et la compression sans perte. un algorithme de compression sans perte de données est réversible, c'est à dire que tu es capable de reconstruire la source à partir de la destination. donc si tes données encodées ne permettent pas de reconstruire l'orignal, c'est qu'il y eu une erreur d'encodage - il faut alors recommencer. Si tu encodes un CD par le biais d'un algorithme de compression sans perte, tu auras alors potentiellement la même qualité d'écoute qu'avec l'orignal (CD).
avatar coink | 
D'après ce que j'ai pu trouver, l'encodeur ALAC d'iTunes encode en bit perfect (identique à la source) pour peu que le CD source ne génère pas d'erreur de lecture. Par contre si les CD source sont vieux ou endommagés, ou si vous êtes stakhanovistes du CDRip, XLD à un mode "parano" qui semble avoir une correction d'erreurs bien plus performantes que iTunes. La conversion FLACALAC ne perd pas d'info, la différence de taille de fichiers vient de l'algo de compression. Selon le type de musique, FLAC ou ALAC est plus performant (perso j'ai remarqué que FLAC est plus performant la plupart du temps ;) ) Et si on doit prendre en compte l'influence de la lune sur nos processeurs, on est pas arrivés !
avatar HAL-9000 | 
"un algorithme de compression sans perte de données est réversible, c'est à dire que tu es capable de reconstruire la source à partir de la destination." Oui grace à des algo correcteurs (filtres sur ton signal). Mais cela n'empeche par l'erreur. "D'après ce que j'ai pu trouver, l'encodeur ALAC d'iTunes encode en bit perfect (identique à la source) pour peu que le CD source ne génère pas d'erreur de lecture." Et pour peux que tu n'ai pas d'interferences notables sur les composants qui assurent ton encodage, en plus des erreurs possibles des algos... Je vais vous prendre un exemple très très simple, en VBA, Java m'importe quoi d'autre, faites un test logique genre 0.99999999999999999999999999999999 == 1 et la reponse sera 1 (vrai)
avatar coink | 
Bon d'accord, la perfection n'est plus de ce monde, on garde nos piles de CD et on reste dans les années 90 ...
avatar Anonyme (non vérifié) | 
"Oui grace à des algo correcteurs (filtres sur ton signal). Mais cela n'empeche par l'erreur." heu non..la compression de données sans perte n'est pas propre à l'audio, cela concerne aussi les données "génériques". si ton support est fiable = que tu lis la même suite de zéro et de un à chaque lecture. et si tu encodes sans perte (de données) ce flux, la réversibilité sera vraie dans tous les cas. si il y a eu une erreur d'encodage, tu peux le vérifier par rapport à la source (réversibilité). C'est des maths et cette règle de réversibilité restera aussi vraie dans le temps qu'un théorème. "Je vais vous prendre un exemple très très simple, en VBA, Java m'importe quoi d'autre, faites un test logique genre 0.99999999999999999999999999999999 == 1 et la reponse sera 1 (vrai) " Ce dont tu parles est justement le contraire: de la compression AVEC pertes de données, qui consiste à faire des "approximations" sur les données pour en simplifier l'encodage (prend moins d'espace disque).
avatar Le Gognol | 
@HAL-9000 : 'Sais-tu que tout algorithme possède des marges d'erreurs ? Ta puce qui encode et décoe le format à uintervalle d'erreur de traduction de +/- quelques bits sur quelques xxxx bits... Donc tu as potentiellement une degradation de ton signal du fait de l'encodage/décodage... Donc non, ils ne SONT PAS IDENTIQUES' Alors si on suit ton raisonnement il fait immédiatement cesser d'utiliser les formats d'archive du genre ZIP, etc. Bref, n'importe quoi...
avatar MrClaye | 
@coink : Merci pour tes réponses ^^ Flac est plus performant dans la compression oui mais justement, c'est pas bizarre qu'en passant d'un .flac en un ALAC le fichier soit légèrement plus petit ? Il devrait garder la même taille ou être plus gros non ?
avatar joneskind | 
@truiter Non, pas vraiment. Ce qu'explique HAL est plus un problème mathématique fondamental. En fait, aucun processeur n'est capable de reconnaître la différence entre 0,9999999.......999 et 1 au delà d'une certaine limite du fait même de sa propre marge d'erreur. Et oui il y a des nombres qu'un ordinateur ne peut pas écrire sous une forme exacte et dont il est obligé de considérer une approximation, c'est le cas de tous les nombres irrationnels comme √2, ε, π. De fait, cette approximation de départ va entraîner une augmentation de la marge d'erreur à chaque itération d'un calcul, quelle qu'en soit la simplicité (ex: (A \-0,1) (B \-0,1) = (A B) \-0,2 ). D'où la perte inévitable de signal à chaque passage à un nouvel algorithme, Lossless ou pas. Donc passer un CD à n'importe quel autre format (même théoriquement 100 fois meilleur) va nécessairement entraîner une dégradation du signal (même inaudible) mais on peut espérer qu'Apple ne rippe pas de vulgaires CD pour faire ces ALAC!
avatar JoKer | 
Si je comprends bien vos histoires d'erreur, on peut penser qu'un lecteur CD à autant de chance de créer des erreurs pendant le décodage du signal numérique du CD qu'une autre puce qui décoderait un fichier compressé sans perte. Et vu le niveau dont on parle, je doute qu'une oreille humaine puisse décelé une erreur dans un décodage.
avatar coink | 
@Joker : C'est pour ça qu'il y a des platines CD haut de gamme à 1000€ avec une électronique de la mort qui tue ;)
avatar JoKer | 
Ouais... et je peux aussi mettre 1000 euros dans un boitier de sortie audio pour mon Mac.
avatar coink | 
Et tu peux brancher cette sortie sur un kit 2.1 à 49.90€ ... Ou sur un ampli hifi haut de gamme :p (Un bon DAC de sortie pour mac ça ne coûte pas 1000€, 300/500€ tout au plus. Et les ampli hifi (non entrée de gamme) possèdent généralement des entrées optiques avec le DAC qui va derrière)
avatar JoKer | 
Ce qui nous ramène à ce que je disais plus haut, je ne vois pas la différence entre une musique au format CD ou dans un format sans perte.
avatar Anonyme (non vérifié) | 
@joneskind j'ai bien compris ce que vous dites justement, relisez la définition la compression sans perte: "Lossless data compression is a class of data compression algorithms that allows the exact original data to be reconstructed from the compressed data. The term lossless is in contrast to lossy data compression, which only allows an APPROXIMATION of the original data to be reconstructed, in exchange for better compression rates." compression SANS perte: source : destination destination : source. compression AVEC perte source : destination destination : approximation(source) "donc passer un CD à n'importe quel autre format (même théoriquement 100 fois meilleur) va nécessairement entraîner une dégradation du signal (même inaudible)" "Et oui il y a des nombres qu'un ordinateur ne peut pas écrire sous une forme exacte et dont il est obligé de considérer une APPROXIMATION" - ce n'est PAS de la compression sans perte!
avatar coink | 
FLAC ou ALAC utilisent des codes types Huffman, du genre arbre/dictionnaire. Tout comme le zip. Il n'y a aucune perte lors de la décompression. Sinon le fichier est détecté comme corrompu via un CRC de toute façon.
avatar JoKer | 
"Et oui il y a des nombres qu'un ordinateur ne peut pas écrire sous une forme exacte et dont il est obligé de considérer une APPROXIMATION" Ceci est donc valable pour tout ce qui est échantillonné. Donc pour le CD aussi.
avatar HAL-9000 | 
Non pas pareil que pour un CD. Si tu passe de PCM -> PCM tu fais de la copie, Alors que PCM -> ALAC tu fais de la conversion. Dans le premier cas tu as 1algo de copie dans le second 1algo copie + 1algo conversion. Donc plus de pertes probables sur le second que le premier.

Pages

CONNEXION UTILISATEUR