Oui donc, comme je le demandais dans le sujet "MP3" (avant de m'auto-censurer pour OT), est ce que certains parmi vous ont eu l'occasion de tester l'encodage Apple Lossless qui semble, sur le papier, assez intéressant et prometteur?...
Si oui, avec quel résultat, en utilisant quels réglages et quid de la compatibilité des fichiers résultant avec nos amis du monde PC??...

Bon je reviens à la charge... Alors personne?... Personne n'a pu tester ce nouveau format??... Pour un forum Mac, c'est quand même surprenant... Nan?...

trés bien du point de vue son, peut être, mais là c'est subjectif une sensation
de legère froideur (ds le grave par rapport à l'aif)
meilleur par exemple qu'un mp3 (192kbps) qui ds le aigues...fait semblant
par contre point de réglages sur l'ail tiounze tout automatique
so... shut up plug and ear

et question qu'on peut se poser : l'ALAC serait il une sorte de FLAC ?

D'après ce que j'ai compris, en théorie (ie les erreurs de lecture et de traitement en moins) le fichier décompressé est 100% identique à l'originale, donc l'impression de froideur ne me semble vraiment être qu'une impression. Mais j'ai pas trop testé en fait...

ben oui, normalement lossless=parfaitement transparent.

OK. Bon ben je crois que je vais essayer tout ça moi même...
La question que je me posais concernait aussi la compatibilité avec le voisin PC... Le codec existera t-il dans Windows Media Player ou Winamp?... Rien n'est moins sûr... J'vais me rencarder...

Pour ceux que ça intéresserait (ils n'ont pas l'air nombreux), j'ai trouvé un article intéressant à ce sujet (ainsi qu'au sujet des différents encodages "lossless" déjà existant). Cet article répond au moins à une question: à l'heure qu'il est seuls ITunes et QT sont capables de lire ce format de compression... Et encore, il faut les bonnes versions (Itunes 4.6). Un peu limité donc.
C'est là:
http://www.neilturner.me.uk/2004/May/09/ap...ss_encoder.html

En clair, ça donne quoi cet encodage lossless, pour un fichier aif de 50 Mo par exemple ?

Ben 25Mo grosso modo... J'ai téléchargé ITunes 4.6, j'vais faire des essais.

un de mes dictons préférés dit : "on ne peut pas mettre 1 litre et demi dans une bouteille d'1 litre "
expliquez moi comment on fait du "lossless" en encodant 25 meg à aprtir de 40 ...
un truc m'échappe
et j'ai rien trouvé sur le net qui decrive avec precision ce codec ...

Je viens de faire un test avec Itunes 4.6. Un fichier AIFF de 82 Mo est réduit à 46 Mo. Ce qui est bizarre, c'est qu'il lui accole l'extension .m4a, comme pour les fichiers AAC...

J'imagine que pour le décompacter, il faut régler l'importation (dans les pref) sur AIF, et aller le convertir depuis la bibliothèque. Et là normalement, on retrouve la qualité originale ?

////Ah, post croisé avec le melon à l'eau... j'y vais quand même...////
------------------------------------------------------------------------
Bon, c'est installé. Première surprise, le fichier obtenu en utilisant l'ALE est un fichier Mpeg4... Je savais pas... Deuxième surprise, QT est incapable de lire le fichier obtenu... J'ai pourtant QT Pro 6.4 (6.2 minimum recommandé par Apple) et le codec Mpeg4. Bizarre.
Pour la taille, j'ai pris un AIFF (44.1/16/stereo entrelaçée) d'un de mes morceaux pesant à l'origine 35,4 Mo et j'arrive après encodage à 24,1Mo. On est loin de la réduction de moitié promise par Apple.

Pour la qualité, difficile à dire puisque seul Itunes est capable de lire la chose. Je ne peux donc importer directement le fichier ALE dans PT.
Du coup j'ai reconverti le fichier ALE en AIFF dans Itunes et importé dans PT le mix d'origine et cet AIFF issu du fichier ALE.
Opposition de phase sur une des pistes dans PT et... plus rien.
Ca tendrait donc à confirmer la qualité de l'encodage LossLess.
Si ce n'est que ça marche peut être comme StuffIt... Une fois décompacté, on retrouve la qualité d'origine??... Il aurait été plus intéressant de pouvoir tester le fichier ALE lui même... En tout cas, à l'oreille, dans ITunes, aucune différence notable.

Dommage qu'il ne soit lisible QUE par Itunes (adieu monde PC sauf pour possesseur éclairés d'Itunes pour Windows 2000 et XP, rares à mon sens), et QUE par la version 4.6 (adieu possesseurs d'une version antérieure et notamment sous Mac OS9).
Un peu inutile en somme, du moins pour ce qui est de l'échange de fichiers vers l'extérieur. Pour du stockage privé et perso, ça parait, en revanche, plutôt intéressant.

faut voir.....

si tu enleves de l'oxygene, tu gagnes en volume

oui, me diras tu, mais ça manque un peu d'air, non?

donc pour que votre mix ne respire plus, adoptez le lossless.

le premier mix regazifié avec son propre gaz !!

c'est une longue enigme, le monstre du lossless.

tu le vois....et hop....tu le vois plus.

sans blague, à part pour les fameux "createurs" appleliens de bibliothèque musicale, où se trouve l'interet de ce codec, à part de s'isoler encore un peu plus de l'universalité

Intéressant ce petit test, Mr T.

Normalement, dites-moi si je me trompe, ce genre de format, c'est pas fait pour être lu, c'est juste un "compactage" provisoire, un peu à la manière de Stufft. Je pense que Apple a bidouillé un truc (avec l'extension .m4a) pour que Itunes puisse le reconnaître malgré tout.
Mais la question, en fait ça serait: est-ce que ce format peut être "décompacté" (et non, lu) par d'autres plates-formes ? (j'y connais rien en la matière)

Et si c'est vraiment sans perte de qualité, c'est quand même très intéressant pour des échanges de fichiers audio entre musiciens (pour autant, qu'ils partagent la même plate-forme, c'est vrai... )

Pour moi l'intérêt du lossless serait pour le stockage des séances sur un seul CD (la plupart de mes séances font 1Go).
Est-ce que l'encodage supporte les fichiers aif en 24 bits ?

(petit OT) Puisqu'on parlait d'AAC, personne ne m'a trouvé le moyen de lire ou décoder ce format sur Mac OS9, je sèche !!!

et stuffit comment ça fait alors ? j'ai toujours cru que ça" rangeait " mieux ... genre , chez moi tu ranges , tu gagnes de la place ! sinon effectivement ...

Oui, j'ai fait le test et ça supporte tous les formats: 44,1/16, 44,1/24, 48/16, 48/24... Pas mal...

Pour ceux que ça intéresse, comme le FLAC est un standard ouvert il est assez bien documenté, on peut lire ici :
http://flac.sourceforge.net/format.html
Je ne trouve pas de doc équivalente pour l'Apple LossLess, mais je me dis que le prinicipe doit être proche.
Si je résume ce que je comprends :
- On scinde le signal en bloc, de taille variable
- On décorelle le signal stéréo, ie on transforme le droite + gauche en milieu + différence par rapport au milieu
- On fait une modélisation mathématique du signal, modélisation facile à décrire de manière très légère (au sens poids des données)
- Ensuite il reste évidemment une différence entre le modèle mathématique et la réalité, c'est cette différence qui est encodé sans perte de qualité (une sorte de sit ou de zip). Et il est plus efficace de compresser cette différence que le signal initial.

Après je ne suis pas un spécialiste, si quelqu'un a des infos plus précises (ou des explications plus claires... ), je suis preneur...

t'as jamais trouvé tes documents Word plus froid après une compression stuffir ?

à mon avis le lossless est très intéressant pour le i-pod s'il n'y a effectivement aucune perte.

Et il n'y aurait pas dérrière tout ça un peu de "Zap" d'Emagic ?

C'est visiblement un peu plus compliqué. On lit que le signal est découpé ainsi:
"* Independent. The left and right channels are coded independently.
* Mid-side. The left and right channels are transformed into mid and side channels. The mid channel is the midpoint (average) of the left and right signals, and the side is the difference signal (left minus right).
* Left-side. The left channel and side channel are coded.
* Right-side. The right channel and side channel are coded".

Le signal stéréo est donc en fait divisé en Left et Right, tout deux indépendants, Side channel et Mid channel...
En gros, de ce que j'en comprends, ça ressemble furieusement à l'encodage LtRt issu d'un LCRS... 4 canaux qui deviennent 2 pour ensuite être à nouveau décodés en 4. Si ce n'est que, dans le cas du LtRt, l'opposition de phase est utilisée pour séparer les canaux puis les réunir à nouveau. Je me demande d'ailleurs si ce n'est pas ce même systême qui est utilisé ici (même s'il n'en est pas fait mention directement, on parle de "Left minus Right", Gauche-droite donc).

Mon explication était en effet erronée, en revanche quand je relis je ne comprends pas qu'il y ait 4 canaux. Ce que je comprends, c'est que les 4 points que tu listes sont 4 manières différentes de décorréler le signal : on choisit celle qu'on veut à l'encodage. Pour moi décorrélation signifie "extraire ce qui est différent entre le gauche et le droit".
Cas 1 : indépendant, on ne calcule pas la corrélation, on code chaque canal séparément
Cas 2 : mid-side, on calcule un canal milieu (ce qui est commun à gauche et droit), et un canal "side", qui est la différence entre gauche et droit
Cas 3 : On garde le canal gauche complet, et on code la difference entre gauche et droit
Cas 4 : On garde le canal droit complet, et on code la difference entre droit et gauche

Me gourre-je ?

A noter que le FLAC permet pendant l'encodage de faire tourner un décodeur en parallèle, et de comparer en temps réel l'entrée et la sortie, pour être vraiment sûr que le signal entrant en identique au signal sortant.
J'aimerais bien savoir si iTunes fait ça en Apple Lossless...

Non, non, on est bien d'accord, je ne parlais du LtRt que pour le côté oppo de phase permettant de réunir deux signaux en un...
Ce n'est évidemment pas exactement la même chose pour un encodage stéréo...

Tout à fait lisible par quicktime, il faut la version 6.5.x...Panther 10.3.4

Cette version de QT n'est pas uniquement disponible pour Panther.
10.2.x ok.

Je suis un ex-matheux, et peux vous dire que la miss a parfaitement raison. S'il n'y a aucune redondance (répétition, grosso modo) dans le signal musique, il est parfaitement impossible de le comprimer sans perte (aucun échantillon ne peut être prévu par des précédants)
Stuffix, ça ne marche que parce qu'il y a des répétitions. Pour rester simple:
0000000000000000000000000000000000000000 peut s'écrire:
40X0, on a pu "comprimer" sans perte.

La manip de Mr.T, je ne la vois pas bien, il est obligé de convertir...

PS Je voulais faire ça pour le mp3, là il faut convertir aussi (je ne sais pas le faire) mais en faisant la différence "original - compressé", on doit entendre tout ce qu'on perd, à très peu près. Un "pro" devrait pouvoir faire ça... Pardon de ne pas ouvrir un sujet là-dessus, mais ça pourrait renseigner sur la qualité des différents systèmes de compression.

C'est, je crois, là où tu te trompe Maurice, ainsi que la Miss.
Il ya des redondances dans un mix stéréo (pour reprendre ton expression).
Certains élémentsde la droite vont se retrouver à l'identique à gauche, des éléments du "centre" ou "milieu" vont également se retrouver distribués à gauche et à droite (prends le cas d'une voix au centre mais réverbérée en stéréo par exemple) et c'est justement, de ce que j'en ai compris, sur ces redondances que travaille l'encodeur.
Encore une fois, on retrouve d'ailleurs plus ou moins ce type de procédé dans l'encodage LtRt (où 4 canaux deviennent 2 pour redevenir 4) où l'opposition de phase permet de mélanger un signal à un autre pour ensuite le "dé-mélanger" (je suis très très loin d'être un matheux moi-même... un Mathieu à la rigueur... Arf, Arf, elle est bonne...). ceci dit, dans ce cas prècis, il est clair qu'il y a dégradation flagrante du signal.

