[linux-audio-user] Re: producing a drum sample library for hydrogen

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>  Why wouldn't you simply record at a higher rate and downsample? 
> There's only one resample {Other than the processing or whatever.}
> and you start with a better quality sample that way.

I'm not an audio professional, nor have I ever played one on TV.  But it 
seems to me that one should probably minimise resampling at all costs 
unless it's necessary.

If you have lots of libraries at 48K/24-bit, you should probably record 
your new material in that format, do all of your processing and mixing in 
that format, and only when exporting to your end-destination format doing 
the requisite dithering and resampling.

I guess Hell is defined as your project having vocals recorded in 44/16, 
drum samples in 24/96, and the rest of your electronica in 48/16.

I think even "trivial" up/downsampling [1:2 or 2:1] ratios are frought with 
some peril, since in the downsampling direction you must be absolutely sure 
there is no spectral energy above Mr. Nyquist's limit.  Every resampling 
event implies some filtering, and filtering seems like one of those you 
things you do only when you have to.  

Filtering removes content, and even the best of them probably remove 
something harder-to-measure than S/N ratios and frequency response.  There 
is a great deal of chatter amongst the audio professionals about "vitality" 
and the "reality" of a given recording's sound, which cannot be but hurt by 
too much chewing and processing.

Again, I'm an outsider to the MUSICAL/CREATIVE part of audio - 
<EMBARRASSMENT> up until shockingly recently, I thought Octave progressions 
followed a power-of-2 sequencing.  </EMBARRASSMENT>

I know only one "audio professional" personally, who is a rather cynical 
and grizzled guy who is a hardcore ProTools Snob [not the new host-based 
stuff].  

"Wire speed is my latency, fool."  "Straight wire with gain is all I need 
from you stupid engineers!"  

He responds to my discussions and questions about DSP, digital filter 
design, and all of that as such "forest besides the trees" talk... "But how 
does it SOUND?!  Are you so busy with your digital processing mathematics 
that you're using your EYES instead of LISTENING?"  Etc, etc.  He's 
obviously not a Luddite as he makes extensive use of digital audio [PT is 
an all-digital system], but his attitudes about which tools to use and when 
are remarkably different than what might seem logical to a mathematician or 
electronics engineer.

It seems reasonable that before setting out to decide on your recording 
format, you need to figure out what you're producing for.  Movie soundtrack 
audio seems to be centered around 48KHz/16bit formats [I think they do 
field acquisition at 20-24 bits on their Nagras though, no?], with CD audio 
being 44.1/16 of course.

If your album is going to be "heavily processed" anyway, I suppose there's 
probably little harm in recording and editing at the highest format quality 
you can use, since repeated iterations through DSP stuff will be damaged 
less at the more "precise" formats.  16 bits is such a shockingly small 
numeric range, really, when you start tossing it into floating point 
algorithms for DSP.  That final downsampling is probably going to do alot 
less damage to your work than the accumulated round-off distortions going 
back and forth to/from floating point algorithms.

Anyway, this is my 1/2 penny.  As a computer science/mathematician-oriented 
person, I know full well the trap of "I'm an engineer, I can FIX that..." 
impulses which arise from a consciousness and a grasp that every "problem" 
just requires another algorithm or technique to evolve or tune.  But 
sometimes, less is more, and as I listen more critically to various pieces 
of music, I find the more "intact" it is, the more "real" it is to me.  

=MB=

-- 
A focus on Quality.



[Index of Archives]     [Linux Sound]     [ALSA Users]     [Pulse Audio]     [ALSA Devel]     [Sox Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux