Combining 24 bit/44.1, 16 bit/44.1 and 16/48 in Vegas?

KeithT wrote on 1/20/2000, 11:16 PM
I'm working on a project that involves mixing some existing
16 bit/44.1 tracks (Rendered from Acid)with new overdubs
that I'm recording in 24 bit/44.1, and possibly flying in
some pre-existing DA88 tracks done in 16/48 thru a MOTU
2408.
Three different rates/depths!
Question: I remember Peter or someone stating that Vegas
is not running at maximum efficency when it has to process
these differences on the fly, so... Should I convert all
files to 24 bit/44.1 to get maximum tracks and processing
power? Thanks to all for this helpful forum, Keith

Comments

wgallant wrote on 1/21/2000, 8:51 AM
FWIW: I can't say what may work best for you, but we almost always
have a few 16/44.1 tracks in with 20 or more 16/48 tracks with no
noticeable difference in performance from Vegas.

Willg...

Keith wrote:

>>different rates/depths!
>>Question: I remember Peter or someone stating that Vegas
>>is not running at maximum efficency when it has to process
>>these differences on the fly, so... Should I convert all
>>files to 24 bit/44.1 to get maximum tracks and processing
>>power? Thanks to all for this helpful forum, Keith
pwppch wrote on 1/21/2000, 11:54 AM
Bit depth conversions are not an issue for the most part as we
convert to floating point internall. Resampling can be expensive. If
your project is mostly 44.1 files, then set your project type to
44.1. A few 48 kHz files here and there wont kill you.

If you have lots of 48k files - long streams from your DA88 - then it
would be better to set your project to 48.

The point is that any conversion takes CPU. The more conversion, the
more CPU. If you are pushing the edge with FX and such, then every
last CPU cycle counts. If you have lots of breathing room, don't
sweat it.

The best optimization is to look at your raw media and then set your
project settings to best fit your media. This is not that big of
deal. You can always switch to what ever project settings if you want
to hear how things are sounding at different sample rates and bit
depths. For the moment to moment editing and such, give Vegas a
breather.

Peter


Keith wrote:
>>I'm working on a project that involves mixing some existing
>>16 bit/44.1 tracks (Rendered from Acid)with new overdubs
>>that I'm recording in 24 bit/44.1, and possibly flying in
>>some pre-existing DA88 tracks done in 16/48 thru a MOTU
>>2408.
>>Three different rates/depths!
>>Question: I remember Peter or someone stating that Vegas
>>is not running at maximum efficency when it has to process
>>these differences on the fly, so... Should I convert all
>>files to 24 bit/44.1 to get maximum tracks and processing
>>power? Thanks to all for this helpful forum, Keith
KeithT wrote on 1/21/2000, 1:23 PM
Thank you Peter and Will. As this is a musical project with mostly
linear tracks from the beginning to end of each song(not that much
muting between events), I am really trying to get the maximum tracks
out of my PII 450 and IDE66 set up.
Previously to going mostly 24-bit, I could get 24-plus linear tracks
of 16/44.1 at mixdown with the basic in-track eq/comp plus 3 or 4 fx
busses easily, but I suspect I'll hit a wall now that I'm going
mostly 24-bit/44.1. I may resample the 48khz files if I don't lose
too much of the original character. Other than the usual Windows
settings for Digital audio, are there any other tips for conserving
power in Vegas Pro?
Thanks, Keith

