Thanks guys for the help. Seems like the bit rate depth you choose is linked to how you are using the song (like in a movie/video or MP3 format, etc).
For my purposes it's just to get a decent sound for my music - I am not a professional audio engineer - just recording my projects, so my usage is probably never going to be as diverse as the professionals' usage.
Looking forward to attempting mastering, screwing it up a million different ways, then getting it correct after much learning.
Never had the tools to master since starting years ago with analog recording.
Now that I do, I had to ask about the bit rate depth.

Al

I'm thinking "most" here have Preferences>Audio>Audio Data set like this:

Folder locations will be different, but File bit depths pretty much the default.
HTH,
T

Sam4246
Thanks guys for the help. Seems like the bit rate depth you choose is linked to how you are using the song (like in a movie/video or MP3 format, etc).

 
This is true, but only for when you deliver the final product. Until then, just keep everything at 24 bit and you can't go wrong. Then you can export to an appropriate format - e.g., 16-bit for CDs.
 
Glad you're having fun with the learning experience! It will definitely keep you busy for a while :) 

gswitz
Flac doesn't seem to be actually lossless to me. If I save a wave to Flac, export, import, null test, normalize, I don't get silence.

If Flac was lossless, I would save as Flac not 24 bit wave.

Flac is indeed lossless. I suspect your null test was flawed. For example, if the two files under test weren't precisely in phase with one another, or if there was an issue with the conversion on the way in, or a fader wasn't exactly at zero - a lot of small things could potentially color the test.
 
The FLAC encoder actually has a built-in test for verifying that data has not been altered. It generates a hash during the encoding process which will only match the decoded file's hash if the two files are bit-for-bit identical. You'll need the standalone FLAC encoder to run this test, but it's a free download.
 
The command line syntax is 
        FLAC -t {file_name}
This decodes a FLAC file internally but doesn't actually write the decoded data out, just performs the checksum function. Because a checksum was created when the wave was originally encoded and stored within the file, all FLAC has to do is decode the file, generate the hash and compare it against the original.
 
You could also encode a wave file, decode it and compare the two.  This would take the DAW out of the picture and all the potential testing errors it might entail.
 
If you're interested in test this out, let me know and I'll see if I can't find you some references. I haven't put FLAC on my new computer yet, so this is just from a geezer's unreliable memory.

P.S. I found this in the FLAC FAQ. It suggests another reason I didn't think of as to why your test files might not null: wave files contain more than just audio data.
 
I compressed a WAVE file to FLAC, then decompressed to WAVE, and the two weren't identical. Why?

WAVE is a complicated standard; many kinds of data besides audio data can be put in it. Most likely what has happened is that the application that created the original WAVE file also added some extra information for it's own use, which FLAC does not store or recreate by default (but can with the --keep-foreign-metadata option) (see also). The audio data in the two WAVE files will be identical. There are other tools to compare just the audio content of two WAVE files; ExactAudioCopy has such a feature.

For the more technically inclined, by default FLAC only stores what is in the 'fmt ' and 'data' sub-chunks of a WAVE file.

Sometimes I just prefer to "accept" that certain things are "true".
I was a pretty good math student, but now it just makes my head hurt.
This will make your life "easy":
Record at 24 bit = good
Dither only once on final export = good
44.1k is "good enough", but if you want to torture your system 96k is "good" if it can handle it...

Bristol_Jonesey
I export my songs at 32 bit without dithering so I can bring them into my Album/Mastering project at as high a resolution as possible.
 
Then for CD, export @ 16bit 44.1KHz WITH dithering.

Dithering only makes sense when you change the bit depth downward anyway. There is no benefit at all (in fact a drawback) to exporting anything at the same bit depth and adding dithering. Maybe you knew that and you were just being complete, but I thought it worth mentioning. So I agree, stay at high bit depth as long as possible and when going 16 bit to burn, add dithering.

As the bitrate gets higher, the amount of possible values that can be stored for a variable gets higher too.  I think it's (2^bitrate) if I'm not mistaken.  So for example, at 16 bits there are 2^16 = 65,536 possible values for volume.  At 24-bit, it's 16,777,216 possible values. 
 
The more possible values there are, the more dynamic range you can get.   16-bit data can handle a range of about 96 dB while 24 dB can handle a range of 144 dB.  So mixing at 24-bit is easier because you can avoid getting values that exceed the top of the dynamic range (clipping).  Also, if you play back at 24-bit, it should theoretically sound more dynamic than 16-bit.
 
The more bits for each data point, the more space that data takes up.  The higher the sample rate, the more data points per unit of time, which also increases the space.  So that's why they can't go crazy with the bit rate and sample rate on a CD which only holds 700 MB.
 
 

does anyone ever render to 64 bit audio? if so, why?

wetdentist
does anyone ever render to 64 bit audio? if so, why?

No one I know.