Corrupted wav file during a copy

[bpn2001]

Hi, I just had a problem with a .wav file when I was "backuping" a sd card on my laptop. The usb connector of the sd card reader just disconnect during the copy, and after that, I was able to recover all my files, but one of them was corrupted. Probably the one that was copying when the cable disconnected. As a result, that wav file comes with an added group of continuous frequencies, like a complex hum upon 1kHz that affect also voices. Do you think your app can resolve that issue? Thanks by advance for your response All the best, Manuel

(I don't know anything about "coding" and when I download your "mac" version, I don't know how to use it.)

[agfline]

Hi,

I don't think wavfix can do much about it. It is able to recover the file structure around actual audio data (when audio players wont play the wav file at all) but it's impossible to recover lost or corrupted audio samples, if it is really what happened here.

If you want, you can send me your file so I have a look at it, but there is not much hope I'm sorry.

Good luck, Adrien

[bpn2001]

Hi Adrien, I just sent you the file via wetransfer.

It’s a quite long file, and it’s a polyfile with 5 tracks.

The problem occurs around 19’32''… until the end.

Thanks a lot for your response and your time

All the best, Manuel

Le 25 mai 2023 à 11:44, Adrien Gesta-Fline @.***> a écrit :

Hi,

I don't think wavfix can do much about it. It is able to recover the file structure around actual audio data (when audio players wont play the wav file at all) but it's impossible to recover lost or corrupted audio samples, if it is really what happened here.

If you want, you can send me your file so I have a look at it, but there is not much hope I'm sorry.

Good luck, Adrien

— Reply to this email directly, view it on GitHub https://github.com/agfline/wavfix/issues/11#issuecomment-1562604688, or unsubscribe https://github.com/notifications/unsubscribe-auth/BACRVUOAVHQJCBL66NSWR7DXH4SWZANCNFSM6AAAAAAYN4HJ4A. You are receiving this because you authored the thread.

[bpn2001]

HI, here’s the link to download the file :

https://we.tl/t-4Hee71vNTY https://we.tl/t-4Hee71vNTY

Thanks! Manuel

Le 25 mai 2023 à 11:44, Adrien Gesta-Fline @.***> a écrit :

Hi,

I don't think wavfix can do much about it. It is able to recover the file structure around actual audio data (when audio players wont play the wav file at all) but it's impossible to recover lost or corrupted audio samples, if it is really what happened here.

If you want, you can send me your file so I have a look at it, but there is not much hope I'm sorry.

Good luck, Adrien

— Reply to this email directly, view it on GitHub https://github.com/agfline/wavfix/issues/11#issuecomment-1562604688, or unsubscribe https://github.com/notifications/unsubscribe-auth/BACRVUOAVHQJCBL66NSWR7DXH4SWZANCNFSM6AAAAAAYN4HJ4A. You are receiving this because you authored the thread.

[agfline]

Hi, just had a look at your file.

Well first, your file structure is completely sane so wavfix is useless here.

I highly doubt this audio issue is due to a bad copy. It sounds much more like some kind of buffer underrun. I also noticed the BWF description field reports Fichier corrompu à 3'45 de la fin..signal numerique (yes, I'm french too). Was it set on the SoundDevices 664 on the field ?

So anyway. Looking closer with Audacity I saw clear sample drops :

The same view at sample level :

As it seems to occur on a regular basis of 32 samples, I wrote a small prog to rewrite this (almost) zero-value sample each 32 samples. It works fine for a few milliseconds then it fails. Not that regular I guess... Probably one could go deeper and look for a way to detect and correct those drops, however I really have no time for it I'm sorry.

So you have two options now :

• First you can redraw those samples manually in an editor which would take forever (or might take half forever if you keep only a very small part of the noisy ITW...)
• Or you can give iZotope RX (or anything of the sort) a try.

Hope you'll recover your file,

Adrien

[bpn2001]

Merci Adrien pour ta réponse.. je bascule en français..:) Qu’est ce que tu appelles un « buffer underrun »? Non je n’ai rien écrit sur le fichier pour le BWF reports… étrange… Le signal initial, lors de l’enregistrement, n’était pas corrompu. Mais en essayant de récupérer les fichier de la carte SD via un logiciel de récupération de données, le fichier est devenu tel que je te l’ai envoyé. Je soupçonne ce logiciel d’avoir modifier le contenu pendant la récupération de données, à cause sans doute d’un mauvaise interprétation de quelques bits (corrompus sans doute?)… Mais je n’en sais pas plus…. Merci en tout cas pour ton aide. Manuel

Le 1 juin 2023 à 00:35, Adrien Gesta-Fline @.***> a écrit :

Hi, just had a look at your file.

Well first, your file structure is completely sane so wavfix is useless here.

I highly doubt this audio issue is due to a bad copy. It sounds much more like some kind of buffer underrun. I also noticed the BWF description field reports Fichier corrompu à 3'45 de la fin..signal numerique (yes, I'm french too). Was it set on the SoundDevices 664 on the field ?

So anyway. Looking closer with Audacity I saw clear sample drops : https://user-images.githubusercontent.com/25045526/242423039-e352e09a-8af1-44e5-b927-198e340aea5e.png The same view at sample level : https://user-images.githubusercontent.com/25045526/242423035-c5d52782-a6e1-4cbb-9681-38768210234c.png As it seems to occur on regular basis of 32 samples, I wrote a small prog to rewrite this (almost) zero-value sample each 32 samples. It works fine for a few milliseconds then it fails. Not that regular I guess... Probably one could go deeper and look for a way to detect and correct those drops, however I really have no time for it I'm sorry.

