have you ever tried making loop regions in Vegas and Mixing To New and then butting those up against each other to see if they play seemlessly? They should. I do it all the time.

>have you ever tried making loop regions in Vegas and >Mixing To New and then butting those up against each >other to see if they play seemlessly? They should. I >do it all the time.

That's exactly what I've tried in Vegas.
I'm working with 24-bit files first of all.
I drop two markers on a single file on track #1. (marker #1 and marker #2)
I set the volume to 0 (no change) and have no plugins in the chain.
I highlight a loop region from the first sample to marker #1, do File->Render as, check the "render loop region only" box, save it to a new file (file #1).

I then highlight a loop region from Marker #1 to Marker #2, do File->Render as, check the "render loop region only" box, save it to a new file (file #2).

I should now have two files that I should be able to reassemble seamlessly.

I take file #1, drag it into a new track (track #2), and then take file #2 and drag it into the same track, butt up against file #1, with no overlap. Both of these files should line up exactly under the file that I made the clippings from

At the sample level, I zoom (horizontally) into the point where the two files meet. I then zoom vertically to exaggerate the slopes of the waves.
*The last sample of file #1 does **not** line up*.
Furthermore, it should look exactly like the track #1 above it at the joining point, and it doesn't.

Everywhere else, the new track looks identical to the track #1 above it, and the two files of track #2 add up to the same number of samples as the section I created them from in track #1.

Try this yourself. If it doesn't do it for a 16-bit file, try it with a 24-bit file, which is what I'm working with.

Anyone that would like a snapshot of this from my screen as proof, I'd be happy to send you one.

And no, it's not just a display bug. I often get an audible click at the point where it switches from file to file. (it's not always audible, but I know it's there). And if I then delete track #1 (the original track), and render this newly created track #2 to a single file, the corruption is there in the new file.

This is just not right. And if you do it all the time, then it's time for you to do this test and see what you've been doing to your audio all this time.
I did, and now I'm not happy at all.

-ccryder

Does the end of file 1 match up with the *beginning* of file 1?

You are asking SF to create a LOOP, yes? In a loop, the waveform amplitude should transition back to the beginning of the *same* file, seemlessly...

Is this perhaps an "intelligent" function of SF products actually giving you what you asked for...a LOOP?

I don't know the answer to this question...I merely hypothesize this possiblity.

And one other idea...Have you checked for / corrected for DC Offset in the recording?

Ccryder -
I just tested with 16bit and 24bit files. I do see and hear what you are talking about. I actually can only hear it if I scrub through it. I also see that the render is slightly longer than both selected loop regions. It's easy to tell this if you do a Mix To New rather than a Render because then it just plops the new render exactly in the same place on a new track.

hmm. Sonic? Any explanation?

When editing sustaining sounds fades *can* cause "thumps". Since the days of cutting tape most people attempt to do edits in the non-sustaining areas of audio to avoid obvious edit points. This is often the most seamless approach. Sometimes this is impossible and then fades and crossfades are often used to help mask the discontinuities of the edit points.

Both Forge and Vegas automatically do fading (to 0dB) at edit points - otherwise most edits would cause a "discontinuity" in the audio signal that would make a click or a pop. Both Sound Forge and Vegas allow these fades to be avoided if desired.

In Sound Forge uncheck the "Pre/Post fade destination edges" checkbox on the dialog used that comes up for stuff like "paste mix".

For Vegas either edit the individual fade in and fade out at the edges of the events or set the pref for fades to be 0ms and it will never fade any events (probably causing a pop and click fest at most edit points). Note Vegas does not fade in events when their start points are exactly the beginning of a file or fade out the end point when it is exactly the end (we assume the file was "popless").

Some other approaches to avoid fades are to cut audio at zero crossings or to use the "pencil" in Forge to erase discontinuities. This is often difficult and time consuming.

right, but I think what ccryder's trying to point out is that even if you have no fade in Vegas and mix to new, you will get a last sample that does not corrolate to the last sample of the original selection. You do have to zoom in all the way to see it. Plus, the length of the render is not exactly the same as the original selection.

Note: Fade Event edges is turned OFF, no effects, no quantize to frames, blah blah bah. It doesn't particularly bother me as I really never have a need to make new renders to make a continuous cd, etc. since CD arch and DAO burning in Vegas make it possible to do all this non-destructively, but to be REALLY picky, it's not 1:1 rendering with the last sample.

right ccryder?

SonicIMC:

Both Forge and Vegas automatically do fading (to 0dB) at edit points - otherwise most edits would cause a "discontinuity" in the audio signal that would make a click or a pop. Both Sound Forge and Vegas allow these fades to be avoided if desired.

Yirm:

I saw this fading in VideoFactory and didn't like it. I was told there is a hidden option to toggle this off, but can't remember it offhand. I access the hidden parameters with Options > Shift/Preferences. What do I do from there again?

I noticed the thump when I allowed VF to do the fades. When I manually removed them, there was no click or pop at all. It was entirely seemless.

-Jeremy

Charlesdem thankfully wrote:
>>>
right, but I think what ccryder's trying to point out is that even if you have no fade in Vegas and mix to new, you will get a last sample that does not corrolate to the last sample of the original selection. You do have to zoom in all the way to see it. Plus, the length of the render is not exactly the same as the original selection.

