[Q] Qualité du codec audios : Apple Lossless vs AIFF
108 réponses
Paul
concernant le téléchargement de musique avec iTunes, Apple dit :
"Clients et mélomanes exigeants souhaitant bénéficier d¹un son de
qualité CD, iTunes ne vous a pas oubliés : il vous offre désormais le
nouvel encodeur Apple Lossless. En effet, ce nouveau codec vous
permettra de préserver intégralement la qualité des CD audio non
compressés tout en ne nécessitant qu¹un espace de stockage réduit de
moitié."
Ce qui les rend différent du ZIP fondamentalement (a part l'usage) c'est qu'il sont spécialisés dans l'audio et qu'il ne nécessite aucun archivage les données restent utilisable directement.
Qu'entends tu par "archivage" (dans le cas d'un seul fichier compressé)?
Copie pour archive, la définition normale... Qu'il y ait 1 ou plusieurs fichiers ne change rien a l'affaire. Je comprend pas trop l'interrogation...
Qu'entends tu par "directement"?
Accès sans avoir a décompresser ou utiliser un outil pour accéder.
Je suis pas clair ?
-- Pierre-Alain Dorange
Vidéo, DV et QuickTime pour Mac <www.garage-video.fr.st> Clarus, the DogCow <www.clarus.mac-fan.com>
Fra <fra@alussinan.org> wrote:
Ce qui les rend différent du ZIP fondamentalement (a part l'usage) c'est
qu'il sont spécialisés dans l'audio et qu'il ne nécessite aucun
archivage les données restent utilisable directement.
Qu'entends tu par "archivage" (dans le cas d'un seul fichier compressé)?
Copie pour archive, la définition normale... Qu'il y ait 1 ou plusieurs
fichiers ne change rien a l'affaire.
Je comprend pas trop l'interrogation...
Qu'entends tu par "directement"?
Accès sans avoir a décompresser ou utiliser un outil pour accéder.
Je suis pas clair ?
--
Pierre-Alain Dorange
Vidéo, DV et QuickTime pour Mac <www.garage-video.fr.st>
Clarus, the DogCow <www.clarus.mac-fan.com>
Ce qui les rend différent du ZIP fondamentalement (a part l'usage) c'est qu'il sont spécialisés dans l'audio et qu'il ne nécessite aucun archivage les données restent utilisable directement.
Qu'entends tu par "archivage" (dans le cas d'un seul fichier compressé)?
Copie pour archive, la définition normale... Qu'il y ait 1 ou plusieurs fichiers ne change rien a l'affaire. Je comprend pas trop l'interrogation...
Qu'entends tu par "directement"?
Accès sans avoir a décompresser ou utiliser un outil pour accéder.
Je suis pas clair ?
-- Pierre-Alain Dorange
Vidéo, DV et QuickTime pour Mac <www.garage-video.fr.st> Clarus, the DogCow <www.clarus.mac-fan.com>
Paul GABORIT
À (at) Fri, 18 Jun 2004 17:33:26 +0200, (Fra) écrivait (wrote):
Paul GABORIT wrote:
Ça permet de les utiliser sur des streams temps réel.
Ca veut dire que le bloc minimal à lire pour commencer à émettre un son est petit ?
Ça veut dire qu'un fichier de 1Go compressé par gzip et dont le centième octet est faux (sans qu'on sache que c'est celui-là) ne pourra jamais plus être décompressé.
Alors qu'un fichier audio de 1Go compressé avec un codec lossless adapté au stream et dont le centième octet est faux sera audible sauf le tout début (en fait le bloc erroné sera détecté et tout simplement sauté ce qui n'est pas possible avec un flux gzip). L'auditeur entendra certainement un couac dû au saut du bloc mais il pourra tout de même entendre les 2 heures de musiques qui suivent.
C'est la même technique qui est utilisé dans le format mpeg2 des DVD qui permettent de voir un DVD rayé (pas trop tout de même) avec saut des plages rayées.
Quel est la taille (la durée) d'un bloc indépendant dans le codec lossless d'Apple ? Je n'en sais rien. Utilise-t-il cette technique de blocs indépendants ? Je n'en sais rien non plus mais cela m'étonnerait que les ingénieurs d'Apple l'ait oublié.
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
À (at) Fri, 18 Jun 2004 17:33:26 +0200,
fra@alussinan.org (Fra) écrivait (wrote):
Paul GABORIT <Paul.Gaborit@invalid.invalid> wrote:
Ça permet de les utiliser sur des streams temps réel.
Ca veut dire que le bloc minimal à lire pour commencer à émettre un son
est petit ?
Ça veut dire qu'un fichier de 1Go compressé par gzip et dont le centième octet
est faux (sans qu'on sache que c'est celui-là) ne pourra jamais plus être
décompressé.
Alors qu'un fichier audio de 1Go compressé avec un codec lossless adapté au
stream et dont le centième octet est faux sera audible sauf le tout début (en
fait le bloc erroné sera détecté et tout simplement sauté ce qui n'est pas
possible avec un flux gzip). L'auditeur entendra certainement un couac dû au
saut du bloc mais il pourra tout de même entendre les 2 heures de musiques qui
suivent.
C'est la même technique qui est utilisé dans le format mpeg2 des DVD qui
permettent de voir un DVD rayé (pas trop tout de même) avec saut des plages
rayées.
Quel est la taille (la durée) d'un bloc indépendant dans le codec lossless
d'Apple ? Je n'en sais rien. Utilise-t-il cette technique de blocs
indépendants ? Je n'en sais rien non plus mais cela m'étonnerait que les
ingénieurs d'Apple l'ait oublié.
--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
À (at) Fri, 18 Jun 2004 17:33:26 +0200, (Fra) écrivait (wrote):
Paul GABORIT wrote:
Ça permet de les utiliser sur des streams temps réel.
Ca veut dire que le bloc minimal à lire pour commencer à émettre un son est petit ?
Ça veut dire qu'un fichier de 1Go compressé par gzip et dont le centième octet est faux (sans qu'on sache que c'est celui-là) ne pourra jamais plus être décompressé.
Alors qu'un fichier audio de 1Go compressé avec un codec lossless adapté au stream et dont le centième octet est faux sera audible sauf le tout début (en fait le bloc erroné sera détecté et tout simplement sauté ce qui n'est pas possible avec un flux gzip). L'auditeur entendra certainement un couac dû au saut du bloc mais il pourra tout de même entendre les 2 heures de musiques qui suivent.
C'est la même technique qui est utilisé dans le format mpeg2 des DVD qui permettent de voir un DVD rayé (pas trop tout de même) avec saut des plages rayées.
Quel est la taille (la durée) d'un bloc indépendant dans le codec lossless d'Apple ? Je n'en sais rien. Utilise-t-il cette technique de blocs indépendants ? Je n'en sais rien non plus mais cela m'étonnerait que les ingénieurs d'Apple l'ait oublié.
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
Patrick Stadelmann
In article <1gfl8he.u1dnv21y42nn6N%, (Patrick C) wrote:
Donc quand le PC extrait du Wav, c'est comme si le mac extrait du Aiff.
Oui, c'est les même échantillons, mais emballés différemment.
Tu fais la conversion facilement ? (sur le mac j'entends).
Entre AIFF et WAV ? Oui, la plupart des softs manipulants de l'audio permettent cette conversion.
Patrick -- Patrick Stadelmann
In article <1gfl8he.u1dnv21y42nn6N%cochardp@alussinan.org>,
cochardp@alussinan.org (Patrick C) wrote:
Donc quand le PC extrait du Wav, c'est comme si le mac extrait du Aiff.
Oui, c'est les même échantillons, mais emballés différemment.
Tu fais la conversion facilement ? (sur le mac j'entends).
Entre AIFF et WAV ? Oui, la plupart des softs manipulants de l'audio
permettent cette conversion.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <1gfl8he.u1dnv21y42nn6N%, (Patrick C) wrote:
Donc quand le PC extrait du Wav, c'est comme si le mac extrait du Aiff.
Oui, c'est les même échantillons, mais emballés différemment.
Tu fais la conversion facilement ? (sur le mac j'entends).
Entre AIFF et WAV ? Oui, la plupart des softs manipulants de l'audio permettent cette conversion.
Patrick -- Patrick Stadelmann
fra
Pierre-Alain Dorange wrote:
Qu'entends tu par "archivage" (dans le cas d'un seul fichier compressé)?
Copie pour archive, la définition normale... Qu'il y ait 1 ou plusieurs fichiers ne change rien a l'affaire. Je comprend pas trop l'interrogation...
Rien n'empèche de détruire l'original. Idem pour aiff->lossless.
Qu'entends tu par "directement"?
Accès sans avoir a décompresser ou utiliser un outil pour accéder.
Je suis pas clair ?
Je crois que j'ai compris. Il ya "interprétation" (pour lecture) du fichier et non "décompression" (?) (C'est subtil comme différence vu que le fichier est plus petit que du PCM.) -- Fra
Qu'entends tu par "archivage" (dans le cas d'un seul fichier compressé)?
Copie pour archive, la définition normale... Qu'il y ait 1 ou plusieurs
fichiers ne change rien a l'affaire.
Je comprend pas trop l'interrogation...
Rien n'empèche de détruire l'original. Idem pour aiff->lossless.
Qu'entends tu par "directement"?
Accès sans avoir a décompresser ou utiliser un outil pour accéder.
Je suis pas clair ?
Je crois que j'ai compris. Il ya "interprétation" (pour lecture) du
fichier et non "décompression" (?)
(C'est subtil comme différence vu que le fichier est plus petit que du
PCM.)
--
Fra
Qu'entends tu par "archivage" (dans le cas d'un seul fichier compressé)?
Copie pour archive, la définition normale... Qu'il y ait 1 ou plusieurs fichiers ne change rien a l'affaire. Je comprend pas trop l'interrogation...
Rien n'empèche de détruire l'original. Idem pour aiff->lossless.
Qu'entends tu par "directement"?
Accès sans avoir a décompresser ou utiliser un outil pour accéder.
Je suis pas clair ?
Je crois que j'ai compris. Il ya "interprétation" (pour lecture) du fichier et non "décompression" (?) (C'est subtil comme différence vu que le fichier est plus petit que du PCM.) -- Fra
Paul
J'aurais une question supplémentaire :
j'ai fait l'acquisition de 2 CD en Apple Lossless. Au final j'ai 36 pistes représentant 2 heures de musique et 480 Mo de données.
Je pensais pouvoir graver tout ça sur un seul CD, puisque la capacité mémoire de 700Mo n'est pas dépassée. Hélas passé 1h16 (je crois...), il iTunes refuse les pistes suivantes.
J'imagine que c'est normal :-((
J'aurais une question supplémentaire :
j'ai fait l'acquisition de 2 CD en Apple Lossless.
Au final j'ai 36 pistes représentant 2 heures de musique et 480 Mo de
données.
Je pensais pouvoir graver tout ça sur un seul CD, puisque la capacité
mémoire de 700Mo n'est pas dépassée. Hélas passé 1h16 (je crois...), il
iTunes refuse les pistes suivantes.
j'ai fait l'acquisition de 2 CD en Apple Lossless. Au final j'ai 36 pistes représentant 2 heures de musique et 480 Mo de données.
Je pensais pouvoir graver tout ça sur un seul CD, puisque la capacité mémoire de 700Mo n'est pas dépassée. Hélas passé 1h16 (je crois...), il iTunes refuse les pistes suivantes.
J'imagine que c'est normal :-((
Patrick Stadelmann
In article , Paul wrote:
j'ai fait l'acquisition de 2 CD en Apple Lossless. Au final j'ai 36 pistes représentant 2 heures de musique et 480 Mo de données.
Je pensais pouvoir graver tout ça sur un seul CD, puisque la capacité mémoire de 700Mo n'est pas dépassée. Hélas passé 1h16 (je crois...), il iTunes refuse les pistes suivantes.
J'imagine que c'est normal :-((
Oui, quand tu graves un CD audio, la capacité est de 74 ou 80 minutes selon le type de CD-R, indépendamment du format des fichiers source.
Patrick -- Patrick Stadelmann
In article <paul.sellis-E2DCD3.19453318062004@news2-e.proxad.net>,
Paul <paul.sellis@alussinan.org> wrote:
j'ai fait l'acquisition de 2 CD en Apple Lossless.
Au final j'ai 36 pistes représentant 2 heures de musique et 480 Mo de
données.
Je pensais pouvoir graver tout ça sur un seul CD, puisque la capacité
mémoire de 700Mo n'est pas dépassée. Hélas passé 1h16 (je crois...), il
iTunes refuse les pistes suivantes.
J'imagine que c'est normal
:-((
Oui, quand tu graves un CD audio, la capacité est de 74 ou 80 minutes
selon le type de CD-R, indépendamment du format des fichiers source.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
j'ai fait l'acquisition de 2 CD en Apple Lossless. Au final j'ai 36 pistes représentant 2 heures de musique et 480 Mo de données.
Je pensais pouvoir graver tout ça sur un seul CD, puisque la capacité mémoire de 700Mo n'est pas dépassée. Hélas passé 1h16 (je crois...), il iTunes refuse les pistes suivantes.
J'imagine que c'est normal :-((
Oui, quand tu graves un CD audio, la capacité est de 74 ou 80 minutes selon le type de CD-R, indépendamment du format des fichiers source.
Patrick -- Patrick Stadelmann
Eric Lévénez
Le 18/06/04 9:38, dans , « Paul GABORIT » a écrit :
À (at) Thu, 17 Jun 2004 22:02:50 +0200, Eric Lévénez écrivait (wrote):
Donc en principe le gzip (ou compress ou bzip2) peut être utilisé pour compresser du son ou de la vidéo, mais en pratique ce n'est pas pratique, surtout pour les petits équipements embarqués qui ont peu de mémoire et un CPU lent.
Et puis gzip ne résiste pas à la perte ou la détérioration d'un morceau du flux. Les codecs au contraire sont en général conçus pour résister à cela (les blocs de données compressés sont indépendants les uns des autres). Ça permet de les utiliser sur des streams temps réel.
Effectivement. Mais on peut encoder un flux gzip en plaçant des points de synchro. Mais plus on place de points, moins la compression est bonne.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 18/06/04 9:38, dans <r74qp9joyh.fsf@michelange.enstimac.fr>, « Paul
GABORIT » <Paul.Gaborit@invalid.invalid> a écrit :
À (at) Thu, 17 Jun 2004 22:02:50 +0200,
Eric Lévénez <news@levenez.com> écrivait (wrote):
Donc en principe le gzip (ou compress ou bzip2) peut être utilisé pour
compresser du son ou de la vidéo, mais en pratique ce n'est pas pratique,
surtout pour les petits équipements embarqués qui ont peu de mémoire et un
CPU lent.
Et puis gzip ne résiste pas à la perte ou la détérioration d'un morceau du
flux. Les codecs au contraire sont en général conçus pour résister à cela (les
blocs de données compressés sont indépendants les uns des autres). Ça permet
de les utiliser sur des streams temps réel.
Effectivement. Mais on peut encoder un flux gzip en plaçant des points de
synchro. Mais plus on place de points, moins la compression est bonne.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 18/06/04 9:38, dans , « Paul GABORIT » a écrit :
À (at) Thu, 17 Jun 2004 22:02:50 +0200, Eric Lévénez écrivait (wrote):
Donc en principe le gzip (ou compress ou bzip2) peut être utilisé pour compresser du son ou de la vidéo, mais en pratique ce n'est pas pratique, surtout pour les petits équipements embarqués qui ont peu de mémoire et un CPU lent.
Et puis gzip ne résiste pas à la perte ou la détérioration d'un morceau du flux. Les codecs au contraire sont en général conçus pour résister à cela (les blocs de données compressés sont indépendants les uns des autres). Ça permet de les utiliser sur des streams temps réel.
Effectivement. Mais on peut encoder un flux gzip en plaçant des points de synchro. Mais plus on place de points, moins la compression est bonne.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
pmanet
Fra wrote:
Mais le système doit-il tout décompresser le lossless avant de commencer l'emmission de son ou pas ?
non, parce que la compression se joue au niveau de petits blocs, avec éventuellement référence aux 2-3 blocs précédents, masi c'est tout. C'est ce qui permet de faire du streaming audio (ou vidéo...) : on n'attend pas d'avoir stocké tout le film pour le lire !!! -- Philippe Manet
Fra <fra@alussinan.org> wrote:
Mais le système doit-il tout décompresser le lossless
avant de commencer l'emmission de son ou pas ?
non, parce que la compression se joue au niveau de petits blocs, avec
éventuellement référence aux 2-3 blocs précédents, masi c'est tout.
C'est ce qui permet de faire du streaming audio (ou vidéo...) : on
n'attend pas d'avoir stocké tout le film pour le lire !!!
--
Philippe Manet
pmanet@invivo.edu
Mais le système doit-il tout décompresser le lossless avant de commencer l'emmission de son ou pas ?
non, parce que la compression se joue au niveau de petits blocs, avec éventuellement référence aux 2-3 blocs précédents, masi c'est tout. C'est ce qui permet de faire du streaming audio (ou vidéo...) : on n'attend pas d'avoir stocké tout le film pour le lire !!! -- Philippe Manet
fra
manet wrote:
Fra wrote:
Mais le système doit-il tout décompresser le lossless avant de commencer l'emmission de son ou pas ?
non, parce que la compression se joue au niveau de petits blocs, avec éventuellement référence aux 2-3 blocs précédents, masi c'est tout. C'est ce qui permet de faire du streaming audio (ou vidéo...) : on n'attend pas d'avoir stocké tout le film pour le lire !!!
ok merci -- Fra
manet <pmanet@invivo.edu> wrote:
Fra <fra@alussinan.org> wrote:
Mais le système doit-il tout décompresser le lossless
avant de commencer l'emmission de son ou pas ?
non, parce que la compression se joue au niveau de petits blocs, avec
éventuellement référence aux 2-3 blocs précédents, masi c'est tout.
C'est ce qui permet de faire du streaming audio (ou vidéo...) : on
n'attend pas d'avoir stocké tout le film pour le lire !!!
Mais le système doit-il tout décompresser le lossless avant de commencer l'emmission de son ou pas ?
non, parce que la compression se joue au niveau de petits blocs, avec éventuellement référence aux 2-3 blocs précédents, masi c'est tout. C'est ce qui permet de faire du streaming audio (ou vidéo...) : on n'attend pas d'avoir stocké tout le film pour le lire !!!
ok merci -- Fra
pmanet
Fra wrote:
Est-ce que la corruption d'un bit peut rendre un fichier non conforme à ce qui est attendu ?
je crois qu'il n'y a pas de correction à proprement parler sur les DD ; il y a un checksum de controle, et s'il est faux, le système relit le secteur ; il y a plusieurs essais possibles (x fixé par le pilote, d'où parfois des DD qui renaclent, c'est mauvais signe). Si c'est correct, le secteur est validé et on passe au suivant, sinon le secteur est annoncé faux et généralement la lecture s'arrete sur une erreur de fichier. Le problème des cheksum est qu'ils puevent etre pris en défaut par 2 erreurs qui se compensent.
En fait, les bits ne sont pas 0 ou 1 ! ce sont des valeurs de champs magnétiques +/- proche d'une valeur seuil, et si la tete a bougé d'une fraction de micron elle n'est plus juste au dessus de la piste ; en relisant ça passe mieux.
Si le pilote du disque dur est bien fait, quand ça se produit trop souvent, il te previent que ton disque n'est pas fiable. -- Philippe Manet
Fra <fra@alussinan.org> wrote:
Est-ce que la corruption d'un
bit peut rendre un fichier non conforme à ce qui est attendu ?
je crois qu'il n'y a pas de correction à proprement parler sur les DD ;
il y a un checksum de controle, et s'il est faux, le système relit le
secteur ; il y a plusieurs essais possibles (x fixé par le pilote, d'où
parfois des DD qui renaclent, c'est mauvais signe). Si c'est correct, le
secteur est validé et on passe au suivant, sinon le secteur est annoncé
faux et généralement la lecture s'arrete sur une erreur de fichier. Le
problème des cheksum est qu'ils puevent etre pris en défaut par 2
erreurs qui se compensent.
En fait, les bits ne sont pas 0 ou 1 ! ce sont des valeurs de champs
magnétiques +/- proche d'une valeur seuil, et si la tete a bougé d'une
fraction de micron elle n'est plus juste au dessus de la piste ; en
relisant ça passe mieux.
Si le pilote du disque dur est bien fait, quand ça se produit trop
souvent, il te previent que ton disque n'est pas fiable.
--
Philippe Manet
pmanet@invivo.edu
Est-ce que la corruption d'un bit peut rendre un fichier non conforme à ce qui est attendu ?
je crois qu'il n'y a pas de correction à proprement parler sur les DD ; il y a un checksum de controle, et s'il est faux, le système relit le secteur ; il y a plusieurs essais possibles (x fixé par le pilote, d'où parfois des DD qui renaclent, c'est mauvais signe). Si c'est correct, le secteur est validé et on passe au suivant, sinon le secteur est annoncé faux et généralement la lecture s'arrete sur une erreur de fichier. Le problème des cheksum est qu'ils puevent etre pris en défaut par 2 erreurs qui se compensent.
En fait, les bits ne sont pas 0 ou 1 ! ce sont des valeurs de champs magnétiques +/- proche d'une valeur seuil, et si la tete a bougé d'une fraction de micron elle n'est plus juste au dessus de la piste ; en relisant ça passe mieux.
Si le pilote du disque dur est bien fait, quand ça se produit trop souvent, il te previent que ton disque n'est pas fiable. -- Philippe Manet
