Print or Export?

  • Thread starter Thread starter sixer2007
  • Start date Start date
S

sixer2007

New member
Hey guys,

I hear some people using the word "print" in talking about getting their song into one Wav file, But i've always been using "export audio mixdown". Is there a "print" function in Cuabse or just export? And if there is a print function, how is it any different?

Thanks!
 
Hey guys,

I hear some people using the word "print" in talking about getting their song into one Wav file, But i've always been using "export audio mixdown". Is there a "print" function in Cuabse or just export? And if there is a print function, how is it any different?

Thanks!

I always use export - I've never noticed any problems with this. The equivalent of 'print' in cubase is to use the 'realtime' checkbox when you export AFAIK.
 
Yeah, i've noticed that box. I used it once and realized that it had to play the song back in real time as it was processed, so I never used it again.
You don't notice any quality difference when you export in real time?
 
iWhen they say print it's jargon for export to stereo track.
Print it ready for mastering.
there might be a print function but its more likely for printing scores from cubase.
Just use the export audio mixdown.
 
iWhen they say print it's jargon for export to stereo track.
Print it ready for mastering.
there might be a print function but its more likely for printing scores from cubase.
Just use the export audio mixdown.

Naw Kip - there are actually guys who SWEAR ON THEIR GRANDMOTHERS GRAVE that a realtime bounce sounds better than an export. The equivalent of a realtime bounce in cubase is the realtime checkbox on export. I bet that a realtime export and a normal export would null to infinity.
 
Naw Kip - there are actually guys who SWEAR ON THEIR GRANDMOTHERS GRAVE that a realtime bounce sounds better than an export. The equivalent of a realtime bounce in cubase is the realtime checkbox on export. I bet that a realtime export and a normal export would null to infinity.

I'd also bet that's true 99% of the time, but it's not necessarily always going to be the case. If a plugin developer calls native timing functions instead of using something like the samplerate and count (which would produce the same results regardless of actual elapsed time) for determining elapsed time (which is a poor decision, IMO, but it's not impossible or unheard of), there's going to be differences since not as much time elapses between calls to process() or processReplacing() or whatever they're using. There's some VSTi's that sound different, too, for reasons I can only speculate have something to do with timing stuff, too - The Grand is one. It actually takes longer to do a normal export when using that VSTi than a real-time one. I don't know if it's a bug in the version I have or what, but it doesn't come out exactly the same.

It's my opinion that any plugin that produces different results in real-time than in non-real-time is bugged, but that doesn't mean they don't exist.
 
I'd also bet that's true 99% of the time, but it's not necessarily always going to be the case. If a plugin developer calls native timing functions instead of using something like the samplerate and count (which would produce the same results regardless of actual elapsed time) for determining elapsed time (which is a poor decision, IMO, but it's not impossible or unheard of), there's going to be differences since not as much time elapses between calls to process() or processReplacing() or whatever they're using. There's some VSTi's that sound different, too, for reasons I can only speculate have something to do with timing stuff, too - The Grand is one. It actually takes longer to do a normal export when using that VSTi than a real-time one. I don't know if it's a bug in the version I have or what, but it doesn't come out exactly the same.

It's my opinion that any plugin that produces different results in real-time than in non-real-time is bugged, but that doesn't mean they don't exist.

Yeah - good call on the 99%. As you pointed out - the developer could be doing something blatantly wrong or stupid, modulation effects with some element of randomness, weird behaviour in vsti etc.. I have the same experience you describe with an older version of Halion from 2004. Normal Export actually takes longer than a real-time export. So you got me on the 1% - there are no absolutes - but I generally go with the 99% explanation when I am describing something to someone asking a very basic question about a 'hot-button' voodoo issue.
 
I find the timing on bundled chopper plugin in Cubase 6 is always messed up when I export, so I've had to freeze the track for it to get it right. The real time option didn't fix it in this case.
 
Printing tracks is something that pro tools users need, not cubase.

Just freeze the tracks if you need more CPU headroom.
 
For the record, I have heard a difference between exported and printed tracks.

There has been many a discussion on this and here is one over at another popular forum:

Cubase export - Gearslutz.com

Cheers :)
 
And I'm sure many people don't know this, but you can print tracks in real time from track to track just like you can in pro tools. You create in/out buses that are disconnected and then route out to in and record it just like in pro tools...

I just don't see the point.
 
Oh yeah, I use that sometimes for things like reverse verbs and whatnot. Usually for just one channel to another though, not sending all channels to a buss and then back out to another single channel. You'd still have to export than one final channel anyway, so I don't see any reason to do that either.
 
Back
Top