Recorded file longer than the record range?

Hello,

Set Left and Right locator range to the exact length you want your recorded file to be.
Arm auto punch-in and auto punch-out. Arm record on your track. Record your track/file.

The resulting Event displays and plays back exactly the length of your locator’s range which is good.
The actual file ends 1,857 samples (44.1K) later and starts 1 sample earlier. Longer than the Locator range, which is very BAD.

This is a problem. When we send a guide file to a client and tell them to send back their overdub files that match the exact length of the guide track, It needs to be exact. Not to mention other reasons like supplying final mixes to video editors that need to match their source guide files. This was never an issue in N4 and earlier.

I have searched preferences and audio device settings and see no preference settings, 0 pre-record, post-record and all.

Any ideas to correct this? Something new in N5 I’ve missed? This can’t be right. Bug or feature?

Nuendo is great
Fox

I always bounce the file after it’s recorded if I’m going to be sharing files; this ensures the proper length. Of course, I have audio pre-record on, so it’s understandable that MY punch in/out files would be longer than visually represented in the project.

Have you tried bouncing?

Chewy

1 sample early is not a problem at all (unless you meant frame). If you’re worried about it export your mixes with a 2 beep on them and have your clients give you back files with a 2 beep as well. I think there were similar issues in N4 but its never caused me any problems.

I’ll run some tests on this…

Being able to simply supply an audio file you pull out the pool is great for workflow… so if length is not what is expected, then IMO it should be looked at as a bug.

I’ve supplied elements this way for computer game work in the past - and completely relied on the punch in and out points being correct. (I was re-recording 3 or 4 layers at a time back into nuendo - using groups back into audio tracks) but I think it was N4 from memory!)

Wheels - it is not enough to say it is not a problem at all when in some situations (like game sound) EVERY last sample counts. Yes - it may not be that 99.9% of the time that single sample is “not a problem” but what about at other times.
(Say, when you are comparing one track to another using phase reversal… or…)

And 1857 samples IS a big deal for the tail - in certain situations.

YMMV, but from where I sit, attention to detail is important; something that may seem trivial to one user may be a show stopper or workflow killer to another.

Chewy - yes, bouncing might help the situation - but when you have 1000’s of small files to do, using already setup cycle markers, and re-recording back into nuendo can save DAYS of time, especially if there are multiple versions or multiple layers to output.

Just my point of view - though I’m one for miss using (abusing!) technology for workflow improvements…

Brendan.

Thanks Brendan, you state it very well. I could also sight many more examples why this needs to be corrected. I have two Nuendo 5 rigs and both are doing it. I have not totally done scientific tests to absolutely confirm the behaviour. So I would appreciate others to test and confirm. In fact the post record length is not consistent. I’ve recorded several takes of the same range with different length tails beyond the right locator punch-out.

I too have been working this way for years and only recently discovered this odd behaviour. My entire work flow will have to change if there is not a way correct.

Nuendo is great
Fox

I always record my stem and other delivery requirement busses. I always end up recording in chunks and punching in nitpicky fixes as I go. Since commercial breaks and leader time need to be exact for the tapes, I select all the bits and bounce as one. This kills many birds with one stone, including the file length issue.

Maybe so; I guess it depends on what you’re doing. The “Kid Dropper Method” describes how I do TV deliverables, and it works really well. For me, as a rule, especially when providing stems or multiple tracks for transfer, bouncing at once is a great way to make sure everything starts at the right place. Plus, if you’re dealing with lots and lots of files, it can make them easier to find in the audio folder when you’re pulling them out. Certainly there would be situations where this might not be the most effective strategy.

Whatever works. Not suggesting that unwanted extra length is not a problem!

Chewy

Ok I did some further testing, starting from an empty project.

Normal:

  1. When the input to your record channel is connected directly from a VST input (channel input = Stereo In), your recorded files match the range exactly as expected. This is good

BUG:
2. When the input to your record channel is connected to a Group Channel (channel input = Group 1), the recorded file randomly overshoots the punch-out point while the event clip is exactly the length of the range. The recorded file is longer than the range and the event clip. This is BAD and should be added to the Bug List.

This is unfortunate for me because I have, what I thought was, an awesome setup using a group channel as my mix output which feeds my 2mix record track. Now becouse of the bug, all mixes done this way are the incorrect length.

This is a bug, I hope Steinberg will add this to their to-do list and correct. I hope my description is clear enough. Let me know if it needs clarification. There may be variations to this problem so I encourage others to explore, recorded range lengths.

Nuendo is great
Fox

Sure thing. Though, I hate having to go into the default Audio Folder to retrieve bounced files. It becomes a file housekeeping mess. My method (recording to a channel) allows me to record my mixes into a selected system folder rather than the default Audio Folder. This file length bug puts a monkey wrench in my method, though. Of course, Export Mix is the other method to do this but since I always listen in real time (old school) to my final mix while recording, recording to a track in real time is a lot more efficient, flexible and simple. Export Mix also gets a little messing when using external FXs.

