I’m transcribing old reel-to-reel audio tapes from the 60’s, recording them as WAV files on a ZOOM H1 digital recorder, then editing them on audacity.
On one transcription yesterday I got a loud crackling sound that my son, who has experience with other editing software, identified as clipping. So I retranscribed the tape at a lower recording level and the noise went away.
So then I thought – If there’s clipping, it must mean that the waveform reached the limit that can be represented digitally. It should be easy to have a computer program read the recorded file and test whether the waveform ever gets near the limit, so I can tell whether there is likely to have been clipping without me having to listen intensely to the whole thing.
Then I thought – Doesn’t Audacity already read the whole file and show me local-peak intensity in a graph? So go look at the file with Audacity and discover that the intensity in nicely centred about zero, and never even goes near plus or minus 0.5. In fact, it looks as if it maxes out at about 0.25. There are no vertical red lines at all, and yes, I did remember to click on View->Show Clipping. And yes, it was the file with clipping noise I viewed. The file without clipping noise has much smaller peaks, staying within plus-or-minus 0.1 on the Audacity graph. And yes, I’m looking at the dark blue part of the graph, not the light blue part.
I’m using Audacity 2.0.3 as installed from the Debian jessie package.
What is likely to be going on here?
When does clipping really occur?
If the limits aren’t plus or minus 1.0 on the waveform graph, what are they?
Clipping can occur anywhere along the signal chain.
The “signal chain” is the path from the original sound through to the final recording.
If you try recording a Saturn V rocket taking off with a normal microphone, the microphone will be overloaded and no matter how low you turn down the recording volume the recording will be distorted. The same can occur at any part of the signal chain. It is essential for a good recording that the signal level is within the capability of the equipment at every stage of the recording.
I have a Zoom H2 and it is terrific, except that the recording volume control is misleading, The H2 has a 3 position Hi,Medium,Low recording level switch. It also has an Up/Down digital recording level control. The switch is great - if the sound is loud, set it to low sensitivity - if the sound is quiet set it to high sensitivity. The digital recording level is useless - it just scales the recorded signal. Setting the digital recording level low does not prevent clipping, it just makes clipped audio quieter because the clipping has occurred before the signal got to the digital recording level control. (Does that make sense?)
Yes, that makes sense. It hadn’t occurred to me that a device as good as the Zoom H1 would have such a misleading recording level indicator or an input level control that operates only after the A-to-D stage.
It doesn’t quite match my experience that the clipping disappeared when I turned down the input level control on the H1. But maybe I misremember and did something else at the same time. I’ll have to experiment to test your very plausible theory.
Assuming you are correct, and I suspect you are, I’d have to adjust the input level at the source, in this case on my reel-to-reel tape player. Which I can do.
So my next step is to use trial and error to set the digital recording level on the H1 so the clipping occurs just when the digital level indicator indicates it might. Then I’ll have the feedback I need to set the output level of the tape recorder.
It does go against the convention of setting the analog output levels high and the input levels low so that any hum picked up en route will be attenuated at the destination.
I’ve got the H2. The H1 may be different. The H2 has a low/mid/high switch which works on the analogue stage. I normally leave the digital level control set at 100 and just use the switch to control the input level (aiming for too low rather than too high), then use the Amplify effect in Audacity if necessary. The Amplify effect essentially does the same as using the digital level control, but safely.
As above, clipping at 0.5 is a signpost that you are recording high level sound on a microphone level connection. This happens to computer soundcards all the time. Newer Windows laptops are missing the High Level input prompting people to try and use Mic-In. Bad move, normally. They get what you have.
My H4 has provision for switching between different levels and inputs. Consult your instructions.
I examined carefully the file I had recorded with the input level set very low, and it too exhibits clipping. It’s not as noticeable, because the volume of everything is very low, making it about as hard to hear as the music.
Attenuating the analog signal outside the H1 does help. I set the H1’s input level to 100, and reduced the volume on my tape deck so as to get the input level display into the -6 to -12 range, and there was no audible clipping. The background hum was loud, though.
It looks as if you are right that the so-called “input level” switches, which the manual says are used to set recording level, do indeed affect the waveform after the A-to-D conversion, and therefore have no effect on clipping.
There’s no documentation about line vs mike input, except the label by the socket on the H1 bearing a picture of a mike, a slash, and the words “LINE IN”. Nothing about it in the manual. I’ve been wondering how it can tell the difference. Maybe some kind of impedance measurement? Or maybe not at all?
The device’s specs are to do 16-bit sampling, I believe. Audacity tells me 32-bit floating-point. I’m assuming this means that samples are recorded in the file as 32-bit floating-point, there is ample room to have 16-bit precision even after the so-called “input level” setting reduces everything be a factor of a hundred. But of course the H1 could botch this arithmetic, too. Still, assuming I’m deaf enough not to hear the difference between 10-but and 16-bit audio, things could work even if I’m wrong on this. I might be able to tell the difference by looking at the WAV file bit by bitter bit.
So I should set the analog level externally to the highest level that avoids clipping, then set the “input level” low enough to get the resulting audio into a reasonable range. That’s probably my best chance to reduce hum. Aside from getting better-shielded cables, of course.
When I opened a stereo WAV file in Audacity, to the left of the intensity graphs it said “stereo, 44100Hz 32-bit float”
Does that mean that the samples in the file are recorded as 32-bit floating-point numbers? And does that mean that they can be out of normal range without being clipped? (assuming the signal that was stored as 32-bit float wasn’t already preclipped, of course.)
I’m wondering, because I’ve actually played one such file through audacity without hearing any clipping artifacts, even though audacity was showing a lot of red vertical bars on the graph.
Of course, converting this to another format might clip it, not my concern at the moment, though.
By default Audacity converts WAV files to 32 bit float on import. It does not mean that the file was 32 bit before it was imported.
Yes 32 bit float can go beyond 0 dB.
The red “Clipping” lines indicate that the waveform reaches 0 dB or more. If the waveform “just touches” 0 dB it may show a red line which indicates that it is at the absolute maximum for “valid” audio signals.
And that’s why. You don’t get clipping in the intermediate stages of audio processing within Audacity.
Can I coax Audacity to tell me what format the actual file is recorded in? Or do I have to look through the bits with a file format spec in hand?
Can I get Audacity to save in floating-point?
The red “Clipping” lines indicate that the waveform reaches 0 dB or more. If the waveform “just touches” 0 dB it may show a red line which indicates that it is at the absolute maximum for “valid” audio signals.
Which indicates whether clipping might occur on export. Useful.
Yes, though there are a couple of effects that don’t take advantage of this. The Wha-wha effect and the Phaser effect both clip at 0 dB, but hopefully this will be fixed before the next Audacity release.
No, Audacity does not do that, but there are several applications that can. On Linux you can probably get that information by right clicking on the file and selecting “properties”, then open the “Audio” tab. (should work with Nautilus file browser). For more information about the file, try “MediaInfo” - it will probably be in the repositories for most Linux distributions (all Debian based distributions should have mediainfo and mediainfo-gui).
We’ve been discussing this recently on the forum - Audacity “Saves” Audacity projects (a .AUP file and a _data folder). By default Audacity projects use 32 bit float. A “Saved” Audacity project contains all of the information to exactly reproduce the Audacity project -but there are some “gotcha’s”.
The “Undo History” is not saved.
If the project contains imported files, there may be “dependencies”: See here for a full explanation: Audacity Manual
I presume that you are asking about “rendering a project to create a standard audio file”? We call this “Exporting” (File menu > Export).
Not all audio formats support 32 bit float, but .WAV format certainly does and is a good choice for exporting in 32 bit float. In the Export dialogue screen, select “Other uncompressed files” as the file type, then click on the “Options” button. You can then select “WAV (Microsoft)” as the header and “32 bit float” as the encoding.
More info here: Audacity Manual
Yes, “Might” is an important word - the red lines don’t mean that the audio “IS” clipped, but it is warning that it “might” be clipped - if they occur when you are recording then the audio probably is clipped. Commercial recordings are frequently compressed and normalised as loud as possible, so will often show clip indicators even though they are not actually clipped (just dangerously close to clipping). See here for why this is a common occurrence: Loudness war - Wikipedia
Some time ago I’ve written a snippet to determine the bit depth of a fresh imported file. I’ll give you Steve’s re-formatted version
;;; mix to mono if stereo
(defun mono (sig)
(if (arrayp sig)
(sim (aref sig 0) (aref sig 1))
sig))
;;; test against powers of 2
(defun bit-test (sig bits)
(peak
(integrate
(diff sig
(quantize sig (truncate (power 2 bits))))) 200000))
;;; find the bit depth
(defun bit-depth (sig)
(let ((sig (mono sig))
(test-values '(10 11 20 23 29 31)))
(dolist (bits test-values)
(if (= (bit-test sig bits) 0)
(return bits)))))
;; run the test
(case (bit-depth s)
(10 "8 bit unsigned")
(11 "12-bit")
(20 "16-bit integer")
(23 "24 bit integer")
(29 "30 bit compressed (mp3 etc.)")
(31 "32-bit integer")
(t "32 bit float"))
If you use it often, we can put a plug-in header before the code and it can then be used as an analyse plug-in (instead of copying it to the Nyquist prompt).
The Mic-In / Line-In thing is not just that one is bigger than the other. Mic-In has a very special Microphone Preamplifier that boosts the microphone signal before the volume control can get to it. That little amplifier is what’s actually overloading and why you can’t stop it.
Why on earth would you want that? Because volume controls add noise and you want to make the microphone performance as loud as possible with the least amount of noise. Normally, this is pretty safe because microphone signals have all the robust, rock-crushing power of a butterfly. So boosting is OK. Not so if you’re working with a much stronger signal from a mixer or other serious audio equipment. That’s not butterflies any more and you are probably smashing the little microphone preamplifier black and blue.
It’s also possible the amplifier is expecting a balanced audio connection typical of grown-up microphones.
Three wires, not two (some mixers use a 1/4" plug for this.) The show signal, the show protection signal and ground or shield. If you wire that wrong, the show protection signal is missing and that’s what prevents the hum and buzz you have.
I think the Mic/Line label is a little optimistic. People have been trying to make one connection do both for years. Hasn’t worked yet. It can work if there is provision for changing the electronics via a switch – or in some cases via a software change.
The instructions have nothing to say about the level you apply to the connection or type of connection expected which does surprise me. It’s like the design of the audio input was left up to the Zoom weekend night guy. There are ways to precondition a high level signal to make it appear like a microphone, but those tend to be noisy and not very well behaved.
