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!

 

[soundofdrums]

I’ve just been testing this for different reasons (just checking PDC was working on one of my plugins) and I discovered exactly what you’re talking about. Whenever I render an audio file in studio pro 8, regardless of method (even stem export) I’m continually seeing an offset of 1 sample when reimported into the session. Doesn’t seem to change even if I change time base or snap or anything else you guys have suggested. Very odd…

 

[pk-1]

I’m continually seeing an offset of 1 sample when reimported into the session

I vaguely remember someone on KVR complaining very loudly about this a few weeks ago. Seems to be a known issue.

 

[darren]

Like a stone in my shoe this continues to nag away at me and I'm really trying to work out whether it really matters or if it's simply a technical peccadillo that gets lost amongst everything else that is going on.

To that end, I mixed down a song (to a WAV file with the same bit/sample rate as my Studio One session) and then re-imported it to compare it to what I was listening to. I'll confess that they both sounded the same on a casual listen but if I nulled them then there were huge differences. That really threw me because it meant that my mixdowns weren't necessarily true to what I was hearing when I was mixing.

I then did another mixdown, compared it to the first, and discovered that they two mixdowns didn't null either. Whoah! Did it a few more times and confirmed that basically every mixdown ended up a bit different.

Thinking that was the "smoking gun" I tried the same thing in Reaper (a clean engine) just to confirm that this was a Studio One issues. And .... same thing happened in Reaper where different mixdowns don't null.

This kind of shocked me but, on reflection, is probably easily explained by the fact that various plugins (esp the spatial effects) have a randomness to them which obviously doesn't get repeated every time the song is mixed down.

I'm (again) not entirely sure what conclusion to draw from this. It would be easy, and seductive, to simply conclude that the whole clean vs offset engine is a huge red herring because there are other factors at play when mixing things down which seem to have a far greater impact. But I can't say I've done enough testing to happily conclude that and put this one to bed.

On the positive side though, it appears that if you don't like your mix then you can just mix it down again and see if that one sounds better

 

[SwitchBack]

Years ago I had a living-room where the middle of the couch was like the most perfect listening position I ever had in a living-room. I could hear details in songs I thought I knew quite well yet never heard before. Something to do with the irregular shape of the room and the distance to the walls and the drapes and whatnot. Quite cool, and I never had a living-room quite like it ever since. Most people never do.

Morale: Worrying about one bit shifts and mixdowns not nulling becomes a bit moot considering the listening conditions songs are played at 99.9% of the time. OK, not 100% but still

Yet I do get the nag felt by the technically inclined. Feel it a bit meself too

 

[tulamide]

I read quite few posts of this thread, and I think, I can add my two cents to summarize it. I have some programming background, and I focus on DSP audio (and MIDI) programming. But only on an advanced hobbyist level.

The core, the heart of every DAW is the sample clock. Whatever sample rate you set your project to, that's the clock's ratio. All other rulers are computed from this. If your project is at 44.1 kHz, it counts 44100 samples for a second. It advances in integers. After sample 1 comes sample 2, etc. And time is computed from this. For example, at 44.1 kHz time has a step value of 1/44100 ≈ 0.000023s.

However, there's also a musical format to be considered. BPM and measure are a time-based format. Under specific circumstances, a musical position can be between 2 samples. But that does not influence the sample clock. 44100 samples per second are outputted sample after sample, no matter what.

We can see that in code. The tracktion engine of the Waveform DAW is open source. In order to play or render, it uses a helper function to convert time/musical time to sample position:

toSamples (TimePosition p, double sampleRate)
{
    return static_cast<int64_t> (
        (p.inSeconds() * sampleRate)
        + (p.inSeconds() >= 0.0 ? 0.5 : -0.5));
}

This simply rounds to the nearest Integer. And any task uses this to set the position. For example, in the Lagrange-Resampler in WaveNode, we find

setPosition (TimePosition t)
{
    setPosition (toSamples (t, getSampleRate()));
}

Within a DAW, the Position is always on the sample grid, even if it tells you 4/2/3 or 27,38s.

However, and that's why I explicitly chose the LagrangeResampler example, any wave file that is not in the DAW's sample rate, has to be resampled. It keeps the same starting position and length, but of course the new sample points are interpolated from the source. Very simplified example: source is at sample rate x, project is at x * 2, source will take its sample 1 as the new sample 1, then a calculated value between sample 1 and 2 as new sample 2, then sample 2 as new sample 3, then a calculated value between sample 2 and 3 as new sample 4, and so on.

This would then let any null test fail, of course, although both audio clips are technically identical, just with different resolutions. And resampling is used for a lot more than just an import sample rate conversion. Anytime, when audio is set to follow tempo, when pitch correcting, and more. The only time, any audio copy is exactly the same after rendering, is when all audio helper tools are disabled, the rate of the project matches the rate of the audio file, and the region of the copy can not be mis-rounded (that has nothing to do with the audio engine, but with the precision of the float format)

 

[SwitchBack]

Nice explanation, thanks

 

[lokeyfly]

I dither whenever I go down in Bit Depth or go from floating to fixed point. The second one happens, when you render to a 24Bit file out of the 32 or 64 Bit floating point audio engine of FSP.

But I'm pretty sure this would not make or break a null test.

Agree.

