Bit perfect or not?
Voici un petit test effectué simplement :
Un CD en bon état est extrait à l'aide de dbPoweramp puis de iTunes en mode correction d'erreur décoché, puis coché. 2 pistes sont choisies, une pour être au milieu du CD et la seconde à la fin.
Les fichiers résultants sont comparés. Afin de s'assurer que l'on utilise uniquement les modes de recouvrement d'erreur l'accès à AccurateRip est coupé. De ce fait seul le logiciel donne son avis sur la qualité de l'extraction :
dbPowerAmp fait 2 passes puis 3 passes (ultra secure mode) sur les deux pistes. La vitesse moyenne reste à x9
et dure environ 6 minutes :
avec iTunes, sans cocher la correction d'erreur la lecture se fait à vitesse moyenne de x9,5 en environ 1,5 minutes.
avec iTunes, en cochant la correction d'erreur la lecture se fait à vitesse moyenne de x7,8 en environ 2,5 minutes.
Après cette opération nous disposons donc de 2 groupes de 3 fichiers.
L'ensemble est ensuite entièrement converti en fichiers WAV :
Les fichiers résultant doivent en principe être les même au niveau des données audio par groupe s'ils sont tous bit perfect. En complément, j'utilise le logiciel MP3TAG pour supprimer les TAGS avant conversion et comparer dans l'absolu la taille des fichiers. Déjà, celle-ci est différente...
Pour vérifier le contenu, j'ai utilisé une petite application développée sur le pouce et comme je n'ai rien à cacher, voici le source. Le calcul du CRC32 est effectué uniquement sur la partie data pour éviter les variations d'entête qui sont possibles entre itunes et dbPowerAmp (c'est d'ailleurs le cas).
Voici les résultats trouvés :
Les informations d'entête étaient bien identique dans les deux cas,
La taille de la zone de données était bien identique, par contre la méthode d'extraction des deux logiciels n'a pas donné le même résultat car le CRC32 est différent ! Donc le contenu est différent, d'ailleurs en utilisant le fichier VB on détermine qu'environ 27000 octets sont semblables puis après il y a une différence... Pour aller plus finement dans la comparaison il faudrait pouvoir comparer les échantillons 1 à 1 et voir où se trouvent les décalages exactement.
Cette petite démonstration très simple a donc servi à prouver que les soit disant extractions bit perfect d'un logiciel à l'autre donne des résultats sans doute très proche au niveau audition mais que le résultat extrait semble tout de même pouvoir varier. Alors, lequel des 2 est bit perfect? ...
Seconde expérience :
pour en avoir le coeur net, j'active AccurateRip et je retente la même opération avec un CD différent :
La plage est donc valide et en accord avec ce qu'on trouvé 27 autres personnes sur le même disque ...
là encore on constate que le résultat n'est pas identique ...
Comment trancher ?
Pour trancher sur le fait que iTunes délivre ou non un résultat correct, il est souhaitable d'utiliser un tiers et donc EAC me semble tout indiqué. En complément, à la demande d'une autre personne, j'ai ajouté JRiver Media Center à la liste de test et déroulé le même protocole.
Une fois la piste extraite au format WAV pour éviter l'ajout de TAG, aucune erreur n'est détectée, le CRC est 64FB6E88 et la copie déclarée bonne, AccurateRip état correctement détecté. Au passage on remarque que le CRC n'est pas calculé de la même manière que dbPowerAmp...
Un passage par le logiciel VB permet d'éditer les éléments suivants :
Récapitulons :
dbPowerAmp et EAC ont trouvés tout deux la même plage encodée identiquement et composée des mêmes données.
iTunes 9 et JRiver MediaCenter ont trouvé dans les deux cas avec ou sans correction d'erreur rigoureusement les mêmes données à chaque fois et également différents à chaque fois de dbPowerAmp.
Ma conclusion sur le sujet sera donc que iTunes ne semble pas extraire de données correctement à tous les coups et de plus ne détecte pas les gaps ou les corrections C2 comme peut le faire un logiciel plus sophistiqué à ce niveau.
Je vous laisse en tirer vos propres conclusions !
Addendum:
L'environnement de test est constitué de :
- 1 portable (Core 2 Duo/2Go RAM, lecteur/graveur de DVD, disque SATA 3Go/s 320Go)
- 1 PC de bureau (Quad Core 8500, 4 Go RAM, lecteur de CD x52, disque 500Go en RAID 1)
- 1 PC de bureau (Core 2 Duo 2,3GHz, 2 Go RAM, lecteur/graveur de DVD, disque SATA II 400Go)
- Logiciel dbpoweramp R13.1
- Logiciel EAC 0.99 Beta 5
- Logiciel iTunes R9.0.2.25
- Logiciel JRiver Media Center 1.4
Le protocole a été déroulé 3 fois sur chaque plate-forme informatique et les mêmes résultats ont été obtenus.
Un CD en bon état est extrait à l'aide de dbPoweramp puis de iTunes en mode correction d'erreur décoché, puis coché. 2 pistes sont choisies, une pour être au milieu du CD et la seconde à la fin.
Les fichiers résultants sont comparés. Afin de s'assurer que l'on utilise uniquement les modes de recouvrement d'erreur l'accès à AccurateRip est coupé. De ce fait seul le logiciel donne son avis sur la qualité de l'extraction :
dbPowerAmp fait 2 passes puis 3 passes (ultra secure mode) sur les deux pistes. La vitesse moyenne reste à x9
et dure environ 6 minutes :
avec iTunes, sans cocher la correction d'erreur la lecture se fait à vitesse moyenne de x9,5 en environ 1,5 minutes.
avec iTunes, en cochant la correction d'erreur la lecture se fait à vitesse moyenne de x7,8 en environ 2,5 minutes.
Après cette opération nous disposons donc de 2 groupes de 3 fichiers.
L'ensemble est ensuite entièrement converti en fichiers WAV :
Les fichiers résultant doivent en principe être les même au niveau des données audio par groupe s'ils sont tous bit perfect. En complément, j'utilise le logiciel MP3TAG pour supprimer les TAGS avant conversion et comparer dans l'absolu la taille des fichiers. Déjà, celle-ci est différente...
Pour vérifier le contenu, j'ai utilisé une petite application développée sur le pouce et comme je n'ai rien à cacher, voici le source. Le calcul du CRC32 est effectué uniquement sur la partie data pour éviter les variations d'entête qui sont possibles entre itunes et dbPowerAmp (c'est d'ailleurs le cas).
Voici les résultats trouvés :
| plage 6 | Taille | CRC32 |
| dbpoweramp | 50132880 | F4AF967 |
| itunes sans correction | 50132880 | 6B40D7E |
| itunes avec correction | 50132880 | 6B40D7E |
| plage 11 | Taille | CRC32 |
| dbpoweramp | 51250080 | D646DC6D |
| itunes sans correction | 51250080 | 193F10F8 |
| itunes avec correction | 51250080 | 193F10F8 |
Les informations d'entête étaient bien identique dans les deux cas,
| 0 ChunkID: | 4 ChunkSize: | 8 Format: | 12 SubChunk1ID: | 16 SubChunk1Size: | 20 Format: | 22 Channels: | 24 SampleRate: | 28 ByteRate: | 32 BlockAlign: | 34 BitsPerSample: |
| RIFF | 50135014 | WAVE | fmt | 16 | 1 (PCM) | 2 | 44100 | 176400 | 4 | 16 |
La taille de la zone de données était bien identique, par contre la méthode d'extraction des deux logiciels n'a pas donné le même résultat car le CRC32 est différent ! Donc le contenu est différent, d'ailleurs en utilisant le fichier VB on détermine qu'environ 27000 octets sont semblables puis après il y a une différence... Pour aller plus finement dans la comparaison il faudrait pouvoir comparer les échantillons 1 à 1 et voir où se trouvent les décalages exactement.
Cette petite démonstration très simple a donc servi à prouver que les soit disant extractions bit perfect d'un logiciel à l'autre donne des résultats sans doute très proche au niveau audition mais que le résultat extrait semble tout de même pouvoir varier. Alors, lequel des 2 est bit perfect? ...
Seconde expérience :
pour en avoir le coeur net, j'active AccurateRip et je retente la même opération avec un CD différent :
La plage est donc valide et en accord avec ce qu'on trouvé 27 autres personnes sur le même disque ...
| plage 2 | Taille | CRC32 |
| dbpoweramp | 27419616 | 4124C6B |
| itunes sans correction | 27419616 | E2905D11 |
| itunes avec correction | 27419616 | E2905D11 |
là encore on constate que le résultat n'est pas identique ...
Comment trancher ?
Pour trancher sur le fait que iTunes délivre ou non un résultat correct, il est souhaitable d'utiliser un tiers et donc EAC me semble tout indiqué. En complément, à la demande d'une autre personne, j'ai ajouté JRiver Media Center à la liste de test et déroulé le même protocole.
Une fois la piste extraite au format WAV pour éviter l'ajout de TAG, aucune erreur n'est détectée, le CRC est 64FB6E88 et la copie déclarée bonne, AccurateRip état correctement détecté. Au passage on remarque que le CRC n'est pas calculé de la même manière que dbPowerAmp...
Un passage par le logiciel VB permet d'éditer les éléments suivants :
| plage 2 | Taille | CRC32 |
| EAC | 27419616 | 4124C6B |
| plage 2 | Taille | CRC32 |
| JRIVER Media Center | 27419616 | E2905D11 |
Récapitulons :
dbPowerAmp et EAC ont trouvés tout deux la même plage encodée identiquement et composée des mêmes données.
iTunes 9 et JRiver MediaCenter ont trouvé dans les deux cas avec ou sans correction d'erreur rigoureusement les mêmes données à chaque fois et également différents à chaque fois de dbPowerAmp.
Ma conclusion sur le sujet sera donc que iTunes ne semble pas extraire de données correctement à tous les coups et de plus ne détecte pas les gaps ou les corrections C2 comme peut le faire un logiciel plus sophistiqué à ce niveau.
Je vous laisse en tirer vos propres conclusions !
Addendum:
L'environnement de test est constitué de :
- 1 portable (Core 2 Duo/2Go RAM, lecteur/graveur de DVD, disque SATA 3Go/s 320Go)
- 1 PC de bureau (Quad Core 8500, 4 Go RAM, lecteur de CD x52, disque 500Go en RAID 1)
- 1 PC de bureau (Core 2 Duo 2,3GHz, 2 Go RAM, lecteur/graveur de DVD, disque SATA II 400Go)
- Logiciel dbpoweramp R13.1
- Logiciel EAC 0.99 Beta 5
- Logiciel iTunes R9.0.2.25
- Logiciel JRiver Media Center 1.4
Le protocole a été déroulé 3 fois sur chaque plate-forme informatique et les mêmes résultats ont été obtenus.
Vous oubliez une chose : les fichiers WAV ont des en-tetes qui peuvent varier dans que les données (l'onde) ne varient. De plus il y a plusieurs facons de coder les données (la taille des blocs est variable).
RépondreSupprimerBref, sujet intéressant mais méthode inadaptée.
Bonjour,
RépondreSupprimerLes CRC ne sont effectués que sur la zone de données extraite et pas sur les entêtes de définition initiale ...
De plus sur une plage donnée, il n'y a pas plusieurs méthodes de codage à la lecture, ce que vous dite est incohérent ... la taille de bloc est variable à l'encodage mais pas au décodage ! Le préambule fixe le format des données, et doit être décodé tel quel.
Cela dit, l'idée du test n'est simplement que de montrer que l'acquisition numérique est faillible mais que certains logiciels s'en sortent mieux pour "garantir" une image au plus près de l'original.
Effectivement, j'ai lu trop vite, je n'avais pas vu que la comparaison portait uniquement sur le bloc de données. Cependant il faut faire attention sur ces données, la taille de blocs peut varier. Par exemple, rien n’empêche d'avoir une 3ieme piste a vide. Il peut aussi apparaitre des petits 'tic' sur le 1er bit de certaines extractions, ce qui va fausser le CRC.
RépondreSupprimerCe qu'on voit, c'est qu'un logiciel se se contredit jamais, pas même en activant la "correction" ce qui veut dire qu'il n'y a pas d'erreur physique d'extraction, simplement des différences logicielles.
Oui, j'ai constaté cela également, qu'a plusieurs reprises, après plusieurs essais, le résultat était invariant.
RépondreSupprimerLa manière dont l'algorithme traite la reconstruction du bloc de données n'intervient qu'a partir du moment où la correction effectué par le firmware du lecteur a échoué. Du coup il est difficile d'estimer exactement lorsque l'un ou l'autre entre en fonction, les logs ne sont pas réellement explicites. Ce qui compte, c'est je pense que retrouver un même résultat sur plusieurs logiciels sur une même piste, amène à déduire statistiquement que le résultat a de grandes chances d'être correct.
Puis-je suggérer un test supplémentaire ?
RépondreSupprimerJe me demande si c'est la lecture du disque qui est plus ou moins fiable suivant l'appli, ou si chaque appli traite la même information lue différemment.
Je suggère de copier d'abord les pistes du CD au format brut AIFF sur le disque dur, et de comparer alors les sorties d'iTunes, EAC, dbPowerAmp ou autre. Le firmware du lecteur CD n'intervient plus alors puisque toutes les appris ont la "même chose à manger".
Merci d'avance.
Là on ne teste plus l'acquisition mais la restitution et la différence est majeure car chaque lecteur en fonction de son interaction avec l'OS devient un transport avec son jitter et ses erreurs propres...
RépondreSupprimerLe résultat est forcément différent dans l'absolu. Attention le test n'a pour but que de mettre en lumière l'acquisition des données.