PreAl wroteSilly question but for the sake of completion does PT and S1 real time bounce null itself out, because if it doesn't that would add to the weird.

That's a good question! I will have to check this out! Someone else in another forum also suggested just bouncing the mixes with no plugins to see what happens. I'm gonna have to try these out!

PreAl wrote

Lokeyfly wroteThe least little thing could disrupt nulling, so my guess is if several of us were to proof out the same audio & effects, same literal "test.song" file, and same settings, then all bets are off. It seems to be an effects device, but let's see. Too little to go on, me thinks.

Well as I keep repeating, I can't see how that scenario can possibly exist, when he got the Real Time render of Studio One to null out an offline bounce in Pro Tools.

He also said "And once again, it's only a single stereo file for mastering, not a full mix with multiple tracks, but just one mix down".

Exactly. That's the thing that I do not understand at all haha IF I had to guess, I would say that Pro Tools' Offline AND Real Time bounce would be identical and S1 is the issue. I won't know that until I do these tests though, so that will be interesting!

flow wrote

mikesupina wroteThanks everyone for the replies!

The plugins I'm using in this order are:

Ozone Dynamic Eq
DMG Equilibrium
SIR Standard Clip
DMG Limitless
TDR Limiter 6

All plugins are matched exactly with all parameters. There should be no issue with pan law because it's one master file mix down that I'm comparing.


But it still does not explain why an offline bounce and a real time bounce of the same file in S1 do not null, but the real time bounce of S1 and Offline bounce of PT DO null. What is happening under the hood with S1??

So, if I understand it correctly, everything nulls except the offline export in S1?
Can you PM me your song file + audio as a download link? If you don't want to send the audio file, just give me the exact specs of that file.
Have you verified whether transient samples line up exactly?

Both sessions are using a 32bit 48k mix down file, and the Pro Tools session is set to 32bit 48k. Studio One is set to 48k, however I could not find an option to set to 32bit for the project (Master and Release) section of S1, but when checking the audio setup, it says the "Process Precision" is (Single 32bit), so I assume it just takes on whatever the file is, unless I'm missing something? But I'm still not sure why you can choose the bit depth in "Record and Mix" but not in "Master and Release"?

That is because the bit depth in the template/song settings is only for recording new files.
Mix processing and bounces follow the Process Precision setting. Export obviously is set manually.

Got ya! That's good to know! So in the Projects tab, it will take on whatever sample rate the imported mix is at?

As far as samples lining up, I have not checked all of them, but I did zoom in on a sample level to match a prominent peak, and they line up perfectly.

I'm gonna do some more testing on all of this. As far as the exact specs of the file, what do you mean by that? Do you mean what is the file I'm using for this test? If so, it is a Stereo Interleaved 32bit 48k file, and the same exact one in both DAWs.

mikesupina wrote
Got ya! That's good to know! So in the Projects tab, it will take on whatever sample rate the imported mix is at?

Yes.

As far as the exact specs of the file, what do you mean by that? Do you mean what is the file I'm using for this test? If so, it is a Stereo Interleaved 32bit 48k file, and the same exact one in both DAWs.

OK. Can you PM me the project file and ideally with the source file as a download link?

Keep us updated.

Well, of course, I had to try this for myself.

1. Bounce track within Studio One to another track. Nulls with original.
2. Export Mix. The Mix doesn't null with the original track. It's only high frequencies that aren't nulling. Granted, they're not loud, but they're there.
3. Export Stem. Nulls with original.
4. Tried Export Mix again just to verify. This time it nulled.
5. Tried one more time to Export mix. Again, it nulled.

However...

I created a new project, dragged the offline mixed file into Studio One, and then dragged in the original file, they didn't null at first but then after several seconds there was a click and they nulled.

Repeated, and this time they stayed unnulled. But, I think I found the issue.

The conclusion...

I think it has to do with bringing a file into SO with automatic time-stretching enabled. When the file didn't null, I changed the original track's Inspector's Tempo Mode from Don't Follow to Timestretch, and the files nulled. However it also seems to work the other way, i.e., if the original file is set to Timestretch, setting it to Don't Follow causes the files to null.

This would explain why it nulls in Pro Tools: there's nothing wrong with the file, the problem happens during playback when you bring it into Studio One. I haven't found out whether the issue is to always have a file in Don't Follow or always in Timestretch or whatever, but that seems to be where the problem lies.

Interestingly, it's not a "permanent" problem. For example, suppose your original file is set to Don't Follow and the one you import is set to Timestretch. You can change either one to the opposite setting, and then the files null. However, if you change back to the original settings, the lack of nulling does NOT reappear. It seems that once they line up, they stay lined up no matter what you do.

I wanted to try the test with Pro Tools, but I installed the latest Pro Tools update last night and now it's unusable due to the faders and panpot settings jittering so much they're incapable of holding a position. It's no wonder I use Studio One...

Welll...I guess since no one has added to this, I probably found out what accounts for what the OP experienced.

Anderton wroteWelll...I guess since no one has added to this, I probably found out what accounts for what the OP experienced.

