Rendering in Studio One (sic)

[FMN-Music]

sorry, did not read properly.
you are right, when there is no buss, timestretching, or tuning involved, the "mixdown selection" of one audio track should null indeed.

Checked it in FSP8, and the Mixdown Selection result nulls perfectly with the original. Even a meter that goes down to -300dBFS shows -infinity.

 

[darren]

Checked it in FSP8, and the Mixdown Selection result nulls perfectly with the original. Even a meter that goes down to -300dBFS shows -infinity.

Thanks - well, that is interesting! Is it the same for export stems channels/tracks (with just one audio track, no plugins)?

 

[darren]

This has been driving me mad and it's taken me a few days to track down the issue but I have finally got to the bottom of it and there seems to be a bug in v6.6. I was going to contact support and tell them but they won't care if it's been fixed in a later version so I wonder if somebody can try this (it won't take long) to see if the issue persists in later version.

The reason that the render isn't quite right is that under certain (very normal) circumstances (see below) any render is 1 sample out. And while that may not seem to be an issue then anybody who's spent time trying to get tracks to be in phase (e.g. multi-mic stuff) then 1 sample can make quite a difference. If your mixdowns don't quite sound like you expected then this could possibly be the reason why.

I'm still trying to pin down the circumstances where it happens but the easiest one to replicate is quite simple
1. Drag a wave file onto a blank project
2. Cut out a section in the middle (don't move anything, just cut it by selecting a range and double clicking the track)
3. Do a "mixdown selection" on the section you've cut out and tick import so it brings it back into the song on the next track.
4. Unmute the original track and flip phase on one of them.
5. See if they null (mine don't)

Now there are lots of other circumstances which cause this issue but I don't have a definitive list and, in some ways, it doesn't matter. What I really want to know is whether this is fixed in later versions because, if not, I'll report it as a bug to Presonus Fender.

Unhelpfully, this doesn't always cause the issue (I have no idea why) so if it does null then you may want to close that open up a new song and test again. It only takes a couple of minutes.

Much appreciated.

 

[FMN-Music]

Tried your Test, plus all the other Bounce and Mixdown Options available in FSP8, but did not get any offset with one single audio track/event.
Also there is no pop up window (anymore?), where I could tick "import" with the "mixdown selection" method. It does it by default.
In FSP8 "Import to Track" Ticks only exist in Export Mixdown or Export Stems as far as I know.

That is not to say that FSP8 has fixed something.. there might be other factors to be discovered.
Maybe something stupid like "Ignore Audio Device Timestamps" or "Sync To external Devices" somehow screws with render timing. Maybe it's the old "depends on where you start playback/render issue" or the "delayed get-back-in-sync loop playback issue" where stuff is out of sync a few seconds after a loop return that then gets shifted back in sync with a sometimes noticable click...
I'm saying all that to keep you from getting angry at me, if you update to v8 and the issue is still present for you.

 

[darren]

Thanks for testing @FMN-Music, that's really helpful. Just to confirm, you did cut out a section in the middle of the track and just did the mixdown selection on that piece?

(Sorry, I was doing so many tests that I got myself confused, mixdown selection doesn't have any options)

Don't worry about "misleading" me as I'm going to wait for the demo for v8 and I'll test it on that before updating but I have to confess I am really concerned about what this means for my mixes. There are too many variables to know exactly what impact this would have but just knowing the mixdowns may not be rendered accurately is a concern because even one sample makes a difference..

Thanks again for doing the test.

 

[FMN-Music]

It is indeed the old "depends on where you start playback/render issue"
[which is probably also connected to the "delayed get-back-in-sync loop playback issue"].

If the resulting Mixdown Selection render is on point, depends on the start of the render. Starting on grid is more often on point and off grid is more often one sample out.

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

Accept third party cookies

Was not aware that this also affects just audio.

Be aware of fluctuating Instrument Track Timing when layering with audio events

This is another classic one I nearly forgot about, but came across again today. I wanted to turn Drum Sample Instruments to Audio to save cpu and get project latency down, but recognized differences in sound afterwards, so I checked with polarity reverse and was reminded of the fact, that...

studiooneforum.com

 

[darren]

Ah, so this was a known bug but the scope of the bug was wider than people thought! I've just had a look at the other thread and I can see that this new information, i.e. that it affects pure audio tracks, may change some of the speculation around midi and clocking issues.

Thanks for much for making a video demonstrating the issue (and also saving me an update to v8 ), I guess my next question is how to make sure that this "undocumented feature" doesn't affect my mixdowns. Which is my key concern.

I'll test this myself next week but sounds like I need to make sure that all my events, including the "start" marker on the grid. Is that right?

PS I need to go and test it but I think this also affects "export stems channels/tracks" in the same way. It's not just a "mixdown selection" issue.

 

[darren]

Ok, I got another half hour of testing in and found some interesting results.

If you change snap to frames, turn snap on and then move everything around (both the event and loop start/end) then it renders perfectly. If you turn snap back to anything else and then move everything around again then it ends up 1 sample out.

I've tried going backwards and forwards and this seems to work/not work every time. You do need to move everything each time though - both the event and the loop start (or song start marker)

 

[darren]

Right, I think I've cracked it (pending some more testing).

Before you render anything, change the snap to frames, move the start point of the render whether that be the start of the loop, the song start marker (or possible the start of the event) and then everything renders perfectly. You can even change the snap to something else and do stuff but just don't move the start point of the render.

That seems to work from my initial testing but I need to put it through its paces. I have no idea why this works, and whether it solves the problem on the other thread, but this (possibly) could be the answer.

 

[darren]

Last post before I head off, here's what AI had to say about it when I asked it to explain what was happening but then challenged its very confident answer.

I wasn’t “sure” because I’d seen this exact case documented online; I was sure because the behaviour you described matches a very specific, well-known class of DAW timing problems.

Let me unpack that honestly.

---

Why I sounded confident without sources​

1. Your symptom is extremely specific​

You didn’t say “render feels off” or “things don’t line up.”
You said:

• exactly 1 sample out
• only on render
• fixed by snapping the start point
• even with no video

That combination rules out:

• plugin delay compensation bugs
• buffer size issues
• clock drift
• human error
• vague rounding “feel”

What’s left is time → sample conversion at a boundary.

---

2. “Snap to Frames” narrows the cause massively​

Frames are not musical.
Frames are not samples.
Frames are timecode units.

If snapping to timecode fixes a sample error, then the bug has to live at the time ↔ sample math layer, not:

• the audio engine
• the plugin chain
• the snap grid itself

That’s a very small box.

---

3. This class of issue exists across DAWs​

Even if Studio One hasn’t documented this exact case, the underlying problem is well known:

• Pro Tools has long-standing sub-sample / frame boundary discussions
• Nuendo has documented timecode rounding discrepancies
• Reaper users talk about 1-sample offsets when rendering regions
• Logic users hit sample misalignment when bouncing from non-zero starts

Different DAWs, same root cause:

internal timeline positions stored as time values, later quantised to samples.
So when you described the behaviour, it immediately mapped to a known failure mode, even if Studio One hasn’t publicly named it.

---

4. The “1 sample” detail is the tell​

If it were:

• random → clock/buffer
• several samples → PDC
• tempo-dependent → musical grid

But 1 sample means:

• rounding (floor vs ceil)
• conversion disagreement between playback and render engines

That’s textbook.

---

The important distinction​

You’re absolutely right about this:

There are no internet sources describing this exact workaround.
Which means:

• I wasn’t recalling a forum post
• I wasn’t quoting PreSonus
• I wasn’t repeating received wisdom

What I was doing was reasoning from engine behaviour + your empirical test, and once you said “Snap to Frames fixes it”, the explanation became effectively forced.

---

Bottom line (no hand-waving)​

• You found a real edge-case
• Studio One doesn’t document it
• The internet doesn’t name it
• But the behaviour is internally consistent and technically inevitable
• And your workaround is correct

 

[FMN-Music]

This is a rabbit hole...
I'd be interested at what frames per seconds it always worked and if different bpm changes anything.
Does another timebase like seconds or samples affect the outcome..
Does timelinear vs beatlinear change anything..?

 

[darren]

This is a rabbit hole...

Yes it is.

I'm going to be testing this week to see if, and when, it matters. My gut feel is that it probably does matter in some cases but not all.