Bitrate or Sample Rate mismatch

I recorded a Chuck Berry Tribute show at Blueberry Hill in St. Louis, MO, on May 4th, 2022 using a Midas M32 connected via USB to my Windows laptop running Adobe Audition.

This was a 13-track multi-track recording at 48K and 16 bits.

When I playback the recorded audio tracks, I hear a digital warbling sound on top of the recorded audio. Would anyone happen to know of a way to repair this audio? It’s some wav encoding issue; bitrate, sample rate, uLaw vs. (some other)Law. I used to be much more familiar with these issues over a decade ago, but I’m hoping somewhere here might have special current knowledge.

This is a link to one of the damaged files: [248 MB]

Please, if anyone can at least identify the issue, that would help.


The problem is “dropouts” (see region marked with label in image below).
Parts of the waveform are missing (flat line), which was probably due to the recorder being unable to keep up with the amount of data per second during recording. It is probably unrepairable. :frowning:


I’m not so sure there isn’t something else going on here. Of every 512 samples (exactly?), a string of 32 samples (exactly?) seem to be zero’d. Furthermore, the samples immediately prior to and after the zero’d samples seem to be extremely close, so is is likely there is not actually any missing data.

I suspect a Nyquist program that throws out every identically zero sample (or similar) could possibly rescue this recording. :smiley: But alas, that is beyond my Nyquist capabilities. :frowning:

:frowning: I also don’t think there’s much hope… :frowning:

The “warble” makes me think you’re missing more than the 32-samples and that makes the problem “worse”.

Otherwise there is the Audacity Repair Effect, or there applications made for removing clicks & pops from vinyl recordings that can replace a short-bit of bad audio with audio constructed from the nearby audio. But, those vinyl repair tools probably won’t recognize a short-bit of silence as a “defect”, so you’d have to find all of the defects manually (Audacity’s Repair is also manual) and that’s just too many defects to fix manually. And it wouldn’t be “perfect” anyway.

There’s always a risk when there’s no chance for “take-2”, especially with computers which are the least reliable things we own… And, you often don’t know there was a problem until you get home the next day… (In the analog days we could monitor from the tape machine’s playback head a fraction of a second after recording. But I never saw a multi-track recorder in person.)

For “critical recording” I usually recommend running a 2nd recorder in parallel as a back-up, but I’m pretty sure you don’t have a multitrack back-up so the backup would probably have to be 2-channel stereo. And with a rock band in a small or medium venue, a good stereo recording usually requires a separate mixer. (If you are in a large venue where ALL of the sound the audience is hearing goes through the PA system the main mixer’s output is fine… Not multitrack, but better than a glitchy multitrack… And you don’t have to spend time with post-production mixing!)

There is a free online book about optimizing your computer for audio called [u]Glitch Free[/u]. And of course the setup has to be debugged, tested, and proven-out before the “big day”.

I continue to disagree. :smiley: If you study the audio carefully you will see that there are no discontinuities, thus no missing audio. Just 32 extra zeros stuck in every 500 or so samples.

It still sounds garbled to me. Here’s a short extract where I have done exactly that:

(This is the code - mono only, and short selections only or it will probably crash Audacity)

(setf ln (truncate len))
(setf in (snd-fetch-array *track* ln ln))
(setf out (make-array ln))

(setf j 0)
(dotimes (i ln)
  (when (/= (aref in i) 0)
    (setf (aref out j) (aref in i))
    (incf j)))

(do ((i j (1+ i)))
    ((>= i ln) (snd-from-array 0 *sound-srate* out))
  (setf (aref out i) 0))

Steve, you did well! That seems to have removed 99% of the glitches! :smiley:

but sadly not well enough as there’s still around 4 glitches per second, and this is apparently just one of 13 tracks.

I suspect that the appearance of being (almost) periodic may be to do with the size of a buffer.