Good find, Craig. "Thank you!" The automatic time stretching when compared to [don't follow] looks quite revealing. That with the various comparisons you made. Seems telling as to the non null, likely due to some change or print along the timing, or alignment between null examples.

Curious, a Pro Tools [autostretch] vs [dont follow] comparison within itself might display that this is a same type of timing issue/error that is inherent in both DAW's when outputting files. That would be an interesting comparison. We could likely then leave it alone, if we're being true to creating a precise null. If not, then a fix by Presonus is needed.

I just closed my PT account, and I am no longer using PT which I'd been using for quite a number of years (since Digidesign first released it). There's nothing in it for me to use PT any longer. A same comparison with PT that you performed could prove worthwhile, perhaps by you or Presonus support.

Just me, but I don't put much stock in a null issue, but I know a lot of us are glad you posted your findings. That helps understand particular differences any of us might come across. It just may connect the dots for the OP as well. Great find!

Some of my favorite channel strip plugins such as the Plugin Alliance B_Console Amek 9099 often doesn't null at times. I think largely due to the TMT (tolorence modeling) of the plugin itself. Of course I'd eliminate that from a null check, and effects were mostly avoided here. In this case, your findings here may help the OP as they had been hearing some very audible non-null differences. They could have inadvertently made some sync or time stretch changes as well. 🤔

Very helpful on that light. Seems the OP should cross-check your findings to their original exports. It might just reveal something they had done.

P.s I avoided posting this earlier to keep your check
visible.

Oh yeah (double P.s.) I had seen in the 6.6.1 release notes under what had been fixed was this item:

* "Export Mixdown" with "Import to Track" engaged causes out-of-sync playback

I know you more than most, undoubtedly had already updated to v6.6.1 I only mention it because it seems there were some recent timing issues of sorts with export mixdown. Perhaps not precise enough?Dunno. Again, I wanted to keep your results visible. Evidently, recent timing was being tinkered with, or adjusted. It might pay to inquire about that.

Thanks again!
Regards,
James

Hmmm...I had not updated to 6.6.1 yet because I was waiting for Patch Tuesday yesterday to fix a Windows problem. It did indeed fix the problem, so now I'm going to update and try the same test again. Thanks for the heads-up!

Not exactly a new issue with time stretching applied. Noticed it a few times after detection was messed with in the patch notes. Sometimes better sometimes worse. Myself and others posted about this May 05, 2022 in the thread below. The only way round it was to remove the tempo data or use not follow to bypass the internal detection with bpm stamped files. I always have it disabled but I also phase check everything as well. More in this DAW than any other after I noticed the way it bounced some files.

I normally write and use single hits with no time stretching applied at all, I will remove the detection from the inspector if need be and it bounces or renders perfect everytime. If your making dance music or fast tempo music, loop on the fly type of person. It will rear it's ugly head more than someone that set's a tempo and works at that tempo with no stretching applied. It can turn a tight mix with supplied tempo stamped files into a slack mess if you don't check after you imprint some tracks and not others.

In defense of any DAW, you should never fully trust stamped files from any source even if that DAW's detection is 100% accurate. Not all imported data starts at 1 and is 100% in phase with each other just because it's contained in a 1bar loop, if you catch my drift. You should always check to be honest but it doesn't excuse inaccurate rendering either.

viewtopic.php?p=282840#p282840

Two years not fixing this is not acceptable and sadly this seems to be a pattern. It will not end well.

PreAl wroteTwo years not fixing this is not acceptable and sadly this seems to be a pattern. It will not end well.

I hate being that guy to be honest because sometimes you take to much flac from people for trying to do the right thing.

As for the two years it may of worked then not worked per update etc. I can't honestly say because I avoid stretching as much as possible. It's more work flow habit than anything else though. Artifact avoidence is always in the back of my mind.

I also slip and slide data under or over each other a lot, not only for phase alignment but for groove and flow to get away from that static grid sound. By the time I bounce all tracks down it's always lined up, it's like working with quantize off kind of thing.

I'm pretty sure how I first noticed it was when I used delays or reverb, they never seemed as tight as they should be. It kind of exaggerated the timing issue on the renderd file vs the original.

Anderton wroteHmmm...I had not updated to 6.6.1 yet because I was waiting for Patch Tuesday yesterday to fix a Windows problem. It did indeed fix the problem, so now I'm going to update and try the same test again. Thanks for the heads-up!

Anytime.
I'm going to follow the timestretch and vice versa portion of the null check, Craig. Then file import as well. I updated last week to ver. 6.6.1. Hopefully, I can check this tonight.
TY!

Okay, for the TL:DR; crowd, the bottom line is that it seems this is a non-issue after all.

I did a zillion tests - bounces with stretching, without stretching, different stretching algorithms, bouncing with one algorithm and playing back with a different one, offline rendering and importing back in with the same variety of stretching and non-stretching setups, etc. etc. etc. etc.

The bottom line is that most of the time everything nulled as expected. With some timestretch combinations, there was a lack of nulling at first. However, between approximately 25 and 55 seconds, the non-nulled waveforms lined up and nulled. I never encountered a situation where non-nulled copies didn't null after a minute of playback.

My theory is that time-stretching a file introduces very subtle changes compared to the original, unstretched file, but that Studio One still remembers the original file. IOW the stretching is an overlay. So, Studio One fixes the timing behind the scenes so that the stretched file lines up timing-wise with the original one. It may take several seconds for that process to be complete. But again, that's just a theory from my "I've-never-coded-anything" brain.

So yes, I experienced rare instances where files bounced online or offline didn't null. However, none of them remained unnulled after a bit of playback time.

@ Anderton.
Aha, I didn't see your response that you just posted.
Anyway, my findings also proved to be a non issue.

Brief null check I performed this afternoon.
Notes:
*I also started from your same step #1 from bouncing within Studio One as a start point.

*I'm not using effects at this time. I wanted to see if selecting [timestretch] and [do not follow] produce any differences per Studio One version. 6.6.1.

*Compare real time processing On, then Off, simply as an added check.

*When mixing down, compare"write tempo" on and off. Obviously if tempo is not altered, this wouldn't be an issue. It wasn't.

*All exports files were .raw, 24 bit, 48k.

*Just for clarity, when stemming, I only selected tracks, not channels. I was looking to target any timing issue that forces a non-null. Not a channel vs track null comparison.

Results so far: No null issues from above examples.
As of now, I see no null issues. Wavefoms weather imported from mixdown or stemmed files all nulled perfectly and waveforms all aligned and remained sample accurate from begining to end.
Some more testing in process.....

***************
Going forward I could introduce a few effect plugins. I'm going to use only Presonus plugins, and they will be EQ, and compressor additions. I'll check channel stems this time as effects would/should properly null.


Thoughts: The only way we can determine what the original poster is questioning, is to have that file, or one they can share exhibiting their issue.

Attached: All track examples (and more) each properly nulled to one another.
Hope this saves a little time, or info with further checking.
Lokeyfly

So your telling me you can't reproduce this time stretch wrong detection phase issue below, or what ever were going to call it. This was done 5 mins ago and yes it's still here two years later.

Every time studio one does a guestimate of the tempo detection and highlights it in red in the inspector, it has a chance to bounce out of phase with the original file no matter the length. If you remove the detection on the exact same file it bounces sample perfect everytime, or correct the fact S1 detects it wrong.

If the detection can't read the data properly as in it's a guess, S1 will render out of phase hence it will not null. If it won't null at this stage it won't after export because it's reading wrong then stamping the detection into the export if you ticked that option ofc. I am no expert on some of these under the hood things but it stands to reason if it can't detect perfect at the bounce to new track stage it's hardly going to fix it's self with an audio export.

It's when S1's detection flags an estimated bpm in red, it's not 100% sure so problems arise from tracks shifting out of phase upon render. If the tempo detects 100% correct and turns white in the inspector or you remove the detection guess number alltogether, the problem is solved and it will render sample perfect.

Pics Below. You can clearly see a perfect render with detection removed in the bottom image. While it's under a guestimate detection in red, it always has a chance to render incorrect, top and middle image below. The file is 150bpm in the example below, it's been detected at the wrong tempo of 152.19, hence the bounce or render will never null unless you correct it. If someone works at say 130bpm and uses 125bpm files as an example and it guestimates wrong. The render or bounce will not null because it's shifted out of phase based on the estimated tempo reading it thinks the source file is at.

It's easy to reproduce, just find a file or loop tempo stamped file that S1 flags in RED as a guess, check it detects right or wrong then bounce to new track and check the phase of both tracks. I am not trying to cast blame here or state it's wrong or the files wrong that's down to Presonus or the audio data provider.

What I am saying is ever sinse they implimented that guesstimate tempo feature where S1 highlights a files tempo reading in red, you really need check it because it has a chance to detect wrong and bounce out of phase with the original data. It never did this before they messed about with tempo detection a few years ago. The last time something like this happened was with Loopmasters files. All of a sudden after the detection was messed with the response was it's the fault of the files. The very same files some of us had sitting on our drives for 5+ years that worked fine in S1 upto that detection work they did. Cubase Reaper and Ableton detect the same file no problem so make of that what you will.

Loops on the fly drag and drop guys will have the worst of it were as write from scratch guys probably never even noticed it. That's why I stated you really need to keep an eye on the detection of imported tempo stamped files. If the Inspector has flagged up red, correct it or at least check the bounce or render against the source.

Just so people know the above doesn't bother or affect me one bit. I always check phase alignment of data as normal practice. My renders or exports are always bang on with S1 and always have been regardless of tempo detection. Like anything else you should never 100% trust any software or hardware is producing the right results just because you clicked a button and asked it to. Nothings perfect all the time so do a little checking during a coffee or something before you commit.

garyanderson5 wroteSo your telling me you can't reproduce this time stretch wrong detection phase issue below, or what ever were going to call it. This was done 5 mins ago and yes it's still here two years later.

None of the files I tested had the red tempo indicator, so maybe that's why I didn't have any issues. It's good to know that if the red appears, you need to check the file.

I still wonder what makes the non-nulled file "snap to null" after 30--60 seconds of playback, but I'm not going to spend any brain cells trying to figure it out