Mon "explication" est, j'en conviens, aussi grossière qu'approximative mais je pense que c'est à peu près ça.

Quant à ma manip, qu'est ce que tu ne comprends pas?...
Je prends un mix, je l'encode en ALE, je le re-encode en AIFF (pour pouvoir le lire dans PT qui ne prend pas le format ALE) et le compare au mix d'origine. En mettant l'un des mix en opposition de phase, je constate qu'il n'y a plus rien... Les deux mixs sont donc parfaitement identiques.
L'un des deux mixs est pourtant bien passé par l'encodage ALE...

Euh, je crois qu'on mélange un peu tout là... Il y a plein de méthodes pour compresser, et un signal audio est justement qqchose qui est hautement redondant (surtout ceux faits avec Garage Band !)
Encore une fois si on part du FLAC (dont on peut avoir une explication technique), les méthodes de compression des données sont multiples au sein d'un même format :
1- Décorréletion : on sait que bien souvent les canaux gauche et droite sont proches, donc au lieu de décrire les deux, on en décrit un et la différence entre les deux => première économie
2- Modélisation : on approxime le signal par une fonction mathématique qu'on sait décrire simplement. Pour schématiser, on dit : mon signal audio, c'est une sinusoïde (par ex.) + un autre bout de signal => deuxième économie
3- Le bout qui reste on l'encode "à la stuffit", c'est à dire je pense ce que décriit messeensib (111111 ~ 6x1), même si je ne trouve pas de doc sur le net décrivant précisément la compression sit ou zip. => Troisième économie

