• SONAR
  • Slow bounce, fast bounce ... (p.3)
2015/12/04 09:39:52
williamcopper
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.
2015/12/04 09:53:05
Beepster
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.
2015/12/04 09:55:28
Beepster
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.
 
2015/12/04 10:02:32
Bristol_Jonesey
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.
2015/12/04 10:06:15
williamcopper
New image showing fast bounce (64 bit engine), fast bounce, and the single sample that was playing at that moment.
 

2015/12/04 10:14:26
williamcopper
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. 
2015/12/04 10:23:40
Beepster
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.
2015/12/04 10:23:49
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.     
2015/12/04 10:32:23
williamcopper
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. 
 

2015/12/04 10:36:47
Beepster
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?
© 2026 APG vNext Commercial Version 5.1

Use My Existing Forum Account

Use My Social Media Account