Fox

True, all that.

Chewy

Jim,


I don’t think this ever was supported.
Nuendo assumes that you will always export the files, and not use the recorded files as such.

I am very familiar with your workflow (recording masters/stems into another track) but I gently disagree with you on the way you want to use them. What you are asking for would only make sense when we would have destructive recording. If you are sending your files -as such- to your client, then you also have to record that file in one single pass. Which doesn’t make sense, you could as easily (and as slow) export the project real time and re-import your file into your project. (There’s an option for that in the export window) The main purpose of re-recording the master/stems into the DAW is that you can easily make fixes, change things, or even record them over a period of days. With your way of working, you exclude all these benefits. In other words, you are not faster -on the contrary- and there is no benefit in it.


As said, we do this all of the time, mainly to be able to mix a project over a longer time, make quick fixes and changes. So we never end up with a single file. As you can see, our re-recorded tracks are always a collection of bits and pieces. When outboard gear is used, we simply export the tracks and load them into a “clean” project, so we can export a 25 minutes episode within 30 seconds. When no outboard is used, you can even use the batch export feature in your original project.

Don’t get me wrong, I am not trying to minimalize your problem, and if we would have destructive recording, it would be considered a major bug. But -as said-, I don’t think recording files was designed to be sample accurate.
I just want to point out that you are not taking any advantage out of the re-recording of masters/stems.


Fredo

I disagree here Fredo.

When re-recording mixes this way (I also does it like this over several days) you end up with a lot of ctus/fades in the re-record.
Then just doing a simple “bounce selection” on the tracks is enough to get a complete and sample accurate file.

BUT, if you take the complete file after a constant re-record (one pass = one file) then that file will also have a buffer at the start for the pre record buffers (default 1 second, my setting 3 seconds).
So this can NEVER be trusted.
But after a simple and very fast “bounce selection” you can trust the file taken from the pool (audio folder).

Best,
Pål

Granted, bounce might actually work too. But I prefer exporting the files into a “def” or “mq” folder, using proper naming protocols, etc … Also when working with multichannel files (which mostly need to go to a PT system), you need to flag the “don’t use wav extensible format”, etc … I also don’t like to go through the annoyance of having to pull out files out of the “audio” folder, the renaming of them and so on. I just think it makes everything more complicated.

BUT, if you take the complete file after a constant re-record (one pass = one file) then that file will also have a buffer at the start for the pre record buffers (default 1 second, my setting 3 seconds).

Even more, the pre-record is of no use when re-recording to tracks. There will be nothing in the pre-record part.


It seems that we actually agree on the fact that “recording in one pass” is not a good idea. Which was actually my point. Unless I misunderstood you.

Fredo

Agree on all you say.
But you din’t state all that in the last post :slight_smile:

White flag up! :slight_smile:

Once again we end up at: You have to know what you are doing, and know the deliverables.

/Pål

Wish I’d said that…

One of my favorite things about Nuendo is, in fact that there are so many ways to skin a cat.

Chewy

Skinning of cats is OT here I Think :slight_smile:

/P

Not if it’s done non-destructively, in real time… and if they bounce.

Chewy

True!

I think the root of the problem is not how to get the job done. We all appreciate how Nuendo allows us to work different ways. I for one choose to mix like I have for 30 years, multitrack - to mixer – 2 track. Nuendo is great, it allows me to work this way and more incredibly all in the box.

The problem with this bug is that Nuendo is recording a file that is randomly longer than the selected range, which is bad enough, but to compound the problem it creates an event that does not reflect the actual file length just created. I am shocked this is not considered a bug. At least the event should show what was just created. The recorded event should match the recorded file.

And another thing, if because of this bug, we have to bounce a new file after recording it, why can’t we select which system folder to bounce to? I hate putting my mix files in the same folder as my track files.

Nuendo is great
Fox

FWIW, Jim-- events frequently don’t represent exact file length, or even one specific file at all-- if you’ve done any processing on any section of a file, for example-- you’re dealing with any number of files that play together as a single event… part of what makes editing in Nuendo so cool in post and restoration, in my experience.

All joking about cat-skinning aside, I don’t see this as a bug at all. Exporting’s always been the final step in the recording process, according to the manual, for what it’s worth. Bouncing tracks, aside from its other uses, is a convenient workaround to more quickly get a final product if no further processing is required.

I, as you do, however, wish we had the option to bounce-to-disk to location of choice. And, as long as we’re talking about file-length, that freeze files were actually useful outside the project–a similar issue for those of us who use vstis a lot, and where bouncing is just not an option. Maybe things could be streamlined in either case. But the software, in both of these examples, works as the documentation says it will… so as far as I can tell, you have more of a design complaint; it’s not a bug. No?

Chewy