Petit test : Je prends un fichier Wave original, je l'encode en ALE, je le décode ensuite avec iTunes. Si je regarde la taille des fichiers avant/après, il y a tout de même qq octets de différence. Un outil de comparaison binaire nous dirait donc que les fichiers ne sont pas identiques. On n'est donc pas sur une compression du type StuffIt (où on _doit_ avoir la même chose avant et après, au bit près).

Mr.T : As-tu fait le même test avec un mp3 bien encodé ? Est-ce qu'on entend vraiment qqchose en sortie à ce moment là ?

Rq : iTunes devient très répandu sur les PC, ce n'est donc pas forcément "s'enfermer" que d'utiliser ce format.

Non, le marsu, on ne mélange pas tout. Les 3 traffics que tu décris modifient le signal. Le 1er ne change rien du tout, d'ailleurs.

Les systèmes de codages mp3, AAC etc... tiennent compte des soi-disants "défauts de l'oreille", l'effet de masque, entre autres. Les auteurs ont dû faire des mesures psychoacoustiques sur des cobayes (les pauvres...).

Il y a une description du mp3 (succinte) sur:
http://www.iis.fraunhofer.de/amm/techinf/l...yer3/index.html

Pour moi, la meilleure compression serait:
<< Aller à votre discothèque, choisir votre CD, l'introduire dans la platine à la plage désirée et appuyer sur "Play" >> (ça doit pas faire plus de 1 ko )

