Project settings match file format of 24 bit 48k, render qual set to best but I can't image that part matters.

When asked for the "render format," did you render it to .wav, .mp3, .aif, .rm, .wma, what?

This matters a lot.

For instance, if you rendered it as an mp3, there is a data bit inserted at the beginning of the file, which causes exactly the kind of offset you described. This is part of the industry .mp3 standard and cannot be worked around in Sony software.

If this is the case, a search of these forums (esp. Sound Forge) will lead you to several detailed explanations of this issue.

Also, are you sure your source file is 24/48? If the source and the project settings do not match, of course it is going to look different on the timeline. Is this only a visual problem, or can you see it after rendering a new 24/48 PCM WAV of the overlaid clips? Uploading some examples somewhere would certainly be a help.

Providing the most detailed information about your problem will often get you the best answers and give others the chance to try to replicate your issue if it is not one that is already known.

Render format = file format, in this case 24/48 mono wav. That is the point. I'm making a clone copy, and it is apparently delayed by one sample. Either that or there is something buggy in the way the new file is set down between the I/O markers that makes it appear to be delayed. I didn't have time to explore the bounds of this issue. I'm asking to see if anyone else has noticed this phenomenon.

Given the information you provided, I was able to reproduce the behavior you described, and determine the cause.

If you merely set loop points in Vegas Pro, they may fall on or in between sample points. This is also true if you set markers or regions, as they do not automatically snap. This is especially true if you are zoomed out on the timeline. If the loop in / out points fall between sample points, as they often do, and you choose to render the loop region (rather than copy and paste), Vegas has no choice but to go to the beginning of the last full sample and begin rendering from there. Thus the beginning of the first rendered sample will not line up exactly with the loop or marker in-point. I noticed this because precise examination showed that the offset was not exactly one sample, which made no sense from a rendering standpoint. The reason for this behavior in Vegas (unlike Sound Forge), is that loop boundaries must generally be set to frame boundaries, not audio samples, when editing video. (Maybe a "quantize to audio samples" feature is something you would like to request.)

The workaround / solution for this understandable behavior is to set your loop region boundaries exactly at sample snap points. The only practical way to achieve this on the Vegas timeline is to first set Time Fomat to Samples, Enable Snapping, turn Quantize to Frames off, and zoom in full. Then drag the loop in / out points (and/or set markers) to a 5-sample boundary, where they will snap (this is the tightest snapping resolution possible in my 8.0c).

Upon doing this, and assuming your source, project, and render sample rates all match, you can then render a PCM WAV, that when placed on a new track and aligned to the loop region or markers, will line up sample-perfect with the original; or, in your case, line up perfectly out-of-phase (canceled) with the phase inverted.

Even if you didn't have time to investigate this thoroughly, to raise it as an issue would be a serious cause for concern for professional users if what you reported affected us or was reproducible. Sony would be very interested also, if there was such an obvious bug in the software.

That's why I took the time to press you for enough details to set up a test case. It would affect me personally if it had not been possible to determine that this issue has a simple explanation. I've done physical acoustics labs and classroom demonstrations since the early Sonic Foundry days (read that fifteen years), and if the stereo phase cancellation demonstration didn't work perfectly every time, well . . .

Thanks for providing enough information to result in an answer.

Many thanks for getting to the root cause, musicvid. I really appreciate you taking the time to investigate and give such a clear explanation. Makes perfect sense.

One conclusion I draw from all of this is: if one is going to do internal bouncing by rendering track(s) and repositioning them on the time line, the safest way to make sure they line up precisely with original tracks is to start the render from t=0, rather than a marker or the In point. Presumably this non-sample boundary issue you describe does not exist at t=0. Please correct me if I've got this wrong.

James

Oh, you can do it at markers and loop points, you just have to make sure they're snapped (to sample boundaries in the case of audio) first.

Have you tried Tools->Render to New Track ?
I've not recalled having any issues with this at all in the past.

Right, from your reply I got that if I took the time to make sure they were snapped to sample boundaries there'd be no issue. But I was looking for a simpler faster way to guarantee it, and for me setting the start point to zero would be easy for my work flow.

I've not tried render to new track. But I will.

The underlying motivation for this whole thing can be found in my new topic post about creating takes from events.

James

I must be missing something -- why do you want to render events as takes?

Why not just select, copy, and paste events or groups of events on new tracks or where you want them?

Ah, well here's my reason. Others may not find this applicable, but I'm guessing some may.

Suppose you've got, as I do, several events, side by side, that represent three takes of a flute performance. Your goal is to comp these into the best overall single performance. I've done this kind of thing two ways:
1. between different parallel events that reside on individual tracks
2. between different takes that reside in the same event on a single track

Method 2 is far and away more efficient and less disruptive to the musical brain.

That's why.

James