Le codec sans pertes d’Apple, ALAC, est disponible en open source. L’ALAC permet de compresser un fichier audio sans pertes (contrairement à l’AAC et au MP3) mais évidemment avec une compression moindre. On est en général aux alentours de 2x, ce qui n’est pas si mal. ALAC est supporté dans la majorité des produits Apple et offre les mêmes fonctions que l’AAC pour les tags et autres joyeusetés.
L’avantage principal d’ALAC par rapport au FLAC, un autre codec sans pertes, c’est qu’il est simple à décoder sur des appareils peu puissant comme des baladeurs. En effet, FLAC est plus rapide à l’encodage et au décodage mais en lecture pure, ALAC demande moins de puissance.
Personnellement, je n’utilise pas ALAC, l’AAC 256 kilobits/s me suffit amplement et je préfère garder un peu de place sur mes SSD et mes appareils iOS.
Salut,
« En effet, FLAC est plus rapide à l’encodage et au décodage mais en lecture pure, ALAC demande moins de puissance. »
Euh… si FLAC est plus rapide à l’encodage et au décodage (donc consomme moins de ressources pour obtenir le même résultat), comment « en lecture pure » ALAC pourrait-il demander moins de puissance?
Le seul avantage d’ALAC vis-à-vis de FLAC, c’est qu’il est compatible iMachins
http://wiki.hydrogenaudio.org/index.php?title=Lossless_comparison
parce que FLAC est plus rapide à la décompression avec des algos qui utilisent FPU et autres SIMD. Mais ça demande des puces adaptées dotées des instructions en question.
De l’ALAC se décode en temps réel sur des vieux ARM7 sans FPU juste en entier.
Info intéressante, je n’avais pas pensé à l’éventualité plate-formes limitées à l’entier seulement.
A l’heure actuelle, quelles sont les plate-formes concernées (où le décodage FLAC/ALAC ne se ferait que sur entiers parce qu’il n’y a pas de FPU ou autres)?
je ne sais pas si ça existe encore, c’était juste un argument en 2004, pour l’iPod
Sinon, ALAC est utilisé pour AirPlay, aussi