What I would have a good look at, is if there are any plugins with any kind of randomness in the song. Like some Saturation Algos, but also plugins like chorus/flanger/doubler/shifter/tapesim wow/flutter (even when timing is synced to host tempo, because Oscillators don't neccessarily start at the same point each time you render) or Dynamic EQ's sometimes don't null (like TBT Kirchoff for instance). Spectral Plugins like Gullfuss or Soothe are also candidates to look at. And of course Synth Plugins.. ALL these need to be rendered down to audio first to be able to do a meaningfull null test comparison of song exports.

The OP removed plugins and tried checking nulls (export stems, export tracks, & mixdown). on a blank song. To which only export channels nulled. I havent checked this on FSP yet, but have on SO 6 2 and all three ways null. Checking any one against another would not be a true null test because stemming track vs channel are pre vs post fader (potential change). It's likely a full mixdown wouldnt null against the other stems either. Basically, because I'm not sure of the complete surgical path FSP, or SO make. The signal routing chart performed by JPetit years back while a gallent effort, was self motivated, and not released by Presonus. So, I'm only offering that even in minimizing a true null check would require what the OP basically tried (starting from scratch), and using only a sign wave for best analytics. To see where the culprit might be.

Dithering, can largely be removed from the table, because AFAIK, or we know, wasn't introduced by the OP. Lets certainly not intruduce spectral plugins, as they've likely not been part of a null check. Ill guess!
But they're great for snake oil conversations.

It would be nice (though likely already has been checked) to hear from someone at Fender/Presonus that full nulling was checked, prior to every release. Only, doubtful we will hear that (running on blind faith). Still, it is almost a given that every DAW manufacturer does this, prior to release. SO our best bet is A/B'ing the quality of our mix. How it translates, and move on. Trust me, I'm not minimizing Darren's [OP] concern. But often nulling can lead to overly drawn out concepts when put to forum conversation. Simply go after the goods on the final output is the best course of action. Me thinks.

Enter most anyone's individual choices with FX, instruments, soft synths, and such and nulling becomes more like nonsense.

Point, One of my best channel plugins is the B_Console Amek 9099. When released, these sold at $500. It doesnt, nor ever has nulled. That's not a fault. Thats a fact. Its circuit tolerance won't allow to be nulled. It's part of the color introduced, when chasing realism. The same with Arturia V synths.TAE (true analog emulation). So, is something like that used, here? Need no answer. You get the idea. There's a million stories in the naked city. If one null checks without only a sign wave, or very good spectral analyzer, and tone generator, all bets are off.

Nulling, while ok to trust our ears (at times), should often be left to........ trusting our ears.

 

[lokeyfly]

I don't think this is academic because when I render my songs for release to the world I'm not expecting them to be different to what I'm hearing in my DAW.

Can anybody shed some light on this?

A genuine concern. It also sounds like you did the right thing by starting with a fresh song.
I'm not sure what you're archiving, but have you performed your null comparisons with a sine wave?

Also, feel free to add anything else. I trust whole heartedly, you kept the analysis very simple. Only, when you re EQ, from your source, as you best wanted to nake your archives sound best to your liking, then compared those nulls afterwords (to those only). Something as simple as an EQ that provides color, might not null. The same holds true if you added reverb (type depending). Of course, I'm leaving out the source material for clarity.

If I may, list your EQ's you used. Its even possible if it were only the Pro EQ bundled in FSP, something could be wrong. A few years back, there was a valid and verified report that the EQ when set to change quality, had an even audible difference. Not saying thats the issue. Only, pooper-scoopers come in many forms. Some work better than others.
*Which, the Pro EQ has always been excellent, and I use it often.

 

[lokeyfly]

Like a stone in my shoe this continues to nag away at me and I'm really trying to work out whether it really matters or if it's simply a technical peccadillo that gets lost amongst everything else that is going on.

To that end, I mixed down a song (to a WAV file with the same bit/sample rate as my Studio One session) and then re-imported it to compare it to what I was listening to. I'll confess that they both sounded the same on a casual listen but if I nulled them then there were huge differences. That really threw me because it meant that my mixdowns weren't necessarily true to what I was hearing when I was mixing.

I then did another mixdown, compared it to the first, and discovered that they two mixdowns didn't null either. Whoah! Did it a few more times and confirmed that basically every mixdown ended up a bit different.

Thinking that was the "smoking gun" I tried the same thing in Reaper (a clean engine) just to confirm that this was a Studio One issues. And .... same thing happened in Reaper where different mixdowns don't null.

This kind of shocked me but, on reflection, is probably easily explained by the fact that various plugins (esp the spatial effects) have a randomness to them which obviously doesn't get repeated every time the song is mixed down.

Hi darren, still at it, I see.
To my admission, I did not read every post here. Only when the subject of nulling becomes several pages long, it's worth asking, is the theory ahead of the outcome? Nulling is a fundamental check to locate something off with polarity, revealing particular frequency differences. Great on the tech bench. Only, you state that you might be questioning your ability to mix, and that is just silly. Particularly when you're not hearing a difference. I hope you're grasping the productive point here.

As a forum, people will offer what they can. Things can even get a little over zealous, like something similar being said over at Music Radar. I mean, c'mon folks. I'm glad I'm not paying for the forum backup data plan. Although, I do think the answer, and largely on your part as starting this thread, that a conclusion can be drawn. Work on your mixes, and not what you can't hear, but insist theres an issue, due to the inability to null.

In the final analysis, the many variables brought up by many, add to conversation.
Only, trying to find something so vast will inhibit stepping on home plate.