Note: Fade Event edges is turned OFF, no effects, no quantize to frames, blah blah bah. It doesn't particularly bother me as I really never have a need to make new renders to make a continuous cd, etc. since CD arch and DAO burning in Vegas make it possible to do all this non-destructively, but to be REALLY picky, it's not 1:1 rendering with the last sample.

right ccryder?

*Right!* No fades are enabled at all, and this problem still occurs. Furthermore, as I previously stated, the software doesn't always seem to follow any kind of "fade to 0dB" logic. Quite often, the last sample ends up being far away from 0dB. I've often seen a wave that tends toward 0dB actually get changed at the last sample to *move away* from 0dB!

The SW, without any fades or processing applied to any of the file or any of its edges, seems to simply make up some random value of the very last sample of a file and apply it *quite* undesirably. If I wanted a fade at the edges, I'd ask for it. I don't care about the software trying to do me the favor of saving pops and clicks, because apparently, it doesn't work anyway, and in fact, for my purposes, it actually *inserts* pops and clicks.

I didn't see the affect of any differences in length of the files. The two files butt up against each other appear to be the same exact length as the original section from which I cut and pasted. FWIW, there is no apparent change to the beginning of the cuts, only the ends.

Charlesdem, thanks for supporting me with this one while I was away from my machine and couldn't respond quickly. Sonic Foundry? Where do we go from here? Can I get a bit transparent cut and paste operation?

-ccryder

The reason this is all necessary is because when recording a long concert at 24/48, I end up with a wave file that is very long, up to 2GB. It is desirable to be able to break up the file into smaller pieces (songs) to be able to burn the individual songs to data CD's for *seamless* playback with Winamp. Also, I'm trying to prep my material for burning to DVD-R, which no SF product currently supports.

I figure breaking up the large file into smaller parts or songs will allow me to play back my 24-bit material in Winamp right from CD for now, while getting me ready for easier burning to DVD-R. Also, since these are live shows, it is a necessity that the files can be played back contiguously *without* any type of anomalies between tracks. Finally, it is nice to be able to feed the tracked 24-bit files into Batch Converter for conversion to 16/44.1 so I can make CD's very easily from my 24-bit material and have it already tracked out.

In fact, this is how I discovered that the processs I had been [erroneously] relying on by using SF5.0 to mark, convert markers to regions, and extract regions to files, and then batch convert the files to 16/44.1, was flawed. When mastering these live CD's, I always check the track boundaries by rewinding 2 or 3 seconds into the previous track and then listening for pops and clicks when the track changes. I found these pops and clicks on a CD I made this way, and traced it back to the source (the cut and paste operations in Sound Forge 5.0). I then tested out several scenarios with SF 5.0, and Vegas 2.0 as well, and both created these anomalies by messing with the very last sample in every file.

Breaking up these large files into songs is also a requirement for being able to transmit them easily over the net after compressing them.

FWIW, if I were to leave the whole 24/48 file intact, convert it to 16/44.1, and track everything with SF 4.5 and burn CD's from the monolithic file in CD Architect, I get none of these anomalies.

However, this behavior is totally unacceptable for preparation for 24-bit DVD-R recording and internet transmittal of 24-bit material where it is desirable to maintain seamless bit transparency throughout the whole show, regardless of how many contiguous pieces the file is broken into.

-ccryder

One last thing:

Even when applying a fade to 0dB in SF 5.0 to the end of a file, the last sample, that *should* be 0dB, is not when the last section (containing the fade out at the end) is cut and pasted or rendered to a new file.

Any logic that explains the supposed behavior where there is an attempt to make the last sample=0dB of every file saved is flawed, because if the last sample is already 0dB when it is faded out to 0dB, there should be no action. Instead, there apparently is a random number applied to the last sample of the file.

-ccryder

I saw this fading in VideoFactory and didn't like it. I was told there is a hidden option to toggle this off, but can't remember it offhand. I access the hidden parameters with Options > Shift/Preferences. What do I do from there again?
---------------------------------
I don't think you need to go into the hidden prefs area. Options/Prefs/Editing uncheck "Fade edit edges of audio events" Factory default is set to 10 milliseconds.

Craig H.

Hi,

I just also confirmed this bug with Rendering Loop Regions (Vegas 2.0b, 16 bit files). All of the preferences that you mentioned are turned off and yet this behavior is still evident: the last sample is changed (visually it looks like micro linear fade to 0 db). Also, it appears that the file is one sample shorter.

Please try the steps that ccryder outlined and see for your self. Let us know what you personally find out and what Sonic Foundry "officially" has to say about this - ASAP!

Hi,

First of all, thanks for you clear and detailed messages about this bug. Hopefully, Sonic Foundry will confirm it and fix it ASAP.

The bug appears to be limted to Rendering. As a work around you might consider cutting and pasting the marked loop areas to the new track. The problem doesn't occur with cutting and pasting, Ctrl dragging, Splitting, etc. This won't help with batch processing, however.

We are working on this. Details to come.

Hi,

It's been a few weeks - any word on this from SF?

On 11/30/01, Sonic Foundry wrote:
>We are working on this. Details to come.

I asked again a few weeks later and there has been no reply. Well, ahem, the holidays are over, everyone's back to work and I'd really like to find out what SF is planning to do about this confirmed bug? A fairly serious one, IMO.

Thanks...

We have fixed the bug relating to the render to new sample error. It will be out with the update.