Just a thought Ledger (although you’ve probably already taken this into account), is when you set say the song options headroom to -6dB and you render to a sample (Ctrl Alt R), with the resulting sample you get back, Renoise automatically switches the volume up by 6dB in the sample properties. When you are at 0dB in the song options headroom setting, the resulting rendered sample volume is 0dB in the sample properties.
I suppose if you now render to sample (via a script) and your song options are at -6dB of headroom, the resulting sample will be a -6dB quieter sample. When you manually load in the sample into Renoise, the chances are the sample volume in the properties will be set at 0dB (not +6dB as if you’ve just clicked Render to Sample.) Don’t know if it will help any or not
@4tey thanks for the info, I wasn’t aware of that, but I’ve checked this now and even eliminating it, the problem still seems to crop up
I am wondering if it has something to do with auto master reduction on loud samples, though I`m not sure.
@ffx this is happening frustratingly sporadically, and with different dB reductions. I will post up a song when I get a consistant exmple.
In mean time here is an Lua render snippet I am using for testing:
---------------------
local song = renoise.song()
--create a temporary os file to make the render
local file_path = os.tmpname("wav")
---------------------------------
function post_render_callback()
---------------------------------
local song = renoise.song()
--create new instrument
local new_inst = song:insert_instrument_at(#song.instruments+1)
--select the new instrument
renoise.song().selected_instrument_index = #song.instruments
--insert a new empty sample in the new instrument
new_inst:insert_sample_at(1)
--load rendered file into new slot
new_inst.samples[1].sample_buffer:load_from(file_path)
--name new instrument
new_inst.name = "New Render"
--add a c-4 of new instrument to track 2
song:pattern(1):track(2):line(1):note_column(1).note_string = "C-4"
song:pattern(1):track(2):line(1):note_column(1).instrument_value = song.selected_instrument_index - 1
end
--render (to continue the function without crashing, we need to complete the rest
--of the code in the callback function: continue_post_render())
song:render({},file_path,post_render_callback)
Now this isn’t really to do with your above problem, but I am just curious about something to do with rendering out samples. Could you load in the attached simple xrns for me, make sure your audio preferences sample rate is 44100Hz. Then could you render out track 01 to a new sample (i.e. right mouse button, Track->Render To Sample in the menu.) You should have a rendered instrument of that track in the next instrument slot.
Now here’s the thing I was wondering about… If you save out instrument 0 sample as a wav file, and you save out instrument 1 sample (the just rendered version) as a wav file from the sample editor, should those two wav files be binary byte for byte identical?
If you save out the rendered wav, could you attach it to a post?
Thanks Ledger. Hmm, nope not identical from the original here. Difference in math (rounding error) between Linux and Windows version maybe
Finally to show what happens to a sample when you keep rendering the rendered sample out, you can flick between instrument 0 and 1 in the sample editor of this attached song. Instrument 0 is the original, instrument 1 is a render of a render of a render…about 1500 times over of the original clap sample. Watch your math libraries/results
Ledger maybe it actually is your metering tool altering volume ?
Not sure what`s going on to be honest, I tried again just now, with and without VUMT and there were no peak differeces. Fortunately when the differences do occur they are not huge so I can just get on with the tool if I account for song headroom.
Thanks Ledger. Hmm, nope not identical from the original here. Difference in math between Linux and Windows version maybe
Yes maybe, also I did make sure to follow your instructions using the right-click menu to engage the render.