Rendering in Studio One (sic)

[freddiphin]

@freddiphin that's really useful and really interesting although I'm not quite sure what to think given @FMN-Music video further up the page which, if I'm understanding you correctly, came up with a different result.

Yes, that is what I'm saying. All my tests, including doing exactly what I see in that video, and BOTH the mixdowns with the altered start point of the cut, resulted in a perfectly silent playback when inverted.

 

[FMN-Music]

i'm nterested to see, if your experience changes, when you turn snap off and use render ranges, that start off grid. Also use test-songtempos other than 120bpm. Since this seems to be mathematical issue, numbers that have same denominators in the bar/beats domain as in the time domain might mask calcualation errors.


"In digital audio workstations (DAWs) and music programming, 120 BPM is the "cleanest" possible tempo.

• At 120 BPM, one beat is exactly 0.5 seconds (500ms).
• Because 120 is a multiple of 60, many subdivisions result in clean integers or simple floating-point numbers.

Using "messy" tempos like 113.7 BPM or 141 BPM forces the software to handle repeating decimals (like 0.333...) or rounding offsets. If there is a bug in how the software calculates the relationship between "Musical Time" (Bars/Beats) and "Real Time" (Seconds), a clean tempo like 120 BPM might hide it because the math "just works out" by coincidence."

 

[freddiphin]

...I did only Mixdown Selection on these with Snap On then Off, at 120 then at 113.7 BPM, varied render ranges off grid; everything nulled perfectly.

I'm not sure if I'm missing something else in what you're saying, but this seems to pan out as desired...

 

[darren]

The thing that broke it for me was moving the start point of the tracks to be mixed down or moving the loop when selecting to mixdown just the loop. If you've just cut an audio track at various points then that's not the same test. I know that's what I said in one of my earlier posts (sorry) but that was a bit inconsistent. The thing that consistently didn't work was moving the track, or moving the loop selection (without having a timebase of frames) and then rendering.

 

[FMN-Music]

ownCloud - A safe home for all your data

Render Test.7z is publicly shared

fmn-music.com

Please Download this songfile.
Select the 2nd event via right click and choose "Mixdown Selection" in the popup menu.
Invert the polarity of rendered track, and see if nulltest is successfull.
On my machine it is never.

EDIT:
use 44.1k interface samplerate

 

[AAV]

ownCloud - A safe home for all your data

Render Test.7z is publicly shared

fmn-music.com

Please Download this songfile.
Select the 2nd event via right click and choose "Mixdown Selection" in the popup menu.
Invert the polarity of rendered track, and see if nulltest is successfull.
On my machine it is never.

I downloaded the file and tried the null test. Unsuccessful here as well. But after several attempts at comparing Bounce to New Track, Mixdown selection (between your markers) to confirm whether or not the problem was relegated to just "Mixdown selection" (all gave the same result), I tried to set the audio settings back to my usual 48 khz/24 bit settings, adjusted the volume of the first track fader to avoid clipping, and redid the mixdown, and this time it nulled. I reset to 48/ 32 float, and curiously still had to adjust the volume to avoid the clip, but it also nulled. So this would suggest (I think - I'm no recording engineer) that the theories about the bpm inaccuracy are at play here and that higher sample rates might help to alleviate the problem.

 

[freddiphin]

.....I did this as well and had the same results in that simply changing the Session sample rate (did not need to adjust volume for clipping and bit depth didn't seem to matter) to 48k produced the perfect null result. ANY other sample rate had the same high frequency bleed. However, MOVING the selection as @darren mentions above caused the render to not null, and this even at 48k as well.

 

[FMN-Music]

Other samlerates just cause the locations of offset renders to move to other places in the timeline, same as BPM changes do. So if you use other samplerates than 44k for the test song, you'll end up with different results.


"The "Off-By-One" Boundary Error

When you tell a DAW to render from "Bar 5, Beat 1," the software has to translate that musical coordinate into a sample number.

As we calculated earlier, at many tempos (and samplerates), "Bar 5, Beat 1" actually sits at a fractional sample (e.g., Sample 440,100.38).

• The "Clean" Engines (Reaper/Cubase): These engines usually use a "Floating Point Timeline." They track that .38 remainder and ensure the render starts at the exact sub-sample phase.
• The "Offset" Engines (Studio Pro/Ableton): These often snap to the nearest Integer Sample. If the engine rounds down when it should have rounded up (or vice-versa), your rendered file starts exactly one sample late or early."

 

[darren]

@FMN-Music that's a really good summary of where we are at the moment. Thanks to you and everybody else on this thread for trying to get to the bottom of this.

Where did you get the clean vs offset engine information from? It certainly correlates to my testing (and yours) but is that from a different source?

Unbelievably (because I've never believed it) it appears that DAWs really do sound different. Or can do.

 

[FMN-Music]

@FMN-Music that's a really good summary of where we are at the moment. Thanks to you and everybody else on this thread for trying to get to the bottom of this.

Where did you get the clean vs offset engine information from? It certainly correlates to my testing (and yours) but is that from a different source?

Unbelievably (because I've never believed it) it appears that DAWs really do sound different. Or can do.

The text in " " is a quote from a lengthy exchange I had with Gemini AI Thinking Model.

 

[darren]

Funnily enough I had a similar answer from ChatGPT but I struggled asking for a really good source that wasn't Gearspace or something like that. I'm surprised there isn't more written about it because it's clearly true (from our observations) and also clearly important!