Bit Depth Rate question

16 bit for cd.

24 bit otherwise for high definition audio.

MP3 for small and portable.

I never export 32.

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.

For use in movies, you might want 48K samples per second rather than 44.1K.

Saving to double rates like 88.2 or 96 might make sense if you were sending it to be mastered.

IMHO I would keep it at 24bit until you are ready to do the final export to CD (or if your exporting to HD - just keep it at 24bit). 

 
Leave it at 24  (or 32?)  until your ready to burn the CD. 
It gives the mastering software room to breath when rendering the audio.  
I keep all my masters at 44.1/24 bit these days and do bulk conversion in Gold Wave for the MP'3. 
Not much call from clients for CD's other than proofing. 
So I only use CD's for proofing mixes and I will export from Sonar at 16 bit to save a step. 
Serious albums go off to the next level once I'm done and that's been using Flash drives these days, so those are 44.1 /24. 
I also use 16 bit for my backing tracks as there's little to be gained otherwise. 
 

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.

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.

this is me too

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

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.

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...

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

No one I know.