Oui j'ai vérifié (j'ai vraiment que ça à faire...) :
-Fichier original= 41781132 octets.
-Fichier original encodé en ALE puis réencodé en AIFF=41779636 octets.

Soit une différence de (roulement de tambour...) : 1496 octets.
1,5Ko...
Ca va, c'est honorable...

Non non, pas d'accord, ce que je décris c'est pas du mp3 ou du AAC, pas question ici de masquage de fréquence et autres bidouillages psychoacoustiques. C'est uniquement des méthodes algorithmiques de compression, adaptées aux fichiers audio. Lis bien le lien que j'ai posté plus haut, tu verras que c'est différent.
Avec le FLAC, il est prévu dans la description du format que le fichier à la sortie du décodeur puisse être comparé au fichier à l'entrée du décodeur, et s'ils ne sont pas 100% pareil, hop message d'erreur... C'est le but recherché de ce format : ne pas dégrader le signal initial.



Oui bon, je suis bien d'accord... Encore que le temps de parcourir les trois mètres de CD pour trouver celui qu'on cherche, par rapport à une petite recherche dans iTunes... Faut avoir le temps, être retraité, tout ça...

1° OK, je vais lire. Y-a que les crétins qui ne changent pas d'avis

2° (OT) Contrairement à ce qu'on pourrait croire, "certains" retraités qui essayent de faire tout ce qu'ils n'ont pas pu (faire) pendant qu'ils bossaient, sont surbouqués

donc c'est bein ce que je me disais au début du thread l'ALAC ou l'ALE c'est une sorte de FLAC ...

Ben on peut le subodorer en effet, mais en l'abscence de toute doc technique d'Apple, au final on sait pas trop ce qui se passe...
Au niveau compression, sur les qq morceaux encodés jusqu'ici, je suis plus proche de 30% que des 50% annoncés par Apple.
Sont à combien les disques 300Go maintenant ?

