williamcopper
Max Output Level: -68 dBFS
- Total Posts : 1120
- Joined: 2014/11/03 09:22:03
- Location: Virginia, USA
- Status: offline
Slow bounce, fast bounce ...
See image. Same music, slow bounce vs fast bounce. While they align and sound similar, clearly they are not the same. Edit -- all of my posts below relate to 'Bounce to Track' as used for a set of midi tracks sending data to a VST (Kontakt) and producing a new audio track. As far as I know, 'bounce to track' as a means of manipulating audio files works ok. Made in Platinum, H version, all is midi sent to Kontakt5, and 'bounced' to generate audio. Top one is fast bounce. 
post edited by williamcopper - 2015/12/04 17:15:08
|
pwalpwal
Max Output Level: -43 dBFS
- Total Posts : 3249
- Joined: 2015/01/17 03:52:50
- Status: offline
Re: Slow bounce, fast bounce ...
2015/12/03 11:26:44
(permalink)
afaia they're different processes - e.g., one of them ignores midi automation, though i forget which (fast?) but a baker or scook should probably confirm
|
batsbrew
Max Output Level: 0 dBFS
- Total Posts : 10037
- Joined: 2007/06/07 16:02:32
- Location: SL,UT
- Status: offline
Re: Slow bounce, fast bounce ...
2015/12/03 11:30:59
(permalink)
just because the screen looks different,
does not mean they are different,
just because of what is involved to 'generate' the wav view.
if you pull them into the same file,
reverse phase,
they should null
|
pwalpwal
Max Output Level: -43 dBFS
- Total Posts : 3249
- Joined: 2015/01/17 03:52:50
- Status: offline
Re: Slow bounce, fast bounce ...
2015/12/03 11:59:38
(permalink)
|
brundlefly
Max Output Level: 0 dBFS
- Total Posts : 14250
- Joined: 2007/09/14 14:57:59
- Location: Manitou Spgs, Colorado
- Status: offline
Re: Slow bounce, fast bounce ...
2015/12/03 12:03:10
(permalink)
The MIDI-automation-not processed-with-fast-bounce-disabled issue was fixed some time ago - even before Platinum IIRC.
Although some synths may behave differently on fast bounce (and some need to have a "render" or "offline" mode explicitly enabled), another likely explanation is that some element in the synth/patch programming is deliberately "random" or not phase-locked so it never renders the same way twice, whether fast or slow. There are many synths and FX that won't null when bounced twice whether fast or not. The difference is audible when null-testing, but probably not in an A/B listening test.
SONAR Platinum x64, 2x MOTU 2408/PCIe-424 (24-bit, 48kHz) Win10, I7-6700K @ 4.0GHz, 24GB DDR4, 2TB HDD, 32GB SSD Cache, GeForce GTX 750Ti, 2x 24" 16:10 IPS Monitors
|
pwalpwal
Max Output Level: -43 dBFS
- Total Posts : 3249
- Joined: 2015/01/17 03:52:50
- Status: offline
Re: Slow bounce, fast bounce ...
2015/12/03 12:06:12
(permalink)
all the freeze/bounce/export processing now uses the same process? good news! :-) eta: of course, not including deliberately randomising functionality within particular plugs thanks for clarifying :-)
post edited by pwalpwal - 2015/12/03 12:19:28
|
bitflipper
01100010 01101001 01110100 01100110 01101100 01101
- Total Posts : 26036
- Joined: 2006/09/17 11:23:23
- Location: Everett, WA USA
- Status: offline
Re: Slow bounce, fast bounce ...
2015/12/03 12:17:14
(permalink)
It'd be an interesting test to clone the track and then bounce/freeze it twice in a row using the same settings and see if the waveforms still appear to be different. If they are, then that suggests there is some randomness in the patch, such as a chorus effect.
Most of the time with sample players you'll get identical results because you're just rendering the same samples. If you don't, then it's because of some effects being applied within the Kontakt instrument (which may not be visible).
The difference, as Steve points out, may not actually be audible. Contrary to intuition, two waveforms can be visually quite different and still sound the same. Sometimes, literally exactly the same.
 All else is in doubt, so this is the truth I cling to. My Stuff
