I’m working with headphones currently. When I record using s.makeGUI the resulting recorded mix is slightly different than the monitor. Maybe my input levels are too hot but the result is that the bass frequencies sound expanded and drown out or compress the other sounds. Is this just a hot signal?
Is this just a hot signal?
Possibly? We’d need a bit more info. Are you working with very crunchy (distorted) sounds? Because there is built in clipping on sc’s monitor outputs and I think that may not also be applied to the file written to by Server.record.
Assuming that your ears work alright, you’d probably notice the clipping on the monitors unless you were already working with distortion.
The clipping thing is, I think, also OS-dependent? What you could do is clip the output to 1.26 (i.e., out = out.clip2(1.26) and see if the recording you get from that now matches what you get from the monitors.
Thanks. Monitor clipping is a good bet. Not because I can hear any clipping but just the fact that I’m making bass heavy sounds with headphones. I was sort of expecting to play it on different speakers and be horrified anyway but just the difference in the audio file and the monitor is throwing me off. In that case it’s just a matter of turning down the individual amps.
Also I’m running SC windows 10. I will try the clip out, thank!
Still with clipping, the monitor output and the recorded output ought to be the same unless there is something un-ordinary about how s.record works (never had reason to believe there is). You could try comparing a recorded with s.record file to one recorded directly to a daw using blackhole (if you are on osx) or something similar which can route audio from SC to a DAW. What happens if you do a very basic sound example like { SinOsc.ar(220) * 0.2 ! 2 }.play and record that? Also, when you look at the output meters, can you visually see clipping? Is the meter color consistently red when you play you sounds (it would be for very loud signals and this would result in clipping). If the meter is mostly green and yellow you should be ok.
monitor output and the recorded output ought to be the same
You might be right, and that sounds more reasonable. My comment above was based on a session where some filters were blowing up and clipping in very beautiful ways (that were definitely software-side), but the recording of that ended up being unusable because it wasn’t clipped at the same treshhold and just had enormous amplitudes. However … I might simply have recorded a specific bus rather than the monitor out.
Not necessarily. SC records to float32 by default, where out-of-range samples don’t clip, but rather shift precision toward larger values. What happens to those samples during playback is then up to the audio player. This may be clipping, but it might also be limiting – and limiting might explain OP’s impression that other sounds are compressed or drowned out. Can I imagine a Windows media player app slapping a limiter onto everything? Yeah… that’s plausible.
hjh
Not the audio player but my device is likely cheap junk. For whatever reason 40% main volume is its balance point with headphones. (As loud as you would ever want it)
I used s.meter and now I see that there’s massive clipping on my main instrument that I don’t understand because it’s not associated with volume swells but modulation control changes. The bass sound was also too high.
So I guess I should be 2 tracking out to another medium or fixing my other problem.
Edit: I figured out the basic problem which is that I my p.c. volume needs to be turned way up and everything else turned down. I know that’s usually the case but for whatever reason other software such as cubase are way louder so that 40% main volume shows the main cubase meter visibly jumping below zero.
Ah yes thanks for the info. I forgot about the float32 format as I tend to record to 24 bit fixed.
If you have a dc offset (sometimes related to lots of bass – it’s the lowest possible frequency), that can cause clipping even if perceived volume doesn’t change…it can also be bad for your speakers. LeakDC.ar is good to keep in mind for this
Spectrum analyzers can be misleading here, unless they do extra math to correct for the way that the discrete Fourier transform leaks energy into adjacent bins for frequencies that don’t exactly match a bin frequency.
If the signal happens to have, say, 20 Hz energy, that’s 2205 samples per cycle. If it’s a 2048-sample FFT as we use in freqscope, then each FFT window has not exactly a full cycle. Each window will span only part of the 20 Hz sinewave – so it will not average to 0, and this appears as DC energy, even though, over a longer span of time, the signal may average to 0 (no DC).
a = { SinOsc.ar(20, 0, 0.1).dup }.play;
s.freqscope; // shows a lot of "DC" energy
This momentary DC energy will alternate (at some rate) between “positive and negative” (that’s an oversimplification, since FFT results exist in the complex plane – edit: actually for DC, it’s accurate to speak of positive and negative because DC has no imaginary component – it lives only on the real axis) – if you averaged several successive DC bins, they would pretty much cancel to 0. But the magnitude that freqscope displays is calculated as sqrt(real_part.squared + imag_part.squared) – which is always positive – so it looks like there is always DC, even though in the long run, there isn’t. This is leakage – the 20 Hz energy cannot be fully captured in bin index 1 (at 44.1 kHz with a 2048 FFT size, bin 1 = 44100/2048 = 21.533203125 Hz), so some of its energy leaks out into bin 0.
Here, the first frame’s not-normalized “DC” is +34.xxx, and the second frame’s is -67.xxx, but “rho” (the magnitude) is positive for both – when freqscope shows only that magnitude, it loses information about the varying phase of the DC.
e = Signal.fill(2048, { |i| sin(2pi * (i / 2205)) });
f = e.fft(Signal.newClear(e.size), Signal.fftCosTable(e.size));
[f.real[0], f.imag[0], f.rho[0]]
-> [34.753307342529, -3.1105530477749e-12, 34.753307342529]
// now advance half a bin (hop = 0.5)
e = Signal.fill(2048, { |i| sin(2pi * ((i + 1024) / 2205)) });
f = e.fft(Signal.newClear(e.size), Signal.fftCosTable(e.size));
[f.real[0], f.imag[0], f.rho[0]]
-> [-67.553115844727, 7.8509525269777e-12, 67.553115844727]
In sum, if an FFT-based spectrum analyzer doesn’t account for longer scale trends in the positivity or negativity of the DC bins, then it’s likely to over-report DC. Not necessarily trustworthy. (Was going to check VCV Rack’s behavior on this, but the spectrum analyzer plugin is broken on my machine right now, so, no dice on that.)
I’ve tended to have more problems with DC when using feedback delays, where a tiny amount of DC at the input compounds upon itself in the feedback loop.
hjh
LeakDC.ar got rid of the clipping.
I appreciate the help! 
1 Like