D'abord, pardon Mathieu, je n'avais pas lu ta réponse en fin de la page 2.

Bon, j'ai pas fini de lire ton lien, le marsu. Mais que vois-je dès le début ?:
"Though it can losslessly code any input, only certain kinds of input will get smaller."

D'abord, cela va sans dire, on ne peut avoir que ( left + right) et ( left - right), donc en aucun cas ce qu'il y a au milieu "tout seul" (appelons le M), ni bien sûr ( left - M) ni ( right - M). Cela va mieux en le disant, ça parait c*n, mais j'ai l'impression que certains peuvent penser qu'il y a 3 canaux (!), pas vous, bien sûr
L'histoire des blocks mal utilisés, d'accord. Mais quand on fait le calcul, ils ont l'air plutôt bien utilisés...
Dès que je vois le mot "prédiction", je suis sceptique
Bien sûr, c'est évident que si on est en mono pure, on peut diviser la place occupée par deux.
Pure spéculation de ma part: si on donne plus de "poids" à ce qu'il y a au milieu (et qu'on n'a jamais) on modifie forcément qque chose, peut-être le rapport S/B (?)
Bon, lettre suit....

PS C'est OT, mais Mathieu, t'as fait ta manip avec du mp3 comme le demandait aussi le marsu ? Là, en faisant la différence, on doit forcément entendre ou voir ce qu'on perd.

Je viens de la faire (j'avais oublié la demande et n'en voyais que moyennement l'intérêt étant assez sûr du résultat...).

J'ai donc pris un de mes mixs (AIFF/ 44.1/ 16bit), l'ai converti en deux MP3, d'abord en 192k puis un autre en 320K (le max proposé par Itunes).
J'ai ensuite re-converti ces deux MP3 en AIFF. Import des 3 dans PT (AIFF d'origine, ex-MP3 192K et ex-MP3 320K) et oppo de phase.

Alors déjà, chose étonnante, j'ai dû recaler à la mano les deux MP3 qui s'était décalés par rapport au mix d'origine... Les formes d'ondes n'étaient pas alignés... Bizarre.
La conversion en MP3 a rajoutée 24ms (soit 1058 samples) au début du mix... Allez comprendre.
Le tout recalé bien comme il faut, il y a définitivement une différence que ce soit entre l'AIFF d'origine et les deux MP3 ainsi qu'entre les deux MP3 eux mêmes.
Altération du signal donc après passage à la moulinette MP3.
Franchement, vous en doutiez??...

PS: à noter aussi, les deux MP3 re-convertis en AIFF (après avoir trouvés la foi) pèsent un chouille plus lourd que l'AIFF d'origine (la différence est en dessous du Ko mais quand même...).

Bon, devant ton scepticisme, une petite démo vaut mieux qu'un long discours

Je prends un fichier Wav, 16bit/44.1kHz, "Rhapsody in Blue" d'un certain Gershwin...
Taille initiale : 173 836 364 octets

Je l'encode avec FLAC 1.1
Taille encodée : 69 895 623 octets, 40% de la taille originale, pas mal...

Je le décode avec le même FLAC
Taille décodée : 173 836 364 octets

Je génère une signature numérique pour chacun des deux fichiers => la même
Les deux fichiers sont 100% identiques

Na

Après, peut être ça marche moins bien avec du hip-hop...

Bon, mais je ne tiens pas particulièrement à avoir raison (que signifie "signature numérique" ?)
Tu as le même nombre d'octets, mais est-ce que ce sont les mêmes ? Autrement dit, as-tu fait la différence en augmentant le niveau disons de 80 dB ? (et en calant à l'échantillon près, bien sûr, je ne vais pas t'apprendre ton métier)
Si oui, j'ai tort... mais je ne m'en porte pas trop trop mal
( mais gagner 60 % sans perte, franchement, ça bouleverse fondamentalement mon équilibre mental... Là, y-a un tour de passe-passe...)

Mathieu, par curiosité, tu as écouté la différence entre les signaux lors de ta manip ? Bizarre, non ?

