It is not as simple as that. There is much more involved that is far more important in the quality of the sound than 24/48 vs 16/44. One of those things is having the ability to hear the difference through experience and in your monitoring chain/environment.

16/44.1 is required for standard CD's. 24/48 as well as other higher bit and sampling rates gives a greater potential for better quality sound, it does not mean you are promised it. Thousands of records are still made using only 44.1 and 16-bit, although 24-bit is now pretty much standard.

All things being equal, recording, mixing, mastering, at the highest possible specs makes for a better recording.

After finishing the master - and only then - converting to the "final product" specs(16/44.1 for a CD), should be the way to go.

Make sure to do the conversions properly(Dithering, etc.).

The goal is to NOT make your final product WORSE than all the quality your final product is capable of! Which can happen if you start and end your project at the same rates as the final product.

A(Rather far-flung) analogy is making 2" master tapes at 30" per second, with the final, major, sale product being audio cassettes. The end product should be better than recording, mixing, mastering, then duplicating from cassette only...(Don't worry, it is.)

How far do you take this? As far as you can...... Up to now, for most of us, for CD or broadcast or web output as the final product, 24/48 is the "defacto" standard - but that would be "way low" for a fine quality DVD output... Do the best you can.

TG

I do agree that for film and video production that 48 khz 24 bit seems to be the norm, but for music I believe the general opinion is that the extra quality gained by recording at 48 and then converting to 44.1 is lost during the conversion process if you are staying in the digital realm. The exception to this is if there is an analog conversion in the production process, i.e mixing to tape or running through an analog compressor/EQ in the mixing/mastering chain. I do my music recording at 44.1/24 which makes bouncing out 16 bit files "mid production" quick and easy without sample conversion.

Indeed, the "24" part can be the most important.

TG

i heard somewhere (heck, it could've been here) that when it comes to samplerate conversion, it's best to stick with multiples of the samplerate that the project will end up on.
example;
if it's gonna end up on a cd, which must have a samplerate of 44.1, then record at 44.1 or 88.2 or 176.4(does this even exist??)

is this correct?

personally, i do everything at 44.1/24 bit. no need for me to get any crazier than that. and when it comes time to mix it down, i just dither from 24 bits to 16 bits.

That's true, or more it used to be "truer"

Dithering and sample rate reduction have gotten a lot better in the past couple of years, so it's not as much of a problem.

I have to agree with Dave62....

if you record at 48 and are converting to 41.1 for CD, there was no point in recording at 48k. Converting to 41, you lost what you gained by recording at 48.

However, if you're possible doing other things with the recording than simply going to CD, then recording at 48 might be a good idea. Recording for DVD, as mentioned, would be one example. Or going to analog....

Audiofreqs, ...that recording at multiples (44.1 - 88.2 - 176.4) sounds like some sort of nummerology-esk urban legend. ;-) I think I understand the idea behind it, but I doubt it matters.....(though I could be wrong). Just sounds like the idea that painting the edge of a CD green makes it sound better. The simple explanation sounds kinda like it might be true, but when you delve into it, you relize it's a load of crP.

Which reminds me....of all places, Skeptic Magazine has a great article on Audio Fraud in this months issue. It's definitely recommended reading...

"...that recording at multiples (44.1 - 88.2 - 176.4) sounds like some sort of nummerology-esk urban legend. I think I understand the idea behind it, but I doubt it matters....."

it does..... of course it's easier to convert 88.2 to 44.1 than 48 to 44.1

what easier to divide by two.... this number: 3.1415927 or this one: 2?

but i think that the best quality is obtained by using 24/44.1 all through the process and then dither down as the absolutely last thing you do.... or 24/48 for film

Q: what easier to divide by two.... this number: 3.1415927 or this one: 2?

A: for a human it would be the number 2. Humans like and need easy, neat and tidy outcomes. It is a real human thing. To a computer, or rather a math processor, it matters not what the number is. It is just as as easy and accurate. Now you can argue floating point vs fixed point processing, but I'd challange any average even above average John to be able to hear a difference in a contolled test that would make one clearly better than the other.

AudioGaff wrote: ... To a computer, or rather a math processor, it matters not what the number is.

No
.. but I think it does matter when you have to push the answer to the nearest integer and you are forced to interpolate.

This is not to say that 88.2 divided by 2 doesn't also have some situations that give rise to special case quirks and errors.

AudioGaff wrote: ... but I'd challange any average even above average John to be able to hear a difference in a contolled test that would make one clearly better than the other.

... and that doesn't include special case examples designed to highlight these errors.

Here probably lies the whole point and as suggested above ... things are getting better at all levels.
Unless you are really interested in the Maths and theories of PCM then I suggest you just let your budget and your ears make your choices ...

sometimes workflow can be a big influence here.
I use 24 bit.
... then I use 44.1k for music ... that is for current projects and I don't know what I might decide for future projects.
I use 48k for video work ... and that doesn't look like it will change for some time yet.

AudioGaff wrote: Q: what easier to divide by two.... this number: 3.1415927 or this one: 2?

A: for a human it would be the number 2. Humans like and need easy, neat and tidy outcomes. It is a real human thing. To a computer, or rather a math processor, it matters not what the number is. It is just as as easy and accurate. Now you can argue floating point vs fixed point processing, but I'd challange any average even above average John to be able to hear a difference in a contolled test that would make one clearly better than the other.

hmmm..... the difference is very audible to me.... but both have qualities the other don't....

but this far i like fixed point better

not again...

Sample rate conversion is not applied in even multiples. Even if you record at 88.2 in effort to "simplify" the conversion...it is first upsampled to ~30 megahertz prior to being downsampled to 44.1 kHz. Any difference you hear b/w 96k and 88.2k after being downsampled is most likely overwhelmingly psychological.

The last poster was correct: SRC's don't just "drop every other sample" or "divide by two."
This is an archaic and incorrect way of looking at SRC.
The actual math behind it is rather complex. Many use inpulses.
An excellently-designed SRC (and they do exist) will only drop Nyquist frequency and not have any other effect on the sound, completely regardless of the "divisor" that we humans have in mind (that is not even considered by the SRC).

But seeing as the only theoretical advantage of higher sampling rates is a higher Nyquist anyway, it kind of negates the point of recording high then converting low.
Some plugins, particularily "CPU-efficiency-oriented" EQ's and compressors, sound better at higher sampling rates. In that case I can see the argument for recording higher than your final rate.

dasbin wrote: The last poster was correct: SRC's don't just "drop every other sample" or "divide by two."

i keep forgetting that we humans are an extremely quantifiable bunch!!

This is an archaic and incorrect way of looking at SRC.
The actual math behind it is rather complex.

GRUNT, me push button.....me hear sound...GRUNT 8-)

honestly though, this was the answer i was looking for