This is the most recent of several instances I’ve seen in the past several months of this very strange soundtrack damage. I’m attaching a .WAV with just 300 samples. (No need to have it longer.) It is stereo, 48khz, 16-bit, from TV. It sounds rather normal to the ear, but please load it into Audacity and you will see that the right channel is… very different. When I load the 1-2 hour whole file, the right channel LOOKS boosted, but sounds no louder than the left. But when you zoom in close, as will happen when you open this very short file, you can see that every THIRD sample in just the right channel has had added to it a fixed value of about 20,000. It’s a normal stereo content and is mostly of a person speaking (with some normal background noise). I don’t know if this is a glitch in their audio system or is some kind of intentional “bad thing”. If I could estimate (visually) the damage value (around 20,000 but we could compare to both the sample around it AND the corresponding samples in the LEFT channel), I need a utility that would subtract the 20,000 value from every 3rd sample in the left channel.
Anyone, please open the file and look at it. I think you’ll agree with my description. Is there any filter or utility that could undo this damage? The audio plays okay, but I need to do some gain modifications, including compression, and it cannot be done with this damage in place.
And I regret that I need to get this done rather promptly (though I realize I’m asking a lot just to ask ppl to look at this).
I can see one spike in there, that by inference from the surrounding two samples, should equate to zero. That is, the value of that sample is the value that needs to be subtracted from every 3rd sample throughout the right channel. I’m new to Audacity. Is there a way to view the numeric value of a single sample, in decimal preferably?
Perhaps there’s a competent C programmer (or VC++, VIsual C++) who knows the .WAV structure and could write a simple program (batch or GUI) that would accept a source filename, destination filename, a channel choice (left or right), and an offset from the start for when the every-third sample should be modified.
The interference is close enough to 15750Hz to make me wonder if the television scanning process is getting into the sound. That could easily happen if someone still had a glass video monitor running.
We would be able to do better analysis but not on the “tick” sound track you sent us. You can post about 10 seconds of representative stereo work on the forum.
We’re probably not going to find very many C++ developers on call to modify a sometimes broken and sometimes not sound track.
Audacity used to have a graphic mode where you could modify sound samples point at a time. How long is the show?
You happened on the one forum with snappy response times. Most forum responses measure in days or weeks. And that’s only if you have an easy problem. You don’t. You should call the client and find out what would happen if you can’t deliver in good time.
Does the client use stereo? Can you split the track into two, delete the damaged track, duplicate the healthy track and make a new stereo show? Many people might notice it doesn’t sound like it used to, but can’t put their finger on what’s wrong.
The “client” will be happy if I do nothing. They might be a bit irritated as I am that there is not adequate compression. (Important background sounds were not mixed strong enough in the mix. They are there but too soft.) So initially I’ll let it (the video) go out as is. But I am still doing tests to see where it is. It turns out it’s happening on all channels, not just the one in question. I’m checking/rebooting/power cycling several pieces of hardware.
Yes, I thought of mono-only dupping from the left channel. I could compress that. But for now, I’ll let it go as stereo, no gain changing. And no one can hear the effect. As it’s every 3rd sample, that would be 48000 / 3 = 16000 times a second. Not audible to MY old ears.
This story ends well. Found the area of the problem, although not the direct cause. The DVR needed to be cold booted. Now all (2) channels I had tried that were showing the problem, as well as the DVR-recorded show in question, all now have NO 16000 cycle “boost” added. Silly glitch somewhere in the DVR. This fits with the couple times it happened previously. It disappears after the next DVR cold boot. I regret that today I did not try a warm boot. It MAY have been enough. I can now recapture the 5 bad hours.
I suppose we could delete this thread, but maybe it will be helpful (or at least weirdly interesting) to others some time.
Moral of the story: When in doubt, power off everything in sight!
A local buddy thought of doing a notch filter, to which I agreed as a possibility. But then I found the culprit and could re-capture the video (with good audio). You apparently posted before reading my last comment in which I reported the problem solved. But your GIF is helpful anyway, as now I can more easily learn notch filtering in Audacity when I eventually WILL need it.
Thank you, Trebor. It’s true that most cannot here 16000 hz. However, a slight flaw of your notch solution is that any of the content which is at 16000 hz will be lost. I see you set your Q to 50, a very high value, which I assume is meant to (in concept) avoid removing 15999 hz and 16001 hz (for examples). Practically, you’re probably right. But I wish there was a purist way to do this. Maybe I need to bite the bullet and learn how to write a C++ utility that will subtract 16384 from every 3rd sample in the right channel. I think this would do it.
Oh, I’m revisiting this subject now because I discovered some files that I cannot recapture. Bunches of them.
I’m confused. Where did you get the .61? Based on what I can see in the graphic I included, the amount needing subtraction is about (or exactly) 16384, not an integer less than 1. (I don’t grasp enough of your code to interpret it.)
Sample values may be represented as integers (usually 8, 16 or 24 bit) or as floating point numbers (usually 32-bit). When integer formats are used, the numeric values are “normalized” to a range of +/- 1.0. This is why the vertical ruler on the left end of a track shows a range of +/- 1.0.
For floating point formats, the literal range of +/- 1.0 is “valid” audio, in that +/- 1.0 represent “full scale” (0 dB, full track height). 32-bit float also supports values greater than 0 dB, which makes it an extremely useful format when working with sound (if you inadvertently cause the level to exceed 0 dB, then it can be recovered back to the “valid” range without loss.)
A single sample value may be found using the Nyquist Prompt and the command SND-FETCH.
Example for a mono track:
;version 4
(snd-fetch *track*)
The above command fetches the value of the first sample in the selection.
To see the values of the first three sample of the selection, you can use:
Click the “Debug” button to see the three results.
I got the figure of 0.61 by looking at sample values in several places where there was one of the high values, with a low value either side (such as the 3rd, 4th and 5th samples). I then took the average of the outer two “correct” values, and subtracted that from the value of the “too high” sample, so as to derive an approximation of the offset.
Testing a few values this way gave “offset” results in the range of about 0.60 to 0.62.
The code in my previous post can run in the Nyquist Prompt. Try it