le marsu, je viens de passer qque temps sur le "FLAC - format", mais les bras m'en tombent (et je ne suis pas payé assez cher )
1° Bon, OK avec un certain niveau de corrélation entre gauche et droite. Mon raisonnement primaire n'est pas complètement idiot:
- Si gauche = droite (mono pure) on divise la taille par 2.
- Si gauche n'a aucun rapport avec droite: rien à faire.
- Entre les deux, on doit pouvoir gagner, mais jamais plus de 50%...

2° Ils parlent de 4 systèmes de prédiction (c'est là que j'ai décroché ) Disons que c'est un genre d'extrapolation. C'est sûrement le système le plus important (peut-être avec de la "mémoire" ...)

3° Ensuite, c'est le signal d'erreur = la différence entre le "vrai" signal et le signal "prédit" qui est codé sans perte. Plus "l'erreur" sera faible, moins elle aura de poids. Cela ne peut marcher que parce qu'on est en numérique et qu'on a simultanément "sous la main" plusieurs échantillons successifs.

Et je me suis arrêté là. Je n'irai pas plus loin

Mais Mathieu et le marsu, si vous parlez de fichiers identiques à 100%, je veux voir " moins l'infini " sur le peakmètre de ProTools quand on en fait la différence. (J'exagère bien sûr, mais combien ? - 100, - 80 dB ?)

PS le marsu, que tu gagnes 60% sur "Rhapsody in blue", vraiment, ça me troue le .... Ce serait du hip hop encore ...

Mais non, tu n'exagère pas Maurice... Quand tu fais une oppo de phase sur deux fichiers identiques, il ne reste strictement rien, nada, niente.
Et, dans le cas de l'encodage ALE, c'est exactement ce que j'ai constaté.
Pour ce qui est de l'écoute des MP3, oui j'ai écouté rapido et si j'entend vaguement une dégradation sur le 192K (et encore, ça dépend des passages), je n'entends rien de spécial sur le 320K.
Bon, ceci dit, ça dépend sans doute aussi du type de musique... Peut être que j'entendrais qqlchose s'il s'agissait d'un philarmonique... Là c'était un de mes morceaux (bien chargé dans le genre), donc le son n'est déjà pas tip-top au départ...

Ah ! moi si !
Sans rire je m'étais jamais demandé comment ça marchait et c'est plutôt intéressant...



C'est les signatures numériques générées dans emule ou mldonkey. Ca génère un mot d'une vingtaine de caractères qui permet d'identifier à coup sûr un fichier, même si on a changé le nom. La norme a un nom dont je ne me rappelle plus. C'est proposé aussi parfois sur certains download, pour vérifier que le fichier downloadé est identique au fichier sur le serveur.
J'ai fait le test : je change juste la hauteur d'un sample du fichier, la signature n'est plus la même...

Digi appelle ça le "Magic Id"... Sont poêtes chez Digi quand même...

quelqu'un pourrait il flacquer du silence?

pour voir combien on gagne

Silence d'heral, codé en FLAC 1.1.

Ce silence eut pu prendre moins de place... Encore eut-il fallu que vous le flacquassiez...

Ce qui me désole, c'est que personne n'ose me dire que je raconte des âneries ( j'avais toutefois pris la précaution de mettre un "si": "S'il n'y a aucune redondance...etc...")
Il n'y a que le marsu qui m'a "démontré" qu'une musique était "compressible" "lossless". Or, ce n'est même pas la peine de le démontrer. C'est évident qu'il y a de la redondance dans n'importe quelle musique, sauf les "stochastiques", et encore.( Ma seule excuse est que dans ma 1ère vie, je faisais de la R&D sur des radars où on n'utilisait que des signaux "incompressibles", mea culpa si j'ai extrapolé à la musique).
En jettant un coup d'oeil sur les systèmes de compression "lossless", je m'aperçois d'abord que le gain de place n'est pas considérable, qu'il dépend du genre de musique, que le temps de codage peut ne pas être négligeable, et enfin que, comme d'habitude, il y aura lutte entre les différents standards (c'est pas tjrs le meilleur qui gagne...)
Là-dessus, je ne vois pas trop l'intérêt du "lossless" pour du back-up. C'est surtout pour l'envoi de fichiers où l'upload est tjrs faible ( 256 kb/s max pour l'instant - ?-) qu'on peut gagner du temps.
Ceci dit, je la boucle