Encodage Apple Lossless., Des expériences??... Options

[le marsu]

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.

[Messensib]

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 )

[Mr.T]

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...

[le marsu]

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.

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 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...

[Messensib]

1° 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.

2° 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

[Miss Kiki]

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 ...

[le marsu]

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 ?

[Messensib]

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.

[Mr.T]

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...).

Ce message a été modifié par Mr.T - jeu. 24 juin 2004, 18:29.

[le marsu]

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."

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...