7.37: Rendered file is 1 sample too short (FIXED)

Paul Eye · 05-02-2025, 09:41 AM

As the title says: render a project in 7.37 and the resulting file is 1 sample too short. No special circumstances needed as far as I can tell; I rendered a simple nulltest project with 2 files/tracks and no plugins, 44.1kHz, length 13:31.000 (35 765 100 samples), rendered file is 13:30.999 (35 765 099 samples). See attached image for render settings.
I also did a test render of a project last rendered from 7.35 (correct length exactly 4:40.000, 48kHz with a few plugins) and it comes out 1 sample too short rendered from 7.37.

Also what makes no sense is that Reaper's media explorer shows the length of these 2 rendered wav files as 13:30.1000 and 4:39.1000 respectively (project lengths in media explorer are 13:31.000 and 4:40.000 as expected). So I did another quick test: put some random music file on a track, length 8:17.857 (23 897 143 samples @ 48kHz), render that to a new file, wav also 1 sample too short but media explorer shows length as 8:17.587 as expected.

Reaper and windows 10 both 64-bit (if that matters).

EDIT: rendering bug fixed in 7.38, media explorer bug fixed in v7.38+dev0504 (although I didn't test this as I tend to stay away from dev versions, but I'll take Justin's word for it)

Justin · 05-02-2025, 10:09 AM

Thanks, fixing!

Paul Eye · 05-03-2025, 12:23 AM

So the rendering length was fixed in 7.38, thanks for that. The Reaper media explorer however still shows that one 1 sample too short file length as 4:39.1000 as opposed to the expected 4:39.999. Media item source properties correctly displays 4:39.999, so something wonky is going on with the media explorer when the media length is just below an even number of seconds (no idea how many versions back it has been doing this however).

Justin · 05-03-2025, 02:24 AM

Quote:

Originally Posted by Paul Eye

So the rendering length was fixed in 7.38, thanks for that. The Reaper media explorer however still shows that one 1 sample too short file length as 4:39.1000 as opposed to the expected 4:39.999. Media item source properties correctly displays 4:39.999, so something wonky is going on with the media explorer when the media length is just below an even number of seconds (no idea how many versions back it has been doing this however).

ah yes thanks, fixing!

Ralph CC · 05-06-2025, 12:02 PM

Hi,
in v7.38 I'm still getting 1 sample shorter renders with long (i.e. >40 minutes) projects, when the Normalize function is switched on. If I switch Normalize off, the rendered length is okay. This is reproducible every time.

Justin · 05-06-2025, 12:21 PM

Quote:

Originally Posted by Ralph CC

Hi,
in v7.38 I'm still getting 1 sample shorter renders with long (i.e. >40 minutes) projects, when the Normalize function is switched on. If I switch Normalize off, the rendered length is okay. This is reproducible every time.

ah thanks (again, lol), fixing this one too!

RJHollins · 05-08-2025, 09:25 AM

Just for clarity ... and there is reason for asking.

Is this a new bug [that was addressed] ... or something that may have existed
in Reaper v6 ?

Thanks for clarification.

schwa · 05-08-2025, 09:29 AM

These 1-sample render length rounding issues were introduced in 7.37, were fixed in 7.38 except when normalizing, and should be totally fixed in the upcoming 7.39.

RJHollins · 05-08-2025, 10:46 AM

Quote:

Originally Posted by schwa

These 1-sample render length rounding issues were introduced in 7.37, were fixed in 7.38 except when normalizing, and should be totally fixed in the upcoming 7.39.

Thanks Schwa.

Though this may not be the proper thread ... if I may ...

I'm still on v6.83 [Window 10]

When Rendering or Freezing a Track within a REGION bound ... I'm finding that the
Audio File rendered is extending beyond the original Region bound.

In fact, it seems the Audio has actually shifted to the Left ... slowly cutting off the Intro.

The only workaround has been to disable the Anticipatory function in options when Rendering or Freezing.

I don't know exactly when this issue started ... but wanted to bring to attention this issue.

Thanks for taking the time on this matter.

D_Guen · 07-23-2025, 01:06 PM

Hi there, I found that same bug on v7.41 and 7.42 by using the freezing, the glueing, and the rendering, with or without normalizing, in full speed offline mode as well as realtime render mode. I just can't render a single loop since it'll always click due to a missing sample.
(I was getting nuts but glad it's not just me :'D...)
I hope 7.43 is the one :3

Justin · 07-23-2025, 02:57 PM

Quote:

Originally Posted by D_Guen

Hi there, I found that same bug on v7.41 and 7.42 by using the freezing, the glueing, and the rendering, with or without normalizing, in full speed offline mode as well as realtime render mode. I just can't render a single loop since it'll always click due to a missing sample.
(I was getting nuts but glad it's not just me :'D...)
I hope 7.43 is the one :3

Can you post a minimal test project and reaper.ini that demonstrates this? Thanks!

D_Guen · 07-24-2025, 12:28 AM

Hi Justin,
Here is one simple example in v7.42 on windows 10 (see gif and reaper files attached):
Step 1: insert a click source on a track
Step 2: glue it --> it's shorter than the original size (in here 2 bars at 47 BPM)

Something else important:
It does not occur with every type of files I noticed. I had no problem importing a simple wav file and glueing it, it kept the same size...
It is mainly occuring when trying to glue frozen assets (from third parties synthesizer plugins or kontakt libraries for example).
Thanks in advance!

schwa · 07-24-2025, 02:59 AM

Thanks for posting a project. I'm not seeing a bug here. The time selection is about 245106.4 samples long at 48k, so gluing correctly results in an file that is 0.4 samples shorter than the time selection. One way to avoid the problem would be to enable "snap to project sample rate" in snap settings.

D_Guen · 07-24-2025, 04:25 AM

Hi schwa,

I just tried to change the snap settings as you proposed and the problem persists: the file is not the same length as the time selection after rendering, or glueing the item within the time selection.
(If I use a loop that's 1 sample too short and I duplicate it several time one next to each other, it's unavoidable that after a while i'll be off tempo)

I guess I should post a link to a video capture of my session since it's complicated to export it (external vsts)...in the meantime let me know if you have any other ideas.

schwa · 07-24-2025, 05:34 AM

Did you make sure to edit the time selection after enabling snap to sample rate?

D_Guen · 07-25-2025, 04:25 AM

Hello again,
I wanted to attach a new reaper session but eventhough i compressed it it's apparently too big, so here's a link from google drive:
https://drive.google.com/file/d/1DRm...usp=drive_link

It is a practical example of the glueing bug, listen to every track separately
at the time selection in repeat mode:

Track 1: there is a stem longer than the time selection, looping seemlessly
in repeat mode within the bounds of the time selection

Track 2: a copy of 1, with this time a trimmed item, still loops perfectly

Track 3: a copy of 2 that has been glued: the file has been altered during
the glueing process and has shifted to the left, the loop doesn't sound seemless
anymore and has a popping sound --> This is the bug, a glued sound shouldn't
sound different from its original.

Track 4: a copy of 3, that has manually been dragged to the right (alt+drag offset)
again (from one sample): the loop works magically again...

I hope this helps, feel free to try to reproduce these steps from track 1, the fix of step 4 should be automatic and not be done manually everytime...

Thanks a lot for checking this out, I really appreciate it!

(been a Reaper user for 10 years, this is really the first time I had any real problem)

schwa · 07-25-2025, 06:39 AM

Thanks for posting the project. The issue does not have to do with rendering or gluing; it has to do with playing back a time selection that is a partial number of samples long, and the behavior you are describing exists in all version of REAPER as far as I can tell, tested back to version 6. We're thinking about possible ways to improve this.

RJHollins · 07-25-2025, 10:16 AM

Quote:

Originally Posted by schwa

Thanks for posting the project. The issue does not have to do with rendering or gluing; it has to do with playing back a time selection that is a partial number of samples long, and the behavior you are describing exists in all version of REAPER as far as I can tell, tested back to version 6. We're thinking about possible ways to improve this.

Is that the possible reason when, Rendering to Time Selection [or Freezing], that the ITEM length changes ?

If so ... I Master Projects that the Client specifically states that the File INTRO and Ending are NOT to be changed from the original.

D_Guen · 07-27-2025, 11:24 PM

Quote:

Originally Posted by schwa

Thanks for posting the project. The issue does not have to do with rendering or gluing; it has to do with playing back a time selection that is a partial number of samples long, and the behavior you are describing exists in all version of REAPER as far as I can tell, tested back to version 6. We're thinking about possible ways to improve this.

Hello again,

Does that mean that I should only choose my project tempo based on that issue? :c
Btw so far my only solution has been to freeze the asset to a longer version so that i can get an entire number of samples, then export it again. But it's not the size of my bar...

schwa · 07-28-2025, 04:38 AM

One thing that will help your situation is to open File > Project Settings and set the project sample rate. Your project has snap to sample enabled, but snap to sample only works if the project sample rate is also set. You'll then have to adjust the time selection slightly, but if the unglued item then loops without a click, then the glued item should as well.

Upcoming REAPER pre-release builds will improve the behavior in two ways: respecting snap to sample even if the project sample rate is not set, by snapping to the device sample rate, and by fixing a longstanding bug where a fractional sample interaction between the loop length and the media item source length can cause a zero sample to be rendered.

05-06-2025, 12:02 PM	#5
Ralph CC Human being with feelings Join Date: Apr 2020 Posts: 1	Still not bug-free Hi, in v7.38 I'm still getting 1 sample shorter renders with long (i.e. >40 minutes) projects, when the Normalize function is switched on. If I switch Normalize off, the rendered length is okay. This is reproducible every time.

07-23-2025, 01:06 PM	#10
D_Guen Human being with feelings Join Date: Mar 2025 Posts: 5	1 sample too short in v7.41 and 7.42 Hi there, I found that same bug on v7.41 and 7.42 by using the freezing, the glueing, and the rendering, with or without normalizing, in full speed offline mode as well as realtime render mode. I just can't render a single loop since it'll always click due to a missing sample. (I was getting nuts but glad it's not just me :'D...) I hope 7.43 is the one :3

07-25-2025, 04:25 AM	#16
D_Guen Human being with feelings Join Date: Mar 2025 Posts: 5	Hello again, I wanted to attach a new reaper session but eventhough i compressed it it's apparently too big, so here's a link from google drive: https://drive.google.com/file/d/1DRm...usp=drive_link It is a practical example of the glueing bug, listen to every track separately at the time selection in repeat mode: Track 1: there is a stem longer than the time selection, looping seemlessly in repeat mode within the bounds of the time selection Track 2: a copy of 1, with this time a trimmed item, still loops perfectly Track 3: a copy of 2 that has been glued: the file has been altered during the glueing process and has shifted to the left, the loop doesn't sound seemless anymore and has a popping sound --> This is the bug, a glued sound shouldn't sound different from its original. Track 4: a copy of 3, that has manually been dragged to the right (alt+drag offset) again (from one sample): the loop works magically again... I hope this helps, feel free to try to reproduce these steps from track 1, the fix of step 4 should be automatic and not be done manually everytime... Thanks a lot for checking this out, I really appreciate it! (been a Reaper user for 10 years, this is really the first time I had any real problem) Last edited by D_Guen; 07-25-2025 at 04:27 AM. Reason: (better version of the compressed folder link, i had accidentally put a rar in a zip before)

07-25-2025, 06:39 AM	#17
schwa Administrator Join Date: Mar 2007 Location: NY Posts: 17,799	Thanks for posting the project. The issue does not have to do with rendering or gluing; it has to do with playing back a time selection that is a partial number of samples long, and the behavior you are describing exists in all version of REAPER as far as I can tell, tested back to version 6. We're thinking about possible ways to improve this. Last edited by schwa; 07-25-2025 at 08:19 AM.

05-02-2025, 10:09 AM	#2
Justin Administrator Join Date: Jan 2005 Location: NYC Posts: 16,799	Thanks, fixing!

05-03-2025, 12:23 AM	#3
Paul Eye Human being with feelings Join Date: Feb 2006 Location: Helsinki, Finland Posts: 324	So the rendering length was fixed in 7.38, thanks for that. The Reaper media explorer however still shows that one 1 sample too short file length as 4:39.1000 as opposed to the expected 4:39.999. Media item source properties correctly displays 4:39.999, so something wonky is going on with the media explorer when the media length is just below an even number of seconds (no idea how many versions back it has been doing this however).

05-08-2025, 09:25 AM	#7
RJHollins Human being with feelings Join Date: Dec 2011 Posts: 2,328	Just for clarity ... and there is reason for asking. Is this a new bug [that was addressed] ... or something that may have existed in Reaper v6 ? Thanks for clarification.

05-08-2025, 09:29 AM	#8
schwa Administrator Join Date: Mar 2007 Location: NY Posts: 17,799	These 1-sample render length rounding issues were introduced in 7.37, were fixed in 7.38 except when normalizing, and should be totally fixed in the upcoming 7.39.

07-24-2025, 02:59 AM	#13
schwa Administrator Join Date: Mar 2007 Location: NY Posts: 17,799	Thanks for posting a project. I'm not seeing a bug here. The time selection is about 245106.4 samples long at 48k, so gluing correctly results in an file that is 0.4 samples shorter than the time selection. One way to avoid the problem would be to enable "snap to project sample rate" in snap settings.

07-24-2025, 04:25 AM	#14
D_Guen Human being with feelings Join Date: Mar 2025 Posts: 5	Hi schwa, I just tried to change the snap settings as you proposed and the problem persists: the file is not the same length as the time selection after rendering, or glueing the item within the time selection. (If I use a loop that's 1 sample too short and I duplicate it several time one next to each other, it's unavoidable that after a while i'll be off tempo) I guess I should post a link to a video capture of my session since it's complicated to export it (external vsts)...in the meantime let me know if you have any other ideas.

07-24-2025, 05:34 AM	#15
schwa Administrator Join Date: Mar 2007 Location: NY Posts: 17,799	Did you make sure to edit the time selection after enabling snap to sample rate?

07-28-2025, 04:38 AM	#20
schwa Administrator Join Date: Mar 2007 Location: NY Posts: 17,799	One thing that will help your situation is to open File > Project Settings and set the project sample rate. Your project has snap to sample enabled, but snap to sample only works if the project sample rate is also set. You'll then have to adjust the time selection slightly, but if the unglued item then loops without a click, then the glued item should as well. Upcoming REAPER pre-release builds will improve the behavior in two ways: respecting snap to sample even if the project sample rate is not set, by snapping to the device sample rate, and by fixing a longstanding bug where a fractional sample interaction between the loop length and the media item source length can cause a zero sample to be rendered.