[6.47] MP3 Render bug - very slow rate (FIXED)

[PhotoDoc05]

Ran into this bug the first time I tried to render an mp3 file after upgrade to 6.47
No changes were made from 6.46 --- using Win10 x64 with latest updates (Feb. 9)

A file will render into the correct folder, but playback sounds stretched out very slow. The time indicator for playback shows 2:48 in 6.47. If I reinstall 6.46, the render works perfectly as it has in the past, and the file time is 1:24 and plays back at normal speed. Never had this happen before in any other previous versions.

Using Audient ID14 interface, 96,000 sample rate, 128 samples.

[schwa]

[edit] fixing, thanks for the report!

[schwa]

This should be fixed in the current prerelease builds. It would help us out if you could try it out.

https://forum.cockos.com/forumdisplay.php?f=37

[PhotoDoc05]

Thanks Schwa, that was fast, and it is fixed! ;o)

[BartR]

yes, it doesn't happen to me, but it happened right now to a client of me.
The only one difference between my installation and his one, is that he is using RØDE RØDECaster Pro, and I use the UMC1820.

Settings are identical.
But to him, MP3s are sounding stretched.

[schwa]

The bug occurs when rendering to mp3 using a sample rate higher than mp3 supports, for example 96kHz. The bug is fixed for REAPER 6.48 which should be released in the next day or so. The workaround is to make sure the render sample rate is 48k or less when rendering to mp3.

[BartR]

Originally Posted by schwa

The bug occurs when rendering to mp3 using a sample rate higher than mp3 supports, for example 96kHz. The bug is fixed for REAPER 6.48 which should be released in the next day or so. The workaround is to make sure the render sample rate is 48k or less when rendering to mp3.

yes I read it and I'm happy it's solved on 6.48.I informed him some minute ago.

Although both we have the same settings: rendering at 96kHz.
On my case it renders MP3 correctly.
On his case, the bug executes.

In this moment, for his needs, I suggested to go back to 6.46 and to wait for the 6.48 :-)

[schwa]

Doesn't matter since it's fixed, but I think the bug only arises if not already resampling.

[BartR]

Originally Posted by schwa

Doesn't matter since it's fixed, but I think the bug only arises if not already resampling.

I would like just to tell you the conditions of both: me and him:

Identical OS (WIN 11 64bit)
Identical project template (I have made it for both, months ago)
Identical track-template (I have also made this for both, months ago)
identical project Sample-Rate (96 kHz)
Identical bit depth: 24 bit

Differences, interfaces:
On his case Rodecaster Pro
On my case UMC 1820

Both we recorded audio from a mic connected to the interface.
And in another track we had some music from an external file as backtrack, ducked by reaComp

Exporting the MP3 with same settings:
LAME 320kb/s top quality (Slow)

I didn't get any issue
He got the stretched audio

Fortunately, searching, I found this topic and the 6.48-RC1 where this issue has been tackled and solved.
I just wanted to highlight that not always this issue was triggered by just resampling.

I already informed him to update to teh 6.48 as soon as will be released :-)