|
Beepster
Max Output Level: 0 dBFS
- Total Posts : 18001
- Joined: 2012/05/11 19:11:24
- Status: offline
Re: Slow bounce, fast bounce ...
2015/12/03 12:20:41
(permalink)
batsbrew
if you pull them into the same file,
reverse phase,
they should null
Yes. That is the proper test. Even still they may not totally null because of things like "anti machine gun" features on drum programs, "round robin" sample playback, effects responding slightly differently through each pass, etc. You would have to FREEZE everything (effects, synths and anything else that might produce any variations in the playback/mixdown) THEN do your comparison/null. Edit: And I see others bringing up the same concepts.
|
Midiboy
Max Output Level: -82 dBFS
- Total Posts : 414
- Joined: 2015/01/14 09:29:54
- Location: Northwood
- Status: offline
Re: Slow bounce, fast bounce ...
2015/12/03 16:20:40
(permalink)
Slow bounce does allow for automation. You just have to be sure to check it in the options.
|
williamcopper
Max Output Level: -68 dBFS
- Total Posts : 1120
- Joined: 2014/11/03 09:22:03
- Location: Virginia, USA
- Status: offline
Re: Slow bounce, fast bounce ...
2015/12/03 18:33:28
(permalink)
Thanks for the ideas. I've posted previously that no, reversing phase (at least as I know how) does not eliminate sound.
I have trouble with the idea that slow bounce is WORSE than fast bounce, since effectively, slow bounce is what we work with just working on a mix and letting the midi drive the VST instrument.
In my work, there is very little, pretty nearly NO, random change in how Kontakt responds to events.
More comments welcome .. I clearly prefer a fast bounce, but if it isn't what I've slaved over for weeks to get to sound right, then I do not prefer fast!
|
williamcopper
Max Output Level: -68 dBFS
- Total Posts : 1120
- Joined: 2014/11/03 09:22:03
- Location: Virginia, USA
- Status: offline
Re: Slow bounce, fast bounce ...
2015/12/03 18:37:02
(permalink)
The OP posted because in a substantial project (10+ minutes) when I mixed some slow bounce and some fast bounce I felt there were some mis-matches that bothered my ear.
|
williamcopper
Max Output Level: -68 dBFS
- Total Posts : 1120
- Joined: 2014/11/03 09:22:03
- Location: Virginia, USA
- Status: offline
Re: Slow bounce, fast bounce ...
2015/12/03 18:38:44
(permalink)
I've also posted before about a sonar bug that essentially eliminates midi controllers that have not changed out past a certain time frame .. this could be the source of the difference.
|
bvideo
Max Output Level: -58 dBFS
- Total Posts : 1707
- Joined: 2006/09/02 22:20:02
- Status: offline
Re: Slow bounce, fast bounce ...
2015/12/03 19:11:46
(permalink)
☄ Helpfulby williamcopper 2015/12/03 19:37:01
Just a thought about the terms "slow" and "fast" bounce. I believe these are misnomers. Better to call them real-time and non-real-time.
The non-real-time bounce is said to be fast because it doesn't wait for audio output to be delivered. However, it also means that it does not have to keep up with real time audio, hence can use signal processing algorithms that emphasize quality over efficiency. So theoretically, this could be the slower bounce, if the CPU is marginal for the project. But since projects might have significantly varying density or complexity in the timeline, the overall render time might indeed be shorter than real-time, even if the CPU would not be able to play the whole project in real time using "quality" algorithms.
Real-time bounce means it is probably producing essentially what you hear when you play the project. Since it is required to "keep up" with audio, it may be using a signal processing algorithm that emphasizes efficiency over quality.
Recall the oversampling that was added in Sonar. When first offered, oversampling would only be engaged during non-real-time export. If oversampling improves quality for a given track, then there should be a visible difference (esp. in the "null") compared with real-time bounce, and one would hope it sounds better.
In another thread it was also mentioned that some synths internally use different algorithms for real-time vs non-real-time (sometimes known as "render", here meaning the intention to place output in a file rather than sending it to audio).
So there are legitimate reasons for real-time audio to differ from non-real-time, not only bugs. Whether it sounds better, just different, or the same is not entirely predictable. And this discussion does not take into account the deliberate randomness mentioned above for some synths and effects, since that is seemingly unrelated to real-time vs non-real-time.
W10 pro, Sonar Platinum, Alesis Multimix 16 FW, MOTU Express 128, Gigabyte Z370 HD3P, i7 8700K, 16 Gigs, ssd + 2 X 2T disks, D50-MEX, JV80, A90EX, M1REX
|
williamcopper
Max Output Level: -68 dBFS
- Total Posts : 1120
- Joined: 2014/11/03 09:22:03
- Location: Virginia, USA
- Status: offline
Re: Slow bounce, fast bounce ...
2015/12/03 19:28:05
(permalink)
Very interesting point of view, bvideo. I did note that the fast bounce in my OP image appeared to be more defined (more jagged edges anyway). If that's right, how are we supposed to use sonar to build a mix? Constantly bounce and listen? Will end up being even more time consuming than 'slow bounce' ... I'll look for more input on this.
|
Anderton
Max Output Level: 0 dBFS
- Total Posts : 14070
- Joined: 2003/11/06 14:02:03
- Status: offline
Re: Slow bounce, fast bounce ...
2015/12/03 20:21:08
(permalink)
If there is any kind of chorusing, detuning, or reverb (which usually includes some randomizing elements to give a more "realistic" effect), the results will be different. Also real-time bounces are subject to latency issues, but not fast bounces, which are all done as calculations inside the computer. I'd be more surprised if there was no difference between real-time and fast bounce.
Create a project with 10 tracks, each with a periodic waveform of a varying frequency (not a virtual instrument, e.g., a test tone generated in Sound Forge or whatever). Do not add any effects. Run the same test and see what happens.
|
Adq
Max Output Level: -82 dBFS
- Total Posts : 426
- Joined: 2015/01/21 20:05:25
- Status: offline
Re: Slow bounce, fast bounce ...
2015/12/03 22:52:12
(permalink)
bitflipper
It'd be an interesting test to clone the track and then bounce/freeze it twice in a row using the same settings and see if the waveforms still appear to be different. If they are, then that suggests there is some randomness in the patch, such as a chorus effect.
This. Did OP try to do two fast bounces and two real-time bounces and compare all four files?
post edited by Adq - 2015/12/03 23:03:38
|
brundlefly
Max Output Level: 0 dBFS
- Total Posts : 14250
- Joined: 2007/09/14 14:57:59
- Location: Manitou Spgs, Colorado
- Status: offline
Re: Slow bounce, fast bounce ...
2015/12/04 02:20:55
(permalink)
Anderton
Also real-time bounces are subject to latency issues, but not fast bounces, which are all done as calculations inside the computer. I'd be more surprised if there was no difference between real-time and fast bounce.
If you do an audible bounce, the output will be subject to latency, but the write to disk of the file is not. Anderton
Create a project with 10 tracks, each with a periodic waveform of a varying frequency (not a virtual instrument, e.g., a test tone generated in Sound Forge or whatever). Do not add any effects. Run the same test and see what happens.
I've done this many times over the years with various projects. If every track is pure audio with all FX and automation bypassed or frozen into the individual tracks, real-time and fast bounces of the entire mix will null to perfect digital silence with one of them inverted. And many active synths and FX will, too - just not all.
SONAR Platinum x64, 2x MOTU 2408/PCIe-424 (24-bit, 48kHz) Win10, I7-6700K @ 4.0GHz, 24GB DDR4, 2TB HDD, 32GB SSD Cache, GeForce GTX 750Ti, 2x 24" 16:10 IPS Monitors
|
brundlefly
Max Output Level: 0 dBFS
- Total Posts : 14250
- Joined: 2007/09/14 14:57:59
- Location: Manitou Spgs, Colorado
- Status: offline
Re: Slow bounce, fast bounce ...
2015/12/04 02:31:51
(permalink)
williamcopper
I've also posted before about a sonar bug that essentially eliminates midi controllers that have not changed out past a certain time frame .. this could be the source of the difference.
I'm pretty sure that's just a display issue with controller shadowing. The synth only has to respond to the controller once, and whatever state is set will persist indefinitely until a different controller value is sent. Unless SONAR is actually sending another controller message with a value of zero at the point that the shadow disappears, there should be no change in the synth output.
SONAR Platinum x64, 2x MOTU 2408/PCIe-424 (24-bit, 48kHz) Win10, I7-6700K @ 4.0GHz, 24GB DDR4, 2TB HDD, 32GB SSD Cache, GeForce GTX 750Ti, 2x 24" 16:10 IPS Monitors
|
williamcopper
Max Output Level: -68 dBFS
- Total Posts : 1120
- Joined: 2014/11/03 09:22:03
- Location: Virginia, USA
- Status: offline
Re: Slow bounce, fast bounce ...
2015/12/04 09:24:14
(permalink)
The only option not checked on my bounce dialog is "64-bit Engine" ... because I've never known what that means. Working now on some of the suggestions above: doing the same bounce twice to eliminate any unintended randomness. The fact that an audio track may bounce perfectly (or not) does not help and is not really relevant ... what I use is midi and vst instruments. One bug/feature I've noticed before is that sometimes the reverb tail of one bounce can be put at the very beginning of the next bounce ... kind of a wild effect.
post edited by williamcopper - 2015/12/04 09:36:18
|
williamcopper
Max Output Level: -68 dBFS
- Total Posts : 1120
- Joined: 2014/11/03 09:22:03
- Location: Virginia, USA
- Status: offline
Re: Slow bounce, fast bounce ...
2015/12/04 09:35:51
(permalink)
Here is very nearly the same passage, bounced twice: once with fast bounce and once with fast bounce, 64 bit engine ... as you can see, they are very close to exactly the same. So this eliminates all the comments about 'random changes in the midi or the synth'. 
|
williamcopper
Max Output Level: -68 dBFS
- Total Posts : 1120
- Joined: 2014/11/03 09:22:03
- Location: Virginia, USA
- Status: offline
Re: Slow bounce, fast bounce ...
2015/12/04 09:39:52
(permalink)
☄ Helpfulby Grumbleweed_ 2015/12/04 16:45:36
Actually as I look more closely, the audio has in fact shifted a bit as a result of changing from fast bounce to fast bounce 64 bit ... that's not good! Same sounds at different times, not exactly what's wanted either. Examining the start, there is about a 30 ms difference from the very beginning. Sure, work around work around ... use the same bounce (64 bit engine or not) all the time. But again, it's not desirable for an audio application to change timing at all without notification to the user. In musical terms, at quarter = mm120, a sixteenth note only lasts 125 ms ... so shifting by 30 ms is going to be audible and problematic, but not obvious what's wrong. And if you use a combination of bounced audio and original midi + synthesizer ... one or the other of those bounces is not going to line up perfectly. Guaranteed.
post edited by williamcopper - 2015/12/04 10:01:25
|
Beepster
Max Output Level: 0 dBFS
- Total Posts : 18001
- Joined: 2012/05/11 19:11:24
- Status: offline
Re: Slow bounce, fast bounce ...
2015/12/04 09:53:05
(permalink)
williamcopper
Here is very nearly the same passage, bounced twice: once with fast bounce and once with fast bounce, 64 bit engine ... as you can see, they are very close to exactly the same. So this eliminates all the comments about 'random changes in the midi or the synth'. It absolutely does NOT! If you want an EXACT replica when bouncing you have to freeze/bounce your synths FIRST. If you do not then the synth is creating a new performance every time you hit play and when you bounce. That will lead to possible variations in the SOUND coming from the synth due to how the synth processes the MIDI input. Will some synths perform EXACTLY the same thing EVERY time? Perhaps but without doing null tests on the INDIVIDUAL synth parts you can know. As was mentioned a lot of effects are going cause variations as well... again making it so you are not going to get an exact replica. These variations are very likely to be so slight that when you LISTEN to that material you don't hear a difference but they are there, in the wave files... which can be confirmed by zooming in and/or doing a null test. THAT is where your variations are almost certainly coming from! Why are you insisting that this is not even a possibility when you have a bunch of extremely smart and experienced people telling you it is? This is the type of crap that makes me think you just do this to make bogus "bug" claims about the software and sow dissent and confusion on the forum. Freeze ALL your tracks (synths and effects) THEN do your bounce/null tests/comparisons. Until you do that you have zero point and you are just wasting time. I am saying this not for you... but for others coming across this thread who may otherwise end up thinking there is a problem with how Sonar exports. Maybe there IS a discrepancy but you are not going to get an accurate result doing things the way you are. If there is I would personally like to know what/why/how it happens however Brundlefly says he's done the null tests and I am inclined to believe him. I've done similar stuff on a smaller scale and it nulled as well. Yeesh.
|
Beepster
Max Output Level: 0 dBFS
- Total Posts : 18001
- Joined: 2012/05/11 19:11:24
- Status: offline
Re: Slow bounce, fast bounce ...
2015/12/04 09:55:28
(permalink)
Time shift? Could have happened for a ton of pilot error reasons like a slight change in where you Now Time was placed before the export or how it was imported into your comparison program. I have NEVER gotten a time shift unless I screwed something up. Edit: Another possible reason could maybe be a syncing/clock issue with your hardware/settings.
post edited by Beepster - 2015/12/04 10:16:00
|
Bristol_Jonesey
Max Output Level: 0 dBFS
- Total Posts : 16775
- Joined: 2007/10/08 15:41:17
- Location: Bristol, UK
- Status: offline
Re: Slow bounce, fast bounce ...
2015/12/04 10:02:32
(permalink)
I think I would have noticed any sort of time shift after doing doing hundreds, if not thousands of bounces/exports/freezes with totally different parameters each time.
CbB, Platinum, 64 bit throughoutCustom built i7 3930, 32Gb RAM, 2 x 1Tb Internal HDD, 1 x 1TB system SSD (Win 7), 1 x 500Gb system SSD (Win 10), 2 x 1Tb External HDD's, Dual boot Win 7 & Win 10 64 Bit, Saffire Pro 26, ISA One, Adam P11A,
|
williamcopper
Max Output Level: -68 dBFS
- Total Posts : 1120
- Joined: 2014/11/03 09:22:03
- Location: Virginia, USA
- Status: offline
Re: Slow bounce, fast bounce ...
2015/12/04 10:06:15
(permalink)
New image showing fast bounce (64 bit engine), fast bounce, and the single sample that was playing at that moment. 
|
williamcopper
Max Output Level: -68 dBFS
- Total Posts : 1120
- Joined: 2014/11/03 09:22:03
- Location: Virginia, USA
- Status: offline
Re: Slow bounce, fast bounce ...
2015/12/04 10:14:26
(permalink)
Ok, I'm still trying to be patient. Earlier in the thread, comments said "do two fast bounces one after the other". I did it. Now you (general) say, oh, no, don't do bounces, do freezes. Ok, working on it. As to Bristol-Jonesy "I would have noticed" ... like you, I've done this thousands of times, very likely tens of thousands of times ... sometimes I think I notice a problem but it is extraordinarily difficult to identify WHAT among all the possible causes of discrepancy is wrong. One thing is certain: the end result has very very very often been not quite what I thought i was producing -- reasons are legion, including operator error naturally.
post edited by williamcopper - 2015/12/04 10:28:30
|
Beepster
Max Output Level: 0 dBFS
- Total Posts : 18001
- Joined: 2012/05/11 19:11:24
- Status: offline
Re: Slow bounce, fast bounce ...
2015/12/04 10:23:40
(permalink)
I said you have to freeze all synths and effects before doing your bounces. Others said that as well.
It is the only way to do this with any level of accuracy. Otherwise you really are just wasting your time and confusing yourself.
Now if you do it correctly and there is still a problem then you may have something going screwy somewhere because that shouldn't happen. Then it's a troubleshooting procedure.
Also... I'm pretty sure using the 64 bit double precision option will actually cause variations because it is processing the audio different. It's higher definition or something. I may be wrong on that but the main test should probably be done between Fast Bounce = On and Fast Bounce = Off and 64 bit DPE either ON or OFF for the two bounces. Don't compare the 64 bit DPE exports with the ones without it.
|
williamcopper
Max Output Level: -68 dBFS
- Total Posts : 1120
- Joined: 2014/11/03 09:22:03
- Location: Virginia, USA
- Status: offline
Re: Slow bounce, fast bounce ...
2015/12/04 10:23:49
(permalink)
I hope it's clear: these are not RR variations. I know exactly which sample is playing when, because I created the sample and the instrument that calls it. There is no variation possible except that introduced by Sonar, by Kontakt, or just possibly by my audio card, RME.
post edited by williamcopper - 2015/12/04 10:35:18
|
williamcopper
Max Output Level: -68 dBFS
- Total Posts : 1120
- Joined: 2014/11/03 09:22:03
- Location: Virginia, USA
- Status: offline
Re: Slow bounce, fast bounce ...
2015/12/04 10:32:23
(permalink)
New image includes Freeze of same material, which results in four audio output tracks; then those four tracks combined in a 'bounce to tracks', fast, 64 bit engine. It appears that the unchecked 64-bit engine fast bounce is the culprit. The "now time', the selection, the import into Samplitude in each case exactly the same. 
post edited by williamcopper - 2015/12/04 10:48:44
|
Beepster
Max Output Level: 0 dBFS
- Total Posts : 18001
- Joined: 2012/05/11 19:11:24
- Status: offline
Re: Slow bounce, fast bounce ...
2015/12/04 10:36:47
(permalink)
williamcopper
I hope it's clear: these are not RR variations. I know exactly which sample is playing when, because I created the sample and the instrument that calls it. There is no variation possible except that introduced by Sonar, by Kontakt, or just possibly by my audio card, RME.
Bounce/freeze the file. Then do your export. You have to eliminate the possibility of the Kontakt player causing the variation. It takes one click to freeze it. If your exports null then you know Sonar isn't the issue. If they don't then try doing TWO exports using the exact SAME settings to see if they null (they most definitely should). If they don't then personally I think you probably have a clock/sync problem between your hardware and Sonar. That can be fixed by support or some of the smarter folks here. Okay?
|