"The Rendering Bug"

[haydxn]

Okay, i don't have a description of what the rendering bug is, because i've not encountered any problems with it. Thus, i don't know how to put it into words, or exactly what it is.

I know the information is in this forum somewhere, but with so many mentions of it, it's very difficult to use the search to track it down precisely.

It would be very useful for those of us that don't quite know what is wrong to have a clear description of it, so could those that DO know please post information in here so that it is accessible and clear?

[Sorry that this may seem redundant but it's good to be tidy]

Thanks a lot guys

[cbit]

there are two.. the pitch related one that's been present since t1 is detailed here

Someone else will be better able to tell you about the 'new' one.

edit: heh, i think you already knew about that one actally

[multree]

well here is what I found out.....

I rendered some BFD tracks (I rendered them & exported them) and there have been some strange artifacts which were noticeable when compressing the shit out of them... which I need to do for the snare....

I bought TapeIt 2 and did the same job.... and there have been no artifacts.... and the BroadcastWav files are really cool

16€ was worth it....

son't know if that's the rendering bug but it sounded different and not good in the lower bits

[diverdee]

Basically when rendering very lowlevel noise e.g. the tails of long spacious reverbs are truncated.
It is at a low level & probably wont be noticeable with certain material - depends on what kind of music you are making as to whether it will have any immediately noticeable effect.

[pHz]

dont think im being too naughty here ... from our little beta-testers forum a while ago (just picked out the pertinent points so it might be disjointed) ... thanks (mostly) to beno and the ears ...

I imported a snare sample to a track, dropped the gain to -24dB, and loaded a 6 second church impulse into SIR.
Turning up the monitor gain to hear the reverb tail clearly sounds fine in real-time, and exactly the same in the 32-bit version.. but the 24 & 16-bit versions have really bad distortion.

32-bit exports are NOT ok.
I ran the same test, but dropped the snare sample to -48dB, and muted the dry signal. I exported a version at 32-bit, and recorded another using TapeIt, then opened both in Soundforge and normalised..
They are definitely NOT the same.

I've sent all the details to (mackie), and had a response.. lets hope its not too hard to fix.
I mean, Tracktion generates pristine audio in real-time, so the audio engine must be fundamentally ok.. right? It must be just some silly mistake in the way the numbers are stored..

OK, here is what I think is happening. There are two bugs.
1. The Tracktion dither is not working properly, it distorts the audio at low levels.
2. The tracktion dither is stuck on. It is always used for rendering tracks (24 bit) and for exporting (24 bit and 16 bit). At 32 bit export it is either still on and it doesn't have an effect or it is actually not on (which is what should happen). I do hear something funny still going on at 32 bit I think but I'm not convinced because I only had sony headphones and not quality monitors and it could be psychological too (I'm hearing something because I want to).

OK, just talked to Jules. This is indeed what is happening. It adds dither for anything less then 32. I suggested he add an option to disable dithering for rendering/freeze/export as a fine solution. then you can use your own dithering plug if you like.

... its definitely in hand ... but no-one (except jules ??? ) has a solid timescale ...

slainte rob

[fake_fake]

That post makes it sound like the problem isn't there if you export at 32bit. I thought I read it was there in another thread... but I will try. If it doesn't cut my reverb trails using 32bit then I can try to use an external app if there are any free ones to convert/dither to 44/16.

[fake_fake]

Hmm the reverb trails seem to be there when I export at 32bit vs 16bit. Interesting.

[fake_fake]

http://www.voxengo.com/product/r8brain/

[haydxn]

@fake - yes the first quote suggests that but the very next one points out that 32 bit is not okay.

thanks for the info rob

[fake_fake]

I can no longer tell, I've listened to these various tests for the past 10min over and over and now the 32bit sounds wrong and the 16bit sounds right. I'm completely disoriented and need to rest the ears

[haydxn]

keep going and you'll find that you've swapped over your response to pressing play/stop too - and will be comparing the silences and skipping the recordings!

[pHz]

http://www.voxengo.com/product/r8brain/

excellent choice ... its what i use anyway ...

@fake - yes the first quote suggests that but the very next one points out that 32 bit is not okay.

as benos post says ... either 32bit export kills the problem or (more likely IMHO) the problem is still there but less audible due to the greater dynamic range etc ... in real-world terms 32bit exports ought to be good for MOST purposes ...

thanks for the info rob

np ... just trying (as always) to clarify things (and also to make explicit for the naysayers that there ARE dedicated people working on identifying ... tracking down ... nullifying this stuff even though the evidence of the process isnt ALWAYS public domain - and nor should it (IMHO) be) ...

slainte rob

[fake_fake]

Yes it is difficult to hear any difference from my 32bit export and T2 playback... I think. But when I convert the 32bit export to 16bit, I hear the difference. I'm not sure if this is entirely the bug, or a combination of it with the fact that 16bit won't sound as full as 32.

[P.T.]

So, does the r8brain solve the problem?

Is this actually a dithering problem?

[fake_fake]

No r8brain doesn't solve it