enlever les grésillements avec sound forge 7

Bonne année à toutes et tous !!

Oui, oui j'ai bien suivi le sujet....mais bon, si on enleve
ces fameux grésillements à la source plus besoin de Sound Forge, non ? Et pb résolu !!

 

C'est vrai, pour avoir moins de problemes, revenons au cinéma muet et en noir et blanc !!

 

16bits et 32000Hz

Juste une remarque en passant:

Il est bien exact que les camescopes DV n'ont que deux réglages:
32000Hz ET 12 bits
ou
48000Hz ET 16bits.

Cela dit, une fois transféré sur un ordinateur et encapsulé en AVI, les samples de 12 bits n'existent pas. En fait avec des logiciels d'édition WAV sous Windows on n'a que 8bits, 16 bits, 24bits etc.. mais toujours un mutiple de 8bits=1 octet, pour que chaque sample soit constitué d'un nombre entier d'octets. Je n'ai pas vérifié informatiquement, mais je suppose que cela se fait en complétant le sample par des zéros pour passer au nombre entier d'octets supérieurs.

Quoiqu'il en soit, la conséquence de cela est que si on extrait l'audio d'un avi DV, même s'il a été capturé en 12bits par le camescope, il apparaîtra comme étant du 16 bits sur le micro-ordinateur. Par exemple DVdate considère de ce fait tous les avi DV comme étant du 16 bits et j'explique alors dans son mode d'emploi qu'il faut se fier uniquement à la fréquence 48000 ou 32000 pour savoir comment a été capturé la vidéo par le camescope.

Donc c'est tout à fait normal si sur le micro de realziz les fichiers avi DV paraissent être du 16 bits.

 

digicheck

je ne suis vraiment pas très compétent sur les finesses du son numérique, aussi je fais surtout des hypothèses, et ne demande qu'à être corrigé.

1) le programme digicheck est - notamment -un outil d'analyse pour tester les flux des cartes audio RME DIGI96® Series, qui sont des cartes qui font de la conversion numérique/analogique en 24 bits mais qui ajoutent aussi des bits supplémentaires PCUV aux samples pour former des samples de 32 bits dont certains non utilisés.

2)Le panneau bit statistics teste un flux audio dans la carte audio et indique quels bits sont utilisés: c'est une sorte de vu-mètre. Le fait qu'il comporte des graduations à 4,8,16 etc... ne signifie pas qu'il travaille spécialement sur des samples à 4,8,16 etc... puisqu'il travaille en fait en interne toujours sur du 32 bits (dont 24 +3 utiles).

Et surtout cela ne signifie pas qu'il crée des fichiers WAV sous windows avec autre chose qu'un multiple de 8bits/sample.


Ici la zone verte montre que le flux est en 16 bits, mais si je comprends bien qu'il utilise en fait aussi un 17ème bit qui est le bit V (validity).

3) En tous cas les spécifications de l'avi sous windows imposent un nombre entier d'octets pour la valeur dwBitspersample qui figure dans l'en-tête du fichier avi, quitte à mettre 0 quand cette valeur est variable comme dans certains formats audio compressés, mais pas en PCM.

4)Bien entendu, les dispositifs physiques qui convertissent le signal sonore en des 0 et 1 travaillent en ce qu'ils veulent, et notamment 12 bits dans le camescope. Mais effectivement une fois encapsulé en avi il me semble que c'est obligatoirement 8, 16 ou 24 (peut-être un jour 32) dès lors que le flux audio est en PCM non compressé, ce qui est le cas dans les vidéos DV.

 

fichier wav de 20 bits

Je ne demande qu'à être convaincu, mais je reste un peu dubitatif. Il n'y a pas de doute qu'un dispositif peut travailler en 20 bits. mais une fois qu'il crée un WAV sous Windows (je ne sais pas si c'est pareil sous Mac), ne va-t-il pas compléter les samples par des bits nuls? On aurait alors tous les deux raison: 20 bits utiles, mais 24 bits occupés dans le fichier.

Si tu as un tel fichier sous la main, ce serait intéressant d'analyser physiquement la taille des samples.

En première approche (si on considère comme négligeable la taille du header, petite devant le grand nombre de samples) on a à peu près:

[longueur du fichier WAVen octets]x8=[ longueur d'un sample en bits]x[frequence]x[duree en secondes]x[nb de canaux (stéréo compté pour 2)].

Par exemple j'ai un fichier de 6.300.342 octets qui est en 44100Hz, durée 35sec et 2canaux, j'obtiens l'approximation

longueur d'un sample=(6300342x8)/(44100x35x2)=16,3 octets, proche de 16 bits.

Avec cette équation tu dois pouvoir déterminer la [longueur du sample], et avoir (à peu près) soit 24 si c'est en 24 bits, ou 20 si c'est en 20 bits.

 

20bits

Personne n'aurait donc un fichier wav en PCM 12 ou 20 bits pour qu'on puisse le tester avec cette équation?

Peut-être tout simplement que cela n'existe donc pas...