What Happens To The Bit-depth Of Samples In Renoise?

I just wanted to start a new thread for this because it’s been on a few peoples’ minds lately, as well as in the past, but as far as I can tell no clear answer from the dev team was provided. If it has been answered before then I certainly apologise for bringing it back up. The forum search is a bit sensitive and won’t even take queries such as “16 bit” so it was difficult to track down old threads.

Hopefully we can finally get to the bottom of this one and presumably highlight something that needs to be fixed in a future version. Maybe this belongs in the bug report section, I’m not sure, or maybe it’s just a limitation that’s somehow gone unnoticed.

Anyway, as it says in the topic: What happens to the bit-depth of samples in Renoise?

After various tests, my own opinion is: They get converted to 16-bit no matter what.

A little more background info…

When this was brought up in the past my first thoughts were simply “why would Renoise convert the sample at all… that doesn’t make sense?”. But I didn’t really dig deep enough with my testing at that time.

Recently looza and Denim both had similar questions relating to bit-depth. In the case of looza’s thread he wondered if a 16-bit sample did in fact remain 16-bit, or whether Renoise would convert it to 32-bit internally. In the case of Denim’s thread he wondered if his 24-bit samples were being converted to 16-bit internally. Naturally I got curious and had to do a few more tests of my own.

In all of my tests I took an empty .RNS file (1 pattern 64-steps in length, no samples loaded) and measured its filesize. Then I loaded a sample into the first instrument slot, saved the song and measured the new size of the .RNS file. I then subtracted the size of the empty .RNS from this new size, theoretically giving me the actual size of the sample data stored within the song.

24-bit test:
Empty .RNS filesize = 24576 bytes
24-bit sample filesize = 266240 bytes
New .RNS filesize = 204800 bytes

16-bit test:
Empty .RNS filesize = 24576 bytes
16-bit sample filesize = 180224 bytes
New .RNS filesize = 204800 bytes

8-bit test:
Empty .RNS filesize = 24576 bytes
8-bit sample filesize = 90112 bytes
New .RNS filesize = 204800 bytes

As you can clearly see, the new .RNS filesize was identical in every test. If we take the size of that new .RNS and subtract the size of the empty .RNS we get:
204800 - 24576 = 180224 bytes
The exact same size as the 16-bit sample itself, therefore my only conclusion is that Renoise is converting the sample to 16-bit internally no matter what.

Now for a slightly extreme example of why this could potentially be very bad.

Here is a 24-bit sample of a sinewave running at 440hz for 1 second. It was generated in Soundforge at -90 dB so don’t expect to hear anything, but do save the file to your machine :)

Now load this sample into Soundforge (or Audacity or a similar wave editor) and normalise it back to 100% / 0.0 dB. Here is what you’ll get:
Even though it was generated at -90 dB which is effectively silent, at 24-bit there was enough resolution to capture the sinewave no problem, allowing you to normalise it again and get a clean signal.

Now load the sample into Renoise and try the same thing. Here’s the result: … Ouch!
This happened because Renoise first converted the sample to 16-bit, greatly reducing the resolution of the sample data, effectively rendering the almost-silent sinewave as a bunch of lo-fi, bitcrushed poo. And when you amplify poo you get… loud poo!

At this point I’m wondering why Renoise even saves samples as 32-bit?

Anyway, dev team, I hope you read this and I hope it can be remedied in a future update to Renoise. I’m sure we’d all prefer our samples to remain untouched, or at the very least not downgraded to a lower bit-depth.

Please understand that this is not angry post in any way, in fact I pretty much exclusively work in 16-bit right now so I’m (hopefully) not very affected by this, but I felt that it should definitely be brought to your attention. And on the off-chance that this is somehow related to each user’s personal system configuration (though I’ve had friends test it for me and they get the same results), then I feel it should definitely be something each user is aware of.


The rns files are compressed so they are smaller when saved.

But i did a test using the file compare option and the samples are modified

c:> FC -b 24-bit-orig_sample.wav renoise_saved_sample.wav  

a small snippet from the results:

