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 !!

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).

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 !

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.