So you have two options now :

First you can redraw those samples manually in an editor which would take forever (or might take half forever if you keep only a very small part of the noisy ITW...) Or you can give iZotope RX (or anything of the sort) a try. Hope you'll recover your file,

Adrien

— Reply to this email directly, view it on GitHub https://github.com/agfline/wavfix/issues/11#issuecomment-1571051773, or unsubscribe https://github.com/notifications/unsubscribe-auth/BACRVUIFD2IZZ26QUYTS7BTXI7BU7ANCNFSM6AAAAAAYN4HJ4A. You are receiving this because you authored the thread.

[agfline]

En gros, un buffer c'est un espace mémoire dans lequel on va écrire et lire des groupes d'échantillons audio. Parfois, l'instance qui écrit et celle qui lit sont distinctes l'une de l'autre et ont besoin d'être synchronisées. L'underrun c'est quand tu écris moins vite que tu ne lis les échantillons, du coup il y a des « trous », c'est à dire des échantillons qui manquent. J'ai eu un problème similaire sur un projet de rétro-ingénérie de driver audio (l'audio était dégradé de façon identique) et c'était du à un problème de synchro entre mon driver et l'interface audio.

Bref, dans ton cas, s'il était question de données corrompues je me serais attendu à une présence d'échantillons audio chaotiques prenant des valeurs aléatoires, or ce n'est pas ce que l'on observe sur la waveform. Mais je ne fais que des suppositions et un problème lors de la récupération de tes fichiers reste bien-sur tout à fait possible. D'ailleurs je bosse avec du SoundDevices depuis des années (552, 633, 833) et je n'ai rencontré de problèmes qu'avec une vieille 552 et ils étaient très différents. C'est d'ailleurs suite à ça que j'ai fait ce programme.

Quand tu dis que le signal initial était propre, tu parles de l'écoute au casque lors de l'enregistrement en sortie de mixette ou d'une écoute en lecture du fichier enregistré ?

Par rapport aux métadonnées voilà ce que j'ai dans le champ description :

sSPEED=025.000-ND
sTAKE=04
sUBITS=$00000000
sSWVER=4.61.05
sSCENE=CRAW-LAKE
sFILENAME=CRAW-LAKET04.WAV
sTAPE=23Y05M05
sCIRCLED=FALSE
sNOTE=Fond Ventilation.. Fichier corrompu à 3'45 de la fin..signal numerique
sTRK1=MixL
sTRK2=MixR
sTRK5=BOOM

Je n'ai pas check l'iXML.

Adrien

[bpn2001]

Un grand m erci pour tes réponses détaillées!En effet, c'est l'ecoute au casque pdt la prise qui était propre, ainsi que le son témoin issu de la 664 que j'envoyais sur la cam. ( ce qui a sauvé une partie de ma prise d'ailleurs..:)) via la piste aux X1.Mais tout ça était "pré-rec" trés probablement, et je n'ai jamais pu réécouter la prise après enregistrement avant mon pb.Bref, si c'est un pb d'underrun, penses-tu que ça vient de la carte sd ou bien de la 664?Merci!ManuEnvoyé de mon iPhoneLe 2 juin 2023 à 01:33, Adrien Gesta-Fline @.***> a écrit : En gros, un buffer c'est un espace mémoire dans lequel on va écrire et lire des groupes d'échantillons audio. Parfois, l'instance qui écrit et celle qui lit sont distinctes l'une de l'autre et ont besoin d'être synchronisées. L'underrun c'est quand tu écris moins vite que tu ne lis les échantillons, du coup il y a des « trous », c'est à dire des échantillons qui manquent. J'ai eu un problème similaire sur un projet de rétro-ingénérie de driver audio (l'audio était dégradé de façon identique) et c'était du à un problème de synchro entre mon driver et l'interface audio. Bref, dans ton cas, s'il était question de données corrompues je me serais attendu à une présence d'échantillons audio chaotiques prenant des valeurs aléatoires, or ce n'est pas ce que l'on observe sur la waveform. Mais je ne fais que des suppositions et un problème lors de la récupération de tes fichiers reste bien-sur tout à fait possible. D'ailleurs je bosse avec du SoundDevices depuis des années (552, 633, 833) et je n'ai rencontré de problèmes qu'avec une vieille 552 et ils étaient très différents. C'est d'ailleurs suite à ça que j'ai fait ce programme. Quand tu dis que le signal initial était propre, tu parles de l'écoute au casque lors de l'enregistrement en sortie de mixette ou d'une écoute en lecture du fichier enregistré ? Par rapport aux métadonnées voilà ce que j'ai dans le champ description : sSPEED=025.000-ND sTAKE=04 sUBITS=$00000000 sSWVER=4.61.05 sSCENE=CRAW-LAKE sFILENAME=CRAW-LAKET04.WAV sTAPE=23Y05M05 sCIRCLED=FALSE sNOTE=Fond Ventilation.. Fichier corrompu à 3'45 de la fin..signal numerique sTRK1=MixL sTRK2=MixR sTRK5=BOOM

Je n'ai pas check l'iXML. Adrien

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>