Bonjour à tous,
De temps en temps j'aime me faire une petite compil sur CDR de mes meilleurs morceaux de CD.
J'utilisais donc Vuplayer pour faire l'extraction et Nero 8 pour graver sur un CDR, avec des CD vièrges Verbatim.
Le soucis c'est que l'autre jour j'ai été chez un ami avec ma compil et sur un morceau il a tiqué, il a aussitot mis le même mais en original et effectivement il y avait une différence (trés grande pour lui et légère pour moi), son électronique est plutot haut de gamme.
J'ai donc rééssayer grace à l'original de refaire une extraction avec Vuplayer pour la 1ere fois et Exact audio copy pour la seconde, puis grace MD5 Cheksum j'ai vérifié le résultat des 2 extractions, ils étaient strictement identique.
Donc je pense que le soucis ne vient pas de l'extractio, à moins d'essayer avec un autre lecteur/graveur de DVD...
Puis j'ai gravé le morceau extrait (qui est donc identique à l'original) avec Néro la 1ere fois puis Exact audio copy la 2ème, j'ai refait ensuite des extractions avec Vuplay pour comparer à nouveau le checksum de l'original et la copie.
Les 2 morceaux gravés individuellement ont un checksum different de l'original...
Y a t il donc un moyen d'avoir une copie proche de l'original, informatiquement parlant ?
Est ce le CDR lui même qui serait en cause ?
PS : il y a des tas d'options dans les logiciels de gravure, comme le rajout des 2 secondes de blanc, qui pourraient expliquer la différence de checksum.
|
12 messages • Page 1 sur 1
|
Modérateurs: Modération Forum Haute-Fidélité, Le Bureau de l’Association HCFR • Utilisateurs parcourant ce forum: cyril.edge, cyril13, decro, Espresso, Goshasei, invictus, lolo05, Nalex05, Prouprou, rod93, sirius57, vindermere et 90 invités
Tout ce qui touche la Haute-Fidélité numérique
Copier un CD audio sur un CDR à l identique ?
- Razmote
- Messages: 4206
- Inscription Forum: 19 Mar 2003 16:52
- Localisation: Dans le Sud, aux pieds de la Bonne Mère !
Bonjour Razmote,
Passons en revue les sources de différences :
Je ne te ferai pas l'affront de citer la compression en mp3 ou autre format lossy.
En format lossless (wav), il y a deux souces de différences majeures : la détection des gaps et leur traitement, et la normalisation.
La détection des gaps est une procédure assez obscure, dont l'utilité est suffisamment proche du néant pour qu'on puisse la confondre avec ce dernier. Le résultat de cette opération, qui précède l'extraction, est une liste de positions situées une à trois secondes en amont de chaque début de plage, et censée, selon une convention plus ou moins respectée, indiquer où se trouve le début de l'espace entre les deux plages. EAC, en particulier, propose, une fois ces positions déterminées, de rattacher ces gaps aux plages précédentes, aux plages suivantes, ou des les supprimer.
Seule l'option consistant à les rattacher aux plages précédentes permet une copie conforme. C'est d'ailleurs ce qu'il se passe lorsqu'on ne les détecte pas.
La normalisation consiste à modifier le volume sonore d'une plage pour le maximiser. Cette option est à proscrire.
Si on veut changer le volume sonore, pour harmoniser une compilation comme tu le fais, autant choisir soi-même le niveau.
Enfin, du côté de la gravure, une grande partie des logiciels, dont Nero, insère stupidement deux secondes supplémentaires de blanc entre les plages. Certains le font même lorsqu'on choisit explicitement de ne pas le faire ! C'est là aussi à proscrire absolument. Le silence entre les plages doit être inclus à la fin de chacune, et conservé tel quel. Ou alors, comme pour le niveau, il est à ajuster manuellement pour que les plages se suivent harmonieusement dans une compilation.
Une fois ces sources de différences éliminées, tu as encore une source de différences systématique assez difficile à gérer, mais sans incidence sur la qualité sonore, qui est l'offset. Il s'agit d'un décalage dans le temps d'environ un centième de seconde. Souvent, c'est la copie qui est en retard par rapport à l'original. Cela vaut mieux que l'inverse, mais parfois, la copie est légèrement en avance. C'est lié aux mécaniques, qui, pour des raisons aussi indéfendables que farouchement enracinées, ne sont pas d'accord entre elles pour définir où commence chaque plage exactement.
Les graveurs munis de mécaniques Plextor (attention, certains modèles Plextor utilisent des mécaniques Pioneer) sont capables de lire et de graver sans aucun décalage d'offset(*).
L'ensemble des logiciels utilisant AccurateRip (en option dans EAC), une fois configurés, lisent l'audio avec un offset conventionnel, toujours le même, permettant à AccurateRip de comparer les checksum d'un lecteur à l'autre. Ils réalisent pour cela une compensation adaptée à chaque mécanique. EAC est aussi capable de graver en compensant le décalage d'offset. Là aussi, il faut le configurer.
Ceci dit, EAC dispose d'un comparateur de wavs qui détecte l'offset et indique si, en dehors de celui-ci, les données sont identiques entre deux fichiers. Tu devrais l'utiliser pour comparer tes fichiers. Il t'indiquera probablement quelques missing ou repeated samples aux deux etrémités, et rien d'autre, preuve que les wavs sont identiques, mais décalés dans le temps.
Ce décalage conduit à la perte complète de quelques données au début de la toute première plage, ou à la fin de la toute dernière plage, selon la direction du décalage. Ces données peuvent être récupérées par EAC si le lecteur accepte l'option d'overread into lead-in (lecture avant le début de la première plage), ou d'overread into lead-out (lecture après la fin de la dernière plage). Il ne suffit pas qu'ils acceptent la commande, d'ailleurs, encore faut-il qu'ils le fassent réellement, et ne se contentent pas d'insérer des zéro pour faire croire que, comme certains.
Pour les graveurs, c'est beaucoup plus compliqué.
Dans une approche brute, il n'existe qu'un seul logiciel permettant de graver "en dehors des plages" pour inclure les données perdues au-delà de ce que le graveur croît être le début ou la fin du CD. C'est EAC, et il n'accepte de le faire qu'avec un seul modèle de graveur. Un Teac 4x des années 1990.
Toutefois, s'il s'agit de graver avant la première page, cela ne devrait pas être trop difficile à condition que celle-ci ait un pré-gap de plus de 2.00 secondes. Seules les deux premières secondes sont considérées "hors zone" (leur numéro de secteur est négatif). Par contre, il doit falloir utiliser un ensemble wav+cue pour y parvenir, afin de pouvoir fournir au logiciel des données qui sont "avant la première plage".
Enfin, les mécaniques Plextor citées plus haut n'ont, en principe pas besoin d'overread ou d'overwrite, puisqu'elle n'ont pas d'offset... sauf que l'offset utilisé en pratique pour AccurateRip et EAC n'est pas le même que celui utilisé par Plextor ! En théorie, c'est Plextor qui a raison (le premier octet du fichier wav est placé en tête du premier bloc du premier secteur). Mais le fait qu'on ne soit pas calé sur la référence d'AccurateRip n'est pas gênant pour une duplication de CD, en dehors du fait qu'AccurateRip ne fonctionnera pas lors de l'extraction, car AccurateRip ignore le début de la plage 1 et la fin de la dernière, pour éviter justement d'avoir des checksum différentes sur les lecteurs qui ne font pas d'overread. Donc en lisant et en réécrivant sans correction d'offset avec une mécanique Plextor, on obtient une copie officiellement conforme des données audio, et les 30 échantillons que l'on rate en raison de l'offset choisi par EAC et AccurateRip ne sont pas pris en compte dans les checksums AccurateRip.
(*) "Décalage d'offset", c'est rigolo, comme expression, ça ! C'est comme si je disais "le numéro number one" !
Passons en revue les sources de différences :
Je ne te ferai pas l'affront de citer la compression en mp3 ou autre format lossy.
En format lossless (wav), il y a deux souces de différences majeures : la détection des gaps et leur traitement, et la normalisation.
La détection des gaps est une procédure assez obscure, dont l'utilité est suffisamment proche du néant pour qu'on puisse la confondre avec ce dernier. Le résultat de cette opération, qui précède l'extraction, est une liste de positions situées une à trois secondes en amont de chaque début de plage, et censée, selon une convention plus ou moins respectée, indiquer où se trouve le début de l'espace entre les deux plages. EAC, en particulier, propose, une fois ces positions déterminées, de rattacher ces gaps aux plages précédentes, aux plages suivantes, ou des les supprimer.
Seule l'option consistant à les rattacher aux plages précédentes permet une copie conforme. C'est d'ailleurs ce qu'il se passe lorsqu'on ne les détecte pas.
La normalisation consiste à modifier le volume sonore d'une plage pour le maximiser. Cette option est à proscrire.
Si on veut changer le volume sonore, pour harmoniser une compilation comme tu le fais, autant choisir soi-même le niveau.
Enfin, du côté de la gravure, une grande partie des logiciels, dont Nero, insère stupidement deux secondes supplémentaires de blanc entre les plages. Certains le font même lorsqu'on choisit explicitement de ne pas le faire ! C'est là aussi à proscrire absolument. Le silence entre les plages doit être inclus à la fin de chacune, et conservé tel quel. Ou alors, comme pour le niveau, il est à ajuster manuellement pour que les plages se suivent harmonieusement dans une compilation.
Une fois ces sources de différences éliminées, tu as encore une source de différences systématique assez difficile à gérer, mais sans incidence sur la qualité sonore, qui est l'offset. Il s'agit d'un décalage dans le temps d'environ un centième de seconde. Souvent, c'est la copie qui est en retard par rapport à l'original. Cela vaut mieux que l'inverse, mais parfois, la copie est légèrement en avance. C'est lié aux mécaniques, qui, pour des raisons aussi indéfendables que farouchement enracinées, ne sont pas d'accord entre elles pour définir où commence chaque plage exactement.
Les graveurs munis de mécaniques Plextor (attention, certains modèles Plextor utilisent des mécaniques Pioneer) sont capables de lire et de graver sans aucun décalage d'offset(*).
L'ensemble des logiciels utilisant AccurateRip (en option dans EAC), une fois configurés, lisent l'audio avec un offset conventionnel, toujours le même, permettant à AccurateRip de comparer les checksum d'un lecteur à l'autre. Ils réalisent pour cela une compensation adaptée à chaque mécanique. EAC est aussi capable de graver en compensant le décalage d'offset. Là aussi, il faut le configurer.
Ceci dit, EAC dispose d'un comparateur de wavs qui détecte l'offset et indique si, en dehors de celui-ci, les données sont identiques entre deux fichiers. Tu devrais l'utiliser pour comparer tes fichiers. Il t'indiquera probablement quelques missing ou repeated samples aux deux etrémités, et rien d'autre, preuve que les wavs sont identiques, mais décalés dans le temps.
Ce décalage conduit à la perte complète de quelques données au début de la toute première plage, ou à la fin de la toute dernière plage, selon la direction du décalage. Ces données peuvent être récupérées par EAC si le lecteur accepte l'option d'overread into lead-in (lecture avant le début de la première plage), ou d'overread into lead-out (lecture après la fin de la dernière plage). Il ne suffit pas qu'ils acceptent la commande, d'ailleurs, encore faut-il qu'ils le fassent réellement, et ne se contentent pas d'insérer des zéro pour faire croire que, comme certains.
Pour les graveurs, c'est beaucoup plus compliqué.
Dans une approche brute, il n'existe qu'un seul logiciel permettant de graver "en dehors des plages" pour inclure les données perdues au-delà de ce que le graveur croît être le début ou la fin du CD. C'est EAC, et il n'accepte de le faire qu'avec un seul modèle de graveur. Un Teac 4x des années 1990.
Toutefois, s'il s'agit de graver avant la première page, cela ne devrait pas être trop difficile à condition que celle-ci ait un pré-gap de plus de 2.00 secondes. Seules les deux premières secondes sont considérées "hors zone" (leur numéro de secteur est négatif). Par contre, il doit falloir utiliser un ensemble wav+cue pour y parvenir, afin de pouvoir fournir au logiciel des données qui sont "avant la première plage".
Enfin, les mécaniques Plextor citées plus haut n'ont, en principe pas besoin d'overread ou d'overwrite, puisqu'elle n'ont pas d'offset... sauf que l'offset utilisé en pratique pour AccurateRip et EAC n'est pas le même que celui utilisé par Plextor ! En théorie, c'est Plextor qui a raison (le premier octet du fichier wav est placé en tête du premier bloc du premier secteur). Mais le fait qu'on ne soit pas calé sur la référence d'AccurateRip n'est pas gênant pour une duplication de CD, en dehors du fait qu'AccurateRip ne fonctionnera pas lors de l'extraction, car AccurateRip ignore le début de la plage 1 et la fin de la dernière, pour éviter justement d'avoir des checksum différentes sur les lecteurs qui ne font pas d'overread. Donc en lisant et en réécrivant sans correction d'offset avec une mécanique Plextor, on obtient une copie officiellement conforme des données audio, et les 30 échantillons que l'on rate en raison de l'offset choisi par EAC et AccurateRip ne sont pas pris en compte dans les checksums AccurateRip.
(*) "Décalage d'offset", c'est rigolo, comme expression, ça ! C'est comme si je disais "le numéro number one" !
- Pio2001
- Contributeur HCFR 2019
- Messages: 9143
- Inscription Forum: 07 Oct 2003 12:50
- Localisation: Neuville-sur-Saône
Pio, les logiciels type CloneCD permettent-ils de copies conformes de CD audio?
- khaos974
- Messages: 1596
- Inscription Forum: 20 Mar 2006 20:46
Bonjour Pio2001,
Je viens de lire ta réponse et wawwwwww impressionnant...
Bien sur j'avais oublié de dire que l'extraction ne concernait que des fichiers wav bien sur...
En résumé, il faut donc un bon graveur (Plextor) et un bon logiciel de lecture/gravue (EAC), vu la complexité de celui ci, existe t il un beau tuto pour savoir quoi paramètrer en lecteur et en écriture, pour avoir une copie de qualité ?
Tout ceci est partie d'un simple constat chez un ami qui a une installation hifi hyper pointu, sue la mienne et étant plus modeste, suis pas sur de l'entendre.
Merci et a+
Je viens de lire ta réponse et wawwwwww impressionnant...
Bien sur j'avais oublié de dire que l'extraction ne concernait que des fichiers wav bien sur...
En résumé, il faut donc un bon graveur (Plextor) et un bon logiciel de lecture/gravue (EAC), vu la complexité de celui ci, existe t il un beau tuto pour savoir quoi paramètrer en lecteur et en écriture, pour avoir une copie de qualité ?
Tout ceci est partie d'un simple constat chez un ami qui a une installation hifi hyper pointu, sue la mienne et étant plus modeste, suis pas sur de l'entendre.
Merci et a+
- Razmote
- Messages: 4206
- Inscription Forum: 19 Mar 2003 16:52
- Localisation: Dans le Sud, aux pieds de la Bonne Mère !
Razmote a écrit:Bonjour Pio2001,
Je viens de lire ta réponse et wawwwwww impressionnant...
+1
- le touriste
- Messages: 8858
- Inscription Forum: 31 Juil 2005 13:13
- Localisation: rp 77
Oui le touriste, ce post mériterait de figurer en post it sur le forum...
Si un modo passe par la
Si un modo passe par la
- Razmote
- Messages: 4206
- Inscription Forum: 19 Mar 2003 16:52
- Localisation: Dans le Sud, aux pieds de la Bonne Mère !
khaos974 a écrit:Pio, les logiciels type CloneCD permettent-ils de copies conformes de CD audio?
Bonjour khaos974,
CloneCD ne propose qu'une fonction très basique de duplication de CD audio. Elle a le mérite de ne pas trafiquer les gaps, mais elle ne gère pas les offsets, et surtout, ne gère pas les erreurs. Elle est équivalente au "burst mode" d'EAC.
CloneCD a eu son heure de gloire grâce à une fonction permettant de pirater une certaine protection placée sur les CD-ROMs de jeux vidéo, et qu'il était impossible de copier à l'aide d'un logiciel standard.
- Pio2001
- Contributeur HCFR 2019
- Messages: 9143
- Inscription Forum: 07 Oct 2003 12:50
- Localisation: Neuville-sur-Saône
Pio2001 a écrit:khaos974 a écrit:Pio, les logiciels type CloneCD permettent-ils de copies conformes de CD audio?
Bonjour khaos974,
CloneCD ne propose qu'une fonction très basique de duplication de CD audio. Elle a le mérite de ne pas trafiquer les gaps, mais elle ne gère pas les offsets, et surtout, ne gère pas les erreurs. Elle est équivalente au "burst mode" d'EAC.
CloneCD a eu son heure de gloire grâce à une fonction permettant de pirater une certaine protection placée sur les CD-ROMs de jeux vidéo, et qu'il était impossible de copier à l'aide d'un logiciel standard.
Ok, merci.
- khaos974
- Messages: 1596
- Inscription Forum: 20 Mar 2006 20:46
Razmote a écrit:En résumé, il faut donc un bon graveur (Plextor) et un bon logiciel de lecture/gravue (EAC), vu la complexité de celui ci, existe t il un beau tuto pour savoir quoi paramètrer en lecteur et en écriture, pour avoir une copie de qualité ?
Tout ceci est partie d'un simple constat chez un ami qui a une installation hifi hyper pointu, sue la mienne et étant plus modeste, suis pas sur de l'entendre.
Bonjour Razmote,
Les explications que j'ai données indiquent pourquoi tu n'as pas obtenu des checksum rigoureusement identiques lorsque tu as comparé la copie à l'original. La solution à employer pour contourner ce problème peut être d'utiliser le comparateur de wavs d'EAC pour vérifier les copies. Ou alors de gérer les offsets, les overread et les overwrite, ce qui peut se révéler assez complexe si on veut pousser la duplication conforme jusqu'au bout.
Par contre, cela n'explique pas la différence audible, car gaps et offsets n'ont aucun effet sur l'intégrité du flux audio en cours de lecture.
L'effet audible d'une mauvaise gestion des gaps est trivial : les espaces entre les plages disparaissent, deviennent trop long, ou, plus subtil, ne font pas exactement la même durée que sur l'original (cas où les originaux ont été supprimés par le logiciel d'extraction, puis remplacés par le logiciel de gravure), avec en prime un possible clic sonore à l'endroit exact où les données ont été mal recollées. Mais cela n'a pas d'effet à l'intérieur des plages musicales.
L'offset n'a en principe pas d'effet audible en soi. Le lecteur semble mettre un centième de seconde de plus à démarrer la lecture avec la copie qu'avec l'original. Exceptionnellement, lors du démarrage, il serait possible dans des cas extrêmes, que l'attaque de la première note soit loupée par le lecteur lors d'un changement de plage ou lors du démarrage du CD (cas où la copie est très en retard sur l'original). Mais une fois la lecture lancée, elle doit se dérouler à l'identique sur l'original et sur la copie.
Les sources de problèmes sonore lors de la lecture sont différentes.
La principale est bien sûr la qualité de lecture. Sur les CD pressés en usine, il est très rare que des erreurs de lecture se produisent. D'après mon expérience, lorsque les lecteurs sont en fin de vie, ils ont tendance à sauter brusquement d'un passage à un autre.
Mais sur des CD gravés, tout peut arriver. Il n'est pas rare que le lecteur n'arrive pas à déchiffrer correctement les données, et que la copie souffre d'une sorte de bruit qui vient par dessus la musique. Il n'est pas forcément évident, car son intensité est proportionnelle à celle du signal. Il est faible quand la musique est faible, fort quand la musique est forte.
J'ai préparé deux fichiers wav illustrant ce bruit, mais il me faudrait d'abord l'avis du staff juridique sur la possibilité de les poster. Ce sont des extraits musicaux d'une dizaine de secondes enregistrés sur des radios FM, directement sur CD, puis relus bien plus tard alors que les CD en question étaient quasiment illisibles.
Pour s'assurer qu'un lecteur donné lise parfaitement une copie, il n'y a pas 36 solutions. Ils faut capter le sortie S/Pdif du lecteur et l'enregistrer sur ordinateur dans un fichier wav. Puis couper ce fichier wav afin qu'il démarre et s'arrête exactement au mêmes endroits que le fichier original ayant servi à la gravure. On peut alors comparer ces fichiers pour s'assurer qu'ils sont identiques.
Le plus délicat n'est pas forcément d'ajuster le début et la fin, mais de s'assurer que l'enregistrement se fait au bit près. Pour cela, il ne faut pas que le lecteur modifie le signal, par exemple à l'aide d'un réglage de volume intégré. Plus difficile, il faut que l'ordinateur enregistre le signal numérique issu du lecteur de salon sans le modifier. Il ne faut donc aucun réglage de volume sur le trajet du signal (contrôle de volume Windows, par exemple, ou activation du mix avec une autre entrée, comme l'entrée ligne). Pour cela, il faut des drivers audio particuliers, comme l'ASIO ou le Kernel Streaming. Certaines cartes son proposent des drivers dit "MME" qui remplissent également cette fonction.
Et il faut s'assurer que le logiciel qui enregistre le fichier wav fait d'une part une acquisition pure au format 44.1 kHz 16 bits, et d'autre part qu'il n'applique aucun dithering lors de l'enregistrement du fichier.
En amont, il aura bien entendu fallu s'assurer que l'original qui a servi à faire la copie a bien été rippé sans erreur. Des logiciels comme EAC ou DBPowerAmp s'acquittent très bien de cette tâche. De ton côté, tu as fait deux rips successifs et obtenu un résultat identique, ce qui prouve que tu n'as eu aucune erreur en lecture, car il est extrêmement rare qu'une erreur de lecture se produise deux fois au même endroit.
Il existe une cause d'erreur assez ennuyeuse quand on réalise l'extraction d'un CD, c'est si le lecteur utilisé a un défaut de conception. On a ainsi pu voir un lecteur CD-ROM Teac décaler des minutes entières d'audio d'une fraction de seconde infime, avec un déclic audible au premier décalage et à le resynchronisation. On connaît le cas d'un lecteur Toshiba qui produisait une erreur isolée lors de l'extraction audio au même endroit quel que soit le CD. Certains Samsung produisaient d'horribles petits silences au début des plages. Ce genre d'erreurs n'est pas détectée par EAC, car elles sont constantes d'une lecture à l'autre, mais AccurateRip n'est pas dupe. En comparant la checksum avec celle d'un autre utilisateur qui, on peut l'espérer, n'a pas le même modèle de lecteur, il ne valide pas les données. Cela n'est d'ailleurs pas d'une grande aide, car lorsqu'AccurateRip ne valide pas, cela ne prouve pas que la copie est mauvaise.
Pour détecter ce genre de problème, il faut faire comme tu as fait : comparer le rip d'une copie à celui d'un original. Si le lecteur est défectueux, la copie apparaîtra différente.
En fait, théoriquement, AccurateRip, après un intervalle de plusieurs semaines, pourrait valider un tel rip : si tu as un lecteur défectueux et que tu as quelques semaines plus tôt soumis toi-même le rip défectueux dans la base de donnée AccurateRip ! Il sera reconnu comme identique, et donc validé.
Une fois toutes ces précautions prises, si la prise S/Pdif du lecteur de salon sort une réplique du fichier wav au bit près lorsqu'il lit la copie, c'est qu'on est techniquement au point.
Les différences audibles sont dès lors à chercher du côté audiophile, qui, comme on le sait, est un véritable puits sans fond, avec ses palets presseurs pour CD, brosses antistatiques à CD, coups de feutres verts sur la tranche, cryogénisation de CD etc.
- Pio2001
- Contributeur HCFR 2019
- Messages: 9143
- Inscription Forum: 07 Oct 2003 12:50
- Localisation: Neuville-sur-Saône
Merci Pio2001 de nous faire part de toute ta connaissance en la matière...
Mais juste pour info tu es ingénieur du son ou un truc du genre ?
Je pense effectivement que les ripps que je fais sont comme à l identique, je vais donc voir du coté de la gravure pour avoir le meilleur rendu possible.
Pour info cet ami a, en effet un appareil qui "supprime" les bulles dans les CD ou un truc du genre, si c'est ce qui fait la différence c'est rudement efficace, mais encore une fois sur un système trés haut de gamme, car j'ai récup son CD et je dois dire que je ne suis pas capable de dire ou est la copie et ou est l originale chez moi.
Encore merci pour tes explications.
Mais juste pour info tu es ingénieur du son ou un truc du genre ?
Je pense effectivement que les ripps que je fais sont comme à l identique, je vais donc voir du coté de la gravure pour avoir le meilleur rendu possible.
Pour info cet ami a, en effet un appareil qui "supprime" les bulles dans les CD ou un truc du genre, si c'est ce qui fait la différence c'est rudement efficace, mais encore une fois sur un système trés haut de gamme, car j'ai récup son CD et je dois dire que je ne suis pas capable de dire ou est la copie et ou est l originale chez moi.
Encore merci pour tes explications.
- Razmote
- Messages: 4206
- Inscription Forum: 19 Mar 2003 16:52
- Localisation: Dans le Sud, aux pieds de la Bonne Mère !
Razmote a écrit:Mais juste pour info tu es ingénieur du son ou un truc du genre ?
Non, rien à voir. En la matière, je pense que "nerd" serait plus approprié : je suis du genre à lire le Red Book pour le plaisir
- Pio2001
- Contributeur HCFR 2019
- Messages: 9143
- Inscription Forum: 07 Oct 2003 12:50
- Localisation: Neuville-sur-Saône
Le lire est une chose, le comprendre et l'expliquer une autre continues à pratiquer ton plaisir...
Merci en tout cas pour tes explications
Merci en tout cas pour tes explications
- Razmote
- Messages: 4206
- Inscription Forum: 19 Mar 2003 16:52
- Localisation: Dans le Sud, aux pieds de la Bonne Mère !
|
12 messages
• Page 1 sur 1
Retourner vers Source dématérialisée et DAC |