Any ideas or advice?
Try bouncing the audio before you export it.
I did. No luck at all 
Export format? Export settings?
It would help to see the ruler. Maybe the original event ends before the right locator?
Those exact same setting produce a sample accurate loop for me….so maybe something in the source file or any active plugins being rendered?
@Grim Thanks for your reply, no active plugins, in the channel, or in the master bus.
I also tried with Constrain delay compensation active and inactive, with identical results.
Also VST delay compensation theshold (for recording) is set to 0ms in the preferences in order to maybe address this…
You’re probably going to have to do some troubleshooting. Some stuff I would try:
Test in new empty project with a single wav imported
Check both realtime and offline exports
Try with a different audio driver selected (or even no driver)
As I say….this works fine here so I don’t think it’s a general bug.
For me this issue happens when Quick Export is used. The resulting file is always longer than the audio contents.
Thanks @BrunoDSL Just tried it with real time export instead. Same issue…
I did have the same issue with both in a project, but after rebooting I only get the same issue with Quick Export.
Now, does your song have any tempo or time signature changes? Mine has one tempo change.
I just did a quick export of the same project I talk about in this post and Cubase for whatever reason added 30 more seconds of complete silence to the export.
For anyone interested, I had a couple of hours Chat GPT session, with step by step instructions in order to exclude possible causes and finally resolve the issue.
The link is here
When I export a two bar audio clip in Cubase and I re insert it into the project, I get a longer audio file. Not by much, but if I zoom all the way in, it can be seen as shown in the picture. What can I do to avoid that?
This usually happens because the exact sample boundaries of the exported clip don’t match the project’s grid when you re-import it. Even if it’s only a few samples longer, Cubase shows it as a slight overhang once you zoom all the way in.
Here are the most common causes and the fixes:
1. Make sure your locators are set exactly to bars/beatsBefore exporting:
Select the event.
Press P (sets left/right locators to the event boundaries).
Make sure Snap is on and set to Bars or Grid.
In the export window, enable “Import into project → Audio Track” to test.
If your selection isn’t exactly aligned to the grid, Cubase exports the exact number of samples, not bars.
2. Disable “Include Tail” in the Export WindowCubase will extend the file if “tail” is added for reverb/delay processing.
In the Export Audio Mixdown window:
Look for “Insert Effects / Channel Batch Export → Tail”
Set Tail: 0 ms or disable extra tail.
3. Check for plugins adding latencyEven if you export only one clip, any plugin delay on the channel, group, or master can cause the rendered file to have padded silence at the start or end.
Fix:
Enable Constrain Delay Compensation (clock icon).
Or temporarily bypass high-latency inserts before exporting.
4. Verify sample rate matches the projectIf your export sample rate ≠project sample rate, Cubase resamples on import, and the file length can shift slightly.
Check:
Project Setup (Shift + S) → Sample Rate
Export Window → Sample Rate
Both should match.
5. Make sure you’re exporting the event, not the cycleIf you export via cycle markers but the event doesn’t perfectly align with the cycle, you may get extra samples.
Use:
Recommended workflow that always prevents overhangSelect the audio event.
Press P.
Go to Audio → Bounce Selection (forces perfect boundaries).
Export with:
No tail
No high-latency plugins
Correct sample rate
When you re-import, it will be sample-accurate perfect length.
If you want, you can upload a screenshot of your Export Audio Mixdown settings, and I can tell you exactly which option is causing the extension.
Thanks for the screenshot — it helps a lot.
Your export settings look mostly fine, so the length issue is almost certainly coming from one of these four areas (all common in Cubase):
1. Your locators are not perfectly aligned to the eventIn the screenshot, your locators show:
Left: 8.1.1.0
Right: 10.1.1.0
That should be exactly 2 bars — but only if the event itself starts and ends perfectly on those grid points.
If the event is even a few samples off-grid, Cubase will still export the full locator range, not the exact event length.
This produces exactly the overhang you saw in your first screenshot.
Before exporting:
Select the audio event.
Press P (sets locators to exact event edges).
Then export.
Or even better:
Select event → Audio → Bounce Selection
This forces the clip to snap perfectly to the grid.
2. You’re exporting from “Stereo Out” with EffectsThis means Cubase is rendering the entire mix path, including:
group bus latency
inserted plugins (even hidden ones!)
master bus latency compensation
Even a tiny amount of plugin latency can cause a rendered file to be padded slightly at the beginning or the end — especially when you export a small loop.
In the Effects dropdown:
Also try this:
It’s the small clock icon on the top toolbar.
This disables high-latency plugins so the render stays sample-accurate.
3. “Insert and Strip” sometimes adds render-paddingEven with no tail selected, Cubase sometimes adds a few samples at the end for strip modules (gate, comp, limiter) because these have look-ahead or release times.
If this track does NOT need channel strip processing:
Switch Effects → “No Effects” or “Dry”
Then export again.
4. Your sample rate matches (good), but check this hidden settingGo to:
Studio → Audio Connections → Outputs
Make sure:
No Control Room plugins
No bus inserts
No post-fader FX
These also cause rendering padding.
Fastest workflow that always gives perfect-length loopsIf you’re exporting small musical loops (2 bars, 4 bars, etc.) use this workflow:
Select the audio event
Press P
Audio → Bounce Selection
(forces perfect start/end samples)
Export using:
Channel Selection → The track itself (not Stereo Out)
Effects → Dry
No latency plugins on the path
Re-import: It will be sample perfect.
Just upload a screenshot of:
The channel strip for the guitar track
The stereo out inserts
Any group bus it is routed through
One of these is almost certainly adding a few samples of look-ahead or release time, causing the file to be slightly longer.
I used your suggested settings Fastest workflow that always gives perfect-length loops If you’re exporting small musical loops (2 bars, 4 bars, etc.) use this workflow: Select the audio event Press P Audio → Bounce Selection (forces perfect start/end samples) Export using: Channel Selection → The track itself (not Stereo Out) Effects → Dry No latency plugins on the path Still the same problem
Thanks for testing those steps — since the problem still happens even after a Bounce Selection and after exporting Dry, that tells us something important:
The issue is NOT coming from plugins, not from the Stereo Out, and not from misaligned event boundaries.
So we narrow it down to the only remaining causes that can create a few extra samples in Cubase:
THE REAL CAUSE (99% likely): Your project’s timebase is NOT sample-accurate at the bar boundaryIn Cubase, the bar grid is NOT always sample-perfect unless the tempo is set so that 1 bar equals an exact integer number of samples.
This means:
Your event looks like it ends at 10.1.1.0
But in samples, Cubase’s bar grid often lands slightly between sample positions.
When Cubase bounces or exports, it must round to the nearest sample
Result: the exported file is a tiny bit longer (usually 1–20 samples)
This is why you only see it when zoomed in all the way.
And this is why Bounce Selection + Dry Export didn’t fix it — because Cubase still snaps to the nearest sample boundary.
This happens most often with:
170 BPM
44.1 kHz sample rate (unlikely to line up perfectly with musical bar lengths)
And your screenshot shows 170 BPM, and you export at 44.1 kHz — that combination guarantees bar → sample mismatch.
This is the same well-known issue Pro Tools, Ableton, Logic, FL, and Cubase all have:
DAWs cannot place a bar EXACTLY on a sample boundary unless tempo + sample rate align mathematically.
THE FIX THAT ALWAYS WORKS48 kHz aligns much more cleanly with common tempos.
Your 2-bar exports will import sample-perfect.
Example:
120 BPM at 44.1 kHz works perfectly
Many odd tempos (like 170) do not
You can test this:
Switch project temporarily to 48 kHz
Bounce again
Export → Import
You’ll see the length is now exact.
Quick test to confirm this:In Cubase, go to:
Audio → Statistics
Select your exported file.
Check the sample length.
Now compare:
Expected sample length = (bars Ă— 60 Ă— sampleRate Ă— 4) / tempo
You will see it’s not an integer — Cubase must round.
What most producers doLoop creators and sample pack makers almost always:
Work in 48 kHz
Use Bounce Selection for loop boundaries
Never worry about a few extra samples because samplers use grid sync, not sample length
Final confirmationIf you want, tell me:
Your exact tempo
Your sample rate
The bar length you are bouncing
And I can show you the mathematical reason your bar length cannot land on a perfect sample boundary.
Would you like me to calculate it?
I am rendering 2 bars at 170 BPM Sample rate 48kHz 24 bit
Great — now that you’re using 170 BPM, 2 bars, 48 kHz, we can check mathematically whether a 2-bar region can land exactly on a sample boundary.
Here’s the calculation:
Step 1 — Length of 1 beat
1 beat = 60 / BPM
= 60 / 170
= 0.35294117647 seconds
2 bars = 8 Ă— (60/170)
= 8 Ă— 0.35294117647
= 2.82352941176 seconds
Samples = time Ă— sample_rate
= 2.82352941176 Ă— 48000
= 135,529.411… samples
Problem: 135,529.411… is NOT an integerAnd Cubase can only place audio events on whole-number sample positions, like:
135,529 samples
OR 135,530 samples
The grid line for “bar 10.1.1.0” at 170 BPM simply does not fall on an exact sample at 48 kHz.
So Cubase is forced to round up or down by a fraction of a millisecond.
That rounding creates exactly the tiny overhang you see when zoomed in.
This issue cannot be fixed because it is a mathematical limitation — the bar length at this tempo + sample rate does not divide evenly into samples.
In other words:Your 2-bar clip at 170 BPM cannot ever be exactly sample-accurate at 48 kHz.
Not in Cubase.
Not in any DAW.
Not at any export settings.
Your export must end up a few samples longer or shorter.
What you can do instead (real-world fixes)Use Audio → Bounce Selection
→ then Turn on “Musical Mode” in the Pool
This tells Cubase “this is 2 bars” even if the sample length doesn’t match perfectly.
Groove Agent, Kontakt, Cubase Sampler Track, Ableton, etc.
They ignore micro-sample mismatches.
Pick a tempo that divides evenly into your sample rate.
At 48 kHz, these BPM values give sample-perfect 2-bar loops:
120 BPM
96 BPM
160 BPM
192 BPM
(and many others)
170 BPM is not one of them.
Still not perfect at 170 BPM, but the rounding error becomes much smaller.
SummaryYour export is longer by a few samples because 170 BPM does not map cleanly to the 48 kHz sampling grid.
This is normal, unavoidable, and happens in every DAW.
Nothing is wrong with your settings.
If you want, I can calculate which tempos at 48 kHz produce perfect loop lengths, so you can choose compatible values.
ChatGPT can make mistakes. Check important info.
Please post the resolution here, so that also folks who don’t care to engage with a notoriously lying chatbot can read it.
TDLR: File is sample accurate….problem is that the bar line at 170bpm 48k doesn’t fall exactly on a sample…..which is why my test at the default 120bpm couldn’t reproduce.
I had to resample the whole project to 48/24.
Also change the tempo from 170 to 160
Except when I had the issue, I did an export of the exact same project using version 14 and there was no issue. It was only then that I stopped having the issue with Export Audio Mixdown, although it still persists on Quick Export.
I tried with 14 as well.
Same issues
We’re talking about a fraction of a sample difference here and its expected behaviour across all DAWs. Your issue is not connected.
Your issue looks like a bug….but looks like you found the workaround at least?