[BUG] Fade out / Fade in instead of autocrossfade at the end of a recorded event.

[Helidream]

There is actually a worrying bug, if i’m right, in the Nuendo record functionality.

I did talk about it inside two other threads, in the “Feature Requests and Suggestions” section of the Nuendo 8 forum.
This bug is linked, i think, to the lack of post-record buffer. I discovered it inside Nuendo 7.1.40 but i suspect it is here since a long time.

See in this example : there is no crossfade at punch out.
Punch in autocrossfade is ok, but punch out autocrossfade is wrong, it is in fact a fade out followed by a fade in !!

here :

[FR] Convert autocrossfade to crossfade to adjust record autocrossfades

and here :

[FR] Add an Audio Post-record buffer and setting

So here is the description :

When recording audio over existing material, a new event is placed over the previous one. If you are rerecording a small length over a previous longer take, then the new event is smaller that the previous underlying one, and then autocrossfades are applied at the start and end of the new event, to merge audio with the existing previous take.

Those crossfades are not viewable, but this is perfectly normal because they are in fact autocrossfades. Their length and curve preferences are determined by autocrossfade settings, at the global or track level.

The problem is located at the right autocrossfade : It should extend to the right of the right event boundary, but there is no audio material for it in the clip here (because there is no post-record buffer).

To say it differently, the last take event audio should be faded out after this event right boundary, but there is no more audio here in the clip to do that…

So actually, there is a fade out ending at the take event right boundary, then a fade in for the underlying event starting here.

So we do not have a real crossfade at the end of the take, but a fade out, followed by a fade in ! This can translate to degraded audio or audible merges specially for long autocrossfades values.


How to reproduce :

1. To hear the bug more easily, set the autocrossfade to the largest 500ms value, choose linear curves, and enable autocrossfades. (menu project, auto fades settings).

2. add a new track, and choose an input channel for it in the routing rack. record arm this track.

3. in the input channel, insert a Testgenerator plugin, and set it to 440Hz (sinus curve).

4. set record mode to “keep history”, then record about 15 seconds of this 440Hz test signal.

5. set the TestGenerator plugin to 1 KHz, and record about 5 seconds of this signal, so that the new take audio event is located approximately in the center of the previous take event.

6. listen to the result, you should have :

• about 5 seconds of 440 hz signal, then a perfect 500ms crossfade with the following 1 Khz signal, starting 500ms before the start of the 1 KHz event.

- about 10 seconds of 1 Khz signal, with a fade out starting 500ms before the end of the event followed by a fade in to the 440Hz signal.

As you can listen it, there is no crossfade here at the transition between the end of the 1 Khz signal, and the 440 Hz signal. There is instead a fade out followed by a fade in.


Probable cause :

I think that this bug is induced by the fact that there is no audio material available in the clip after we press the record button, (same problem after auto punch out).

Possible solution :

Add a post-record buffer, as described in this thread :

[FR] Add an Audio Post-record buffer and setting

And correct Nuendo code to place the take event fade out at the right place, after the right boundary, instead of before.
.

[Helidream]

.
Because this is a bug that can affect audio quality in a mix, i report my test here to show it clearly and alert the developers about the absolute necessity to correct it asap.

The test has been done inside Nuendo 8.1.10. and Nuendo 7.1.40 with exactly the same result.

For this test :

• i did set a 500ms autocrossfade in the project menu.

• I did put a 200 Hz tone signal on a track

• then i did record over it a 1 KHz signal coming from a generator connected to an analog input of the audio interface.
  
  
  Then after a mixdown, i got this (the upper part is the recorded clip over the underlying event, the lower part is the mixdown of this superposition) :

As you can see the start crossfade is ok : we get a 500 ms crossfade. But the end crossfade is a total mess. It is a 500 ms fade out followed by a 500 ms fade in !!.. Not only this is not a crossfade, but the length is two times higher than the set value !


You can listen that in the mixdown wave file :
test-record.zip (317 KB)
As i did explain in the previous post, there is not enough audio in the recorded clip to render the end crossfade at the right place. This is for sure the reason why we get a fade out + fade in.

This can be corrected adding a post-record buffer setting in Nuendo (a default value of 1 second should be ok), and correct the code to render the end autocrossfades at the right place.
.

[Helidream]

Same problem with Nuendo 8.2.

I did test with a shorter more common crossfade setting of 50 ms.


I got the same result : the end crossfade is wrong : it is a fade out followed by a fade in instead of a crossfade.


Can be easily seen in this screen capture of the punch out autocrossfade :

[Fredo]

I guess you are seeing the auto-fade.
A fade is automatically applied to each event to prevent clicks and pops.
Project/auto Fade settings


Fredo

[Helidream]

Yes this is what i did indicate at the beginning of the post :

So here is the description :

When recording audio over existing material, a new event is placed over the previous one. If you are rerecording a small length over a previous longer take, then the new event is smaller that the previous underlying one, and then autocrossfades are applied at the start and end of the new event, to merge audio with the existing previous take.

So yes this is an autocrossfade, or more exactly it should be because and it is actually not shown neither played like an autocrossfade but like a fade out followed by a fade in at the end of the recorded material. Please listen to the .wav example i did post in the first post. You will ear clearly that there is no autocrossfade at the end of the take. This example was done with a 500 ms autocrossfade setting, not very common, but i did choose this value to clearly show the problem. In the last post i did show a picture with a 50 ms crossfade, very common for recording, that exhibit exactly the same problem. So the problem i did describe first is not linked to the long autocrossfade length i did choose in the first test.


Autocrossfade or not, this does not change the problem : when a punch in / punch out recording is done with Nuendo (perhaps with Cubase too if they share the same record code, could someone test that ?), the end crossfade is wrong and affect the mix quality.

When we see the just upgraded 64 bits mix engine of Nuendo 8.2, giving extreme precision in audio processing, such a bug is a terrible thing compared to the global editing precision and audio quality we get with Nuendo.

And anyway, it’s a terrible thing from the start. I think that it did stay hided probably since years because Nuendo does not draw autocrossfades on events waveforms. You need to listen carefully with delicate audio material, or bounce the events, to clearly see it.

Another probable reason that explain why it did stay hided, is because tracking is not the strong point of Nuendo, so i think that most serious recording studios are using Protools for this task and it does have some clear advantages here like destructive recording or unlimited record buffers compared to Nuendo.

I would say that it must be corrected asap for the reputation of Yamaha and Nuendo, but not only. Tracking with Nuendo is not actually a good idea, seen as an audio quality perspective, as soon as there are tracking takes with punch ins / punch outs.

Protools does not exhibit this bug. Basic bugs like this one affecting audio quality must be tracked and corrected as a top priority.

I gave the solution in the previous post : a post-record buffer need to be added to give enough audio material at the punch out, and the code corrected to apply an autocrossfade on punch outs instead of a wrong fade out followed by a fade in.