Subject: Re: [linux-audio-user] Re: Sample Rates / Sample Sizes
From: Mark Knecht (mknecht_AT_controlnet.com)
Date: Thu Jun 24 2004 - 21:05:09 EEST
Steve Harris wrote:
> On Thu, Jun 24, 2004 at 09:52:54 -0700, Mark Knecht wrote:
>
<SNIP>
>> Thanks for the clarifications though. It does raise an interesting
>>difference between something like Ardour, I guess, and Pro Tools where I
>>can insert a dithering plugin pretty much anyplace in the signal chain
>>if I choose to. Maybe the RTAS standard makes some decision to go to int
>>based on where the output is going? I don't know.
>
>
> I suspect that the difference is that in RTAS the conversion is specified
> (well, as theres only one host, it /is/ specified ;).
>
> - Steve
>
Yes, that's correct. Although there are some strange paths I hadn't
quite considered.
1) The hardware and Pro Tools is native 24-bit, so I think everything
that goes to the hardware is actually 24-bits deep.
2) If I insert a dither then presumably what's sent to the hardware is
24-bits deep with the bottom 8 bits zeroed out and the upper 16-bits
containing the audio + dither. you hear 16-bits over 24-bit hardware.
Still OK.
3) Since bouncing is non-realtime, when bouncing with a dither inserted
it likely bounces first a 24-bit file ala #2, then converts it to 16-bit
by stripping out data. There is an option for conversion on the fly vs.
afterward. Still make sense, I think.
4) If I insert a dither in the middle of a session on a single track
then it's unlikely that the output is converted to int unless Pro
Tools/RTAS is design to convert it right back to float so that the track
can mix with the rest of the session. I don't have a clue what really
happens in this case. I've never had a reason to use this, but it does
raise the question of how to best import a 24-bit track into a 16-bit
session. I've have to do this once or twice. Possibly I should have
dithered the track. I'd guess the normal conversions just strip the
bottom 8-bits?
Anyway, interesting, I suppose, to some of us. Sorry for consuming
bandwidth for those that are not.
Cheers,
Mark
This archive was generated by hypermail 2b28 : Thu Jun 24 2004 - 20:58:08 EEST