Peter Haller wrote:
>>Bit depth conversions are not an issue for the most part as we
>>convert to floating point internall. Resampling can be expensive.
If
>>your project is mostly 44.1 files, then set your project type to
>>44.1. A few 48 kHz files here and there wont kill you.
>>
>>If you have lots of 48k files - long streams from your DA88 - then
it
>>would be better to set your project to 48.
>>
>>The point is that any conversion takes CPU. The more conversion,
the
>>more CPU. If you are pushing the edge with FX and such, then every
>>last CPU cycle counts. If you have lots of breathing room, don't
>>sweat it.
>>
>>The best optimization is to look at your raw media and then set
your
>>project settings to best fit your media. This is not that big of
>>deal. You can always switch to what ever project settings if you
want
>>to hear how things are sounding at different sample rates and bit
>>depths. For the moment to moment editing and such, give Vegas a
>>breather.
>>
>>Peter
>>
>>
>>Keith wrote:
>>>>I'm working on a project that involves mixing some existing
>>>>16 bit/44.1 tracks (Rendered from Acid)with new overdubs
>>>>that I'm recording in 24 bit/44.1, and possibly flying in
>>>>some pre-existing DA88 tracks done in 16/48 thru a MOTU
>>>>2408.
>>>>Three different rates/depths!
>>>>Question: I remember Peter or someone stating that Vegas
>>>>is not running at maximum efficency when it has to process
>>>>these differences on the fly, so... Should I convert all
>>>>files to 24 bit/44.1 to get maximum tracks and processing
>>>>power? Thanks to all for this helpful forum, Keith
pwppch wrote on 1/21/2000, 2:23 PM

If you have tracks that have long sections of silence, then split the
one long event into multiple events and then adjust the events so
that they don't include the silence. This will help to make Vegas
only stream what it needs to stream. The silence is not needed and we
can generate silence internally - where no events exist - more
efficeintly than reading silence from a file.

So slice and dice up your big long events- not the files - into
events that only have content. Of course, if you have a mostly solid
audio in all of the tracks - little silence - this technique will not
buy you a lot. If your 24 track project has 24 tracks of solid audio
from beginning to end, then you are streaming lots of data. If you
have 24 tracks, but say at the most only 12 of those tracks have
audio at one time playing - no silence - you cut down the streaming
and file reading overhead.

Peter


Keith wrote:
>>Thank you Peter and Will. As this is a musical project with mostly
>>linear tracks from the beginning to end of each song(not that much
>>muting between events), I am really trying to get the maximum
tracks
>>out of my PII 450 and IDE66 set up.
>>Previously to going mostly 24-bit, I could get 24-plus linear
tracks
>>of 16/44.1 at mixdown with the basic in-track eq/comp plus 3 or 4
fx
>>busses easily, but I suspect I'll hit a wall now that I'm going
>>mostly 24-bit/44.1. I may resample the 48khz files if I don't lose
>>too much of the original character. Other than the usual Windows
>>settings for Digital audio, are there any other tips for conserving
>>power in Vegas Pro?
>>Thanks, Keith
>>
>>Peter Haller wrote:
>>>>Bit depth conversions are not an issue for the most part as we
>>>>convert to floating point internall. Resampling can be expensive.
>>If
>>>>your project is mostly 44.1 files, then set your project type to
>>>>44.1. A few 48 kHz files here and there wont kill you.
>>>>
>>>>If you have lots of 48k files - long streams from your DA88 -
then
>>it
>>>>would be better to set your project to 48.
>>>>
>>>>The point is that any conversion takes CPU. The more conversion,
>>the
>>>>more CPU. If you are pushing the edge with FX and such, then
every
>>>>last CPU cycle counts. If you have lots of breathing room, don't
>>>>sweat it.
>>>>
>>>>The best optimization is to look at your raw media and then set
>>your
>>>>project settings to best fit your media. This is not that big of
>>>>deal. You can always switch to what ever project settings if you
>>want
>>>>to hear how things are sounding at different sample rates and bit
>>>>depths. For the moment to moment editing and such, give Vegas a
>>>>breather.
>>>>
>>>>Peter
>>>>
>>>>
>>>>Keith wrote:
>>>>>>I'm working on a project that involves mixing some existing
>>>>>>16 bit/44.1 tracks (Rendered from Acid)with new overdubs
>>>>>>that I'm recording in 24 bit/44.1, and possibly flying in
>>>>>>some pre-existing DA88 tracks done in 16/48 thru a MOTU
>>>>>>2408.
>>>>>>Three different rates/depths!
>>>>>>Question: I remember Peter or someone stating that Vegas
>>>>>>is not running at maximum efficency when it has to process
>>>>>>these differences on the fly, so... Should I convert all
>>>>>>files to 24 bit/44.1 to get maximum tracks and processing
>>>>>>power? Thanks to all for this helpful forum, Keith
karlc wrote on 1/21/2000, 4:48 PM

