2009-11-12 10 views
0

J'ai une situation où il y a un fichier WAV corrompu à partir duquel j'essaie de récupérer des données. Mes collègues ont découpé le grand fichier WAV en plus petits fichiers WAV avec des en-têtes appropriés. Cela a produit des résultats intéressants.Récupération de données de fichier WAV

coupées en tranches 1MB nous obtenons ces résultats:

  • Le premier segment de fichier wave est tout le bruit.
  • Le segment de fichier de deuxième vague est déformé.
  • Le segment de fichier de troisième vague est clair.

Ce motif est répété sur toute la longueur du fichier (après qu'il a été divisé en fichiers plus petits).

Pour les tranches de 20MB:

  • Le premier segment de fichier wave est tout le bruit.
  • Le segment de fichier de deuxième vague est clair.
  • Le segment de fichier de troisième vague est déformé.

Encore une fois, ce modèle est répété pour toute la longueur du fichier (après qu'il a été divisé en fichiers plus petits).

Quelqu'un sait-il pourquoi cela se produit?

Répondre

2

En supposant que le WAV contient des échantillons non compressés (bruts), la récupération devrait être facile. Vous devez connaître le format de l'échantillon. Par exemple: 16 bits, deux canaux, 44100 Hz (qui est de qualité CD). Parce que l'un des segments est correct, vous pouvez regarder cela pour déterminer quelles sont les bonnes valeurs. Ensuite, il suffit d'ouvrir le WAV en utilisant ces valeurs dans, par exemple, Adobe Audition (anciennement Cool Edit), ou tout autre éditeur d'ondes prenant en charge l'importation de données brutes.

Modifier: Bon, maintenant, pour répondre à votre question. Certains segments sont clairs, car l'alignement est correct. Reprenez la qualité du CD, comme je l'ai déjà décrit. Les octets d'un échantillon ressembler à ceci:

left_channel_high | left_channel_low | right_channel_high | right_channel_low 

(!. Je ne suis pas sûr de la commande ici, mais il est juste un exemple) Ainsi, le premier octet de données vaut mieux être l'octet le plus significatif du canal gauche , ou bien vous vous retrouverez avec des fragments de deux échantillons étant interprétés comme un ensemble de l'échantillon:

left_channel_low | right_channel_high | right_channel_low || left_channel_high 
-------------------part of first sample------------------ || --second sample-- 

vous pouvez voir que tout « déplacé » ici, ce qui arrive parce que la taille de vos tranches de fichiers est pas un multiple de la taille de l'échantillon en octets.

Si vous êtes chanceux, cela provoque simplement l'échange des canaux. Si vous êtes malchanceux, les octets hauts et bas sont échangés. Il est intéressant de noter que cela conduit à un son de type reconnaissable mais gravement déformé.

Ce qui me laisse perplexe, c'est que le motif que vous signalez se répète en blocs de trois. D'après ce qui précède, je m'attendrais à deux ou quatre. Peut-être utilisez-vous un format d'échantillon inhabituel, tel que 24 bits (3 octets)?

+0

Je vais essayer. nous ne sommes pas sûrs à 100% si le format de l'échantillon b/c les données d'en-tête initial est corrompu. il y a donc un travail de conjecture impliqué ici. –

+0

Encore une fois, si vous pouvez obtenir un son clair sur l'une des tranches, cela doit être le bon format d'échantillon. – Thomas

+0

j'ai eu plus de détails de mes corworkers. alors voici le format d'échantillonnage: 96000 Hz fréquence d'échantillonnage 1 canal 24 bits –

Questions connexes