Comparing files 24-bit-orig_sample.wav and renoise_saved_sample.wav  
00000030: 01 00  
00000034: FF 00  
00000035: 4F 40  
00000038: 01 00  
0000003C: 02 00  
00000040: F7 00  
00000041: FF F0  
00000044: 03 00  
00000048: 01 00  
0000004C: 02 00  
00000050: F8 00  
00000051: BF B0  
00000054: 15 00  
00000058: 15 00  
0000005C: 08 00  
00000060: 04 00  
00000064: 69 00  
00000068: EF 00  
00000069: 3F 00  
0000006C: DF 00  
0000006D: FF 00  
00000070: BF 00  
00000071: FF 80  
00000074: 03 00  
00000078: B4 00  
00000079: FE 00  
0000007A: 5B 5A  
0000007C: 10 00  
00000080: 1F 00  
00000084: 8E 00  
00000085: FF 00  
00000086: 2F 2E  
00000088: A1 00  
00000089: 7F 00  
0000008C: D3 00  
0000008D: 7F 00  
00000090: 0F 00  
00000094: 25 00  
00000098: 02 00  
0000009C: F9 00  
0000009D: 9F 80  
000000A4: FD 00  
000000A5: 2F 20  
000000A8: F7 00  
000000A9: 6F 60  
000000AC: 02 00  
000000B4: FB 00  
000000B5: 2F 20  
000000B8: F5 00  
000000B9: FF F0  
000000BC: 03 00  
000000C0: 05 00  
000000C4: 03 00  
000000C8: FD 00  
000000C9: 7F 70  
000000CC: 03 00  
000000D0: 0E 00  
000000D4: F9 00  
000000D5: 3F 20  
000000D8: 0D 00  
000000DC: 03 00  
000000E0: E8 00  
000000E1: BF A0  
000000E4: EB 00  
000000E5: 3F 00  
000000E8: FF 00  
000000E9: BF A0  
000000EC: 13 00  
000000F0: 11 00  
000000F4: 22 00  
000000F8: 06 00  
000000FC: FE 00  
000000FD: FF E0  
00000100: 12 00  
00000104: 0E 00  
00000108: 0C 00  
0000010C: 02 00  
00000110: EF 00  
00000111: 7F 60  
00000114: 16 00  
00000118: F7 00  
00000119: DF C0  
0000011C: FC 00  
0000011D: BF A0  
00000120: FE 00  
00000121: 1F 00  
00000124: FE 00  
00000125: 5F 40  
00000128: F4 00  
00000129: BF A0  
0000012C: 08 00  
00000130: FD 00  
00000131: 3F 20  
00000134: F8 00  
00000135: DF C0  
00000138: EF 00  
00000139: 9F 80  
0000013C: 05 00  
00000140: 03 00  
00000144: EE 00  
00000145: BF A0  
00000148: F4 00  
00000149: 1F 00  
0000014C: FE 00  
0000014D: FF E0  
00000150: 0B 00  
00000154: F5 00  
00000155: 5F 40  
00000158: FD 00  
00000159: FF E0  
0000015C: 16 00  
00000160: F0 00  
00000161: BF A0  
00000164: 0A 00  
00000168: 07 00  
0000016C: 0F 00  
00000170: 09 00  
00000174: 07 00  
00000178: 09 00  
0000017C: 01 00  
00000180: F2 00  
00000181: DF C0  
00000184: FB 00  
00000185: 1F 00  
00000188: 0C 00  
0000018C: 03 00  
00000190: F2 00  
00000191: 7F 40  

If it makes any consolation, samples in the next edition are untouched because they are zip-compressed instead.

Yeah, I tried the binary comparison myself just now.

Made a 32-bit float sinewave in Soundforge as usual. Saved it out of Renoise like you suggested. Filesizes were identical and everything but the binary comparison showed clear differences.

Finally, I took a 16-bit sample into Renoise, saved it from Renoise, converted it from Renoise’s 32-bit format back to 16-bit in Soundforge, then did a binary comparison. The files were identical.

