Bonjour,
Sur le site Renaissens lors du test de l'Hiface 2 on peut lire:
"... Les fichiers ont été directement stockés en AIFF sur un disque dur externe. Sachez que toute copie vers un autre support, entraîne irrémédiablement un voile ainsi qu'une perte de dynamique à l'écoute. Le choix du format AIFF n'est pas non plus anodin, il constitue à notre avis le meilleur type de fichier audio à l'heure actuelle."
Qu'est ce qu'ils appellent "un autre support"? Les disques durs internes, clé usb, DVD, CD?
Qu'en pensez vous? Avez vous déjà testé?
Merci.
|
33 messages • Accèder à une page • 1, 2, 3
|
Modérateurs: Modération Forum Haute-Fidélité, Le Bureau de l’Association HCFR • Utilisateurs parcourant ce forum: boby6kiler, Enrok, Espresso, gailuron, patmousse, pierrepauljack, ricouxxx, Rubix, sirius57, syber, xano91 et 72 invités
Tout ce qui touche la Haute-Fidélité numérique
jmlfocal a écrit:Bonjour,
Sur le site Renaissens lors du test de l'Hiface 2 on peut lire:
"... Les fichiers ont été directement stockés en AIFF sur un disque dur externe. Sachez que toute copie vers un autre support, entraîne irrémédiablement un voile ainsi qu'une perte de dynamique à l'écoute. Le choix du format AIFF n'est pas non plus anodin, il constitue à notre avis le meilleur type de fichier audio à l'heure actuelle."
Qu'est ce qu'ils appellent "un autre support"? Les disques durs internes, clé usb, DVD, CD?
Qu'en pensez vous? Avez vous déjà testé?
Merci.
qu'un magasin qui propage de telles "conn...ies" est à fuir ...
- j_yves
- Messages: 5871
- Inscription Forum: 18 Oct 2002 14:21
Impressionnant
- alan.dub
- Messages: 3128
- Inscription Forum: 13 Nov 2010 15:51
- Localisation: Malouin en Charente Maritime
Un torchon à bruler
- Gandalflux
- Messages: 46286
- Inscription Forum: 07 Avr 2008 23:03
- Localisation: Luxembourg
+1664.
Pour en avoir le coeur net, tu peux très bien télécharger un logiciel de calcul de CRC (type F-CRC Calculator par exemple). Celà génère un identifiant unique pour un fichier donnée.
1) Tu calcules le CRC pour tonfichier.flac
2) Tu copies tonfichier.flac ailleurs sur ton disque (pour pouvoir garder le même nom)
3) Tu calcules le CRC pour tonfichier.flac d'origine ainsi que la copie et tu verra que les CRC seront identiques à celui calculé en 1) ; la preuve sera faite qu'il n'y a pas de perte lors de la copie, ni sur la source, ni sur la copie.
CQFD
edit : par ailleurs, on est dans le numérique et pas dans l'analogique, s'il y avait eu altération lors de la copie, le fichier serait corrompu et donc serait illisible dans 99.999999999% des cas.
Pour en avoir le coeur net, tu peux très bien télécharger un logiciel de calcul de CRC (type F-CRC Calculator par exemple). Celà génère un identifiant unique pour un fichier donnée.
1) Tu calcules le CRC pour tonfichier.flac
2) Tu copies tonfichier.flac ailleurs sur ton disque (pour pouvoir garder le même nom)
3) Tu calcules le CRC pour tonfichier.flac d'origine ainsi que la copie et tu verra que les CRC seront identiques à celui calculé en 1) ; la preuve sera faite qu'il n'y a pas de perte lors de la copie, ni sur la source, ni sur la copie.
CQFD
edit : par ailleurs, on est dans le numérique et pas dans l'analogique, s'il y avait eu altération lors de la copie, le fichier serait corrompu et donc serait illisible dans 99.999999999% des cas.
- niklos0
- Messages: 1229
- Inscription Forum: 26 Avr 2009 12:15
niklos0 a écrit:edit : par ailleurs, on est dans le numérique et pas dans l'analogique, s'il y avait eu altération lors de la copie, le fichier serait corrompu et donc serait illisible dans 99.999999999% des cas.
Pour ce dernier point, c'est inexact. Un fichier AIFF corrompu reste parfaitement lisible. Les données audio sont juste différentes... sauf si la corruption affecte l'en-tête du fichier, qui ne fait en principe que quelques octets, là où le type de fichier, la quantification, la fréquence d'échantillonnage, le nombre de canaux, la taille du fichier etc, sont inscrits.
Pour le reste, je plussoie.
- Pio2001
- Contributeur HCFR 2019
- Messages: 9089
- Inscription Forum: 07 Oct 2003 12:50
- Localisation: Neuville-sur-Saône
...Je vois ce que tu veux dire : s'il y a corruption du flux numérique, l'erreur est soit corrigée, et le fichier est intact, soit détectée, et le fichier n'est pas transmis.
Bon. Mais est-ce que tu me permets d'enlever quelques 9 à ton pourcentage ?
Il existe en effet un cas où la corruption n'est pas détectée, c'est si elle a lieu dans la RAM (à moins d'avoir de la RAM spéciale, comme sur les serveurs professionnels).
En 15 ans, cela m'est arrivé 3 fois au moins, dont une fois sur un fichier audio (RAM défectueuse, et il n'y a pas que le fichier audio qui a trinqué !) et deux fois dans des playlists. Dans ce dernier cas, la RAM était en parfait état de marche, mais il se trouve que les playlist sont les données qui cumulent le plus long temps de stockage en RAM : à chaque fermeture du lecteur, elle sont copiées depuis la mémoire sur le disque où elles attendent la prochaine ouverture. C'est un peu comme si elles étaient restées 10 000 heures d'affilée en mémoire.
Bon. Mais est-ce que tu me permets d'enlever quelques 9 à ton pourcentage ?
Il existe en effet un cas où la corruption n'est pas détectée, c'est si elle a lieu dans la RAM (à moins d'avoir de la RAM spéciale, comme sur les serveurs professionnels).
En 15 ans, cela m'est arrivé 3 fois au moins, dont une fois sur un fichier audio (RAM défectueuse, et il n'y a pas que le fichier audio qui a trinqué !) et deux fois dans des playlists. Dans ce dernier cas, la RAM était en parfait état de marche, mais il se trouve que les playlist sont les données qui cumulent le plus long temps de stockage en RAM : à chaque fermeture du lecteur, elle sont copiées depuis la mémoire sur le disque où elles attendent la prochaine ouverture. C'est un peu comme si elles étaient restées 10 000 heures d'affilée en mémoire.
- Pio2001
- Contributeur HCFR 2019
- Messages: 9089
- Inscription Forum: 07 Oct 2003 12:50
- Localisation: Neuville-sur-Saône
Pio2001 a écrit:...Je vois ce que tu veux dire : s'il y a corruption du flux numérique, l'erreur est soit corrigée, et le fichier est intact, soit détectée, et le fichier n'est pas transmis.
Bon. Mais est-ce que tu me permets d'enlever quelques 9 à ton pourcentage ?
Je te le permets ! J'ai peut être un peu exagéré ! Mais le principe est là !
- niklos0
- Messages: 1229
- Inscription Forum: 26 Avr 2009 12:15
Je crois qu'il ne faut pas mélanger la partie numérique et analogique. En numérique on est d'accord sur le fait qu'il y a un très très faible pourcentage pour qu'un fichier soit altéré. Heureusement d'ailleurs pour tous nos documents, sites web etc ...
Maintenant comment peut-on affirmer qu'un bruit qui est récupéré (ou généré) dans la partie numérique d'un système (et donc superposé au signal numérique) n'est pas en partie "recopié" sur le signal analogique lors de la conversion ? Comment être sûr qu'il y a un dispositif particulier dans la puce de conversion ou dans le système pour filtrer ce bruit avant conversion ? Pour la puce si on la connait on peut encore se fier aux datasheets mais est ce que les résultats annoncés par le constructeur ne sont pas optimiste ? Est ce que les conditions de mise en oeuvre sont optimales ?
Sur mon Raspberry Pi par exemple le câble réseau est une véritable antenne et toutes les pollutions qu'il récupère sont transmises avec fidélité sur l'alim mais aussi sur le bus DATA de la sortie USB. Si le DAC USB derrière ne filtre pas, je pense qu'il y a une grande chance pour en retrouver une bonne partie sur les sorties analogiques.
De la même façon les lecteurs réseaux sont aujourd'hui de vrais ordinateurs et il est difficile d'être certain que le système d'exploitation et/ou la partie logicielle n'apporte pas elle même des erreurs dans la restitution.
Après je ne saurais pas juger de l'influence que cela peut avoir sur la qualité du son ni de quel gamme de système HIFI et d'oreilles il faut pour s'en rendre compte ... mais sur le principe purement technique ça ne me choque pas plus que ça.
Maintenant comment peut-on affirmer qu'un bruit qui est récupéré (ou généré) dans la partie numérique d'un système (et donc superposé au signal numérique) n'est pas en partie "recopié" sur le signal analogique lors de la conversion ? Comment être sûr qu'il y a un dispositif particulier dans la puce de conversion ou dans le système pour filtrer ce bruit avant conversion ? Pour la puce si on la connait on peut encore se fier aux datasheets mais est ce que les résultats annoncés par le constructeur ne sont pas optimiste ? Est ce que les conditions de mise en oeuvre sont optimales ?
Sur mon Raspberry Pi par exemple le câble réseau est une véritable antenne et toutes les pollutions qu'il récupère sont transmises avec fidélité sur l'alim mais aussi sur le bus DATA de la sortie USB. Si le DAC USB derrière ne filtre pas, je pense qu'il y a une grande chance pour en retrouver une bonne partie sur les sorties analogiques.
De la même façon les lecteurs réseaux sont aujourd'hui de vrais ordinateurs et il est difficile d'être certain que le système d'exploitation et/ou la partie logicielle n'apporte pas elle même des erreurs dans la restitution.
Après je ne saurais pas juger de l'influence que cela peut avoir sur la qualité du son ni de quel gamme de système HIFI et d'oreilles il faut pour s'en rendre compte ... mais sur le principe purement technique ça ne me choque pas plus que ça.
- eaugier
- Messages: 71
- Inscription Forum: 22 Fév 2005 19:06
- Localisation: Alpes de Haute Provence
eaugier a écrit:Maintenant comment peut-on affirmer qu'un bruit qui est récupéré (ou généré) dans la partie numérique d'un système (et donc superposé au signal numérique) n'est pas en partie "recopié" sur le signal analogique lors de la conversion ?
Là n'est pas la question ! On parle de copie numérique vers numérique. L'analogique n'a strictement rien à faire la dedans.
Comme je le disais, pour en avoir le coeur net, il suffit de faire un calcul de CRC sur la source et la copie. Cela permet de se rendre compte de la qualité de la copie. Si les CRC sont identiques, la copie est parfaite et inversement.
- niklos0
- Messages: 1229
- Inscription Forum: 26 Avr 2009 12:15
eaugier a écrit:Sur mon Raspberry Pi par exemple le câble réseau est une véritable antenne et toutes les pollutions qu'il récupère sont transmises avec fidélité sur l'alim mais aussi sur le bus DATA de la sortie USB. Si le DAC USB derrière ne filtre pas, je pense qu'il y a une grande chance pour en retrouver une bonne partie sur les sorties analogiques.
L'usb transporte du courant, il n'y a pas de mystére.
eaugier a écrit:De la même façon les lecteurs réseaux sont aujourd'hui de vrais ordinateurs et il est difficile d'être certain que le système d'exploitation et/ou la partie logicielle n'apporte pas elle même des erreurs dans la restitution.
En dehors des bug de conceptions des softs ou drivers, affirmation qui devra etre étayer par des preuves
- dinococus
- Messages: 3000
- Inscription Forum: 22 Déc 2012 18:31
eaugier a écrit:Sur mon Raspberry Pi par exemple le câble réseau est une véritable antenne et toutes les pollutions qu'il récupère sont transmises avec fidélité sur l'alim mais aussi sur le bus DATA de la sortie USB. Si le DAC USB derrière ne filtre pas, je pense qu'il y a une grande chance pour en retrouver une bonne partie sur les sorties analogiques.
tu t'es aperçu de ça comment?
- j_yves
- Messages: 5871
- Inscription Forum: 18 Oct 2002 14:21
dinococus a écrit:En dehors des bug de conceptions des softs ou drivers, affirmation qui devra etre étayer par des preuves
10 ans d'AC97 n'ont donc pas suffi ?
Resampling, resampling asynchrone, dithering, clipping, altération, voire normalisation du volume, insertion de silences entre les plages... les occasions ne manquent pas d'introduire des altérations dans le flux numérique sans même que l'on parle de bug.
Aujourd'hui encore, sans même parler d'ordinateurs, nombre de lecteurs de Blu-ray ne sont pas capables d'envoyer les données DTS-HD ou Dolby True HD à leurs propres convertisseurs à partir du moment où l'option "audio secondaire" est activée.
- Pio2001
- Contributeur HCFR 2019
- Messages: 9089
- Inscription Forum: 07 Oct 2003 12:50
- Localisation: Neuville-sur-Saône
Pio2001 a écrit:dinococus a écrit:En dehors des bug de conceptions des softs ou drivers, affirmation qui devra etre étayer par des preuves
10 ans d'AC97 n'ont donc pas suffi ?
Resampling, resampling asynchrone, dithering, clipping, altération, voire normalisation du volume, insertion de silences entre les plages... les occasions ne manquent pas d'introduire des altérations dans le flux numérique sans même que l'on parle de bug.
clipping, à part le fichier, connais pas
insertion de silence : du logiciel ? J'ai un DAP dont le soft dit gapless ne l'ai pas. c'est un bug
normalisation du volume : ?
dithering, resampling, asynchrone : il aussi possible de rouler avec une surcharge de 100 %.
et si le dithering n'est pas maitrisé, le développeur devrait changer de métier.
- dinococus
- Messages: 3000
- Inscription Forum: 22 Déc 2012 18:31
|
33 messages
• Page 1 sur 3 • 1, 2, 3
Retourner vers Source dématérialisée et DAC
|