Il ne faudrait pas confondre copie de CD/données, transmission de données, et lecture de CD/données, c'est pas la même chose... chers théoriciens... et souvent la finalité.
Le numérique est solide dans sa reproduction/transmission/copie NON TEMPORALISÉE EN DÉBIT, non contrainte en débit. (les bugs de débits c'est commun, ça existe !)
Les redondances des données, la redondance des protocoles, les corrections d'erreurs/manques et les divers contrôles, permettent de copier et transmettre la plupart du temps sans erreurs/manques... SAUF SI... perturbations, dysfonctionnements, incompatibilités, protocoles non équivalents en données/non conservateurs des données d'origine... ce qui fait déjà beaucoup de contraintes à tenir.
Dans le meilleur des mondes du numérique, on idéalise trop souvent la conversion numérique (de protocoles) qui n'est pas toujours conservatrice des données d'origine DÉJÀ.
De plus, ces données de copie/transmission ont une horloge propre d'origine, de "tempo" de ces données, qui doit être conservée ou reconduite ou reconstruite presque à chaque transition de protocoles, ce qui est prévu (et corrigé) par les protocoles numériques... SAUF SI... IDEM perturbations et protocole non conservateur de l'horloge d'origine, ce qui est bien plus souvent le cas, avec des horloges et synchronismes propriétaires (interne machine ou protocole)... d'où l'existence de master clock en petit circuit fermé.
Pour la transmission à distance, si l'horloge n'est pas conservée et transmisse, la précision des horloges actuelles (de "reconstruction/retempolarisation") permet SOI-DISANT de ne pas faire apparaitre de différence (dans certains domaines dont l'audio).
On peut dire DÉJÀ pour la copie/transmission que l'horloge d'origine est peu souvent conservée (remplacée plusieurs fois) et donc remplacée/redéfinie par le protocole ou encapsuleur final (avec sa propre horloge propriétaire).
Maintenant la différence avec la lecture est qu'elle est soumise TOUJOURS à des contraintes de débits (ce qui peut être le cas aussi de la copie et transmission suivant les protocoles, le débit de traitement des pupuces).
Dans la lecture, on a moins de temps pour la correction et le contrôle, de même pour la mise en mémoire des données à resynchroniser, reconfigurer ou à livrer... rapidement.
Une contrainte forte sur les protocoles qui doivent reconduire ou traiter un grand nombre de données (dont des données de redondances, de corrections, de livraisons) ce qui est aussi prévu SOI-DISANT par la rapidité de traitement et d'échange des protocoles, entre protocoles.
Ça en fait des contraintes, des attentions, des immunités... des équivalences de données, d'horloges, de débits... à tenir pour du "parfait/identique" souhaité ou idéalisé.
Et toujours des problèmes de jitter, de latence, de débit... difficilement contournable... et pas absent de la lecture (et souvent de la transmission) numérique ni de sa théorie !!!
Quand à sa conversion ENSUITE dans une autre domaine (tempéré pour nous l'audio analogique) celle-ci et son résultat ne seraient-ils pas soumis/dépendants/tributaires tout autant au protocole/contrainte/forme finale (choisis ou reconstruits) à convertir qu'aux données qu'il contient... hein DÉJÀ JA !!!
Ah là là toutes ces transitions, toutes ces contraintes, tous ces protocoles transparents et pupuces aveugles à tout faire, toutes ces temps-péte de binaire... c'est si facile la brasse dans la baie peu profonde, farpétement... heureusement que ça marchotte... SOIT-DISANT, SAUF, DÉJÀ.
Et pour ceux qui font de la manip numérique (pour soit-DISANT se croire "coller" à l'original "respecté"... quelle blague), c'est plus du "parfait/identitique", vous colorez, coloriez (avec une trousse bien pleine) en numérique
push
Le numérique est solide dans sa reproduction/transmission/copie NON TEMPORALISÉE EN DÉBIT, non contrainte en débit. (les bugs de débits c'est commun, ça existe !)
Les redondances des données, la redondance des protocoles, les corrections d'erreurs/manques et les divers contrôles, permettent de copier et transmettre la plupart du temps sans erreurs/manques... SAUF SI... perturbations, dysfonctionnements, incompatibilités, protocoles non équivalents en données/non conservateurs des données d'origine... ce qui fait déjà beaucoup de contraintes à tenir.
Dans le meilleur des mondes du numérique, on idéalise trop souvent la conversion numérique (de protocoles) qui n'est pas toujours conservatrice des données d'origine DÉJÀ.
De plus, ces données de copie/transmission ont une horloge propre d'origine, de "tempo" de ces données, qui doit être conservée ou reconduite ou reconstruite presque à chaque transition de protocoles, ce qui est prévu (et corrigé) par les protocoles numériques... SAUF SI... IDEM perturbations et protocole non conservateur de l'horloge d'origine, ce qui est bien plus souvent le cas, avec des horloges et synchronismes propriétaires (interne machine ou protocole)... d'où l'existence de master clock en petit circuit fermé.
Pour la transmission à distance, si l'horloge n'est pas conservée et transmisse, la précision des horloges actuelles (de "reconstruction/retempolarisation") permet SOI-DISANT de ne pas faire apparaitre de différence (dans certains domaines dont l'audio).
On peut dire DÉJÀ pour la copie/transmission que l'horloge d'origine est peu souvent conservée (remplacée plusieurs fois) et donc remplacée/redéfinie par le protocole ou encapsuleur final (avec sa propre horloge propriétaire).
Maintenant la différence avec la lecture est qu'elle est soumise TOUJOURS à des contraintes de débits (ce qui peut être le cas aussi de la copie et transmission suivant les protocoles, le débit de traitement des pupuces).
Dans la lecture, on a moins de temps pour la correction et le contrôle, de même pour la mise en mémoire des données à resynchroniser, reconfigurer ou à livrer... rapidement.
Une contrainte forte sur les protocoles qui doivent reconduire ou traiter un grand nombre de données (dont des données de redondances, de corrections, de livraisons) ce qui est aussi prévu SOI-DISANT par la rapidité de traitement et d'échange des protocoles, entre protocoles.
Ça en fait des contraintes, des attentions, des immunités... des équivalences de données, d'horloges, de débits... à tenir pour du "parfait/identique" souhaité ou idéalisé.
Et toujours des problèmes de jitter, de latence, de débit... difficilement contournable... et pas absent de la lecture (et souvent de la transmission) numérique ni de sa théorie !!!
Quand à sa conversion ENSUITE dans une autre domaine (tempéré pour nous l'audio analogique) celle-ci et son résultat ne seraient-ils pas soumis/dépendants/tributaires tout autant au protocole/contrainte/forme finale (choisis ou reconstruits) à convertir qu'aux données qu'il contient... hein DÉJÀ JA !!!
Ah là là toutes ces transitions, toutes ces contraintes, tous ces protocoles transparents et pupuces aveugles à tout faire, toutes ces temps-péte de binaire... c'est si facile la brasse dans la baie peu profonde, farpétement... heureusement que ça marchotte... SOIT-DISANT, SAUF, DÉJÀ.
Et pour ceux qui font de la manip numérique (pour soit-DISANT se croire "coller" à l'original "respecté"... quelle blague), c'est plus du "parfait/identitique", vous colorez, coloriez (avec une trousse bien pleine) en numérique
push