It seems to be the act of simply loading the samples into Renoise which causes the conversion though. Will this definitely be fixed in the next edition?


A: ```

Comparing files 24-bit-orig_sample.wav and RNS_NE.WAV
FC: no differences encountered

:D :D :D

Cheers, mate.

but can someone explain what happens to that very quiet sin wave sample that dblue provided?

i mean its not just compression. When i load that sample into renoise and save the file (then reopen renoise, just in case) and export that sample out of renoise and then try to normalize it in cooledit then i get the same distortion…

EDIT: i know genereted my own sample. Not that quiet as dblue but fairly quiet. I dont get that distortion in renoise but i can can clearly hear difference between sample that have gone through renoise and sample that is pure 32 bit

24-bit can store 16,777,216 possible values.
16-bit can store 65,536 possible values.

To put it another way, 24-bit can store 256 times more detail than 16-bit. In the world of audio this translates to a higher degree of accuracy in capturing the amplitude of a sample.

To (over) simplify my sinewave example, imagine that all the samples of the sinewave fall between the values 0 and 512. When we convert this to 16-bit we are forced to make the samples fit within the available range that 16-bit can handle. We do this by dividing the 24-bit values by 256 and rounding them off to the nearest available number.

0 / 256 = 0 = 0
1 / 256 = 0.00390625 = 0
2 / 256 = 0.0078125 = 0

255 / 256 = 0.99609375 = 1
256 / 256 = 1 = 1
257 / 256 = 1.00390625 = 1

510 / 256 = 1.9921875 = 2
511 / 256 = 1.99609375 = 2
512 / 256 = 2 = 2

This is quite literally a bit-crusher effect in action. The smooth curve of the sinewave gets truncated into something much more rough and lo-fi sounding. All the samples of the sinewave existed “in between” the possible values that 16-bit can handle, so they simply get rounded off in the conversion process.


yap, i know what truncating is… i meant that then renoise DOES convert all samples to 16 bit and works with them that way? so its not just a compression… But then i dont understand why it converts them back to 32 bit when exporting? its not like you will get your resolution back…

heh, sorry man. didn’t mean to explain the obvious, but you can never be too careful.

but yeah, strange behaviour.

no problem man :) lets just hope that next edition will solve that issue… i hope it wount just store sampels in untouched zip but will actually process them in 32 bit :)

Sorry, havn’t noticed this topic so far.

Yes, Renoise 1.5 saves samples into the RNS using 16 bit delta values. No matter what they used to be. We used to write 32bit floats into the rns in earlier versions, but then got reports that the filesizes of the RNS are too big. Well, at the end we (I) simply forgot this. Sorry.

This is no longer the case in the next version: There, samples will always be saved in Renoises native internal format: 32 bit float. They are anyway played back as floats, so this doesnt matter quality wise. The resulting rns files are nevertheless not much bigger than before, because they are now zipped…

ok, thanks for reply taktik! cheers ;)

jesus, i’m sloppy. didn’t notice this thread until now :)
great testwork dblue, and great news taktik!

as i’m yet not very steady on the subject digital audio theory/math,
i began to wonder if there is any point for me to continue using 24bit samples
in Renoise the way it works now? i guess not?

of course, i could reload all of my original samples in every song when the next version has been released, but i doubt that would be an entertaining process, hehe.

well, i don’t know about how important this issue has been for my listening enviroment so far,
i guess i’ll notice that when the next version is here.

i wish i dared to ask when:rolleyes:

The only point might be if Renoise truncates them from 24 to 16 more beautifully than something else? :)

Btw, with the next edition you’d probably be able to save to the new .xrns format and then only change the samples in the .zip (i.e. not having to reload everything). I’m not sure what would happen to your loop points and instrument settings though.

You would have to rename your samples manually to the file-name structure Renoise uses. Though it uses the original file-name (if sample/instrument-name is not manually changed in Renoise!) as part of it, there is also this Sample00(my_wave-file-name).wav structure.

Creating a tool to automatically replace samples in song-files is peanuts on the other hand.
Even with Visual Basic you could do this.