Would this also apply to tracks that contain these multiple smaller
events, but still use the volume and/or pan envelopes?

IOW, I might have copied a solid audio file to another track, slid it
back in time a few milliseconds, but only want to use parts of it, at
an increased volume, to excite a reverb return.

If I get what you are saying, it is best to "split" the copy as
necessary and delete those parts not in use instead of relying on the
volume evelopes to silence the unwanted parts?

I ask because I am all for sucking that last bit of performance out
of Vegas ... and a bit here and a bit there evenentually adds up to
some bytes or more. :)

Thanks!

KAC ...

Peter Haller wrote:

>>So slice and dice up your big long events- not the files - into
>>events that only have content. Of course, if you have a mostly
solid audio in all of the tracks - little silence - this technique
will not buy you a lot.
pwppch wrote on 1/21/2000, 9:32 PM
>>Would this also apply to tracks that contain these multiple smaller
>>events, but still use the volume and/or pan envelopes?
>>

>>IOW, I might have copied a solid audio file to another track, slid
it
>>back in time a few milliseconds, but only want to use parts of it,
at
>>an increased volume, to excite a reverb return.
>>
>>If I get what you are saying, it is best to "split" the copy as
>>necessary and delete those parts not in use instead of relying on
the
>>volume evelopes to silence the unwanted parts?
>>
Yes. We still stream data in this case, even if the mix/envelopes
cause silence to occur. If there is no event, no processing or reads
are done at that point.

Basically, if an event exists at a point during playback (an event
that has file associated to it), we stream that data. Because all
event parameters are editable in real time, we have little choice in
this. If there is no event at a point in time, there is nothing to
read and simple silence generated and streamed.

One thing to note. This is at the track level. If you have a track
that is also "sending" data to a assignable FX, in order to keep the
fx ready and correct, we stream through them. What this means is that
while slicing and dicing will gain you in one aspect, other mixing
aspects are still in play when no events are being "streamed".

>>I ask because I am all for sucking that last bit of performance out
>>of Vegas ... and a bit here and a bit there evenentually adds up to
>>some bytes or more. :)
>>

This technique definitly falls in to this area. It can be tedious
editing, but this is also part of the strength of Vegas.

Take a look at the Demos on the Vegas CD. These are great examples of
slicing and dicing. Silence is golden in a DAW and directly equals
CPU and resources.

The alternative is using Vegas as a tape recorder and track envelopes
as mutes/solos. Vegas gives you a non destructive erase head. Take
advantage of it.

Peter
karlc wrote on 1/22/2000, 2:25 PM
Thanks, Peter ... IMO, this is classified as "need to know" stuff and
will come in handy to tweak that last ounce of resources out of a DAW
running Vegas.

It is fortuitous that it was brought up at this time as I just
started mixing a project that necessitated these very same techniques
be used, and I did so more out of a gut reaction than an actual
informed reasoning ... can't say that anymore. :)

BTW, just saw the Vegas review in EQ. Overall a good job.

KAC...


Peter Haller wrote:


>>Basically, if an event exists at a point during playback (an event
>>that has file associated to it), we stream that data.

>>Silence is golden in a DAW and directly equals
>>CPU and resources.
>>

>>Vegas gives you a non destructive erase head. Take
>>advantage of it.
pwppch wrote on 1/23/2000, 7:17 PM
>>BTW, just saw the Vegas review in EQ. Overall a good job.
>>

Yeah, not a bad review at all. Suprising for being a 1.0 and the new
kid on the PC-DAW block.

Imagine what we will be doing by the time we hit version 6!

Peter